How to add test-jar as aspectLibrary in Maven - maven

I have an aspect that I want to use in my test-classes. I don't want to add it to the main jar, as it would pull in test libraries like junit and mockito. While there's a configuration setting to add an aspectLibrary, it always adds the main jar, there's no way to specify the test-jar.
My aspectj plugin looks like this:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.7</version>
<configuration>
<aspectLibraries>
<aspectLibrary>
<groupId>aspect.test</groupId>
<artifactId>general</artifactId>
<type>jar</type>
</aspectLibrary>
</aspectLibraries>
</configuration>
<executions>
<execution>
<phase>process-sources</phase>
<goals>
<goal>compile</goal>
<goal>test-compile</goal>
</goals>
</execution>
</executions>
</plugin>
I actually want to specify test-jar but that doesn't seem possible. Without the it defaults to the jar (obviously).
I also might have to configure aspectj-maven-plugin for the compile and test-compile goal... but first I need to know how to specify the test-jar. Any suggestions are welcome.

Please read the Maven JAR Plugin documentation, chapter How to create a jar containing test classes. There are two options listed:
the easy way: using type "test-jar" (will not work here)
the preferred way: creating a normal JAR containing only test classes, then importing it with scope "test"
We will choose the preferred way because it solves your problem. So basically you do the following:
Create a separate module for test helper aspects/classes, put everything under src/main/java, not src/test/java. AspectJ Maven plugin should have an execution with <goal>compile</goal> for that module.
Add that module as a test-scoped dependency wherever you need the test aspects
Refer to the module as an <acpectLibrary> from AspectJ Maven plugin and also be careful to only use <goal>test-compile</goal> in your plugin execution for that module so as to avoid to have the aspects woven into production code or to get error messages because the dependency has test scope and is unavailable for normal compile.
Because I do not want to fully quote 3 POMs and several classes here, I have created a little GitHub sample project for you. Just clone it, inspect all the files and their respective locations and - be happy. ;-)

Related

How to specify a default goal for a Maven plugin?

I've defined a Maven plugin with multiple goals. Currently users run my plugin as follows:
<plugin>
<groupId>myGroupId</groupId>
<artifactId>myArtifactId</artifactId>
<version>someVersion</version>
<executions>
<execution>
<goals>
<goal>myGoal</goal>
</goals>
</execution>
</executions>
</plugin>
but I've seen other plugins, like maven-compiler-plugin and Flyway, that don't require specifying an execution: https://flywaydb.org/getstarted/java
<plugin>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>5.2.4</version>
<configuration>
<url>jdbc:h2:file:./target/foobar</url>
<user>sa</user>
<locations>
<location>classpath:db/migration</location>
</locations>
</configuration>
</plugin>
How do I specify the goal that should run by default when users exclude the <executions> block?
AFAIK, there are not default goals for Maven plugins.
You can configure a plugin without adding a goal. But this does not execute the plugin.
The plugin must be either executed explicitly on command line (like flyway:migrate) or is executed automatically through the lifecycle (like compile:compile or jar:jar).
I assume you are using the Java5 Annotations to mark your plugin as available mojo? (and not the javadoc way of living).
The #Mojo annotation has a defaultPhase attribute.
Once a user adds the plugin into the build these defaults (if set) will be used.
The Flyway Migrate Mojo does it this way too.
The compiler plugin is a bit of a bad example, as it is part of the default plugin bindings of the maven life-cycle itself. So the phase itself will know what mojo to run.
These are the docs for the maven plugin api, the one for using annotations is nearby.
If it is not your plugin, you can put the configs you want into a parent pom into the pluginManagement section.

What is the difference between executions and configurations in a maven plugin?

I found this description but it does not seem comprehensive. Could someone explain in detail what is the difference between executions and configurations in a maven plugin?
An <execution> causes the plugin to be executed during the maven build lifecycle, i.e. during your build. The <configuration> allows you to configure the plugin for how it should behave during execution. Many Maven plugins provide documentation about their configuration options, e.g. the maven-compiler-plugin.
You can define <configuration>s on the <plugin> level or the <execution> level. The former is globally valid for all executions, the latter is specific to the execution.
Example for global an execution-specific configurations:
Suppose, you have to compile your project with Java 1.7 but you want to early adopt Java 9 Jigsaw features and add a module-info.java to your project. This Java file will not compile using source level 1.7. What you can do is define two executions of the maven-compiler-plugin, one that compiles everything except module-info.java with source level 1.7 and one that does only compile module-info.java with source level 1.9:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.3</version>
<!-- Global plugin configuration for source and target levels. -->
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
<executions>
<!-- Compile all code except module-info.java with the configured source level -->
<execution>
<id>default-compile</id>
<phase>compile</phase>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<excludes>
<exclude>module-info.java</exclude>
</excludes>
</configuration>
</execution>
<!-- Compile module-info.java with source level 1.9 -->
<execution>
<id>compile-module-info-java</id>
<phase>compile</phase>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<source>1.9</source>
<target>1.9</target>
<includes>
<include>module-info.java</include>
</includes>
</configuration>
</execution>
</executions>
</plugin>
I think answer from #Stefan is already quite clear. I would like to be even a bit more verbose in case it helps.
"execution" under plugin is declaring "what should be done at when". Basically, an execution usually at least contains: phase and goal (I know you don't always see it in config, but conceptually they are there), which you can see it as: When the build process reached phase, then the goal action of the plugin will be executed.
Of course, you can have multiple executions for a plugin, so that different/same goals can be run in different/same phases.
Then come to configuration. Sometimes you need to tell the plugin extra detail on how the plugin should act on because the plugin may not be able to guess what you want to do by default. configuration is doing such work. You can refer to document of plugin's goal to see what kind of configuration they accept.
Plugin level configuration will be applied to all executions of the plugin, while you can also define configuration under each execution, which serve as execution-specific configuration. Plugin-level configuration + execution-level configuration is the "real" configuration received by an execution.
A <configuration> section outside an <execution> block affects the plugin's behavior in general way. For instance, plugins that are either executed directly through the CLI or have a default phase that they bind to will use this type of configuration. An example of such a plugin would be the compiler plugin.
On the other hand, a <configuration> section inside an <execution> block only applies to that specific execution.
As always, a more specific configuration can override a general configuration. So if a general configuration (outside an execution block) says <doCheck>false</doCheck>, an execution might choose to only override this by doing <doCheck>true</doCheck>.
Another feature of general configurations is that their parameters will be inherited by all executions of that plugin.

Using CodeNarc with Maven

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

getting exec-maven-plugin to execute a class in a dependency

I have two individual maven projects named Utilities and Campaigns. My utilities project has dependencies in it. The Campaigns project needs to execute the main method inside a class within Utilities. To accomplish this, I have been using the exec-maven-plugin. Using this plugin, I'm able to execute the main method of the dependency (Utilities) from my Campaigns pom file. However, transitive dependencies from Utilities don't seem to resolve when I execute the method. I can get around this by adding the same dependencies to both pom files, but if possible I'd like to avoid this redundancy and just inherit from Utilities. I've included the plugin portion of my Campaign pom file below. This is a little confusing, but is there a way I can get around this without having to define the same dependencies? Without having to list the dependencies in the plugin section?
The main method is found in com.sample.generics.Login.java.
Campaign.pom
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2</version>
<executions>
<execution>
<phase>test</phase>
<goals>
<goal>java</goal>
</goals>
</execution>
</executions>
<configuration>
<mainClass>com.sample.generics.Login</mainClass>
<classpathScope>test</classpathScope>
<arguments>
<argument>${resourcesDir}</argument>
<argument>${settingsFile}</argument>
</arguments>
<includeProjectDependencies>true</includeProjectDependencies>
</configuration>
</plugin>

how to wildcard attach multiple files to an artifact in maven?

In my maven project, the ant plugin generate multiple war files and I want to attach them all in the same artifact. I tried the build-helper-maven-plugin like this
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<id>attach-artifacts</id>
<phase>package</phase>
<goals>
<goal>attach-artifact</goal>
</goals>
<configuration>
<artifacts>
<artifact>
<file>${project.build.directory}/*.war</file>
<type>war</type>
</artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
I don't want to specify each war file separately because the ant plugin is dynamic. Is there a way to do that?
Thanks,
Providing wildcards for single artifacts does not seem to be supported by the Build Helper plugin (btw, if it did, it would likely use the includes/excludes configuration used by Resources Plugin).
I've learned that, if you choose to use Maven, it's best to just adjust your build to "the Maven way."
In this case, you should revise your build to not use the ant war plugin, and instead have a multi-module build with a separate module (sub-project) for each war file.
Alternatively, in the past I have accomplished something like you are doing via the Maven Assembly plugin, where the wars are all shipped together in a single tar/gz file. The archive (which contains each of the wars) is then attached to the build.
Note that you should prefer to have your "web apps" module have a artifact type of "pom." The assembly plugin will attach the archives to the final build.
For more information, I've found that Sonatype's online books are a great resource:
http://www.sonatype.com/Support/Books

Resources