Jenkins: maven release plugin ignores dependency classifier - jenkins

I want to release a module via Jenkins that uses a dependency which is not only distinguished by its version but also by a custom classifier passed as a system property at build time. The effective pom printed in the console output shows that the correct classifier is used
<dependency>
<groupId>de.test</groupId>
<artifactId>common-module</artifactId>
<version>0.0.4-SNAPSHOT</version>
<classifier>custom</classifier>
<scope>provided</scope>
</dependency>
However, when the release plugins' prepare goal runs, the build breaks due to a compilation error because of missing classes which are only available in the dependency version that uses the custom classifier. Printing the properties with the maven-antrun-plugin reveals that the release plugin is using the version without classifier.
[INFO] [echoproperties] de.test\:common-module\:jar=/var/lib/****/.m2/repository/de/test/common-module/0.0.4-SNAPSHOT/common-module-0.0.4-SNAPSHOT.jar
[INFO] [echoproperties] maven.dependency.de.test.common-module.jar.path=/var/lib/****/.m2/repository/de/test/common-module/0.0.4-SNAPSHOT/common-module-0.0.4-SNAPSHOT.jar
I would expect the release plugin to pickup the jar named common-module-0.0.4-SNAPSHOT-custom.jar which is definitely available in the maven repository. Doesn't the release plugin support classifiers?

Problem solved. I found out that there are two issues. First, the module was also part of a transitive dependency, so maven tried to download a version without classifier that doesn't exist prior to the version containing the classifier. Second, the classifier was not passed to the maven release plugin. To pass system variables to the plugin one has to use the arguments option, so the actual command should be clean install -Darguments="-Dmy-classifier=custom" -Dmy-classifier=custom -B release:prepare release:perform. The system variable declaration must be redundant, one for the pom dependency and another for the release plugin.

Related

How to set up a version-consistent environment for compiling with Lombok and Tycho

I am using Lombok in my Tycho builds. I have a local copy of the lombok jar file on disk and point to it using jvm.config. It looks like this:
-javaagent:.mvn/lib/lombok-1.18.20.jar=ECJ
This works well, but contains a concrete version number, which can fall out of sync with the one used in the Maven build.
My question is: Is there a way to use a single version number from the Tycho environment (POM or target) to configure the lombok compiler and annotation library?

Sonar warnings due to unresolvable dependencies

Our project is a multi module plugin project built using maven. The Sonar analysis runs fine but in the process generates a lot of warnings and probably incorrect results. Below is the set up of the project and warnings generated during analysis. Any help in fixing these warnings is highly appreciated.
Project setup:
Sonar analysis via the jenkins build.
Jenkins Sonar plugin is used to run the analysis.
Jenkins and Sonar along with MySQL are running on different machines.
Below properties are provided to Sonar plugin in Jenkins during sonar analysis.
-Dsonar.profile="My Project Profile"
-Dsonar.dynamicAnalysis=reuseReports
-Dsonar.core.codeCoveragePlugin=jacoco
-Dsonar.jacoco.reportPath=../../releng/com.mycompany.myproject.releng.builds/coverage_data/jacoco.exec
Below are the warnings generated during analysis:
Note: The below warnings are not generated if Sonar and Jenkins are running in the same machine
Before the Sonar analysis of individual modules the following error is thrown.
[WARNING] The following dependencies could not be resolved at this point of the build but seem to be part of the reactor:
15:04:52 [WARNING] o com.mycompany.myproject.plugins:com.mycompany.myproject.external.libraries:jar:1.0.0-SNAPSHOT (provided)
15:04:52 [WARNING] Try running the build up to the lifecycle phase "package"
15:04:52 [WARNING] The following dependencies could not be resolved at this point of the build but seem to be part of the reactor:
15:04:52 [WARNING] o com.mycompany.myproject.plugins:com.mycompany.myproject.somefunctionality.framework:jar:1.0.0-SNAPSHOT (provided)
During the analysis of the modules, it throws the following warning
Class 'com/mycompany/myproject/core/common/datatransfers/MyClass' is not accessible through the ClassLoader.
[WARN] [15:05:25.731] Class 'com/mycompany/myproject/core/common/datatransfers/MyClass' is not accessible through the ClassLoader.
Almost all modules are marked as skipped after the analysis after the build is complete, However the analysis results are available in Sonar.
[INFO] com.mycompany.myproject.platform.feature ................ SKIPPED
[INFO] com.mycompany.myproject.somefeature.feature ... SKIPPED
[INFO] My Product ............................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
I know this is a late reply, but I had the same problem and it turned out that I had run mvn clean package instead of mvn clean install. I found this thread on the SonarQube mailing list, hope this helps.
This warning may simply due to a race condition in plugins such as maven-jar-plugin (I had the same warning in another Sonar unrelated case with Maven 3.6.3).
Let's consider the following project layout:
acme-parent parent for all project
acme-aggregator
acme-common
acme-p1 depends on acme-common
acme-p2 depends on acme-common
acme-p3 depends on acme-common
acme-p4 depends on acme-p2 and acme-p3
Maven will build in this order:
acme-parent
acme-common
acme-p1, acme-p2, acme-p3 and acme-p4
However, for the internal machinery, it is another story:
acme-p2 and acme-p3 are not in the local repository
all are in the reactor
during invocation of a plugin in acme-p1, maven will validate the artifact found in the reactor and will try to resolve path of local artifact but fail (hence the warning).
If you move acme-p4 before acme-p1, this change the build order: the warning goes away (note: the dependencies needs to be removed from local repository) because now, acme-p2 and acme-p3 are effectively built before acme-p1.
Maven will build in this order:
acme-parent
acme-common
acme-p2, acme-p3, acme-p4 and acme-p1
There are some fixes:
Adding a dependency from acme-p4 to acme-p1: this will enforce the build order at the cost of extra care (in my real use case, acme-p4 packages acme-p2 and acme-p3 using maven-assembly-plugin).
Reorder project in reactor: I did not test that with the -T options, allowing concurrent build, but I think it may also fail.
Do a package build: it is mentioned by the warning, but I suspect that Maven will in some case reference an artifact in the local repository or in the remote repository (if you deploy SNAPSHOT on them). This may be tricky: if someone change the signature of a method, then Maven may download the SNAPSHOT (it is newer, and it is NOT in the reactor, therefore it is better than the local repo) and the build may fail (this is purely my hypothesis).
This may also be an error in Maven in how it order module in the reactor.

How to skip building of the pom in multi-module project

I'm trying to optimize my build process (in development) in term of time to build the whole tree of maven multi-module project. Some of the POM are actually aggregation of sources/libraries that rarelly (and typically) never change. So specific sub-questions are
Is it possible to somehow configure maven to not build pom if there are no changes in sources specified in POM:project/build/sourceDirectory attribute?
Or is it possible to (at least) conditionally disable maven-bundle-plugin? - it takes most of the time.
Google could not find anything relevant Q#1. Typical solution does not work for #2 - when i try to specify 'executions' for maven-bundle-plugin (like this)
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>${maven-bundle-plugin.version}</version>
<extensions>true</extensions>
<executions>
<execution>
<id>osgi-bundle</id>
<phase>bundle</phase>
<goals>
<goal>bundle</goal>
</goals>
i receive this error in output
[bundle:bundle]
Bundle artifact-id:bundle-id:bundle:0.1.0-SNAPSHOT : The JAR is empty: dot
Error(s) found in bundle configuration
Any help is appreciated. I'm aware about following:
* Disable a Maven plugin defined in a parent POM
(maven-bundle-plugin can't work with 'executions' tag)
* Skip execution of a maven plugin if a file does not exist (maven-bundle-plugin does not have skip confiuration option)
* How to skip lifecycle phase in multi maven module (the same as previous)
* If entire maven-bundle-plugin is moved into profile, maven does not recognize packaging=bundle.
Finally I have to admit that (C) Eugene Kuleshov - "Maven generally don't track sources/changes, so it is always a full build."
But, returning back to Java after 5+ on .NET and 5+ years erlier on C++, it looks weird for me that such a common feature like incremental build is not support by widely used tool having a history of 10+ years. So I could not spend my time on waiting to rebuild each and every unchanged module in my multi-module project and decided to make customized version of Maven 3.0.4 :)
Feel free to grab it here http://code.google.com/p/maven-onchange-activator/, try and report issues.
Maven generally don't track sources/changes, so it is always a full build. However to disable any plugin you could move it into profile and then enable/disable the whole profile, e.g. either conditionally or from the command line.
You should check things like
mvn -am
in relationship with
mvn -pl ...
so doing a build like:
mvn -am -pl SubModule clean package
will build only those modules which have been changed and which needed to be built as a result of a dependency to the change module.
I would suggest switching to Gradle.
Gradle has such support out of the box (no configuration needed) and conversion from Maven should be easy.

Maven 3 Parallel build Projects Skipped

Does anybody know of any reason why some of my projects are marked as SKIPPED at the end of a successful maven build?
please note that the 'skip chain' always starts with my web project which includes the following features:
jspc-maven-plugin
war plugin with overlay
maven-dependency-plugin
It could be due to OutOfMemoryError's inside Maven. We had similar problem with Maven skipping half of the modules. Increasing memory for Maven process itself solved the issue. I don't know if it is specific to some particular plugin behaving bad or to the Maven core.

Can we use pom.xml into ANT

I know that, we can very well use ANT and Maven together to build the project.We can run ANT scripts through Maven's POM.xml. But my question is can we run pom.xml through ANT's build.xml ?
i.e. can we create maven build from build.xml
Yes, using maven ant tasks.
The page lists out multiple maven tasks which can be integrated into an ant build script, thus combining the features of both. To take an example, there is the mvn task, which as documented can do a full maven build from ant.
<artifact:mvn mavenHome="/path/to/maven-3.0.x">
<arg value="install"/>
</artifact:mvn>
Besides this, there are
Dependencies task
Install and Deploy tasks
Pom task
each described with examples.
Maven and ANT are very different build tools. In ANT you write all the logic yourself, whereas a standard build process is "baked in" with Maven.
The POM file contains no logic, instead it contains a series of declarations about your project.
If you understand well how Maven works, it is theoretically possible to take a POM and generate an ANT build that emulates the behaviour of the Maven build. I'm not aware of any solution which can easily convert in the other direction, mainly because ANT is missing Maven functionality, such as dependency management.
Instead of trying to convert an ANT build into Maven, I'd recommend that you keep your existing build logic and delegate the management of your classpath to the ivy or Maven ANT tasks. These tools also provide tasks to publish your build output to a Maven repository, enabling your project to share with other projects using Maven.
Finally, I'm an ivy advocate and wrote an ant2ivy script which can assist in upgrade process. It creates an initial set of configuration files for downloading your projects dependencies from the Maven central repository.

Resources