I want to deliver a single .jar file to my clients, but my project is currently built with Maven, and I have several modules that generate a single .jar each.
I know nesting different .jar files is not a great idea, so I am not sure how can I achieve this.
Any ideas?
If you really want to go this direction, there are several ways to do that:
with the Maven Assembly Plugin and maybe the jar-with-dependencies predefined assembly descriptor (that will unpack dependencies)
with the Maven Shade Plugin (similar to the above one but gives more flexibility)
with the Maven One-Jar Plugin (that uses One-JAR and its custom classloader to allow nesting of JARs)
Depending on your exact requirements and constraints, you might prefer one or the other.
First of all, ask yourself if you have a really good reason for packaging your application and all of its dependencies in to a single jar. I haven't found a very many good reason for this at all (with most reasons being related to organizational policy foolishness or just plain ignorance). The way to go is to keep libraries in their own jars and supplying a .zip/.tar.gz containing all of your libraries and your application with either
An executable .jar with the
classpath setup appropriately in
your MANFIEST.MF file
a .bat/.sh
script that invokes java and builds
an appropriate classpath based on
your deps
Conversely, use JNLP (better known as Java Web Start).
If you really want to have maven bundle all of your dependencies and your application under a single jar, what you want to use is the "jar-with-dependencies" predefined assembly. The maven assembly plugin usage page also shows how you might this up as well.
You can try Maven Shade plugin too.
http://maven.apache.org/plugins/maven-shade-plugin/
General instructions on how to use the Shade Plugin can be found on the usage page. Some more specific use cases are described in the examples given below. Last but not least, users occasionally contribute additional examples, tips or errata to the plugin's wiki page.
In case you still have questions regarding the plugin's usage, please feel free to contact the user mailing list. The posts to the mailing list are archived and could already contain the answer to your question as part of an older thread. Hence, it is also worth browsing/searching the mail archive.
If you feel like the plugin is missing a feature or has a defect, you can fill a feature request or bug report in our issue tracker. When creating a new issue, please provide a comprehensive description of your concern. Especially for fixing bugs it is crucial that the developers can reproduce your problem. For this reason, entire debug logs, POMs or most preferably little demo projects attached to the issue are very much appreciated. Of course, patches are welcome, too. Contributors can check out the project from our source repository and will find supplementary information in the guide to helping with Maven.
Actually, nesting .jar files is not possible. A jar can't have other jars in it.
.war and .ear files can contain jars, and that's a good solution if you're delivering a J2EE application.
If your app is just J2SE, however, I recommend looking at the Maven Assembly plugin. As the name implies, it allows you to create a single binary distribution of your build.
Related
I am installing to Maven repository our internal files using mvn install:install command. All Jars installed in such way have version name added automatically as a suffix. Since we have many batch scripts with the Jars names it is very inconvenient for us. How this auto-renaming can be switched off?
You can't. Dependency resolution in Maven works because Maven has conventions and the naming of artifacts is one of them. So you can't turn off the way maven install artifacts (and you actually don't want to).
The common way to handle scripts (bat/sh) is to put them in your source tree (e.g. in src/main/bin) and to create a distribution of your project with the assembly plugin. When building your assembly, you can rename artifacts, filter distribution files, etc. That would be the right place to do such kind of things.
it's tempting to want to remove the version number, but I'd recommend keeping it on if at all possible.
Instead of removing the version numbers, maybe you could use Maven's resource filtering capability to manage your batch scripts? Maven can manage your batch scripts by replacing placeholders such as ${project.version} inside the bat script with the current version number from the pom.xml. That way you can ensure that the batch script is running the correct (expected) version of the code.
You could probably force maven to deploy a jar without a version, but if you do so, you lose some of the main benefits of having Maven manage your build in the first place, imo. For example, just yesterday I was asked to maintain a java project not managed by maven with a bunch of non-versioned jar files inside a lib directory. There's no way to know where any of the jars came from.
It might be a little bit of a headache up front, but if you're using maven, you might as well jump in 100% (again, from my experience).
I am newbie with maven.
Other than its use for managing dependencies, I am finding little use for it.
It was getting so hard to write up a pom.xml, that I generated a ant build.xml from one of maven's tasks (which is a nice handy task...)
I had to tweak the build.xml that was generated by maven. And now all my compiling, testing, etc., is being done with this build.xml..
Is such a combination common? I am thinking of making it permanent in my project.
Other than its use for managing dependencies, I am finding little use for it.
That's because you don't get it :) Dependencies management is only a small part of Maven, Maven has really much more. Quoting Maven: The Definitive Guide:
Maven is a project management tool which encompasses a project object model, a set of standards, a project lifecycle, a dependency management system, and logic for executing plugin goals at defined phases in a lifecycle. When you use Maven, you describe your project using a well-defined project object model, Maven can then apply cross-cutting logic from a set of shared (or custom) plugins.
Maven uses convention over configuration with lots of useful defaults (directory locations, a defined life-cycle, a set of common plugins that know how to build and assemble software), Maven provides a common interface to build project (unlike Ant, you know how to do things like running tests, packaging, etc with every project, no need to open the build script to find out how it's done), Maven implements reuse through maven plugins (build logic is embedded into plugins for DRY purpose, you don't have to repeat yourself over and over, you don't have to copy/paste parts of your build scripts), Maven has a Project Object Model that allows you to describe your project through meta-data (this enables dependency management, remote repositories, reuse of build logic, tool integration, artifacts search...).
So, because Maven provides a lingua franca or shared language for project management, comparing Maven vs. Ant (+ Ivy if you want), Maven vs. Buildr, Maven vs. Gradle is like comparing apples to oranges, the comparison is just irrelevant.
Is such a combination common? I am thinking of making it permanent in my project.
Well, no, that's really not the maven way of doing things. This might seem tempting (because you have the feeling that you regain control because you understand what is happening with Ant) but you are actually repeating yourself again and losing all advantages of Maven. Sure, there is some learning curve with Maven and I'm not saying you'll learn it in one night but once you'll get it, you'll feel the power. I'd thus recommend to keep trying, to ask questions on the mailing list or here on SO, to read the Maven Book, etc. But don't give up.
So you re-did what Maven gives you for free by writing Ant Tasks within a pom.xml?
Besides doing the Dep-Mgmt, Maven will compile the sources, run all test cases and package the whole thing as jar file for you with no extra configuration. That's the default.
It is not common to enrich a pom.xml with Ant clutter. However, some special tasks or legacy Ant tasks are sometimes embedded into the pom.xml lifecycle, but these are exceptions and not the common case.
What exactly is hard when writing a pom.xml?
I wonder, because most of the time you will do this once for a project and not struggle with it all the time. Also, most IDEs have support for creating the minimum pom.xml, which is just a few lines anyway.
I've tried Maven, personally for home projects and professionally at my workplace, and... I hate it. I must admit I don't have a lot of experience, but it doesn't feel good. I get the idea Maven is a less-than-perfect implementation of a good idea. I'll probably get flamed by Maven enthusiasts, but this is my personal opinion.
I think Maven comes into its own in organizations that deal with a network of interrelated projects, like Apache does; where dependencies tend to change a lot and need to be quite explicitly specified to avoid "jar version hell". For isolated projects dependent on a few seldom changing jars, I find it overly intrusive.
To answer your question: I've read forum and blog posts on the Internet of other people doing exactly what you propagate. They use Maven for dependency management and then do their building with Ant. This undermines some of the benefits Maven is supposed to bring, such as the fact that a "normal" build is simpler to specify in Maven than Ant. However, I think you can be encouraged by the fact that you're not the only person with this idea, and it is indeed working for some other people.
I'd like to give you links to quotes, but I came across this stuff in the past few weeks and didn't collect references.
I'm a Maven fan, but it's not without its problems. Some of the issues I remember (and still fight):
Just like Ant, it has a magical syntax that can be hard to understand. If you're familiar with Any you may forget that, but lots of Ant tasks are terribly documented. The same is true for Maven. One of the reasons I eventually switched to Maven, though, is that for many of the mojos (similar to Ant tasks), you don't have to understand how to configure them. You just have to put the various pieces in the right place (which can be as hard as configuring a task...).
The automatic dependency management is amazing!... when it works. When you have to use non-Maven dependencies (like Hadoop) it becomes a problem. You either have to reference them as system scope dependencies, find somebody else who has packaged them, or package them yourself. And you eventually need to setup your own Maven proxy, like Nexus. And that's a whole extra hassle.
Maven is a lot of trouble on non-network or isolated LANs. The automagic is great, as long as you're networked.
It was getting so hard to write up a pom.xml, that I generated a ant build.xml from one of maven's tasks (which is a nice handy task...) I had to tweak the build.xml that was generated by maven. And now all my compiling, testing, etc., is being done with this build.xml..
Well. you can use maven archetype plugin to generate pom :)
Is such a combination common? I am thinking of making it permanent in my project.
JBoss Seam uses Maven internally to handle dependencies and do some targets in Maven. It's a big project that grew up with Ant, and now is difficult to build entire project solely in Maven, but that is going to happen in near future.
If you just need dependency management with Ant, you could give Ivy a try. Maven is a tool for managing the whole lifecycle of the build process.
Personally, I find Maven a nice tool once you get over the learning curve since you can standardize the build process for a lot of projects and there are a lot of great add-ons (particularly for code analysis tools). However, it's very possible that you do enough custom stuff with your build that the Ivy + Ant combo makes more sense.
Honestly, I would love to see a dependency management tool that implemented that part of Maven, specifically as a command line tool. For everything BUT dependency management, I find Maven to be absolutely awful if you're doing anything but exactly what the most general case is. Every time I try to do something that isn't "normal" (system/acceptance tests, etc), I run into a brick wall due to
either horrid documentation,
being told it's "not the maven way" (when it's a task that needs to happen, and "the way" shouldn't be a factor), or
being told to wait for the next version of maven, because maybe it'll be supported then.
I'd love to have a command line tool that can implement the "I need this as a dependency, go get it" functionality of Maven, possibly even using the pom.xml files of various packages. Then I could just use that in a Makefile and happy :)
Simple answer to the question posed: YES <-- click the link for details and reasoning.
I requested Maven training at work, and the bosses want to hire someone who knows Maven to come work with us as a consultant so that we'll learn Maven from a real-world perspective instead of a training perspective.
I've been tasked with coming up with questions of various difficulty to ask potential hires in order to ascertain their Maven ability. The problem is that I don't fully understand Maven yet (hence the training request).
What questions would you ask someone to determine their Maven ability, and what level of knowledge would someone have to have of Maven to answer them?
In my opinion, a "Maven consultant" should:
Have a good understanding of how Maven differs from other build tools like Ant (Maven provides a "lingua franca" for project management).
Have a good understanding of Maven principles: Conventions over Configuration, the default layout, the naming conventions, the philosophy of the tool (one primary output per project).
Have a good understanding of how Maven works: from where the conventions are coming from (the super POM), the lifecycles (main, clean, site), the phases, how plugins are bound to phases, the influence of packaging, etc
Know what profiles are and how they can be used to deal with different environments, how to trigger them.
Know how to use plugins, how to configure them, how to plug them in a maven build.
Know how repositories work, the difference between local and remote repositories, what SNAPSHOT dependencies are.
Know how dependencies are resolved, what transitive dependencies are, how to control them, what dependencies scope are, how to use dependencyManagement.
Know how to implement code health checks, the essential plugins (Checkstyle, PMD and Findbugs plugins), how to implement various kind of tests (unit, integration, functional), how to measure coverage, when to fail the build, when to report.
Know how to setup maven in a corporate environment (using a shared repository, setting up CI, a company POM).
Know how to handle advanced packaging scenarii (with the assembly plugin)
Know how to handle deployment, the various protocols, the deploy plugin, the release plugin, the SNAPSHOT resolution.
Know how to setup a Maven build for a Java EE project, how to setup a multi-modules build, what modules are required, how to test in the development environment, how to handle the production environment.
Someone with these skills should put you on the right path (and has very likely a decent experience of Maven).
A lot of good questions here, especially the ones proposed by Pascal Thivent. However, I would ask another question:
Q: What is the difference between the aggregation and inheritence in Maven?
A: You can have a short explanation here.
I would suggest that you think about what you wanna do with Maven, or why you wanna introduce it into your projects. Maybe ask your boss for his reasons/goals in introducing Maven.
After you have named your main goals why to introduce Maven. Ask potential consultants how they would use Maven to achieve those goals.
Examples 1
Goal: Improve overall code quality in project.
Question: How may we use Maven to improve our overall code quality in projects.
Possible answer: Maven has several plug-ins to force/meassure code quality in projects, we could integrate those into our buildscripts in almost no time. (e.g. checkstlye, pmd, cobertura, xradar...)
Examples 2
Goal: Creating automated deployment scripts for several destination environments.
Question: How may we use Maven to automatically deploy artifacts to several destination environments.
Possible answer: We could use Maven plug-ins for deployment (e.g. Cargo) and use maven's profiles to handle several configurations.
a.s.o.
I would ask:
Describe what is the practice of SCM?
Describe your ideal Maven infrastructure (server, repositories, CI, plug-ins, conventions, etc.)?
Both are very open questions, but they should give your a feeling of his skills and what you can learn from him and what he could bring to your company.
EDIT
Maven is just one piece in the overall software configuration management (SCM) strategy. A good consultant should know the details of maven in and out but also know how it fit in the big picture. Just like you expect a Java EE consultant to be expert in a Java but to know what it means to deliver enterprise application to a customer.
In the company I worked, we had a guy responsible of the SCM who had been a Maven contributor. And his view was way broader than "just" maven. He was in charge to have a productive build, configuration and release process. Two examples:
We were hard-coding the release number in java code to be able to display it into the "about" dialog of our desktop applications. Most of the time we forgot to change it after the release resulting in a mismatch between the actual release number and the about dialog -- big problem for integrators on-site. This was a bad practice. He then set up something so that the release number in Maven would be correct in the manifest file and educated us to read the manifest file from Java to ensure both match.
When you would release a module, he wrote a script to not only build the application, but also close the corresponding version in the ticket system (JIRA) and push the release notes in the wiki.
All that to say that knowing how to "mavenize" a project is important, but more important, the guy must understand how you currently work, what is in place and help you set up something reasonable to improve your productivity.
Here are the questions I would ask:
How would you enforce the use of JDK6
for a group of projects?
How would you enforce the use of a
particular version of a plugins?
What are some of the reasons why you
would use an assembly to build a jar
rather than the jar plugin?
Describe the process of releasing a
Java EE project made up of an EJB, a WAR
file and two utility jars.
How many repositories should an
internal company repository server have and why?
How would you structure a POM project made up of N child projects so they it can easily be used in Eclipse?
All of these questions have at least two answers. I would be looking for someone who can provide at least two answers and point out the pros and cons of each approach. Ideally, this person should be tweaking the set up to be less disruptive to the way your environment already works.
If you have the luxury, I suggest having the consultant come onsite for a day, give him/her an existing java project that you're working on and have him/her "mavenize" it for you. The next day, sit with him/her and have them explain how to compile, and build a jar (or war).
Or maybe have them come to the interview with a maven project to demonstrate. The should be able to compile, and build a jar/war at the very least, imo. If they can run unit tests, deploy to tomcat, integrate with any of the various frameworks like gwt, hibernate, spring, etc, then even better.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am really tired of struggling with Maven 2 all the time. Build tools should not be in the way. Recently I have been looking at Buildr and Gradle. Maven 3 seems to fix some of the struggles. So, what should I go for now? Buildr? Gradle? Or wait a year for Maven 3?
I wouldn't expect too much from Maven 3. The people behind the Maven pedigree of build tools have always held the assumption that project builds are homogeneous, that is: all build problems fundamentally boil down to the same problem. This view of the world can be held fairly consistently in the face of opposing views but comes at a cost. The absence of scripting logic in Maven ("when you want to script you know you're doing something wrong"), the cumbersome plugin API ("no ordinary Maven user should want to write a plugin") and the central repository ("we all have the same dependencies") are all testaments of this overarching assumption.
In the real world build problems are heterogeneous because people build software for a wide variety of reasons. They all 'develop' like we all 'drill holes' once in a while for solving unique problems. Regardless of your level of abstraction you'll always find similarities when comparing arbitrary build problems. It is the reveration of these similarities and the condemnation of differences that is the downfall for Maven's design and the reason why it draws so much flak. Basically, Maven is authoritarian and utopian in its outlook.
PS: Maven has good features, like convention-over-configuration and the idea of using repositories (the Maven implementation of this idea is troublesome).
No build system is a magic bullet. I find Maven solves more problems than it causes for me, but I'm quite comfortable writing plugins to get round its shortcomings, I also deal with hundreds of projects, so Maven's inheritance and dependency processing is quite helpful for me.
Browse SO a bit and you'll see Buildr and Gradle both have issues too (same for Ant and Ivy), generally you're trading one set of problems for another and its a case of finding the least painful.
Is there anything in particular that is bothering you about Maven or is it a general itch? If it is a particular problem it is worth looking at the Maven 3 issues on Jira, if the problem isn't addressed, you can raise it, or else there may be little point in you waiting
We use Maven here, but I find that once you get outside of a simple project, the pom.xml starts to get more and more complex. You start spending a lot of time working out how in the heck to configure your pom to do what you want, and how to work around the various issues.
The thing that really got me was the ear we're building. We have multiple wars in that ear file, and Maven normally sticks the libraries in the wars. However, to reduce the size of the wars, and to keep the jars all the same, we wanted to put the jars shared between the wars in the ear's lib directory.
Unfortunately, Maven doesn't handle this very well. We needed to manually configure this for each of the wars' poms, and then add all of these dependencies into the ear's pom.
In another project we have HTML based help files. The people who write the help write them in Microsoft Word then use a program to translate them into HTML. A single character change can reverberate throughout hundreds of files.
To get around this issue, our help system is stored in our source repository as a single zipped file. When our documentation team creates a new set of help files, they zip it up and replace what is in the repository.
So, part of my build is unzipping this file and placing it in the war. Easy to do in Ant, can't do it in Maven unless you use the Antrun plugin which allows you to write Ant code to handle issues that Maven cannot handle without a full blown plugin.
I can see what Maven is doing, but theory got ahead of reality. What I found is that Ivy and Ant can do most of the dependency checking that Maven does without all the issues of writing and maintaining the poms.
If you're not already using Maven, try Ant with Ivy first. Then when, Maven 3 comes out, try that. I remember the transition from Maven 1 to Maven 2. They were entirely incompatible with each other and anything you learned using Maven 1 was obsolete. It would be silly to learn and redo your projects in Maven 2 to suddenly find yourself redoing everything for Maven 3.
maven 3.x is already embedded in IDEs (at least on netbeans, check this link for more infomration). You can play today with maven 3.x simply building a Maven project with netbeans.
Another nice news is that maven got more 'enterprise' support with integrating EJB/WS in IDE projects (again, at least on netbeans).
So I would stick to maven 2.x for production builds and play with maven 3.x for development.
Maven 2 and 3 have both been working perfectly for me on a variety of projects. I am currently using Maven 3 alpha 7 which works very well, especially in conjunction with the Eclipse Maven plugin.
Maven integrates seamlessly with Ant - in both directions. In my current project, we invoke Maven from Ant multiple times in order to perform complex integration test. Likewise, we use Ant via Maven's AntRun plugin, and we also wrote our own Maven plugins. This, by the way, is a matter of minutes and boils down to writing an annotated Pojo.
Maven gets a lot of flak because many developers don't like rules or conventions. Quite simply, nobody forces you to use Maven. If you want ultimate freedom - by any means - re-write your own build process for every project you join. However, if you like to create software rather than re-inventing the wheel with a custom-made build process on every project, go for Maven.
Keep your code well maintained and broken into well defined modules and porting between build systems becomes a minor problem.
As for now, maven-2 is a good choice for the middle 2/3rd of projects. For the really simple, ant is still ok. For the really complex, a hybrid of maven-2 and other tools (like antrun) becomes inevitable.
Not sure why you are having problems with maven-2.
It differs from ant and buildr in that it is a tool for describing your build process, not scripting it. Complex builds, the ones with multiple dynamic parts and nested and/or transient dependencies are hard to build because they are hard to describe.
Give Lattice https://github.com/hackingspirit/Lattice a try. I am the author. Here is the scoop:
In Lattice build files are written not in XML, but in the Python language. The ben- efits are much better readability and powerful imperative build scripting supported by Python.
For multi-module projects. Lattice uses topological sorting to decide the correct order to build each module. It’s also planned that Lattice will analyze the module dependency to determine how the module compilation can be parallelized.
Lattice’s source code is extremely lean, currently it consists of about 500 lines of Python source code.
I think people complaining about Maven should spend a little extra time investigating available plugins. In response to comments complaining that Maven is rigid and makes it hard to use custom build logic / provide fine-grained control over the build process - I would recommend looking into Ant plug-in for Maven (there are actually several, but here is one: http://maven.apache.org/plugins/maven-antrun-plugin). I have had great success customizing Maven builds with it over the years. Basically, it allows you to run any Ant command as part of the Maven build, and you can do pretty much anything with Ant ;)
Ant with Ivy does the same dependency management Maven does (in fact, it uses Maven's whole dependency management infrastructure including the same URL repositories), but without all the POM configuration mess.
Ant with Ivy might be a way of handling the dependency issues for people who really don't want to use Maven. It solves 90% of the stuff that Maven was suppose to solve.
We have a Java codebase that is currently one Web-based Netbeans project. As our organization and codebase grows it seems obvious that we should partition the various independent pieces of our system into individual jars. So one Jar library for the data access layer, one for a general lib, one for a specialized knowledge access, etc. Then we'd have a separate project for the web application, and could have one for a command line tools app, another web app eventually, etc.
What is the recommended practice for doing and managing this? Is it Maven? Can it all be effectively done with just Netbeans alone by simply creating individual projects and setting the dependecies of one project on the jar files of the others?
I'd agree with SteveG above on using Maven2 to help you modularise your code base, but I'd use Nexus as the local repository for Maven instead of Archiva. The guys at Sonatype also have an excellent (free html/pdf) book on how to use Maven, Nexus, and integrate it into IDEs.
Be careful on how you decide to partition up your projects, though. There's no sense in over-complicating your dependencies just for the sake of it.
I would definitely say check Maven(2) out. It is very good for doing this sort of thing. You can define individual models and version then very easily. Netbeans also does a decent job of integrating with.
Also I suggest you set up Archiva which will let you be dependent upon binaries of other artifacts that your company generates internally. This also acts as a proxy and will keep a local copy of any external dependencies your projects might have so its very quick to get the new versions internally.
I would create ant scripts to build the pieces and for deployment. Then you are not depending on your IDE for build/deployment.
It sounds like your code is getting to the point where you're graduating from the WAR approach and have entered into the EAR level.
An EAR is just another archive that contains all the other JARs and WARs that get combined to create an application. There are four types of modules that can reside inside it, Web, EJB, Connectors and Utilities. Most people only use Web and Utilities so they go with using the WEB-INF/lib approach.
But if you're starting to get a lot of interdependencies what you do create an EAR project and make your web project a child of it. Each Utility JAR which is just straight Java code used by other modules also becomes a child of the EAR. Finally in each of your projects there should be a META-INF/manifest.mf file that just has the name of the JARs that JAR/WAR depends on.
I'm an eclipse guy and most of this gets taken care of for you in eclipse, but I'm sure netbeans has very similar functionality.
Now the only problem is that you have to use a full Java EE server to deploy an EAR so I don't think you can use Tomcat if that's what you're currently using.