maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Casey" <casey.joh...@gmail.com>
Subject Re: Maven and the Apache processes...
Date Thu, 12 Oct 2006 15:15:31 GMT
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 <daniel.kulp@iona.com> 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
> daniel.kulp@iona.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message