I have two projects that I compile and run together. These projects use different versions of certain jars. so I may have foo.1.15.jar and foo.1.16.jar both in my maven repo. The pom files correctly specify which project should use which jar, and I can run mvn verify to run all my integration tests without issue from the command line.
However, when I try to run a junit test from within eclipse I often run into errors with the wrong version of the jar being used. I believe that eclipse is always using the newest version of a jar that it finds within the maven repo, so if it sees foo.1.15 and foo.1.16 it will use the 16 version. The problem is that I want the 15 version, the tests fail if they run with the 16 version because it's not backwards compatible.
How do I make eclipse recognize that it needs to use an older version? In particular is there a way that I can make the junit tests recognize my pom file and utilize the correct jar versions specified within the pom?
I'm using m2eclipse if that is relevant.
edit: it looks like the problem is not an insistence on using the newest jar each time.
The problem is that my project A uses my project B. A uses foo.16 and B uses foo.15. the junit tests for A tries to use foo.16 even when it's running classes in B that are dependent on 15. However, I can't really change the dependencies, A needs 16 and B needs 15. Can I make eclipse understand this?
Your assumption about Eclipse always using the latest version of a Maven artifact is not correct.
However, Eclipse only supports one classpath per project and cannot distinguish the Maven dependency scopes, so test scope dependencies are also on the Eclipse compile and runtime classpath. It's hard to tell if this is really related to your problem.
You can open the POM editor and look at the Dependency Hierarchy tab to find out the (transitive) dependency path and the version used for each artifact. This may given you a clue for fixing your setup.
Related
I'm working on upgrading a legacy Java project to be compatible with jboss wildfly. As part of that process, I'm replacing our old system of managing dependencies (manually scanning for jars in a folder) with an automated system.
My first thought was to use maven, which worked well initially. The maven plugin for eclipse was able to scan my project and create a pom with most of the required dependencies. That works fine for compiling and running with eclipse, but production deployment uses an ant build script. I looked into maven-ant-resolver ( https://maven.apache.org/resolver-ant-tasks/index.html ) but as far as I can tell that project doesn't have a way to add dependencies to the classpath, the best it can do is bundle them into a jar.
The other option I looked at was Ivy. It seems better suited to integration with ant. Unfortunately, the tooling for ivy seems primitive compared to maven. From what I can tell, there is no option to generate the dependency file (ivy.xml) from an existing project. With the number of dependencies I'm dealing with, especially from jboss, creating the dependency xml from scratch is not a realistic option.
What are my options for solving this problem? Is there a way to do what I want with maven or ivy that I'm not seeing? Is there another dependency management tool out there that offers all the features I need?
The maven-assembly-pluginis what i can recommend for likely usecases. Not sure if it suits you though.
In a nutshell:
You can pack folders, jars, resources, dependencies, whatever into a jar for production deployment. This jar is packaged with the, from maven-assembly-plugin internally used and thus not needed to be referenced explicitly, maven-archiver-plugin which also stores a MANIFEST.MF with the classpath in it (not by default but with few codes of tweaking).
Useful to know though: Maven allows you to quite easily create own Plugins that completely do what you want. If its just a file with the stored classpath, this could be a clean solution.
We have a multiple modules in our Java project and each module publishes SNAPSHOT jar files to Nexus repository. All the sub-modules are directly dependent on the SNAPSHOT jar files.
During development, we want to depend on the Eclipse project rather than SNAPSHOT jars. So we introduced a flag which switches between the dependencies as shown below.
if(System.properties.'setupProject'){
compile project(':Core')
compile project(':Module1')
compile project(':Module2')
}else{
compile 'com.test:core:0.1-SNAPSHOT'
compile 'com.test:module1:0.1-SNAPSHOT'
compile 'com.test:module2:0.1-SNAPSHOT'
}
Executing the following command generates the .classpath file as expected.
gradle eclipse -DsetupProject=true
Is there a better way to do this? Can we use Gradle configurations to achieve the same?
I could not find good examples for the same.
At the moment this is the way to go. You might tweak this even more and instead of using a System property to mark a project as available you can check if the project folder is available (project is checked out)
cheers,
René
Below is my project structure.
-project
-sources
-my.package
-MyClass.java
-test
-my.package
-MyClassTest.java
I want to use JDK version less than 1.5 for my source.
Where as my junit test classes needs latest JDK.
Is there any possibility to use two different JDKs for same project.
Current solution: I can configure latest JDK for the project and can compile using different targets one for source and one for test. javac -target.
Is that correct way to do? or Please suggest any correct solution.
Thanks in advance.
In an Ant build, you can freely specify different JDK and compiler settings for different source folders.
But for Eclipse compilation, I think you will be restricted to using one JDK and compiler settings per-project. I don't think you can specify separate compiler per folder in an Eclipse project.
Options:
Treat these folders as separate Eclipse projects. Or,
Implement Ant build for both folders, but Eclipse build only for one of them. For
example, your junit classes would be built by Ant only.
I have inherited a big project with several subprojects.
all of them use several jar files, all of them located under each project's lib directory. I want to take all the projects and migrate them to maven, but dependencies are a problem (too many of them), some of them are commonly used libraries (apache projects, xerces, jms, etc) and others are not.
is there a way to autogenerate maven dependencies for those jars that can be found on public maven repositories. for example, see that my project use the spice-jndikit-1.2.jar file and automatically get the appropiate depedency with group, artifact and (if possible) version?
thank you
I wrote a groovy script to generate a starting set of Apache ivy files.
https://github.com/myspotontheweb/ant2ivy
In my case, I wanted to "Maven-ize" my ANT builds without switching completely away from ANT.
It is feasible to extend this code to generate a Maven POM, if people were interested in this feature.
You can convert a project to Maven using the m2e plugin, but this erases your jar references, and should not be used.
I doubt that such a thing exists since typical jars (unless themselves built with Maven) don't have the necessary information to correlate the groupId, artifactId and version back to a repository to get the proper path.
You might be able to write something that parses the file name for the name and version, but you still have the package-based path to figure out.
If you're building using Ant, you might also consider using Apache Ivy, and its file-system based resolution (very fast and easy to configure), to get you started, and slowly role over to the Maven repos for the artifacts, this way you're not spending a lot of time up-front finding Maven dependencies.
I've seen that there are quite a few questions regarding this problem, but unfortunately none have solved it for me. Here is a screencap of what's going on:
It is dependent on the android-support-v4 jar file which as you can see is added to my build path. It the exact jar file from the maven library directory's libs folder. I've tried the following:
Restarting Eclipse
Cleaning the project
Right-clicking the project and updating dependencies
Updating project configuration Disabling and re-enabling workspace resolution
Nothing has helped. Is there any other tricks to getting this resolved? All of the answer's I've seen suggest doing these things that I have already tried.
Thanks a lot!
Actual root cause:
The OP JMRboosties reports in this instance having to desactivate Proguard (the tool which shrinks, optimizes, and obfuscates your code by removing unused code and renaming classes, fields, and methods with semantically obscure names)
disabling proguard on the line where the error occurred (the <plugin> item) in pom.xml solved the problem
(See "How to use ProGuard with android-maven-plugin ").
Certain side-effects can result from using Proguard: For example, the Proguard page does mention:
The default proguard.cfg file tries to cover general cases, but you might encounter exceptions such as ClassNotFoundException, which happens when ProGuard strips away an entire class that your application calls.
Original answer:
As mentioned in this GitHub post:
you need to use maven Android SDK Deployer to install it:
I'm going to deploy my own android artifacts to my personal repository to avoid having this problem again.
If you're not explicitly using Maven you can just import it as a regular Android project into eclipse and it'll pick up the .jar from the libs/ directory.
(Note your android-support-v4.jar isn't in libs in your project)
declare it in your pom.xml.
You have to install both Android 1.6 and the compat lib using the maven SDK deployer for now.
cd to platforms/platform-4/ and extras/compatibility-v4/ in the deployer and run mvn install in each.
Hopefully the compat lib makes it into maven central soon so I can avoid this step.
Again, the project is set up to be used as a normal Android project in eclipse too completely separate from maven.
File, New, Project, Android, use existing sources, select library/ folder.
Assuming you're using m2e-android behind the scenes, the reason you're getting compile problems is that the m2e-android plug-in strips out all provided scope dependencies from the Eclipse project classpath.
We do this because, due to changes in ADT 16.0.0, any JAR file in the Eclipse classpath will be packaged into distributable APK file.