When I execute in my Maven project the Versions Maven Plugin plugin with the command:
mvn versions:use-latest-versions
The pom.xml is updated with updated dependencies as it is supposed to do.
The problem is that some libraries are updated to version as new as the do not contains some of the packages used in previous versions so the compiler says package not found. Does anybody know how to avoid automatically? I mean, update to the latest version which have the packages and classes I am using in my code.
In my opinion, there is no easy way to determine which version update is "save".
Even if you would check that all classes you compile against still exist, method signatures might have changed. And even if all the method signatures stay the same, the behaviour might have changed, leading to runtime exception etc.
The only reasonable way I know to check a version update is to run a compile and run all test cases. Doing this for all combinations of possible version updates is possible but it will take a lot of time.
The plugin is not going to analyse your code and adjust the dependencies version accordingly.
The objective of the goal use-latest-versions is to upgrade your project to the latest release of your project dependencies, and as a result of you may have compilation and deployment problems.
Once you identified the problems you need to fix all the problems so that your whole project is upgraded to the latest releases of your dependencies.
The problem is that some libraries are updated to version as new as
the do not contains some of the packages used in previous versions so
the compiler says package not found. Does anybody know how to avoid
automatically? I mean, update to the latest version which have the
packages and classes I am using in my code.
Of course, it is not possible.
Updating dependencies is not a game of chance.
If you need to have the last version of a dependency, you should not worry about if this version breaks or doesn't break your code because you need it.
You update a library because you need to update that version. If you don't need to update your dependencies, don't update your dependencies, but if you need to do that, you should make the work to update your code too if necessary.
Related
I have a maven project, called Data_Types. This is a dependency in a different project called ApiUse as such
Data_Types pom.xml
<artifactId>Data_Types</artifactId>
<version>0.1.10.1</version>
<name>DataTypes</name>
ApiUse pom.xml
....
<artifactId>ApiUse</artifactId>
<version>0.0.12.1</version>
...
<dependency>
<groupId>xxx</groupId>
<artifactId>Data_Types</artifactId>
<version>[0,)</version>
</dependency>
when I use the eclipse "Dependency Hierarchy" I get it just fine to the latest version
The problem arises when I import that second project to a third one.
For some reason even thought I am getting the proper latest version of ApiUse, the it is loading an older version of Data_Types instead of the latest one.
If I change the declaration from [0,) to 0.1.10.1 It loads it just fine. It makes no sense to me. Any ideas? Thanks
EDIT
as you can see from the screen shot, on this particular case the old version is not used, because the same dependency is imported from a different class, and maven is using that other version (which happens to be the latest one, but this is not always the case). In any case this old version should not be imported in the first place. My problem is not that this version is omitted. It shouldn't be there in the first place. I have noticed that even though the latest version is loaded, some methods are loaded from the old version. It sounds stupid, I know, but thats what I have noticed
Your 2nd screenshot says the the dependency Data_Types:0.0.1 was omitted for conflict. This means that it is also provided from another dependency.
You can use mvn dependency:tree or your IDE features to find out where it comes from.
Supposing you don't have control over all the dependencies, you can use a <dependencyManagement> section in your 3rd project to "force" a specific version of Data_Types.
Also note that it's often not recommended to use non-fixed versions like [0,) although it's opinion-based.
So I ran into a problem with a project. Where Eclipse would say that java.util.* has an import error The package java.util is accessible from more than one module: <unnamed>, java.base
I dug around a lot it appears that for some reason no one else is really having this issue. Everyone in our office was. They have told me though that a RC version of Eclipse from 2018 I think Sept works, but that is the only one they can get it to work in. I'll try to post the real version later. So I searched a lot and then started playing with the gradle file for includes. And found that the problem only exists if I include the Cassandra-unit-spring testCompile requirement and because of that it only causes a problem on the test case side.
My assumption is that this is somehow a bug with eclipse as gradle itself has no problem with it. As well as intelij. Let me know what else I can provide here to narrow this down further.
Eclipse Build id: 20190917-1200
Eclipse with Lombok Lombok v1.18.10
Gradle 5.6.4
Oracle JDK 11.0.5
tried cassadnra-unit-spring versions 3.5.0.1 - 3.11.x
Also using spring boot 2.1.3.release
Thanks.
I have excluded all (transitive) dependencies of cassandra-unit and re-included them one by one. Eventually, I found out that the library com.boundary:high-scale-lib, i.e., a transitive dependency included by org.apache.cassandra:cassandra-all, is responsible for the import errors.
The library is not Java 9+ ready, since it uses a java.base package name, i.e., java.util. This is not allowed. Unfortunately, you cannot exclude this transtive dependency, since it is required.
I found out that the release version of Eclipse 4.10 does not indicate errors in projects using the library. This is probably a UI bug in newer Eclipse versions, since I can compile and build my application with Gradle without any errors.
You can try this Eclipse version.
Thank you very much for your hard work Sincostan
So with the information you provided, if you put into your build.gradle file the inclusion of the cassandra unit test like this
testImplementation ('org.cassandraunit:cassandra-unit-spring:3.11.2.0') {
exclude module: 'high-scale-lib'
}
This allowed it to work in my case. you would of course need to use your own version etc. This is with Gradle 6.3 at this time.
I have a gradle project where the jar is built and pushed to artifactory. I always want every build/new artifact to be referred as the latest which can be used externally. How do I achieve it through gradle? Can I set up something like 'latest' alias for the artifact, so at any point in time my latest tag would be pointing the latest jar which can be added as dependency?
Eg : abc-1.0-latest.jar should always fetch me the latest build irrespective of how many builds I run internally.
Hm - that might be a quite odd thing to do?
So, you'd like to publish an artifact several times with the same versioning, but with different signature? That is; the artifact abc-1.0 can evolve, but the versioning stays the same? Don't know if that is a good practise.
Anyway, why not look in to the versioning of maven/gradle works? Might be that you can add something like this to always fetch the newest artifact of the abc-library:
Maven:
<dependency>
<artifactId>abc</artifactId>
<groupId>com.whatever</groupId>
<version>[1.0,)</version>
<dependency>
Gradle:
dependencies {
compile 'com.whatever:abc:1.+'
}
In this case, the version 1.1, if available, it will be fetched from artifactory.
Keep in mind, though, that your code will not be easy to rebuild, as the artifact will be fetched using a dynamically dependency approach.
Your use case does sound very strange and not according to best practices.
It looks like what you really need is to use maven snapshot versions.
You can avoid specifying the version at all then Gradle will pick the latest one
dependencies {
compile 'com.google.guava:guava:+'
}
or if you want the latest of 7 release
dependencies {
compile 'com.google.guava:guava:7.+'
}
EDIT: sorry I misunderstood the question.
if you want your project always use the latest code is it not better to create a multi-project in this situation and rely on the project 'build' outcome?
I have a project which depends on a JAR file. The version of this JAR changes often and we are having a hard time trying to ensure we are using the correct one. It is also causing problems when investigating bugs: which version of JAR contains the bug. Some programmers may forget to update corresponding dependencies and include 2 versions of this JAR inside the project, so that an old version may be found by the classloader.
A question is how to account for this issue.
I have a following plan:
1) When an error occurs log the JAR name I am working with to ensure it is a correct version. I plan to use something like
this.getClass().getResource(someResourceINeedFromThatJar).getFile()
2) I can write a test to account for this. But I don't know how I can run a test AFTER the package phase of my Maven build
3) Maybe you can suggest something else for this?
Well, We have same scenario and solved issue by using maven dependencyManagement
It does two things.
Set a default version for dependencies in submodules/child projects
override the version of transitive dependencies
it does override a specified value in a transitive dependency.
The enforcer plugin does not ignore the dependencyManagement. But is unable to recognize the discrepancy since the transitive dependency's version was altered before it went to work.
Here is a nice article : You can go through it:
http://andydennie.com/2012/08/02/maven-enforcer-plugin-vs-dependencymanagement/
And another source: http://maven.apache.org/enforcer/maven-enforcer-plugin/
I'm maintaining an open source java library which has itself some dependencies to third party libraries (e.g. commons-beanutils:commons-beanutils-1.8.3). During development I just added the most recent version of such libraries to my pom. Now I did some changes to my library and realized that those versions are no more recent.
I'm now wondering which strategy is best practice with such dependencies.
My feeling says run mvn versions:use-latest-releases test.
I would recommend using mvn versions:display-dependency-updates and updating relevant libraries by hand.
It is not necessary to always use the latest version of the library.
Usually, should update your dependencies if:
you need a feature of the new version (for major and minor releases)
the update resolves a known bug (that affects you)
the update fixes a security problem.
resolves an incompatibility with another dependency
Otherwise, consider staying on your current version.
You might, temporarily consider using version ranges commons-beanutils:commons-beanutils:[1.8.0,1.9.0) to always use the latest bugfix version. Note however, that this results in non-reproducable builds and must be changed before releasing your project.