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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
