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.
Related
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.
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.
With maven I can create a parent pom.xml and extends it everywhere. Also in parent pom I can define some general properties like library version and other properties which are wanted to share across several imdepeneded projects. How to do this with sbt if projects are different and they do not build from one root project/folder?
Important
The question is not about multi project build!
Not tested, but should work:
Create a normal SBT project, define your desired settings, etc. there. Let's say it's in the path ~/parent.
Note that the project folder of an SBT project is itself a project.
You can depend on external projects from file system or VCS in SBT. In the builds where you want to reuse parent project, create project/project/Build.scala (or project/build.sbt) if it doesn't exist yet, define the project as usual and and add a dependency on ProjectRef(file("~/parent"), "project").
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 3 Java projects with the same entities.
I want to share entities between these projects because entities can evolve during the development phase.
We are thinking about building a jar with entities and sharing it using Maven (with a repository).
Maybe you have another solution ?
I also can recommend to use Maven to share code between projects.
Here are some tips to get started:
Use a Maven Repository Manager such as Nexus. It will help you to
create a stable development environment.
Every developer (also the Continuous Integration Server user) should configure their settings file to use your Maven Repository
Manager. Don't specify your repositories in the POMs, confiugre them
only in your Maven Repository Manager.
http://www.sonatype.com/books/nexus-book/reference/maven-sect-single-group.html
Use the dependencyManagement and pluginManagement elements of your parent POMs to specify all versions of the plugins and dependencies
you are using. Omit these versions in the other POMs (they will
inherit them from the parent POM).
I also recommend to use different POMs for multi-module builds and parent POMs.
If you want to share common interfaces, classes, functionality or components, Maven is the way to go. In addition to the dependency management, you also get the added bonus of a standard project layout that will simplify things. Easy integration with most common continuous integration servers and a standard release process are further benefits.
Definitely take a look at Maven!
making an own JAR-library is definitely a good solution.
The jar-file is easy to distribute via dependency management (maven, ivy, gradle ..)
The jar is versioned
The projects using the library can be tested against a certain verion. Otherwise it may gets a problem if you change enties and forget to change a depending project. -> integration tests
Regards
Entities are the representation of a given object am I correct? If so the default mechanism implemented by Java is Object serialization - http://en.wikipedia.org/wiki/Serialization. In the case of jar files if an entity changes you would have to change jar once again each time as well. It may be tedious.
Geneate a standard war file in roo.. But then change it's package to jar file.
Then from any standard war file you can just deploy this jar (Ill use the jar as a maven dependency). Ill maintain a unique named applicationConext like pizzaShop-applicationContext.xml and like pizzaShop-applicationContext-jpa.xml. so from a parent spring project I can stack up various roo projects in this fashion.
Ill also keep their generated webapps folder to allow for the generator to work more easily. (This means I have to open up the pom.xml and keep changing it back to jar). Also helps with cut and paste fodder for non roo generated war files web.xml entry additions.
Seems like it may be a confusing point about roo.. You can just mix and match these jars as you would any spring project. They function like self contained units of springness and work fine sitting side by side with other spring jars all under the same webapp/web.xml context.
Its tedious but still better then writing spring code by hand.