commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [all] Sharing maven setup [was Re: HELP!]
Date Sun, 11 Dec 2005 16:58:27 GMT

Thanks!!  +1 for the commons-plugin.  See comments interspersed.  One
thing to keep in mind is to try to keep it as simple as possible.  I
think we got a little too complicated in the site generation stuff and
it has been a pain to maintain.  Other nice-to-haves are ease of
migration to maven 2 and reusability outside of commons (group of
related, but independent projects wanting to share some common

On 12/5/05, Dennis Lundberg <> wrote:
> >> I remain -1 on reverting to extending the commons-build POM
> >
> > I agree that we should not extend the commons-build POM. However we
> > could do with a way to share stuff.

Yes, the trick is how to do this while keeping projects self-contained.

> >
> > I have in my mind that what we need is a commons maven plugin. It would:
> > - create target/commons
> > - download commons-build within target/commons
> > - update the local maven installation
> > - merge the latest mandatory POM settings
> > - merge the latest mandatory POM properties
> > - merge the latest mandatory xdocs
> >
> > Thus, to push a site or release out you do:
> > maven commons
> > then any other command:
> > maven ...
> >
> > This is probably a pipedream though, as I doubt anyone has the time to
> > write this (ie. I don't!)
> Yes, of course! A plugin is the way to go.
> Most people seems to agree that extending commons-build is a bad thing,
> so we need to figure out a way to make each commons component
> self-supporting.
> Imagine this directory structure in the commons component of your choice:
> /
> +- commons-<component>/
>     +- site/
>     |  +- menus/
>     |  |  +- ...
>     |  +- parts/
>     |  |  +- ...
>     |  +- commons-site.jsl
>     |  +- cvsusage.xml
>     |  +- ...
>     +-
>     +- project.xml
>     +- project-parent.xml
> First we make sure that every commons-component extends the *local*
> project-parent.xml, see directory-structure above. This would be a
> one-time job.
> If we then create a plugin that does the following, it might just work:
> - Download commons-build/project-parent.xml via anonymous SVN to
> commons-<component>/project-parent.xml
> - We would probably need to do something similar for,
> I'm not sure how that would work though
> - Download commons-build/site/menus/ , commons-build/site/parts/ et al
> via anonymous SVN to commons-<component>/site/
> This way we don't have to think about merging xml documents and other
> fancy stuff - just download some files from SVN.
> Does this sound at all possible?

Definitiely sounds doable and reasonable to me; with the exception of
the POM inheritance bit.  I am not yet 100% convinced of the need for
project-parent and I am not sure about the consequences of this from a
maven repo standpoint.  I don't know if you can inherit from an
"abstract" POM or even if such a thing exists - i.e., IIUC your
project-parent would have to have a groupID/artifactID and the local
repo (and eventually apache/ibiblio) might get corrupted/confused, as
this could change over time.  The latter actually is the core of the
issue - in order for the releases to be really self-contained, either
we have to tag and version the common stuff with each component
release, or they need to be able to essentially fork it (as they more
or less do now).

I do like the idea of copying in the commons-build pieces at build
time using the scm plugin or somesuch.  That can help us untangle the
current navigation mess, among other things.  To get around the
tagging / versioning problem, I have thought about suggesting in the
past that we check local copies into release branches and tag these as
part of releases.  So, when working in trunk you do something like
what you have described above, but then when cutting a release, you
create an svn release branch that includes the local copies.  These
then go into the release tag and you can later duplicate the release
from the tag.   The plugin could support a branch goal that would
create the release branch with the local stuff in it.

> Should I have go at it? I have not made a plugin before, but there's a
> first time for everything...
Agree with Robert's comments below.  I will chime in as time and
knowledge permits :-)
Have a look at the jdiff and changelog plugins for examples of how to
use the scm stuff.


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

View raw message