I created a webservice and would like to generate documentation for the API. So I looked into Enunciate downloaded the maven enunciate plugin. However I get the below error on compile as the webservice annotations are on my interface class that my POJO implements rather than the POJO itself.
I don't want to clutter the POJO by adding the annotations to it.
artifact org.mortbay.jetty:maven-jetty-plugin: checking for updates from central
[INFO] [enunciate:docs {execution: default}]
[INFO] initializing enunciate.
[INFO] invoking enunciate:generate step...
[WARNING] Validation result has errors.
/Users/vkumar/IdeaProjects/identity-service/trunk/src/main/java/com/foobar/ids/service/IDService.java:17: [jersey] Jersey doesn't support interfaces as root resources.
The #Path parameter will need to be applied to the implementation class.
public interface IDService {
^
1 error
[INFO] ------------------------------------------------------------------------
The pom.xml snippet is here
<plugin>
<groupId>org.codehaus.enunciate</groupId>
<artifactId>maven-enunciate-plugin</artifactId>
<!-- check for the latest version -->
<version>1.20</version>
<executions>
<execution>
<goals>
<goal>docs</goal>
</goals>
<configuration>
<!-- the directory where to put the docs -->
<docsDir>${project.build}/docs </docsDir>
</configuration>
</execution>
</executions>
</plugin>
That's a limitation of Jersey. You have to annotate your implementation class.
CXF, however, doesn't make that same requirement, so you may want to consider using the CXF implementation of JAX-RS instead of the Jersey implementation:
<plugin>
<groupId>org.codehaus.enunciate</groupId>
<artifactId>maven-enunciate-cxf-plugin</artifactId>
<!-- check for the latest version -->
<version>1.20</version>
<executions>
<execution>
<goals>
<goal>docs</goal>
</goals>
<configuration>
<!-- the directory where to put the docs -->
<docsDir>${project.build}/docs </docsDir>
</configuration>
</execution>
</executions>
</plugin>
Related
I have looked around from various questions on stackoverflow, but I have not found the answer that solve my purpose.
I want to import a properties file in a pom.xml; my purpose is to replace the <properties> section with the properties loaded from the external file.
Each property refers to the version of a particular maven dependency.
I have tried the properties-maven-plugin, but the properties are not solved and the project is not built.
I'm looking for a way that preserve the standard build of Eclipse, and also the mvn install goal of Maven.
As an example, I want that this section:
<properties>
<dependency1.version>1.0.0</dependency1.version>
</properties>
will be replaced with the property declared in a dependency.properties file, like this one:
dependency1.version=1.0.0
How can I implement my pom.xml in order to obtain this behaviour?
Thanks in advance.
EDIT
This is what I have tried:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0.0</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>${basedir}/dependencies.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>generate-resources</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>my version: ${dependency1.version}</echo>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Well, if I do a simple mvn install, in maven console it prints:
[INFO] Executing tasks
[echo] my version: 1.0.0
[INFO] Executed tasks
So, the plugin solve the property, but when I try to import the dependency with this:
<dependencies>
<dependency>
<groupId>dependency1</groupId>
<artifactId>dependency1</artifactId>
<version>${dependency1.version}</version>
</dependency>
</dependencies>
I obtain this error:
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] 'dependencies.dependency.version' for dependency1:dependency1:jar must be a valid version but is '${dependency1.version}'. # line 21, column 13
#
The property is solved in the maven-antrun-plugin, but if it is used in the dependencies section, it doesn't work.
The following plugin added to the pom.xml allows source-jar to be created when performing mvn package:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<executions>
<execution>
<id>attach-sources</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
The usage of the scala-maven-plugin is :
<plugin>
<groupId>net.alchim31.maven</groupId>
<artifactId>scala-maven-plugin</artifactId>
<version>3.2.1</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>testCompile</goal>
</goals>
</execution>
</executions>
<configuration>
<jvmArgs>
<jvmArg>-Xmx12g</jvmArg>
</jvmArgs>
<args>
<arg>-feature</arg>
<arg>-deprecation</arg>
<arg>-target:jvm-1.7</arg>
</args>
</configuration>
</plugin>
However only the java sources are being included: the scala sources are left out. Note that we are using the standard maven directory layout. In particular we have scala sources here:
src/main/scala
So - are there additional options to the maven-source-plugin to encourage it to invite the scala classes to participate? Or a different scala-specific plugin and/or option to get them onboard?
The jar goal of the Maven Source Plugin will bundle all of the sources of the Maven project into a JAR. You can select what to include or exclude in those source folders (with the includes and excludes parameters), but you cannot add whole new source folders to it; they must be added as source folders of the Maven project itself.
When you have a pure Scala project, src/main/scala and src/test/scala are declared as source folders, because you would have:
<sourceDirectory>src/main/scala</sourceDirectory>
<testSourceDirectory>src/test/scala</testSourceDirectory>
in your POM, overriding the default src/main/java and src/test/java. So the Maven Source Plugin would correctly add the sources present in those two folders without additional configuration.
But when you have a mixed Java / Scala project, the <sourceDirectory> and <testSourceDirectory> element are typically left in to their default values. This does not create any problems with regard to compiling or running Scala code with the plugin, as it looks up the files by default in ${project.build.sourceDirectory}/../scala. However, other unrelated Maven plugins can't know about those new folders.
To fix this, the plugin provides the add-source goal, which adds src/main/scala and src/test/scala as source and test source directory to the Maven project, and, thus, makes them available for the other plugins relying on the source directories, like the Maven Source Plugin. You should therefore change your POM to:
<plugin>
<groupId>net.alchim31.maven</groupId>
<artifactId>scala-maven-plugin</artifactId>
<version>3.2.1</version>
<executions>
<execution>
<goals>
<goal>add-source</goal>
<goal>compile</goal>
<goal>testCompile</goal>
</goals>
</execution>
</executions>
<!-- rest of configuration -->
</plugin>
Is it possible for a POM to declare (or at least publish) an artifactId containing system properties? I mean the artifactId of the actual project, not dependencies.
I am using maven to build a scala project and thus, to allow publishing the project for different scala versions, in the pom.xml I'd like to declare:
<artifactId>myproject_${scalaBinaryVersion}</artifactId>
however maven 3.3. complains
[WARNING] 'artifactId' contains an expression but should be a constant
Since I'd like this project to be interoperable with sbt, what would be the best way to publish an artifact suffixed with the scala binary version?
The Maven way of doing so would be to use classifiers. From official documentation an example matches exactly your case (for different Java versions, but you can replace Java with Scala):
The classifier allows to distinguish artifacts that were built from the same POM but differ in their content. It is some optional and arbitrary string that - if present - is appended to the artifact name just after the version number.
As a motivation for this element, consider for example a project that offers an artifact targeting JRE 1.5 but at the same time also an artifact that still supports JRE 1.4. The first artifact could be equipped with the classifier jdk15 and the second one with jdk14 such that clients can choose which one to use.
You can configure your POM as following:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.5</version>
<executions>
<execution>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<classifier>${scalaBinaryVersion}</classifier>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Note: we are adding an additional execution of the Maven Jar Plugin, so the project would create two jars, the normal one + an additional one with the specified (dynamic) classifier.
Then Maven will automatically publish the classified jar together with the normal jar (since it will be automatically attached to the build). You can then import it as a further Maven dependency in another project specifying its classifier as part of the Maven GAV (GAVC in this case):
<dependency>
<groupId>your.group.id</groupId>
<artifactId>your.constant.artifact.id</artifactId>
<version>your.version</version>
<classifier>your.dynamic.classifier</classifier>
</dependency>
If you want to only build the classified one and no standard (unused) jar, you can skip the creation of the normal jar as following:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.5</version>
<executions>
<execution>
<id>default-jar</id>
<phase>none</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
<execution>
<id>scala-version-jar</id>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<classifier>${scalaBinaryVersion}</classifier>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Note: we are simply overriding the default execution of the Jar Plugin and binding it to a non existing phase. Hence Maven will only generate the classified Jar. The Install Plugin will then only install the classified one.
Update: how to have dynamic artifactId installed with dynamic dependencies
If different transitive dependencies are required for different dynamic versions, then indeed classifiers are not suitable.
Dynamic artifactIds with dynamic dependencies (and hence dynamic transitive dependencies) can however be achieved. Here below is the approach I used (and successfully tested):
As preference, I isolated the dynamic behavior in a profile, but you can obviously move it back to the default build (or have the profile active by default).
First of all, let's define in our pom the dependencies requiring a dynamic version, hence via properties as following:
<properties>
<scalaBinaryVersion>scalaversion</scalaBinaryVersion>
<dependency.version>4.11</dependency.version>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>${dependency.version}</version>
</dependency>
</dependencies>
Note: for the sake of an example, I'm using Junit as dependency in this case and not in test scope, because I want it as compile dependency (again, just for this example).
Then let's define a profile for our dynamic behavior:
<profiles>
<profile>
<id>build-scala-version</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.5</version>
<configuration>
<finalName>${project.artifactId}_${scalaBinaryVersion}-${project.version}</finalName>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.7</version>
<executions>
<execution>
<id>copy-pom</id>
<phase>generate-resources</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/${scalaBinaryVersion}</outputDirectory>
<resources>
<resource>
<directory>${basedir}</directory>
<includes>
<include>pom.xml</include>
</includes>
<filtering>true</filtering>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>com.google.code.maven-replacer-plugin</groupId>
<artifactId>replacer</artifactId>
<version>1.5.1</version>
<executions>
<execution>
<id>replace-artifactid</id>
<phase>prepare-package</phase>
<goals>
<goal>replace</goal>
</goals>
<configuration>
<file>target/${scalaBinaryVersion}/pom.xml</file>
<token><artifactId>${project.artifactId}</artifactId></token>
<!-- Replace to -->
<value><artifactId>${project.artifactId}_${scalaBinaryVersion}</artifactId></value>
<outputDir>target\${scalaBinaryVersion}\replacer</outputDir>
<outputFile>pom.xml</outputFile>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.5.2</version>
<executions>
<execution>
<id>default-install</id>
<configuration>
<skip>true</skip>
</configuration>
</execution>
<execution>
<id>install-scala-version</id>
<phase>install</phase>
<goals>
<goal>install-file</goal>
</goals>
<configuration>
<groupId>${project.groupId}</groupId>
<artifactId>${project.artifactId}_${scalaBinaryVersion}</artifactId>
<version>${project.version}</version>
<packaging>${project.packaging}</packaging>
<file>${project.build.directory}/${project.artifactId}_${scalaBinaryVersion}-${project.version}.jar</file>
<pomFile>${project.build.directory}/${scalaBinaryVersion}/replacer/pom.xml</pomFile>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
Note, the profile is customizing and providing the following:
Changing the final Jar name with a dynamic name, depending on the runtime (aka dynamic) value, to ${project.artifactId}_{scalaBinaryVersion}-${project.version}
Filtering the existing pom file via the Maven Resources Plugin and copying it to the directory target\${scalaBinaryVersion}. The copied pom will have the dependencies with the dynamic version because the Resources Plugin will replace them. However, it will not have the dynamic artifactId (yet).
Finalizing the dynamic pom file. The Replacer plugin will replace the artifactId XML element with the dynamic value (working on the target folder, hence everything on temporarely files)
Skipping the generation of the default installation
Performing a custom install-file installation with the dynamic pom file (the filtered, copied and replaced one, providing dynamic dependencies (and as such dynamic transitive dependencies) and a dynamic artifactId
Hence, performing the following maven invocation:
mvn clean install -Pbuild-scala-version -DscalaBinaryVersion=hello -Ddependency.version=4.4
Maven will effectively install a new artifact in the local cache for the dynamic artifactId, the dynamic dependency version and the dynamic pom.
Note: if the concerned dependency version(s) and the dynamic scala version is the same, then you can save up a parameter and make the invocation shorter and more consistent.
if you are using maven for that I will saggest using multi pom with maven helper plugin so the artifactId is constant in each module.
We follow the properties (via profiles) based approach as suggested here: scala-maven-plugin FAQ
<artifactId>something_${scala.compat.version}</artifactId>
<properties>
<scala.compat.version>2.12</scala.compat.version>
</properties>
maven will still issue a warning (with good reason), but with the help of the flatten-maven-plugin we build/install poms that has the variables replaced.
Has anyone had success following the Eclipse Annotation Processing directions for GWTP Boilerplate Generation? I followed the directions for Eclipse Annotation Processing, but cannot import the GWTP annotation package.
I'd appreciate any insight on either Eclipse Annotation Processing, or the alternative Maven Configuration setup that is mentioned also.
These are the directions from GWTP Boilerplate Generation (bottom of page):
Eclipse Annotation Processing
In Eclipse, the annotation processor kicks in as soon as you save the file you're working on and incrementally
changes only the required files. Another method exists by using the Eclipse lifecycle mapping. If the lifecycle
mapping is used, the annotation processor doesn't have to be setup. Find out more in the Maven Configuration on
how to setup the annotation processing with out touching eclipse properties.
To enable GWTP annotation processing in eclipse:
Open the properties for your project
Ticking all the boxes on the Annotation Processing page.
Ticking all the boxes on the Annotation Processing page.
Add the GWTP jar to the factory path.
Add the GWTP jar to the factory path.
In maven you can try this:
1) Import gwtp processors
<dependency>
<groupId>com.gwtplatform</groupId>
<artifactId>gwtp-processors</artifactId>
<version>${gwtplatform.version}</version>
</dependency>
2) use next plugins
<!-- Run annotation processors on src/home/java sources -->
<plugin>
<groupId>org.bsc.maven</groupId>
<artifactId>maven-processor-plugin</artifactId>
<version>2.0.5</version>
<executions>
<execution>
<id>process</id>
<goals>
<goal>process</goal>
</goals>
<phase>generate-sources</phase>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>com.google.web.bindery</groupId>
<artifactId>requestfactory-apt</artifactId>
<version>${gwt.version}</version>
</dependency>
</dependencies>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.9</version>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${project.build.directory}/generated-sources/apt</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
I have been trying to deploy application to Weblogic 10.3.6 using maven
I have created weblogic plugin for maven as mentioned in this article.
I have added the following to pom.xml
<build>
<plugins>
<plugin>
<artifactId>maven-plugin-plugin</artifactId>
<version>2.3</version>
<configuration>
<goalPrefix>weblogic</goalPrefix>
</configuration>
</plugin>
<plugin>
<groupId>weblogic</groupId>
<artifactId>weblogic-maven-plugin</artifactId>
<version>10.3.6.0</version>
<configuration>
<adminurl>t3://localdomain:7001</adminurl>
<user>weblogic</user>
<password>password</password>
<name>wldemo</name>
<remote>true</remote>
<upload>true</upload>
<targets>AdminServer</targets>
</configuration>
<executions>
<execution>
<id>deploy</id>
<phase>pre-integration-test</phase>
<goals>
<goal>deploy</goal>
</goals>
<configuration>
<source>target/EmployeesApp-1.0-SNAPSHOT.war</source>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
When I did mvn com.oracle.weblogic:weblogic-maven-plugin:deploy I am getting the following errors, how can I resolve these errors?
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Final Memory: 3M/15M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.oracle.weblogic:weblogic-maven-plugin:10.3.6.
0:deploy (default-cli) on project EmployeesApp: The parameters 'source' for goal
com.oracle.weblogic:weblogic-maven-plugin:10.3.6.0:deploy are missing or invali
d
You have specified the source parameter in the execution configuration, so in order to make it taken into account you should invoke this particular execution. It can be done using the phase key you specified, so e.g.:
mvn integration-test
Maven will go through the whole lifecycle and on the pre-integration-test test phase (which precedes the integration-test one) it will run the execution of weblogic-maven-plugin you configured.