Q: treatment of type=java-source dependencies by net.ltgt.gwt.maven:gwt-maven-plugin

[Thomas Broyer]

Hi all,

I know this is the group for the CodeHaus/MojoHaus plugin, but I'm trying to reach GWT + Maven users so…

The net.ltgt.gwt.maven:gwt-maven-plugin's import-sources and import-test-sources goals, in addition to declaring all source roots as resources, unpack dependencies with type=java-source and add them as resources as well, so that the sources of the dependencies end up being packaged within the gwt-lib.

This is something that can be accomplished using dependency:unpack or dependency:unpack-dependencies and explicitly declaring the <resource> (or using build-helper:add-resource).

I was trying to document which one of type=java-source and classifier=sources you should use, and I realized that type=java-source is only useful in a limited number of cases.

I therefore would like to remove that "feature" from the plugin. What do you think?

Below is the documentation I had written. Note that the "special treatment for reactor dependencies" actually only works because of a bug in Maven 3.0 that has been fixed in 3.1 (and we're already at 3.3); in Maven 3.1+, the dependency "needs to be packaged already at the time it's needed", just like with classifier=sources, so it's not a compelling argument (and I'll soon update the gwt-maven-archetypes to better support Maven 3.1+ with gwt:codeserver and gwt:devmode)

$h3 Sources classifier vs. `java-source` type

When adding a dependency on the sources of a shared library, Maven allows you to reference it in two ways:

using `<type>java-source</type>` or `<classifier>sources</classifier>`.

There's a big difference between those two forms:

 * a `<type>java-source</type>` is not added to the classpath, it needs special processing by a plugin.

   The [`gwt:import-sources`](import-sources-mojo.html) and [`gwt:import-test-sources`](import-test-sources-mojo.html) goals

   will (among other things), automatically unpack those dependencies and add the unpacked files to the project resources

   so they're packaged within a `gwt-lib`.

   Those goals have special treatment for reactor dependencies and will automatically pick sources from a referenced project

   without the need for the `java-source` artifact to have been packaged already.

   You can declare the `<resource>` for the unpacked folder yourself and define includes and excludes patterns

   (by default, the resource is created with an `**/*.java` include pattern).

   You'll want to use a `<scope>provided</scope>` to prevent those dependencies being seen transitively.

 * a `<classifier>sources</classifier>` is handled just like any other JAR dependency,

   so it's put in the classpath and is transitive, and needs no special treatment.

   The dependency however needs to be packaged already at the time it's needed (e.g. [`gwt:compile`](compile-mojo.html)).

**So, when to use which?**

Use `<type>java-source</type>` if you want to further filter which source files will be packaged

(for example, exclude a class for which you provide a super-source),

or to limit the number of dependencies in the classpath.

[Cristiano Costantini]

Hi Thomas,

I'm sorry I've never used the net.ltgt gwt plugin yet, we stick using the codehaus one for our GWT developments;

I've read your question, and personally I don't like that it is needed to use dependency:unpack or dependency:unpack-dependencies or the build-helper:add-resource - but as I have not used it, I may be misunderstanding something.

What I can tell you, is that with Codehaus plugin we do generate the source jar for each module of our project (even the ones for the backed) and in projects that need to compile it using GWT, we do add an explicit dependency on it using the <classifier>.

In terms of maven configuration, our global parent pom is configured like this:

<pluginManagement>

<plugins>

...

<plugin>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-source-plugin</artifactId>

<version>${source.plugin.version}</version>

<executions>

<execution>

<id>attach-sources</id>

<goals>

<goal>jar</goal>

</goals>

</execution>

</executions>

</plugin>

...

</plugins>

</pluginManagement>

The "mvn install" command produces two jars for each module, for example:

mysubmodule-1.0.0-SNAPSHOT.jar

mysubmodule-1.0.0-SNAPSHOT-sources.jar

Then in each project that needs the sources for the GWT compiler, we add both dependencies in this way:

<dependency>

<groupId>mygroup</groupId>

<artifactId>mysubmodule</artifactId>

<version>1.0.0-SNAPSHOT</version>

</dependency>

<dependency>

<groupId>mygroup</groupId>

<artifactId>mysubmodule</artifactId>

<version>1.0.0-SNAPSHOT</version>

<classifier>sources</classifier>

</dependency>

I hope this can be useful in some way, at least for a comparison!

Regards and thank you for your work on both the plugins.

Cristiano

--
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.
For more options, visit https://groups.google.com/d/optout.

[Thomas Broyer]

On Tuesday, July 14, 2015 at 8:01:13 AM UTC+2, Cristiano wrote:

Hi Thomas,

I'm sorry I've never used the net.ltgt gwt plugin yet, we stick using the codehaus one for our GWT developments;

I've read your question, and personally I don't like that it is needed to use dependency:unpack or dependency:unpack-dependencies or the build-helper:add-resource - but as I have not used it, I may be misunderstanding something.

You are.

 

What I can tell you, is that with Codehaus plugin we do generate the source jar for each module of our project (even the ones for the backed) and in projects that need to compile it using GWT, we do add an explicit dependency on it using the <classifier>.

And not only can you continue to do the same with the net.ltgt.gwt.maven:gwt-maven-plugin, I want to make it the preferred way (which it probably already is).

The plugin has another feature (absent from the CodeHaus/MojoHaus plugin) that unpacks type=java-source dependencies like you'd do with dependency:unpack-dependencies. I want to remove that feature.

 

Following comments are unrelated to the current matter:

In terms of maven configuration, our global parent pom is configured like this:

<pluginManagement>

<plugins>

...

<plugin>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-source-plugin</artifactId>

<version>${source.plugin.version}</version>

<executions>

<execution>

<id>attach-sources</id>

<goals>

<goal>jar</goal>

You should probably use jar-no-fork  BTW.

 

</goals>

</execution>

</executions>

</plugin>

...

</plugins>

</pluginManagement>

The "mvn install" command produces two jars for each module, for example:

"mvn install" is an antipattern. One should only ever use "package" or "verify" (and "deploy" of course).

"install" is useful of course, but only as a "deploy" equivalent limited to your machine. If you don't reuse your artifact in another project (outside the reactor), then you have absolutely no reason to use "install", and many reasons to avoid it.

[Cristiano Costantini]

Ok,

so my point was that I like declaring dependencies explicitly, even the ones on the "sources", using an extra maven <dependency> tag with the classifier for sources.

I'm still using codehaus plugin because for the moment it works for us and it works using it in this way, but Codehaus is no more active while you are very active with your net.ltgt.gwt.maven:gwt-maven-plugin, so I want to help you and I will be glad to switch to your soon.

What prevents me now from migrating, is that I need to make significant changes to my poms: in an ideal world I want to switch groupId from org.codehaus.mojo to net.ltgt.gwt.maven and then run mvn install (in the post scriptum I'll explain you why I need the "install" step); the net.ltgt.gwt.maven:gwt-maven-plugin should output some error which tell me how to fix the configuration, maybe a couple of times, then the migration should be finished.

Does it work this way?

With "net.ltgt.gwt.maven:gwt-maven-plugin" I understand that I need to switch the <packaging> of my libraries to "gwt-lib" and my applications to "gwt-app", and I don't like it: 

- my libraries are simply .jar plus sources.jar and don't depends on the maven-gwt-plugin: I use these libraries both in the GWT-emulated-JRE on the browser and on the real JVM on the server and I don't want to use the gwt-maven-plugin on the Jars used on the server (the only compromise, is that I need to put the gwt.xml modules I these projects).

- my applications are simply .war, where the gwt-maven-plugin is used to create the javascript folder of the application, but the applications contains also other plugin which will not like to be packed in a pom of packaging "gwt-app" (Note: I could clean these projects, and split GWT from other technologies, it could be maybe a cleaner approach and then use the "gwt-app" packaging, but it won't work until I perform some heavy refactoring)

My considerations on "net.ltgt.gwt.maven:gwt-maven-plugin" comes only from reading the docs, I have not made any real test because I'm scared of the changes I need to do by reading these docs. 

My previous reply was maybe a little off topic, without understanding fully your question, but my intent was to support you...

So, what can I do for the net.ltgt.gwt.maven:gwt-maven-plugin? ;-)

Regards,

Cristiano

P.S: In fact I use mvn install on the project using the gwt-maven-plugin because it is not the final product of my build, the final product is another war which only extracts the generated GWT Javascript to the final web application. If I don't build with mvn install, it either fails the compilation of the main Web Application, or the Integration Tests that runs by resolving the dependency on the War installed on the local maven repo.

P.P.S. For reference, we use another maven plugin which require us to change the packaging (=> http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html#using-the-plugin) but it also support to be used without changing the packaging (=> http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html#adding-osgi-metadata-to-existing-projects-without-changing-the-packaging-type) 

[Thomas Broyer]

On Thursday, July 16, 2015 at 8:54:46 AM UTC+2, Cristiano wrote:

Ok,

so my point was that I like declaring dependencies explicitly, even the ones on the "sources", using an extra maven <dependency> tag with the classifier for sources.

+1

I don't intend to change that.

I never liked CodeHaus/MojoHaus' compileSourcesArtifacts <https://gwt-maven-plugin.github.io/gwt-maven-plugin/compile-mojo.html#compileSourcesArtifacts>

 

I'm still using codehaus plugin because for the moment it works for us and it works using it in this way, but Codehaus is no more active while you are very active with your net.ltgt.gwt.maven:gwt-maven-plugin, so I want to help you and I will be glad to switch to your soon.

What prevents me now from migrating, is that I need to make significant changes to my poms: in an ideal world I want to switch groupId from org.codehaus.mojo to net.ltgt.gwt.maven and then run mvn install (in the post scriptum I'll explain you why I need the "install" step); the net.ltgt.gwt.maven:gwt-maven-plugin should output some error which tell me how to fix the configuration, maybe a couple of times, then the migration should be finished.

Does it work this way?

With "net.ltgt.gwt.maven:gwt-maven-plugin" I understand that I need to switch the <packaging> of my libraries to "gwt-lib" and my applications to "gwt-app", and I don't like it: 

No, you don't *have* to use the new packagings.

A packaging in Maven is merely a way to bundle "conventions" (at phase X, execute goals Y and Z; such as: compile:compile at compile phase, resources:resources at process-resources phase, jar:jar at package phase, etc. for the "jar" packaging — it's more complicated than that, and absolutely not documented –but what in Maven is documented?– but I think that's an acceptable simplification). In theory you can do the same with the "pom" packaging and explicitly configuring all plugins; in theory only though, because many plugins and tools have expectations about packagings.

You can continue to use the "war" packaging and just execute the gwt:compile goal at the prepare-package phase.

gwt:devmode and gwt:codeserver would also work, but you'd have to explicitly list the GWT projects as they couldn't use discovery based on the gwt-app packaging.

- my libraries are simply .jar plus sources.jar and don't depends on the maven-gwt-plugin: I use these libraries both in the GWT-emulated-JRE on the browser and on the real JVM on the server and I don't want to use the gwt-maven-plugin on the Jars used on the server (the only compromise, is that I need to put the gwt.xml modules I these projects).

Those are "shared libs", not "client libs", so you shouldn't use a gwt-lib packaging.

See https://tbroyer.github.io/gwt-maven-plugin/ for the different types of projects. See https://tbroyer.github.io/gwt-maven-plugin/artifact-handlers.html for definitions of the new packagings in terms of produced artifacts.

 

- my applications are simply .war, where the gwt-maven-plugin is used to create the javascript folder of the application, but the applications contains also other plugin which will not like to be packed in a pom of packaging "gwt-app" (Note: I could clean these projects, and split GWT from other technologies, it could be maybe a cleaner approach and then use the "gwt-app" packaging, but it won't work until I perform some heavy refactoring)

I strongly believe you should split GWT into a separate gwt-app module, but you're not forced to do it. You could just replace org.codehaus.mojo:gwt-maven-plugin:compile with net.ltgt.gwt.maven:gwt-maven-plugin:compile and keep your WAR the way it is.

 

My considerations on "net.ltgt.gwt.maven:gwt-maven-plugin" comes only from reading the docs, I have not made any real test because I'm scared of the changes I need to do by reading these docs.

That means either you read them too quickly, or (more probably I'm worried) I wasn't good at writing them… I think maybe I'm assuming/expecting too much knowledge of Maven from readers than most actually have.

 

My previous reply was maybe a little off topic, without understanding fully your question, but my intent was to support you...

So, what can I do for the net.ltgt.gwt.maven:gwt-maven-plugin? ;-)

Start using it ;-)

https://tbroyer.github.io/gwt-maven-plugin/migrating.html

Then feel free to suggest improvements to the documentation.

BTW, regarding the original topic of this thread, I went ahead and removed the feature.