I would like to generate two jars from the same maven project when executing a mvn clean install.
The only difference between the two jars, will be the content of the META-INF folder.
For the moment, I've my-app.jar, I would like to have now my-jar-xxx.jar and my-jar-yyy.jar.
How can I achieve this ?
Regards.
You should not be creating two maven jars from the same maven project. Why? This sonatype blog post should explain.
The same article also explains two ways in which you can still do it, if you want to
Using profiles
By doing two executions of maven jar plugin
Here is the related stackoverflow post as well.
First of all +1 for Raghuram recommendation. In his linked sonatype blog you get hints about doing what you want using the classifier to distinguish between your two jars. The jars belong to the same artifact in this case.
You can also use two different poms for two different builds and call
mvn -f pom-xxx.xml clean install
mvn -f pom-yyy.xml clean install
In each pom you can specify an own artifactId. That separates both artifacts a bit more than the classifier solution does.
Nevertheless the advice not to do this seems reasonable and I would follow the parent/module project layout suggestion.
Related
That looks easy enough: search the net in which package they are, copy the dependency into your pom.xml and here you go!
But I didn't didn't anything that I could use as a dependency.
Not much of a surprise, other people had the same problem, and solutions can found here https://stackoverflow.com/a/29270114/4142984 in combination with https://stackoverflow.com/a/15692230/4142984 .
In other words, those solutions suggest to get the jar manually and hard-link it in you build-path. It worked, though.
But isn't maven supposed to do that?
Question is: what did I miss, to tell maven to do this.
And I'm using maven with eclipse, just in case this would make a difference.
The links you provided suggest adding a JAR to your project CLASSPATH. That's not using Maven.
If you want to have Maven manage that dependency, and it's not in a Maven Central repo, you need to do an mvn install to your enterprise or local Maven repository.
I'm not if this Maven plugin is what you need. Maybe you can consider that as well.
I am new to Maven and I faced a problem when I tried to convert my current project from using Ant -> using Maven.
That project requires many Jars, and I look up those jars on mvnrepository and add all to POM.xml.
I don't know if some dependency is redundant.
Do you guy know any way to check if which dependency which I really need?
The Maven dependency analyzer plugin is just what you're looking for.
Just run
mvn install dependency:analyze
(on some platforms, for some reason, the full notation is required:)
mvn install org.apache.maven.plugins:maven-dependency-plugin:2.9:analyze
And review the report it produces.
My (maven)project is dependent on both stanford-CoreNLP and stanford-Parser and apparently the (lexicalized)parser of each dependency is producing different outputs, they are not alike.
My question is that how can I determine which package the parser should be loaded from ? the parser class has a same name in both packages:
edu.stanford.nlp.parser.lexparser.LexicalizedParser
and maven automatically loads the class from stanford-coreNLP package while I want it to be loaded from stanford-Parser.
I'd appreciate if you please help me with your suggestions.
I would raise a bug asking them to move the lexical parser into a new maven artifact (or several of them), so you can distinguish them.
If that doesn't happen, you have two options:
Use the Maven shade plugin (as suggested by ooxi)
Delete the offending classes
Breakdown of the second approach:
Use you favorite ZIP tool to open the JAR archive.
Delete the offending packages.
Copy the original POM
Change the version version to something like 1.1.MythBuster.1 or 1.1.no-lexer.1
Use mvn file:install to install the modified artifact in your local repo
Test it
Use mvn deploy:deploy-file to install the modified artifact in your company's repo
I prefer the second approach since it makes sure the build has a clean classpath, people know that you messed with the original file and it's pretty obvious what is going on.
I once had this problem and could solve it by using a virtual package depending on the two conflicting dependencies (in your case stanford-CoreNPL and stanford-Parser) and merging them using the Maven shade plugin.
When shading only one class will be in the virtual package, depending on the order of <dependency /> tags.
I have two projects A and B managed with maven and B depends on A. (Additionally they both have external dependencies from the public repositories).
When I run mvn compile on A everything is ok.
When I run mvn compile on B it tells me 1 required artifact is missing.
Doing mvn install on A does not help. What should I do?
I should add that these are two different projects rather than two modules of 1 project. Help.
UPDATE
It was just a typo in the referencing pom.xml, which I discovered thanks to #Raghuram's comment
Doing mvn install should be enough - check there are no typos in your pom.xml files.
Either install it manually to your local repository or use a repository manager like Nexus.
I would, as Rohan mentions as a comment to your question, create a parent pom you can execute the install goal for, including your two "internal" projects as modules.
I'm in the process of learning maven (and java packaging & distribution) with a new oss project I'm making as practice. Here's my situation, all java of course:
My main project is ProjectA, maven-based in a github repository. I have also created one utility project, maven-based, in github: ProjectB. ProjectA depends on a project I have heavily modified that originally was from a google-code ant-based repository, ProjectC.
So, how do I set up the build for ProjectA such that someone can download ProjectA.jar and use it without needing to install jars for ProjectB and ProjectC, and also how do I set up the build such that someone could check out ProjectA and run only 'mvn package' for a full compile?
(Additionally, what should I do with my modified version of ProjectC? include the class files directly into ProjectA, or fork the project into something that could then be used by as a maven dependency?)
I've been reading around, links such as this SO question and this SO question, but I'm unclear how those relate to my particular circumstance. So, any help would be appreciated. Thanks!
So, how do I set up the build for ProjectA such that someone can download ProjectA.jar and use it without needing to install jars for ProjectB and ProjectC
Assuming ProjectA is a JAR, you can create an executable JAR that bundles the dependencies with the Maven Assembly Plugin (and the predefined jar-with-dependencies descriptor) or with the Maven Shade Plugin.
how do I set up the build such that someone could check out ProjectA and run only 'mvn package' for a full compile?
You have to deploy the dependencies to a repository that can be read over HTTP and to declare this repository in your pom.xml. AFAIK, git-hub doesn't offer any facility for that. But any web hosting service with FTP access (or better, scp) should do the trick. If your project is open source, another option would be to use Sonatype's OSS Repository Hosting service.
Just in case, you might want to read this blog post but you won't learn much more things.
The easiest would still be to organize the 3 projects as a multi-modules maven project and to build all modules.
Additionally, what should I do with my modified version of ProjectC?
From a modularization point of view (assuming you found a solution for the above part about repository), it would certainly make sense to have it as a separate module, especially if there is an opportunity someone can use ProjectC outside your project.
You have to publish the code from the additional dependencies. Two options:
Use the maven-shade-plugin to create a maven artifact containing all the content of the B and C jars, and publish that under your own G/A/V coordinates.
Publish copies of B and C under your own G/A/V coordinates using the maven-deploy-plugin to your forge just as you will publish your own code. Different forges have different policies; but if you abide by the licenses of B and C you should be OK.