maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tamás Cservenák <>
Subject Re: Further cleanup of Builders (extension of MNG-5575)
Date Thu, 06 Feb 2014 20:37:32 GMT

a bit off topic, but you mention that  "if last reactorProject" type logic
breaks badly in parallel mode.

Any pointers how to fix/replace it?


On Thu, Feb 6, 2014 at 4:05 PM, Jason van Zyl <> wrote:

> 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:
> 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)
> 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
> ---------------------------------------------------------
> 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)

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