Let's say I have a maven project which has some maven modules inside.
My main module depends on the other modules, so when I compile the main module they should be compiled together.
The question is, how to add these modules as dependencies to the main module?
I know if I have a custom lib that I want to use with maven, let's say a utilities project, I have to compile the jar of the project, do a mvn install:install-file on it to install it on the local repository and then add it to the pom.xml.
Do I have to do this with all my modules and add the dependency to the pom.xml on my main module? Because if it should be done like this, there will be a lot of work to do when changing code on the other modules.
What is the best practice to use avoid the trouble of compiling/installing the modules to local repository?
The question is, how to add these modules as dependencies to the main module?
The same way you add any other dependency to your maven project. By adding group id, artifact id and version to <dependency> element
Do I have to do this with all my modules and add the dependency to the pom.xml on my main module?
If your main module depends on some module A then only the pom of the main module should contain dependency declaration towards module A. You do that for all the dependencies of your module.
I don't know what you mean by "a lot of work when changing the code on other modules". Maven has nothing to do with code changes, it just builds the projects whatever they look like at the given moment...
What is the best practice to use avoid the trouble of compiling/installing the modules to local repository?
Any project that you invoke mvn install on gets built and it's jar copied to local repository. That's all you need to do to get the jar into the repo. This will also put all the dependent jars, if available, into the local repo.
As for best practices for multi module projects:
If your parent project (the one that has modules inside) has <modules> section that lists the modules of your application, and modules are in subdirectories of your parent project, then you simply mvn install (or whatever you want to do) the parent project and that will cause all the modules to be built in order defined by declared dependencies between them. That means that if your main module has dependency on module A, then module A will be built before the main module. This way you can build and install all your modules with one command. On the other hand this approach makes more tight coupling between modules which is not desired in some cases, so it depends on your use case whether it is a good approach or not.
I'm currently working on creating a Maven-Tycho build environment for a relatively large RCP project. The Maven build is already completing successfully, but I'm having trouble removing all the errors from the projects when opening all the sub-projects in the Eclipse IDE.
One of the problems that is most common is, that a MANIFEST.MF contains a Require-Bundle line that cannot be found. This is mostly because I'm using the tycho-pomless extension to reduce the number of pom files I need to maintain.
So the error that happens is, that it cannot find a dependency in the Manifest, because the project should inherit it from the parent-pom. Because it is a pomless build though, the temporary pom for the project is only existing while building the project with tycho-maven. This means that eclipse does not seem aware of the inheritance of the dependency.
I've created a minimal example HERE.
If you open this workspace with an Eclipse IDE you can see, that there are errors and the following lines in App.java have errors:
import com.github.oxo42.stateless4j.conversion.ParameterConversion;
ParameterConversion.validate(null,null);
The required dependency is in the parent pom in the root directory of the workspace:
<dependency>
<groupId>com.github.oxo42</groupId>
<artifactId>stateless4j</artifactId>
<version>2.5.0</version>
</dependency>
The dependency is also in the Manifest of module 1, but it cannot be found in the Eclipse IDE.
If you try to build the project with Maven from a shell, you will notice that the dependency inheritance is honored, even without test.module1 having a pom file and the build succeeds.
So the current state is: CLI Maven build is working, but Eclipse IDE cannot resolve the dependencies correctly making development a bit of a mess.
Is there a way around this, or will I just have to create a pom file for those specific modules?
I'm developing library with Maven system, which is published in the Nexus repository.
In the nexus (and the maven build as well), the project produces the final jar named <projectName>-<version>.jar - this is exactly what I want.
Now, I decided to split the library into maven modules and therefore top level pom.xml have <packaging>pom</packaging>. The build also do not produce final <projectName>-<version>.jar, instead it produces <moduleName>-<version>.jar for each module.
What I want to achieve is to have the project split into modules and be able to produce final <projectName>-<version>.jar containing defined modules. Is this possible?
Is it possible to solve this issue migrating to the Gradle?
When you decided to split the library into multi modules it means that you decided to build them independently. So it's expected that each module creates it's own <moduleName>-<version>.jar.
Now when you use the created modules as dependencies for the bigger module with scope of compile maven would automatically add them to lib of the project.
So in your case you don't need to change packaging to pom and just add the modules as dependency in the pom.xml file and let maven to create the final jar for you.
Also if you want use pom packaging there is a good question here which might help you.
I am converting my simple working web application (runs from eclipse) to a maven project. This is my first maven project. I have 3 external jar dependencies to it and i added then to the pom.xml my build is failing saying that it can't find those 3 dependencies. here my pom.xml file
The build is saying that the 3 packages does not exist.
package javax.servlet does not exist
package org.apache.commons.codec.binary does not exist
package org.apache.commons.configuration does not exist
What i am missing? I am running my application from Mac and in the .m2/repository i see these 3 libraries/packages present.
You need to either remove the dependencyManagement tags that surround dependencies or add the dependencies again but nested within the project tag, i.e. at the same level as dependencyManagement.
dependencyManagement allows you to fix information about dependencies across a multi-module project - e.g. like version numbers - however you still need to provide a dependencies section alongside that so that Maven knows to include them.
If your project is not a multi-module project I would be tempted to not use a dependencyManagement section at all.
Just remove dependecyManagement tags
I was given a maven project to compile and get deployed on a tomcat server. I have never used maven before today, but I have been googling quite a bit. It seems like the top level pom.xml files in this project have the packaging type set as pom.
What am I supposed to do after mvn install to get this application deployed? I was expecting to be able to find a war file somewhere or something, but I guess I am looking in the wrong place or missing a step.
pom is basically a container of submodules, each submodule is represented by a subdirectory in the same directory as pom.xml with pom packaging.
Somewhere, nested within the project structure you will find artifacts (modules) with war packaging. Maven generally builds everything into /target subdirectories of each module. So after mvn install look into target subdirectory in a module with war packaging.
Of course:
$ find . -iname "*.war"
works equally well ;-).
pom packaging is simply a specification that states the primary artifact is not a war or jar, but the pom.xml itself.
Often it is used in conjunction with "modules" which are typically contained in sub-directories of the project in question; however, it may also be used in certain scenarios where no primary binary was meant to be built, all the other important artifacts have been declared as secondary artifacts
Think of a "documentation" project, the primary artifact might be a PDF, but it's already built, and the work to declare it as a secondary artifact might be desired over the configuration to tell maven how to build a PDF that doesn't need compiled.
Packaging of pom is used in projects that aggregate other projects, and in projects whose only useful output is an attached artifact from some plugin. In your case, I'd guess that your top-level pom includes <modules>...</modules> to aggregate other directories, and the actual output is the result of one of the other (probably sub-) directories. It will, if coded sensibly for this purpose, have a packaging of war.
To simply answer your question when you do a mvn:install, maven will create a packaged artifact based on (packaging attribute in pom.xml), After you run your maven install you can find the file with .package extension
In target directory of the project workspace
Also where your maven 2 local repository is search for (.m2/respository) on your box, Your artifact is listed in .m2 repository under (groupId/artifactId/artifactId-version.packaging) directory
If you look under the directory you will find packaged extension file and also pom extension (pom extension is basically the pom.xml used to generate this package)
If your maven project is multi-module each module will two files as described above except for the top level project that will only have a pom
Packaging an artifact as POM means that it has a very simple lifecycle
package -> install -> deploy
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
This is useful if you are deploying a pom.xml file or a project that doesn't fit with the other packaging types.
We use pom packaging for many of our projects and bind extra phases and goals as appropriate.
For example some of our applications use:
prepare-package -> test -> package -> install -> deploy
When you mvn install the application it should add it to your locally .m2 repository. To publish elsewhere you will need to set up correct distribution management information. You may also need to use the maven builder helper plugin, if artifacts aren't automatically attached to by Maven.
I suggest to see the classic example at: http://maven.apache.org/guides/getting-started/index.html#How_do_I_build_more_than_one_project_at_once
Here my-webapp is web project, which depends on the code at my-app project. So to bundle two projects in one, we have top level pom.xml which mentions which are the projects (modules as per maven terminology) to be bundled finally. Such top level pom.xml can use pom packaging.
my-webapp can have war packaging and can have dependency on my-app. my-app can have jar packaging.
“pom” packaging is nothing but the container, which contains other packages/modules like jar, war, and ear.
if you perform any operation on outer package/container like mvn clean compile install. then inner packages/modules also get clean compile install.
no need to perform a separate operation for each package/module.
Real life use case
At a Java-heavy company we had a python project that needed to go into a Nexus artifact repository. Python doesn't really have binaries, so simply just wanted to .tar or .zip the python files and push. The repo already had maven integration, so we used <packaging>pom</packaging> designator with the maven assembly plugin to package the python project as a .zip and upload it.
The steps are outlined in this SO post
https://maven.apache.org/pom.html
The packaging type required to be pom for parent and aggregation (multi-module) projects. These types define the goals bound to a set of lifecycle stages. For example, if packaging is jar, then the package phase will execute the jar:jar goal. If the packaging is pom, the goal executed will be site:attach-descriptor
POM(Project Object Model) is nothing but the automation script for building the project,we can write the automation script in XML,
the building script files are named diffrenetly in different Automation tools
like we call build.xml in ANT,pom.xml in MAVEN
MAVEN can packages jars,wars, ears and POM which new thing to all of us
if you want check WHAT IS POM.XML