The following comment has been added to this issue:
Author: Matthias Kerkhoff
Created: Fri, 25 Jun 2004 4:01 PM
Body:
Hmm. What's the advantage of not parsing the file name? (I tried to explain the
benefits of parsing: reduced complexity of the client's maven.xml, reduced probability
of errors).
>From what I've seen in the source, all execution paths create at some point a File
>object.
Parsing the File name therefore would just be a check, if File.getName() contains
SNAPSHOT_SIGNIFIER. Eventually, the SNAPSHOT_SIGNIFIER has to be replaced with the
timestamp.
That's it (more or less, of course).
Of course, your comment somehow suggests that we're using maven in some unintended
way. Here's how we're working with snapshots:
Between releases (releases are defined as not containing the term 'SNAPSHOT' in the
version part of the name) we are working with snapshots. The intra-module dependencies
are stored as "xyz-SNAPSHOT", so the xyz-SNAPSHOT.type artifact need to be the
somewhere in the repo (locally or remote). Usually, we would not need to "resolve" the
'SNAPSHOT' with timestamped versions in between releases. However, there is a
realistic chance that we have to hand out a build between official releases. If that
happens, such builds should be using resolved SNAPSHOTs (ie. timestamps) in their
dependencies. Otherwise, the software given to others may not be reproduced easily.
Just for that case, it's a good idea to also have have the timestamped versions in the
repo.
So to answer your question: Yes, if a project.xml has 'SNAPSHOT' somewhere in it's
version tag, we treat the artifact always as a snapshot. For the above mentioned
reason it is important for us that the artifact is available unresolved (as
xyz-SNAPSHOT.<type>) and resolved (as xyz-<timestamp>.<type>) in the repo.
Of course we welcome any suggestions how to streamline our development process.
---------------------------------------------------------------------
View this comment:
http://jira.codehaus.org/browse/MPARTIFACT-19?page=comments#action_21044
---------------------------------------------------------------------
View the issue:
http://jira.codehaus.org/browse/MPARTIFACT-19
Here is an overview of the issue:
---------------------------------------------------------------------
Key: MPARTIFACT-19
Summary: determine automatically if artifact is a snapshot or not
Type: Improvement
Status: Unassigned
Priority: Minor
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: maven-artifact-plugin
Versions:
1.0
Assignee:
Reporter: Matthias Kerkhoff
Created: Fri, 25 Jun 2004 3:58 AM
Updated: Fri, 25 Jun 2004 4:01 PM
Environment: maven 1.0rc3
Description:
Currently, the artifact plugin defines a taglibary with
tags to install/deploy "release" artifacts and other tags to install/deploy snapshot
artifacts.
This distinction, although comprehensible from a technical point of view, should be
hidden away from the clients of the artifact plugin.
>From the users point of view there is just an artifact which should be installed or
>deployed, be it a snapshot or not.
To differ between them introduces unnecessary complexity and also adds possibilities
for usage errors (ie, trying to install snapshots, to install-snapshot release
versions and so on).
IMHO, there should be only two tags, one to deploy and one to install an artifact. A
possible implementation just needs to check the filename for SNAPSHOT_SIGNIFIER. If it
is part of the artifacts file name, treat it as a snapshot, otherwise not.
To avoid breaking anything, the proposed tags can be added in addition to the existing
tags. After a transition period the current tags should be removed.
---------------------------------------------------------------------
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]
