Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <43B5D596.1060509@mdh.se>
Date: Sat, 31 Dec 2005 01:49:26 +0100
From: Dennis Lundberg <dennis.lundberg@mdh.se>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: Commons, Maven, Site, Release
References: <43A5EB4B.5080702@apache.org>
In-Reply-To: <43A5EB4B.5080702@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
Downloading: 
http://snapshots.maven.codehaus.org/maven2/org/apache/maven/skins/maven-classic-skin/1.0-SNAPSHOT/maven-classic-skin-1.0-SNAPSHOT.jar
[WARNING] Unable to get resource from repository snapshots 
(http://snapshots.maven.codehaus.org/maven2)
Downloading: 
http://cvs.apache.org/maven-snapshot-repository/org/apache/maven/skins/maven-classic-skin/1.0-SNAPSHOT/maven-classic-skin-1.0-SNAPSHOT.jar
[WARNING] Unable to get resource from repository apache.snapshots 
(http://cvs.apache.org/maven-snapshot-repository)
[INFO] 
----------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] 
----------------------------------------------------------------------------
[INFO] The skin does not exist: Unable to download the artifact from any 
repository

   org.apache.maven.skins:maven-classic-skin:jar:1.0-SNAPSHOT

from the specified remote repositories:
   central (http://repo1.maven.org/maven2),
   apache.snapshots (http://cvs.apache.org/maven-snapshot-repository),
   snapshots (http://snapshots.maven.codehaus.org/maven2)


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.
> 
> http://docs.codehaus.org/display/MAVEN/Sites+and+Inheritence
> 
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org