If I have a POM that contains a dependency of type=POM, e.g.
<dependency>
<groupId>com.mycompany</groupId>
<artifactId>mysql-starter</artifactId>
<version>1.0</version>
<type>pom</type>
</dependency>
I see that the included POM can contain other dependencies, thus providing a way to package together a set of related dependencies.
Can the reference POM also contain build steps?
For example: Use the resource plugin to copy certain files that are needed when using the specific JAR mentioned in its dependencies.
Dependencies of type pom may contain some build configuration information (such as resources, plugins or pluginManagement) but any of them will be executed for the current project but if you configure the pom of the current project to invoke them.
In fact, only the current pom and the parent pom of the current project define in the build element the build information/taks of the current project.
Related
I have a parent project with around 20 child modules:
<project>
<modules>
<module>module-1</module>
<module>...</module>
<module>module-20</module>
</modules>
</project>
I would like to use this project as one single entity, with all 20 modules included, in other projects. What is the convenient way to do this in Maven?
Should I make a new child module which imports the other 20 modules and refer to this project? Should this be a JAR or a POM project?
<project>
<packaging>jar</packaging>
<dependencies>
<dependency>... module-1 ...</dependency>
<dependency>...</dependency>
<dependency>... module-20 ...</dependency>
</dependencies>
</project>
I think the way you mentioned in your question is a good idea. It is actually mentioned as a best practice in the Maven book, quoting:
If you have a set of dependencies which are logically grouped together. You can create a project with pom packaging that groups dependencies together.
You can create a new module called module-all, which would be of pom packaging, that simply has a dependency on each of the modules. The packaging should be pom because the primary artifact of this module will only be the pom.xml (there will be no sources to compile, no JAR...). Then, in your external projects, you can simply add a dependency to this new module (as <type>pom</type>) and every module-i dependencies will be included transitively.
There would be a cave-at if all of your modules did not share the same version: there would need to be a reference to a specific version of a specific module and you would have to update the module-all version each time a module's version changes. However, if they all share the same version, module-all release cycle would be in line with module-i's.
I would like to import properties from a project X pom file into my project Y pom such as library versions. I do not want to make the project X my project's parent.
I have tried to include project Xs pom in the dependency management section as an import.
<dependency>
<groupId>abc</groupId>
<artifactId>def</artifactId>
<version>1.1</version>
<type>pom</type>
<scope>import</scope>
</dependency>
Please advise.
Thanks.
I think, today, the answer is NO. You can't read properties from external dependency without inheritance.
However a hack can be done with the codehaus Properties Maven Plugin. In fact, it can load maven properties from an external file. It can even use classpath: URLs to load files from. So you might try to load those from another dependency (which should have an appropriate scope since you probably do not want that dependency's JAR to hang around at runtime).
The usual approach to share dependency versions without using parent POMs are BOMs.
These are separate projects that only contain a pom.xml which consists of <dependencyManagement>. This can then be imported in several other projects with <scope>import</scope>.
These other projects then import the dependencyManagement inside the BOM.
Basically, you need to create a parent pom which is imported by both projects.
The parent has a <dependencyManagement> section which lists groupId, artifactId and version
The child pom's only need to list groupId and artifactId since the version is inherited from the parent's <dependencyManagement> section
eg:
root/pom.xml - Builds all modules, a simple pom with a `<modules>` section which includes parent, project1 and project2
root/parent/pom.xml - This has a `<dependencyManagement>` section
root/project1/pom.xml - parent=../parent/pom.xml
root/project2/pom.xml - parent=../parent/pom.xml
More info here
I'm new to Maven, I try to use Maven with Spring, Hibernate in my project. After go though the Spring and Hibernate reference, I found that "there is no need to explicitly specify the dependent liberaries in POM.xml file for such Apache commons liberaries".
My questions is that : If my other parts of project refer to Apache commons liberary, such as commons-io, SHOULD I explicit specify this dependency in POM.xml file?
You should define those dependencies in Maven which your project is using. For example, even though some library depends on commons-io but if your code needs this then you should directly define commons-io in your pom.xml
You should not worry about the dependencies of the libraries you have defined in your pom.xml. Maven will do that for you.
Maven is used to avoid the issue of having to run down JAR files that are dependent on other JAR files. Of course you do not HAVE to use maven to do this, but you should. Maven will automatically download the dependent JAR files of the JAR file you require. THe hibernate-entity manager JAR file, for example, has over 100 dependencies and maven does the work for you.
Anyway,even if you do add the commons-io file to the build path/classpath of the maven project,and then update the project configuration, maven will kick it out.
You can provide a lib name on a site like mvnrepository.com to see what it depends on (e.g. take a look at a section called "This artifact depends on ..." in case of spring-webmvc library). Those dependencies (which your artifact depends on) are called transitive dependencies. You don't have to specify these in your pom.xml as maven will resolve them for you.
For the sake of readability you should only state those dependencies in your module that you rely on directly. You want JUnit to test your software, only declare JUnit; you need hibernate to use ORM, declare hibernate, and so on. Leave the rest to Maven.
And most of the time you should state what you intend to use in the very module you want to use it in. So if you want to use a dependency in more than one module, consider moving it into a dependencyManagement block in a parent pom and referencing it from there in the module you want it in.
parent pom.xml
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.10</version>
<scope>test</scope>
</dependency>
</dependencies>
</dependencyManagement>
child pom.xml
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
</dependencies>
This guarantees you version-stability and still allows you to find out what a module uses by only looking in it's pom (and not all over the place).
We deliver our package with many external dependencies to customers. Now customers can use you libraries to develop stuff on top. For those who are also using Maven we would like to include a pom.xml file in the assembly which contains all dependencies, so they can simply use it in their Maven build:
It should contain all dependencies used by us as follows:
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-math</artifactId>
<version>2.1</version>
<scope>compile</scope>
</dependency>
Is there a way to achieve that in Maven?
The pom.xml for your jar/war is by default placed inside your jar/war in the location META-INF\maven\<groupId>\<artifacdId>
You have two choices:
The first one which is the most common and preferred way is relying on Maven's transitive dependency resolution.
Have a POM (assume called foo-api:1.0) in your project that declares the dependency (e.g. A:1.0:jar, B:1.0:jar).
Developer's own project (bar:2.0) should then simply depends on foo-api:1.0. Maven will simply include A:1.0:jar and B:1.0:jar as dependency of bar:2.0, through the transitive dependency resolution.
Another way is similar to the above approach, but use foo-api:1.0 as parent POM of bar:2.0.
Either way should work but which one is suitable depends on your design.
I have a multi module project like this:
gwt-app
model
webapp (depends on gwt-app and model)
when I try to execute any goals in webapps, for example, launch jetty, build fails because maven can't find its dependencies (I didn't install modules into a local repo). Is there a possible way to reference the parent pom so that when I run any goals in a submodule, all its dependencies will be compiled (recompiled)?
An example of your pom files would be great but in multi module projects I always declare the dependencies in the parent pom in the dependencyManagement tag:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
<version>1.0</version>
</dependency>
...
In the module pom I just delcare the dependency without the version:
<dependencies>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
</dependency>
...
That way were are sure each module uses the same version.
The thing to remember is that modules in maven do not inherit dependencies from the parent. You must declare the dependencies used in the module itself.
Another thing is, I believe that when you are running outside of an IDE (which searches the workspace for dependencies) you need to have each module installed in your local repo. I do not think maven will search for un-installed dependencies within a multi module project if you are not executing on the parent pom.
If you make your parent pom just have regular setup like
<plugins>
</plugins>
<dependencies>
</dependencies>
Then anything in those groups are inherited automatically into the child pom. Child pom just needs the parent section in it:
<parent>
</parent>
You don't even need to declare the same plugins or dependencies in the child pom in this manner. You only need to list the plugins or dependencies in the child pom IF you use or in the parent pom OR you want to override something in the parent pom. I actually just went through all of this week and have my builds working nicely now (small child poms with more things in the parent pom like plugin configurations).
I asked a question about this that might help you:
Maven - Parent Pom - Child Inheritance