[POLL] Maven project layout, what to "standardize"?

[Thomas Broyer]

Hi all,

As some of view may already know, I'm porting GWT to use Maven as the build system (instead of Ant). I'm also about to "reboot" GWT+Maven integration (more to come by the end of the week, stay tuned).

As part of this effort, I'm wondering which project structure to use as the default, "standard" layout for GWT projects using Maven? I'm particularly looking for advice/preferences for GWT library projects (such as GWT itself, mgwt, Errai, GXT, etc.), not much for GWT applications (the one you run the GWT Compiler on).

NOTE: this poll is cross-posted to the GWT and gwt-maven-plugin groups, please answer only once! (wherever you want)

The question is about where to put files such as: GWT module descriptors (*.gwt.xml), GWT "processed resources" (*.ui.xml, etc.), and super-sources.

It comes without saying (for me at least) that Java sources would go into src/main/java and "public resources" (i.e. the things within **/public/**, e.g. the CSS and image files from the themes) into src/main/resources, so the "everything" below only refers to those other files listed above.

Remember I'm only interested in defining the "standard layout" for GWT libraries, and please think about them as GWT-only libraries, not the kind with server-side and client/server-shared code!

Note that in any case, src/main/java is also added as a resource folder (packaged within the JAR)

Here are the alternatives I thought about:

1. everything in src/main/java
   super-sources in src/main/resources
2. everything in src/main/resources
   
3. everything in src/main/resources
   super-sources in src/main/super (or gwt-super, or some other name, let's discuss that later as I suspect it's a bikeshed)

When casting your vote, do not hesitate to explain why you prefer that particular layout over the others, or why you don't like one of the proposed layouts. Also feel free to propose a fourth alternative.

[Stefan Ollinger]

Hi,

I would prefer alternative 2, since it follows the Maven standard project layout. Personally I sometimes put the .ui.xml and .gwt.xml files in the  src/main/java folder, since it allows for faster navigation in Eclipse. I guess that is mainly a tooling issue and should not have any impact on the standard we choose.

For super sources I am not sure what is best, since I dont use them.

Regards,
Stefan

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/npnUeQyrLXkJ.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Abraham Lin]

It comes without saying (for me at least) that Java sources would go into src/main/java and "public resources" (i.e. the things within **/public/**, e.g. the CSS and image files from the themes) into src/main/resources

I agree with this.

 

everything in src/main/java
super-sources in src/main/resources

 

The major drawback to this is that putting everything in src/main/java makes it more difficult to re-use filtering configuration for maven-resources-plugin. Placing the super-sources in src/main/resources may also cause filter-related "surprises."

 

everything in src/main/resources

 I suspect that this may cause problems/annoyances because project.build.sourceDirectory points to src/main/java by default. This also is subject to potential filtering issues.

everything in src/main/resources
super-sources in src/main/super (or gwt-super, or some other name, let's discuss that later as I suspect it's a bikeshed)

I like the idea of having the super-sources in a separate source directory. Objections to putting everything in src/main/resources are noted for option #2 above.

 

Also feel free to propose a fourth alternative.

I'd propose keeping non-super sources in src/main/java, public resources in src/main/resources, and super-sources in src/main/super. As different as GWT projects may be from other "normal" Java projects, I think there's still value in keeping to convention if it's possible and sensible to do so.

-Abraham

[Thomas Broyer]

On Tuesday, November 13, 2012 5:18:15 PM UTC+1, Abraham Lin wrote:

Placing the super-sources in src/main/resources may also cause filter-related "surprises."

Ah, good catch!

 

Also feel free to propose a fourth alternative.

I'd propose keeping non-super sources in src/main/java, public resources in src/main/resources, and super-sources in src/main/super. As different as GWT projects may be from other "normal" Java projects, I think there's still value in keeping to convention if it's possible and sensible to do so.

This is option 3 then (you agreed that "It comes without saying (for me at least) that Java sources would go into src/main/java", and I suppose that by "public resources" you mean not only **/public/** but also  *.ui.xml and the like)

[Abraham Lin]

This is option 3 then (you agreed that "It comes without saying (for me at least) that Java sources would go into src/main/java", and I suppose that by "public resources" you mean not only **/public/** but also  *.ui.xml and the like)

Ah sorry, I had misread your definition of "everything" to include non-super sources as well. But yes, I think that all non-Java files (e.g. module descriptors, UiBinder templates, **/public/** resources) should go in src/main/resources.

-Abraham

[Nader]

I vote for alternative 1, as it complies with maven convention and I had no problem at all with this structure.

[Thomas Broyer]

On Wednesday, November 14, 2012 11:16:11 AM UTC+1, Nader wrote:

I vote for alternative 1, as it complies with maven convention and I had no problem at all with this structure.

The question is about whether in a library *.gwt.xml and the likes should be seen as sources or resources, so calling out "maven conventions" is pointless (no offense). And on the contrary, people calling out "maven conventions" before generally were pointing that everything non-Java had nothing to do in src/main/java.

I take note of your vote though.

[Christoph Henrici]

I am not quite sure why super-sources should / must be treated differently? Back i am probably lacking experience and knowledge here....

I like the notion the *gwt.xml files are actuallly part of the sources and not resources for gwt libraries..... 

So that would be Option 1, without understanding the motivation for super sources into src/main/resources.... also why not if necessary src/main/super? 

[Brian Slesinsky]

It will be more convenient for Google if all Java code and Java resources (that is, things in the classpath) are contained in directories named either "java" or "javatests", and the path from there is where the file should show up in the classpath. We can copy files but it makes builds or mirroring slower and/or less transparent.

- Brian

[Thomas Broyer]

On Fri, Nov 16, 2012 at 1:56 AM, Brian Slesinsky <bsles...@gmail.com> wrote:
> It will be more convenient for Google if all Java code and Java resources
> (that is, things in the classpath) are contained in directories named either
> "java" or "javatests", and the path from there is where the file should show
> up in the classpath. We can copy files but it makes builds or mirroring
> slower and/or less transparent.

I fully understand that we'll have to make some concessions for GWT
itself to make it easier for Google (even though Matthew actually told
me the opposite); you don't expand variables in the About.properties
for instance, so the About class has to cope with placeholder values.
The scope of this poll is however not about GWT itself actually (we'll
see if we can apply the outcome to GWT or not; I'd love to do it so
that GWT can serve as a reference, but if it's problematic for you
then we'll do without and/or take a few liberties).

[Thomas Broyer]

Poll results: option 3, aka src/main/resources + src/main/super.

Bonus: it apparently works with the latest version of the GPE (wasn't the case before, where it –basically– only looked into src/main/java)

[Daniel Kurka]

Hi Thomas,

I have been out on devoxx and haven`t had time to cast a vote yet. 

I think its a good idea to go with a separate package like src/main/super for super sourcing.

Why are we thinking of moving resources out of src/main/java, what is the main advantage here?

-Daniel

[Matthew Dempsky]

On Thu, Nov 15, 2012 at 11:59 PM, Thomas Broyer <t.br...@gmail.com> wrote:

I fully understand that we'll have to make some concessions for GWT

itself to make it easier for Google (even though Matthew actually told
me the opposite);

Well, our build system is turing complete, so theoretically it should be possible to handle anything reasonable.  The default build rules make it slightly more convenient for us if source and classpath resources go in a "java" or "javatests" directory (just like Maven makes it slightly more convenient for them to go in src/{main,test}/{java,resources} by default), but obviously we can cope with other structures since GWT doesn't use those conventions currently anyway.

I actually expect as more and more external projects are adopting Maven, it's likely we can push for our internal tools to better cope with third-party projects that use standard Maven layouts.  And because of that, I think in the long-run in makes more sense for us to try to be as similar to what a standard Maven project would look like, rather than some weird mutant layout that no one's happy with.

Of course, that's just my 2c and might be fueled by naive optimism from having just joined the GWT team. :)  Also, I'm largely an mg user, so it's possible I'm overlooking issues with (e.g.) what our Eclipse environment expects.

[Thomas Broyer]

Le 16 nov. 2012 17:59, "Daniel Kurka" <kurka....@gmail.com> a écrit :
>
> Hi Thomas,
>
> I have been out on devoxx and haven`t had time to cast a vote yet. 
>
> I think its a good idea to go with a separate package like src/main/super for super sourcing.
>
> Why are we thinking of moving resources out of src/main/java,

Depends where you come from ;-)
Maven users where (almost) ALL complaining when GPE didn't see their files in src/main/resources.
If you think of src/main/java as the set of files processed by javac, then gwt.xml, ui.xml and the like should obviously go to resources (or some other, GWT specific, folder).

> what is the main advantage here?

Separation of concerns (even though java sources will end up processed the same as gwt.xml, they're also processed by javac, and generally not filtered), filtering, freedom (e.g. one might want to put the gwt.xml at the root of resources and define <targetPath> to relocate them in the appropriate package in the generated JAR, it'd make navigation easier in Eclipse – IntelliJ has a package presentation which makes this pointless –; I could see me doing that for super-sources in case I have a single module in my lib)
Honestly, it's mostly a matter of taste, and both would work and in 99% of the cases, but src/main/resources feels more "mavenish" (note: I was a proponent of src/main/java some time ago, I now believe it was mostly due to tooling).

[Brian Slesinsky]

Oops, my mistake! Carry on.

[Christoph Henrici]

I went the other way... having used maven before and being "new" to gwt.... i had  the *.gwt.xml intially in src/*/resources ... after a while i moved them to the src/*/java .... mostly because i felt they had much to do with the java code and package structure... 

[Joseph Lust]

In multi module projects, it is quite nice to have the Java sources and *.gwt.xml files in a single package in src/main/java. Spreading it out into the resource folder would make such projects a bit more difficult to maintain/navigate.

Sincerely,

Joseph

[Juan Pablo Gardella]

+1, and integrate well with eclipse too if have this files in src/main/java

2012/11/19 Joseph Lust <lifeo...@gmail.com>

In multi module projects, it is quite nice to have the Java sources and *.gwt.xml files in a single package in src/main/java. Spreading it out into the resource folder would make such projects a bit more difficult to maintain/navigate.

Sincerely,

Joseph

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/sxkhAHV--CkJ.

[Andreas Horst]

That's true. But I do not have to edit both Java files and GWT module descriptors at the same time very often. More often that's the case for UIBinder/CSS and Java files.

I have multi module projects with several hierarchy levels either but still prefer the src/main/resources option(s).

2012/11/19 Joseph Lust <lifeo...@gmail.com>

In multi module projects, it is quite nice to have the Java sources and *.gwt.xml files in a single package in src/main/java. Spreading it out into the resource folder would make such projects a bit more difficult to maintain/navigate.

Sincerely,

Joseph

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

[Thomas Broyer]

On Mon, Nov 19, 2012 at 4:54 PM, Joseph Lust <lifeo...@gmail.com> wrote:
> In multi module projects, it is quite nice to have the Java sources and
> *.gwt.xml files in a single package in src/main/java.

How is it related to multi-module projects?

> Spreading it out into
> the resource folder would make such projects a bit more difficult to
> maintain/navigate.

As I said, it's mostly a tooling issue. IntelliJ IDEA has a "packages"
view for instance that gives you the gwt.xml and java files in the
same treeview branch [1], and if you ask me, it's a shame that Eclipse
has no such feature (or I haven't found it).
I'm in Eclipse 99% of the time (still evaluating IDEA from time to
time, not ready to switch; I run into too many Java Swing bugs in
Linux with IDEA 11, some of them seem to be fixed in IDEA 12, but
there are still annoying ones) so I fully understand what you're
saying here, and that's the layout I've used for years.
When I ask myself what a "truly mavenish" layout should be though, I
rather put them in src/main/resources. But what matters most is that
both work and you're free to choose what works best for you (keeping
in mind that if you need/want filtering, then using src/main/resources
makes it easier). Best would be to document the pros and cons of each
approach IMO.

[1] http://www.jetbrains.com/idea/webhelp/project-tool-window.html

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

[Abraham Lin]

This is typically caused by incorrect project classpath settings (check the includes/excludes for the resources folder). It's not clear whether m2e or GPE is to blame here.

-Abraham

On Mon, Jan 28, 2013 at 4:02 AM, Olivier NOUGUIER <olivier....@gmail.com> wrote:

Hum 

  Sorry to say, that :

On Fri, Nov 16, 2012 at 2:34 PM, Thomas Broyer <t.br...@gmail.com> wrote:

Poll results: option 3, aka src/main/resources + src/main/super.

Bonus: it apparently works with the latest version of the GPE (wasn't the case before, where it –basically– only looked into src/main/java)

Is not true :(

In fact, from a fresh project, the *.gwt.xml file are not detected if they lies in src/main/resources ... 

Once the Launch configuration exists the file can be moved from src/main/java to src/main/resources.

--
You received this message because you are subscribed to the Google Groups "Codehaus Mojo gwt-maven-plugin Users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/codehaus-mojo-gwt-maven-plugin-users/-/JXHDJbf3zW0J.

To post to this group, send email to codehaus-mojo-gwt-...@googlegroups.com.
To unsubscribe from this group, send email to codehaus-mojo-gwt-maven-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/codehaus-mojo-gwt-maven-plugin-users?hl=en.

--
"Computers are useless. They can only give you answers."
- Pablo Picasso -

--

You received this message because you are subscribed to the Google Groups "Codehaus Mojo gwt-maven-plugin Users" group.

To post to this group, send email to codehaus-mojo-gwt-...@googlegroups.com.
To unsubscribe from this group, send email to codehaus-mojo-gwt-maven-...@googlegroups.com.

Visit this group at http://groups.google.com/group/codehaus-mojo-gwt-maven-plugin-users?hl=en.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[James Nelson]

Personally, I store all super source and .gwt.xml in src/main/resources, and never have a problem. (Eclipse 4.2; not too painful if you don't use GTK window manager)

No filtering, especially on src/main/java; the contract of maven is source goes into src/main/java, and it will go into the jar as compiled classes, while everything in src/main/resources goes in the jar, no filters needed.

When I want to produce a jar for gwt compiles, rather than include source into the jar of every module, I just make a single uber-module, which pulls in all the modules it needs, then using maven assembly plugin to combine all the dependencies and their sources into a single uber jar.  It works quite well; library code sticks to the specific modules it needs and no more, while the consuming code that gets deployed to the server simply pulls in the uber jar to get all the features bundled together.

This is also very good for code-sharing with the server; I can make the uber-jar provided so it's there for compiles, but rather than deploy a massive jar full of sources and resources to the server, it can just declare runtime dependency only on the submodules it needs, which only contain class files, like a good artifact ought to.  If any other modules needs the source of one of the gwt modules, it's free to use the sources classifier and get the sources jar, or the uber module and uber classifier to get everything bundled up.

On Monday, January 28, 2013 8:22:33 AM UTC-7, olivier.nouguier wrote:

IMHO GEP is to blame, please note that is is only the new GWT Launch UI that suffer from this issue ! If you move the *.gwt.xml file to "resources" afterward it will work. 

I will take a closer look asap.

To post to this group, send email to codehaus-mojo-gwt-maven-plugin...@googlegroups.com.
To unsubscribe from this group, send email to codehaus-mojo-gwt-maven-plugin-users+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/codehaus-mojo-gwt-maven-plugin-users?hl=en.

--
"Computers are useless. They can only give you answers."
- Pablo Picasso -

--

You received this message because you are subscribed to the Google Groups "Codehaus Mojo gwt-maven-plugin Users" group.

To post to this group, send email to codehaus-mojo-gwt-maven-plugin...@googlegroups.com.
To unsubscribe from this group, send email to codehaus-mojo-gwt-maven-plugin-users+unsubscribe@googlegroups.com.

Visit this group at http://groups.google.com/group/codehaus-mojo-gwt-maven-plugin-users?hl=en.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "Codehaus Mojo gwt-maven-plugin Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to codehaus-mojo-gwt-maven-plugin-users+unsubscribe@googlegroups.com.

To post to this group, send email to codehaus-mojo-gwt-maven-plugin...@googlegroups.com.

Visit this group at http://groups.google.com/group/codehaus-mojo-gwt-maven-plugin-users?hl=en.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Rob]

+1 Option 3

[Thomas Broyer]

On Sun, Feb 17, 2013 at 7:46 AM, Rich <rich....@gmail.com> wrote:

Thomas,

How does the plugin support supersource today. I've tried to piece this together from multiple searches and have something close to your option 3, but it's not clear.

1). How is the plugin configured to use main/src/super?

It's not. If you want to use src/main/super, you have to declare it as a <resource> in your POM.

 

2). If src/main/super is an overlay onto src/main/java then how does the super-souce path (which must be relative) work within the module XML? Or is it intended that you'll still do "path doubling" under super? (e.g., src/main/super/com/foo/super/com/foo/Bar.java for a module def in src/main/resources/com/foo/Foo.gwt.xml)

The latter. The way I do it is that I don't do "path doubling" but use <targetPath> in the <resource> declaration in the POM.

I.e. I have src/main/super/com/foo/Bar.java and

<resource>

   <directory>src/main/super</directory>

   <targetPath>com/foo/super</targetPath>

</resource>

It limits the super-sources to a single module though (it won't do com/foo/super and com/bar/super)

Also, I'll throw-in an alternative:

src/

  main/

    java/

    resources/ (Would we ever put Android "res" here? Why is GWT any different?)

    gwt/

      super/

      resources/

I must say I don't understand. How are src/main/gwt/resources different from src/main/resources? Remember that the poll was about "GWT-only libraries", not "shared libraries" (used in GWT client and server, or in GWT and pure-Java clients) or GWT applications.

 

Thanks,

RB

--

You received this message because you are subscribed to the Google Groups "Codehaus Mojo gwt-maven-plugin Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to codehaus-mojo-gwt-maven-...@googlegroups.com.
To post to this group, send email to codehaus-mojo-gwt-...@googlegroups.com.

Visit this group at http://groups.google.com/group/codehaus-mojo-gwt-maven-plugin-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

[Thomas Broyer]

On Sunday, February 17, 2013 6:37:38 PM UTC+1, Rich wrote:

Thomas,

Thanks very much for the response.

First, is there any way you can share a POM from one of your projects -- or ideally point me at an entire open source project that uses it?

Hmm, there's https://github.com/tbroyer/gwt-sandbox/blob/master/user/gwt-user-core/pom.xml but this is work in progress, and unnecessary complicated in some places. This is ongoing work to moving GWT itself to use Maven as the build system.

 

Many things aren't clear (to me) from the docs. Examples: 

1). You say add a <resource> tag.

The problem is if I add a single <resource> tag then the default src/main/resources seems to be overridden, so my guess is you mean something like the following added to the <build> tag:

    <resources>

      <resource>

        <directory>src/main/resources</directory>

      </resource>

      <resource>

        <directory>src/main/super</directory>

        <targetPath>com/foo/super</targetPath>

      </resource>

    </resources>

Yes, that's how Maven works. src/main/resources is only the default if nothing's specified.

 

And, in com.foo.Foo.gwt.xml contains

  <super-source path="super"/>

Yes.

Again, it's a guess since I still don't have hello-supsersource working.

2). The comments regarding goals are conflicting. E.g., for tests to run it's suggested to add:

          <execution>

            <goals>

              <goal>test</goal>

            </goals>

          </execution>

But to get source-jar to run as part of install you need something like:

          <execution>

            <phase>install</phase>

            <goals>

              <goal>source-jar</goal>

            </goals>

          </execution>

If src/main/java and src/main/super are declared as resources, then the sources will be added to the JAR, and you don't need a source-jar.

 

3). Giving up on source-jar for the moment (i.e., just having the top config), when I run tests, they just hang and timeout. In fact, if I just create a blank project from the archetype, that's what happens:

[INFO] Running junit.framework.TestSuite@29edc073

Process 1361122241179 is killed.

[WARNING] Forked JVM has been killed on time-out after 60 seconds

Is this from surefire:test, failsafe:integration-test or gwt:test?

4). Frequently, if I don't run clean first, the tests fails with exceptions: e.g., 

[INFO] Running com.foo.FooTest

[INFO] [ERROR] Failure in unit cache map load.

[INFO] java.util.concurrent.ExecutionException: java.lang.StackOverflowError

Hmm, this is a "pure GWT" error, unrelated to Maven (until proven otherwise); have you searched the GWT issue tracker? Errors in Unit cache loading are "expected" when upgrading GWT or changing JVM (GWT classes don't have a serialization ID), but obviously not in other situations.

[Rich Burdon]

Inline.

On Sun, Feb 17, 2013 at 2:12 PM, Thomas Broyer <t.br...@gmail.com> wrote:

Hmm, there's https://github.com/tbroyer/gwt-sandbox/blob/master/user/gwt-user-core/pom.xml but this is work in progress, and unnecessary complicated in some places. This is ongoing work to moving GWT itself to use Maven as the build system.

 

Many things aren't clear (to me) from the docs. Examples: 

1). You say add a <resource> tag.

The problem is if I add a single <resource> tag then the default src/main/resources seems to be overridden, so my guess is you mean something like the following added to the <build> tag:

    <resources>

      <resource>

        <directory>src/main/resources</directory>

      </resource>

      <resource>

        <directory>src/main/super</directory>

        <targetPath>com/foo/super</targetPath>

      </resource>

    </resources>

Yes, that's how Maven works. src/main/resources is only the default if nothing's specified.

Understood (now). I'm just making the point that from a docs clarity POV, it's important to tell folks to add both <resource> tags.

 

And, in com.foo.Foo.gwt.xml contains

  <super-source path="super"/>

Yes.

Again, it's a guess since I still don't have hello-supsersource working.

2). The comments regarding goals are conflicting. E.g., for tests to run it's suggested to add:

          <execution>

            <goals>

              <goal>test</goal>

            </goals>

          </execution>

But to get source-jar to run as part of install you need something like:

          <execution>

            <phase>install</phase>

            <goals>

              <goal>source-jar</goal>

            </goals>

          </execution>

If src/main/java and src/main/super are declared as resources, then the sources will be added to the JAR, and you don't need a source-jar.

I was hoping not to put src/main/java in resources since it contains many files that are not GWT compatible and I use JAR execution classifiers to filter these (e.g., **/gwt/** and **/android/**, etc.) So having the source-jar pick the appropriate files was convenient. I don't know how to reconcile both "exections". Perhaps this is my maven ignorance.

 

3). Giving up on source-jar for the moment (i.e., just having the top config), when I run tests, they just hang and timeout. In fact, if I just create a blank project from the archetype, that's what happens:

[INFO] Running junit.framework.TestSuite@29edc073

Process 1361122241179 is killed.

[WARNING] Forked JVM has been killed on time-out after 60 seconds

Is this from surefire:test, failsafe:integration-test or gwt:test?

Out of the box, here are the errors I get (command line options given to create archetype below my sig):

Error on "mvn test"

Tests in error: 

  initializationError(com.test.client.GwtTestTest): com/google/gwt/dev/cfg/Condition

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0

Error on "gwt:test"

[INFO] Running junit.framework.TestSuite@29edc073

[INFO] [ERROR] Errors in 'file:/Users/burdon/projects/src/testing/gwt_test/src/test/java/com/example/client/GwtTestTest.java'

[INFO]    [ERROR] Line 46: No source code is available for type com.example.client.GreetingServiceAsync; did you forget to inherit a required module?

[INFO] [ERROR] Unable to find type 'com.example.client.GwtTestTest'

[INFO]    [ERROR] Hint: Previous compiler errors may have made this type unavailable

[INFO]    [ERROR] Hint: Check the inheritance chain from your module; it may not be inheriting a required module or a module may not be adding its source path entries properly

[INFO] [ERROR] Errors in 'file:/Users/burdon/projects/src/testing/gwt_test/src/test/java/com/example/client/GwtTestTest.java'

[INFO]    [ERROR] Line 46: No source code is available for type com.example.client.GreetingServiceAsync; did you forget to inherit a required module?

[INFO] [ERROR] Unable to find type 'com.example.client.GwtTestTest'

[INFO]    [ERROR] Hint: Previous compiler errors may have made this type unavailable

[INFO]    [ERROR] Hint: Check the inheritance chain from your module; it may not be inheriting a required module or a module may not be adding its source path entries properly

Again, this is running mvn on a freshly generated, untouched archetype.

4). Frequently, if I don't run clean first, the tests fails with exceptions: e.g., 

[INFO] Running com.foo.FooTest

[INFO] [ERROR] Failure in unit cache map load.

[INFO] java.util.concurrent.ExecutionException: java.lang.StackOverflowError

Hmm, this is a "pure GWT" error, unrelated to Maven (until proven otherwise); have you searched the GWT issue tracker? Errors in Unit cache loading are "expected" when upgrading GWT or changing JVM (GWT classes don't have a serialization ID), but obviously not in other situations.

Yep. It's difficult to search for this kind of thing since so far since I haven't actually started writing any meaningful code -- just trying to build the samples. I know this is all work in progress, but as often the case with OS maven projects, I have no idea what is expected to be working (e.g., many of the JS related plugins are checked in completely broken and abandoned).

Your sandbox example is very simple -- i.e., there are no tests. Do you know if anyone is successfully using all of the plugin's features (supersource, test, source-jar, etc.) on a project other than GWT itself?

Thanks again,

RB

> mvn archetype:generate \

>    -DarchetypeGroupId=org.codehaus.mojo \

>    -DarchetypeArtifactId=gwt-maven-plugin \

>    -DarchetypeVersion=2.5.1-rc1

...

[INFO] Generating project in Interactive mode

[INFO] Archetype repository missing. Using the one from [org.codehaus.mojo:gwt-maven-plugin:2.5.0] found in catalog remote

Define value for property 'groupId': : com.example

Define value for property 'artifactId': : gwt_test

Define value for property 'version':  1.0-SNAPSHOT: : 

Define value for property 'package':  com.example: : 

Define value for property 'module': : Test

Confirm properties configuration:

groupId: com.example

artifactId: gwt_test

version: 1.0-SNAPSHOT

package: com.example

module: Test

[Rich]

Thomas,

Thanks very much for the response.

First, is there any way you can share a POM from one of your projects -- or ideally point me at an entire open source project that uses it? Many things aren't clear (to me) from the docs. Examples: 

1). You say add a <resource> tag.

The problem is if I add a single <resource> tag then the default src/main/resources seems to be overridden, so my guess is you mean something like the following added to the <build> tag:

    <resources>

      <resource>

        <directory>src/main/resources</directory>

      </resource>

      <resource>

        <directory>src/main/super</directory>

        <targetPath>com/foo/super</targetPath>

      </resource>

    </resources>

And, in com.foo.Foo.gwt.xml contains

  <super-source path="super"/>

Again, it's a guess since I still don't have hello-supsersource working.

2). The comments regarding goals are conflicting. E.g., for tests to run it's suggested to add:

          <execution>

            <goals>

              <goal>test</goal>

            </goals>

          </execution>

But to get source-jar to run as part of install you need something like:

          <execution>

            <phase>install</phase>

            <goals>

              <goal>source-jar</goal>

            </goals>

          </execution>

3). Giving up on source-jar for the moment (i.e., just having the top config), when I run tests, they just hang and timeout. In fact, if I just create a blank project from the archetype, that's what happens:

[INFO] Running junit.framework.TestSuite@29edc073

Process 1361122241179 is killed.

[WARNING] Forked JVM has been killed on time-out after 60 seconds

4). Frequently, if I don't run clean first, the tests fails with exceptions: e.g., 

[INFO] Running com.foo.FooTest

[INFO] [ERROR] Failure in unit cache map load.

[INFO] java.util.concurrent.ExecutionException: java.lang.StackOverflowError

Again, this is with a trivial hello world project -- no real code, just bootstrap and empty methods.

Really appreciate any pointers you can give me. I've been working with GWT since it's inception (actually internally as a Google employee on a different project) and very much appreciate your efforts to bring this to maven.

Thanks again,

Rich

To unsubscribe from this group and stop receiving emails from it, send an email to codehaus-mojo-gwt-maven-plugin-users+unsubscribe@googlegroups.com.
To post to this group, send email to codehaus-mojo-gwt-maven-plugin...@googlegroups.com.

Visit this group at http://groups.google.com/group/codehaus-mojo-gwt-maven-plugin-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

[dparish]

I think a major goal should be to cooperate with other container plugins, specifically Jetty.  I've been struggling with getting the Jetty plugin to fully cooperate w/ the gwt plugin and am astounded at how hard it is to:

1. Get my server code to be updated without a server restart (if the compiled code goes in WEB-INF/classes, just bouncing the webapp is enough.

2. Running in dev mode w/o having to do a compile to get the code in the right place in the exploded src/main/webapp directory

3. Start the jetty container w/ also doing a gwt compile (it should just compile the server side code)

I'd like to see an option in the GWT plugin where it runs much like it does with the GWT embedded jetty but with the jetty maven plugin instead.  

Why do I want the jetty plugin instead of the embedded jetty:

1. I get a later version of Jetty

2. I can customize Jetty more easily (authentication, jdbc, etc)

3. I can control the startup of Jetty more easily

4. I can use the same mvn to run and control a production version of Jetty

[Thomas Broyer]

On Mon, Feb 25, 2013 at 4:47 PM, dparish <dpa...@gmail.com> wrote:

I think a major goal should be to cooperate with other container plugins, specifically Jetty.  I've been struggling with getting the Jetty plugin to fully cooperate w/ the gwt plugin and am astounded at how hard it is to:

1. Get my server code to be updated without a server restart (if the compiled code goes in WEB-INF/classes, just bouncing the webapp is enough.

That's nothing to do with GWT right?

 

2. Running in dev mode w/o having to do a compile to get the code in the right place in the exploded src/main/webapp directory

compile into src/main/webapp !?!?!?

 

3. Start the jetty container w/ also doing a gwt compile (it should just compile the server side code)

mvn -Dgwt.compiler.skip jetty:whatever ?

But it suggests you have your client and server code in the same Maven module, which is wrong, to begin with.

Actually, the main issues I've got with the jetty-maven-plugin are that it doesn't work well with multi-module projects. the tomcat7-maven-plugin worked much better for me (either that or running Jetty standalone, configured with extraClasspath to pick classes from all dependent projects).

See https://jira.codehaus.org/browse/JETTY-1517?focusedCommentId=306630&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-306630 and https://github.com/tbroyer/gwt-maven-archetypes/pull/13

I'd like to see an option in the GWT plugin where it runs much like it does with the GWT embedded jetty but with the jetty maven plugin instead.  

Why do I want the jetty plugin instead of the embedded jetty:

1. I get a later version of Jetty

2. I can customize Jetty more easily (authentication, jdbc, etc)

3. I can control the startup of Jetty more easily

4. I can use the same mvn to run and control a production version of Jetty

Let's be clear, there's no reason to use the embedded server, apart for convenience when you have very few needs wrt the servlet environment.

--
Thomas Broyer
/tɔ.ma.bʁwa.je/