Phil Steitz wrote: > 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. I've already started in the sandbox. It requires an SVN build of the site plugin at present, but I'll be finishing that up after some time off for Christmas.
Once it works there, we can decide about branching other components, doing it side by side, etc. I think you'll find side by side will work for build migration, and there should be very little need for a "commons-build" other than the parent site and pom. At present, I've put the parent stuff into the trunks-sandbox. I'm not sure if that's desirable or not. > 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 > working. > The plugin exists and is based on the m1 version. You can try it out and see if it meets these needs - I think it might lack in producing a distribution (but is fine for a jar if that was all you referred to). Equally important to me is that this plugin isn't a requirement to do anything (ie, its a requirement to be able to produce a working ant build, but a working ant build shouldn't be a requirement for doing things). I'd like to see Maven doing nightly (perhaps using Continuum). >>> 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? > That might be a good idea if there is boilerplate, but this doesn't cover when things change. An archetype is just for the initial creation. > 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. > This is pretty much taken care of, but every works like a formal dependency (the repository is integral to doing stuff in m2). I think all this is covered on the site proposal I posted. >>> http://docs.codehaus.org/display/MAVEN/Sites+and+Inheritence >>> > 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) > selective running is fine, compilation is not (but I assume that's what you meant) > 2) generate sites locally, then publish (components separately, main > site by itself) > Possible now. The site inheritence uses the repository if the filesystem doesn't contain the parents, and navigation is inherited. > 3) create and deploy snapshot jars to internal apache repo > Possible now. > 4) generate clirr/jdiff/clover/pmd/checkstyle and other code analysis > reports periodically > All of these are possible except clirr right now. PMD needs some work, and there is also cobertura as well as clover if you prefer. Doing this periodicially is just a matter of scheduling, and its possible that we could have Continuum set up for that. > 5) manage versioned javadocs > Possible to some extent. There isn't any special treatment of versioning, but I think its a best practices discussion. > 6) our wonderful release process (output is *signed* tarballs, zips > with "the right stuff" and release jar deployed to > /dist/java-repository) > This is a list unto itself that we have already started investigating. M2 is capable of everything the current build is, I think, but there is more we can do. > 7) generate working ant build.xml > Well, its generates a working one :) It might be able to be improved. > 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). > These aren't really special requirements for commons, but another best practices discussion. I think Maven is mostly capable of this now, but again could be improved. I think it should be part of the release discussion. > 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). > I think even a lot of 6 can be part of Maven's standard, and the rest part of plugins. To start with, I'd recommend trying what is there now (unfortunately the site changes require the latest builds of Maven 2.0.2: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/) and we can work through some feedback. Tasks are in JIRA for the site plugin which you are welcome to work on if they aren't assigned already. The release plugin and others are not nailed down that much yet, so working on the commons wiki page there to get that down to specifics would be helpful. That's all I can think of right now :) Cheers, Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
