My team is working on a webservice project, and I am working on creating the documentation for the web service API. I have used a custom JavaDoc doclet to create two xml outputs of the available methods, one for internal developers and one for external developers.
Now, we are using the Jboss Maven Jdocbook plugin to create a DocBook output, along with other xml files, to create a users guide for our webservices.
What I want to do is run the Maven JdocBook plugin twice, once using the internal methods and once on the external methods, to create two separate users guides for either internal or external developers, using two different master.xml files. The pom file:
<build>
<defaultGoal>generate</defaultGoal>
<plugins>
<plugin>
<groupId>org.jboss.maven.plugins</groupId>
<artifactId>maven-jdocbook-plugin</artifactId>
<extensions>true</extensions>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<formats>
<format>
<formatName>html</formatName>
</format>
<format>
<formatName>html_single</formatName>
</format>
</formats>
</configuration>
<executions>
<execution>
<id>internal</id>
<phase>compile</phase>
<configuration>
<baseOutputDirectory>../../Test/JavaDocTest/internal/</baseOutputDirectory>
<sourceDocumentName>masterInternal.xml</sourceDocumentName>
</configuration>
</execution>
<execution>
<id>external</id>
<phase>compile</phase>
<configuration>
<baseOutputDirectory>../../Test/JavaDocTest/external/</baseOutputDirectory>
<sourceDocumentName>masterExternal.xml</sourceDocumentName>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.jboss.maven.plugins</groupId>
<artifactId>maven-jdocbook-style-plugin</artifactId>
<version>1.0.0</version>
<extensions>true</extensions>
</plugin>
</plugins>
The problem I am running in to is that unless I put the sourceDocumentName in the base configuration (outside of the execution section and in the section with the formats) the build does not recognize the different source document name. The standard master file is called master.xml, and on compiling in NetBeans, it says it is looking for master.xml, which it can't find because it does not exist, and then skips the generation.
It is appearing to just skip the execution sections altogether, as when I try to run the build with multiple executions (such as above) it still just runs once. Any ideas why it's skipping the execution sections?
I believe it might have something to do with the phase tag of the execution, but according to http://www.jboss.org/maven-jdocbook-plugin/ there are only a few phases (process-resources, compile, package, install, deploy), and I've tried all of them and none of them seem to work.
Thanks in advance.
My group figured out that you need to set sourceDocumentName in the main configuration area. It turns out that the docbook is generated once using the main config section, and then it looks for any other executions and runs those using the specific sub-configuration for that execution.
Hope this helps someone in the future.
Related
I have read up on the limited information regarding com.alexnederlof jasperreports-plugin and I'm looking to convert my current ant build to use this maven plugin, but there doesn't seem to be any documentation available.
My biggest concern is run-time: If I use this plugin at build-time, what version of jasper-reports do I need to use at run-time?
Am I missing a reference somewhere? As the old adage goes, "If there isn't any documentation, then I guess I'll have to write it."
I am not sure of what you are after but, I am using this plugin in maven to generate the source .jrxml files to .jasper files and the configuration in pom goes like this:
<plugin>
<groupId>com.alexnederlof</groupId>
<artifactId>jasperreports-plugin</artifactId>
<version>2.3</version>
<executions>
<execution>
<phase>process-sources</phase>
<goals>
<goal>jasper</goal>
</goals>
</execution>
</executions>
<configuration>
<!-- These are the default configurations: -->
<compiler>net.sf.jasperreports.engine.design.JRJdtCompiler</compiler>
<sourceDirectory>src/main/jasperreports</sourceDirectory>
<outputDirectory>${basedir}/src/main/webapp</outputDirectory>
<outputFileExt>.jasper</outputFileExt>
<xmlValidation>true</xmlValidation>
<verbose>false</verbose>
<numberOfThreads>4</numberOfThreads>
<failOnMissingSourceDirectory>true</failOnMissingSourceDirectory>
<sourceScanner>
org.codehaus.plexus.compiler.util.scan.StaleSourceScanner
</sourceScanner>
</configuration>
</plugin>
Hope this helps
I'm new to Serenity and BDD. I've a small demo project based on Serenity-Cucumber and Page Based model. Below is the structure of the project:
The Login and Logout features have around 8 scenarios.
I want to be able to run the feature files in parallel. What is the easiest and most effective way to achieve this?
So far I have
Created separate Runner class for each feature and then used failsafe or surefire plugin - This is something I don't want as I don't want a new runner for each feature file.
Used the "cucumber-vm-parallel-plugin". I copy pasted below code in my pom file. Nothing happened.
<plugin>
<groupId>com.github.temyers</groupId>
<artifactId>cucumber-jvm-parallel-plugin</artifactId>
<version>1.0.1</version>
<executions>
<execution>
<id>generateRunners</id>
<phase>validate</phase>
<goals>
<goal>generateRunners</goal>
</goals>
<configuration>
<glue>com.automationrhapsody.cucumber.parallel.tests</glue>
<featuresDirectory>src/test/resources/com</featuresDirectory>
<cucumberOutputDir>target/cucumber-parallel</cucumberOutputDir>
<format>json,html</format>
<tags>"~#ignored"</tags>
</configuration>
</execution>
</executions>
Looked into Serenity documentation and ran my program using following parameters, but could not achieve parallel execution.
mvn verify -Dthucydides.batch.count=2 -Dthucydides.batch.number=2
I'm stuck over here. Any help (easy and effective) will be appreciated.
Also, please suggest how options 2 and 3 above can be done correctly
Thanks.
You also need to add below plugin.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.19</version>
<configuration>
<forkCount>5</forkCount>
<reuseForks>true</reuseForks>
<includes>
<include>**/*IT.class</include>
</includes>
</configuration>
</plugin>
I found this description but it does not seem comprehensive. Could someone explain in detail what is the difference between executions and configurations in a maven plugin?
An <execution> causes the plugin to be executed during the maven build lifecycle, i.e. during your build. The <configuration> allows you to configure the plugin for how it should behave during execution. Many Maven plugins provide documentation about their configuration options, e.g. the maven-compiler-plugin.
You can define <configuration>s on the <plugin> level or the <execution> level. The former is globally valid for all executions, the latter is specific to the execution.
Example for global an execution-specific configurations:
Suppose, you have to compile your project with Java 1.7 but you want to early adopt Java 9 Jigsaw features and add a module-info.java to your project. This Java file will not compile using source level 1.7. What you can do is define two executions of the maven-compiler-plugin, one that compiles everything except module-info.java with source level 1.7 and one that does only compile module-info.java with source level 1.9:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.3</version>
<!-- Global plugin configuration for source and target levels. -->
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
<executions>
<!-- Compile all code except module-info.java with the configured source level -->
<execution>
<id>default-compile</id>
<phase>compile</phase>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<excludes>
<exclude>module-info.java</exclude>
</excludes>
</configuration>
</execution>
<!-- Compile module-info.java with source level 1.9 -->
<execution>
<id>compile-module-info-java</id>
<phase>compile</phase>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<source>1.9</source>
<target>1.9</target>
<includes>
<include>module-info.java</include>
</includes>
</configuration>
</execution>
</executions>
</plugin>
I think answer from #Stefan is already quite clear. I would like to be even a bit more verbose in case it helps.
"execution" under plugin is declaring "what should be done at when". Basically, an execution usually at least contains: phase and goal (I know you don't always see it in config, but conceptually they are there), which you can see it as: When the build process reached phase, then the goal action of the plugin will be executed.
Of course, you can have multiple executions for a plugin, so that different/same goals can be run in different/same phases.
Then come to configuration. Sometimes you need to tell the plugin extra detail on how the plugin should act on because the plugin may not be able to guess what you want to do by default. configuration is doing such work. You can refer to document of plugin's goal to see what kind of configuration they accept.
Plugin level configuration will be applied to all executions of the plugin, while you can also define configuration under each execution, which serve as execution-specific configuration. Plugin-level configuration + execution-level configuration is the "real" configuration received by an execution.
A <configuration> section outside an <execution> block affects the plugin's behavior in general way. For instance, plugins that are either executed directly through the CLI or have a default phase that they bind to will use this type of configuration. An example of such a plugin would be the compiler plugin.
On the other hand, a <configuration> section inside an <execution> block only applies to that specific execution.
As always, a more specific configuration can override a general configuration. So if a general configuration (outside an execution block) says <doCheck>false</doCheck>, an execution might choose to only override this by doing <doCheck>true</doCheck>.
Another feature of general configurations is that their parameters will be inherited by all executions of that plugin.
Sometimes, my Talend Open Studio components have resources but not Java sources (they are purely metadata components). I need to disable the generation of JAR files in such a case.
I configured the maven-jar-plugin this way:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<configuration>
<forceCreation>false</forceCreation>
<skipIfEmpty>true</skipIfEmpty>
<useDefaultManifestFile>false</useDefaultManifestFile>
</configuration>
</plugin>
but I still get the ${project.name}.jar file with pom.properties, pom.cml, the manifest and an empty file App.class containing only "class {}"
While I can disable the includes of all maven stuff using this:
<archive>
<addMavenDescriptor>false</addMavenDescriptor>
</archive>
I still get a JAR with the manifest file inside it
Are there some configuration parameters I misconfigured?
Most efficient way to disable the creation of jars is to configure the maven-jar-plugin like this:
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.1</version>
<executions>
<execution>
<id>default-jar</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
</plugins>
It will place the default jar creation in the none phase, it will never be run.
I found the solution by myself, even if it's only a workaround. I delete the JAR using a delete antrun task if /src/main/java directory doesn't exist:
<!-- remove the empty JAR if not needed -->
<if>
<not><available file="${basedir}/src/main/java" type="dir" /></not>
<then>
<delete file="${project.build.directory}/${project.name}-${project.version}.jar"/>
</then>
</if>
this task requires antcontrib to work properly and, ofc, it doesn't work if you plan to do releases with maven (but it's ok for metadata-only components, like Talend Open Studio plugins)
You can instruct maven-jar-plugin to not generate META-INF/maven/*/pom. files, as explained in Maven Archiver Reference.
Also, you can use its skipIfEmpty option.
Following code combines both these (just to have them copy-paste ready):
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<configuration>
<skipIfEmpty>true</skipIfEmpty>
<archive>
<addMavenDescriptor>false</addMavenDescriptor>
</archive>
...
This works fine, but when you do mvn install, it fails due to missing project artifact.
Similar problem will probably be with mvn deploy and with release, but I didn't check these.
However, if you can live with antrun's delete, the property skipIfEmpty will probably work well for you, and is a bit more elegant. At least it does not introduce a new execution and its dependencies etc.
I'm building a service which contains a client module which is using Spring. The service which will be implementing the client does not contain spring but it has a dependency on the client which has dependencies on Spring. Ideally I would like the client to include the needed Spring dependencies in the JAR but I can't seem to figure out how to accomplish this. I've seen a few different examples of using maven-assembly-plugin but I would prefer to not have to use something other than "mvn clean package" to accomplish this.
Any help is appreciated.
The maven-shade-plugin allows you to build an uber-jar containing some (or all) of your dependencies. It should allow you to do what you need.
By binding the assembly plugin's single goal to the project's build lifecycle, you can accomplish what you want by running mvn clean package.
Cut/pasting the pom configuration to do this from the usage page of the plugin,
<project>
[...]
<build>
[...]
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2.2</version>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
<executions>
<execution>
<id>make-assembly</id> <!-- this is used for inheritance merges -->
<phase>package</phase> <!-- bind to the packaging phase -->
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
[...]
</project>
Of course, you would tweak either either to use a different predefined descriptor or even use a separate descriptor file.