Maven 1.x Artifact Plugin

determine automatically if artifact is a snapshot or not

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.0
  • Fix Version/s: 1.5
  • Labels:
    None
  • Environment:
    maven 1.0rc3
  • Number of attachments :
    0

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.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Brett Porter added a comment -

I'm not sure about this - the whole point is so that we don't need to parse the filename

current practice is to set currentVersion to 1.2.0-SNAPSHOT during development - should this be deployed as a timestamped version, or not?

This needs more thought.

Show
Brett Porter added a comment - I'm not sure about this - the whole point is so that we don't need to parse the filename current practice is to set currentVersion to 1.2.0-SNAPSHOT during development - should this be deployed as a timestamped version, or not? This needs more thought.
Hide
Permalink
Matthias Kerkhoff added a comment -

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.

Show
Matthias Kerkhoff added a comment - 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.
Hide
Permalink
Brett Porter added a comment -

I've checked it out and your usage is correct and will be better supported in a future version.

Show
Brett Porter added a comment - I've checked it out and your usage is correct and will be better supported in a future version.

People

  • Assignee:
    Unassigned
    Reporter:
    Matthias Kerkhoff
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: