I'm trying to write a Maven plugin, following the documentation. When I try to build I get:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-plugin-plugin:2.9:descriptor
(default-descriptor) on project cmake-dependency-plugin: Error
extracting plugin descriptor: 'No mojo definitions were found for
plugin: com.iar:cmake-dependency-plugin.' -> [Help 1]
Google points me to this Jira issue, which, if I read it correctly means that annotations do not work in maven unless a rather cumbersome workaround is employed (which, by the way, did not work for me).
What bothers me more is that it seems to be closed due to some form of Jira-bankruptcy executed by the Maven developers where a bunch of Jira issues have been summarily closed. Since this seems like the primary way to write Maven plugins, I would think that this would be pretty important, but I'm obviously missing something.
Am I misinterpreting the issue, or are maven annotations really broken?
EDIT: This seems to refer to the same problem, but I would be interested to know more details about why such a seemingly central feature can be left broken like this. Aren't Maven annotations used by Maven plugin developers?
First you are using an old maven-plugin-plugin version 2.9 from 2011...I assume you are working with Maven 3.X and so i would recommend to use an up-to-date version like 3.2. and follow the steps described in the JIRA issue.
Furthermore i would recommend to read the documentation about maven-plugin-plugin where clearly stated that starting with version 3.0 you can use annotations.
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-plugin-plugin</artifactId>
<configuration>
<goalPrefix>XYZ</goalPrefix>
</configuration>
<executions>
<execution>
<id>default-descriptor</id>
<goals>
<goal>descriptor</goal>
</goals>
<phase>process-classes</phase>
</execution>
<execution>
<id>help-descriptor</id>
<goals>
<goal>helpmojo</goal>
</goals>
<phase>process-classes</phase>
</execution>
</executions>
</plugin>
Related
I managed to build a Maven project in a way that makes the release deploy artifacts either double or not at all.
Since the project uses an abstract parent pom of our company it's a bit hard to post the relevant code, but I'll try.
First things first. The parent pom has the following definition:
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.8.2</version>
<configuration>
<deployAtEnd>true</deployAtEnd>
</configuration>
</plugin>
With nothing defined in the actual project, the release will fail after these lines:
[INFO] [INFO] Uploaded to our_repo: http://acme.org/nexus/content/repositories/org.acme.project/1.0.0/org.acme.project-1.0.0-sources.jar (14 kB at 3.8 kB/s)
[INFO] [INFO] Uploading to our_repo: http://acme.org/nexus/content/repositories/org.acme.project/1.0.0/org.acme.project-1.0.0-sources.jar
Our repo doesn't like having two release JARs with the same version, so everything fails. The weird part here is that the deployment is NOT at the end. In fact the project build fails halfway through.
However if I copy the above plug-in in the project, the build will print Deploying repo:org.acme.repo:1.0.0 at end at the same position and then not deploy anothing at the end.
But I'm not even sure that's part of the problem. Still I think both builds should work exactly the same no matter where the plug-in definition is.
I found this question, which made me check the maven-source-plugin in the effective pom. However there are no duplicates there:
<plugin>
<artifactId>maven-source-plugin</artifactId>
<version>3.0.1</version>
<executions>
<execution>
<id>attach-sources</id>
<goals>
<goal>jar-no-fork</goal>
</goals>
<configuration>...</configuration>
</execution>
</executions>
</plugin>
Nothing is defined in the maven-assembly-plugin either, so no JAR is added for deployment (suggested in this question).
It might have to do with us using Java 10 or Maven 3.5.2, though I'm honestly stumped on what to test and where to progress.
How do I fix this mess? (If you'd like more information about the build, just ask. The pom.xml is way to big to share them here.)
Inspired by that question I tried to disable the release profile, and now it works somehow. I'm not able to conjure any kind of explanation for that behavior.
Snippet for removing the release profile:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<configuration>
<useReleaseProfile>false</useReleaseProfile>
</configuration>
</plugin>
Is it possible to specify in a POM the minimum version of Maven required to build the project?
We've been wasting lots of time chasing issues from people building our project due to bugs in older versions of Maven that cause large artifacts (>2GB) to be silently truncated. These tend to cause, unsurprisingly, strange and broken behavior in the final product.
Yes, we have stated that 3.2.5 is the minimum version we intend to support, but I'm wondering: Is there a way to ask Maven to bail if the version is less than that? I reckon I can easily write a plugin to do this, but that seems overkill. So, I was hoping there is a simpler way.
You can use the maven-enforcer-plugin and its enforce goal to specify a minimum required Maven version:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.4.1</version>
<executions>
<execution>
<id>enforce-maven</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireMavenVersion>
<version>3.2.5</version>
</requireMavenVersion>
</rules>
</configuration>
</execution>
</executions>
</plugin>
If someone tries to build the project with a Maven version less than 3.2.5, the build will fail.
You can enforce a lot of different rules with this plugin (Java version, OS...); see the complete list on the plugin documentation.
If you only need the maven version the prerequisites should already do the job:
see: https://maven.apache.org/pom.html#Prerequisites
Anything more than that will require the enforcer plugin (see other answer).
I recently started using maven. so this question might sound basic.
This question came up when I was browsing through some code using cargo plug-in.
In the following snippet of maven plugin in pom.xml, that i extracted from here,
my understanding is as follows:
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<executions>
<execution>
<id>start-container</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start</goal>
</goals>
</execution>
<execution>
<id>stop-container</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
<configuration>
[Cargo plugin configuration goes in here]
</configuration>
</plugin>
This plug in bound to pre-integration-test and post-integration-test phase of build LifeCycle, which also means when I run mvn install this will be executed.
The goals (start and stop) of this plug-in gets executed during these phases respectively
Q1:: Does the <id>start-container</id> has any relevance? what's its purpose & importance?
Q2:: How do I know what are the different goals available for a plug-in. In this case for cargo plug-in I see in one of the codes in my work, <goal>redeploy</goal> is used. so I am wondering how to find information on these specific goals and other goals available. I did look at online documentation. I did not find any. possible that I did not search in the right place.
A1: the id doesn't change how the execution works, it's just a way of giving it a name.
A2: The best way is to read the documentation. Maven3 is also considerably better than maven2 in this aspect. If you call a plugin with an invalid goal, it will print out all the valid goals, but it won't print what are the different parameters that can be passed to the plugin (and some plugins use different parameter names for command line and pom parameters)
The documentation of cargo is a bit odd, most other plugins have their documentation set up in a different way, which makes it easier to find the goals and the parameters that can be set.
By the way, both your points 1 and 2 are correct.
I have a Maven plugin which is a year or two old. Recently I noticed that the helpmojo goal of maven-plugin-plugin appears to not be working.
It is working for an older version of the plugin - I'm not sure at which release it stopped working.
By "not working" I mean that the help goal is not correctly generated and is not found when called using mvn <plugin>:help, whilst other goals are found.
HelpMojo.java is created under target/generated-sources/plugin, but no entry appears in the the plugin descriptor, plugin.xml in the final .jar.
Has a bug or breaking change been introduced in a recent version of maven-plugin-plugin or have I changed something which has prevented it from working as a side-effect? (For example, the plugin project is now multi-module.)
The pom.xml config looks like this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-plugin-plugin</artifactId>
<version>3.2</version>
<executions>
<execution>
<id>generated-helpmojo</id>
<goals>
<goal>helpmojo</goal>
</goals>
</execution>
</executions>
</plugin>
The fix was to downgrade to version 3.1
I am trying to integrate CodeNarc with a Maven-based Groovy project. The documentation on the site for the CodeNarc Maven plugin is minimal. The usage aspects I am trying to understand are:
How to point to the custom rule sets and where in the project to place them?
How to fail the Jenkins build if any of the rules are violated.
Currently I am able to run CodeNarc using command
mvn codenarc:codenarc
When I add the 'reporting' section to the POM file (as described at http://www.mojohaus.org/codenarc-maven-plugin/usage.html) and run
mvn site
no CodeNarc report is generated. I get this warning
[WARNING] No URL defined for the project - decoration links will not
be resolved
but it is not clear where it is related to CodeNarc.
What is the proper way of using CodeNarc with Maven?
I just did it, in case you still need the tip. You can hook the execution of the plugin by creating a "plugin" entry under "build"->"plugins"->"plugin". Here is what I have.
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>codenarc-maven-plugin</artifactId>
<version>0.18-1</version>
<configuration>
<sourceDirectory>${project.basedir}/src/main/groovy</sourceDirectory>
<maxPriority1Violations>0</maxPriority1Violations>
<maxPriority2Violations>0</maxPriority2Violations>
<maxPriority3Violations>0</maxPriority3Violations>
</configuration>
<executions>
<execution>
<phase>prepare-package</phase>
<goals>
<goal>codenarc</goal>
</goals>
</execution>
</executions>
</plugin>
...
</plugins>
</build>
Note the "maxPriority_Violations" values. This is what makes the build fail in case of violations.
I dont use any custom rules, but it seems you can define your own rules by setting the "rulesetfiles" configuration option. See configuration options here: http://www.mojohaus.org/codenarc-maven-plugin/codenarc-mojo.html
Example of project with this configuration: https://github.com/tveronezi/faceid/tree/master/faceid-web