On 7-Aug-08, at 9:07 AM, John Casey wrote:
I think that to be clear moving forward, the information (and, I suppose, background) should probably focus on creating a formal, *written* spec for every major piece - separate ones for lifecycle management, project building, artifact resolution, etc...*not* describing what we're currently in the process of changing.
That is absolutely necessary. The problems we are having right now in 2.0.x are a direct result of not saying we need up front. Code shifts back and forth organically addressing point issues which breaks many other things. There's nothing more I would like then to be able to point someone at a document that describes how a POM is resolved, and how a build is executed.
To a certain extent, I'm guilty of doing this backward with the build planning. I did document the new system as I implemented it on a branch, and we all talked about it (at least, as much as I could get people to) before I merged it to the trunk. However, having a document that describes the rough design of the system - not the specific implementation details - would be good to contribute to the overall architecture documentation. I can convert the documentation I do have to any format we settle on for this.
Ultimately I think the wiki is best, I just hate editing on a web form so I've kept my Confluence markup in SVN for all the 2.1 related work
I've asked Oleg do document the architecture in Mercury, and Shane the project builder, and I can do the embedder. Without these even starting a discussion it's impossible to argue for a change in the process of a system when you can't see what the plan for it is. And many of these things just happened with too few people. Mercury is markedly different in that it's been myself, Greg, Jan, Oleg, and Jesse. And Oleg and I have been looking at this for over a year now. The project builder myself, and Shane but that's going to be more evident and the code base is going to be drastically smaller.
We can call it whatever version. At this point I don't think it much matters.
Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven jason at sonatype dot com ---------------------------------------------------------- We all have problems. How we deal with them is a measure of our worth. -- Unknown --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
