At the moment I'm working in a project which contains out of 260 maven submodules under one parent pom. This seems to slow down the build. That's why I came up with the question when should I use submodules and when shouldn't I use it.
Introduction to the POM says:
If you have several Maven projects, and they all have similar configurations, you can refactor your projects by pulling out those similar configurations and making a parent project. Thus, all you have to do is to let your Maven projects inherit that parent project, and those configurations would then be applied to all of them.
And if you have a group of projects that are built or processed together, you can create a parent project and have that parent project declare those projects as its modules. By doing so, you'd only have to build the parent and the rest will follow.
Create submodules when:
projects share the same configuration, to avoid configuration duplication
projects are interconnected, to make building easier
This question is a bit broad because it is hard to set a general rule.
My rule of thumb:
"A multi-module project consists of those modules/artifacts that should always be built together".
If you just want to share configuration, you can use a parent POM without using multi-module.
Related
I have a parent Maven project (pom packaging) and 4 Maven modules (jar packaging) as children of that. Is there any way/plugin to create a importable dependency of the parent project including all the children? I mean that I want to create some kind of abstraction, so when somebody wants to import my project, it won't be necessary to import a specific childermodule (the module that he will use), he will just import the whole project (all the children modules)
The Maven parent project corresponds with inheritance. It is meant the children projects to inherit the settings, so you do not have to repeat them and you may set all the common stuff in a single place.
On other side, the convenience Maven project containing dependencies corresponds with composition.
You should not mix these two things together. Parent project is a common super-class of your modules. This convenience project you wish to have is a collection containing all your modules as dependencies. You should not want the theAnimal class to depend on all the animals.
Just accept the fact that you need two separate Maven projects:
the parent (if you need it), and
the convenience project for transitive dependencies.
The solution for your problem is described e.g. here: 3.6.1. Grouping Dependencies
If you have a set of dependencies which are logically grouped together. You can create a project with pom packaging that groups dependencies together. For example, let’s assume that your application uses Hibernate... Every project which uses Hibernate might also have a dependency on the Spring Framework and a MySQL JDBC driver. Instead of having to include these dependencies in every project that uses Hibernate, Spring, and MySQL you could create a special POM that does nothing more than declare a set of common dependencies. You could create a project called persistence-deps (short for Persistence Dependencies), and have every project that needs to do persistence depend on this convenience project.
I have four projects, Proj-A, Proj-B, Proj-C and Proj-D. Proj-B, Proj-C and Proj-D all have Proj-A as a dependency inside their POMs. B,C, and D are not dependent on each other. I have put profiles in Proj-A in order to allow parametrization of some settings (jpa settings for dev, test and prod db connections). That works fine.
Is there a way to build the other projects, and have them pass the proper build profile to use when building the dependent project? If so how? I would like to do this without putting properties in the settings.xml file for the maven repository.
I am familiar with Maven2 but by no means an expert, any ideas?
As far as I know there is no a beautiful way :/
You can inherit profiles from a parent to its children.
But the planned implementation of mixins is still open
What I've seen is that people create a parent containing the profiles and then use it as parent for the project-parent pom.xml
What is also possible is to use a different (released) parent for modules:
project-parent (having modules configured)
/module1 -> using webservice parent pom
/module2 -> using rest parent pom
That is not the usual structure but one way to share configuration for related modules in different projects.
I am using maven 3 for building my huge multi module project. I have nearly 80 projects and many dependencies are used by many project thus makes me to add the same dependency entry in all my projects. In case if i am updating/moving any of my dependency to its latter or earlier version I need to update in all other projects which uses that dependency which is quite impossible.More over it is not possible to create a parent pom for set of projects which has same dependency.
Is there any plugin just to map as below in a pom of parent project
<dependency>somegroup:somefact:anyV<dependency>
<projects>
<project>somegroup:somefact:anyV</project>
</projects>
or is it possible to implement a plugin on my own </br>
or whether maven provide any other way to do this in its style.
Maven has a concept of importing dependencies. The documentation says that this feature is for cases where extending a base POM is not possible. I have not used this feature so I'm not sure how it works, might be what you are looking for though.
I am still fairly new to Maven, I finally have it how I want but now I need to break it all over again.
Here is my scenario:
I need to write two different server applications, which use identical core functionality; just, what is done with that framework is very different. One server application is very easy/simple - it's already done - whereas the other is a lot more complicated.
The code is written in a dependency injection style (using Guice, if it matters), so it should be extremely easy to break apart.
My question is this: how would you structure the projects in Eclipse, using Maven? Would you set up three different projects, something like:
server-core
server-appEasy
server-appComplicated
where each server would have it's own pom. Or, would you keep it all in one project? I need to be able to easily recompile appEasy in, say, a month from now, while I work on appComplicated. The classes for appEasy are already in a subpackage. Note: core would not work by itself without at least a mock dependency injection. It doesn't have a main class.
All thoughts appreciated, even on things I haven't thought of.
I would have a structure like this:
/server
/server-core
pom.xml
/server-appeasy
pom.xml
/server-appcomplicated
pom.xml
pom.xml
So each project has its own pom.xml that allows you to build that project in isolation.
However the parent folder also has a pom.xml, which will build all the projects if run. You can do this by including the projects as modules in the parent pom.
E.g. In the parent pom.xml
<modules>
<module>server-core</module>
<module>server-appeasy</module>
<module>server-appcomplicated</module>
</modules>
You can also use managed dependencies in the parent pom tio allow you to centralise external dependency and plugin version numbers.
I would suggest to structure all as a Maven Multi Module project.
The parent project, would have the three projects as modules, the 3th party dependency versions, and the version of your project as a property.
Then, in the server-appComplicated and server-appEasy I would add a dependecy to the server-core.
In this way you will gain:
1- A root project to compile (the parent), that it will generate the two servers and the core-lib.
2- A point where to handle the version numbers and the common dependencies.
I hope it helps
Im not a maven expert but here is my 2 cents.
Each project needs its own pom.
Do you need to build all the projects together? In that case it might make sense to have a parent pom , which has all the common dependencies.
EDIT: In that case, I feel just have three separate 3 pom files for each project.
There are multiple ways to do this, depending on how you need it when it comes to deployment. Assuming that 'server-core' is a shared artifacts among your 'server-appEasy' and 'server-appComplicated' artifacts, I would suggest something as below
Create a Maven Project 'server-core'
Add two module projects
by name 'server-appEasy' and 'server-appComplicated'
Make sure the module projects have their parent set as the 'server-core'
In the end you should have three projects (each has separate pom.xml), where
a. Building 'server-core' will also build the modules
b. Building either of the 'easy' and 'complicated' modules independently on need basis will also build the server-core.
Hope this helps!
I have a small (4 module) maven project with the root pom in pom packaging. Right now, I have a impl module that contains the main methods and setup. This does lead to some issues, eg building a single jar for the entire project, (possible) huge dependency list containing all modules, and confusion trying to trace back to the main method for future developers.
So I'm thinking: Is it best practice to put this kind of stuff in the root project, or should it stay in its own module? Would there be any disadvantages of putting it in root (eg plugin issues)?
This does lead to some issues, eg building a single jar for the entire project
There are solutions for this (e.g. using a dedicated module and the Maven Assembly Plugin or the Maven Shade Plugin).
(possible) huge dependency list containing all modules,
I didn't understand what you're referring to here.
and confusion trying to trace back to the main method for future developers.
Just document things if nobody can transmit the information.
So I'm thinking: Is it best practice to put this kind of stuff in the root project, or should it stay in its own module? Would there be any disadvantages of putting it in root (eg plugin issues)?
Stephen is correct, aggregating and/or parent POMs must have a packaging of type pom and you can't put any code in them.
AFAIK, the parent module of a multi-module project has to have type "pom" and that would preclude putting any code or other resources into it.
Certainly, I wouldn't try this.
If you want to have all of your classes, etc assembled into a single JAR, there are other ways of doing this. For example, take a look at the Maven Shade Plugin.