Say a Maven project has a cool build plugin configured:
<project>
...
<build>
... extensions etc.
</build>
...
</project>
I want this configuration to be reusable, so that I can run the goals provided by the plugins/extensions in any new project. The above project might exist just so that other projects can reuse the config.
What is the best way to achieve this?
Use a parent.pom. Deploy this pom to your local repository. Of course you could configure parent.poms for each type of project that you regularly develop in your organisation. Probably a master.pom with general values (location of servers, organisation name, general code style...) is a good idea. The project specific poms would use this as parent.
Declare this pom.xml as of type pom:
<type>pom</type>
and declare it as a parent in every "child" pom.xml that needs the configured plugins: http://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Project_Inheritance
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.
In a multi module project structure as
myApp
|-moduleA
|---pom.xml
|-moduleB
|---pom.xml
|-pom.xml
If i have the following properties in the parent.pom
<properties>
<moduleA.version>4.67</moduleA.version>
<moduleB.version>4.68</moduleB.version>
</properties>
How can i access the properties in the parent pom from any of the child poms? I tried this on the child pom but it didnt work.
<groupId>com.test</groupId>
<artifactId>moduleA</artifactId>
<version>${moduleA.version}</version>
If you have a real multi-module build you should never define the modules to have different versions. They should have the same version which make releasing possible and other things as well. Otherwise you should not use the multi-module setup than use simple single modules which are separated.
This should work. One possible reason I can think of is that perhaps you don't actually inherit the pom where these properties are defined (i.e. it's not defined as your <parent> directly or indirectly), but you only have a main pom that aggregates your projects. It's a guess, though.
I have a maven project - it is a plugin for jenkins. It's parent should be a:
<parent>
<groupId>org.jenkins-ci.plugins</groupId>
<artifactId>plugin</artifactId>
<version>1.414</version>
</parent>
But at the same time this plugin can be also used for hudson, without changing any line of code. But the parent project for it should be:
<parent>
<groupId>org.jvnet.hudson.plugins</groupId>
<artifactId>hudson-plugin-parent</artifactId>
<version>2.0.1</version>
</parent>
Can I specify 2 different profiles for that and use them to build plugin for jenkins or hudson accordingly? So that I call something like that:
mvn package -P jenkins
or
mvn package -P hudson
I have tried to specify properties in profiles, but those are not replaced by their values inside the <parent> tag. So is there any other possibility to build plugin for both, but with as much as possible common code and files?
Added: So, if I cannot do that, what should I do then? How to refactor? What the new structure should be?
As already mentioned, this is not possible.
Also, it is not possible to set a property for the parent's version as the interpolation for that happens a lot earlier than the handling of the profiles.
I would suggest that you create a masterbuild project as follows:
master
|-plugin-jenkins
|-plugin-hudson
|-plugin-assembly
The master should build all three as usual. However, in the assembly, you could add each of the two plugins as dependencies in separate profiles. And... each of these plugins can have the parent you like.
This is obviously somewhat a deviation from the Maven convention, but I believe it is a solution to your problem.
It's not possible because the tag "parent" is not available in the profiles section of the pom.
Currently we decided to stick with 1 repository and 2 separate pom.xml files, giving maven key which pom.xml use to build the project.
mvn package -f pom-jenkins.xml
mvn package -f pom-hudson.xml
No you cannot do that. you will have to refactor somehow to avoid the necessity.
As mentioned already not possible. I would suggest to make separate projects for jenkins plugin and hudson plugin. I assume that in not that far future that will not work anymore cause Hudons and Jenkins will diverge.
In general, you should be able to set the {group,artifact}Id and version of the parent POM via Java System Properties or Environment Variables, but it seems there is a Bug in Maven which will only be fixed in 4.x:
https://issues.apache.org/jira/browse/MNG-624
Another solution is to delegate the inclusion of the parent POM to your own parent POMs which you reference in the relativePath element, and change the content of the target e.g. via a symlink or cp command.
So in the main POM you would write:
<parent>
<groupId>org.mycompany.project</groupId>
<artifactId>foo-artifact</artifactId>
<version>1.0.0</version>
<relativePath>./my-parent.pom</relativePath>
</parent>
And in my-parent-jenkins you would just put:
<groupId>org.mycompany.project</groupId>
<artifactId>foo-artifact</artifactId>
<version>1.0.0</version>
<parent>
<groupId>org.jenkins-ci.plugins</groupId>
<artifactId>plugin</artifactId>
<version>1.414</version>
</parent>
The same project information with the block for hudson you put in my-parent-hudson.pom.
No you can either use
ln -s my-parent-jenkins.pom my-parent.pom
or
ln -s my-parent-hudson.pom my-parent.pom
to include the respective parent POM without the need to maintain two different main POM files for your project.
In case POM does not exist at the place referenced in relativePath, Maven will look up the POM in the remote repository[1], which is also an easy way to overwrite a parent POM locally.
[1] http://maven.apache.org/components/ref/3.3.9/maven-model/maven.html#class_parent
We are adding new code to an existing project that uses a custom build system developed with Ant and Ivy for dependency management.
Our new team is used to Maven and its features like testing execution, cobertura reports, etc.
Our question is: is it viable to add a pom.xml matching the current project structure, but instruct Maven to load its classpath from the "lib" dir already filled by Ivy?
In other words: we want to use Maven without its dependency management.
One really dirty approach would be to generate one big jar from the libdir and config the pom.xml to include just that... but we believe there should be cleaner approach.
Any idea or recommendation?
Note: we are not interested in generating a pom.xml with dependencies from the Ivy config, we just want Maven to rely on Ivy's generated classpath. No need to discriminate between test/runtime/compile classpath.
This is our final setup to solve this:
For each Ivy legacy project, use ivy:makepom and manual inspection to figure out the dependencies that we need to send to the new projects (Maven-based). This is a one-time process for each project.
Modify the legacy build system in a way that, every time a project is built, the identified dependencies are also exported to a mvn repo. Because de build machine holds the internal repo, we just use mvn install.
In the new maven projects, declare each dependency in the pom.xml and make sure the build system runs maven builds after the legacy builds.
Thank you all for your help!
One possibility is to use the system scope to define your dependencies in maven. This allows maven to use the jars downloaded by ivy for its dependencies.
e.g.
<dependencies>
<dependency>
<groupId>group.id</groupId>
<artifactId>artifact</artifactId>
<version>a.b.c</version>
<scope>system</scope>
<systemPath>${basedir}/lib/artifact-a.b.c.jar</systemPath>
</dependency>
...
</dependencies>
Maybe the makepom task will be helpful, it creates a pom from the ivy file.
Example from that page:
<ivy:makepom ivyfile="${basedir}/path/to/ivy.xml" pomfile="${basedir}/path/to/module.pom" conf="default,runtime">
<mapping conf="default" scope="compile"/>
<mapping conf="runtime" scope="runtime"/>
<dependency group="com.acme" artifact="acme-logging" version="1.0" optional="true"/>
</ivy:makepom>
Upon each change commited to our svn, hudson initiates a maven build with the -amd -pl flags, to make only the changed projects. However, the project it compiles "a" is dependent on another project "b", and it fails while looking for "b" in maven repositories across the web. Half an hour later it does a full build and succeeds...
Maybe we've set up our maven dependencies wrong? We have several projects a,b,c and one "maven-parent" project who has only a pom.xml with this in it:
<project>
<artifactId>maven-parent</artifactId>
<packaging>pom</packaging>
<modules>
<module>../a</module>
<module>../b</module>
<module>../c</module>
</modules>
</project>
and the "a" project references "b" like so:
<project>
<artifactId>a</artifactId>
<packaging>jar</packaging>
...
<dependency>
<groupId>com.pursway</groupId>
<artifactId>plummet</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
</project>
Thanks!
Set up each project as a separate project in Hudson and use the Hudson configuration for downstream dependant projects to build whatever is necessary depending on the scm changes.
Perhaps you should try -am -pl. From mvn --help
-am,--also-make If project list is specified, also
build projects required by the
list
-amd,--also-make-dependents If project list is specified, also
build projects that depend on
projects on the list
You can specify what Raguram has pointed out in hudson project configuration. Under the build
option you can specify Maven Goals and options.
See that in image below
http://imageshack.us/photo/my-images/696/hudsonmaven.jpg/