Is it best practise to store snapshot versions in Artifactory in maven applications? As snapshot versions should be used only for development purposes.
Asked
Active
Viewed 1,003 times
2 Answers
2
It's not true that SNAPSHOT versions should be used only for development. When SNAPSHOT version is uploaded it's not uploaded as is - it gets transformed into a unique version, something like this: 1-20150904.140213-59. When referencing such dependency you can:
- either use SNAPSHOT word like
1-SNAPSHOT, then you don't really know which exact version is used - or use a resolved version:
1-20150904.140213-59
Using the 1st option is discouraged for any purpose - be it a deployment, or a <dependency> in pom.xml (even for development purposes), because it leads to non-repeatable actions. You run build once - you get a dependency with version 1-20150904.140213-59 downloaded, you run it for the 2nd time you may get another version like 1-20150904.140214-60.
But there's nothing wrong with referencing the full (resolved) version. So you can leverage snapshots the same way you do with release versions. Note though that remote repositories (e.g. Nexus) can be configured to delete old snapshot versions - so you need to take this into consideration.
By the way, snapshots are very convenient for releases.
Stanislav Bashkyrtsev
- 14,470
- 7
- 42
- 45
0
A SNAPSHOT version is meant to be used for development. You can store it in Artifactory, but for using an artifact productively, you should build a release version.
@Stanislav is right that timestamped SNAPSHOTs could technically be used like release versions, and I believe him that this works, but I wouldn't do it because it is not how SNAPSHOTs and releases were meant to be.
J Fabian Meier
- 33,516
- 10
- 64
- 142
-
While I agree that idiomatic usage of the tools is almost always the right approach, in this particular case Maven's take on releases is simply outdated and doesn't suit modern approaches anymore. Good thing in this particular case - non-idiomatic approach is battle-tested :) – Stanislav Bashkyrtsev May 20 '20 at 14:37
-
Use a release for it's purpose is the thing. SNAPSHOT's are by definition not intended for that. You can create a release very easy why misusing SNAPSHOT's? Also usage in other tools like repository managers etc. ...and I don't see any outdated thing there ...but maybe you can explain that in more detail and what you mean by modern approach ? – khmarbaise May 20 '20 at 14:42
-
@khmarbaise by modern I mean "build once, deploy everywhere". Which implies that when testing is finished that _same_ binary that was built at the beginning of the pipeline and got tested at later stages - it then continues to PRD. Re-building for nicer version - that shouldn't be done. You can implement this either by using releases only (_every_ build has a release version), or snapshots only. Both are okay. Snapshots are simply more convenient as they have versions standardized. They also can have retention policies configured which is nice when we have constraints on the disk space. – Stanislav Bashkyrtsev May 20 '20 at 14:51
-
Another thing that I'd like to emphasize once more - in classic Maven definitions there doesn't seem to be any reason to use SNAPSHOTs. Personally the only case that I ever used it - when I had 2 projects being changed simultaneously. I needed to _locally_ install a new version and then use it in another project to build it _locally_. Once-in-a-decade case :) I heard of teams that would create a common lib and share it across multiple projects, and because they changed it frequently they used snapshots. Very questionable practice, but maybe, maybe.. – Stanislav Bashkyrtsev May 20 '20 at 15:03
-
We use SNAPSHOTs until we have reasonably working version that can go to the first official test stage. For that, we build a release version. – J Fabian Meier May 20 '20 at 15:05
-
And then when this "reasonably working version" fails testing - what do you do? You build another release version, right? So this "release" version doesn't really mean anything in regards to PRD deployment. Thus.. why bother with SNAPSHOT versions at all? Just use release versions _all the time_. For that you'll need to create a unique release version on each build (instead of incrementing it in VCS). Thus it's going to be done as part of the Build job. Doesn't this look like our old friend SNAPSHOT versioning? :) – Stanislav Bashkyrtsev May 20 '20 at 15:10
-
The release versions are under stricter control: You may only use other release versions as dependencies and also parent POMs are checked. Furthermore building release versions all the time would mean that you need to increase version numbers in dependencies all the time which is inconvenient. Furthermore, it is more difficult to say what to keep and what to delete (SNAPSHOT versions can be deleted without bothering anybody). – J Fabian Meier May 20 '20 at 15:14
-
Changing dependency version may seem inconvenient, but it's also safe. You and your teammate are guaranteed to build against the same dependency. Now, I don't believe in shared libs and I create them rarely. In my limited experience changing a version was never an issue, but I don't want to fully discard the possibility that snapshots may be useful in this context. Regarding removals - yes, you'll have to create a promotion mechanism (2 different snapshot repos) if you want to leverage retention policies, unfortunately it'd have to be automated with custom plugin/script. – Stanislav Bashkyrtsev May 20 '20 at 15:26
-
In our company you usually use dozens of artifacts from different other teams as dependencies when you build WARs/EARs. – J Fabian Meier May 20 '20 at 15:28
-
In my opinion, It is suggestible to give release versions to other teams so they have a confidence that this is static version of jar/war and is never going to change during their development. Also as mentioned in the comments above, if there are any issues with this release version, the other teams can easily refer to which version has this issue. Thus it makes it easier to track the issue. – commonDeveloper May 21 '20 at 17:03