Under a common parent I have three Maven projects that are loosely related, and I must add the jars that all of these projects generate and their dependencies to a third party ear. For each of those three projects I have properly configurate de dependency:copy-dependencies goal.
In order to have things as automated as possible, I want to join all the jars in a single location.
An initial idea would be using an empty "joiner" project that depends on all of the previous three projects, and just use dependency:copy-dependencies on it. But I do not really like the idea of an empty project with its empty artifact, and I am wondering if there is a more standard way of doing this (ideally by copying the dependencies in a directory of the parent that does not need to be commited to version control) with the standard plugins.
Related
If I have a parent Maven project that contains the Maven wrapper files, is there any reason to also including the wrappers in the submodules of this project? Does it really matter? Any possible side effects of doing this I need to look out for? I only plan on running Maven commands from the parent project, but some day I may want to break the submodules up into their own separate projects.
Edit: To be clear, I'm talking about mvnw, mvnw.cmd, and the .mvn directory
The Maven Wrapper is only needed on the root level the project. The intention is to define a the version which will be used for building the project by downloading it automatically.
If you later decide to split up the project this would result in creating separated repositories (Git) and this means you have for each of such projects an other root which mean there it would make sense to have the maven wrapper.
I have a situation at the moment where I have:
Project A which is built into a fat jar using Maven assembly plugin.
Project B which uses the jar built in Project A. It is added to the project as a resource and launched in a separate process using a process builder.
I wonder if it's possible to achieve similar behaviour using just one Maven project. I.e build the jar containing only the classes and dependencies required for project A, and then build the rest of the project with the prebuilt jar.
Sorry if I'm not being very clear here.
This is against a few of Maven's core concepts:
One project, one model (POM). Two projects (A, B), two models (POMs).
There's one artifactId in a POM. What is a second artifact (jar) supposed to be named?
One project leads to one artifact. There is no additional "prebuilt jar" built within the very same project.
Dependencies are for the whole project (and possible sub-module projects). I'm not aware of how to "containing only the classes and dependencies required for project A".
Artifacts are stored:
in <project>/target temporarily
in the local Maven repository (default: ~/.m2/repository)
possibly in a remote Maven repository
... while resources are taken from <project>/src/main/resources during the build.
There might be some tricky solutions (which have possibly pitfalls, too) to achieve this if one thinks about it thoroughly. But I'd never ever recommend such.
There is a complex multi module project I am working on to move from ant.
Things we want to achieve are:
Ease of development, and packaging for developer.
Example: Parent Project
SON A
Parent Project
SON
GRANDSON A
GRANDSON B
DAUGTER (DEPENDS ON SON)
GRANDSON C
GRANDSON D
What I want is that when a developer is working on Daughter Project he just downloads the parent project and the SON dependency should be resolved from svn repository. I know it can be done by defining dependecy in pom.xml but that will conflict with my second requirement.
2) To download all daughters and sons of the parent project and compile them so that build consistently can be checked by automated build manager like Jenkins. And in addition I would also like to release the revisions on a flag to the maven repository if the build is successful. Please note that revision needs to be head of each module.
3) In both the procedure I want to create a tar file or my own style directories which will contain different jars in different directory as per my need. (I can achieve this by adding ant copy command; any better Idea on same)
What are the standard approaches in maven to achieve it.
In your Maven hierarchy, only the leaf projects (the grandchildren in your example) will be actual modules that contain code and produce an artifact (e.g. a jar). The internal nodes (Parent, Son, Daughter) will only be used to hold common configuration and dependencies that are shared by modules down the hierarchy. Therefore, Daughter cannot depend on Son, but Grandson C can depend on Grandson A, for instance.
If the parent project hierarchy have their own life cycle, i.e. the poms can be released independently, they should be on their on SVN module. Developers working on submodules do not even need to download these poms, as they would be automatically retrieved from your Archiva, if they are deployed there by Jenkins. See this answer for a similar situation.
However, you see to indicate you wish to build and release all modules are the same time. In this case, you can have the same pom hierarchy by keep all projects in the same SVN repository.
Very new to Maven, can someone please explain to me the difference between using maven modules vs just adding a dependency to your maven project to another maven project in your workspace? When would you use one over the other?
A dependency is a pre-built entity. You get the artifact for that dependency from Maven Central (or Nexus or the like.) It is common to use dependencies for code that belongs to other teams or projects. For example, suppose you need a CSV library in Android. You'd pull it as a dependency.
A Maven module gets built just like your project does. It is common to use Maven modules for components that the project owns. For example, maybe your project creates three jar files.
A dependency can be thought of as a lib/jar (aka Artifact in Maven parlance) that you need to use for building and/or running your code.
This artifact can either be built by your one of the modules of your multi module project or a third party pre-build library (for example log4j).
One of the concepts of maven is that each module is going to output a single artifact (say a jar). So in case of a complex project it is good idea to split your project to multiple modules. And these modules can be dependent on each other via declared dependencies.
See http://books.sonatype.com/mvnex-book/reference/multimodule-sect-intro.html for example of how a web app is split to parent and child modules and how they are linked.
One of the most confusing aspects of Maven is the fact that the parent pom can act as both a parent and as an aggregator.
99% of the functionality you think about in Maven is the parent pom aspect, where you inherit things like repositories, plugins, and most importantly, dependencies.
Dependencies are hard, tangible relationships between your libs that are evaluated during each build. If you think of your software as a meal, it's basically saying A requires ingredient B.
So let's say you're preparing lasagne. Then your dependency chain would look something like this:
lasagne
<- meatSauce
<- groundBeef
<- tomatoPaste
<- cheese
<- noodles
The key thing is, each of the above items (meatSause, groundBeef, cheese, etc) are individual builds that have their individual set of dependencies.
By contrast, the only section of your pom that pertains to aggregation is the modules section:
<modules>
<module>meatSauce</module>
<module>groundBeef</module>
<module>tomatoPaste</module>
<module>cheese</module>
<module>noodles</module>
</modules>
Aggregation simply tells your build engine that it should run these 5 builds in rapid succession:
groundBeef -> tomatoPaste -> cheese -> noodles -> meatSauce
The main benefit of aggregation is the convenience (just click build once) and ensuring the builds are in the correct order (e.g. you wouldn't want to build meatSauce before tomatoPaste).
Here's the thing though: even if you organize the libs as standalone projects without module aggregation, your build will still come out the same provided you build in the correct order.
Moreover, both Jenkins and Eclipse have mechanisms for triggering builds if a dependent project has changed (e.g. changing groundBeef will automatically trigger meatSauce).
Therefore if you're building out of Jenkins or Eclipse, there is no need for aggregation
I've following scenario:
ProjectA have two dependencies depA and dep2
I want to create two builds one with both dependencies and another one just have one dependency.
Now, my question is:
How can I achieve custom builds?
Can I create simply two POM files? If yes, then how should I be building projects using specific POM?
There are two ways you could create multiple output packages. One is to use the maven assembly plugin to create multiple archives. The other is to create a multi-module project and give each artifact it's own pom.xml. I would recommend the latter case as it embeds less assembly logic in your pom. In this case I would create at least three modules... one for the project artifact with no packaged dependencies and two others for that artifact plus the various dependency items.