I'm playing with maven plugins, specifically i'm trying to develop a custom maven plugin for eclipse. All goes well, it builds from console ... etc until:`
"Plugin execution not covered by lifecycle configuration"
appears. I research and find this:
http://wiki.eclipse.org/M2E_plugin_execution_not_covered;
obviously i do not want to ignore the plugin's execution, the execute instruction does not seem to work, as for the delegate to project configurator, i am not able to find
AbstractJavaProjectConfigurator.java.
I've searched in org.eclipse.jdt , core and source but there is no reference to what i am searching, best match i could find was here:
http://git.eclipse.org/c/m2e/m2e-core.git/tree/org.eclipse.m2e.jdt/src/org/eclipse/m2e/jdt
All in one, what i want to achive is this: "Starting with m2e 1.1, maven plugin developers are able to provide lifecycle mapping metadata as part of the plugin itself." as stated in the first link i inserted. Any help would be greatly appreciated.
To simply bypass the mojo execution or telling m2e to simply execute your mojo via maven embedder you need the following:
a proper lifecycle mapping as explained in your link. Reference: https://github.com/php-maven/maven-php-plugin/blob/master/ide-plugins/eclipse/tags/2.0.3/org.phpmaven.eclipse.core/lifecycle-mapping-metadata.xml
However I put it in the root of the eclipse project to be able to debug it (finding those extra resources sometimes failes if you put them in src folders).
A build properties to embedd it into build: https://github.com/php-maven/maven-php-plugin/blob/master/ide-plugins/eclipse/tags/2.0.3/org.phpmaven.eclipse.core/build.properties
Activation via dependencies and extension:
Hope this helps. I was confused about the project configurator too. But the above example does not require any project configurator.
Related
Which maven build lifecycle phase is executed by clicking the " load maven changes " in intelliJ (you know, the little m letter that pops up each time you change something in the pom).
Cheers!
Well, thats a tricky question.
IDEA get project model using maven components classes, during import it does not execute maven goals per se.
IDEA loads maven libraries, injects into maven process, and calls maven classes directly.
In short words, at first IDEA reads project model (using
org.apache.maven.model.io.ModelReader class, I don't know if exact lifecycle exists)
Then dependencies and plugins resolved (well, again using maven classes directly, but this could be mapped to dependency:resolve). You can look implementation at org.jetbrains.idea.maven.server.Maven3XServerEmbedder
To generate sources, phase which set in File | Settings | Build, Execution, Deployment | Build Tools | Maven | Importing |Phase to be used for folders update used
Frameworks detection/compiler settings/language level/artifacts configuration/etc, are not taken from maven execution at all. For such things IDEA read pom.xml files using own parser.
But what do to want to achieve? If you describe your issue and what do you want to get in result, I'll try to help you find a solution.
Not a complete answer but for illustration a screenshot from IJ 2020.2.4. Guessing from the text "Analyzing..." showing up when clicking the "m" IntelliJ performs a mvn dependency:analyze using Maven dependency plugin.
[]
I've been working with the release plugin, but am trying to automate its solution a little for our needs.
At the moment, all our builds run the following command:
mvn clean initialize release:prepare release:perform
While that's functional, it's not as concise as I would like it. I have a few plugins defined in my super-pom which are activated during the initialize phase and are required before the release plugin is run. Ideally, I would like to see my command as something like:
mvn doMyRelease
which in turn calls the necessary phases/goals of the different plugins.
Additionally, I'd like to create a phase called doMyStage which would do the following:
mvn clean initialize release:prepare release:stage
I figure that a custom plugin with a custom lifecycle is the way to go about this, but I am confused how to accomplish this. From what I read, the lifecycle is mapped to the packaging type. I do not wish to change the packaging type of any of my projects (as their packaging remains correct), but rather just provide a shortcut for the build command line.
I'm also having trouble finding a good tutorial/working maven 3 example for this concept. Most examples I see all refer to a components.xml file, but I read that this has been replaced with a default-bindings.xml descriptor in Maven 3.
I found this article https://developer.jboss.org/wiki/CreatingaCustomLifecycleinMaven?_sscc=t which touches a little on the issue, but like most examples, it requires changing the packaging type to match the lifecycle hint.
Is there a way to accomplish this?
I'm reading about Gradle's detached dependency configurations and the API docs' method description says "Creates a configuration, but does not add it to this container". What I'd like to know is
Why would I want to do this?
At what point would I then re-attach this dependency configuration?
Some initial searching revealed a plugin related reason but this was not conclusive.
To summarise what was mentioned here and in my own question on the Gradle forums the reason for using detached configurations is : Resolve artifacts in a general way for dependencies not declared in the build file.
For example, as mentioned by Al Jacinto above, for a plugin you would not want to "pollute" the project using the plugin with irrelevant dependencies. This would also prevent the project using the plugin from interfering with those plugin dependencies.
There's link in that post http://discuss.gradle.org/t/modify-dependencies-of-plugin-checkstyle-configurations/5969 The guy is complaining that the plugin configuration polluting the project configuration and he has to explicitly exclude it.
Second answer to you question, don't need to reattach. I guess it is just detached to the project but still available for the plugin.
I have set up Sonar with MySQL Database. My project is a multi module eclipse project, which means it has multiple plugins.
I have set up a Jenkins build with Maven to build this project and also installed Jenkins Sonar plugin to analyse the code with sonar.
All the configurations seem to be correct. However, when sonar tries to analyse this project after the build, it complains of duplicate source code and the build fails.
Each eclipse plugin has Activator.java class and Sonar complains that this is duplicate. I have excluded this class from analysis, but Sonar complains of classes in a particular plugin that is added as a dependency to lot other plugins.
Incomplete analysis of the code leads to other issues in Sonar for this project. like, even though the project is visible in the Sonar dashboard, it asks for authentication again on clicking the project, even though I am logged in as admin.
Any inputs on pointing me to the right direction would be very helpful.
Please let me know if any additional inputs are necessary to better understand my problem.
IMO, the best example you can follow is our Sonar Eclipse project: https://github.com/SonarSource/sonar-eclipse. This is also a multi-module Eclipse project.
In this example, you want to have a look at the parent module (https://github.com/SonarSource/sonar-eclipse/tree/master/org.sonar.ide.eclipse.parent) which goal is only to define the parent POM. Almost everything happens there.
I guess that you should find your way thanks to this.
I was able to fix this issue by removing the test tag in the parent pom.xml. This was somehow causing sonar to throw the duplicate source error. It was a tedious task to figure out the root cause and I had to reconstruct pom.xml from scratch, adding section by section.
Thanks to all for the help.
There is a section in the pom.xml file that requires the Maven-Replacer-Plugin and (I believe) GitDescribe.
Here are the errors it gives me:
Plugin execution not covered by lifecycle configuration: com.lukegb.mojo:gitdescribe-maven-plugin:1.3:gitdescribe (execution: default, phase: compile)
Plugin execution not covered by lifecycle configuration: com.google.code.maven-replacer-plugin:maven-replacer-plugin:1.3.8:replace (execution: default, phase: generate-resources)
This message comes up because m2e doesn't know what to do at this phase. The build should work with command line maven, but m2e wants you to specify whether you want it to run the plugin or not.
The fix depends on what you want to happen. You can either have eclipse ignore the plugin or execute it as part of the build.
The documentation explains it in further detail here, but I'm copying the easy answer below.
https://www.eclipse.org/m2e/documentation/m2e-execution-not-covered.html
This changes the pom to add some eclipse metadata. If you're just trying to get it to build this will work.
HINT: Use quick fix to create “ignore” mapping, then replace
action with . M2Eclipse 1.3 and newer assume safer
runOnIncremental=false by default. It is recommended to always
specific desired runOnIncremental value explicitly in lifecycle
mapping configuration.
You can also change your preferences in newer eclipse/m2e versions. It's the other quick fix option. You can change this one under Project Properties->Maven->Lifecycle Mapping.
This error was well described in their documentation.
This feature was added in M2Eclipse 1.0 (now m2e).
It caused much trouble, like reported in this blog post.
One solution was to pollute the pom.xml with data about the plugin lifecycle mapping metadata, but it was not very satisfying.
In m2e 1.1, plugin developers could embed a file named lifecycle-mapping-metadata.xml in their plugins to make it work in Eclipse (see M2E compatible maven plugins).
Fortunately, since m2e 1.2, things have evolved and we can now configure it in Eclipse Preferences (see Eclipse workspace lifecycle mapping metadata).