Re: Discussion: gwt-user.jar-like uber jar for T.Broyer's multi-module project.

On Friday, April 27, 2018 at 9:36:04 PM UTC+2, vitrums wrote:

If your lib does not have one single main gwt.xml entry point but really is more like a gwt-user.jar "set of libraries", then you'd probably better skip the gwt:generate-module and gwt:generate-module-metadata and put all your modules in src/main/resources (and not use src/main/module.gwt.xml).

 

To recap. Are you suggesting to get rid of module.gwt.xml and related to it gwt:generate-module and gwt:generate-module-metadata in the build process, because you don't think using this pattern to be a good practice anymore? So I should simply get back to the roots of GWT, where I had to manually put MyTextBox.gwt.xml in the directory that is root for client folder, but this time under resources (as opposed to src), shouldn't I?

There are two things:

• if you want to produce a JAR that contains several "unrelated" GWT modules (in the sense that you want to tell users "add that JAR/Maven dependency, then choose among those GWT modules which one(s) to inherit"), then you can skip the src/main/module.gwt.xml+gwt:-generate-module, and you should skip gwt:generate-module-metadata as that doesn't fit with the way you want your artifact to be used. And I'm suggesting that you should do all that, rather than splitting into smaller Maven modules just to follow some convention of using src/main/module.gwt.xml+gwt:generate-module, and then repackage everything into a bigger JAR.
  I'm also suggesting, and that would be a third point, that you shouldn't produce such a bigger JAR in the first place; most people use dependency managers (Maven, Gradle, Ivy, etc.) so producing bigger JARs (which used to help setting up projects when you had to download things and put them in a folder in your project and add them to your build scripts, etc. all manually) brings no real benefits these days (for a bit of history: when GWT was born, the world was much different, so you would download the GWT SDK as a ZIP file, compile against gwt-user.jar and then run GWT using both gwt-dev.jar and gwt-user.jar; this organisation didn't age well, and led to circular dependencies between GWT modules making it really hard if not impossible in some cases to modularize it; this modularization work is however finally happening)
• I'm really not sure gwt:generate-module-metadata and the generateInheritsFromDependencies facet of gwt:generate-module is a good thing after all, it doesn't look like many people use it either, and I don't know of any other plugin / build tool that copied it. Sometimes, I even wonder if gwt:generate-module (and src/main/module.gwt.xml then) is a good thing, as it leads to such questioning like yours; but overall I think it is, I maybe just need to make it clearer that it really is optional.

 

The real question is why you're developing my-client-lib and my-client-lib-a separately if your goal is to ship them as a single artifact (there can be use cases of course, but it's the exception rather than the rule).

Because I look at module.gwt.xml in my-client-lib and simply don't fully understand how I can have my little widget-size modules like TextBox.gwt.xml as a part of this module, since it would go against the gwt:generate-module idiom. Therefore I'm left to think, that have to physically slice the project into many little modules... That is a big part of the my overall confusion.

See above.

 

Look at gwt-user.jar. Googlers made it the way that it logically contains dozens of modules. But imagine they were using Maven and this archetype. Did they really have to physically keep them as different modules?

See historical note above. Had they started today, no doubt it would have been different (Google's build system works better with many small libraries)

 

I noticed your note of criticism about how erroneously I use this archetype. Basically you imply that I should not use it to develop library code. But I'm not sure why it would be such a bad idea.

This is not what I said. What I say is you keep saying "archetype" when you're actually talking about the gwt-lib packaging and building GWT libraries.

 

I mean I have to develop it somewhere. This way I have a separate "playground" project dedicated to develop some components that are frequently reused in other projects. It's not a huge scale widget library, but still a set of shared interfaces, classes and resources common to more than one project. And in terminology of sandbox example I have a gwt-app packaged sandbox-client with Entry Point. I add dependencies to lib-packaged client modules like my-client-lib to debug and develop them.

What you have is a gwt-app that you use as a playground/sandbox to help you test gwt-lib⋅s. It happens that the gwt-app was initialized from the archetype, but it could have not been the case and wouldn't have changed anything to your gwt-lib issue. It also happens that your gwt-app is built in the same Maven multi-module project, but again it could have been different, and it wouldn't have changed your gwt-lib issue. This is why I said, and keep saying, the archetype is not part of the equation.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.