Hi Felipe, I haven't had a chance to read this yet, but I'll take a look later. I'm happy to open up discussion on this, but hesitant for any work to start for a couple of reasons: - we are about to address this in m2, so need a solution consistent across both - http://jira.codehaus.org/browse/MAVEN-1438 - I had meant to file this long ago. We really need to rip out the code from maven-artifact-plugin and use maven-wagon because it was forked from that about a year ago and is much improved.
Note that this would not be part of wagon, as wagon is just repsonsible for taking a version (whether it be 1.0, 1.0-SNAPSHOT, SNAPSHOT, 20040608.201018, or whatever). It would still belong in maven-artifact-plugin (and in the maven-artifact component of m2). One thing I don't see in scanning your email is consideration for snapshots on branches. I think we will end up not having a plain SNAPSHOT version, but instead 1.0-SNAPSHOT, 1.1-SNAPSHOT, 2.0-SNAPSHOT so that you can maintain concurrent versions. Despite all this, by all means I think it's a good idea to discuss the concepts of snapshots and how they work for people. - Brett Quoting Felipe Leme <[EMAIL PROTECTED]>: > Hi all, > > As I described on MPARTIFACT-18 > (http://jira.codehaus.org/browse/MPARTIFACT-18), I'd like to propose a > new API that generates/manages the version signatures of a project. > > Conceptually, this new API is based on the fact that each project can > generate 3 types of version signatures: timestamp, release and snapshot. > Typically, release will be ${pom.currentRelease} and snapshot > MavenConstants.SNAPSHOT_SIGNIFIER (i.e., SNAPSHOT) but timestamp can > have many different approaches, as we'll see below. > > The current model has basically 2 limitations: > > - if a maven invocation generates many artifacts (like a jar and > javadoc.jar for a single project or multiple jars in a multi-project > environment), every artifact will have a different timestamp > - the user doesn't have programmatic access to the timestamp neither can > he/she defines what timestamp to use. That is particularly bad when you > integrate Maven with other continuous integration tools, like AntHill or > CruiseControl (as described in the original bug and in the users list, > some of these tools needs to know the timestamp in order to create a SCM > tag). > > The new API I'm proposing is generic enough to solve these issues and, > mostly important, without breaking backwards compatibility. I have > already implement most of it, except by the test cases and documentation > (which I will gladly create once the proposal gets approved :-) > > So, here is how it works: > > 1.The DefaultArtifactDeployer relies on a SignaturesManager to get the > timestamp signature for a given project (actually, not only the > timestamp, but also the snapshot and release signatures) > 2.The SignaturesManager is obtained by a Helper/factory (this is > important to maintain backward compatibility - the ArtifactDeployer > interface has not been changed) > 3.The SignaturesManager implementation to be used is defined by the > property maven.artifact.versioning.type. This property can have > pre-definied values (right now: default, singleTimestamp, > perProjectTimestamp or userDefinedTimestamp) or be the name of a class > implementing the SignaturesManager interface. The meaning of the > pre-defined values are: > default - same behavior as the current implementation. I.e., each call > has a new timestamp > singleTimestamp - the same timestamp will be used by all calls in any > project > perProjectTimestamp - the same timestamp will be useb by all calls of > the same project, but different projects will have different timestamps > (can be useful in a multi-project invocation) > userDefinedTimestamp - the timestamp must be defined by the property > maven.artifact.versioning.userDefinedTimestamp > > 4.There is also a new goal (artifact:show-signatures) and a new tag > (<artifact:version-signatures>) that allow programmatic access to this > API in Jelly Scripts (and command line) > > > Finally, notice that if this new API get through, we can change the > goals that generate manifests to include both an implementation and > specification ids (in a release, both values would be > SignaturesManager.getReleaseVersion(); both in a snapshot, the > implementation id would be SignaturesManager.getTimestampVersion()). > That is very useful when you don't know exactly which nightly build > originated a XXX-SNAPSHOT.jar that's been used by a project. > > > So, here is my +1 :-) > > > Felipe > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
