commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <>
Subject Re: Commons, Maven, Site, Release
Date Mon, 26 Dec 2005 10:12:09 GMT
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.

> 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.
> See comments interspersed below.  I am still learning maven 2
> (actually, maven 1 too ;-), so apologies if I have some concepts
> wrong.

We learn as long as we live...

> On 12/22/05, Dennis Lundberg <> wrote:
>> Brett Porter wrote:
> <snip/>
>>> There are some gotchas.
>>> - Some plugins may not be available. At this point, I am not aware of
>>> anywhere that this is the case in Commons, but I will do a check over
>>> this shortly and report back.
> We should establish a list, based on basic build and site gen.  See
> use cases below.
>>> - Some services are not yet available. Specifically I am thinking of
>>> Gump and the automated repository sync. I am working with Leo on the
>>> gump stuff, and I think it will be all ready by the time Gump 3 is done.
>>> there is always the ability to generate a reasonable ant build script to
>>> use here.
> I would consider something like the maven 1 Ant plugin a requirement. 
> We need to ship working Ant builds, IMHO.  Nightlies are a different
> issue, but as long as we maintain the ability to generate working
> build.xml with a dist goal that works, the current setup will keep
> working.
>>> - It's a change, and any change is disruptive. I had planned to get
>>> everything working  at least to the level it already does in M1 for some
>>> sandbox components before even bringing it up, so this thread was rather
>>> timely.
> OK...lets go :-)
>>> Now, some specific thoughts on what is needed.
>>> Inheritence - I believe the common parent is a good way to go, and Maven
>>> 2 facilitates this by allowing it to be in the repository, avoiding a
>>> bizarre checkout structure. This should avoid the need for externals
>>> that has been under discussion.
> Why wouldn't we just create a commons archetype to generate a full POM
> for each component containing the right stuff?
>>> I am currently working on site inheritence. The descriptor goes in the
>>> repository, facilitating the same as above. I am adding breadcrumbs,
>>> top/bottom navigation inheritence (to prevent the need for the entities
>>> used previously), skins (css + images in a jar that can be shared among
>>> projects), and documenting/facilitating best practices about separation
>>> of different releases and separating developer information from user
>>> information. If the site layout + CSS is still not good enough, a single
>>> velocity template should be able to be added to the skin as well.
> So something akin to commons-build becomes a (versioned) formal
> dependency?  Sounds good, as long as users can build component sites
> independently from distros and we can make it easy for interested
> parties to play with the l & f (so those who care can be those who do
> ;-).  If you can break out some simple tasks for others to help with,
> pls post here or to the ticket below.

Brett, I was going to have a go at the commons look and feel next. 
Should I try altering the velocity template or should I await the new 
skins feature?

>>> While on the site, most people love the APT format in Maven 2, which is
>>> a definite advantage of using that. Some might want to look into the
>>> i18n aspects as well.
>>> Unfortunately this didn't land during the hackathon as I had hoped, but
>>> I'll get it together very soon.
>>> Plugin versions - Maven 2 always treats plugins as dependencies. It has
>>> discovery for versions and by prefix to reduce the burden during
>>> development, but you can always enforce a particular version (or range
>>> of versions) from the POM, and the release plugin locks it in to make
>>> builds reproducible.
>>> Custom plugin - should be easy to write on of these and tie it into the
>>> Maven 2 lifecycle for annotating JARs with extra information. We will
>>> also accept bug reports and patches as mentioned to the core plugins
>>> where it might make more sense to adopt the same practices in general.
> I am still getting used to the maven 2 lifcycle.  Before starting on a
> plugin, we should see how much can be accomplished directly by
> configuring or patching the maven 2 plugins.  The most common things
> we need to do (actually, I think the list may be exhaustive) are:
> 1) compile and run tests (in some cases selectively)
> 2) generate sites locally, then publish (components separately, main
> site by itself)

I'm working on this. Haven't gotten to the publish step yet.

> 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 

We should also standardize which of these reports we should use as much 
as possible.

> 5) manage versioned javadocs
> 6) our wonderful release process (output is *signed* tarballs, zips
> with "the right stuff" and release jar deployed to
> /dist/java-repository)
> 7) generate working ant build.xml
> We have some special requirements (at least some of us think so :-)
> around jar manifest contents and the JDK version used to compile
> distribution jars (not necessarily the same as the JDK that maven
> itself runs under).
> As I said, I am still grokking the maven 2 setup, so am not sure where
> to start with patching existing plugins or creating new ones.  I can't
> see any but 6) as "special" - so it is probably best to get 1)-5),7)
> covered by standard plugins (patched as necessary).
> Phil
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Dennis Lundberg

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

View raw message