On 12/26/05, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > Phil Steitz wrote: > > Let's start experimenting with a maven2 build infrastructure going > > after the various requirements posted here and on the wiki. Unless > > someone has a better idea, I think it could be best to just branch > > commons-build to create a home for the new stuff and associated > > documentation. > > A branch will work nicely for the build stuff, but I think the > documentation could be done on the wiki to start with. In that I assume > you mean documenting the process and not the individual components. > Yes, I mean the stuff that is now linked under "building components" and "releasing components" on the commons site. I am OK starting this on wiki pages, but would want to see these pages eventually replaced with new - hopefully simpler ;-) - content.
> > We can also branch some "volunteer" components to test > > the new build infrastructure. I will do that for [math] and [id] if > > there are no objections from the other committers on these components. > > A branch for each "volunteer" components seems like a good idea. I have > started working on [logging] locally. I'll put up a page on the wiki > with my experiences so far. Then we can accumulate problems and > (hopefully) solutions there. > > > A script to do the svn copies into the new structure would be nice to > > have if someone has one. I am also assuming that svn will have not > > problem merging into the new structure when we have things working. > > Are you referring to the preferred maven directory structure? My > experiences thus far indicates that we need to change the structure of > our components for maven to work correctly. I'll put a note on this on > the upcoming wiki page. Yes, that's what I mean. Looks like the directory structure will change and it will be good to have a standard way to handle the branching and merging operations (assuming we decide to do it this way). <snip/> > > 3) create and deploy snapshot jars to internal apache repo > > 4) generate clirr/jdiff/clover/pmd/checkstyle and other code analysis > > reports periodically > > When you say "periodically", do you mean in an automated way? If so, > then this would be a new feature compared to the current commons-build > setup. > > We should also standardize which of these reports we should use as much > as possible. > I am not sure that I agree on the "standardization" part - individual components should be able to choose what they publish and when. What I meant by "periodically" is when an individual component site maintainer decides s/he wants to do it. Some of these (clirr / jdiff) are only really relevant during the runup to a release and it is convenient to be able to generate them and publish them as part of the release preparation process. Some may want to link archived copies of these reports on the component site. Other code and scm analysis reports make sense for some components, some of the time, but not all components all of the time. The point is that we need flexibility and an easy site publication process that does not require lots of local configuration pain. I have never been a fan of the automated nightly site update idea, mostly because of oversight concerns. Phil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
