Using Maven for maintaining user documentation [closed] - pdf

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
We are using Maven for building a Java server-style application. It consists of several modules (in a single Maven "reactor") which can be plugged together to generate a final product (essentially a .jar) with the features enabled that the customer needs. All the internals are documented using JavaDoc and all, but that's not what you can give to the customer to find out how to get the thing running. Currently we have an OpenOffice document which serves as end-user documentation.
I'd like to integrate this documentation into the Maven build process where each module's documentation is maintained (hand-edited) together with the Module's sources and the final document can reference the required Module documentation sections, add some friendly foreword and, if possible at all, can reference into the JavaDocs. Ultimately, the document should be output as a PDF.
Is there any experience on Maven plugins can help with this? Is DocBook the right tool? Maybe Latex? Or something completely different? A sound "stick with OpenOffice and some text blocks" could be an answer, too.

I'm assuming you haven't looked at the Maven site documentation generation yet with the maven-site-plugin. It's pretty robust and will allow you to incorporate and include the JavaDoc generation as well as the content from your OpenOffice document.
While the site documentation doesn't output as a PDF, it does however output as a static HTML website that has lots of capabilities built in. Using Maven profiles, you could configure Maven to generate one site for internal use that includes Surefire test results and other reports for checks like Checkstykle and PMD. In another profile, you could configure it to only generate the documentation necessary for distribution to the clients that doesn't include the internal reports that the clients may not care about.
One note though, much of the site documentation generation is changing for Maven 3. While most of Maven 3 is backwards compatible with Maven 2, be mindful of the reporting changes for Maven 3. Check out these links:
Site Generation Compatibility
Converting maven-site-plugin for
Maven 3

And in case the site plugin with external docs does not produce a high enough quality, you can use docbook with Maven to produce HTML and PDF output. In fact Sonatype does that for all their books (e.g. Maven: The Complete Reference, Nexus book, M2Eclipse book...) and they are open source so you can see how it all works and copy the setup and modify it for your needs. The advantage of using docbook is that the tooling is pretty good (xmlmind for example) and that it produces print quality books with index, toc and so on.
Oh and since you mentioned it there is also a LaTeX plugin for Maven but I have no experience with it (but quite a bit with LaTeX prior to my Maven usage...)

Another solution is the Maven docbkx plugin for conversion of DocBook into PDF; HTML, etc.
Read this description on how to add the converted DocBook to HTML to a Maven project site, if you would like to see your DocBook content also appear in the Maven generated site.
Interesting related questions:
What is the recommended tool chain for formatting XML DocBook?.

I have a multi-module maven project in which each module has it's own reference-manual written in docbook format. And then I have a general reference manual, also written in docbook that includes the others so I am re-using the documentation.
When I execute mvn site, the project generates HTML and PDF files with all the reference manuals and they are neatly integrated into the maven site.
For this I use the docbkx plugin. I think it really rocks. Here is the plugin configuration:
<plugin>
<groupId>com.agilejava.docbkx</groupId>
<artifactId>docbkx-maven-plugin</artifactId>
<executions>
<execution>
<id>docbook-HTML</id>
<phase>pre-site</phase>
<goals>
<goal>generate-html</goal>
</goals>
<!-- HTML configuration -->
<configuration>
<generateToc>false</generateToc>
<targetDirectory>${project.build.directory}/site</targetDirectory>
<htmlCustomization>${basedir}/src/site/docbkx-config/docbook-html.xsl</htmlCustomization>
<htmlStylesheet>./css/apache-maven-fluido-1.3.0.min.css</htmlStylesheet>
<chunkedOutput>false</chunkedOutput>
</configuration>
</execution>
<execution>
<id>docbook-PDF</id>
<phase>pre-site</phase>
<goals>
<goal>generate-pdf</goal>
</goals>
<!-- PDF configuration -->
<configuration>
<generateToc>true</generateToc>
<paperType>A4</paperType>
<imgSrcPath>file:///${basedir}/src/site/resources/</imgSrcPath>
<calloutGraphicsPath>file:///${basedir}/src/site/resources/images/callouts/</calloutGraphicsPath>
<calloutGraphicsExtension>.svg</calloutGraphicsExtension>
<calloutGraphicsNumberLimit>30</calloutGraphicsNumberLimit>
<calloutIconSize>6</calloutIconSize>
<shadeVerbatim>true</shadeVerbatim>
<targetDirectory>${project.build.directory}</targetDirectory>
<foCustomization>${basedir}/src/site/docbkx-config/docbook-fo.xsl</foCustomization>
<!-- <bodyFontFamily>Kaffeesatz</bodyFontFamily>
<monospaceFontFamily>LiberationMono</monospaceFontFamily>
-->
<fonts>
<font>
<name>Kaffeesatz</name>
<style>normal</style>
<weight>normal</weight>
<embedFile>${basedir}/src/fonts/YanoneKaffeesatz-Regular.ttf</embedFile>
<metricsFile>${basedir}/target/fonts/YanoneKaffeesatz-Regular-metrics.xml</metricsFile>
</font>
<font>
<name>LiberationMono</name>
<style>normal</style>
<weight>normal</weight>
<embedFile>${basedir}/src/fonts/LiberationMono-Regular.ttf</embedFile>
<metricsFile>${basedir}/target/fonts/LiberationMono-Regular-metrics.xml</metricsFile>
</font>
<font>
<name>VeraMono</name>
<style>normal</style>
<weight>normal</weight>
<embedFile>${basedir}/src/fonts/VeraMono.ttf</embedFile>
<metricsFile>${basedir}/target/fonts/VeraMono-metrics.xml</metricsFile>
</font>
</fonts>
</configuration>
</execution>
</executions>
<!-- Shared configuration -->
<configuration>
<sourceDirectory>${basedir}/src/site/docbkx</sourceDirectory>
<includes>*.xml</includes>
<xincludeSupported>true</xincludeSupported>
<generatedSourceDirectory>${project.build.directory}/site</generatedSourceDirectory>
<highlightSource>1</highlightSource>
<calloutGraphics>true</calloutGraphics>
<!-- DEFAULT HTML CONFIG -->
<targetDirectory>${project.build.directory}/site</targetDirectory>
<htmlCustomization>src/site/docbook-config/docbook-html.xsl</htmlCustomization>
<htmlStylesheet>css/apache-maven-fluido-1.3.0.min.css</htmlStylesheet>
<!-- // DEFAULT HTML CONFIG -->
</configuration>
</plugin>
You can check out my project site here and you can even download the sources into your computer and see how the whole thing is set up.
If you have any questions don't hesitate to reach out.
Hope it helps
Cheers
Carlos

Related

How to share karate html reports to others without sending as zip. If only html single file is sent then it shows as plain file [duplicate]

After running a test case with Karate, some html reports are published with surefire plugin. In particular, I've found that there is an html report for each feature file. This is inconvenient when tests are run from an automated pipeline, like in my case, where I use htmlpublish Jenkins plugin to get a public link to access reports and spread them across slack channels or emails.
I've tried to add this snippet in my pom.xml
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-report-plugin</artifactId>
<version>2.4.2</version>
<configuration>
<aggregate>true</aggregate>
<!--also set this to link to generated source reports-->
<linkXRef>true</linkXRef>
</configuration>
</plugin>
But it had not the desired effect.
I'm trying to achieve a single index.html into the target/surefire-reports directory so i can publish and browse all test reports
Any suggestion?
Thanks
Are you using the parallel runner ? If not, please read up about it: https://github.com/intuit/karate#parallel-execution
Since we emit the cucumber-compatible JSON report in addition to the industry-standard JUnit XML format, you have the choice of any reporting solution that fits your needs. I think the maven-cucumber-reporting library should work for you - but you can decide: https://github.com/intuit/karate/tree/master/karate-demo#example-report
EDIT: For any other advanced needs, please consider writing your own report: https://stackoverflow.com/a/66773839/143475

In maven, what is the difference between main/resources and main/config?

I want to put a configuration file in my Maven project. Looking at the standard directory layout, there are two places that seem sensible, "src/main/resources" and "src/main/config". Could someone explain the difference between these, and explain when you would put something in config and when in resources?
In this case, the file I'm looking at is ehcache.xml, but my question isn't ehcache specific, I'm curious for log4j.properties etc.
A bit of googling discovered this person had the same question, but the answers seemed contradictory, and not very authorative.
The email exchange at http://www.mail-archive.com/users#maven.apache.org/msg90985.html
says:
"This is all theory... Perhaps while writing the docs, someone involved with Maven development thought it might be useful to have a src/main/config directory and so it was included in docs, but since it was never implemented in the code, it is not being used today."
and
"The directory [src/main/config] doesn't show up on the classpath so the application or test classes
can't read anything in it."
So just use src/main/resources.
Note: I don't know if this is true (I'm the question asker), but that would explain why so many people on the web recommend src/main/resources for log4j.properties. If people agree this is the right answer could you let me know (comment or vote) I put it here to save other people the typing.
scr/main/resources is a place where you put your images, sounds, templates, language bundles, textual and binary files used by the source code. All config files like excache.xml, log4j.properties, logback.xml and others go to src/main/config.
Add to your pom.xml:
<build>
<resources>
<resource>
<targetPath>.</targetPath>
<directory>src/main/config</directory>
</resource>
</resources>
</build>
The inclusion of src/main/config in Maven's standard directory layout has been removed due in part to the confusion caused between src/main/config and src/main/resources. This very stackoverflow question is actually referenced in the JIRA ticket for the removal of src/main/config from Maven's standard.
Short answer: Use src/main/resources not src/main/config. It's the (new) Maven way.
Use case is pretty straightforward if you ask me. (It seems src/main/config has since been removed standard directory layout)
/src/main/resources go on into jar and thus on classpath
/src/main/config is intended for assembly plugin where you might construct a
zip file:
hello-world.zip
lib/
<dependencies>
bin/
run.bat
run.sh
config/
config.properies

Maven Checkstyle Plugin - Test XREF

My maven reports are working great, all except Checkstyle and test xref. My test source is still being cross referenced at xref and not the test xref. So, when I click on the xref from within a Checkstyle report, I naturally get an error, the file isn't found. If I click on a source file, it works perfectly.
I tried testXrefLocation in the configuration to no avail. Is this by design, or am I missing a configuration?
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<configuration>
<enableRulesSummary>false</enableRulesSummary>
<includeTestSourceDirectory>true</includeTestSourceDirectory>
<configLocation>${project.build.directory}/checkstyle.xml</configLocation>
<testXrefLocation>${project.reporting.outputDirectory}/xref-test</testXrefLocation>
</configuration>
</plugin>
mvn clean install site
In my target directory where all this stuff is generated, I have both xref and xref-test. However, my checkstyle reports for my test source code are still linked to target/xref and not target/xref-test.
Also, FYI, I am using a lot of inheritance to reduce the amount of configuration in a single Maven POM. Therefore, this plugin belongs to a parent pom which declares which plugins I want to use for testing. I have another that says I want to generate javadoc and source in addition to the compiled code.
Walter
I actually ended up removing this configuration in favor of using Sonar since it gives me much more information with a nicer UI.

How do you use the maven-simian-plugin in Maven2?

I'm looking for a Maven2 reporting plugin for Simian and the closest thing to such a reporting I found is this. The problem is, the documentation for it appears to be for Maven 1 instead. Why is a Maven 1 plugin stored in a Maven 2 repository? I suppose that means I can use it... but how to use? The site mentions reporting but if I don't have a src/main/site, does that mean I can't use it? I was kinda hoping for something like mvn simian:simian similar to mvn checkstyle:checkstyle and mvn pmd:pmd. I don't want to generate site just for the reports. Sites take too long to generate when all I want is a quite xml report.
The Simian plugin listed on central is actually for Maven 1 (if you inspect the contents you'll see a project.xml and a plugin.jelly). So that explains why it doesn't work. This is rubbish and should be removed in my opinion.
As far as I can make out there isn't a publically available Maven 2 plugin, this may have something to do with the licence (Simian isn't open source).
As an alternative, have a look at PMD's CPD plugin, it may not be as fully featured as simian but I know it works in a Maven 2 build and detects copypasta pretty well.
To configure PMD, add something like the following to your POM:
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>2.4</version>
</plugin>
</plugins>
</reporting>

Creating documentation with maven

I'm just in the middle of revisiting maven. Our team had a bad experience when we last looked at this, as it was during the period when maven was rearchitecting from 1.x to 2.x, so a lot of the dependencies we needed hadn't been moved across to the new repositories. However, I have the time to reconsider now.
I am interested in using maven and either LaTeX or DocBook for creating documentation, and I was wondering if anyone had any experiences to share, project/module structure, good plugins to use, etc...
Many thanks :-)
Edit:
Just to clarify, I was looking to write a technical article/book, and my desired artifact would probably be a PDF.
DocBook is one of the many supported inputs to Doxia, the engine used to generate docs by maven. Refer here: http://maven.apache.org/doxia/modules/index.html
In fact, the Doxia site answers your exact question: http://maven.apache.org/doxia/book/index.html
You can easily create a site (that contains documentation) with Maven using the mvn site command (i.e. using the plugin site).
This plugin creates technical reports (such as Javadoc, Unit tests reports, code coverage...) but can be also used to create a "real site".
You have more details about that in this page.
Basically, you write your page using APT (Almost Plain Text which is quite simple to understand), or a XML-based format, Xdoc.
2 years ago, I create a complete user guide for one application I developed, using the XDoc format and the Site Maven plugin. Globally, it was quite easy to create!
I hope this will help you!
I've been using with success the Maven plugin Docbkx. You should give it a try
Docbkx
You should definitely take a look at the Maven Docbkx Plugin. It probably fits your needs. Doxia's support of DocBook is -uhm- suboptimal. In fact, last time I tried it, it generated something new that - as far as I could tell - wasn't DocBook.
The Maven Docbkx Plugin that I'm referring to supports all the customizations of the world (through plugin parameters, or XSLT overrides, if you're into that) + it features some mechanisms to integrate it with the Maven build. (Such as processing instructions for including Maven pom properties into your documents.)
Note that the ambition is to have a plugin that prevents you from having to manually put together a processing chain yourselves. So this plugin will both do the transformation to FO, and transforming that to PDF.
I recently implemented the project documentation for my maven multi-module project using docbook and the docbkx plugin for maven. I now have it automatically generating html and pdf files every time I build the project site. I think docbkx really rocks, so I would suggest you use that.
Its true -you can create a very nice site just using the maven site and doxia plugins. In fact I'm using those two to generate my project site, But doxia support for docbook is very limited and doesn't let you modularize documentation, including parts of documents in a main document, for instance. So for the big reference-manuals I'm using docbkx.
If you want to take a peek, my project is here. You can actually download the source and see the nitty gritty of it. And, of course, if you have any question regarding this setup, i'll be more than glad to help.
Cheers
Carlos
Although the question is quite old I want to give an update on this. If you want to use LaTeX for your documentation you should use a maven plugin to generate the documentation. There are a couple of maven-plugins doing this but a lot of them are not maintained anymore.
There is a new maven-plugin which requires none or less configuration to get it working and the generated PDF (or PS or DVI) can be published as artifact.
Have a look at: mathan-latex-maven-plugin
There is AFAIK no official or semi-official plugin that will process LaTeX or DocBook, but what you could do (besides using the aforementioned site plugin) is to configure the exec plugin to process your LaTeX/DocBook sources during the site lifecycle, i.e. at the same time that the project's website is built.
E.g., something like
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<executions>
<execution>
<id>latex</id>
<goals>
<goal>exec</goal>
</goals>
<phase>site</phase>
<configuration>
...
</configuration>
</execution>
</executions>
</plugin>