maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: SNAPSHOT design
Date Wed, 23 Mar 2005 12:46:37 GMT
Maczka Michal wrote:

>Is the symetry between local and remote repositories no longer a desgin
>Isn't it possible to find a solution, which will enable at any moment in
>time to turn any local repository into a remote repository without any extra
To some extent, they are intentionally different, as the act of
deployment is the promotion of a successful build up the ladder to
release, where the local is your own build which is not in any way
shared with anyone else as the work is not committed. If they were meant
to be the same, there'd just be a deploy goal - no install.

As for the actual differences, the reason for not using the same
snapshot-version file was listed in the document - its timestamp is used
to check whether to consult the remote repository again. The other more
important one is to avoid the cost of filling up your disk with
timestamped snapshots on install, which in turn means building tools to
clean them out. I used this technique for a while, and I disliked it
intensely. I'd prefer the same snapshot be overridden.

>This was ofen very useful feature for m1. 
I can't think of any decent use cases - please elaborate. The only time
I used it was to use a fresh repo, and add the old one to my remote list
to pull them across again one by one. But it was more related to
development on maven rather than any normal use.

The additional files are markup - they don't stop it behaving as it
should. If you request a SNAPSHOT, it will fall back to the file.

>If I remeber we had workable
>solution for that for m2.
If you figure it out, let me know.

>Why some magic strings, which are concatenating timestamp and build number
>together are used?
It's convenient to be able to reference it as an entire version string.
It's not magic - I used a delimiter of "-" where you used a delimiter of
"\nbuild: ".

>Would not it be better to directly use a properties file with for example
>the following (and possibly more) fields:
>timestamp: 20040101.100011
>build: 10
>deployer: brett
>profile: qa
This is a version tracker that is meant to remain small. The "many more"
fields you are alluding to probably all relate to auditing which I don't
believe should be incorporated in this file as it will require history.
For now, the username on the server is just as useful as putting it in here.

>Is this solution uniform with another places in maven where pointer files
>are needed 
>(I mean e.g the strategy how the latest released plugin or another artifact
>is going to be discovered)?
it applies equally to all artifacts - plugins, jars, etc.

- Brett

View raw message