I'm using maven and the maven-javadoc-plugin with the umlgraph-doclet to create javadoc for my project. The part from my pom:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<inherited>false</inherited>
<configuration>
<reportPlugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.8</version>
<configuration>
<show>public</show>
<quiet>true</quiet>
<doclet>org.umlgraph.doclet.UmlGraphDoc</doclet>
<docletArtifact>
<groupId>org.umlgraph</groupId>
<artifactId>doclet</artifactId>
<version>5.1</version>
</docletArtifact>
<useStandardDocletOptions>true</useStandardDocletOptions>
<additionalparam>
-inferrel -inferdep -quiet -hide java.* -hide org.eclipse.* -collpackages java.util.* -postfixpackage
-nodefontsize 9 -nodefontpackagesize 7 -attributes -types -visibility -operations -constructors
-enumerations -enumconstants -views
</additionalparam>
</configuration>
<reportSets>
<reportSet>
<reports>
<report>aggregate</report>
</reports>
</reportSet>
</reportSets>
</plugin>
</reportPlugins>
</configuration>
</plugin>
</plugins>
</build>
The images are generated and look fine, when building the javadoc with jdk1.6 they get automatically integrated into all javadoc pages. But when building with jdk1.7, the images still get created but are not inside the javadoc pages. Even when using the v5.4 from the official website, the javadoc is imageless. And the debug output of maven also don't give any clue. On top of that, there is no way of contacting one of the UmlGraph devs by mail.
Can anyone give me some advice here, or have some ideas how to fix that?
Update: version 5.6.6 is now on maven central. I built with JDK 7 and diagrams look ok.
<plugin>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.7</version>
<configuration>
<aggregate>true</aggregate>
<show>private</show>
<doclet>org.umlgraph.doclet.UmlGraphDoc</doclet>
<docletArtifact>
<groupId>org.umlgraph</groupId>
<artifactId>umlgraph</artifactId>
<version>5.6.6</version>
</docletArtifact>
</configuration>
</plugin>
I checked the possibilities, and the situation is following:.
relevant bug in the UmlGraph has been already fixed: https://github.com/dspinellis/UMLGraph/pull/8
problem is however that no stable version of UmlGraph has been released yet that would include the fix
However good news is that there exists snapshot repository containing the fix: https://oss.sonatype.org/content/repositories/snapshots/org/umlgraph/umlgraph/5.5.8-SNAPSHOT/
Therefor you need to get the jar file to your local repository (depending on your infrastructure setup):
either by adding reffered repository to your environment
or by importing to your local repo (http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html)
afterwards update:
<doclet>org.umlgraph.doclet.UmlGraphDoc</doclet>
<docletArtifact>
<groupId>org.umlgraph</groupId>
<artifactId>doclet</artifactId>
<version>5.1</version>
</docletArtifact>
to the following (naming convention has been changed):
<doclet>org.umlgraph.doclet.UmlGraphDoc</doclet>
<docletArtifact>
<groupId>org.umlgraph</groupId>
<artifactId>umlgraph</artifactId>
<version>5.5.8-SNAPSHOT</version>
</docletArtifact>
UmlGraphDoc version 5.4, altering javadocs
Warning, could not find a line that matches the pattern '/H2'
The HTML is simply different.
Java7 JavaDocs
START OF CLASS DATA
h2 title="blah blah
Java6 JavaDocs
START OF CLASS DATA
H2
You can decompile and modify UmlGraphDoc.java
I have the same problem. My guess is that it's this bug:
https://issues.jboss.org/browse/APIVIZ-10
Related
I have a legacy maven project and want to integrate the FindBugs successor SpotBugs to create a report of all issues but fail if there a High priority issues only (for now).
It is easy to create the report only without fail ing or to fail on a specific threshold. But when specifying a threshold all issues below that one are also removed from the report.
I have tried to configure the plugin according to to documentation but without success:
<plugin>
<groupId>com.github.spotbugs</groupId>
<artifactId>spotbugs-maven-plugin</artifactId>
<version>3.1.3</version>
<configuration>
<effort>Max</effort>
<threshold>High</threshold>
<xmlOutput>true</xmlOutput>
<spotbugsXmlOutputDirectory>${project.build.directory}/spotbugs-reports</spotbugsXmlOutputDirectory>
<xmlOutputDirectory>${project.build.directory}/spotbugs-reports</xmlOutputDirectory>
</configuration>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
I am using Maven 3 and SpotBugs 3.1.3.
Not sure if that helps, it's mostly a workaround.
I have a similar case and what I did was that I placed the configuration in a "reporting" tag (not reportSets). In the "build" tag, I just put the plugin information and the dependencies. The configuration used the default values for the output xml and output folder. I also added file which was filtering out some of the bugs:
<build>
<plugins>
<plugin>
<groupId>com.github.spotbugs</groupId>
<artifactId>spotbugs-maven-plugin</artifactId>
<version>3.1.10</version>
<dependencies>
<dependency>
<groupId>com.github.spotbugs</groupId>
<artifactId>spotbugs</artifactId>
<version>3.1.11</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
<reporting>
<plugins>
<plugin>
<groupId>com.github.spotbugs</groupId>
<artifactId>spotbugs-maven-plugin</artifactId>
<version>3.1.10</version>
<configuration>
<excludeFilterFile>spotbugs_filter.xml</excludeFilterFile>
</configuration>
</plugin>
</plugins>
</reporting>
I then did a
mvn clean install site spotbugs:check
This gave me:
a spotbugsXml.xml file in the build_directory containing ALL of the bugs found (no filters applied).
a report spotbugs.html was produced in target/site which contained the filtered list of bugs.
So, to link this with your issue, I guess that using these "steps" you can have two reports, one with the threshold and another one without.
Does this make sense?
I'm just trying to wrap my head around a couple of things.
If I have this in my masterpom:
<reporting>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>2.5.2</version>
<configuration>
<failOnError>false</failOnError>
<threshold>High</threshold>
<effort>Default</effort>
<xmlOutput>true</xmlOutput>
<skip>${skipFindBugs}</skip>
<xmlOutputDirectory>target/reports/findbugs</xmlOutputDirectory>
<excludeFilterFile>
src/main/resources/findbugs-exclude-filters.xml
</excludeFilterFile>
</configuration>
</plugin>
</plugins>
</reporting>
My findbugs-exclude-filters.xml looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<FindBugsFilter>
<Match>
<Bug category="I18N" />
</Match>
</FindBugsFilter>
QUESTIONS
Why does clean verify site report 2 warnings, but clean verify findbugs:check return 14 bugs? I don't understand what the difference is.
Why does my site report warn about I18N:DM_DEFAULT_ENCODING
The findbugs-maven-plugin plugin needs to be configured in BOTH the <reporting><plugins/></reporting> and <build><plugins/></build> section. Have experimented with this all sorts of ways and the only way I have been able to get it to work is to duplicate findbugs-maven-plugin configuration.
So try adding something like the following in your pom.xml:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>2.5.2</version>
<configuration>
<failOnError>false</failOnError>
<threshold>High</threshold>
<effort>Default</effort>
<xmlOutput>true</xmlOutput>
<skip>${skipFindBugs}</skip>
<xmlOutputDirectory>target/reports/findbugs</xmlOutputDirectory>
<excludeFilterFile>
src/main/resources/findbugs-exclude-filters.xml
</excludeFilterFile>
</configuration>
</plugin>
</plugins>
</build>
Note that it's a cut and paste of what you posted inside of the <reporting/> block. I have not tested the above. I'm just trying to give you a general idea here.
The Reporting section of the POM Reference states that:
And the subtler difference is that a plugin configuration under the reporting element works as build plugin configuration, although the opposite is not true (a build plugin configuration does not affect a reporting plugin).
I have been able to make this work with Maven 3.0.5. I have not tried it on 3.1.0 yet.
I have a Maven-built web-app that uses JPA 2.0 at the back end. The JPA provider is EclipseLink 2.3.2.
When I build the project (and it deploys runs successfully) it builds the JPA meta-model in the directory
${basedir}/target/generated-sources/annotations/
Yet the IDE doesn't see the classes defined there. Little red dots with an exclamation point everywhere. Yet I can navigate to those files in the Projects window and open the generated source files.
Does this happen to anyone else and does anyone know of a way to fix it?
UPDATE:
As a work-around I have discovered that I can exit NetBeans, delete the NetBeans cache directory, then restart. This forces NetBeans to rebuild the cache and then the classes become visible again. Should I submit a bug to the NetBeans bug tracker? I can't come up with a test case to make it happen, but it does fairly often.
If you go to project properties/sources there is a note about this: you need to generate sources under
${basedir}/target/generated-sources/FOOBAR
where FOOBAR is the name of your plugin.
After reading #jeqo answer, I tested if, by manually renaming:
"${project.build.directory}/generated-sources/annotations" to ".../generated-sources/hibernate-jpamodelgen"
would make a difference to Nebeans (I'm using v8.2 on ubuntu 16.04).
Everything worked like a charm.
I then modified the pom file as follows:
1) removed the "org.hibernate: hibernate.jpamodelgen" dependency.
2) configured the maven-compiler-plugin as follows:
<plugin>
<groupId>>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.6.1</version>
<configuration>
<compilerArgument>-proc:none</compilerArgument>
</configuration>
</plugin>
These two steps is to make sure that the hibernate-jpamodelgen does
not run on auto-pilot just by adding it in the project dependency
list. Please refer to JPA Static MetaModel Generator doc.
3) added the following plugin with configuration
<plugin>
<groupId>org.bsc.maven</groupId>
<artifactId>maven-processor-plugin</artifactId>
<version>3.2.0</version>
<executions>
<execution>
<id>process</id>
<goals>
<goal>process</goal>
</goals>
<phase>generate-sources</phase>
<configuration>
<processors>
<processor>org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor</processor>
</processors>
<defaultOutputDirectory>${project.build.directory}/generated-sources/hibernate-jpamodelgen/</defaultOutputDirectory>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-jpamodelgen</artifactId>
<version>5.2.9.Final</version>
</dependency>
</dependencies>
</plugin>
This config is directly from the Hibernate JPA Static Metamodel Generator documentation page except for the following line:
<defaultOutputDirectory>${project.build.directory}/generated-sources/hibernate-jpamodelgen/</defaultOutputDirectory>
This line simply generates the metamodel in the directory named after the maven plugin name. From this point, I got all Netbeans references working at design time as if the generated classes were in the src directory subtree.
Hope this helps,
J
Sometimes Netbeans has troubles refreshing. Perhaps clean and rebuild the project and restart Netbeans?
Today I did more experiments on this topic because it is so annoying for me as well. Finally I have realized it is only a problem related how NetBeans deal with indexing classes. This is not a problem of the target directory name and not a problem of the project. It is only NetBeans' mistake. So I have created an issue as well hopefully NetBeans Team can bring the final solution soon. You can see my ticket here https://issues.apache.org/jira/browse/NETBEANS-4191
In my environment the NetBeans 11.3 (x64) with openJDK 1.8.0_242-b08 and apache-maven 3.6.3 version is used under Windows 10 (1607).
But until the final solution arrives here is what I did as a workaround solving the symbol not found problem.
I have added a profile section to my pom file:
<profile>
<id>nb-modelgen-fix</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<id>modelgen-touch-files</id>
<phase>install</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<touch>
<fileset id="model.elements" dir="src/main/java" includes="**/*.java">
<containsregexp expression="(#Entity|#MappedSuperclass|#Embeddable)" casesensitive="yes" />
</fileset>
</touch>
</target>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
I am using the following simple solution to generate the metamodel classes in my project:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<annotationProcessors>
<annotationProcessor>
org.eclipse.persistence.internal.jpa.modelgen.CanonicalModelProcessor
</annotationProcessor>
</annotationProcessors>
<compilerArgs>
<arg>-Aeclipselink.persistenceunits=MY-PU</arg>
</compilerArgs>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
And of course a maven-build-helper adding the generated source folders to the project:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>3.1.0</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/annotations</source>
<source>${project.build.directory}/generated-sources/wsimport</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
And also I have created a file in the same place where the pom.xml is located called nbactions.xml with the following content (to activate this profile in NetBeans IDE only)
<?xml version="1.0" encoding="UTF-8"?>
<actions>
<action>
<actionName>rebuild</actionName>
<packagings>
<packaging>*</packaging>
</packagings>
<goals>
<goal>clean</goal>
<goal>install</goal>
</goals>
<activatedProfiles>
<activatedProfile>nb-modelgen-fix</activatedProfile>
</activatedProfiles>
</action>
</actions>
What it does? When you execute the "Clean and Build" action in NetBeans IDE it activates a task (implemented easily with maven-antrun-plugin) which just a simple touch on all JPA annotated with #Entity, #MappedSuperClass or #Embeddable theese are the sources for the metamodel generations. I have attached this task to the install phase but it worked as well in other phases as well. It lookes that this way NetBeans wake up and makes for the missing indexes for the metamodel classess.
You can read more on this in my NetBeans' issue ticket.
I hope this can save time for anybody else.
If you are using jaxws then make sure you add a <sourceDestDir> node to the <configuration> section of the jaxws plug-in "artifact" in the appropriate pom. For example:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>dojaxws</goal>
</goals>
<configuration>
<sourceDestDir>${project.build.directory}/generated-sources/jaxws</sourceDestDir>
....
</configuration>
</execution>
</executions>
<configuration>
<wsdlDirectory>src/main/resources/com/mystuff/ws</wsdlDirectory>
<bindingDirectory>src/jaxws/binding</bindingDirectory>
<target>2.0</target>
</configuration>
</plugin>
As explained above and as noted by netbeans, you must use the generate-sources path appended with the "plug-in" name. Hopefully the above clears up what "plug-in name" means and how exactly one is supposed to get jaxws to put the generated sources where netbeans need them to be. Clearly the "configuration" section will be different for each plugin... The node <sourceDestDir> is needed for jaxws, other plugins may use something else.
For me it worked after I added <endorsed.dir>${project.build.directory}/endorsed</endorsed.dir> to the <properties> of the pom.xml, e.g.:
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<endorsed.dir>${project.build.directory}/endorsed</endorsed.dir>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<jakartaee>8.0</jakartaee>
</properties>
But I have no explanation why.
How can I make resources like .gitignore be part of the resulting project?
create archetype with archetype-resources/.gitignore
mvn install
mvn archetype:generate
resulting project doesn't contain .gitignore
PS. I'm sure it isn't there.
The bug seems to be still present in the maven-archetype-plugin v3.0.1 .
For those who do not want to downgrade the maven-resource-plugin. I managed to establish a more or less ugly workaround.
First you rename the archetype-resources/.gitignore to
__gitignore__
then inside the archetype-metadata.xml add
<requiredProperties>
<requiredProperty key="gitignore">
<defaultValue>.gitignore</defaultValue>
</requiredProperty>
</requiredProperties>
<fileSets>
<fileSet>
<directory></directory>
<includes>
<include>__gitignore__</include>
</includes>
</fileSet>
</fileSets>
When the archetype is generated maven will now first copy the __gitignore__ then sees the __[file]__ syntax and will replace it with the default value ".gitignore"
This solution for upcoming maven-resources-plugin v3.0.0 (not yet released at the time of posting this; current is still 2.7) from https://issues.apache.org/jira/browse/MRESOURCES-190 seems better than holding back version upgrades:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<configuration>
<!-- Required so that .gitignore gets included in archetypes; see https://issues.apache.org/jira/browse/MRESOURCES-190 -->
<addDefaultExcludes>false</addDefaultExcludes>
Add a fileSet entry to src/main/resources/META-INF/maven/archetype-metadata.xml with an empty directory tag:
<fileSet>
<directory></directory>
<includes>
<include>.gitignore</include>
</includes>
</fileSet>
This will copy the included files from src/main/resources/archetype-resources to the project root directory.
Check your maven-resources-plugin version by launching the Maven build on debug (with -X option). If you use 2.7, there is a regression where .gitignore files are silently ignored.
In this case, you will have to explicitly use 2.6 in your pom.xml:
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
</plugin>
</plugins>
</pluginManagement>
</build>
ARCHETYPE/issues/ARCHETYPE-505 shows that this is thoroughly broken with current versions of the plugin and maven. No workarounds help anymore with this.
Solution that worked perfectly for me was to use archetype post install groovy script.
Create a file META-INF/archetype-post-generate.groovy in the resources folder of your archetype project.
Add this code:
file = new File( request.getOutputDirectory(), request.getArtifactId()+"/.gitignore.tmpl" );
def gitIgnorefile = new File( request.getOutputDirectory(), request.getArtifactId()+"/.gitignore" );
file.renameTo(gitIgnorefile)
In your archetype-metadata.xml file include the template .gitignore.tmpl file.
<fileSet>
<directory/>
<includes>
<include>.gitignore.tmpl</include>
</includes>
</fileSet>
I had problems with maven resource plugin hence used groovy script solution.
While looking for a solution for this problem, went to the FAQ section of the maven-archetype-plugin, and, apparently, version 3.2.1 supports such case, i.e, we can now include .gitignore.
For that, config maven-resources and maven-archtype-plugin:
<plugins>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<configuration>
<addDefaultExcludes>false</addDefaultExcludes>
</configuration>
</plugin>
<plugin>
<artifactId>maven-archetype-plugin</artifactId>
<configuration>
<useDefaultExcludes>false</useDefaultExcludes>
</configuration>
</plugin>
</plugins>
Note: I used version 3.3.0 for the maven-resources-plugin and version 3.2.1 for the maven-archetype-plugin.
Source:
https://maven.apache.org/archetype/maven-archetype-plugin/faq.html#excludes
Alternative for downgrading maven-resources-plugin is to enforce plexus-utils version which actually has a regression:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.7</version>
<dependencies>
<!-- it's for fixing maven-resources-plugin 2.7 MRESOURCES-190 -->
<dependency>
<groupId>org.codehaus.plexus</groupId>
<artifactId>plexus-utils</artifactId>
<!-- this is last 2.x release -->
<version>2.1</version>
</dependency>
</dependencies>
</plugin>
the bug is still in the newest maven-archetype-plugin 2.4 and maven-resources-plugin 3.0.1.
here is the solution:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-archetype-plugin</artifactId>
<version>2.2</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
</plugin>
and in your generate pom.xml you should add
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
</plugin>
I've got a taglib project that I use the TLDGen library to help build my TLD files from annotations in my classes. I've then got it plugged into the Maven JavaDoc plugin to have it build the TLD files via the javadoc:javadoc Maven goal. Pom portion that handles this is as follows:
<build>
...
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.7</version>
<configuration>
<doclet>org.tldgen.TldDoclet</doclet>
<docletArtifact>
<groupId>com.google.code.tldgen</groupId>
<artifactId>tldgen-all</artifactId>
<version>1.0.0</version>
</docletArtifact>
<show>private</show>
<additionalparam>-name test
-uri "http://www.mycompany.com/tags/wibble"
-tldFile ..\..\..\src\main\resources\META-INF\w.tld
</additionalparam>
<useStandardDocletOptions>true</useStandardDocletOptions>
<author>false</author>
<encoding>utf-8</encoding>
</configuration>
</plugin>
</plugins>
</build>
And this works fantastically. Trouble is that I know want to create 2 TLD's from this project. I can pass a -subpackages attribute in th addtionalparam element so I can produce a TLD with exactly what I want.
But I can only have one configuration element at that point. I've tried moving the configuration into the reporting section in my pom with two reportsets to see if that helps but no luck.
Has anyone ever attempted this before and can help point me in the right direction for getting it right? Cheers!
It's been a while since this question was posted, but here's how I did multiple tld generation with TLDGen. I started from your question, since the guys over at the project used your answer as a reference :).
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.7</version>
<configuration>
<includes>
<include>**</include>
</includes>
<doclet>org.tldgen.TldDoclet</doclet>
<docletArtifacts>
<!-- listing all dependencies for tldgen:
the tldgen library, commons-logging, commons-io,
commons-lang, geronimo-jsp_2.1_spec, log4j, saxon, stax
not sure if they have to be listed here, will have to check; if I
don't set them I get class not found errors, but I'm guessing I
have a misconfiguration -->
</docletArtifacts>
<show>private</show>
<additionalparam>
-htmlFolder ${basedir}/target/docs
-tldFolder ${basedir}/src/main/java/META-INF
-license NONE
</additionalparam>
<useStandardDocletOptions>true</useStandardDocletOptions>
<author>false</author>
<encoding>utf-8</encoding>
</configuration>
<dependencies>
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jsr173_api</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
<executions>
<execution>
<phase>generate-resources</phase>
<goals>
<goal>javadoc</goal>
</goals>
</execution>
</executions>
</plugin>