1. I don't think anyone can complain with compliance issues. One thing I would say is, we could/should be using a plugin to resolve the license file from the url given in the POM, and include it in the appropriate place. Not only would this ensure that the license is properly included in the binary, but also that it's accessible separately, which IMO is a good thing. This doesn't require new core functionality, just a new plugin.
2. I agree completely with the concept of staging a release, voting on it and/or testing it, and then promoting the binary. This is also something that many of us are seeing come out of discussions with large corporate clients, where release engineering is taken *very* seriously. I think we would need a new 'stage' mojo, and maybe a 'promote' one to go along with it...then, if there were a way to say that we're following that process (vs. the original prepare,perform one), we could reuse the prepare mojo. Would it be a good idea to "stage" out to an incremented RC number of some sort, rather than pushing it out as a final release? That way, downloaded tarballs don't get misrepresented. 3. I think we have some code in commons-* somewhere to do pgp signing, but I don't think it's finished yet. If we could get this done, we could easily write a plugin to do this during the release process, I think. -john On 10/12/06, Daniel Kulp <[EMAIL PROTECTED]> wrote:
Jason and I have had some chats about this, but I thought it might be good to bring this up to a wider audience... With more and more Apache projects (specifically incubator projects) using maven, there are a lot more people that are running into "issues" related to the apache requirements that are imposed on the build/release processes. IMO, Maven itself should act as the "ideal model" for how to do those things. Thus, when a question comes up, we can point to maven and say "look how they are doing it." So the first question is: does that make sense? The problem is, Maven doesn't seem to do things "correctly", or at least makes things hard(er) to do correctly. 1) The LICENSE/NOTICE files in the META-INF dir of the jar - currently, none of the maven plugins do this at all. I've seen projects handle this in a couple different ways. Some projects put them in the src/main/resources... dir like other resources, but that kind of hides them. Others put them in the same dir as the pom.xml and add a "." resource dir, but that breaks eclipse:eclipse. Both have the issue of having BUNCHES of copies of the LICENSE and NOTICE files to maintain, which sucks. There are a couple options. One option that I understand is coming in 2.1 is the ability to access stuff from the "parent" directory. Shared resources type things. Thus, a single copy could be used. Honestly, I'd like to see a "Apache-Maven" plugins (and a Incubator subclass plugin) that would automatically add those files automatically when possible. One note: according to http://www.apache.org/legal/src-headers.html, all Apache releases done AFTER November 1, 2006 must have the license/notice files done correctly. Thus, this item really needs to be taken care of REAL SOON NOW. 2) The release process - I honestly think Maven does this "wrong." At least for incubator projects, we need to do the tagging/build/signing/etc.. first, then vote on the resulting binaries. This definitely doesn't seem to be what maven is doing. They seem to vote on the "state of the code in the repository", then do the release steps. I think it would be good if the processes that were used could act as an example, especially for the incubator folks that are learning. My (somewhat wacky idea) might be to add a "release:stage" that would do ALL the release steps, but to a "staging area" (apache home directory or similar, maybe need a "staging" section to the distributionManagement section of the pom) that the project could vote on, then another release goal to copy the staging to the real "release" area if/when the vote passes. 3) Signing/deploying - this is another area that maven doesn't seem to "help" too much. Everyone seems to run deploy/release, then login to the people.apache.org and run a script over the directory to do the signing. It would be nice to have "help" from maven to do that. Actually, the Maven project doesn't seem to do it at all sometimes. The javadoc plugin did get signed, but the new clover one did not. However, the new maven-metadata.xml files got changed with javadoc, but didn't get re-signed so the .asc file does not match and thus verify fails. Kind of hard to "trust" the maven repository when the sigs fail. Anyway, I just wanted to start a discussion. I'd love to point to maven and say "model Apache maven project," but, IMO, there is a bit to go. Enjoy! -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 F:781-902-8001 [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
