in this comment i also mentioned use of 'synthetic' maven poms.  heriein lies 
the scope and garbage collection features, where by semaphore or lack of 
semaphore, almost any single process can  decorate a repo with artifacts and 
precursor artifacts using the synthesized repo for the project or build-session.

by garbage collection, keeping it simple, im saying perhaps 

synthetic-pom/
synthetic-pom/shard1
synthetic-pom/shard2
synthetic-pom/shard2/target/
synthetic-pom/shard2/target/synthetic-sub-pom/shard2-1/
synthetic-pom/shard2/target/synthetic-sub-pom/shard2-1/target

..and so on

creating a temporary or session-specific repo with shard1-1,shard1-2, etc. etc. 

these artifacts, with a small bit of digest cleverness can become somewhat 
permanent cache assets as well.

so for supposition sake, as I won't pretend to be familiar with gwt multi-node 
builds, maven provides out-of-the-box:

descriptors for access protocols and plugins 
descriptors for scm and plugins
descriptors for final publishing 
descriptors for build hooks
descriptors for actual projects
occasionally borrowed ant-tasks
well understood repositories
transitive dep unified namespace
plugins to deploy to test, production, to fire up servlets, etc.

maven would need some extra mojo for:
build reactor traffic cop
spawn rules
descriptors for build mesh/cloud
intermediate-representation plugins and tasks along the lines of javacc and 
antlr examples

having said all this, i looked over the code-review and I liked what has been 
submitted in terms of code clarity for the objectives. At the end of the day I 
am just a casual RFc observer however.

Jim


On Feb 11, 2010, at 2:43 PM, Lex Spoon wrote:

> On Wed, Feb 10, 2010 at 11:25 AM, James Northrup <[email protected]> 
> wrote:
> the usecases being described as a point of deliberation, defining 
> dependancies, repository access, and bundling automation, are well solved 
> items in the maven stable.  how hard can it be to define a multiproject 
> descriptor, assign "channels" of build-stage progression, and have a 
> top-level project build coordinated by one maven instance publish artifacts 
> to sucessive build-channels served elsewhere by daemons which trigger maven 
> sub-builds?
> 
> That's a nice idea.  Has anyone heard of a project using  Maven to support 
> distributed builds?
> 
> The little bit of web searching I did turned up did not look good.  People 
> were saying it would be logical to build that way, but that Maven has a 
> fundamental showstopper: the local repositories are not thread safe.  Perhaps 
> that has changed by now?
> 
> Maven aside, there are other options.  Hudson and Pulse should work well.
> 
> Lex
> 
> 
> -- 
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Reply via email to