How to manage snapshot dependencies?

[ddidier]

Hi,
Is there a way to not lock the SNAPHOT dependencies, i.e. keep -SNAPHOT instead of -SNAPHOT-<timestamp>? I know this defeats the whole purpose of the plugin, but how do you cope with the development version of a Java project?
Thanks

[vandmo]

Hi!

Some kind of configuration option to give the behavior that you want seems reasonable.
I don't think defeats the purpose that much. You would still know which dependencies you have and the versions for all the other dependencies would still be there.

It is probably best to implement it in the same way as useMyVersionFor so that you can have different behavior on different artifacts. Probably not a very common use case that you would want to have different behavior but adding a global option first and then add support for different behavior later would make it messy.

I am not really sure how to repeat it locally and add a test case for it.
Do you know of any publicly available project that publishes SNAPSHOT releases?
I will have a look at adding https://www.mojohaus.org/mrm/mrm-maven-plugin/ which is used by https://github.com/apache/maven-dependency-plugin to be able to write a test.

[ddidier]

Sorry for answering so late, I've been on another task this past month. When you say "Probably not a very common use case" I'm wondering if I explained correctly, since to me this is a very common use case (but I may be wrong of course ;-). Let's say I'm developing an application with several Maven JAR projects, e.g. my-application-commons and my-application-api, and my-application-api has a dependency on my-application-commons. During the development lifecycle, I'd like to change both:

1. update my-application-commons
2. mvn clean install my-application-commons
3. update my-application-api
4. mvn clean install my-application-api

This is working locally because install creates a -SNAPSHOT dependency (my-application-commons-0.1.0-SNAPSHOT.jar) and not a timestamped one like my-application-commons-0.1.0-20220112.144849-6.jar.

On my CI, I'd like to do this:

1. push my-application-commons
2. build and deploy my-application-commons which creates a timestamped artifact
3. push my-application-api
4. build my-application-api which is locked on a previous timestamped artifact and so is failing

There is no more uniqueVersion option in the deploy plugin.

[vandmo]

Sorry for being unclear. What I meant was that having timestamped versions for some artifacts and snapshot version for some in the same project is uncommon. Having timestamp versions for all snapshot artifacts is, as you say, pretty common.

Maybe it would make sense to implement something like <ignore><dependency>com.myproject:application-*</dependency></ignore>. That might be useful for some other things as well.
<timestampedSnapshots><dependency>com.myproject:application-*</dependency></timestampedSnapshots> would probably be better for this use case though. Probably relatively simple to implement, but I am not really sure how to test it and I haven't had time to dig deeper into that yet.

[ddidier]

The "same application" dependencies are all declared in the POM as -SNAPSHOT but that's the deployment to the central repository that adds the timestamp. It's no longer possible to disable this behavior, as stated by Major Version Upgrade to version 3.0.0. So the dependencies are then resolved and downloaded as the timestamped ones.

I also think that ignoreDependencies should be useful in some cases, but timestampedSnapshots is more suited for my use case. Thank you for your time.

[vandmo]

allowTimestampedSnapshots is perhaps a better name right? Since sometimes it might actually be 0-SNAPSHOT if you have built the artifacts locally.

[vandmo]

Sorry for late reply.
I am looking into implementing this in a 1.x version.
I will remove the possibility of editing the dependency-lock.json file to add "use-mine". I don't like breaking backwards compatibility, but it is a bad feature and it makes it harder to implement new good features.

[ddidier]

Hi, have you been able to make some progress on this one?

[vandmo]

It was a bit more tricky to implement than I thought initially.
The lock file could contain both 0-SNAPHOT or similar or 0-20220112.144849-6 and it should be able to allow either from either of these. Another problem is related to a feature which I am working on which lets you lock and verify the integrity of the dependencies. The snapshots will probably differ in that regard as well.
I pushed code now that lets you ignore some dependencies completely which would also ignore the checksum of the files.
You should be able to use that for now.
I am working on a 1.0 release but I want some more tests before I release that.
I have released a version 0.0.78f56707b3a1d639c8e769bba1686587e9a89564 that you could try and I am confident that it will be compatible with the 1.0 release, but I am not making any promise about that.

[vandmo]

I have been thinking a bit more now and it would probably be better to do something like:

<dependencySet>
  <ignoreVersion>true</ignoreVersion>
  <ignoreIntegrity>true</ignoreIntegrity>
  <includes>
    <include>com.mycompany.something</include>
    ...
  </includes>
</dependencySet>

That way you could configure it to only ignore the version and possibly the integrity if applicable.
It would also be possible to add something like <allowTimestampedSnapshots> or similar which would be even more specific than ignoring the version completely.

[ddidier]

I wasn't aware that the plugin was checking integrity too ;-) I'm using it only to notice dependencies change. So your last proposal fits me quite well too.

[vandmo]

It isn't checking integrity yet, but it is a feature that I am working on that it will be possible to enable :)
Perhaps even enabled by default in 1.0 release.

[vandmo]

Fixed in master branch.