commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: Commons, Maven, Site, Release
Date Mon, 26 Dec 2005 16:07:29 GMT
On 12/26/05, Dennis Lundberg <> 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


> > 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message