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 <ja...@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) > > > > > > > > > >
