Maczka Michal wrote:
>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.
tar works well too. This isn't something we want to be encouraging -
every time they make a development build of a SNAPSHOT it would be
pushed out to all their colleagues...
>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 feels even more like magic than my solution. Watch as I make your
files disappear! :)
However, this still doesn't cover the use cases of having the ability to
check the remote repo for updates only on a periodic basis, because
you'll not know whether it is a local or remote artifact.
>This will also remove the issue that old snapshots are currently deleted
>before the attempt to fetch the replacement is made.
I don't know what you mean here. Are you sure you are talking about m2?
>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.
There is only one pom between them, and the snapshot version is
associated with that, so they will need to be resolved together. Since
we aren't properly handling any derived artifacts until alpha-2, it
isn't in the design, but following from Vincent's mail yesterday, I'll
add it to the "not yet tackled" list.
>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.
I'm not sure why this has any special handling. If you are assuming that
everything is already present, then just don't declare
@requiresDependencyResolution on the mojo.
Personally, I think it should so it can build from a clean environment,
and you're going to trust the user to know what they are getting, and
not test, then release after some other builds have been promoted and
not test later.
>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
Read my reply to Vincent's mail.