Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Received-SPF: pass (athena.apache.org: domain of t.cservenak@gmail.com
 designates 209.85.215.45 as permitted sender)
MIME-Version: 1.0
Sender: t.cservenak@gmail.com
In-Reply-To: <64F8CBFC-D834-4A0C-AE96-197F6DCB30FB@takari.io>
References: <64F8CBFC-D834-4A0C-AE96-197F6DCB30FB@takari.io>
From: =?UTF-8?B?VGFtw6FzIENzZXJ2ZW7DoWs=?= <tamas@cservenak.net>
Date: Thu, 6 Feb 2014 21:37:32 +0100
Message-ID: 
 <CAPLpRQJ5kPx=xPbT4a2eiTz6BM+H+H_QLfWkH_pVAHmjixFyLQ@mail.gmail.com>
Subject: Re: Further cleanup of Builders (extension of MNG-5575)
To: Maven Developers List <dev@maven.apache.org>
Content-Type: multipart/alternative; boundary=001a11c36ad4efa2af04f1c2d814

--001a11c36ad4efa2af04f1c2d814
Content-Type: text/plain; charset=UTF-8

Jason,

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?


Thanks,
~t~


On Thu, Feb 6, 2014 at 4:05 PM, Jason van Zyl <jason@takari.io> 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:
>
> 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)
>
>
>
>
>
>
>
>
>
>

--001a11c36ad4efa2af04f1c2d814--