Due to inter-type declarations the project I'm currently working on has it's pom.xml set to use ajc disabling javac.
// disable javac
<build>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<executions>
<execution>
<id>default-compile</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
We were planing to use Dagger2 but that would require to put dagger-compiler as an <annotationProcessorPaths> to be used by the disabled javac.
As aspectj-maven-plugin does not support the required <annotationProcessorPaths> I'm a bit at lost here. Any simple solution I'm not seeing or should I simply go with Guice?
Related
I have a Maven build that runs Arquillian tests on a Wildfly. What I want to do is run JaCoCo as well so that I get a test coverage.
What I did to my working Arquillian setup: I changed the parent's pom.xml the following way:
<properties>
<sonar.java.coveragePlugin>jacoco</sonar.java.coveragePlugin>
<sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis>
<jacoco.out.ut.file>../target/jacoco/jacoco-ut.exec</jacoco.out.ut.file>
<jacoco.out.it.file>../target/jacoco/jacoco-it.exec</jacoco.out.it.file>
<sonar.jacoco.reportPaths>${jacoco.out.ut.file},${jacoco.out.it.file}</sonar.jacoco.reportPaths>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>${jacoco.version}</version>
<executions>
<execution>
<id>prepare-ut-agent</id>
<phase>process-test-classes</phase>
<goals>
<goal>prepare-agent</goal>
</goals>
<configuration>
<destFile>${jacoco.out.ut.file}</destFile>
<propertyName>jacoco.agent.ut.arg</propertyName>
<append>true</append>
</configuration>
</execution>
<execution>
<id>prepare-it-agent</id>
<phase>package</phase>
<goals>
<goal>prepare-agent-integration</goal>
</goals>
<configuration>
<destFile>${jacoco.out.it.file}</destFile>
<propertyName>jacoco.agent.it.arg</propertyName>
<append>true</append>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-failsafe-plugin</artifactId>
<configuration>
<argLine>${test.argLine} ${jacoco.agent.it.arg}</argLine>
</configuration>
</plugin>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>${test.argLine} ${jacoco.agent.ut.arg}</argLine>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
That's a setup that works in multiple other projects (without Arquillian), so I assume it must work now, too.
For the module hosting the integration project I added the following:
<dependencies>
<dependency>
<groupId>org.jboss.arquillian.extension</groupId>
<artifactId>arquillian-jacoco</artifactId>
<version>1.0.0.Alpha9</version>
<scope>test</scope>
</dependency>
</dependencies>
The maven-surefire-plugin is called there (which is weird to me, but I tried maven-failsafe-plugin and it didn't work either).
When executed the module produces a jacoco.exec (which is 70kb for only the one module, so at least not empty). Sonar uses these files in the report generation. Still the code coverage gets displayed as 0%.
I found a couple tutorials on this topic, but they all seem to be missing a step (at least the setup is always identical to mine).
How do I get Arquillian to use JaCoCo to report the code coverage?
I've spent quite a bit of time figuring out how to invoke Maven shade plugin to build a uber-jar (with all dependencies).
Most of the google-able info that I found (including numerous examples, and Maven documentation) suggests that all I have to do is include the plugin into pom.xml:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.4.3</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
</execution>
</executions>
</plugin>
and then "mvn package" (or any other goal that eventually invokes "package") will automatically trigger this plugin.
But no matter what I tried - the only way to actually invoke the plugin appears to be: running "mvn package shade:shade" (which seems to defeat the purpose of config-driven build). Same results whether running Maven from within Eclipse (STS Version: 3.8.2.RELEASE), or from command line (Apache Maven 3.3.9).
Am I missing anything?
UPD: solved, see answer by GauravJ.
I have managed to reproduce your problem. In your pom.xml, you must have defined plugin like below,
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.4.3</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
</execution>
</executions>
</plugin>
....
</plugins>
</pluginManagement>
</build>
instead of
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.4.3</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
This will probably fix your problem.
I'm pretty new to Maven...
What I'm trying to do is skip the maven-deploy-plugin during the deploy phase, while replacing it with my own plugin (i.e. I'm deploying to a non-repository location).
I realize I could do this in multiple other ways, but the boss wants to be able to run:
mvn deploy
To get the results of my current workaround, which is disabling the maven-deploy-plugin (which seems to be disabling the entire deploy phase), and manually specifying the custom upload goal from the command line.
I'm currently failing to succeed in my mission with:
<executions>
<execution>
<phase>deploy</phase>
</execution>
</executions>
in the build/plugins/plugin section containing my plugin specification, since the deploy phase is skipped by:
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.7</version>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
Thanks!
disabling the maven-deploy-plugin (which seems to be disabling the entire deploy phase)
This is not correct. Disabling maven-deploy-plugin doesn't disable the entire deploy phase. This is how it should be done (looks like you're doing it already):
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
Try this (untested) alternative for disabling the standard deploy plugin:
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.7</version>
<executions>
<execution>
<id>default-deploy</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
I want to build on #yegor256's answer a bit... 8 years, 4 months later!
I found myself here getting into the weeds on some legacy Maven configurations that were full of cruft. Coming from a Maven mindset, albeit some years between now and active hacking, I was re-familiarizing myself with the Maven lifecycle.
TLDR... mvn help:effective-pom is your friend. Use your IDE's tools for viewing the effective POM often (NetBeans makes it easy. I added a keyboard shortcut in IntelliJ.)
In the configuration I was reviewing, the previous developers had created two (2) deploy-file executions, one war, one jar.
<build>
...
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.8.2</version>
<executions>
<execution>
<id>deploy-war</id>
<phase>deploy</phase>
<goals>
<goal>deploy-file</goal>
</goals>
<configuration>
... omitted ...
</configuration>
</execution>
<execution>
<id>deploy-jar</id>
<phase>deploy</phase>
<goals>
<goal>deploy-file</goal>
</goals>
<configuration>
... omitted ...
</configuration>
</execution>
</executions>
</plugin>
...
</plugins>
...
</build>
I was aware that these executions would be appended to the default-deploy bound to the deploy phase and observed this behavior in the logs. The default-deploy would run, uploading an empty war file, then the deploy-war would run, uploading, and overwriting, the first war file.
Several options exist.
skip and combine.self="override" (my preference)
As presented, using <skip> as a <configuration> option is viable. It is safe and more portable than setting setting the <phase> to none.
However, it will be inherited by the other executions (certainly as presented). To prevent this, you must explicitly tell your additional <execution> configurations to not inherit.
...
...
<executions>
<execution>
<id>deploy-war</id>
<phase>deploy</phase>
<goals>
<goal>deploy-file</goal>
</goals>
<configuration combine.self="override">
... omitted ...
</configuration>
</execution>
...
...
Override default-deploy
Another option, possibly more verbose and lest esoteric than combine.self="override" is to override the execution of the default-deploy <id> of the plugin.
...
<execution>
<id>default-deploy</id>
<configuration>
<skip>true</skip>
</configuration>
</execution>
...
This will not be inherited by the additional <executions>.
Another option
As #yegor256 notes, but in the additional configurations explicitly state <skip>false</skip> to "reset" the inherited <skip> from the plugin.
HTH.
I have maven-jaxb2-plugin. I generate jaxb objects and refer it in other classes of project.I've put jaxb plugin and compiler plugin under pluginManagement tag. Maven is executing compile phase first than generate phase where as if i remove pluginManagement tag, it works fine, first generate phase gets executed and all jaxb object gets generated and then compile phase gets executed. Due to pluginManagement tag, my project doesn't compile. Is pluginManagement tag used only for defining all the plugins in parent pom so that child pom can refer to these plugins ? My project is not a multi-module project.
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.6</source>
<target>1.6</target>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
<configuration>
<schemaDirectory>${basedir}/src/main/resources/schema</schemaDirectory>
<generatePackage>com.common.dto</generatePackage>
<schemaIncludes>
<include>*.xsd</include>
</schemaIncludes>
<removeOldOutput>false</removeOldOutput>
<strict>false</strict>
<verbose>true</verbose>
<forceRegenerate>true</forceRegenerate>
<extension>true</extension>
</configuration>
</plugin>
</plugins>
</pluginManagement>
Yes, <pluginManagement> is used to create ready-to-use configurations, but does not automatically activate your plugins - you still need to include them.
So in effect you are right, <pluginManagement>, just like <dependencyManagement> are very useful in the parent pom to centralize plugin configurations and dependency management.
Effectively, 'declaring' your plugins in the right module benefits from a much more compact syntax:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
</plugin>
</plugins>
We're using Maven 3 and I'm facing a project that has JSP-files and also uses "global" JSP-files stored in a different project. This works nicely when using maven-war-plugin and webResources. All JSP-files find their way into the WAR-file.
The new idea is to pre-compile all the JSPs. The obvious choice is to use jspc-maven-plugin. However, that doesn't include the external JSPs when it compiles the project-local JSPs.
Here's the snippet from the pom.xml:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jspc-maven-plugin</artifactId>
<executions>
<execution>
<id>jspc</id>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1</version>
<configuration>
<warName>${pom.groupId}.${pom.artifactId}-0.0.1-SNAPSHOT</warName>
<webXml>${basedir}/target/jspweb.xml</webXml>
<webResources>
<resource>
<directory>../name.of.external.project/src/global/webapp</directory>
</resource>
</webResources>
</configuration>
</plugin>
The error is
[ERROR] Failed to execute goal org.codehaus.mojo:jspc-maven-plugin:1.4.6:compile (jspc) on project internal.project: JSPC Error: file:C:/workspace/name.of.internal.project/src/main/webapp/WEB-INF/views/show.jsp(2,0) File "/WEB-INF/views/../jspGlobal/jsp-declaration.jspf" not found -> [Help 1]
The jspGlobal-directory would get copied with the <directory>../name.of.external.project/src/global/webapp</directory>-line above.
What's missing to include the external JSPs in JspC?
EDIT: Thanks to prunge's and Raghuram's input I looked deeper into sources and JavaDocs. I noticed that the mentioned sources requires a FileSet which does NOT allow a list of directories. And since sources is also not a list, I see no chance how I can specify more than one JSP-source directory. I even tried to copy the <plugin>-element, but that didn't help. My current situation is this:
<plugin>
<groupId>org.codehaus.mojo.jspc</groupId>
<artifactId>jspc-maven-plugin</artifactId>
<version>2.0-alpha-3</version>
<executions>
<execution>
<id>jspc</id>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
<configuration>
<sources>
<directory>${basedir}/../name.of.external.project/src/global/webapp</directory>
</sources>
<!-- the later mentioned <sources> gets picked
<sources>
<directory>${basedir}/src/main/webapp</directory>
</sources>
-->
<!-- 1.6 doesn't work!? Something lower than 1.5 seems to be the default -->
<source>1.5</source>
<target>1.5</target>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.mojo.jspc</groupId>
<artifactId>jspc-compiler-tomcat6</artifactId>
<version>2.0-alpha-3</version>
</dependency>
</dependencies>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1</version>
<configuration>
<warName>${pom.groupId}.${pom.artifactId}-0.0.1-SNAPSHOT</warName>
<webXml>${basedir}/target/jspweb.xml</webXml>
<webResources>
<resource>
<directory>../name.of.external.project/src/global/webapp</directory>
</resource>
</webResources>
</configuration>
</plugin>
Now the external JSPs are compiled into the target-path of the current project. Now I need a way to compile the JSPs of the current project. How do I do this?
BTW, if I switch the <sources> to the line for the current project I get the same error as mentioned earlier.
Perhaps you could try with the latest version of jspc-maven-plugin, which is 2.0-alpha-3. Do note that the usage is a little different from the earlier version.
Looking at the source code of CompilationMojoSupport, I see a sources property of type FileSet. You might be able to configure this in the configuration of the plugin to add additional source directories. It looks like by default it uses ${project.basedir}/src/main/webapp regardless of the configuration of the WAR plugin.