Reputation: 1042
Currently I have approximately 100 projects (micro-services). And a task which possibly related to half of them. While iterating over the projects I found that some of them updated more than year ago.
The problem is: dependencies version resolution. We declared them like this
compile group: 'org.apache.xmlgraphics', name: 'batik-ext', version: "1.+"
So the actual version is not strictly fixed and can evolve over time. So some of my projects faced the broken API with such evolution.
I think it would be better to freeze the versions and be sure that the sources in repository are compilable at any time.
Upvotes: 0
Views: 48
Reputation: 231
Just now I tested what will happen with this code:
compile group: 'org.apache.xmlgraphics', name: 'batik-ext', version: "1.+"
What it does is that, when we are doing a gradle build/refresh dependencies, we are getting the latest version of 1.xx. So if the latest version is 1.12(July 2017), and you added the jar as dependencies for your project when 1.2 was the latest, then if you give above groovy code in build.gradle and build the application, latest i.e 1.12 will get dwonloaded in your .gradle folder.
So if you need to freeze a particular version give it as :
compile group: 'org.apache.xmlgraphics', name: 'batik-ext', version: "1.2"
so that your application will not break.
It is always recommended to keep the static version to run your applications as expected, because versions keeps on changing with some changes in classes in a jar during time.
I have an experience with these jar :
compile group: 'org.jboss.resteasy', name: 'resteasy-multipart-provider', version: '3.0.19.Final' compile group: 'org.jboss.resteasy', name: 'resteasy-multipart-provider', version: '3.0.10.Final'
Both has InputPart interface which has
getBody(GenericType type)
But the package of GenericType is different in 3.0.10 and 3.0.19. This broke my application.
So its better to keep a static version if you need your application without any breaks.
Upvotes: 1