I have two libraries as dependencies in my project. Each of those two libraries has bunch of libraries as dependency. However there are two same named libraries with different version, and one of them as I can see in maven pom dependency hierarchy is ommited conflicting with same named one. When I run program program it uses elements of both "parent" libs, but it uses one of conflicting "child" libs whit which it tries to work with "parent" lib which should use other conflicting lib. So is it possible to have both conflicting libs used in project.
Thanks
Not really.
You can use the Maven shade plugin to construct a shaded jar that contains the dependency with a different package hierarchy.
But the usual solution is to try to find a version of the library that works with all of the other stuff (not always possible, I know).
Related
I am trying to add a dependency as jar file and that jar is shipped with all the classes which are needed for it to run.
compile files('lib/org.hl7.fhir.igpublisher.jar')
Along with that, I have few other dependencies which are added as maven dependencies.
compile ("ca.uhn.hapi.fhir:hapi-fhir-base:2.3")
Now I am facing a lot of issues related to class conflicts because same classes have been shipped with different versions.
In an ideal case, how should I solve this problem? I want to say that the local jar should always use its own files and other dependencies should ignore the local jar files.
Note:- I am using IntelliJ idea.
This is a tricky problem. There is only one classpath and multiple versions of the same class mean that only one of that versions is visible and the other ones are hidden.
One should generally avoid to declare dependencies on "fat jars" that contain their own dependencies. If possible, one should use the slim version without the dependencies (often both versions are published). If there is not alternative one can construct such a slim jar yourself by manually splitting up the jar file. It is also possible to control the structure by carefully ordering the dependencies on the classpath, but this is a little brittle.
I have recently come across some libraries which provide their jar files with their dependencies bundled with them (sometimes referred to as an uber jar, fat jar, or shaded jar thanks to Maven's Shade plugin).
The problem is that I have two libraries (A and B) which contain
different versions of the same class file (same.fully.qulaified.class), and one of the libraries doesn't play nicely with the class file version in the other. I know I could play around with a custom classloader to sandbox the classes from A and B, but I'd rather go with a simpler, more standard solution if one exists.
Also, in general I'm surprised that these libraries are released as uber jars at all. It seems like when library providers package their dependencies in this way, this sort of problem is likely to show up.
So I have a couple questions:
1) Is it common and accepted practice for library providers to release uber jars?
2) Are there standard solutions to resolve conflicting transient dependencies (dependencies of dependencies) that show up at runtime when two of your required libraries have different versions of a class?
I have a web app with thousands classes packed in hundred jar's placed in several folders.
I want create in local maven repository a library, containing all classes from those jars.
And I can use this dependensy in all my projects...
Like in a IntelliJ IDEA i create a global library. Select a folder with sets of jars with subfolders and set name "My web-app libs". And then i add this global lib on my project.
I have founded a way for construct group for several libraries, described here. But I have a hundred jar files and stupid make new project for each.
In advance thanks.
Look at maven shade plugin.
This plugin provides the capability to package the artifact in an uber-jar,
You may want to create another project which enlists all your artifacts as dependencies. So when you include it into your project all the needed 100 dependencies will be transitively resolved.
Maven Versions plugin could help you bulk updating the many versions inside this new artifact.
UPDATE
If all your 300+ jars are completely static, i.e. their versions are fixed, you might probably need to repack them with the shade plugin. Otherwise updating a version of a JAR from this huge set could be a trouble... I can't predict the performance, but my guess is that a normal Maven approach is more efficient.
A note on Maven shade plugin: you might need to move your shaded libraries to shaded package. That's what they usually do to avoid library versions conflicts. I.e. if your 300+ libs use spring-2.0 and your current project uses spring-3.1.0, both will be included anyway. So to avoid conflicts, it's recommended to configure this plugin to move spring-2.0 packages under a different package.
UPDATE 2
If your jars are not mavenized, Maven won't be a big help here. You should probably merge your jars manually and check if it works for you: Merging Multiple Jars in to a Single Jar.
I intend to extract several classes and packages from one Java project and place them into another (which will have a distributable jar). That much isn't too difficult, but of course with such a large refactoring there are consequences. Namely there are many classes in the original project that are subclasses of the classes I want to extract. What's the best method for approaching this sort of refactoring?
You can create separate projects and the main project will have dependencies for all these projects. So in your IDE you can navigate through source code easily.
When building your application, each dependency could be built into a jar and the main application will be bundled with all the dependents jars in its classpath.
Let take as example a web app using plugins, and plugins using common classes, utilities and so on stored in a project named common-plugins.
project/webapp: having dependency on plugin1, plugin2 and common-plugin
project/plugin1: having dependency on common-plugins
project/plugin2: having dependency on common-plugins
project/common-plugins: having no dependencies
When building your project, you could build the plugins and the common-plugins into jars, bundled with your web app
project/webapp.war/WEB-INF/lib/plugin1.jar
project/webapp.war/WEB-INF/lib/plugin2.jar
project/webapp.war/WEB-INF/lib/common-plugins.jar
This way in your IDE, I will take eclipse for instance, you will have a workspace having 4 projects with dependencies as described above. At build using maven, ant, ivy, or what you want, you will build the 3 projects that the webapp project depends on, then bundle the whole stuff.
So basically this is what I did:
Create a new project
Copy over the appropriate classes from the old project to a new package in the new project, reconfigure until everything builds
Test that project separately and build it in to a jar
add jar as a dependency
Delete the classes from the original project
Manually change all the imports from the old packages to the new packages
What I was really looking for was some way to automate or streamline step 6 to make sure I didn't break anything, but I'm not sure it exists beyond mass find/replace.
I've got an Android project that has multiple modules. These are all Git submodules, and several of them are packaged with the same jars (android support v4, Guice, Roboguice, etc.). My main project also has these same dependencies, so I've got three copies of these jars, one in my project, and one in each of two submodules.
When I build, it fails at the dex stage, complaining that certain classes have already been added. I can hack around this, by getting rid of the jars from all the modules, except one, then pointing the dependencies to that location, but it just feels so dirty. There's got to be a better way. Any suggestions?
Use a build tool like Maven or Ivy that manages dependencies for you, so you don't have to check JARs into your project.
Are you using Eclipse ADT? If so this problem has been solved with the latest ADT. The old one used to have the problem you are describing but the new one should work.
Check this link out for details:
http://tools.android.com/recent/dealingwithdependenciesinandroidprojects