Maven generate-source ALWAYS Successful - maven

I am trying to run a ant task in maven generate-sources phase.
However, after many non productive "successes" i've realised, that the build always succeeds regardless of anything i enter.
Here is the plugin config for the pom.xml of my module.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<configuration>
<tasks>
<fail message="Something wrong here."/>
</tasks>
</configuration>
<phase>generate-sources</phase>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
It still succeeds. If i place a bad ant file. Still succeeds.
Does anyone know what i could be doing wrong here?
The Compile/Clean/Install/Deploy phases all work fine. Just "generate-source" doesnt work at all.
My settings.xml file only contains Repo information
Thanks for any advice
Edit:
I've been able to narrow the error down a little.
<configuration>
<target>
<echo message="hello ant, from Maven!"/>
<echo>Maybe this will work?</echo>
</target>
</configuration>
If place that within the configuration of the plugin, Not in the nested configuration in the execution tag. and run "mvn antrun:run" I see the echos. However If i place it in the nested configuration in the execution element, it doesnt show... Is there some link missing between my mvn goal and the antrun instruction?
I don't get it. The same configuration runs outside of the executions/execution tags, but not within.

Solution *Solution* Solution
AHHH I found it!
In my pom.xml I had all my 'plugins''plugin' configured under the 'pluginManagement' .. This 'pluginManagement' configures the plugins not for this project, but for all children project. Effectively a parent default config file for all children implementing the plugin.. I simply removed the 'pluginManagement' tags and it works...
Thank heavens. I've been looking at this for a full day...

Try adding <failOnError>false</failOnError> to the execution.
Per the documentation, this parameter "specifies whether a failure in the ant build leads to a failure of the Maven build. If this value is 'true', the Maven build will proceed even if the ant build fails. If it is 'false', then the Maven build fails if the ant build fails."
This is counterintuitive to me. I would think that the default value of "true" would cause the Maven build to fail if the ant build failed, but that isn't what the docs appear to be saying.

Related

Maven : exclude target/generated-sources from compilation

This question, just to be sure my interpretation is correct :
I'm using Mojohaus jaxb2-maven-plugin to generate java classes from .xsd files, and by default it puts them in target/generated-sources
Now, I want to get track of these classes in source control (target is of course excluded), and I may one day slightly customize one with an annotation or a line of code, and I may even change my class generation plugin, so what do is I copy these classes and packages in src/main/java
This upsets Maven when I try to compile because he considers "target/generated-sources" as a source directory and he finds all clases twice. For what I understand, I can exclude classes inside a source directory, but I can't remove a source directory from Maven build, am I right ?
So the only solution would be to configure my jaxb2 plugin to generate the classes elsewhere, right ?
UPDATE :
Ok, this doesn't work as I thought, if I change the outputDirectory of my jaxb plugin, it's still included as a source directory by Maven, and I have no clue why.
<configuration>
<outputDirectory>${project.build.directory}/tatata/jaxb</outputDirectory>
</configuration>
UPDATE 2 : The explanation is the plugin is adding the outputDirectory as a maven source directory during the generate-sources phase of the build, and it's not optionnal or customizable.
First things first, do not add generation code to source control. Do not modify it manually. You will get into trouble. Believe me, I've seen it too many times. A new version of the schema and you're lost.
Ok, now to your question.
With maven-jaxb2-plugin you could turn off adding generation directory as a compile source root with:
<configuration>
<addCompileSourceRoot>false</addCompileSourceRoot>
</configuration>
Disclaimer: I'm the author of maven-jaxb2-plugin.
The answer from Lexicore is an interesting lead but my question was about the plugin I'm currently using, not how to do it with an other plugin.
So here is the workaround for the Mojohaus plugin : you can just skip the generate-sources by default (no need to do this task at every build when your model changes once in a week, then once in a year), and trigger it only when needed using a dedicated maven profile : How to skip generate-sources in Maven
you can always specify the target directory(generateDirectory) in pom config file as below. Hope it helps
`
<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
<version>0.12.3</version>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
<configuration>
<schemaLanguage>WSDL</schemaLanguage>
<generateDirectory>${basedir}/src/main/java</generateDirectory>
<generatePackage>com.myproj.proxy</generatePackage>
<schemas>
<schema>
<!-- <url>${project.basedir}/src/main/resources/wsdl/test.wsdl</url> -->
<fileset>
<!-- Defaults to schemaDirectory. -->
<directory>${basedir}/src/main/resources/wsdl</directory>
<!-- Defaults to schemaIncludes. -->
<includes>
<include>*.wsdl</include>
</includes>
</fileset>
</schema>
</schemas>
</configuration>
</plugin>
`

Setup baseline for Maven Findbugs

I have this issue that I have been trying to solve for the better part of a day, but can't really seem to do.
I have set up my maven so that it fails if findbugs finds any bugs. However, because of reasons, I would like to ignore all the bugs that currently exist in the project, and only fail if new bugs are found. A baseline.
I am able to generate an XML file containing a <BugCollection>
with all my current bugs, using FindBugs plugin for IntelliJ. However, supplying this to the maven plugin does nothing.
It seems the maven plugin requires a filter file in this format:
<Match>
<Class name="com.foobar.MyClass" />
</Match>
My question is then: How do I generate this filter file?
It seems that the findbugs:gui is not a great option, as it only allows me to filter on bug type and class. Meaning new bugs of the same type in the same class but a different method would be ignored.
Alternatively: How do I make findbugs for maven ignore existing bugs and only fail on new ones?
Thank you :)
You should use the excludeBugsFile configuration, something like below. The findbugs-baseline.xml is the file exported with the FindBugs-IDEA plugin in Intellij
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<configuration>
<excludeBugsFile>${project.basedir}/findbugs-baseline.xml</excludeBugsFile>
</configuration>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>

What does "echo" mean when it comes to using Maven?

I'm currently learning how to use Maven and have encountered a term called "echo". I was just wondering what it actually means?
There are few important concepts related to Maven Lifecycles, which
are worth to mention:
1) When a phase is called via Maven command, for example mvn compile,
only phases up to and including that phase will execute.
2) Different maven goals will be bound to different phases of Maven
lifecycle depending upon the type of packaging (JAR / WAR / EAR).
In the following example, we will attach maven-antrun-plugin:run goal
to few of the phases of Build lifecycle. This will allow us to echo
text messages displaying the phases of the lifecycle.
echo is an ant task which allow to print messages to console (system.out)
This makes sense when using maven-antrun-plugin which allow to execute ant tasks in a maven build.
It can be used to print some maven properties during the build as there is no built-in way to output value to console in maven.
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>${maven.antrun.plugin.version}</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>Configuration properties :</echo>
<echo>service.endpoint=${service.endpoint}</echo>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
It means to use echo tag in ant script executed by maven-antrun-plugin:run. Nothing directly related to maven itself.

Use maven-exec-plugin to run command line

I want to use maven-exec-plugin to run command line (cmd) for converting a Markdown file to a PDF file using Pandoc.
To do that manually, I've executed these commands:
pandoc ReadMe.md -o ReadMe.html
pandoc ReadMe.html --latex-engine=xelatex -o ReadMe.pdf
I wasn't able to run that in one command, pandoc giving weird error! But this is another problem...
I've added this to my pom file using other sample found on the web but without success.
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version>
<executions>
<execution>
<id>pandoc</id>
<phase>generate-pdf</phase>
<configuration>
<executable>cmd</executable>
<workingDirectory></workingDirectory>
<arguments>
<argument>/C</argument>
<argument>pandoc</argument>
<argument>README.md</argument>
<argument>-o</argument>
<argument>README.html</argument>
</arguments>
</configuration>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
I'm not a maven guru and help is appreciate!
The defined phase, <phase>generate-pdf</phase>, is not a maven phase, hence Maven didn't bind the execution to its workflow.
You should bind it to a standard Maven phase, depending on your need. Try <phase>package</phase> for instance, it will be executed nearly at the end of your build.
The id element of a plugin execution is free text, you can type the id you want, it will appear as part of the build output in curved brackets after the plugin and goal name,
i.e. exec-maven-plugin:1.1:exec (pandoc)
The phase element instead must match a well known maven phase in order to attach the plugin/goal execution to it. If the phase is not well known, then Maven will simply ignore that plugin/goal execution (which is also an adopted approach, usually using the de-facto standard none as phase, to disable an inherited plugin execution, but that's a bit advanced for the scope of this question I would say).
For more details on maven phases, look at the official documentation, here.
For a full list of maven phases, here.

Eclipse Maven multi module project with xmlbeans

I have a multi module project, in which one of the module ( say MODULE-A) generates sources and classes using xmlbeans plugin. So everytime when I do a clean install of parent project, eclipse recognizes all of the generated sources as new classes, and I don't want to commit the same files again and again when there is no schema change. To overcome this problem, I wrapped xmlbeans build under a profile so that I can build it with profile whenever there is a schema change. But it didn't solve the problem completely.
Whenever I try to do clean build of parent, MODULE-A is not creating 'schemaorg_apache_xmlbeans' under build directory ( which is something only generated by xmlbean plugin when I run with profile ). I can tell maven to exclude 'schemaorg_apache_xmlbeans' from the clean task. But I want to know if this is the right way to handle.
Appreciate your responses.
Thanks in advance
One alternative to this approach is to add this plugin:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${project.build.directory}/generated-sources/</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
This will allow the generated-sources to be added as a source folder so every time it generates you will have them built and available. You wouldn't commit these but when the actual jar gets built/released they will be in there and work all the same. This allows you to always be using code most up to date with your schema. This may not be the best solution for you but I found it to be a good idea when I ran into a similar situation.

Resources