[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.

[Andreas Horst]

Hi Thomas,

I develop GWT API projects myself and I use and would always go for alternative 2(or 3, see below). I did not use alternative 1 as - strictly speaking - it is against the convention. I just like to have Java and resources separated. I do just what you seem to be doing: I add src/main/java as a resource to the POM in order to have the Java sources for GWT compilation and get an easily built and packaged GWT API/libary.

I actually cannot give a clear vote regarding alternative 2 or 3 since I do not use super sources myself at the moment. Do you have a particular use case for having them in a separate source directory?

By the way: I use the same separation/layout for src/test/*.

2012/11/13 Thomas Broyer <t.br...@gmail.com>

--
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/-/npnUeQyrLXkJ.
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.

[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)

[Thomas Broyer]

On Tuesday, November 13, 2012 2:12:31 PM UTC+1, Andreas Horst wrote:

Hi Thomas,

I develop GWT API projects myself and I use and would always go for alternative 2(or 3, see below). I did not use alternative 1 as - strictly speaking - it is against the convention. I just like to have Java and resources separated. I do just what you seem to be doing: I add src/main/java as a resource to the POM in order to have the Java sources for GWT compilation and get an easily built and packaged GWT API/libary.

I actually cannot give a clear vote regarding alternative 2 or 3 since I do not use super sources myself at the moment. Do you have a particular use case for having them in a separate source directory?

Abraham Lin accurately said that filtering might be an issue if super-sources are put into src/main/resources. I tend to agree.

It's otherwise just a matter of whether you see super-sources as "just resources", or "sources that are not compiled" (or whose *.class files are not packaged in the final WAR)

 

By the way: I use the same separation/layout for src/test/*.

Indeed.

[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

[Andreas Horst]

You are right. I just did not work that much with super sources, so I'll complain about the resulting convention later ;-)

No seriously, I think if you initially avoid any resulting tooling issues like filtering then I'm totally happy with alternative 3 as well.

2012/11/13 Thomas Broyer <t.br...@gmail.com>

--

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/-/JQW-Mr_Kap4J.

[Olivier NOUGUIER]

Option 3:

   The most maven style !

   Note that until last version of GEP *.gwt.xml files had to stay in src/main/java to be found when launching the Application.

Do you think you will use/support wtp and m2e-wtp ?

Thanks. 

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

[Oliver Krylow]

I would love to have :

src/main/java
src/main/resources
src/main/webapp
src/main/gwt
(src/main/super )

The reason I like to dedicate a whole folder to gwt modules is because I think of them as real entities. They are not mere source files and also not just config files. Also in our mobile projects for hybrid apps we tend to have a lot of them. At least one per target and a slew of others with different debug and testing settings, so it is not too outlandish to have a separate folder for modules.
In the same vain one could argue that super-source files being a gwt concept (correct me if I am wrong) would also belong in the gwt folder . That would be fine for me, put them wherever. Maybe even don't have a standard place for super-sources. They are really such a special case...

If this alternative is too weird for people , I vote for 3 :) .

[Thomas Broyer]

On Tuesday, November 13, 2012 7:08:07 PM UTC+1, olivier.nouguier wrote:

Option 3:

   The most maven style !

   Note that until last version of GEP *.gwt.xml files had to stay in src/main/java to be found when launching the Application.

Does it means that restriction is now gone with the latest version? How about *.ui.xml then? (I haven't updated my eclipse installations yet)

[Olivier NOUGUIER]

Me neither  :) 

I'll give a try tonight ... (home work) and tell you then if nobody replies.

(still stuck with my gwt configurator issue)

--

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/-/5ApZ9UDopfUJ.

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.

[Olivier NOUGUIER]

This issue  is not longer true.

So option 3

[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)

[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).

[Olivier NOUGUIER]

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.

[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

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.
 
 

[Adrien Rivard]

On Mon, Jan 28, 2013 at 3:16 PM, Abraham Lin <atomknig...@gmail.com> wrote:

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

What m2e does with include/exclude in the project .classpath file is :

- excluding anything exept *.java from src/main/java (to let eclipse do the java compilation)

- excluding anything from src/main/resources ( to *NOT* let eclipse do the copy, but to let the  maven-resource-plugin do it , mainly for the filtering resources fuctionnality)

In short these excludes  should not be removed or you give up build consistency (especially if you are using filtering).

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.
 
 

--
Adrien Rivard
06 63 08 79 74

[Olivier NOUGUIER]

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.

On Mon, Jan 28, 2013 at 3:16 PM, Abraham Lin <atomknig...@gmail.com> wrote:

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.
 
 

[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.

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

[Rich]

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?

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)

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/

Thanks,

RB

[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

On Tuesday, November 13, 2012 7:51:37 AM UTC-5, Thomas Broyer wrote:

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.

--

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/

[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/

[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

 

--
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.

[Christofer Dutz]

Hi,

I was told to contribute my ideas here ... guess this is the tread that fits best :-)

First of all, I come from an Adobe Flex background and have recently had to switch to GWT. I noticed some things, that I found relatively "unclean" in the default GWT approach.

What would you think about this:

- Introduce a new packaging type of "gwt", which can be used for building GWT artifacts that are re-used in other maven modules.

- Such a "gwt" module has gwt code in "src/main/gwt" and resources (such as CSS, JavaScript, Images, ...) in src/main/resources (Note ... no src/main/java)

- When compiling such a "gwt" artifact the java sources are compiled to "target/classes" the normal way and same applies to the copying of resources from src/main/resources (including fintering)

- When packaging such a "gwt" artifact the content of src/main/gwt as well as that of target/classes is zipped up into one file containing java-sources, xml, compiled classes and resources is created.

- "gwt" modules can have dependencies to jar and gwt modules (but jar artifacts can't use gwt modules).

- In the web artifact the gwt compiler will use the dependencies to jar and gwt modules to compile the GWT application but will not deploy the gwt modules to the output.

Some Benefits would be:

- This way we can reference server code from GWT code, but not the other way arund. 

- This way the compiled application will not contain all the intermediate gwt sources, classes, xmls and other gwt-resources.

- By using the alternate source directory src/main/gwt developers will immediately see that they are working on GWT code.

What do you think?

Chris

[Thomas Broyer]

On Mon, Feb 25, 2013 at 1:19 PM, Christofer Dutz <christo...@gmail.com> wrote:

Hi,

I was told to contribute my ideas here ... guess this is the tread that fits best :-)

First of all, I come from an Adobe Flex background and have recently had to switch to GWT. I noticed some things, that I found relatively "unclean" in the default GWT approach.

What would you think about this:

- Introduce a new packaging type of "gwt", which can be used for building GWT artifacts that are re-used in other maven modules.

- Such a "gwt" module has gwt code in "src/main/gwt" and resources (such as CSS, JavaScript, Images, ...) in src/main/resources (Note ... no src/main/java)

Why? GWT is all about Java, why would you put your *.java anywhere else than src/main/java? particularly as you want to use the maven-compiler-plugin, which defaults to src/main/java.

 

- When compiling such a "gwt" artifact the java sources are compiled to "target/classes" the normal way and same applies to the copying of resources from src/main/resources (including fintering)

- When packaging such a "gwt" artifact the content of src/main/gwt as well as that of target/classes is zipped up into one file containing java-sources, xml, compiled classes and resources is created.

- "gwt" modules can have dependencies to jar and gwt modules (but jar artifacts can't use gwt modules).

- In the web artifact the gwt compiler will use the dependencies to jar and gwt modules to compile the GWT application but will not deploy the gwt modules to the output.

My main question is to determine what constitutes a "GWT application" (vs. a GWT library) and thus where to put the gwt:compile.

My first idea was to go "flex-like" with both a "gwt-library" and "gwt-application" packagings, where the latter produces something that can be used more-or-less as a WAR overlay (either a straight WAR overlay, or using a goal similar to flexmojos:copy-flex-resources). It unfortunately has negative side-effects wrt DevMode (can't use the embedded server, can't debug several GWT apps at a time, etc.)

I'm thus floating the idea of moving the gwt:compile to the WAR, and using scope=gwt (inspired by scope=tomcat) to tell GWT dependencies and prevent packaging them in the WAR. I foresee a problem with resolving dependencies though: we don't want to include the scope=compile and scope=provided in the classpath for the GWT Compiler or DevMode, and going farther we don't want those to be used by Maven either when resolving dependencies (e.g. GWT validation requires Hibernate 4.1, but you might want to use Hibernate 4.3 on the server-side). I haven't experimented with this approach, and can't tell if it's an issue in practice, but I'm almost certain it will be.

Some Benefits would be:

- This way we can reference server code from GWT code, but not the other way arund.

Nothing will prevent the "jar depends on gwt", unless you possibly add the gwt-maven-plugin with a specific goal to the non-client project; but then who will make sure you didn't forget that one too?

 

- This way the compiled application will not contain all the intermediate gwt sources, classes, xmls and other gwt-resources.

This can already be the case if you structure your project with a clear client vs. server separation (see https://github.com/tbroyer/gwt-maven-archetypes for some examples)

 

- By using the alternate source directory src/main/gwt developers will immediately see that they are working on GWT code.

I'm not convinced.

How about the shared libraries too? They're "GWT code" (in the sense they should only use GWT-compatible code), but they're also "pure Java" code.

[James Nelson]

Anything which violates standard maven packaging should be avoided.
I used to use custom structure until I realized it was more pain than it is worth.

You can (and should) stick to the src/main/java and src/main/resources setup,

and only add the src/main/super if you want targetPath super source support.

If you have complex dependency concerns and want to split code up, do it the maven way, 

i.e., separate out into different modules, and only inherit the one(s) you want.

Going the multi-module route, I also do NOT compile sources into my gwt shared libs.

When it comes to designing for gwt compiles versus gwt shared code, I just leave everything as normal maven modules,

and whereever the gwt compiler is running, that is where I add the <classifer>sources</classifier> dependencies.

The final, exported gwt module can bundle everything gwt needs using maven assembly to bundle source and classes together.

So, any server code that shares with gwt only gets lightweight jars of classes, while the gwt compile gets it's blob of sources. :) 

Anything which violates standard java packaging, src/main/java and src/main/resources, just means more work, messier poms, and harder to debug builds.

If you want to demarcate code as gwt only, don't use a funky directory structure, put it in a module of its own and use a naming convention to say "this is gwt".

Your directory structure no longer exists in jar form, but the name does, so use that to say gwt-client-only or something, if that's important to you.

Anyway, this is just tips from my experience with using gwt and maven together in a module-heavy ( > 25 module) project.

"If it ain't broke, don't fix it" ;)

[Christofer Dutz]

Am Montag, 25. Februar 2013 13:44:49 UTC+1 schrieb Thomas Broyer:

Why? GWT is all about Java, why would you put your *.java anywhere else than src/main/java? particularly as you want to use the maven-compiler-plugin, which defaults to src/main/java.

Well you are correct, that the language is acutally Java, but it's actually not 100% (as far as I understood it). Quite some restrictions apply to GWT code (handing of types, handling of exceptions, only parts of the normal java packages that you are allowed to use). That's why I would suggest to mark this by using a src/main/gwt ... it won't prevent your IDE from being able to debug and you can easily configure the Java compiler plugin to use the alternate location. So that shouldn't be a real issue. 

 

My main question is to determine what constitutes a "GWT application" (vs. a GWT library) and thus where to put the gwt:compile.

To me a GWT application is a web-application, therefore the place where the GWT code is automagically converted to HTML+JavaScript is usually the war project, for which the GWT compiler plugin is usually configured to run. I would really like the concept of a "gwt-application-module", but could definitely live with the current solution of assuming "gwt-application-module == war-module" and this definitely wouldn't break the tooling.

Introducing a custom "gwt" packaging also shouldn't be that hard. I am currently the lead-developer of the Flexmojos project and we do things like that all the time (After all Maven doesn't know swc or swf packages per default and it is nicely possible to have swc and jar dependencies in one artifact (usually for code-generation).

I think you can only use custom packaging types if the plugin that defines them is actually active in the current module. So if you have a Jar artifact and don't define the gwt-maven-plugin (or whatever defines the gwt packaging), this should result in errors (Haven't checked this though). But at least it would clearly make a gwt dependency appear as a gwt dependency and make it easy so distinguish that from a normal jar dependency.

 

My first idea was to go "flex-like" with both a "gwt-library" and "gwt-application" packagings, where the latter produces something that can be used more-or-less as a WAR overlay (either a straight WAR overlay, or using a goal similar to flexmojos:copy-flex-resources). It unfortunately has negative side-effects wrt DevMode (can't use the embedded server, can't debug several GWT apps at a time, etc.)

 

Nothing will prevent the "jar depends on gwt", unless you possibly add the gwt-maven-plugin with a specific goal to the non-client project; but then who will make sure you didn't forget that one too?

 

- This way the compiled application will not contain all the intermediate gwt sources, classes, xmls and other gwt-resources.

This can already be the case if you structure your project with a clear client vs. server separation (see https://github.com/tbroyer/gwt-maven-archetypes for some examples)

 

- By using the alternate source directory src/main/gwt developers will immediately see that they are working on GWT code.

I'm not convinced.

How about the shared libraries too? They're "GWT code" (in the sense they should only use GWT-compatible code), but they're also "pure Java" code.

Well I would clearly suggest that you have either a gwt library or a java library. Having some mixed library sound quite dirty to me. Perhaps you have a java library with shared code and you create a gwt counterpart of this by creating a gwt module with a dependency to the jar shared java library. If you simply have shared gwt code, this would go to into an artifact with packaging "gwt" and you could use this in any other gwt-module without any problems.

Chris