Specifically, using io.swagger:swagger-codegen-maven-plugin:2.1.5 (which generates to ${project.build.outputDirectory}/generated-sources/swagger/src/main), then using build-helper-maven-plugin to attach the generated source - will fail import by m2e into Eclipse.

Not entirely sure where this issue originates, but the error is reported from org.eclipse.jdt.core as

Cannot nest 'foo/target/classes/generated-sources/swagger/src/main' inside output folder 'foo/target/classes'

Workaround is commenting out the builder-helper-maven-plugin, then manually adding the target/generated-sources/swagger/src/main/java directory in the project - giving it a "default output" for classes (i.e target/classes).

Currently we are not able to provide wildcard characters like '*' in the file name. Expecting the below structure to work. This would avoid multiple configurations in case of several artifacts needs to be attached.

    <plugin>
		<groupId>org.codehaus.mojo</groupId>
		<artifactId>build-helper-maven-plugin</artifactId>
		<executions>
			<execution>
				<id>attach-artifacts</id>
				<phase>package</phase>
				<goals>
					<goal>attach-artifact</goal>
				</goals>
				<configuration>
					<artifacts>
						<artifact>
							<file>${project.basedir}/src/main/resources/*.properties</file>
							<type>properties</type>
						</artifact>
					</artifacts>
				</configuration>
			</execution>
		</executions>
	</plugin>

I ran into an issue with the reserve-network-port goal, where in some cases in my build the directory where the output file is written might not exist in this stage of the build.

Would it be possible for the goal to create the directory if it didn't exist before?

As a workaround for a rough spot in Artifactory, I'm using remove-project-artifact to clear artifacts from test builds on a Jenkins server. However, the metadata for the removed artifact isn't cleared, which means that the next time that Jenkins tries to build a project that depends on "this" one with a matching version range, the downstream build fails because Jenkins can't resolve the "missing" version. These projects are not resolved from any external repository when built on the CI server.

Reproduction:

• create project A with version 0.1.0, install
• update A to 0.1.1, install, run remove-project-artifact
• create project B that depends on A:[0.1.0,0.2.0)

Expected behavior: B resolves the latest existing version of A (0.1.0). Instead, it resolves the removed version 0.1.1, and the Maven build fails.

Example maven-metadata-local.xml "before":

<?xml version="1.0" encoding="UTF-8"?>
<metadata>
  <groupId>io.ngin.sandbox.build</groupId>
  <artifactId>build-sandbox</artifactId>
  <versioning>
    <release>3.0.1</release>
    <versions>
      <version>3.0.0</version>
      <version>3.0.1</version>
    </versions>
    <lastUpdated>20180709210726</lastUpdated>
  </versioning>
</metadata>

Example after version 3.0.2 was installed and deleted (this will fail because 3.0.2 doesn't exist):

<?xml version="1.0" encoding="UTF-8"?>
<metadata>
  <groupId>io.ngin.sandbox.build</groupId>
  <artifactId>build-sandbox</artifactId>
  <versioning>
    <release>3.0.2</release>
    <versions>
      <version>3.0.0</version>
      <version>3.0.1</version>
      <version>3.0.2</version>
    </versions>
    <lastUpdated>20180711173248</lastUpdated>
  </versioning>
</metadata>

The fork me on github link goes to https://github.com/mojohaus/mojo-parent not not https://github.com/mojohaus/build-helper-maven-plugin

Hello, I can't get a point how to use this plugin. No one of examples from usage page is working. I try to add timestamp to my pom.xml file with following configuration:

Failed to execute goal org.codehaus.mojo:build-helper-maven-plugin:1.7:timestamp-property (default-cli) on project wildfly-spring-boot-sample: The parameters 'name' for goal org.codehaus.mojo:build-helper-maven-plugin:1.7:timestamp-property are missing or invalid -> [Help 1]

Trying to do the following:

<configuration>
    <regexPropertySettings>
        <regexPropertySetting>
            <name>version.first</name>
            <value>origin/master</value>
            <regex>origin/</regex>
            <failIfNoMatch>false</failIfNoMatch>
        </regexPropertySetting>
        <regexPropertySetting>
            <name>version.second</name>
            <value>${version.first}</value>
            <regex>/</regex>
            <replacement>_</replacement>
            <failIfNoMatch>false</failIfNoMatch>
        </regexPropertySetting>
    </regexPropertySettings>
</configuration>

When trying to do this, I keep getting errors that a value is required. Shouldn't we be able to reuse a variable?

Hi,
We are using build-helper-maven-plugin plugin to reserve port for starting up a process. We execute cucumber test cases with various tag name (meaning maven process in same build machine) and since reserve network port assigns port in sequence, few build fails at random. For a cleaner approach, can a parameter for random port assignment be introduced?

                       <execution>
                    <id>reserve-network-port</id>
                    <phase>package</phase>
                    <goals>
                        <goal>reserve-network-port</goal>
                    </goals>
                    <configuration>
                        <portNames>
                            <portName>jetty.http.port</portName>
                        </portNames>
                        <minPortNumber>9021</minPortNumber>
                        <maxPortNumber>9120</maxPortNumber>
                    </configuration>
                </execution>

I'm looking to call this plugin internally from a Java API. I'm unable to due to the private scope and no getter/setters for the variables in the ParseVersionMojo.

If you could provide getter/setters or make them protected, it would be greatly appreciated.

No upgrade reason not major version update done.

If I'm doing a Maven build, I want to generate a property using the timestamp-property in the format yyyy-MM-dd, but I want it to reflect the current time zone of the machine doing the build. (Thus I want it equivalent to a LocalDate saying what date the build was performed on; the time zone is irrelevant.)

But currently the timeZone defaults to GMT. Instead, the timeZone should default to the current JVM time zone to reflect the time zone of the build. If the developer wants to use GMT, they can specify that in the timeZone value.

As it stands, there is no way for the developer to indicate that the timestamp should be determined based upon the current JVM time zone.

It would be nice for reserve-network-port goal to be able to configure port names via external resource instead of specifying it only via configuration.portNames. For instance:

<configuration>
  <urls>
    <url>file://${project.basedir}/port_names1.txt</url>
    <url>file://${project.basedir}/port_names2.txt</url>
  </urls>
</configuration>

port_names1.txt:

# Tomcat
tomcatPort
# Jetty
jettyPort
# Glassfish
glassfishPort

Able to lookup file in classpath would be a huge plus.

Please see marc-@7396a3d .

Environment: Mac 10.12.6, JDK 1.8, maven 3.5

                   <plugin>
                        <groupId>org.codehaus.mojo</groupId>
                        <artifactId>build-helper-maven-plugin</artifactId>
                        <version>3.0.0</version>
                        <executions>
                            <execution>
                                <id>integration-test-ports</id>
                                <phase>pre-integration-test</phase>
                                <goals>
                                    <goal>reserve-network-port</goal>
                                </goals>
                                <configuration>
                                    <minPortNumber>7000</minPortNumber>
                                    <maxPortNumber>8000</maxPortNumber>
                                    <outputFile>${build.directory}/ports.properties</outputFile>
                                    <portNames>
                                        <portName>db.port</portName>
                                        <portName>memcache.port</portName>
                                    </portNames>
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>


```After this plugin runs, we launch a couple of docker containers based on these values.  So far so good.

Typical output:

[INFO] --- build-helper-maven-plugin:3.0.0:reserve-network-port (integration-test-ports)
[INFO] Port assigned7000
[INFO] Reserved port 7000 for db.port
[INFO] Port assigned7001
[INFO] Reserved port 7001 for memcache.port

However, if port 7000 is occupied as shown here:

netstat -tan | grep LISTEN
tcp6 0 0 ::1.7000 . LISTEN
tcp4 0 0 *.7000 . LISTEN
tcp6 0 0 ::1.7001 . LISTEN
tcp4 0 0 *.7001 . LISTEN

Then when I run the plugin I still get:

[INFO] --- build-helper-maven-plugin:3.0.0:reserve-network-port (integration-test-ports)
[INFO] Port assigned7000
[INFO] Reserved port 7000 for db.port
[INFO] Port assigned7001
[INFO] Reserved port 7001 for memcache.port

And the docker containers fail to launch because of network binding issue.

Workaround to reduce collisions is to randomize the port, but it won't eliminate them altogether.  Thanks.

[ERROR]

Failed to execute goal org.codehaus.mojo:build-helper-maven-plugin:1.10:reserve-network-port (reserve-ports) on project scratch: Execution reserve-ports of goal org.codehaus.mojo:build-helper-maven-plugin:1.10:reserve-network-port failed: Port value out of range: 65536 -> [Help 1]

I don't know if this has been fixed in the latest version or not.

after making a pull request when travis is running the integration-tests (concurrently with jdk7 & jdk8) I get the following error in the travis log.

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile (default-testCompile) on project test-reserve-port-with-surefire: Compilation failure: Compilation failure:
[ERROR] Source option 5 is no longer supported. Use 6 or later.
[ERROR] Target option 1.5 is no longer supported. Use 1.6 or later.

Sorry I don't know enough about travis to resolve this. But I'm keenly aware that this plugin binds ports on the target machine during the integration-tests and may NOT play nicely with concurrent builds on the same target.

add-source (and add-test-source, add-resource, etc.) should IMHO issue a warning if the directory doesn't exist, as this is almost certainly a configuration error. Maybe the build-helper-maven-plugin should even fail the build, although that may not be a backward-compatible change, so a <failOnWarning> configuration option may be necessary.

For the version 1.2.3-01-SNAPSHOT here's what I get:

[majorVersion] 1
[minorVersion] 2
[incrementalVersion] 3
[qualifier] 01-SNAPSHOT
[buildNumber] 0

buildNumber should be 01
And qualifier should be just SNAPSHOT

We use a timestamp for the build number in our maven builds and this is causing the parse-version goal to fail because it is stored as an int.

I'd love to use the m2e lifecycle mapping which is already committed on master.

Would it be possible just to release 1.13 with what is on master now?

Full name:

org.codehaus.mojo:build-helper-maven-plugin:is-release

Description:
Determine if the current version is a release version, and place it under a configurable project property

Attributes:
Requires a Maven project to be executed.
The goal is thread-safe and supports parallel builds.
Binds by default to the lifecycle phase: initialize.

Mandatory parameters:
None

Optional parameters:
isRelease: The name of the property in which to store the boolean.

Reasoning:
I couldn't see any easy way to access this information.
I am prepared to implement this.

Using a version like this: 02.3.4.XYZ should be handled correctly like this:

major=2, minor=3, incremental=4, qualifier=XYZ

but currently the OsgiArtifactVersion will parse this as:

major=0, minor=0, incremental=0, qualifier=02.3.4.XYZ.

Based on the definition of the OSGi this is wrong. The grammar definition looks like this:

 version ::= major('.'minor('.'micro('.'qualifier)?)?)?
 major ::= digit+
 minor ::= digit+
 micro ::= digit+
 qualifier ::= (alpha|digit|'_'|'-')+
 digit ::= [0..9]
 alpha ::= [a..zA..Z]

Special purpose transformation / translation Maven plug-ins typically handle their up-to-date checking as part of MOJO execution. However, certain generic MOJOs (such as exec:exec) can be configured to perform arbitrary resource transformations that should, logically, be skipped if the target files are up to date with respect to their respective source files. However, there is at present no Maven mechanism for performing such up-to-date checks.

This is a feature request for a general purpose up-to-date checking capability for use in conjunction with such general purpose MOJOs. The new goal (say build-helper:uptodate-property) should be configurable to set a specified property to a specified value if a specified file set's target (output) files are up to date with respect to its source (input) files, and optionally to set the property to a different value if the target files are out of date. The associated file set needs to support an optional output directory and the standard Maven mapper types (flatten, glob, identity, merge, package, unpackage). A second goal (say build-helper:uptodate-properties) could simultaneously set multiple properties for multiple file sets, following the pattern established by the build-helper:regex-property and build-helper:regex-properties goals.

I shall provide an implementation, complete with test cases and documentation, and submit as a Pull Request.

Hello!

We use maven linkcheck plugin to check links on checkstyle's website: http://checkstyle.sourceforge.net/ . The plugin reports that on page http://checkstyle.sourceforge.net/plugins.html the following link is redirected:
http://mojo.codehaus.org/build-helper-maven-plugin (302 Found) at http://www.mojohaus.org .

Links on plugins.html are generated by Apache Maven Project Info Reports Plugin. All URLs are grabbed from effective POMs of plugins.

Here is the code:

https://github.com/apache/maven-plugins/blob/trunk/maven-project-info-reports-plugin/src/main/java/org/apache/maven/report/projectinfo/PluginsReport.java#L239

https://github.com/apache/maven-plugins/blob/trunk/maven-project-info-reports-plugin/src/main/java/org/apache/maven/report/projectinfo/PluginsReport.java#L269

In effective POM.xml of maven build helper plugin the problematic link is:
http://mojo.codehaus.org/build-helper-maven-plugin

As a result, we do not have an ability to change plugins urls on that page, because those links are specified by plugins developers.

So, please correct the link, because there are contradictions between linkcheck and maven build helper plugin.

Thank in advance!

Is it possible to have the time in 0-24 format?

Last commits are a year old and some of the new issues and pull requests are missing answers. Is this repository inactive @khmarbaise @dantran @rfscholte ? Is something specific needed to get the changes moving?

Any time scale for a 3.0.1 release, or any open defects or pull requests that need resolving before a 3.0.1 release is done?

I'd like to be able to define a property by applying multiple possible regex replacements to a value.

Specifically, I'd like to be able to, in Maven, canonicalize the Java "arch" parameter in the same way as JNA does in its Platform.getNativeLibraryResourcePrefix(), as follows:

${os.arch}:
amd64|x86_64 -> x86-64
i[3-6]86 -> x86
powerpc -> ppc
arm.* -> arm

(If there's already a way to do this with the existing regex-properties rule, it's not clear to me how to do it; consider this a doc enhancement request if so.)

Hi,

it seems the properties defined by the "reserve-network-port" goal will not override any properties with the same names specified in the main <properties> section of the pom, if the plugin execution is defined as part of a maven profile.

(Override works if the plugin is not defined inside a profile, but that does of course not make much sense. Also, using a default profile is not an option as other profiles need to be active.)

Is this generally impossible or could it be added?

Cheers
Martin

We have a project and in the pom.xml we did not specify the groupId becuase we inherit it from the parent pom.
If we then run mvn -B build-helper:parse-version versions:set -DnewVersion=\${parsedVersion.majorVersion}.\${parsedVersion.minorVersion}.\${parsedVersion.incrementalVersion}, we get an error:

[ERROR] Failed to execute goal org.codehaus.mojo:versions-maven-plugin:2.2:set (default-cli) on project dbutils: Execution default-cli of goal org.codehaus.mojo:versions-maven-plugin:2.2:set failed. NullPointerException -> [Help 1]

I checked this is a bug from the maven versions plugin and there are workarounds e.g., using 2.1 instead of 2.2.

Do you know, how can I avoid this error using your build-helper plugin?

Thank you,
Yashu

The released-version goal currently only provides access to the major, minor and incremental properties of the latest released version.

Could the functionality be added to set releasedVersion.buildNumber as well

Hello, I can't get a point how to use this plugin. No one of examples from usage page is working. I try to add timestamp to my pom.xml file with following configuration:

            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>build-helper-maven-plugin</artifactId>
                <version>3.0.0</version>
                <inherited>false</inherited>
                <executions>
                    <execution>
                        <id>timestamp-property</id>
                        <goals>
                            <goal>timestamp-property</goal>
                        </goals>
                        <configuration>
                            <name>timestamp</name>
                            <pattern>YYYY-MM-dd HH:mm:ss</pattern>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

but when I launch plugin with mvn build-helper:regex-property it shows an error:
The parameters 'name' for goal org.codehaus.mojo:build-helper-maven-plugin:3.0.0:timestamp-property are missing or invalid

It would be nice if build-helper-maven-plugin could set some properties within my Maven build context for me with the ports it picked. It's a little inconvenient to have it write them out to a file - then I have to read that file back into memory via properties-maven-plugin to access them.

Here's a specific use case: I have a Jenkins server that builds lots of stuff. Not everyone can have their test Jetty server running on port 8080 simultaneously, so we each use build-helper-maven-plugin to select a random port for it to use. But the jetty-maven-plugin configuration needs me to specify in the XML what port it runs on, which means I now have to read the random port back into memory with another plugin.

It would really be convenient to be able to skip that second step and have reserve-network-port set the variables as part of its invocation. Can we make that happen?

look at PR #36

Let me know if there was good reason to skip generation of this variable.

Christophe.

Often, some build resources at the root of a multi-module project are needed for the child modules. The child modules can be several layers deep. So, it is not easy to reference these resources with relative paths.

If a goal could be run to create a property once, at the root of a project, with an absolute path, then it would be easy for plugin configuration to reference resources relative to the root, regardless of how deep they are.

This would enable users to use the property like:

<configFile>${projectRoot.basedir}/build-resources/findbugs-excludes.xml</configFile>

(The above assumes that the property created by this goal was called "projectRoot.basedir". The actual property name should be configurable, but have a sensible default.)

Hi

I am using attach-artifact to attach a jar produced by IzPack. The pom is using the element to specify the name of the jar produced by IzPack but attach-atifact mojo uses the artifactId instead of the finalName. See below, the artifactId is installer while finalName is MI-4.1.1

C:\MXW\DEMOS\MI-4.1.1\MI_Installer>mvn install -o -rf :installer

C:\MXW\DEMOS\MI-4.1.1\MI_Installer>setlocal

C:\MXW\DEMOS\MI-4.1.1\MI_Installer>set JAVA_HOME=C:\Program Files\Java\jdk1.6.0_45

C:\MXW\DEMOS\MI-4.1.1\MI_Installer>set M2_HOME=C:\ASF\apache-maven-3.2.5

C:\MXW\DEMOS\MI-4.1.1\MI_Installer>C:\ASF\apache-maven-3.2.5\bin\mvn install -o -rf :installer
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Mainframe Integrator Installer Build with IzPack 4.1.1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven) @ installer ---
[INFO]
[INFO] --- maven-resources-plugin:2.7:copy-resources (copy-scripts) @ installer ---
[INFO] Using 'ISO-8859-15' encoding to copy filtered resources.
[INFO] Copying 6 resources
[INFO]
[INFO] --- maven-resources-plugin:2.7:copy-resources (copy-izpack-config) @ installer ---
[INFO] Using 'ISO-8859-15' encoding to copy filtered resources.
[INFO] Copying 9 resources
[INFO]
[INFO] --- maven-resources-plugin:2.7:copy-resources (copy-launch4j-config) @ installer ---
[INFO] Using 'ISO-8859-15' encoding to copy filtered resources.
[INFO] Copying 7 resources
[INFO]
[INFO] --- maven-antrun-plugin:1.8:run (create-staging-area) @ installer ---
[WARNING] Parameter tasks is deprecated, use target instead
[INFO] Executing tasks

main:
     [copy] Copying 1 file to C:\MXW\DEMOS\MI-4.1.1\MI_Installer\installer\target
[INFO] Executed tasks
[INFO]
[INFO] --- maven-dependency-plugin:2.8:copy-dependencies (copy-product-dependencies) @ installer ---
[INFO] Copying izpack-4.1.1.jar to C:\MXW\DEMOS\MI-4.1.1\MI_Installer\installer\target\lib\izpack.jar
[INFO] Copying commons-io-2.4.jar to C:\MXW\DEMOS\MI-4.1.1\MI_Installer\installer\target\lib\commons-io.jar
[INFO] Copying izpack-standalone-compiler-4.3.5.jar to C:\MXW\DEMOS\MI-4.1.1\MI_Installer\installer\target\lib\izpack-st
andalone-compiler.jar
[INFO]
[INFO] --- maven-dependency-plugin:2.8:copy-dependencies (copy-izpack-dependencies) @ installer ---
[INFO] Copying izpack-4.1.1.jar to C:\MXW\DEMOS\MI-4.1.1\MI_Installer\installer\target\custom\izpack-4.1.1.jar
[INFO]
[INFO] --- izpack-maven-plugin:5.0.10:izpack (default) @ installer ---
24 mars 2017 14:46:13 com.izforge.izpack.core.container.PlatformProvider provide
INFO: Detected platform: windows,version=6.1,arch=x64,symbolicName=WINDOWS_7,javaVersion=1.6.0_45
[INFO] Logging initialized at level 'INFO'
[WARNING] Maven property izpack.version could not be overridden
[INFO] Setting the installer information
[INFO] Adding content of jar: /C:/MXW/DEMOS/MI-4.1.1/MI_Installer/installer/target/lib/izpack.jar
[INFO] Adding content of jar: /C:/MXW/DEMOS/MI-4.1.1/MI_Installer/installer/target/lib/commons-io.jar
[INFO] Adding uninstaller
[INFO] Setting the installer information
[INFO] Setting the console preferences
[INFO] Setting the GUI preferences
[INFO] Adding langpack: fra
[INFO] Adding resource: flag.fra
[INFO] Adding resource: LicencePanel.licence
[INFO] Adding resource: shortcutSpec.xml
[INFO] Adding resource: installer.langsel.img
[INFO] Adding resource: Installer.image
[INFO] Adding resource: userInputSpec.xml
[INFO] Adding resource: userInputLang.xml_eng
[INFO] Adding resource: userInputLang.xml_fra
[INFO] Adding resource: ProcessPanel.Spec.xml
[INFO] Adding panel: panel.helloPanel :: Classname : com.izforge.izpack.panels.checkedhello.CheckedHelloPanel
[ATTENTION] No automation helper found for class com.izforge.izpack.panels.checkedhello.CheckedHelloPanel, panel type wi
ll be skipped in automated installation
[INFO] Adding panel: panel.licencePanel :: Classname : com.izforge.izpack.panels.licence.LicencePanel
[ATTENTION] No automation helper found for class com.izforge.izpack.panels.licence.LicencePanel, panel type will be skip
ped in automated installation
[INFO] Adding panel: panel.targetDirPanel :: Classname : com.izforge.izpack.panels.target.TargetPanel
[INFO] Adding panel: panel.jdkChoicePanel :: Classname : com.izforge.izpack.panels.jdkpath.JDKPathPanel
[INFO] Adding panel: panel.packsPanel :: Classname : com.izforge.izpack.panels.packs.PacksPanel
[INFO] Adding panel: panel.licenseFileSelectionPanel :: Classname : com.izforge.izpack.panels.userinput.UserInputPanel
[INFO] Adding panel: panel.summaryPanel :: Classname : com.izforge.izpack.panels.summary.SummaryPanel
[ATTENTION] No automation helper found for class com.izforge.izpack.panels.summary.SummaryPanel, panel type will be skip
ped in automated installation
[INFO] Adding panel: panel.installPanel :: Classname : com.izforge.izpack.panels.install.InstallPanel
[INFO] Adding panel: panel.postintallActionsPanel :: Classname : com.izforge.izpack.panels.process.ProcessPanel
[INFO] Adding panel: panel.shortcutPanel :: Classname : com.izforge.izpack.panels.shortcut.ShortcutPanel
[INFO] Adding panel: panel.finishPanel :: Classname : com.izforge.izpack.panels.finish.FinishPanel
[INFO] Adding content from archive: C:\MXW\DEMOS\MI-4.1.1\MI_Installer\installer\target\.\geronimo\geronimo-tomcat6-java
ee5-2.1.8-bin.zip
[INFO] Marked target file parsable: bin/miStart.sh
[INFO] Marked target file parsable: bin/miStop.sh
[INFO] Marked target file parsable: bin/vsVoyage.sh
[INFO] Adding pack Mainframe Integrator containing 9670 files
[INFO] Adding content from archive: C:\MXW\DEMOS\MI-4.1.1\MI_Installer\installer\target\.\launch4j\launch4j-3.9-win32.zi
p
[INFO] Marked target file parsable: launch4j/MIStart_launch4j_config.xml
[INFO] Marked target file parsable: launch4j/MIStop_launch4j_config.xml
[INFO] Marked target file parsable: launch4j/VsVoyage_launch4j_config.xml
[INFO] Adding pack Windows pack containing 325 files
[INFO] [ Begin ]
[INFO]
[INFO] Copying the skeleton installer
[INFO] Copying 10 files into installer
[INFO] Merging 0 jars into installer
[INFO] Writing 2 Packs into installer
[INFO] Writing Pack 0: Mainframe Integrator
[INFO] Writing Pack 1: Windows pack
[INFO]
[INFO] [ End ]
[INFO]
[INFO] --- build-helper-maven-plugin:1.12:attach-artifact (attach-artifacts) @ installer ---
[INFO]
[INFO] --- maven-install-plugin:2.5.2:install (default-install) @ installer ---
[INFO] Installing C:\MXW\DEMOS\MI-4.1.1\MI_Installer\installer\pom.xml to C:\Users\FrancisANDRE\.m2\repository\com\scort
\iz\mi\installer\4.1.1\installer-4.1.1.pom
[INFO] Installing C:\MXW\DEMOS\MI-4.1.1\MI_Installer\installer\target\MI-4.1.1.jar to C:\Users\FrancisANDRE\.m2\reposito
ry\com\scort\iz\mi\installer\4.1.1\installer-4.1.1.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:22 min
[INFO] Finished at: 2017-03-24T14:47:29+01:00
[INFO] Final Memory: 51M/691M
[INFO] ------------------------------------------------------------------------
C:\MXW\DEMOS\MI-4.1.1\MI_Installer>

Dear all,

We hit following exception when running enforcer plugin with maven2.

[INFO] [enforcer:enforce {execution: enforce-java}]
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] org.codehaus.plexus.component.configurator.BasicComponentConfigurator cannot be cast to org.codehaus.plexus.component.configurator.ComponentConfigurator
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.ClassCastException: org.codehaus.plexus.component.configurator.BasicComponentConfigurator cannot be cast to org.codehaus.plexus.component.configurator.ComponentConfigurator
at org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1351)
at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:724)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:468)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] ------------------------------------------------------------------------

We can work around the issue by downgrading the plugin to version 1.10, or upgrading the maven to maven3.

Appreciate if anyone can take a look.

Thanks and regards,
William

I just ran across this article indicating functionality that I never knew existed! This would be a nice addition to the documentation for the parse-version goal.

Using the rootlocation in a multi module build and having a sub module which contains rootlocation.

Calling mvn like this:

mvn -pl submodule package

Does not seemed to work correctly.

If resources are generated at build time from java code in the project, add-resources must be called after the compile phase. When a phase later than generate-resources is specified for build-helper-maven-plugin, it does not add the resource to the target jar.
running mvn 3.3.9, freebsd 10.3, java 1.8.0_112
One can test this in the simple example by creating a file in
src/xmldata/foo.xml
and adding the following to the pom:

I'm building Apache Ranger using eclipse neon.2 & the m2e plugin.

I was initially using the 1.9.1 release but see the same behaviour with 1.12 (modify ranger/pom.xml)

Would it be possible to add the required changes to support these also?

Hi

I am having a small issue with my SNAPSHOT versions, or the lack of them.

I am trying to run the same command on my project, whether it is a SNAPSHOT version or not:
mvn build-helper:parse-version versions:set -DnewVersion=${parsedVersion.majorVersion}.${parsedVersion.nextMinorVersion}.${parsedVersion.incrementalVersion}-${parsedVersion.qualifier} versions:commit

In case of a SSNAPSHOT version, all is well, but as soon as it is a "release" version, without the qualifier I end up with a trailing "-".

How can I get past that ?

Thanks in advance

Yoav

Now that the Codehaus page no longer exists, it would be nice to have something online to which developers could go to get usage details etc.

The maven.build.timestamp property does not allow for timezone overrides for obvious reasons.

The timestamp-property goal can be used to create one with a local timezone timestamp. But the default implementation uses the current time, which is thus not the same for all modules in a multi module project.

The new timeSource parameter with value build now allows the usage of maven.build.timestamp property instead of the current timestamp.