I can remove the implementation as it's all fairly self-contained, but you probably know best which classes like Schedule, Scheduling, ProjectIndex, PhaseRecorder and possibly other classes that were weave specific that we can remove from the lifecycle executor code. If that's done it will help a lot and then I want to try and whittle the Builder interface down to
builder.build( session ) On Feb 6, 2014, at 11:16 AM, Kristian Rosenvold <[email protected]> wrote: > I can fremover weave mode entirely this weekend. It wasnt worth it. > > K > 6. feb. 2014 16:06 skrev "Jason van Zyl" <[email protected]> følgende: > >> 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) >> >> >> >> >> >> >> >> >> >> Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- We know what we are, but know not what we may be. -- Shakespeare
