On Friday, April 27, 2018 at 7:38:41 PM UTC+3, Thomas Broyer wrote:
- <executions>I must say I don't understand what you're talking about here (i.e. how you'd use them here)
In context of maven-jar-plugin I was simply referring to something like e.g. https://maven.apache.org/plugins/maven-jar-plugin/examples/attached-jar.html
- BOM parent to manage dependencies better. I think it also helps to keep versioning clean.I'm not sure how this is related to the issue, but that can be useful to the users of the libraries yes.
I've seen a hack for large multi-module projects. It introduced another bom-like parent with a dynamic list of child modules to better controll what has to be rebuild. Plus it allowed a "multiartifact" nature of build.
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?
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. 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?
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. 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. But then I stumbled across the "one module.gwt.xml per one Maven module" limitation and started to think about workarounds like uber-jar one. That's where the whole buzz came from.
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.
No comments:
Post a Comment