I have encountered similar problem as stated in following question: Install 3rd Party Libraries with Transitive Dependencies / Dependency Tree?
I will quote most important part from it below:
I know mvn install:install-file does install a single JAR. But how
to install locally in the repsoitory something like this:
+ Parent.jar
+ ChildA.jar (Requuired by Parent)
+ ChildB.jar (Required by Child A)
To make it more complcated and real life: Parent.jar and ChildA.jar
are legacy/commercial Jars not available in the public maven
Repository but the Child B is a jar that is found in the public
repository (for example like a logging jar).
UPDATE: I do not only want to install them locally (with a system
dependency) but to also "correctly" integregrate them with maven so i
can redistribute this dependency tree to other developers or the
public (and I assume this is important for maven), so that maven knows
and understands the dependecytree (to avoid version conflicts,
unnecessary downloads etc...)
I have similar case jars are legacy and commercial I will deploy them to internal company repository.
Solution is simple which I figured before finding a question, to write pom for every jar and import them using syntax mvn install:install-file -Dfile=<path-to-file> -DpomFile=<path-to-pomfile>. But in my case there is over 200 jars with more than 10.000 class files in total. That's why I was wondering wether there is software which could provide me with easy parse-able and/or process-able output telling which jars depend on which. Otherwise it could take insane amount of time do it manually. Open every jar, decompile every class, find which classes it referenced, are they from other jars (which?) or not.
I think this should be possible to automate since classloaders do something similar. If it need to load a certain class it have to load class that are used by this certain class, so there is a way to know which classes are referenced. And you can tell which classes belongs to which archives.
I'm also aware that I might not be not able to import them because of some circular dependencies between classes from different jars. I'm fine with that if software says - NO if it's not possible. That's actually another reason why I don't want to do it manually and acknowledge after 2 weeks that I just waste my time.
So any idea if such software exists?
Related
I am currently working in a Java project, and we use maven to build the final jar. There are two ways to build the jars as we all know, i.e. one single jar with-dependencies, and a jar without dependencies. In the latter case, we need to add dependent jars to the classpath as well.
In principle both can work, personally I prefer one jar with dependencies, but in the project team members decided to use separate jar without dependencies. So hereby I would like to know which choice is better?
This question has no answer, since it depends on what you need to do.
If you're writing an utility package or component, that could be a dependency of another project, then there's no point in having all the dependencies inside it - it's better to leave dependency resolution to a dependency manager, like Maven.
If you, instead, are writing a full application packaged as a jar, I mean something with a MainClass that can be executed with java -jar myjar, then having the dependencies together will make distribution easier.
Consider that, for instance, if you're writing a webapp, that'll be packaged as a WAR, it normally comes with dependencies.
I've inherited a few maven projects which have added a /dependencies directory to capture Java jar libraries that aren't part of the project war and must be installed by a DevOps into a Tomcat installation.
The libraries in this directory seem to fall into four categories:
"provided" scope libraries,
downstream dependencies of those provided libraries, and
discoverable implementations of api jars
"mystery" libraries, i.e., not available in an external repository, and maybe unsure where they ever came from.
Is there a strategy to get Maven to help manage these dependencies and perhaps fetch them for external install?
There are probably several strategies to choose from.
Number one: leave it as it is. If it works and the build is reproducible (on different environments) that seems one valid solution.
The "mystery" part of the build might not be more of an issue for new people working with it.
I think it is valid to create an own maven module to be delivered to the infrastructure team. This module can contain the jars in the /dependencies folder.
What you would need to do is create a pom.xml and add all dependencies currently in that directory (of course not the transitive ones). The magic ones would need to go in a repository proxy (nexus, artifactory, ...). If you don't have a maven repository yet: you want one! (its easy to setup and it does help a lot!)
I would then use the assembly plugin or some ant task to build the zip do be delivered. So the infrastructure team is able to just unzip / copy the files where they need to be. This step can then even be scripted (so the upload / unzip is done through SSH or something like that).
This is probably only one way to do it. I would assume to resolve the jar's in the /dependencies directory may be a bit of a pain.
The advantage is obviously that you document and simplify the management of those libraries. I would also assume if you update some of them it is easier across branches to merge since there are no binary files around. So it may be worth the effort.
I'm trying to find a command that does the opposite of mvn dependency:tree. I want to find out all the projects that depend on a specific module. As trivial as it may sound, I couldn't find such thing.
The use case is in order to find, in a very large project, if I can delete a module or if there are other modules that use it as their dependency.
Try this:
mvn dependency:tree -Dincludes=module
Where module is the dependency you're interested in. You should get the list of libraries that depend on the module you've specified, either directly or transitively.
Although outdated since the question is from 2014, I was looking for something similar:
matching dependencies (f.e. junit) to a list of projects (f.e. maven-compiler-plugin 3.6.0) in use, which should give a list of dependent dependencies currently in use (f.e. junit 4.12). That should point us (for our own projects) to outdated dependencies (f.e. junit 3.8). This will be used for the undeployment of overgrown services (in this case).
Since I was unable to find an automated version (other than manual nexus/repo-plugins or maven-dependency-greps), I wrote a small java tool: reverseDependencies. Feel free to use if you come across a similar task. Note: it will check against the online Nexus-like repository or cache file that you specify.
This is something that is not part of Maven. But it can be implemented in Maven repositories like Nexus and Bintray. The closest I've found is in Bintray and its Build Integration.
But since my clients are using different Maven repositories I needed something that works for any repository. So I created Pom Dependency Analyzer Web that can keep track of dependents, and dependencies.
I'm working on a project that has a reliance on a significant number of 3rd party jars; these jars contain both proprietary classes and custom/patched versions of existing libraries. I'm trying to figure out how to tie these jars into the maven architecture so as to be CI friendly.
My initial idea was to create an uberjar of all these libraries, and add that one uberjar to the maven repository, however I have not been able to figure out how to take this set of standalone jar files (that are not dependencies) to merge like that. There exists lots of documentation on how to uberjar a project and its dependencies, but not standalone jars.
I feel like i'm missing something basic, or maybe there is a better way. Any recommendations are welcome.
You would be better off to proceed as follows:
Set up a repository manager.
Write a shell script that runs mvn deploy:deploy-file for each of your jars, generating the GAV with a simple algorithm.
treat them like anything else.
To elaborate on Step 2:
G:A:V - my-company-name:name-of-jar:version-based-on-todays-date.
I'm setting up a (java) maven project that depends on a library (Jettison, among others) that is in the Maven repo. Jettison, in turn, depends on stax. I need to run a tool (Jar Jar Links) on stax (to change the namespace). How do I alter the rules for a transitive dependency in a maven project? My transitive dependencies are being included in my target folder using the copy-dependencies goal (I assume this is how things are usually done). I assume that this is the point where the plugin would be run on the transitively-generated artifact.
Extra question: I don't need this at this point but how would I go about altering the source in the transitive dependency? I can get the jar of the source with mvn dependency:sources but, from there, I'm not sure what the right approach is.
Victory!
Seems at least two people are even more clueless about Maven than me so let me explain what I'm doing before I report the fix at the bottom of this post (spoiler alert: it looks to be a bug in JarJar).
Android uses Java but its missing a lot of the java core (specifically, javax classes). The Android DEX compiler (which converts .jars to Android .dex files) won't even allow you to compile things in the java.* or javax.* namespace because it'll (usually) break stuff. However, in some (many) cases, there are routines that you might want to include -- specifically because they are used by existing libraries. The most legendary is StAX, which is why Google posted an example of how to include it here in the Dalvik repo's wiki. The example uses JarJar... with ant. Transitive dependencies are not really an issue when you aren't using a repo so they are not addressed in the wiki.
I was able to get JarJar to run on my source with Maven but without changing the namespaces in the dependencies (and transitive dependencies), that's worthless. Hence my question.
I thought that the copy-dependencies plugin might be useful for... copying the dependencies and running a transforming plugin in the process. Copying dependencies is mentioned as a step in the official "Maven in 5 minutes" doc so it seemed like a good start but maybe the the people who wrote the official docs don't know how to use it :-) . Either way, it it didn't help -- there is no simple way I could see to transform the jars as it copies.
Using the verbose spew from Maven, I was able to see that Jar Jar was in fact processing my jars properly... and then throwing out the result. It would have packaged the converted classes from the transitive dependencies in my artifact with the rest of my code but, instead, it "Excluded" them. Jar Jar parameters are basically undocumented and most of the tags aren't even listed in the docs but all of the examples I could find use a section with wild-cards that tell it what classes to hold onto. At least I thought (think?) that's what the section is for. Instead, it seems to randomly throw out stuff. Basically, the section is busted. For example, I had:
<keep>
<pattern>com.example.**</pattern>
</keep>
...thinking that this would keep classes that began with com.example. Wrong. It keeps whatever the hell it wants. I tried a million things in that spot until one worked:
<keep>
<pattern>*.**</pattern>
</keep>
This only keeps the classes I wanted -- the classes it updated and the originals of the ones that it didnt touch. Note that ** doesn't even work. This is version 1.8 of the JarJar plugin (the version most poms Ive found use).
Back to work.