I only want to document two classes from a package. In standard javadoc tool, it would be something like:
C:> javadoc -d C:\home\html C:\home\src\java\awt\classA.java C:\home\src\java\awt\classB.java
How can I do it in maven-javadoc-plugin?
sourceFileIncludes should do what you're looking for.
https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#sourceFileIncludes
Here's an example:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.10.1</version>
<configuration>
<sourceFileIncludes>
<include>com/mycompany/myproject/MyClass.java</include>
</sourceFileIncludes>
</configuration>
</plugin>
UPDATE:
I tried this out on one of my maven projects and it worked at the package level, but not on individual classes. It looks like these open Maven issues are the cause:
http://jira.codehaus.org/browse/MJAVADOC-388
http://jira.codehaus.org/browse/MJAVADOC-365
Note that issue #365 is actually related to sourceFileExcludes; the fix for that is scheduled for maven-javadoc-plugin 2.11.
Related
It seems like maven assembly plugin always output to ${project.dir}/target regardless of all the descriptor fields I set. Is this feature supported by maven assembly plugin?
You can of course change that behaviour by using the correct configuration for outputDirectory like this:
<plugin>
<groupId>org.apache.maven.plugin</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.5.5</version>
<configuration>
<outputDirectory>TheLocationYouLike</outputDirectory>
..
</configuration>
</plugin>
But i can't recommend that, cause it is against the convention over configuration paradigm.
In project pom.xml is it required to include both maven-release-plugin and maven-compiler-plugin? The reason I want the release plugin is because I want to release the project at the end of a sprint/release. I understand that the compiler plugin will compile the source code, however I am not sure if the release plugin will also compile the source code, apart from updating the pom and checking out/in to scm.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.2.2</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
Any help with this is much appreciated.
If unspecified, Maven will know what to do when it needs to compile the code. However, in order to be able to control things like source and target versions, you will need to have a declaration of the maven-compiler-plugin.
It is generally good practice, to explicitly define the plugins you are using, along with their configurations and above all their versions, so that you have a guarantee of what was working.
What the Maven Release Plugin does is described here.
Your question is about the bullet "Run the project tests against the modified POMs to confirm everything is in working order". There is not that much magic here. What happens is that the maven-release-plugin will start a new Maven session. It will execute "mvn verify" in the same folder where you ran "mvn release:prepare".
All the steps done by the maven-release-plugin could also be done by hand, but that's asking for mistakes.
I have my standard flyway config in my pom file and I am trying to override in through system properties, as mentioned here.
Here is my configuration in the pom file:
<plugin>
<groupId>com.googlecode.flyway</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<url>dbUrl</url>
<user>dbUser</user>
<password>dbPass</password>
<schemas>
<schema>core</schema>
<schema>public</schema>
</schemas>
</configuration>
</plugin>
And following is the command line that I'm running:
mvn clean compile flyway:migrate -Dflyway.url=anotherDbUrl -Dflyway.user=anotherDbUser -Dflyway.password=anotherDbPass
The documentation in the above link says System properties > Maven properties > Plugin configuration. Am I missing something?
Good catch. This seems to have broken along the way. Could you please file an issue? I'll fix this in time for 2.2.1.
I feel a bit stupid about this question but i can't figure out how to add a SINGLE dependency (jdom.jar) into another jar.
Context: We developed a simple plug-in for our application, this plug-in have many dependency. We were using fatjar to include jdom.jar into it. I am trying to fix a bug in this plug-in, so i decided to "maven-ize" it at the same time. (We just switched to maven) This plug-in is loaded on the runtime so the only dependencies we want packaged with it is the jdom.jar.
Problem: I found that there is a maven fatjar plug-in! Unfortunately i could not find any documentation and this maven plug-in add EVERY dependency into the ouput jar. After many try i decided to give up on this fatjar plug-in and searched for another one. I found one-jar , shade but after a quick read on them they look like they add every dependency.
Question: what would be a simple way to add only jdom.jar into my plug-in jar like this:
-MyPlug-in.jar
|
|-src
|-main
|-java
|-*.java
|-jdom.jar
Also I don't want to alter the manifest or the output jar filename
Thank a lots for your time.
There was no answer here regarding how to use maven to include one single jar-file with the maven-shader-plugin. It took me some time to figure out how to actually do that. Here is a snippet to include just the classes from the dependency com.googlecode.json-simple:json-simple.
<project>
...
<build>
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>1.6</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<artifactSet>
<includes>
<include>com.googlecode.json-simple:json-simple</include>
</includes>
</artifactSet>
</configuration>
</execution>
</executions>
</plugin>
...
</plugins>
</build>
...
</project>
For this kind of purpose i would suggest to use the maven-shade-plugin which will create a ueber-jar which can be controlled in many ways.
With the shade plugin you can exclude things you don't like. But this might be caused by not using a separate maven module where you can control the dependencies.
Using maven Shade would work fine, one-jar would have done the job too.
But we finally decided that packaging jdom in our extension would be a bad practice.
So instead we gonna do this:
|-Root application Folder
|-Extension Folder
|-MyExtension.jar
|-libs Folder
|-jdom.jar
The jar into the lib folder will be loaded dynamically and won't be loaded if the extension cannot find the appropriate libs into the libs folder.
For the people who look to solve my primary problem please check out #khmarbaise Answer.
I would like to setup my maven release to run in batch mode, but I'm not a fan of the default scm tag ${artifactId}-${releaseVersion}. Instead, I'd like to simply tag it with ${releaseVersion}; however, I'm unclear if such a property exists (ie. without the -SNAPSHOT suffix).
I'd like the configuration to resemble the code below. Is such a default tagging possible with the maven-release-plugin?
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.0</version>
<configuration>
<tag>${releaseVersion}</tag>
</configuration>
</plugin>
I just got this to work when using Hudson to do my release. I noted that Hudson (with the Maven Release Plugin) is initiating the command with a property like -Dproject.rel.com.example:my-artifact-id=1.0.1. Using the following plugin configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<configuration>
<tag>REL-${project.rel.com.example:my-artifact-id}</tag>
</configuration>
</plugin>
Resulted in the tag being REL-1.0.1
I'm new to the release plugin but I would assume something similar would work from the command line.
You can pass in the properties for:
releaseVersion -- What version you want it to be released as (1.0)
developmentVersion -- The next version (2.0-SNAPSHOT)
tag -- The name of the tag
a 1.0-SNAPSHOT implies a 1.0 release version, but doesn't set it. You can set that property in your POM file as a regular property.
try this:
<configuration>
<tag>${project.version}</tag>
</configuration>