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

Reply via email to