From my pom http://code.google.com/p/memorizeasy/source/browse/MemoPlatform/persistence/pom.xml:
<plugin>
<groupId>org.bsc.maven</groupId>
<artifactId>maven-processor-plugin</artifactId>
<version>1.3.7</version>
<executions>
<execution>
<id>process</id>
<goals>
<goal>process</goal>
</goals>
<phase>generate-sources</phase>
<configuration>
<!-- Without this, the annotation processor complains about persistence.xml not being present and fail -->
<compilerArguments>-Aeclipselink.persistencexml=src/main/resources/META-INF/persistence.xml -Aeclipselink.persistenceunits=com.mysimpatico_MemoPlatform-database_nbm_1.0-SNAPSHOTPU</compilerArguments>
<!-- For an unknown reason, the annotation processor is not discovered, have to list it explicitly -->
<processors>
<processor>org.eclipse.persistence.internal.jpa.modelgen.CanonicalModelProcessor</processor>
</processors>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<inherited>true</inherited>
<configuration>
<compilerArgument>-proc:none</compilerArgument>
</configuration>
</plugin>
We discussed this last year here, and reported a relevant bug (no one cared about #eclipselink).
Note: I'm the author of the plugin.
To make configuration a lot simpler I would recommend you test: https://github.com/ethlo/eclipselink-maven-plugin.
With EclipseLink 2.2.0, it works for me without specifying the processor. The compiler argument is still needed.
Related
Is it possible to get the major version (<Major>.<Minor>.<Patch>) of the project.version?
For example if my version is 1.3.4, I'd like to get 1 to later use it in a configuration of the same pom.xml
Something like:
<configuration>
<name>project_name.${project.version:major}</name>
</configuration>
If not, what are the alternatives?
Found it. The build-helper-maven-plugin has the ability to parse-out the components of the version.
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<phase>initialize</phase>
<id>parse-version</id>
<goals>
<goal>parse-version</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>[version] ${project.version}</echo>
<echo>[majorVersion] ${parsedVersion.majorVersion}</echo>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
This works on Maven 3.3.9:
${project.artifact.selectedVersion.majorVersion}
Versions don't necessarily come in the structure you describe.
Maven has conventions for trailing numbers, but you don't have to use them.
If you have a convention that you like that you want to disassemble, you can write your own maven plugin that sets several properties to the several pieces as you define them.
I have a POM where I am using JAXB2 plugin to generate code from mulitple webservices (wsdl).
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
<!-- maven-jaxb2-plugin -->
<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
<executions>
<execution>
<id>Bus</id>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<schemaLanguage>WSDL</schemaLanguage>
<schemas>
<schema>
<url>http://server/Service1?wsdl</url>
</schema>
</schemas>
<generatePackage>com.core.business</generatePackage>
</configuration>
</execution>
<execution>
<id>Ser</id>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<schemaLanguage>WSDL</schemaLanguage>
<schemas>
<schema>
<url>http://server/Service2?wsdl</url>
</schema>
</schemas>
<generatePackage>com.core.search</generatePackage>
</configuration>
</execution>
<execution>
<id>Tab</id>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<schemaLanguage>WSDL</schemaLanguage>
<schemas>
<schema>
<url>http://server/Service3?wsdl</url>
</schema>
</schemas>
<generatePackage>com.core.table</generatePackage>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
The generated class files are all included in all the Packages. Therefore
com.core.business
com.core.search
com.core.table
It appears that namespaces are not handled correctly as the classes for wsdl1,2,3 are combined in all the 3 packages.
How to ensure that these packages include the specific classes specified in the wsdl?
Those asterisk on each side of your <url> and <generatePackage> attributes are wild card characters.
See this example from http://www.mojohaus.org/jaxb2-maven-plugin/Documentation/v2.2/example_xjc_basic.html
<project>
...
<dependencies>
<!--
You need the JAXB API to be able to annotate your classes.
However, starting with Java 6 that API is included in the
Java SE platform so there is no need to declare a dependency.
-->
...
</dependencies>
...
<build>
<pluginManagement>
<plugins>
<!--
If we e.g. execute on JDK 1.7, we should compile for Java 7 to get
the same (or higher) JAXB API version as used during the xjc execution.
-->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxb2-maven-plugin</artifactId>
<version>${project.version}</version>
<executions>
<execution>
<id>xjc</id>
<goals>
<goal>xjc</goal>
</goals>
</execution>
</executions>
<configuration>
<!-- The package of your generated sources -->
<packageName>com.example.myschema</packageName>
</configuration>
</plugin>
...
</plugins>
<build>
...
</project>
I would definitely take the * and ** of the beginning of those lines. I found the answer to your question pretty quickly by going to https://github.com/highsource/maven-jaxb2-plugin/wiki/Configuration-Cheat-Sheet
I would like to build from a maven pom running two sequential executions of the same plugin, in the same phase differing only by a single property, which will result in two different archives being created. Since the configuration is rather complicated, I'd rather NOT copy it just to change one value, which would create a maintenance nightmare. If it was somehow possible to define such a property in the <executions> section of the plugin config, I could avoid this headache.
Question: Is this possible and if so how?
Update: Two answers have mentioned using multiple executions and one of them mentions that you can have separate configurations in each execution. But given that the majority of my configuration is constant between the two executions, can I have one configuration on the plugin level and also have configuration sections in each execution for the parts that are different?
Given the simple Maven Source Plugin configuration (as an example) you have a shared configuration across all of its executions (outside the executions element) and then a custom configuration per each execution, for the same phase, as requested by your question:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.4</version>
<configuration>
<includePom>true</includePom>
</configuration>
<executions>
<execution>
<id>test-id1</id>
<phase>verify</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<finalName>aaa</finalName>
</configuration>
</execution>
<execution>
<id>test-id2</id>
<phase>verify</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<finalName>bbb</finalName>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
The configuration entry <includePom>true</includePom> will in this case be merged with the custom configurations of each execution and as such centralize the common configuration as plugin generic configuration.
For more details on the different level of configurations, you can check official Maven documentation, here, in particular the example "Configuring compile to run twice". Further details are also available on the official POM documentation, here, Plugins section.
You need to create a different execution (still bound to the same phase)
To avoid duplication of the config, you can put the <configuration> outside the <execution> element and then in the 2 executions, you only define the property that is different.
Taken from the maven docs:
<project>
...
<build>
<plugins>
<plugin>
<artifactId>maven-myquery-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<id>execution1</id>
<phase>test</phase>
<configuration>
<url>http://www.foo.com/query</url>
<timeout>10</timeout>
<options>
<option>one</option>
<option>two</option>
<option>three</option>
</options>
</configuration>
<goals>
<goal>query</goal>
</goals>
</execution>
<execution>
<id>execution2</id>
<configuration>
<url>http://www.bar.com/query</url>
<timeout>15</timeout>
<options>
<option>four</option>
<option>five</option>
<option>six</option>
</options>
</configuration>
<goals>
<goal>query</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
...
</project>
You create two <execution> elements within the <plugin> declaration. Each <execution> element can have it's own <configuration> section.
I wanted to create a jar and a put in in a zip file with other config files
This worked for me
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.4.1</version>
<executions>
<execution>
<id>build-jar-with_dep1</id>
<phase>package</phase>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<finalName>${buildversion}</finalName>
<finalName>finalname</finalName>
<appendAssemblyId>false</appendAssemblyId>
</configuration>
<goals>
<goal>assembly</goal>
</goals>
</execution>
<execution>
<id>build_zip1</id>
<phase>package</phase>
<configuration>
<descriptor>src/assembly/bin.xml</descriptor>
<finalName>${buildversion}</finalName>
<finalName>finalname</finalName>
<appendAssemblyId>false</appendAssemblyId>
</configuration>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
With following configuration, how can I make it sure to check against the signature for limited classes and packages?
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>animal-sniffer-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
<configuration>
<signature>
</signature>
<!-- How can I select packages/classes to check? -->
</configuration>
</execution>
</executions>
</plugin>
You can extract those packages in separate sub-modules, and only use the plugin in those modules.
Is it possible to get the major version (<Major>.<Minor>.<Patch>) of the project.version?
For example if my version is 1.3.4, I'd like to get 1 to later use it in a configuration of the same pom.xml
Something like:
<configuration>
<name>project_name.${project.version:major}</name>
</configuration>
If not, what are the alternatives?
Found it. The build-helper-maven-plugin has the ability to parse-out the components of the version.
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<phase>initialize</phase>
<id>parse-version</id>
<goals>
<goal>parse-version</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>[version] ${project.version}</echo>
<echo>[majorVersion] ${parsedVersion.majorVersion}</echo>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
This works on Maven 3.3.9:
${project.artifact.selectedVersion.majorVersion}
Versions don't necessarily come in the structure you describe.
Maven has conventions for trailing numbers, but you don't have to use them.
If you have a convention that you like that you want to disassemble, you can write your own maven plugin that sets several properties to the several pieces as you define them.