> -----Original Message-----
> From: Brett Porter [mailto:[email protected]]
> Sent: Wednesday, March 23, 2005 1:47 PM
> To: Maven 2 Developers List
> Subject: Re: SNAPSHOT design
> 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.
I have seen quite often the situtation when one person in the compoany
started to experiment with maven1 and
after some minutes (when internet connection to ibiblio is slow it can ealsy
take 30+ minutes) he has finally populated
his local repository with artifacts which are needed to use maven plugins
and by his project.
Then it was very convient to just share his local repo with other collegues.
But I am not sure if this is that important for snapshot artifcts.
> 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.
I think it will be just enough to have also timestamped files in local repo
and after sucessfully delivering newer artifact
to first switch local pointer form old snapshot to new one and then delete
the old artifact for saving diskspace (this could be optional).
This will also remove the issue that old snapshots are currently deleted
before the attempt to fetch the replacement is made.
At the the moment in the case of the sitution when download or validation is
failing you actually would have a missing dependency and can be left in
This can be also importand when you will want to fetch both primary and
during the same "transaction" and only switch to newer snapshot if all
artifacts were upgraded sucessfully.
I am not sure if this is relevant remark here: prior to the release process
you should have all artifacts and metadata locally and you should not be
required to hit any remote repository. It means for example that if you
would use "convert-snapshots" function of release plugin no transfer from
remote repo should be required as you will fetch duplicates.
> >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.
This I know.
I asked if this is already aligned with for example the strategy for getting
the latest release (not the snapshot)
If I remember when we introduced the idea of pointer files they were also
covering that use case.
In m2 you need it for example to automatically download missing plugins (the
name of the plugin was guessed from the name of the goal).
I don't know if this feature is still preserved but the version was simply