[PROPOSAL/VOTE] New API for artifacts versioning

[Felipe Leme <ma...@felipeal.net>]

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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [PROPOSAL/VOTE] New API for artifacts versioning

[Brett Porter <br...@apache.org>]

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 <ma...@felipeal.net>:

> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org