I agree with most of this, but I just wanted to mention that I think breaking up the dependency chain will be a little tricky for maven when it comes to tests. Maven general practice is that a given module contains its tests and runs them. The problem with gwt-dev and gwt-user is that many of the gwt-user tests can't run unless gwt-dev has been built, but gwt-dev IIRC has some tests that depend on gwt-user. So it may be that you need to make separate gwt-dev-tests/gwt-user-tests subprojects.
Personally, I'd like to break up GWT-user further into lots tiny pieces, like Core, I/O, Emulation, RPC, Widgets, DOM/Media/HTML, etc We can still build an uber gwt-user.jar, but there are lots of projects that don't use everything, and being able to move stuff off of the classpath speeds up the compiler and dev-mode. There are some projects like PlayN for example, that pretty much only use Core. -Ray On Fri, Mar 16, 2012 at 2:41 PM, Thomas Broyer <[email protected]> wrote: > Hi Rajeev [Cc: GWT-Contrib], > > I saw you created a BuildingWithMaven wiki page earlier today, which I > suppose is about mavenizing the GWT build process. > > I thought about it a little these past weeks. > > The major pain point IMO is about dependencies, particularly those > that have been patched: ECJ and Flute come to mind. > > As we're talking about mavenization, I'd also like to see artifacts > reorganized to favor reuse (dependency) over duplication: > - common: classes shared between the compiler, server code and user lib > - requestfactory-shared > - requestfactory-client: depends on requestfactory-shared > - requestfactory-server: depends on requestfactory-shared and common > - requestfactory-apt: depends on requestfactory-shared (and maybe common) > - gwt-extension-api: provides the API for generators and linkers > - gwt-compiler: equivalent to the current "compiler.standalone" task > in gwt-dev, depends on common and gwt-extension-api > - gwt-dev: depends on gwt-compiler, contains the dev-mode, equivalent > to the current gwt-dev feature-wise > - gwt-shared: everything shared by gwt-user and gwt-servlet today > - gwt-user: depends on gwt-extension-api and gwt-shared, equivalent > to the current gwt-user feature-wise, minus the server-side code > - gwt-servlet: depends on gwt-shared and common, equivalent to the > current gwt-servlet feature-wise, minus the request-factory stuff > > The only breaking changes would be that gwt-servlet no longer contains > request-factory stuff. That shouldn't break much people, and is only a > matter of adding requestfactory-server as an additional dependency. > > The gwt-maven-plugin could depend on gwt-compiler only and dynamically > download gwt-dev only if running GWTTestCase or the dev mode (or > depend directly on gwt-dev as it currently does, that's probably > simpler to implement). The split between gwt-compiler and gwt-dev is > not strictly necessary, but as there's already a "compiler.standalone" > task, I suppose some people have a need for it. > > I believe the gwt-user, gwt-servlet and gwt-dev could still be made to > conditionally (using a Maven profile) produce all-in-one JARs as we > know them today, for people not using Maven for their projects. > > What do you think? > > -- > Thomas Broyer > /tɔ.ma.bʁwa.je/ > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
