I am writing a plugin to Maven. I want to customize action depend on Maven version (person's who use my plugin)
something like:
if (MavenVer == "2.2.1")
//do some things
if (MavenVer == "3.0")
//do another things
I found out build-helper-maven-plugin but i'm not shure how to use it to do this job.
you need to inject maven reference into plugina and simply check version using API
http://maven.apache.org/ref/2.2.1/maven-project/apidocs/org/apache/maven/project/MavenProject.html#getVersion()
http://maven.apache.org/ref/3.0.3/maven-core/apidocs/org/apache/maven/project/MavenProject.html#getVersion()
code for injection
public class MyMojo extends AbstractMojo {
/**
* #component
*/
ArtifactFactory factory;
/**
* #component
*/
ArtifactResolver artifactResolver;
/**
* #parameter default-value="${project.remoteArtifactRepositories}"
*/
List remoteRepositories;
/**
* #parameter default-value="${localRepository}"
*/
ArtifactRepository localRepository;
/**
* #parameter default-value="${project}"
*/
MavenProject mavenProject;
I have been looking for an answer to your question and I have come to the conclusion that there is no simple way to get the maven version, or at least I couldn't find it. The best I was able to find is that the maven-enforcer-plugin contains code that looks up the maven version. However in looking at the maven-enforcer-plugin source code it is a little complicated and involves getting a handle to a RuntimeInformation instance through plexus (the IoC container used by Maven).
I recommend you take a look at the maven-enforcer-plugin and see if you can use what they did. Pay particular attention to RequireMavenVersion and EnforcerMojo classes.
Related
I want to create a settings plugin (not project plugin) to simplify some stuff, but I cannot get the configuration clause to work.
This is my plugin (Java code)
public class SettingsPlugin implements Plugin<Settings> {
#Override
public void apply(Settings target) {
target.getExtensions()
.create("modules", IncludeModulesExtension.class, target);
System.err.println("Applied settings plugin");
}
}
public class IncludeModulesExtension {
private final Settings _settings;
public IncludeModulesExtension(Settings settings) {
_settings = settings;
}
public void include(String path) {
}
}
My problem is, that gradle is not picking up the "modules" dynamic function in my settings.gradle.kts:
pluginManagement {
...
}
plugins {
id("com.ieffects.gradle-tools.settings-server") version ("7.0.23-SNAPSHOT")
}
modules {
}
I omitted the pluginManagement, the plugin is found and applied, however the "modules" is not picked up. What is it I'm doing wrong?
Starting Gradle Daemon...
Gradle Daemon started in 2 s 396 ms
Applied settings plugin
e: /Volumes/Development/Git/server-framework-galcon/settings.gradle.kts:22:1: Unresolved reference: modules
FAILURE: Build failed with an exception.
* Where:
Settings file '/Volumes/Development/Git/server-framework-galcon/settings.gradle.kts' line: 22
* What went wrong:
Script compilation error:
Line 22: modules {
^ Unresolved reference: modules
1 error
I faced the same issue when implementing a similar plugin, and although I didn't find out why, I did manage to work around it:
// SettingsExtensions.kt
import org.gradle.api.Action
import org.gradle.api.initialization.Settings
import org.gradle.api.plugins.ExtensionAware
/* WORKAROUND: for some reason a type-safe accessor is not generated for the extension,
* even though it is present in the extension container where the plugin is applied.
* This seems to work fine, and the extension methods are only available when the plugin
* is actually applied. */
/**
* Retrieves the [modules][IncludeModulesExtension]
* extension.
*/
val Settings.modules: IncludeModulesExtension
get() =
(this as ExtensionAware).extensions.getByName("modules") as IncludeModulesExtension
/**
* Configures the [modules][IncludeModulesExtension] extension.
*/
fun Settings.modules(configure: Action<IncludeModulesExtension>): Unit =
(this as ExtensionAware).extensions.configure("modules",
configure)
As the comment explains, it behaves exactly the same as a generated type-safe accessor (same syntax and the extension is only available when the plugin is actually applied).
I didn't test if it works for the Groovy DSL, but since the extension methods are syntactically identical to the generated accessors, I assume it does.
Alternatively you can do without if instead of the modules DSL you do this in the settings script where the plugin is applied:
configure<IncludeModulesExtension> {
...
}
This also works because even though the type-safe accessor is not generated, the extension is properly initialized and added to the extensions container. But the DSL is obviously nicer.
I would like to add a shortcut to a specific unit test from my class level comment. This way a developer can quickly navigate to a test within their IDE.
Using IntelliJ, I added the following to the class comment for "MyClass":
/**
* #see com.my.address.AnotherClass
* #see com.my.address.MyClassTests
* {#link com.my.address.MyClassTests#nameOfMyTest NameOfMyTest}
*/
IntelliJ presents this error for the two shortcuts that reference the tests:
Cannot resolve symbol 'com.my.address.MyClassTests' less... (⌘F1)
This inspection points out unresolved references inside javadoc
Is it possible to present a shortcut to a unit test from comment? If so, how?
--- additional info (Jan.28/2015) ---
This is my module setting in IntelliJ for this project:
Assuming they are in the same package you don't need the package name, but you do need a # between the class name and the method name:
{#link MyClassTests#NameOfMyTest()}
It's vary hard to find proper search query for my question so I hope it's not a duplicate.
I'm developing maven plugin with few goals. I'd like to combine two of them in the chain (lifecycle?). Before clean-checkout goal is executed I would like to execute checkout goal first. I'm using annotation approach and tried using #Execute annotation to point which goal should be executed. The plugin compiles but is not executed in the way I assumed, cause there is no preceeding checkout goal while executing clean-checkout.
#Mojo(name = "checkout", defaultPhase = LifecyclePhase.GENERATE_SOURCES)
public class Checkout extends AbstractMojo {
#Mojo(name = "clean-checkout", defaultPhase = LifecyclePhase.GENERATE_SOURCES)
#Execute(goal = "checkout", phase = LifecyclePhase.GENERATE_SOURCES)
public class CleanCheckout extends AbstractMojo {
Without defaultPhase and phase properties, the build was failing.
Where I'm doing mistake?
Defining a custom lifecycle might help you.
Two years ago I analyzed the maven-release-plugin in more details and noticed that they use their own lifecycle.
Here you can find their lifecycle definition:
http://svn.apache.org/viewvc/maven/release/tags/maven-release-2.3.2/maven-release-manager/src/main/components-fragment.xml?view=markup
Additionally I found details inside Sonatype's Mavenbook:
http://www.sonatype.com/books/mvnref-book/reference/writing-plugins-sect-plugins-lifecycle.html
This interesting blog might also help you:
http://www.sonatype.com/people/2009/08/create-a-customized-build-process-in-maven/
I'm trying to write a custom maven plugin, and want to get some information about the project.
After some searching around, I found that I can set parameters to certain project related values (presumably from the POM?) - e.g.
/**
* #goal myPlugin
*/
public class MyTestMojo extends AbstractMojo {
/**
* #parameter expression="${project}"
* #required
* #read-only
*/
private Object project;
#Override
public void execute() throws MojoExecutionException, MojoFailureException {
getLog().info(project.toString());
}
}
However, I cannot find any documentation on what parameters are available in this format. At the moment, I'm proceeding with trial and error, but that's proving a bit frustrating.
Any ideas?
Here is a short list of available properties. You may also want to look trough available Maven plugin tutorials.
See the Mojo API specification, section The Descriptor and Annotations.
There is a good introduction to writing plugins in Maven: The Complete Reference: 11.4 Writing a Custom Plugin, section 11.4.5. Mojo Class Annotations on the Sonatype website.
We've recently upgraded one of our projects. This involves new versions of JARs also.
Sitemesh was one of them. We updated from 2.2.1 to 2.4.2. Things stopped working.
We had a custom filter extend Sitemesh's PageFilter which now does not work because in v2.4 PageFilter extends SiteMeshFilter which does not expose the same methods (the ones we were overriding).
OK, no biggy, we'll just change our code to match, but then I saw this in the source code I downloaded from http://java.net/downloads/sitemesh/
/**
* Core Filter for integrating SiteMesh into a Java web application.
*
* #author Joe Walnes
* #author Scott Farquhar
* #since SiteMesh 3
*/
public class SiteMeshFilter implements Filter {
private FilterConfig filterConfig;
private ContainerTweaks containerTweaks;
private static final String ALREADY_APPLIED_KEY = "com.opensymphony.sitemesh.APPLIED_ONCE";
............
#since SiteMesh 3? This is v2.4.2. What 3?
Is the release corrupt or what? Am I missing something?
I'm using sitemesh 2.4.2 in one project and it works fine.
You can see that that change (which mentions Sitemesh 3) was done back in 2005 when they refactored the architecture to be compatible with sitemesh3. Here's the commit in github.
I remember getting a similar impression when I was browsing the javadocs a few months ago :).
So the answer is: The jar is not corrupt, it's just the result of a crooked merge.