My problem is similar like this question:
Storm command fails with NoClassDefFoundError after adding jsoup as provided dependency
But I want to know the latest solution and better way to solve this.
I will post the same description in storm user mailing list:
Hi all,
I am building a topology with a load of libraries, such as spring, geotools, etc. Right now, I extract each jar files and pack it into one jar, (as suggested by many forums), using maven. The problem here, each jar sometime has conflicting files, so I have to merge manually. Another thing, though I pack my libraries in jar, storm loads its libraries first. For example, I use guava 16, and storm uses guava 13. My program won't work because guava 13 is loaded.
Current solution is I change the clojure script to put my jar first in the classpath before other jars. Or, I put my jars in lib/ directory.
Is there any simple and reliable way to include jar in Storm? Sorry if this email is too long. I want to make myself clear.
You can use the maven-shade-plugin instead of the maven-assembly-plugin to build your uber-jar. Then, use the relocation feature to move classes into a different package.
Related
I have multiple projects using gradle. Each one of them generates a separate jar on build. I would like to make multiple fat jars which contains a subset of all the jars? I looked at other answers but they seem really old and hence does not seem to work anymore.
Check out the link here to see how to build an "uberjar." Or at the very least use it as a model for your own uberjar task.
I'm trying to figure out how to make my WARs lighter by putting JasperReports, Apache POI and other heavy libs directly to JBoss AS by using JBoss Modules.
Now, Jasper uses many many libraries to generate PDF or XLS files as you can see here. Our templates are pretty old and we are stuck with old jasper version 3.7.1 which of course uses older versions of libraries such as commons which are already present on JBoss AS 7.1.1 modules.
How can I make one "big" module which will contain all jars used by Jasper and keep other parts of application using newer modules?
Putting all jars into separate directories seems so much work without guaranteed success, can we put everything into one module without creating package alike directories?
We started with JBoss modules recently and wrote a small plugin for Maven that generates module folders with module.xmls based on XML descriptors. The plugin is called smartics-jboss-modules-maven-plugin and you'll find additional information about it at the project's blog.
We just started to work with it, but it already makes the process of synchronization between the POM and the module.xml (plus directory structure) for our projects very easy.
The downside of this approach is that you have to learn an additional XML descriptor and have to configure an additional Maven plugin.
If you want to give it a try, the plugin is licensed under Apache License 2.0.
The creation of JBoss modules for external libraries can be automated through maven as explained in another answer here on SO. The author has posted a GitHub project too. This can lessen the pain in managing lots of transitive dependencies.
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.
I am completely new to Maven and come from an ant world. I am having lots of trouble something that might be really trivial.
I want to have a maven project that is made out of non-code items that I want to ship along my jars. These items are DDL scripts, installer scripts a couple of utility scripts, readmes etc.
I do not want to use "resources" in the corresponding java projects since I do not want them living in the actual product jars. I want them shipped as separate artifacts that just like any other jar.
It is acceptable to bundle them up in a jar or zip, etc.
Is there a way to do this?
Thanks!
Use the build helper plug-in to add additional artifacts to the Maven module.
Check out the answer to the following question
Ok, I found it and it was pretty simple. Just created a project added a simple pom with no plugin pacakging jar and I create the proper dir structure
src/main/resources/...
This builds it into a jar
I'm creating a java command line project, with no GUI. The project uses any number of open source projects : Spring, Logback, Commons CLI etc.
When I started to think about packaging, I imagined it would come out as a zip file, that could be exploded to the jar, with a lib sub directory, and dependent jars in the lib.
adapter.jar
/lib/dependencyA.jar
/lib/dependencyB.jar
etc.
I've been playing with Maven Assembly, but it's still not coming out like the above, and I haven't found any examples that do generate the structure above. Is it possible to do so ?
In addition, having a multi-module structure adds another layer of complexity that I haven't been able to resolve, as the assembly module can't find the core module as a dependency. This is my first Maven project, so am still learning how Maven works. I've been through the Sonatype book, but missed something as even using the Best Practices section couldn't get the missing dependency resolved.
The examples I've seen usually involve merging into an uber executable jar, some of which use the Shade project, some don't. My question is, is doing an uber jar including 3rd party libs like Spring etc a good idea ? Or should I persevere with my original zip / lib subdirectory plan ?
Have your assembly module depend on the modules you want to package and then use the <dependencySets> of <moduleSets> tags to include them in any layout you wish. If you have some other files that do not come from a dependency, you can put them in the deployment module itself.
Please have a good read on the assembly descriptor docs. You can pack, unpack, include/exclude and set permissions for the files in your assembly.
In case you haven't seen the sonatype book on maven, here is the relevant chapter: http://www.sonatype.com/books/mvnref-book/reference/assemblies-sect-best-practices.html
EDIT: escaped the <'s
You just need to be more specific in your assembly descriptor. Use one dependencySet that includes only the main jar and delivers it to the top, and another that excludes only the main jar and delivers to the lib dir.