And you guys are doing this to make life easier? This seems like a lot of effort. On 12/31/05, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > -- > Dennis Lundberg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
-- http://www.multitask.com.au/people/dion/ "You are going to let the fear of poverty govern your life and your reward will be that you will eat, but you will not live." - George Bernard Shaw --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
