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 03:14:30 GMT
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.  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 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.

See comments interspersed below.  I am still learning maven 2
(actually, maven 1 too ;-), so apologies if I have some concepts

On 12/22/05, Dennis Lundberg <> wrote:
> Brett Porter wrote:

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

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

> >
> > 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)
3) create and deploy snapshot jars to internal apache repo
4) generate clirr/jdiff/clover/pmd/checkstyle and other code analysis
reports periodically
5) manage versioned javadocs
6) our wonderful release process (output is *signed* tarballs, zips
with "the right stuff" and release jar deployed to
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).


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

View raw message