Re: Discussion: gwt-user.jar-like uber jar for T.Broyer's multi-module project.
> > 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. > Oh wow. Now I can very well see that indeed, multi-module archetype hasn't been the part of the equation this whole time. In fact the original problem was eventually reduced to a simple question of ideal use case for *gwt:generate-module* and *gwt:generate-module-metadata*, and whether its use would be appropriate for *gwt-lib* modules with deep inheritence structure. Your insight on the problems raised by the upcoming (hopefully) release of GWT3.0 makes me think about many things. I guess a well thought architecture of an app is not a subject of depreciation and it will easily surpass those days with grace. But it's hard to be optimistic about the fate of actual client components. Not the the best time to invest time and efforts into building castles, it may turn out that you built them on a swamp. -- 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+unsubscr...@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.
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 g
Re: Discussion: gwt-user.jar-like uber jar for T.Broyer's multi-module project.
On Friday, April 27, 2018 at 7:38:41 PM UTC+3, Thomas Broyer wrote: > - ** >> > > 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+unsubscr...@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.
Re: Discussion: gwt-user.jar-like uber jar for T.Broyer's multi-module project.
On Friday, April 27, 2018 at 4:34:25 PM UTC+2, vitrums wrote:
>
> Any experienced developer tends to reuse existing components and organize
> his own code to allow reusability in future whenever it is possible.
> Division of labor further encourages a group of developers to physically
> split a big project into modules and work independently on each part. I
> think T.Broyer's multi-module project archetype for Maven introduces a
> great platform enabling these features and making versioning task look
> effortless.
>
> However I personally start to have issues with the last part, when it
> comes to the release. Specifically, should I aggregate the build artifacts
> into one *gwt-user.jar* kind of unit? I know it's a broad topic, and
> there're multiple angles to look at this problem, one of which says "it's
> not Maven way" (though I start to doubt that I applied "Maven way" concept
> in the appropriate contex). Therefore I want to hear your advice regarding
> this matter and avoid reinventing the wheel. If there's a sample project
> already configured to do the similar task with grace, then I guess a link
> to github will be sufficient.
>
First, the archetypes are all about applications, not libraries. The
archetypes will produce one WAR with the full application, that you can
deploy effortlessly to any servlet container.
If you're going to talk about libraries, then let's step away from the
archetypes and concentrate on the gwt-lib packaging from the
net.ltgt.gwt.maven:gwt-maven-plugin (as that's what you're talking about).
> Imagine you're developing *gwt-user*. Inside *com\google\gwt\user* folder
> you'll find *client *direcotry and a bunch of *.gwt.xml* files
> such as *User.gwt.xml, UI.gwt.xml, TextBox.gwt.xml.* The latter contains
> a bunch of deferred binding instructions, e.g.:
>
>
>
>
>
>
>
> *User* inherits *UI *and *UI *inherits *TextBox*. But then we also have a
> subfolder *datepicker *with *DatePicker.gwt.xml* and it's own *client*
> directory.
>
> So my view on this is that you don't wanna ship *datepicker.jar* to your
> clients, but instead combine the components from all related projects and
> modules into one library.
>
>
>
>
> Further in the text I'm gonna present my hack to multi-module archetype
> build configuration based on *maven-shade-plugin*, so let's get into
> details.
>
> There were three strong candidates to do this job: *maven-jar-plugin, *
> *maven-assembly-plugin* and *maven-shade-plugin*. However the latter was
> specifically made for:
> - This plugin provides the capability to package the artifact in an
> *uber-jar*, including its dependencies and to shade - i.e. rename - the
> packages of some of the dependencies.
> - The Shade Plugin has a single goal: *shade:shade *is bound to the *package
> *phase and is used to create a shaded jar.
>
> In multi-module structure of my *sandbox *project I have two *gwt-lib*
> packaged
> modules *my-client-lib* and *my-client-lib-a*. The task is to gather
> their build artifacts inside one jar. My solution was to create
> a subsidiary *module* *sandbox-gwt* (though it could as well be another
> *project*) with the same groupId as *my-client-lib** and to include only
> such artifacts in the uber-jar. Making it this way automates the task of
> naming by exploiting ${project.groupId} and ${project.version} properties.
>
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).
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).
But maybe please consider the future where J2Cl in GWT3 will transpile all
source files from JARs, without any kind of filtering. You'd better have
many small jars then, than a bigger jar containing several libs users won't
necessarily all use.
> But there's a set of techniques mentioned in different sources, which
> might do the task better?! Those include the use of:
> - **
>
Don't use profiles, that's not what they're made
for:
https://www.cloudbees.com/blog/maven-profiles-and-%E2%80%9C-maven-way%E2%80%9D
> - **
>
I must say I don't understand what you're talking about here (i.e. how
you'd use them here)
> - *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.
>
>
> -
Discussion: gwt-user.jar-like uber jar for T.Broyer's multi-module project.
Any experienced developer tends to reuse existing components and organize
his own code to allow reusability in future whenever it is possible.
Division of labor further encourages a group of developers to physically
split a big project into modules and work independently on each part. I
think T.Broyer's multi-module project archetype for Maven introduces a
great platform enabling these features and making versioning task look
effortless.
However I personally start to have issues with the last part, when it comes
to the release. Specifically, should I aggregate the build artifacts into
one *gwt-user.jar* kind of unit? I know it's a broad topic, and there're
multiple angles to look at this problem, one of which says "it's not Maven
way" (though I start to doubt that I applied "Maven way" concept in the
appropriate contex). Therefore I want to hear your advice regarding this
matter and avoid reinventing the wheel. If there's a sample project already
configured to do the similar task with grace, then I guess a link to github
will be sufficient.
Imagine you're developing *gwt-user*. Inside *com\google\gwt\user* folder
you'll find *client *direcotry and a bunch of *.gwt.xml* files such
as *User.gwt.xml, UI.gwt.xml, TextBox.gwt.xml.* The latter contains a bunch
of deferred binding instructions, e.g.:
*User* inherits *UI *and *UI *inherits *TextBox*. But then we also have a
subfolder *datepicker *with *DatePicker.gwt.xml* and it's own *client*
directory.
So my view on this is that you don't wanna ship *datepicker.jar* to your
clients, but instead combine the components from all related projects and
modules into one library.
Further in the text I'm gonna present my hack to multi-module archetype
build configuration based on *maven-shade-plugin*, so let's get into
details.
There were three strong candidates to do this job: *maven-jar-plugin, *
*maven-assembly-plugin* and *maven-shade-plugin*. However the latter was
specifically made for:
- This plugin provides the capability to package the artifact in an
*uber-jar*, including its dependencies and to shade - i.e. rename - the
packages of some of the dependencies.
- The Shade Plugin has a single goal: *shade:shade *is bound to the *package
*phase and is used to create a shaded jar.
In multi-module structure of my *sandbox *project I have two *gwt-lib* packaged
modules *my-client-lib* and *my-client-lib-a*. The task is to gather their
build artifacts inside one jar. My solution was to create a subsidiary
*module* *sandbox-gwt* (though it could as well be another *project*) with
the same groupId as *my-client-lib** and to include only such artifacts in
the uber-jar. Making it this way automates the task of naming by exploiting
${project.groupId} and ${project.version} properties.
*pom.xml* of *sandbox-gwt *module*:*
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
com.example.project
sandbox
0.0.1-SNAPSHOT
net.coolcode.gwt
sandbox-gwt
${project.groupId}
my-client-lib
${project.version}
${project.groupId}
my-client-lib-a
${project.version}
org.apache.maven.plugins
maven-shade-plugin
3.1.1
${project.groupId}
true
package
shade
*artifactSet* - Artifacts to include/exclude from the final artifact.
Artifacts are denoted by composite identifiers of the general form
*groupId:artifactId:type:classifier*.
But there's a set of techniques mentioned in different sources, which might
do the task better?! Those include the use of:
- **
- **
- *BOM* parent to manage dependencies better. I think it also helps to keep
versioning clean.
I also noticed, that *gwt-maven-plugin* can generate some code in <
*actual-module-name>.gwt.xml*, such as adding
In the context of a large uber-jar such as *gwt-user.jar* if it could
establish the crossreferencing between modules based only on Maven
dependencies, that would be interesting. E.g. to put
inside *MyCoolCodeApp.gwt.xml*, if *my-client-lib* depends on
*my-client-lib-a*.
Lastly I'm curious, in a context of development of *gwt-user* project it
seems that due to an unconventional for GWT applications module structure (
*src/main/module.gwt.xml* not *src/main/pa
