maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <ja...@takari.io>
Subject Further cleanup of Builders (extension of MNG-5575)
Date Thu, 06 Feb 2014 15:05:32 GMT
Hi,

I made a first pass at coalescing the logic for a specific way to build (single threaded,
multi threaded, weave) into its own implementation but there is still much cleanup to be done.
This was pure refactoring and there isn't much functional change aside from adding a command
line parameter to specify the id of a specific builder if you have your own implementation.
I'm using this capability for an aggressive mode of parallelization and while that works the
core is still a bit of a mess, and the signature for a Builder still isn't very nice. It should
ultimately become:

builder.build( session );

or if we ultimately make the session immutable (which would be nice because in any parallel
mode it has to be cloned for safety which is expensive)

build.build( session, mutableDataThatCanPotentiallyBeSharedBetweenProjects )

Right now the weave mode code has been conflated into much of the other code and it should
be contained to its implementation. Ideally a builder gets the projects to build and the task
segments to execute (clean install) and the rest is up to the implementation. All scheduling
information, specific metrics, particulars about the order of execution should all be local
to the implementation. Now that there is a clean spot at the end of the build that you can
attach to the ordering of execution that occurs in a Builder won't affect code that takes
advantage of this. Though code using the "if last reactorProject" type logic need to be change
as that breaks badly in parallel mode. The projects to built are already stored in the session,
we can probably store the task segments there as well to try and reduce the signature of a
Builder.

I would like to start the next phase by removing the weave mode code. I don't think it's really
a viable model for execution, and even if it was a cleaner implementation can be made but
I don't think anyone is really using it to be honest. If your projects are modularized properly
you will be rewarded in any parallel mode. I think the weave mode would just encourage poor
structuring and ultimately not much gain because even if you can move a little bit ahead in
the build and do a few segments in a few more projects you're still going to get blocked by
the critical path and if you don't clean that up you're screwed anyway. The second you clean
that up any parallelized mode you will be rewarded and the complexity of the weave mode for
possibly a slight gain is not worth it. 

At any rate there is a lot more cleanup to do but I would like to start by removing the weave
mode. Really this is up to Kristian, but it will help me greatly clean up the rest of the
code.

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.

  -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)










Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message