<ui:style> src attribute causes error in the Google Eclipse plugin
Philippe Beaudoin
@def darkPanelColor #fcb072;@def lightPanelColor #fcd5b6;@def messageBoxColor #fad163;@def titleFontWeight bold;@def titleFontSize 22px;@def titleColor #921b12;@def minAppWidth 700px;@def leftColWidth 200px;@def formLineSpacing 8px;
<ui:style src='../../defines.css'>
Thomas Broyer
- running DevMode: it'd be hard (or very convoluted) to run DevMode with its embedded server when your code is split in several apps, while still supporting "hot refreshes". But this is actually a global issue with Maven, that you also have when coding a multi-module webapp, see http://stackoverflow.com/q/3636493
I tend to think this is on-purpose with Maven: favoring unit-tested modules rather than "integration-tested", manually tested, applications.
We've opted for -noserver and a separate Jetty server (using WTP, but it would work with mvn jetty:run) - some plugins (cobertura, checkstyle, pmd, findbugs; maybe not all of them, but at least some, and I can't remember those) are apparently looking at any class that has its java counter-part in the classpath; or is it the maven-compiler-plugin compiles them? (why is it compiling sources that don't come from the project.build.sourceDirectory, isn't it the actual bug?)
Brian Reilly
away with adding src/main/resources as a source folder in the Eclipse
project if it isn't already. It's been a while since I've used
Eclipse; I don't know if that would be enough to make the GEP happy.
If calling src/main/resources a source folder seems dirty to you (as
it does to me), I think a convention of having a src/main/gwt would
work nicely. It could be configured in both maven and Eclipse as a
source folder. Then GWT-specific .css, .ui.xml, .gwt.xml, etc. files
wouldn't pollute src/main/java.
> All of these are why I do think that GWT projects in Maven should have a
> specific type/packaging (or actually several specific types: one for "GWT
> libraries", that are only packaged as JARs, and one for "GWT apps", that go
> through the compiler to generate javascript files, that you'd then use in a
> packaging=war module).
> See http://www.sonatype.com/books/mvnref-book/reference/flex-dev-sect-multimodule-archetype.html for
> an example of what I mean, just using "shockwave" libraries (swc) and
> "shockwave" applications (swf), later used by a webapp.
Excellent point. I would really like to see this as well. I don't know
much about maven internals, other than the fact that even the most
basic operations are implemented as plugins. I assume that it would be
possible to add new packaging types using a plugin.
> But there are two kinds of "libraries": client-only code (gwt-google-apis or
> GIN for instance) and "shared code", where you don't want to have your
> source code deployed to your server as "resources" in the JAR (so you'd need
> two JARs).
Would it be so bad to have the source for shared code to be deployed
as "resources" on the server? I don't imagine they would get in the
way, and wouldn't do any harm... as long as they're not some place
where the webapp container could serve them...
> The main "complication" is if you want to still support "simple webapps"
> where everything (client, shared and server code) is in one module; but I
> think that if you use Maven, you should have separate modules for client and
> server code.
I think "simple webapps" could still be done using the traditional war
packaging. Since everything is in one place, you don't need to worry
about packaging the sources. Getting back to the original post, the
CSS in that case is definitely a source rather than a resource. Again,
it can be in some directory other than src/main/java that is
configured as a source folder.
> The drawbacks of all these are:
>
> running DevMode: it'd be hard (or very convoluted) to run DevMode with its
> embedded server when your code is split in several apps, while still
> supporting "hot refreshes". But this is actually a global issue with Maven,
> that you also have when coding a multi-module webapp,
> see http://stackoverflow.com/q/3636493
> I tend to think this is on-purpose with Maven: favoring unit-tested modules
> rather than "integration-tested", manually tested, applications.
> We've opted for -noserver and a separate Jetty server (using WTP, but it
> would work with mvn jetty:run)
Maven is most definitely a tool aimed at reliable, reproducible
builds. To that end, it actually does somewhat of a disservice to
developers in cases like this. That's not going to stop a lot of
projects from adopting maven, however.
Beyond the -noserver option, I think using a tool made for developers,
specifically an IDE that understands maven, can help overcome this. I
don't think that maven should be configured to reach across the
boundaries of modules (as suggested by some on stackoverflow), but
there's no reason why an IDE can't... and I bet that most do. If the
IDE understands GWT applications and can launch them directly, I bet
they do (or at least could) set them up nicely to allow quick
change/test cycles.
> some plugins (cobertura, checkstyle, pmd, findbugs; maybe not all of them,
> but at least some, and I can't remember those) are apparently looking at any
> class that has its java counter-part in the classpath; or is it the
> maven-compiler-plugin compiles them? (why is it compiling sources that don't
> come from the project.build.sourceDirectory, isn't it the actual bug?)
I may not understand what you mean here, but PMD and findbugs operate
on the bytecode, so they don't need the source. Checkstyle operates on
the source, and I'd be surprised if it reaches across modules when run
from the maven plugin. I'm not sure about cobertura (might need the
source, or might just use debug info in the JAR).
-Brian
John
times, since I have multiple modules that each have the same copy of
my define.css file in them (since you can't use CssResources as a
src ...), so I have to drop a whole directory structure into my war.
I think - and I haven't tried this yet - but I think that if we moved
the define.css to a public directory as defined in the *.gwt.xml file,
then it would copy over correctly, and the relative paths would stay
correct.
John
On Mar 4, 9:14 am, Brian Reilly <brian.irei...@gmail.com> wrote:
> First, one idea about the original question. You might be able to get
> away with adding src/main/resources as a source folder in the Eclipse
> project if it isn't already. It's been a while since I've used
> Eclipse; I don't know if that would be enough to make the GEP happy.
>
> If calling src/main/resources a source folder seems dirty to you (as
> it does to me), I think a convention of having a src/main/gwt would
> work nicely. It could be configured in both maven and Eclipse as a
> source folder. Then GWT-specific .css, .ui.xml, .gwt.xml, etc. files
> wouldn't pollute src/main/java.
>
> > All of these are why I do think that GWT projects in Maven should have a
> > specific type/packaging (or actually several specific types: one for "GWT
> > libraries", that are only packaged as JARs, and one for "GWT apps", that go
> > through the compiler to generate javascript files, that you'd then use in a
> > packaging=war module).
Philippe Beaudoin
Hilco Wijbenga
You can most certainly put all of your resources (*.css, *.ui.xml,
*.gwt.xml) in src/main/resources. You do have to make sure that when
you add src/main/resources as a source folder in Eclipse that
Eclipse/Maven do not add an exclusion filter (i.e. remove it).
Another option is to use the Java annotation [i.e.
@Source("../../defines.css")] and use ui:with instead of <ui:style> in
your *.ui.xml. This works very well.
Hilco Wijbenga
> There's a deeper question there: are UiBinder ui.xml, LocalizableResources
> properties, ClientBundle css, images, etc. "resources" or "sources"?
From Maven's point of view: yes, they are resources, not sources.
Sources contain source code (i.e. Java code).
> Because these are all about client-side code, which is meant to be given to
> the GWT Compiler, I tend to think of them as "sources" more than
> "resources".
Resources are available to all Maven plugins and tools. Just like,
e.g., a Hibernate configuration file. So the fact that a resource is
given to the GWT compiler doesn't make it a source (from Maven's point
of view).
> In the context of a "GWT library" though, you don't give them directly to
> the GWT Compiler and you'd want them in the packaged JAR so they'd rather be
> "resources"; but even Java files play both roles here: compiled by javac
> (and packaged as *.class files in the JAR) and packaged as *.java files,
> i.e. seen as "resources".
True but a rather unfortunate consequence of not being able to create
real GWT libraries. A "real" GWT library would not need to be
recompiled when included in the WAR project. A "real" GWT library
would only have resources and JavaScript (assuming no shared or server
Java code).
> This gets even blurier when your "GWT library" is made of "shared code".
> All of these are why I do think that GWT projects in Maven should have a
> specific type/packaging (or actually several specific types: one for "GWT
> libraries", that are only packaged as JARs, and one for "GWT apps", that go
> through the compiler to generate javascript files, that you'd then use in a
> packaging=war module).
That's an interesting idea. I would still like to be able to actually
GWT compile my libraries, though. That would seriously cut down on
compile time of the whole app. The GWT compiler would only have to
(re)link all the libraries together (I'm guessing) to create the end
result.
> See http://www.sonatype.com/books/mvnref-book/reference/flex-dev-sect-multimodule-archetype.html for
> an example of what I mean, just using "shockwave" libraries (swc) and
> "shockwave" applications (swf), later used by a webapp.
> But there are two kinds of "libraries": client-only code (gwt-google-apis or
> GIN for instance) and "shared code", where you don't want to have your
> source code deployed to your server as "resources" in the JAR (so you'd need
> two JARs).
>
> The main "complication" is if you want to still support "simple webapps"
> where everything (client, shared and server code) is in one module; but I
> think that if you use Maven, you should have separate modules for client and
> server code.
Yes, I agree.
> The drawbacks of all these are:
>
> running DevMode: it'd be hard (or very convoluted) to run DevMode with its
> embedded server when your code is split in several apps, while still
> supporting "hot refreshes". But this is actually a global issue with Maven,
> that you also have when coding a multi-module webapp,
> see http://stackoverflow.com/q/3636493
We create separate widgets that can run independently (in their
project). That way you don't need to run the whole app to work on
parts. Once such a widget is "done" you include it somewhere else and
it cannot be changed anymore (at least not directly in the including
project). This alleviates the problem to a large extent.
> I tend to think this is on-purpose with Maven: favoring unit-tested modules
> rather than "integration-tested", manually tested, applications.
Yep.
> We've opted for -noserver and a separate Jetty server (using WTP, but it
> would work with mvn jetty:run)
> some plugins (cobertura, checkstyle, pmd, findbugs; maybe not all of them,
> but at least some, and I can't remember those) are apparently looking at any
> class that has its java counter-part in the classpath; or is it the
> maven-compiler-plugin compiles them? (why is it compiling sources that don't
> come from the project.build.sourceDirectory, isn't it the actual bug?)
I'm not entirely clear what you mean here.
Brian Reilly
>> properties, ClientBundle css, images, etc. "resources" or "sources"?
>
> From Maven's point of view: yes, they are resources, not sources.
> Sources contain source code (i.e. Java code).
Java code is just one example. Groovy and Scala are not Java, but are
still source code. I would also consider .ui.xml files to be source
code. Leaving aside libraries for the moment, they are not bundled in
the final artifact and are instead compiled into an entirely different
form.
>> Because these are all about client-side code, which is meant to be given to
>> the GWT Compiler, I tend to think of them as "sources" more than
>> "resources".
>
> Resources are available to all Maven plugins and tools. Just like,
> e.g., a Hibernate configuration file. So the fact that a resource is
> given to the GWT compiler doesn't make it a source (from Maven's point
> of view).
True. However, by default, there is an implication that resources will
be copied (possibly with filtering) directly into the target packaging
area during the build. Here's a subset of the maven lifecycle. Note
the description of process-resources (I've included the surrounding
phases for context).
* generate-sources: generate any source code for inclusion in compilation.
* process-sources: process the source code, for example to filter any values.
* generate-resources: generate resources for inclusion in the package.
* process-resources: copy and process the resources into the
destination directory, ready for packaging.
* compile: compile the source code of the project.
* process-classes: post-process the generated files from compilation,
for example to do bytecode enhancement on Java classes.
If you have files in your project that:
* are needed for compilation
* don't fit in any other source directory under src/main (e.g. src/main/java)
* shouldn't be included in the final artifact
you can either:
* put them in src/main/resources and configure a resource exclude
* add another source directory under src/main and configure a source include
The types of files that Thomas mentioned are in this category. If I
were to be concerned with not polluting src/main/java with these, I
would choose to add another source directory.
Finally, as Thomas pointed out, whether or not the files are included
in the final artifact depends on whether it's an application WAR or a
library JAR. I've been assuming WAR above. For a JAR, I would probably
use the same directory structure for consistency and just change the
includes/excludes to get the files packaged correctly.
Though I also agree that it's unfortunate that they can't be
configured the same, compiled separately, and linked together for the
final application WAR.
-Brian
Hilco Wijbenga
>>> There's a deeper question there: are UiBinder ui.xml, LocalizableResources
>>> properties, ClientBundle css, images, etc. "resources" or "sources"?
>>
>> From Maven's point of view: yes, they are resources, not sources.
>> Sources contain source code (i.e. Java code).
>
> Java code is just one example. Groovy and Scala are not Java, but are
> still source code. I would also consider .ui.xml files to be source
> code. Leaving aside libraries for the moment, they are not bundled in
> the final artifact and are instead compiled into an entirely different
> form.
I haven't worked with Groovy/Scala and Maven. Are you saying
Groovy/Scala code is supposed to go in src/main/resources? That would
indeed be strange.
The *.ui.xml files are certainly outliers. It would be nice to have
separate directories for specific GWT stuff. Maybe
src/main/gwt-resources or simply src/main/gwt.
Yep, agreed.
> The types of files that Thomas mentioned are in this category. If I
> were to be concerned with not polluting src/main/java with these, I
> would choose to add another source directory.
I'm too lazy to do so but I agree. :-)
Brian Reilly
> Groovy/Scala code is supposed to go in src/main/resources? That would
> indeed be strange.
Generally, no. Groovy (and maybe Scala too) is a little bit of an
unusual case because (I think) you don't actually have to compile the
source ahead of time. I would compile it, but if I didn't, I still
wouldn't use src/main/resources for Groovy code. The project I work on
does have some tests written in Groovy that live in src/test/groovy. I
was figuring the same convention would apply to src/main for Groovy,
Scala, etc.
> The *.ui.xml files are certainly outliers. It would be nice to have
> separate directories for specific GWT stuff. Maybe
> src/main/gwt-resources or simply src/main/gwt.
I like src/main/gwt myself. Indicates non-java sources that are used
by the GWT compiler. Packaging of the files depends on whether it's an
application or a library.
Now, wouldn't it be nice to have a couple of maven packaging types
that followed these conventions automatically...
-Brian
Philippe Beaudoin
Hilco Wijbenga
I assume you already saw and tried this:
? Secondly, you might have a look at the "additionalConfig" parameter.
You probably already looked into both. The only other thing I can
think of is some Antrun plugin thing that "fixes" the .classpath.
That, or try to add explicit support for what you want to the Maven
Eclipse plugin?
