mojohaus / mojo-parent Goto Github PK

View Code? Open in Web Editor NEW

121.0 23.0 59.0 1.34 MB

This is the parent pom for all MojoHaus Maven plugins and components.

Home Page: https://www.mojohaus.org/mojo-parent/

mojohaus java java8

mojo-parent's Introduction

MojoHaus Parent

This is the parent pom for all MojoHaus Maven plugins and components.

Releasing

Make sure gpg-agent is running.
Execute mvn -B release:prepare release:perform

For publishing the site, do the following (assuming mono-module project):

cd target/checkout
mvn verify site site:stage scm-publish:publish-scm

mojo-parent's People

Contributors

Stargazers

Watchers

mojo-parent's Issues

Signing with timestamping -tsa

Possibility to specify "-tsa" switch to jarsigner for signing the jars.

update ci information

I don't know what's the target, but at least this issue will help us track the issue :)
(and learn on simple things how to use the new github issues system)

maven-dependency-plugin upgrade to 2.10

Update mojo.java.target to 1.7

As even JDK7 has reached EOL, compiling for JDK 1.5 becomes cumbersome.

Fixing build failure

Upgrade to fluido-skin 1.5 in relationship with maven-site-plugin 3.5.1

Change maven-plugin-api base from 2.2.1 to 3.0

Minimum Maven plugin api from 2.2.1 to 3.0

Upgrade maven-site-plugin to 3.5.1

Upgrade animal-sniffer-maven-plugin to 1.15

Site generation failure based on coberatura-maven-plugin

If i do a mvn clean verify site with the current mojo-parent for the mrm project it will fail. If i remove the cobertura-maven-plugin from reporting area the build run without any issue.

The following will happend:

[INFO] --- maven-surefire-plugin:2.19.1:test (default-test) @ mrm-servlet ---

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running org.codehaus.mojo.mrm.impl.maven.ArchetypeCatalogFileEntryTest
Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 0.173 sec <<< FAILURE! - in org.codehaus.mojo.mrm.impl.maven.ArchetypeCatalogFileEntryTest
testCleanArchetypeCatalogFileEntry(org.codehaus.mojo.mrm.impl.maven.ArchetypeCatalogFileEntryTest)  Time elapsed: 0.011 sec  <<< ERROR!
java.lang.NoClassDefFoundError: net/sourceforge/cobertura/coveragedata/TouchCollector
    at org.codehaus.mojo.mrm.impl.maven.ArchetypeCatalogFileEntryTest.testCleanArchetypeCatalogFileEntry(ArchetypeCatalogFileEntryTest.java:22)
Caused by: java.lang.ClassNotFoundException: net.sourceforge.cobertura.coveragedata.TouchCollector
    at org.codehaus.mojo.mrm.impl.maven.ArchetypeCatalogFileEntryTest.testCleanArchetypeCatalogFileEntry(ArchetypeCatalogFileEntryTest.java:22)

testFileSystem(org.codehaus.mojo.mrm.impl.maven.ArchetypeCatalogFileEntryTest)  Time elapsed: 0.105 sec  <<< ERROR!
java.lang.NoClassDefFoundError: Could not initialize class org.codehaus.mojo.mrm.impl.maven.ArchetypeCatalogFileEntry
    at org.codehaus.mojo.mrm.impl.maven.ArchetypeCatalogFileEntryTest.testFileSystem(ArchetypeCatalogFileEntryTest.java:35)

testParent(org.codehaus.mojo.mrm.impl.maven.ArchetypeCatalogFileEntryTest)  Time elapsed: 0.001 sec  <<< ERROR!
java.lang.NoClassDefFoundError: Could not initialize class org.codehaus.mojo.mrm.impl.maven.ArchetypeCatalogFileEntry
    at org.codehaus.mojo.mrm.impl.maven.ArchetypeCatalogFileEntryTest.testParent(ArchetypeCatalogFileEntryTest.java:49)

testArtifactStore(org.codehaus.mojo.mrm.impl.maven.ArchetypeCatalogFileEntryTest)  Time elapsed: 0.01 sec  <<< ERROR!
java.lang.NoClassDefFoundError: Could not initialize class org.codehaus.mojo.mrm.impl.maven.ArchetypeCatalogFileEntry
    at org.codehaus.mojo.mrm.impl.maven.ArchetypeCatalogFileEntryTest.testArtifactStore(ArchetypeCatalogFileEntryTest.java:67)

Running org.codehaus.mojo.mrm.impl.maven.ArtifactStoreFileSystemTest
Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 0.006 sec <<< FAILURE! - in org.codehaus.mojo.mrm.impl.maven.ArtifactStoreFileSystemTest
testSnapshotArtifactRegex(org.codehaus.mojo.mrm.impl.maven.ArtifactStoreFileSystemTest)  Time elapsed: 0.001 sec  <<< ERROR!
java.lang.NoClassDefFoundError: net/sourceforge/cobertura/coveragedata/TouchCollector
    at org.codehaus.mojo.mrm.impl.maven.ArtifactStoreFileSystemTest.testSnapshotArtifactRegex(ArtifactStoreFileSystemTest.java:113)
Caused by: java.lang.ClassNotFoundException: net.sourceforge.cobertura.coveragedata.TouchCollector
    at org.codehaus.mojo.mrm.impl.maven.ArtifactStoreFileSystemTest.testSnapshotArtifactRegex(ArtifactStoreFileSystemTest.java:113)

testSiteXmlReleaseVersion(org.codehaus.mojo.mrm.impl.maven.ArtifactStoreFileSystemTest)  Time elapsed: 0.003 sec  <<< ERROR!
java.lang.NoClassDefFoundError: Could not initialize class org.codehaus.mojo.mrm.impl.maven.ArtifactStoreFileSystem
    at org.codehaus.mojo.mrm.impl.maven.ArtifactStoreFileSystemTest.testSiteXmlReleaseVersion(ArtifactStoreFileSystemTest.java:162)

testSiteXmlSnapshotVersion(org.codehaus.mojo.mrm.impl.maven.ArtifactStoreFileSystemTest)  Time elapsed: 0 sec  <<< ERROR!
java.lang.NoClassDefFoundError: Could not initialize class org.codehaus.mojo.mrm.impl.maven.ArtifactStoreFileSystem
    at org.codehaus.mojo.mrm.impl.maven.ArtifactStoreFileSystemTest.testSiteXmlSnapshotVersion(ArtifactStoreFileSystemTest.java:172)

testGroupMetadataRegex(org.codehaus.mojo.mrm.impl.maven.ArtifactStoreFileSystemTest)  Time elapsed: 0.001 sec  <<< ERROR!
java.lang.NoClassDefFoundError: Could not initialize class org.codehaus.mojo.mrm.impl.maven.ArtifactStoreFileSystem
    at org.codehaus.mojo.mrm.impl.maven.ArtifactStoreFileSystemTest.testGroupMetadataRegex(ArtifactStoreFileSystemTest.java:44)

testArtifactRegex(org.codehaus.mojo.mrm.impl.maven.ArtifactStoreFileSystemTest)  Time elapsed: 0 sec  <<< ERROR!
java.lang.NoClassDefFoundError: Could not initialize class org.codehaus.mojo.mrm.impl.maven.ArtifactStoreFileSystem
    at org.codehaus.mojo.mrm.impl.maven.ArtifactStoreFileSystemTest.testArtifactRegex(ArtifactStoreFileSystemTest.java:60)

Running org.codehaus.mojo.mrm.impl.maven.DiskArtifactStoreTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.002 sec <<< FAILURE! - in org.codehaus.mojo.mrm.impl.maven.DiskArtifactStoreTest
testArchetypeCatalog(org.codehaus.mojo.mrm.impl.maven.DiskArtifactStoreTest)  Time elapsed: 0.002 sec  <<< ERROR!
java.lang.NoClassDefFoundError: net/sourceforge/cobertura/coveragedata/TouchCollector
    at org.codehaus.mojo.mrm.impl.maven.DiskArtifactStoreTest.testArchetypeCatalog(DiskArtifactStoreTest.java:18)
Caused by: java.lang.ClassNotFoundException: net.sourceforge.cobertura.coveragedata.TouchCollector
    at org.codehaus.mojo.mrm.impl.maven.DiskArtifactStoreTest.testArchetypeCatalog(DiskArtifactStoreTest.java:18)

Running org.codehaus.mojo.mrm.impl.maven.MockArtifactStoreTest
Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.002 sec <<< FAILURE! - in org.codehaus.mojo.mrm.impl.maven.MockArtifactStoreTest
testArchetypeCatalog(org.codehaus.mojo.mrm.impl.maven.MockArtifactStoreTest)  Time elapsed: 0.001 sec  <<< ERROR!
java.lang.NoClassDefFoundError: org.codehaus.mojo.mrm.api.maven.BaseArtifactStore
    at org.codehaus.mojo.mrm.impl.maven.MockArtifactStoreTest.testArchetypeCatalog(MockArtifactStoreTest.java:47)

testInheritGavFromParent(org.codehaus.mojo.mrm.impl.maven.MockArtifactStoreTest)  Time elapsed: 0 sec  <<< ERROR!
java.lang.NoClassDefFoundError: org.codehaus.mojo.mrm.api.maven.BaseArtifactStore
    at org.codehaus.mojo.mrm.impl.maven.MockArtifactStoreTest.testInheritGavFromParent(MockArtifactStoreTest.java:24)

testClassifiers(org.codehaus.mojo.mrm.impl.maven.MockArtifactStoreTest)  Time elapsed: 0.001 sec  <<< ERROR!
java.lang.NoClassDefFoundError: org.codehaus.mojo.mrm.api.maven.BaseArtifactStore
    at org.codehaus.mojo.mrm.impl.maven.MockArtifactStoreTest.testClassifiers(MockArtifactStoreTest.java:32)


Results :

Tests in error:
  ArchetypeCatalogFileEntryTest.testArtifactStore:67 NoClassDefFound Could not i...
  ArchetypeCatalogFileEntryTest.testCleanArchetypeCatalogFileEntry:22 » NoClassDefFound
  ArchetypeCatalogFileEntryTest.testFileSystem:35 NoClassDefFound Could not init...
  ArchetypeCatalogFileEntryTest.testParent:49 NoClassDefFound Could not initiali...
  ArtifactStoreFileSystemTest.testArtifactRegex:60 NoClassDefFound Could not ini...
  ArtifactStoreFileSystemTest.testGroupMetadataRegex:44 NoClassDefFound Could no...
  ArtifactStoreFileSystemTest.testSiteXmlReleaseVersion:162 NoClassDefFound Coul...
  ArtifactStoreFileSystemTest.testSiteXmlSnapshotVersion:172 NoClassDefFound Cou...
  ArtifactStoreFileSystemTest.testSnapshotArtifactRegex:113 » NoClassDefFound ne...
  DiskArtifactStoreTest.testArchetypeCatalog:18 » NoClassDefFound net/sourceforg...
  MockArtifactStoreTest.testArchetypeCatalog:47 NoClassDefFound org.codehaus.moj...
  MockArtifactStoreTest.testClassifiers:32 NoClassDefFound org.codehaus.mojo.mrm...
  MockArtifactStoreTest.testInheritGavFromParent:24 NoClassDefFound org.codehaus...

Tests run: 13, Failures: 0, Errors: 13, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Mock Repository Manager: Project .................. SUCCESS [8.725s]
[INFO] Mock Repository Manager: API ...................... SUCCESS [17.160s]
[INFO] Mock Repository Manager: Servlet .................. FAILURE [1.596s]
[INFO] Mock Repository Manager: Web Application .......... SKIPPED
[INFO] Mock Repository Manager: Maven Plugin ............. SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 27.836s
[INFO] Finished at: Wed Jul 13 17:47:10 CEST 2016
[INFO] Final Memory: 84M/1026M

Chat Setup

I have invited many of you to https://gitter.im/mojohaus ...may be this is a good place for chatting...May be we can create a supplemental are via irc ? (freenode?)

configure parent site deploy as "mvn site-deploy" for mono-module projects

A vast majority of MojoHaus projects are mono-module projects: for these ones, parent pom can be configured to make "mvn site-deploy' do the job instead of "mvn site site:stage scm-publish:publish-scm"
see http://maven.apache.org/plugins/maven-scm-publish-plugin/examples/one-module-configuration.html

Why is it not possible to set dirmode on individual mappings?

I would like to build an rpm where one directory has a different dirmode than the default. This option is not available, whereas , , and are available on the mapping level.
Why the difference?

By the way, this issue has been floating around since 2010:

http://mojo.10943.n7.nabble.com/rpm-maven-plugin-is-there-any-way-to-specify-the-dirmode-other-than-the-defaultDirmode-attribute-td37839.html

Move codecoverage plugins to separate profile

While trying to do some jigsaw related improvements I noticed that with the current parent it will be impossible to build a project with JDK9. The cause is the cobertura-plugin. It is part of the default build AND it depends on tools.jar, which doesn't exist anymore in JDK9.
By moving it to a codecoverage profile we have the option to enable or disable it when we want. It won't have any effect on the resulting artifact, only on the quality statistics.

How can i annotate all classes with @XmlRootElement?

I am trying to annotate all classes generated from a complexType with @XmlRootElement but i couldn't make it.

This is the xjb file:

<bindings xmlns="http://java.sun.com/xml/ns/jaxb"
          xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
          xmlns:xs="http://www.w3.org/2001/XMLSchema"
          xmlns:annox="http://annox.dev.java.net"
          extensionBindingPrefixes="annox"
          xsi:schemaLocation="http://java.sun.com/xml/ns/jaxb http://java.sun.com/xml/ns/jaxb/bindingschema_2_0.xsd"
          version="2.1">
    <bindings schemaLocation="http://schemas.dmtf.org/ovf/envelope/1/dsp8023_1.1.0.xsd" version="1.0">
        **<!-- This one works because all complextype s are in the same xsd file -->
        <bindings node="xs:complexType[@name]" required="false" multiple="true">
            <annox:annotate>
                <annox:annotate annox:class="javax.xml.bind.annotation.XmlRootElement"/>
            </annox:annotate>
        </bindings>**

    </bindings>
    **<!-- This one doesn't work.  -->
    <!-- master.xsd includes other xsd s.  -->
    <bindings schemaLocation="../xsd/1.5/schemas/master/master.xsd" version="1.0">
        <bindings node="//xs:complexType[@name]" required="false" multiple="true">
            <annox:annotate>
                <annox:annotate annox:class="javax.xml.bind.annotation.XmlRootElement"/>
            </annox:annotate>
        </bindings>
    </bindings>**
</bindings>

Only run github-report during site generation when not running in CI

During run in Travis, builds sometimes fail because Travis hits the github API to hard, so you get the following:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project mojo-parent: Error generating maven-changes-plugin:2.11:github-report: API rate limit exceeded for 52.0.240.122. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.) (403) -> [Help 1]

So put github-report generation in a profile which is not activated in Travis.

Manage plugin versions with properties

By means of this, it is much easier to update them automatically using the versions:update-properties

Upgrade to Maven 3+ only parent

Removing the prerequisites and using maven-enforcer-plugin to check the minimum version of Maven to use.

Fix site issues and introduce github ribbon

Currently the logo is not correctly rendered in the site because the site plugin inserts the artifactId into the image URL.
The google search still referenced mojo.codehaus.org
Add a github-ribbon.
Add a introductory page for mojo-parent.

Ignore the transient Takari Maven wrapper in .gitignore

The Takari maven wrapper libraries creates some files in the root directory of the project.
These should not be checked in, so exclude them in the standard .gitignore file.

Takari Maven Wrapper

/mvnw.bat
/mvnw
/.mvn/

Package prefixing per WSDL

Edit: see mojohaus/jaxws-maven-plugin#21

_

maven-project-info-reports-plugin only in reporting profiles to prevent WARNINGs

Currently creating reporting via mvn -Preporting site site:stage will produce the following:

[INFO] configuring report plugin org.apache.maven.plugins:maven-project-info-reports-plugin:2.8
[WARNING] cim report is declared twice in default reportSet
[WARNING] dependency-info report is declared twice in default reportSet
[WARNING] index report is declared twice in default reportSet
[WARNING] issue-tracking report is declared twice in default reportSet
[WARNING] mailing-list report is declared twice in default reportSet
[WARNING] project-team report is declared twice in default reportSet
[WARNING] scm report is declared twice in default reportSet
[WARNING] summary report is declared twice in default reportSet
[INFO] configuring report plugin org.apache.maven.plugins:maven-changes-plugin:2.11
[INFO] configuring report plugin org.apache.maven.plugins:maven-checkstyle-plugin:2.16
[INFO] configuring report plugin org.apache.maven.plugins:maven-javadoc-plugin:2.10.3
[INFO] preparing 'javadoc' report requires 'generate-sources' forked phase execution

javadoc: warning - Error fetching URL: http://junit-team.github.io/junit/javadoc/latest/

During site build, the following warning is displayed:

javadoc: warning - Error fetching URL: http://junit-team.github.io/junit/javadoc/latest/

Improve diagnostics when encountering a class that ASM cannot read

I recently ran Animal Sniffer's Maven plugin against a project that depends on Jersey 2.25 and it failed with an IllegalArgumentException. Running the build with -X showed that it was failing in ASM:

Caused by: java.lang.IllegalArgumentException
	at org.objectweb.asm.ClassReader.<init>(Unknown Source)
	at org.objectweb.asm.ClassReader.<init>(Unknown Source)
	at org.objectweb.asm.ClassReader.<init>(Unknown Source)
	at org.codehaus.mojo.animal_sniffer.ClassListBuilder.process(ClassListBuilder.java:71)
	at org.codehaus.mojo.animal_sniffer.ClassFileVisitor.processJarFile(ClassFileVisitor.java:153)
	at org.codehaus.mojo.animal_sniffer.ClassFileVisitor.process(ClassFileVisitor.java:105)
	at org.codehaus.mojo.animal_sniffer.maven.CheckSignatureMojo.apply(CheckSignatureMojo.java:377)
	at org.codehaus.mojo.animal_sniffer.maven.CheckSignatureMojo.buildPackageList(CheckSignatureMojo.java:324)
	at org.codehaus.mojo.animal_sniffer.maven.CheckSignatureMojo.execute(CheckSignatureMojo.java:227)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
	... 21 more

Attaching a debugger and breaking on the construction of an IllegalArgumentException allowed me to identify that the problematic class was /Users/awilkinson/.m2/repository/org/glassfish/hk2/external/asm-all-repackaged/2.5.0-b30/asm-all-repackaged-2.5.0-b30.jar:module-info.class. At this point I figured out that this class was compiled with Java 9 which ASM 5 cannot read and that I could avoid the problem by adding an <excludeDependency> for the offending jar.

Could the diagnostics in ClassListBuilder be improved so that it catches any exception that comes from ASM and logs the name of the class file that it was trying to read?

Change the maven-enforcer-plugin message according to the Maven minimum version

maven-pmd-plugin configuration contains reference to broken mojo_rules.xml

hello

the maven-pmd-plugin contains

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-pmd-plugin</artifactId>
  <version>3.4</version>
  <configuration>
    <targetJdk>${mojo.java.target}</targetJdk>
    <rulesets>
     <ruleset>http://svn.codehaus.org/mojo/tags/mojo-parent-34/src/main/config/pmd/mojo_rules.xml</ruleset>
    </rulesets>

This breaks generating the maven site for (most?) plugins. Currently at least the rpm-maven-plugin site is affected.

Not sure how the link is replaced during a release. I guess it should look similar to:
https://raw.githubusercontent.com/mojohaus/mojo-parent/mojo-parent-34/src/main/config/pmd/mojo_rules.xml

use variable for github project

IMHO the idea of mojo-parent is to define the common sense for mojohaus projects.
Hence, I would suggest to define a property like mojohaus.project.name that defaults to mojo-parent. Then instead of hard-coding mojo-parent in issueManagement, distributionManagement, scm, etc. just use the variable.
Then the mojohaus projects can simply override the mojohaus.project.name and that's it.
I forgot to override issueManagement in servicedocgen-maven-plugin and hence you can see the github issue report for mojo-parent on my maven site.
The property could avoid a lot of redundancy.

Use the mojohaus icon which is used on github for the web site

Upgrade maven-javadoc-plugin to 2.10.4

Upgrade Plugins which are not yet released

maven-sources-plugin 3.0.1
maven-jar-plugin 3.0.2

Update all plugins to their newest version

Github report should be sorted on release version

Currently (mojo-parent 40) the Github report is sorted on issue number, which makes it hard to see what has been fixed in what release. Change that so it is sorted on release version.

Fix releasing and publishing site.

By default mvn release:perform will execute mvn deploy site-deploy. However this does not work with the maven-scm-publish-plugin out of the box.

So for now only execute mvn deploy during release:perform.
Add instructions for publishing the released site in README.md.

logging consistency for dependencies and plugin

maven-junit-plugin <configuration><links> is no longer valid

Since 73c10ff (2015-07-18), mojo-parent's pom.xml has had this in the maven-javadoc-plugin:

   <configuration>
     <links>
       <link>http://junit-team.github.io/junit/javadoc/latest/</link>
     </links>
   </configuration>

(before that, the pointed at http://junit.sourceforge.net/javadoc/

That link (up until recently) resolved to the javadoc for junit-4.12.

Recently, junit-team.github.io began redirecting to junit.org (presumably for the junit-5.0.0 release on 2017-09-10).

And that means that "mvn site" on projects like versions-maven-plugin produces an error:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.6:site (default-site) on project versions-maven-plugin: Error generating maven-javadoc-plugin:2.10.4:javadoc:
[ERROR] Exit code: 1 - javadoc: warning - Error fetching URL: http://junit-team.github.io/junit/javadoc/latest/

The now redirected-to junit.org page has links to junit5 javadoc (e.g., http://junit.org/junit5/docs/current/api/), but given that adoption of junit5 is still very early, I suspect we still want junit4 javadoc in mojo-parent.

Luckily, one can still find the junit4 javadoc at http://junit.org/junit4/javadoc/latest/

Upgrade maven-project-info-reports-plugin from 2.8 to 2.9

Upgrade plugins to new generation

maven-clean-plugin 3.0.0
maven-resources-plugin 3.0.1
maven-compiler-plugin 3.5.1
maven-assembly-plugin 2.6

SCM: enforce usage of ssh-protocol for developerConnection and https for connection

Additionally check, that URL does not have the scm:git prefix.

Specify dependencies and configLocation for maven-checkstyle-plugin

maven_checks.xml and maven-header.txt are not part of the maven-checkstyle-plugin-2.16 anymore. Therefore checkstyle fails during site generation.

We need to specify the new containing dependency (maven-shared-resources-2) in pluginManagement and configure maven-checkstyle-plugin in the plugins section
otherwise this is not picked up correctly during site generation.

2.5 breaks dependent projects with independent version numbers

Previous versions would simply substitute the version text, for example 1.2.047 -> 1.2.048.

Version 2.5, however changes this behavior to simply use ${project.version}. This breaks projects that use a reactor as a parent that have independent version numbers.

For example:
If I have a project version 1.3.002 that has a parent of version 1.2.047, then it keeps looking for all my dependencies w/ version 1.3.002 instead of 1.2.047.

We have a reactor that's used as a parent for a dozen or more projects, each with their own versioning and release schedule. For now, we've reverted to using 2.4.

make requireEncoding validate encoding rather than detect encoding by ICU4J

It seems that the requireEncoding rule is detecting ISO-8859-1 where my IDE happily detects UTF-8. It seems to me that instead of detecting encoding the rule should try to parse files with desired encoding and signal decoding failures instead.

Upgrade maven plugins

maven-surefire-plugin, animal-sniffer-maven-plugin, maven-plugin-tools-javadoc
Added maven-failsafe-plugin.

Multiple configurations do not look at source parameter

Given the following configuration:

            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>jaxb2-maven-plugin</artifactId>
                <executions>
                    <execution>
                        <id>generate-import</id>
                        <goals>
                            <goal>xjc</goal>
                        </goals>
                        <configuration>
                            <addGeneratedAnnotation>true</addGeneratedAnnotation>
                            <packageName>com.mygroup.model.published</packageName>
                            <outputDirectory>target/generated-sources</outputDirectory>
                            <encoding>UTF-8</encoding>
                            <sources>
                                <source>${project.basedir}/src/main/resources/xsd/publish/publish.xsd</source>
                            </sources>
                        </configuration>
                    </execution>
                    <execution>
                        <id>generate-publish</id>
                        <goals>
                            <goal>xjc</goal>
                        </goals>
                        <configuration>
                            <addGeneratedAnnotation>true</addGeneratedAnnotation>
                            <packageName>com.mygroup.model.imported</packageName>
                            <outputDirectory>target/generated-sources</outputDirectory>
                            <encoding>UTF-8</encoding>
                            <sources>
                                <source>${project.basedir}/src/main/resources/xsd/import/import.xsd</source>
                            </sources>
                            <clearOutputDir>false</clearOutputDir>
                        </configuration>
                    </execution>
                </executions>

            </plugin>

The source configuration is not found, and an error is seen on the console:

Ignored given or default sources [C:\workspaces\project\src\main\xsd], since it is not an existent file or directory.

If I have the following config:

            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>jaxb2-maven-plugin</artifactId>
                <executions>
                    <execution>
                        <id>generate-import</id>
                        <goals>
                            <goal>xjc</goal>
                        </goals>

                    </execution>
                </executions>
                <configuration>
                    <addGeneratedAnnotation>true</addGeneratedAnnotation>
                    <packageName>com.mygroup.model.published</packageName>
                    <outputDirectory>target/generated-sources</outputDirectory>
                    <encoding>UTF-8</encoding>
                    <sources>
                        <source>${project.basedir}/src/main/resources/xsd/publish/publish.xsd</source>
                    </sources>
                </configuration>
            </plugin>

Then that single one is generated fine. Then plugin is not observing the source directive when there are multiple configurations.

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>aspectj-maven-plugin</artifactId>
    <executions>
        <execution>
            <id>compile</id>
            <goals>
                <goal>compile</goal>
            </goals>
            <configuration>
                <showWeaveInfo>true</showWeaveInfo>
                <weaveDirectories>
                    <weaveDirectory>${project.build.outputDirectory}</weaveDirectory>
                </weaveDirectories>
                <sources/>
            </configuration>
        </execution>
        <execution>
            <id>test-compile</id>
            <goals>
                <goal>test-compile</goal>
            </goals>
            <configuration>
                <weaveDirectories>
                    <weaveDirectory>${project.build.testOutputDirectory}</weaveDirectory>
                </weaveDirectories>
                <testSources/>
            </configuration>
        </execution>
    </executions>
</plugin>

Output: No sources, nothing to compile.

I am using the ant plugin to work around this problem, it works but I'd rather use this plugin.

ant config:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-antrun-plugin</artifactId>
    <executions>
        <execution>
            <id>weave-classes</id>
            <phase>process-classes</phase>
            <goals>
                <goal>run</goal>
            </goals>
            <configuration>
                <target>
                    <taskdef resource="org/aspectj/tools/ant/taskdefs/aspectjTaskdefs.properties" classpathref="maven.plugin.classpath"/>
                    <iajc destDir="${project.build.outputDirectory}"
                          inpath="${project.build.outputDirectory}"
                          source="${java.version}"
                          target="${java.version}"
                          aspectPath="${org.springframework:spring-aspects:jar}"
                          classpathRef="maven.compile.classpath"
                          Xlint="ignore"/>
                </target>
            </configuration>
        </execution>
        <execution>
            <id>weave-test-classes</id>
            <phase>process-test-classes</phase>
            <goals>
                <goal>run</goal>
            </goals>
            <configuration>
                <target>
                    <path id="aspectPath">
                        <pathelement location="${org.springframework:spring-aspects:jar}"/>
                        <pathelement location="${project.build.outputDirectory}"/>
                    </path>
                    <taskdef resource="org/aspectj/tools/ant/taskdefs/aspectjTaskdefs.properties" classpathref="maven.plugin.classpath"/>
                    <iajc destDir="${project.build.testOutputDirectory}"
                          inpath="${project.build.testOutputDirectory}"
                          source="${java.version}"
                          target="${java.version}"
                          aspectPathRef="aspectPath"
                          classpathRef="maven.compile.classpath"
                          Xlint="ignore"/>
                </target>
            </configuration>
        </execution>
    </executions>
</plugin>

Change release-plugin to use local git repository during release:perform

Instead of pulling the repositories from GitHub again, we may use localCheckout for speedup.

Configure maven-changes-plugin to use GitHub for issues

By means of this a run of mvn changes:announcement-generate will produce a list of solved issues.