maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: [PROPOSAL/VOTE] New API for artifacts versioning
Date Mon, 06 Sep 2004 23:13:08 GMT
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
- - 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 <>:

> Hi all,
> As I described on 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message