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 Sat, 31 Dec 2005 00:49:26 GMT
Hi Brett

I finally found some time to try out the new Maven 2 site stuff that you 
have put into the sandbox. There are quite a few hurdles to jump over 
though and I think I fell on the last one. Hope you can help me out. 
Here's what I did:

- Bootstrapped Maven from the 2.0.x branch

- Added to the sandbox pom.xml a build/plugins/plugin/version tag for 
maven-site-plugin and set it to 2.0-SNAPSHOT, to get all the fancy new stuff

- Added a skin/version tag, with the value '1.0-SNAPSHOT' to 
src/site.xml, otherwise it tried to download the release version

- Added snapshot repositories to the sandbox pom

- When I run 'mvn site' in sandbox-trunks I get an error from Maven when 
it is trying to download the classic-skin, see stack trace below

[INFO] snapshot org.apache.maven.skins:maven-classic-skin:1.0-SNAPSHOT: 
checking for updates from apache.snapshots
[WARNING] Unable to get resource from repository snapshots 
[WARNING] Unable to get resource from repository apache.snapshots 
[INFO] The skin does not exist: Unable to download the artifact from any 


from the specified remote repositories:
   central (,
   apache.snapshots (,
   snapshots (

Any ideas?

Brett Porter wrote:
> Hi,
> I've been tracking a lot of the discussion on commons-dev and there are
> lots of points to reply to, so I thought it was appropriate that I do a
> brain dump to get everything up to date. Apologies for length.
> First, it seems clear that Maven 2 is a better choice to use than to do
> significant work on Maven 1.x. A lot of things have been proposed for a
> Maven 1.x plugin for commons that are already possible out of the box in
> Maven 2.
> 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.
> - 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. The repository sync will be available early in the new year
> and is much improved.
> - 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.
> 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.
> 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.
> 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.
> Distributions - this is customisable by a descriptor in Maven 2, so a
> shared commons descriptor might be appropriate here. I actually think
> the defaults can work for what commons distributes now. If individual
> commons components need to use a different descriptor they can always
> override it - no messy hacking on the goals.
> Releases - this is all being captured in the shopping list on the wiki.
> A lot of this is above and beyond what anything does right now so may be
> a little bit more towards the long term, but all seems achievable under
> the Maven 2 framework.
> Converting POMs - while we do have a tool to help, I would never
> recommend doing this blind as there are a lot of simplifications that
> can be made to dependencies and inheritence along the way. The commons
> poms are actually quite simple and should just end up as a set of
> dependencies and basic information with most inherited so I don't see
> this being a big issue.
> I hope that covers everything. Sorry I hadn't done more on this earlier,
> but if folks are interested in contributing to this effort through more
> requirements or even some code, please let me know and we can start some
> discussion on the maven dev list for the parts relevant there.
> Cheers,
> Brett
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Dennis Lundberg

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

View raw message