The following issue has been updated:
Updater: Felipe Leme (mailto:[EMAIL PROTECTED])
Date: Mon, 6 Sep 2004 1:07 PM
Comment:
Here is the patch I mentioned. Instead of simply defining a property for the timestamp
version, it creates a new API (org.apache.maven.artifact.versioning) responsible for
the task, with an interface (SignaturesManager), 4 basic implementations, a helper and
a Jelly tag.
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 mantain
backward compatibility - the ArtifactDeployer interface has not been changed
3.The SignaturesManager 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 programatic access to this API in Jelly
Scripts (and command line)
I think this solution is very flexible and also backwards compatible, so I will
propose a vote on the devs list for applying this solution. (and if we approve it, I
will write the test cases and better documentation).
Also 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()).
-- Felipe
Changes:
Attachment changed to MPARTIFACT-18
---------------------------------------------------------------------
For a full history of the issue, see:
http://jira.codehaus.org/browse/MPARTIFACT-18?page=history
---------------------------------------------------------------------
View the issue:
http://jira.codehaus.org/browse/MPARTIFACT-18
Here is an overview of the issue:
---------------------------------------------------------------------
Key: MPARTIFACT-18
Summary: Need a property to specify what value should be used for a snapshot
deploy.
Type: Bug
Status: Open
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: maven-artifact-plugin
Assignee: Felipe Leme
Reporter: Jason Chaffee
Created: Tue, 22 Jun 2004 9:02 PM
Updated: Mon, 6 Sep 2004 1:07 PM
Description:
We would like to have the ability to override the value used for snapshots. In some
cases we would like to use a timestamp, while in others we would like to use a build
number. Currently, all snapshots have are create with a timestamp intead of the
current version, I would like to see this become configurable with a property that
defaults to using timestamps.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
