[jira] [Created] (MRELEASE-1119) release plugin ignore developmentVersion

[Robert Patrick (Jira)]

Robert Patrick created MRELEASE-1119:


 Summary: release plugin ignore developmentVersion
 Key: MRELEASE-1119
 URL: https://issues.apache.org/jira/browse/MRELEASE-1119
 Project: Maven Release Plugin
  Issue Type: Bug
Reporter: Robert Patrick


I just ran a release process using the 3.0.0 version of the 
maven-release-plugin with a release.properties file like this:

{{tag=release-3.0.4}}
{{releaseVersion=3.0.4}}
{{developmentVersion=3.1.0-SNAPSHOT}}

After running {{mvn -B release:prepare release:perform}}, the pom.xml version 
is 3.0.5-SNAPSHOT. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MRELEASE-1119) release plugin ignore developmentVersion

[Robert Patrick (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17703153#comment-17703153
 ] 

Robert Patrick commented on MRELEASE-1119:
--

No

On Tue, Mar 21, 2023 at 2:29 AM Michael Osipov (Jira) 



> release plugin ignore developmentVersion
> 
>
> Key: MRELEASE-1119
> URL: https://issues.apache.org/jira/browse/MRELEASE-1119
> Project: Maven Release Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Robert Patrick
>Priority: Major
>
> I just ran a release process using the 3.0.0 version of the 
> maven-release-plugin with a release.properties file like this:
> {{tag=release-3.0.4}}
> {{releaseVersion=3.0.4}}
> {{developmentVersion=3.1.0-SNAPSHOT}}
> After running {{mvn -B release:prepare release:perform}}, the pom.xml version 
> is 3.0.5-SNAPSHOT. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (MRELEASE-1119) release plugin ignores developmentVersion

[Robert Patrick (Jira)]

 [ 
https://issues.apache.org/jira/browse/MRELEASE-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Patrick updated MRELEASE-1119:
-
Summary: release plugin ignores developmentVersion  (was: release plugin 
ignore developmentVersion)

> release plugin ignores developmentVersion
> -
>
> Key: MRELEASE-1119
> URL: https://issues.apache.org/jira/browse/MRELEASE-1119
> Project: Maven Release Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Robert Patrick
>Priority: Major
>
> I just ran a release process using the 3.0.0 version of the 
> maven-release-plugin with a release.properties file like this:
> {{tag=release-3.0.4}}
> {{releaseVersion=3.0.4}}
> {{developmentVersion=3.1.0-SNAPSHOT}}
> After running {{mvn -B release:prepare release:perform}}, the pom.xml version 
> is 3.0.5-SNAPSHOT. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MRELEASE-1119) release plugin ignores developmentVersion

[Robert Patrick (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711647#comment-17711647
 ] 

Robert Patrick commented on MRELEASE-1119:
--

No, I have not.  No one wants to type a big long command line when this has
been advertised as working for years and does work provided you only
increment the last digit.  As soon as you try to do anything else, it
ignores what you tell it and increments the last digit.

See https://github.com/oracle/weblogic-deploy-tooling

On Wed, Apr 12, 2023 at 6:14 PM Karl Heinz Marbaise (Jira) 



> release plugin ignores developmentVersion
> -
>
> Key: MRELEASE-1119
> URL: https://issues.apache.org/jira/browse/MRELEASE-1119
> Project: Maven Release Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Robert Patrick
>Assignee: Karl Heinz Marbaise
>Priority: Major
>
> I just ran a release process using the 3.0.0 version of the 
> maven-release-plugin with a release.properties file like this:
> {{tag=release-3.0.4}}
> {{releaseVersion=3.0.4}}
> {{developmentVersion=3.1.0-SNAPSHOT}}
> After running {{mvn -B release:prepare release:perform}}, the pom.xml version 
> is 3.0.5-SNAPSHOT. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MRELEASE-1119) release plugin ignores developmentVersion

[Robert Patrick (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17712110#comment-17712110
 ] 

Robert Patrick commented on MRELEASE-1119:
--

{quote}I just ran a release process using the 3.0.0 version of the 
maven-release-plugin with a release.properties file like this:

{{tag=release-3.0.4}}
{{releaseVersion=3.0.4}}
{{developmentVersion=3.1.0-SNAPSHOT}}

After running {{{}mvn -B release:prepare release:perform{}}}, the pom.xml 
version is 3.0.5-SNAPSHOT. 
{quote}
[~khmarbaise] I thought I was very clear in the original description.
 # I created a release.properties file with the tag, releaseVersion, and 
developmentVersion properties defined in it.
 # From the command-line at the basedir, I ran:   {{mvn -B release:prepare 
release:perform}}

The root level POM has a 
[declaration|https://github.com/oracle/weblogic-deploy-tooling/blob/main/pom.xml#L321-L330]
 for the maven-release-plugin.

> release plugin ignores developmentVersion
> -
>
> Key: MRELEASE-1119
> URL: https://issues.apache.org/jira/browse/MRELEASE-1119
> Project: Maven Release Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Robert Patrick
>Assignee: Karl Heinz Marbaise
>Priority: Major
>
> I just ran a release process using the 3.0.0 version of the 
> maven-release-plugin with a release.properties file like this:
> {{tag=release-3.0.4}}
> {{releaseVersion=3.0.4}}
> {{developmentVersion=3.1.0-SNAPSHOT}}
> After running {{mvn -B release:prepare release:perform}}, the pom.xml version 
> is 3.0.5-SNAPSHOT. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MRELEASE-1119) release plugin ignores developmentVersion

[Robert Patrick (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17712110#comment-17712110
 ] 

Robert Patrick edited comment on MRELEASE-1119 at 4/13/23 10:14 PM:


{quote}I just ran a release process using the 3.0.0 version of the 
maven-release-plugin with a release.properties file like this:

{{tag=release-3.0.4}}
{{releaseVersion=3.0.4}}
{{developmentVersion=3.1.0-SNAPSHOT}}

After running {{{}mvn -B release:prepare release:perform{}}}, the pom.xml 
version is 3.0.5-SNAPSHOT. 
{quote}
[~khmarbaise] I thought I was very clear in the original description.
 # I created a release.properties file with the tag, releaseVersion, and 
developmentVersion properties defined in it.
 # From the command-line at the basedir, I ran:   {{mvn -B release:prepare 
release:perform}}

The root level POM has a 
[declaration|https://github.com/oracle/weblogic-deploy-tooling/blob/main/pom.xml#L321-L330]
 for the maven-release-plugin.  No profiles or anything relevant in settings.xml


was (Author: rhpatrick00):
{quote}I just ran a release process using the 3.0.0 version of the 
maven-release-plugin with a release.properties file like this:

{{tag=release-3.0.4}}
{{releaseVersion=3.0.4}}
{{developmentVersion=3.1.0-SNAPSHOT}}

After running {{{}mvn -B release:prepare release:perform{}}}, the pom.xml 
version is 3.0.5-SNAPSHOT. 
{quote}
[~khmarbaise] I thought I was very clear in the original description.
 # I created a release.properties file with the tag, releaseVersion, and 
developmentVersion properties defined in it.
 # From the command-line at the basedir, I ran:   {{mvn -B release:prepare 
release:perform}}

The root level POM has a 
[declaration|https://github.com/oracle/weblogic-deploy-tooling/blob/main/pom.xml#L321-L330]
 for the maven-release-plugin.

> release plugin ignores developmentVersion
> -
>
> Key: MRELEASE-1119
> URL: https://issues.apache.org/jira/browse/MRELEASE-1119
> Project: Maven Release Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Robert Patrick
>Assignee: Karl Heinz Marbaise
>Priority: Major
>
> I just ran a release process using the 3.0.0 version of the 
> maven-release-plugin with a release.properties file like this:
> {{tag=release-3.0.4}}
> {{releaseVersion=3.0.4}}
> {{developmentVersion=3.1.0-SNAPSHOT}}
> After running {{mvn -B release:prepare release:perform}}, the pom.xml version 
> is 3.0.5-SNAPSHOT. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MRELEASE-1119) release plugin ignores developmentVersion

[Robert Patrick (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17712110#comment-17712110
 ] 

Robert Patrick edited comment on MRELEASE-1119 at 4/13/23 10:16 PM:


{quote}I just ran a release process using the 3.0.0 version of the 
maven-release-plugin with a release.properties file like this:

{{tag=release-3.0.4}}
{{releaseVersion=3.0.4}}
{{developmentVersion=3.1.0-SNAPSHOT}}

After running {{{}mvn -B release:prepare release:perform{}}}, the pom.xml 
version is 3.0.5-SNAPSHOT. 
{quote}
[~khmarbaise] I thought I was very clear in the original description.
 # In basedir, I created a release.properties file with the tag, 
releaseVersion, and developmentVersion properties defined in it.
 # From the command-line at the basedir, I ran:   {{mvn -B release:prepare 
release:perform}}

The root level POM has a 
[declaration|https://github.com/oracle/weblogic-deploy-tooling/blob/main/pom.xml#L321-L330]
 for the maven-release-plugin.  No profiles or anything relevant in settings.xml


was (Author: rhpatrick00):
{quote}I just ran a release process using the 3.0.0 version of the 
maven-release-plugin with a release.properties file like this:

{{tag=release-3.0.4}}
{{releaseVersion=3.0.4}}
{{developmentVersion=3.1.0-SNAPSHOT}}

After running {{{}mvn -B release:prepare release:perform{}}}, the pom.xml 
version is 3.0.5-SNAPSHOT. 
{quote}
[~khmarbaise] I thought I was very clear in the original description.
 # I created a release.properties file with the tag, releaseVersion, and 
developmentVersion properties defined in it.
 # From the command-line at the basedir, I ran:   {{mvn -B release:prepare 
release:perform}}

The root level POM has a 
[declaration|https://github.com/oracle/weblogic-deploy-tooling/blob/main/pom.xml#L321-L330]
 for the maven-release-plugin.  No profiles or anything relevant in settings.xml

> release plugin ignores developmentVersion
> -
>
> Key: MRELEASE-1119
> URL: https://issues.apache.org/jira/browse/MRELEASE-1119
> Project: Maven Release Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Robert Patrick
>Assignee: Karl Heinz Marbaise
>Priority: Major
>
> I just ran a release process using the 3.0.0 version of the 
> maven-release-plugin with a release.properties file like this:
> {{tag=release-3.0.4}}
> {{releaseVersion=3.0.4}}
> {{developmentVersion=3.1.0-SNAPSHOT}}
> After running {{mvn -B release:prepare release:perform}}, the pom.xml version 
> is 3.0.5-SNAPSHOT. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MRELEASE-1119) release plugin ignores developmentVersion

[Robert Patrick (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17712119#comment-17712119
 ] 

Robert Patrick commented on MRELEASE-1119:
--

I just created a very simple project–nothing but a pom.    

[https://github.com/robertpatrick/mrp-test]

The initial commit was at version 3.0.4-SNAPSHOT.

{{{}I created the release.properties file in the basedir with the following 
contents:{}}}{{{}{}}}

{{tag=release-3.0.4}}
{{releaseVersion=3.0.4}}
{{developmentVersion=3.1.0-SNAPSHOT}}

{{Ran: mvn -B release:prepare release:perform}}

{{Same issue.  After the release process finished, the pom version is 
3.0.5-SNAPSHOT.}}

 

 

 

> release plugin ignores developmentVersion
> -
>
> Key: MRELEASE-1119
> URL: https://issues.apache.org/jira/browse/MRELEASE-1119
> Project: Maven Release Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Robert Patrick
>Assignee: Karl Heinz Marbaise
>Priority: Major
>
> I just ran a release process using the 3.0.0 version of the 
> maven-release-plugin with a release.properties file like this:
> {{tag=release-3.0.4}}
> {{releaseVersion=3.0.4}}
> {{developmentVersion=3.1.0-SNAPSHOT}}
> After running {{mvn -B release:prepare release:perform}}, the pom.xml version 
> is 3.0.5-SNAPSHOT. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MRELEASE-1119) release plugin ignores developmentVersion

[Robert Patrick (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17712367#comment-17712367
 ] 

Robert Patrick commented on MRELEASE-1119:
--

That is really ugly.  The property file I showed works perfectly fine except 
when changing the development version.  Not sure I understand why the same 
system properties you use on the command-line cannot be used in the 
release.properties file.  Seems like everything expect the developmentVersion 
is already working using the old approach I was using.  If this were my 
project, I would treat that as a bug...   

> release plugin ignores developmentVersion
> -
>
> Key: MRELEASE-1119
> URL: https://issues.apache.org/jira/browse/MRELEASE-1119
> Project: Maven Release Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Robert Patrick
>Assignee: Karl Heinz Marbaise
>Priority: Major
>
> I just ran a release process using the 3.0.0 version of the 
> maven-release-plugin with a release.properties file like this:
> {{tag=release-3.0.4}}
> {{releaseVersion=3.0.4}}
> {{developmentVersion=3.1.0-SNAPSHOT}}
> After running {{mvn -B release:prepare release:perform}}, the pom.xml version 
> is 3.0.5-SNAPSHOT. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (MNGSITE-523) Maven Enforcer Plugin goals page not found

[Robert Patrick (Jira)]

Robert Patrick created MNGSITE-523:
--

 Summary: Maven Enforcer Plugin goals page not found
 Key: MNGSITE-523
 URL: https://issues.apache.org/jira/browse/MNGSITE-523
 Project: Maven Project Web Site
  Issue Type: Bug
Reporter: Robert Patrick
 Attachments: Screenshot 2023-09-06 at 2.20.30 PM.png

It is no longer possible to navigate the the goals page for the Maven Enforcer 
Plugin...see attached



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (MCOMPILER-553) Multi-release build generates compilerSourceRoots is read-only warning

[Robert Patrick (Jira)]

Robert Patrick created MCOMPILER-553:


 Summary: Multi-release build generates compilerSourceRoots is 
read-only warning
 Key: MCOMPILER-553
 URL: https://issues.apache.org/jira/browse/MCOMPILER-553
 Project: Maven Compiler Plugin
  Issue Type: Bug
Affects Versions: 3.10.1
Reporter: Robert Patrick


We are building a multi-release jar in a module of our project.  As such, the 
directory structure looks like this:

{{src/main}}
{{    java}}
{{{}    java17{}}}{{{}{}}}

To get this to work, we are doing the following:

{{}}
{{  org.apache.maven.plugins}}
{{  maven-compiler-plugin}}
{{  }}
{{    }}
{{      default-compile}}
{{      }}
{{        compile}}
{{      }}
{{      }}
{{        7}}
{{        7}}
{{      }}
{{    }}
{{    }}
{{      compile-java-17}}
{{      }}
{{        compile}}
{{      }}
{{      }}
{{        17}}
{{        17}}
{{        17}}
{{        }}
{{          
${project.basedir}/src/main/java17}}
{{        }}
{{        true}}
{{      }}
{{    }}
{{  }}
{{}}

The build works fine but I am getting this annoying warning:

[*INFO*] *---* compiler:3.10.1:compile *(compile-java-17)* @ 
weblogic-deploy-core *---*

[*WARNING*]  Parameter 'compileSourceRoots' is read-only, must not be used in 
configuration

[*INFO*] Changes detected - recompiling the module!

[*INFO*] Compiling 2 source files to 
/Users/rpatrick/Projects/weblogic-deploy-tooling/core/target/classes/META-INF/versions/17

[*INFO*] 

 

I have tried using includes and excludes instead but that results in all 
classes from src/main/java in the JAR file's META_INF/versions/17 directory.  
If there is a better way to accomplish this, please let me know.  Otherwise, I 
think it is wrong to print a warning for something that appears to be the only 
way to make it work.

 

 

 

 

 

 

 

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (MENFORCER-439) 3.1.0 will not run with JDK 7

[Robert Patrick (Jira)]

Robert Patrick created MENFORCER-439:


 Summary: 3.1.0 will not run with JDK 7
 Key: MENFORCER-439
 URL: https://issues.apache.org/jira/browse/MENFORCER-439
 Project: Maven Enforcer Plugin
  Issue Type: Bug
  Components: Plugin
Affects Versions: 3.1.0
 Environment: Maven 3.8.6
JDK 7u351
Reporter: Robert Patrick


Using JDK 7u351 to run an integration-test build on some older software, we get 
an error because one of the plugin's dependencies seems to require JDK 8.  
Maven 3.8.6 is supposed to support JDK 7 so it would be good if the core 
plugins followed that lead.  Is there an earlier version we can use to get 
around this issue? 


[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-enforcer-plugin:3.1.0:enforce 
(enforce-build-environment) on project weblogic-deploy-alias-test-generate: 
Execution enforce-build-environment of goal 
org.apache.maven.plugins:maven-enforcer-plugin:3.1.0:enforce failed: Unable to 
load the mojo 'enforce' in the plugin 
'org.apache.maven.plugins:maven-enforcer-plugin:3.1.0' due to an API 
incompatibility: 
org.codehaus.plexus.component.repository.exception.ComponentLookupException: 
org/apache/maven/plugins/enforcer/EnforceMojo : Unsupported major.minor version 
52.0



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

Robert Patrick created MNG-6083:
---

 Summary: Maven 3.3.9 breaks release:perform by not including 
maven.config
 Key: MNG-6083
 URL: https://issues.apache.org/jira/browse/MNG-6083
 Project: Maven
  Issue Type: Bug
  Components: General
Affects Versions: 3.3.9
Reporter: Robert Patrick
Priority: Blocker


Our release process runs both our build and our integration tests.  The 
integration tests rely on our project root directory's .mvn/maven.config file 
to run properly.  The maven.config file is NOT checked into the source tree 
because it contains environment-specific values so each developer has their own 
version of it on each machine on which they build.

This has been working fine for months now but simply changing the version of 
Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having the 
-Ds defined in $PROJECT_ROOT/.mvn/maven.config.

It appears that the release:perform goal checks out the release source in 
another location and with Maven 3.3.9, the maven.config from the original 
location is not being used.  The build specifies the release-plugin version so 
the difference seems to be in the core Maven distribution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15455263#comment-15455263
 ] 

Robert Patrick commented on MNG-6083:
-

Well...  In our case, we need to add things like "where is the database 
software installed" so that we can use the database client (e.g., sqlplus) to 
create/populate the necessary database tables that we need for our integration 
tests.  This all works fine in Maven 3.3.3 so something that was changed in 
3.3.9 changed the behavior.

If I cannot use maven.config for environment-specific details, what do you 
suggest?  Environment variables?  System properties?  I thought the whole idea 
of maven.config was to remove those undocumented project dependencies and make 
them part of the project.  We have a maven.config-template file checked in.  
The developers copy that file and edit it for their environment.  I suppose we 
could be more nazi-like and tell them that they all have to have everything in 
their environment in the specified location but, if you have ever worked with 
developers, that rubs them the wrong way... :-)


> Maven 3.3.9 breaks release:perform by not including maven.config
> 
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.3.9
>Reporter: Robert Patrick
>Priority: Blocker
>
> Our release process runs both our build and our integration tests.  The 
> integration tests rely on our project root directory's .mvn/maven.config file 
> to run properly.  The maven.config file is NOT checked into the source tree 
> because it contains environment-specific values so each developer has their 
> own version of it on each machine on which they build.
> This has been working fine for months now but simply changing the version of 
> Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having 
> the -Ds defined in $PROJECT_ROOT/.mvn/maven.config.
> It appears that the release:perform goal checks out the release source in 
> another location and with Maven 3.3.9, the maven.config from the original 
> location is not being used.  The build specifies the release-plugin version 
> so the difference seems to be in the core Maven distribution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15455269#comment-15455269
 ] 

Robert Patrick commented on MNG-6083:
-

By the way, we are using them for Maven's command-line configuration...

-Dmyproperty=/u01/path/to/required/software

Or are you trying to tell me that it was only designed for -Ds that Maven 
defines?

> Maven 3.3.9 breaks release:perform by not including maven.config
> 
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.3.9
>Reporter: Robert Patrick
>Priority: Blocker
>
> Our release process runs both our build and our integration tests.  The 
> integration tests rely on our project root directory's .mvn/maven.config file 
> to run properly.  The maven.config file is NOT checked into the source tree 
> because it contains environment-specific values so each developer has their 
> own version of it on each machine on which they build.
> This has been working fine for months now but simply changing the version of 
> Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having 
> the -Ds defined in $PROJECT_ROOT/.mvn/maven.config.
> It appears that the release:perform goal checks out the release source in 
> another location and with Maven 3.3.9, the maven.config from the original 
> location is not being used.  The build specifies the release-plugin version 
> so the difference seems to be in the core Maven distribution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15457205#comment-15457205
 ] 

Robert Patrick commented on MNG-6083:
-

That's a great tip but given that I have a about 20 or so possible -Ds in 
maven.config, it will be very painful to do this on the command-line.  I guess 
I will just stay on 3.3.3 until I invent my own way to deal with this outside 
of Maven...it's too bad whoever designed maven.config didn't consider this use 
case...

> Maven 3.3.9 breaks release:perform by not including maven.config
> 
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.3.9
>Reporter: Robert Patrick
>Priority: Blocker
>
> Our release process runs both our build and our integration tests.  The 
> integration tests rely on our project root directory's .mvn/maven.config file 
> to run properly.  The maven.config file is NOT checked into the source tree 
> because it contains environment-specific values so each developer has their 
> own version of it on each machine on which they build.
> This has been working fine for months now but simply changing the version of 
> Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having 
> the -Ds defined in $PROJECT_ROOT/.mvn/maven.config.
> It appears that the release:perform goal checks out the release source in 
> another location and with Maven 3.3.9, the maven.config from the original 
> location is not being used.  The build specifies the release-plugin version 
> so the difference seems to be in the core Maven distribution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15457205#comment-15457205
 ] 

Robert Patrick edited comment on MNG-6083 at 9/2/16 1:50 AM:
-

That's a great tip but given that I have about 20 or so possible -Ds in 
maven.config, it will be very painful to do this on the command-line.  I guess 
I will just stay on 3.3.3 until I invent my own way to deal with this outside 
of Maven...it's too bad whoever designed maven.config didn't consider this use 
case...


was (Author: rhpatrick00):
That's a great tip but given that I have a about 20 or so possible -Ds in 
maven.config, it will be very painful to do this on the command-line.  I guess 
I will just stay on 3.3.3 until I invent my own way to deal with this outside 
of Maven...it's too bad whoever designed maven.config didn't consider this use 
case...

> Maven 3.3.9 breaks release:perform by not including maven.config
> 
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.3.9
>Reporter: Robert Patrick
>Priority: Blocker
>
> Our release process runs both our build and our integration tests.  The 
> integration tests rely on our project root directory's .mvn/maven.config file 
> to run properly.  The maven.config file is NOT checked into the source tree 
> because it contains environment-specific values so each developer has their 
> own version of it on each machine on which they build.
> This has been working fine for months now but simply changing the version of 
> Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having 
> the -Ds defined in $PROJECT_ROOT/.mvn/maven.config.
> It appears that the release:perform goal checks out the release source in 
> another location and with Maven 3.3.9, the maven.config from the original 
> location is not being used.  The build specifies the release-plugin version 
> so the difference seems to be in the core Maven distribution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15459480#comment-15459480
 ] 

Robert Patrick commented on MNG-6083:
-

And how exactly do you propose that would work if the property values vary 
across the environments where it needs to run (e.g., Windows vs. Linux)?  You 
have made it very clear that you believe in checking the maven.config file into 
source control.  What you haven't made clear is how you you handle 
environment-specific dependencies that the project has without the developers 
stepping on each other by overwriting maven.config every time they check in.  
Clearly, you don't feel like maven.config is the solution for this.  So what is?

> Maven 3.3.9 breaks release:perform by not including maven.config
> 
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.3.9
>Reporter: Robert Patrick
>Priority: Blocker
>
> Our release process runs both our build and our integration tests.  The 
> integration tests rely on our project root directory's .mvn/maven.config file 
> to run properly.  The maven.config file is NOT checked into the source tree 
> because it contains environment-specific values so each developer has their 
> own version of it on each machine on which they build.
> This has been working fine for months now but simply changing the version of 
> Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having 
> the -Ds defined in $PROJECT_ROOT/.mvn/maven.config.
> It appears that the release:perform goal checks out the release source in 
> another location and with Maven 3.3.9, the maven.config from the original 
> location is not being used.  The build specifies the release-plugin version 
> so the difference seems to be in the core Maven distribution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15459480#comment-15459480
 ] 

Robert Patrick edited comment on MNG-6083 at 9/2/16 8:13 PM:
-

And how exactly do you propose that would work if the property values vary 
across the environments where it needs to run (e.g., Windows vs. Linux)?  You 
have made it very clear that you believe in checking the maven.config file into 
source control.  What you haven't made clear is how you would handle 
environment-specific dependencies that the project has without the developers 
stepping on each other by overwriting maven.config every time they check in.  
Clearly, you don't feel like maven.config is the solution for this.  So what is?


was (Author: rhpatrick00):
And how exactly do you propose that would work if the property values vary 
across the environments where it needs to run (e.g., Windows vs. Linux)?  You 
have made it very clear that you believe in checking the maven.config file into 
source control.  What you haven't made clear is how you you handle 
environment-specific dependencies that the project has without the developers 
stepping on each other by overwriting maven.config every time they check in.  
Clearly, you don't feel like maven.config is the solution for this.  So what is?

> Maven 3.3.9 breaks release:perform by not including maven.config
> 
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.3.9
>Reporter: Robert Patrick
>Priority: Blocker
>
> Our release process runs both our build and our integration tests.  The 
> integration tests rely on our project root directory's .mvn/maven.config file 
> to run properly.  The maven.config file is NOT checked into the source tree 
> because it contains environment-specific values so each developer has their 
> own version of it on each machine on which they build.
> This has been working fine for months now but simply changing the version of 
> Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having 
> the -Ds defined in $PROJECT_ROOT/.mvn/maven.config.
> It appears that the release:perform goal checks out the release source in 
> another location and with Maven 3.3.9, the maven.config from the original 
> location is not being used.  The build specifies the release-plugin version 
> so the difference seems to be in the core Maven distribution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15459551#comment-15459551
 ] 

Robert Patrick commented on MNG-6083:
-

Maven profiles would be one way of solving this.  Of course, we are already 
using profiles to control what sub-modules get build in different situations 
(e.g.., dev, dev-install, system-test) so we cannot use profiles to handle this 
without losing the ability to control what submodules we run or at least not 
without duplicating tons of configuration across the various 
"environment-specific profiles":

I would have to create multiple versions of our current system-test (i.e., 
integration tests) profile--one for every developer/environment--with all of 
the content duplicated (making for a pom maintenance nightmare)

fred-system-test
fred-linux-system-test
jane-system-test
mary-system-test
bert-system-test
jenkins-system-test

Definitely not a manageable solution...  It looks like the only solution Maven 
offers is environment variables.

> Maven 3.3.9 breaks release:perform by not including maven.config
> 
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.3.9
>Reporter: Robert Patrick
>Priority: Blocker
>
> Our release process runs both our build and our integration tests.  The 
> integration tests rely on our project root directory's .mvn/maven.config file 
> to run properly.  The maven.config file is NOT checked into the source tree 
> because it contains environment-specific values so each developer has their 
> own version of it on each machine on which they build.
> This has been working fine for months now but simply changing the version of 
> Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having 
> the -Ds defined in $PROJECT_ROOT/.mvn/maven.config.
> It appears that the release:perform goal checks out the release source in 
> another location and with Maven 3.3.9, the maven.config from the original 
> location is not being used.  The build specifies the release-plugin version 
> so the difference seems to be in the core Maven distribution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15459551#comment-15459551
 ] 

Robert Patrick edited comment on MNG-6083 at 9/2/16 8:46 PM:
-

Maven profiles would be one way of solving this.  Of course, we are already 
using profiles to control what sub-modules get build in different situations 
(e.g.., dev, dev-install, system-test) so we cannot use profiles to handle this 
without losing the ability to control what submodules we run or at least not 
without duplicating tons of configuration across the various 
"environment-specific profiles":

I would have to create multiple versions of our current system-test (i.e., 
integration tests) profile, one for every developer/environment, with all of 
the content duplicated (making for a pom maintenance nightmare)

fred-system-test
fred-linux-system-test
jane-system-test
mary-system-test
bert-system-test
jenkins-system-test

Definitely not a manageable solution...  It looks like the only solution Maven 
offers is environment variables.


was (Author: rhpatrick00):
Maven profiles would be one way of solving this.  Of course, we are already 
using profiles to control what sub-modules get build in different situations 
(e.g.., dev, dev-install, system-test) so we cannot use profiles to handle this 
without losing the ability to control what submodules we run or at least not 
without duplicating tons of configuration across the various 
"environment-specific profiles":

I would have to create multiple versions of our current system-test (i.e., 
integration tests) profile--one for every developer/environment--with all of 
the content duplicated (making for a pom maintenance nightmare)

fred-system-test
fred-linux-system-test
jane-system-test
mary-system-test
bert-system-test
jenkins-system-test

Definitely not a manageable solution...  It looks like the only solution Maven 
offers is environment variables.

> Maven 3.3.9 breaks release:perform by not including maven.config
> 
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.3.9
>Reporter: Robert Patrick
>Priority: Blocker
>
> Our release process runs both our build and our integration tests.  The 
> integration tests rely on our project root directory's .mvn/maven.config file 
> to run properly.  The maven.config file is NOT checked into the source tree 
> because it contains environment-specific values so each developer has their 
> own version of it on each machine on which they build.
> This has been working fine for months now but simply changing the version of 
> Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having 
> the -Ds defined in $PROJECT_ROOT/.mvn/maven.config.
> It appears that the release:perform goal checks out the release source in 
> another location and with Maven 3.3.9, the maven.config from the original 
> location is not being used.  The build specifies the release-plugin version 
> so the difference seems to be in the core Maven distribution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15459551#comment-15459551
 ] 

Robert Patrick edited comment on MNG-6083 at 9/2/16 8:50 PM:
-

Maven profiles would be one way of solving this.  Of course, we are already 
using profiles to control what sub-modules get build in different situations 
(e.g.., dev, dev-install, system-test) so we cannot use profiles to handle this 
without losing the ability to control what submodules we run or at least not 
without duplicating tons of configuration across the various 
"environment-specific profiles":

I would have to create multiple versions of our current system-test (i.e., 
integration tests) profile, one for every developer/environment, with all of 
the content duplicated (making for a pom maintenance nightmare)

fred-system-test
fred-linux-system-test
jane-system-test
mary-system-test
bert-system-test
jenkins-system-test

Definitely not a manageable solution...  It looks like the only solution Maven 
offers is environment variables.

The concern is whether those will work properly with the Maven release process 
or not...


was (Author: rhpatrick00):
Maven profiles would be one way of solving this.  Of course, we are already 
using profiles to control what sub-modules get build in different situations 
(e.g.., dev, dev-install, system-test) so we cannot use profiles to handle this 
without losing the ability to control what submodules we run or at least not 
without duplicating tons of configuration across the various 
"environment-specific profiles":

I would have to create multiple versions of our current system-test (i.e., 
integration tests) profile, one for every developer/environment, with all of 
the content duplicated (making for a pom maintenance nightmare)

fred-system-test
fred-linux-system-test
jane-system-test
mary-system-test
bert-system-test
jenkins-system-test

Definitely not a manageable solution...  It looks like the only solution Maven 
offers is environment variables.

> Maven 3.3.9 breaks release:perform by not including maven.config
> 
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.3.9
>Reporter: Robert Patrick
>Priority: Blocker
>
> Our release process runs both our build and our integration tests.  The 
> integration tests rely on our project root directory's .mvn/maven.config file 
> to run properly.  The maven.config file is NOT checked into the source tree 
> because it contains environment-specific values so each developer has their 
> own version of it on each machine on which they build.
> This has been working fine for months now but simply changing the version of 
> Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having 
> the -Ds defined in $PROJECT_ROOT/.mvn/maven.config.
> It appears that the release:perform goal checks out the release source in 
> another location and with Maven 3.3.9, the maven.config from the original 
> location is not being used.  The build specifies the release-plugin version 
> so the difference seems to be in the core Maven distribution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15462892#comment-15462892
 ] 

Robert Patrick commented on MNG-6083:
-

Karl, 

I already explained why I need different environments for different developers. 
 We are building real-world software that depends on commercial software 
packages.  I have four profiles defined in my top-level POM:

dev - this is the default profile that developers use to build and run unit 
tests on the software we are building
dev-install - this profile that builds our "installer", which is a zip file, 
and "installs" it in a directory that developers can use to run manual tests.
system-test - this profile is what runs our integration tests.  These tests 
depend on complex setup for a commercial software package.
release - this profile is the one used for running the Maven release process, 
that includes all modules.

We have two main Jenkins job types.  One build the software and runs the unit 
tests (using the default dev profile) and pushs the resulting SNAPSHOT JARs 
into Artifactory.  The other job runs nightly and runs our system-test profile 
to build our installer and run the integration tests against it, publishing the 
new installer to Artifactory if the integration tests succeed.  This installer 
can then be picked up by automated QA jobs that further test the quality of the 
nightly build. 

The current properties in maven.config are:

1.) The location of the "install directory" where the dev-install profile 
creates an installed version of the software.  For example, mine is currently 
set to -Da2c-home-parent-dir=c:\tmp on my laptop.  When running on my devops 
environment based on Linux, I cannot use c:\tmp.  My other developers use there 
own locations.

2.) Our "system-test" module that runs the integration tests for the software 
we are building depends on a large commercial software package and runs our 
tests against 3 different versions of that package, requiring 2 different 
versions of java (depending on which version a particular test uses).  The 
other commercial software package is the Oracle database.  As such, the 
maven.config file current has the locations where the three versions of the 
commercial software package and 2 different JDK versions are installed.  

3.) The integration tests also depend on an Oracle database, where some 
developers use an installation on their laptop but Jenkins (and my release 
process) use a centrally installed database.  In order to make sure that 
developers (and Jenkins) don;t step on one another when they happen to run 
integration tests concurrently, the maven.config file contains the database 
connection information required by the test (e.g., connection URL, user name, 
and password).

4.) To make the integration tests work on both Windows and Linux, we ended up 
writing shell scripts that do the pre-integration-test setup and 
post-integration-test teardown of the environments required to run the 
commercial software package mentioned in step 2.  As such, the maven.config 
file also contains a property that tells the maven exec plugin executions the 
shell-script-extension to use for this particular build (i.e., cmd or sh).

What I was trying to say about the fred-system-test profile, etc. was that 
trying to push the environment-specific settings currently in maven.config into 
the profiles would mean that I would need to copy the existing profiles 
multiple times, one for each environment.  I see that as a non-starter.  I am 
not familiar enough with toolchains to know whether this would help me or not.  
My current thinking is that if I cannot use maven.config for these 
environment-specific configuration, I will be forced to drop back to 
environment variables--even though I see this as a more error-prone mechanism.

Is this real enough for you?  I am happy to show you all the detail but my 
employer might get upset if I posted the actual POMs and such to such a public 
forum...

Hope this helps,
Robert


> Maven 3.3.9 breaks release:perform by not including maven.config
> 
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.3.9
>Reporter: Robert Patrick
>Priority: Blocker
>
> Our release process runs both our build and our integration tests.  The 
> integration tests rely on our project root directory's .mvn/maven.config file 
> to run properly.  The maven.config file is NOT checked into the source tree 
> because it contains environment-specific values so each developer has their 
> own version of it on each machine on which they build.
> This has been working fine for months now but simply changing the version of 
> Maven used 

[jira] [Comment Edited] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15462892#comment-15462892
 ] 

Robert Patrick edited comment on MNG-6083 at 9/4/16 1:02 PM:
-

Karl, 

I already explained why I need different environments for different developers. 
 We are building real-world software that depends on commercial software 
packages.  I have four profiles defined in my top-level POM:

dev - this is the default profile that developers use to build and run unit 
tests on the software we are building
dev-install - this profile that builds our "installer", which is a zip file, 
and "installs" it in a directory that developers can use to run manual tests.
system-test - this profile is what runs our integration tests.  These tests 
depend on complex setup for a commercial software package.
release - this profile is the one used for running the Maven release process, 
that includes all modules.

We have two main Jenkins job types.  One build the software and runs the unit 
tests (using the default dev profile) and pushs the resulting SNAPSHOT JARs 
into Artifactory.  The other job runs nightly and runs our system-test profile 
to build our installer and run the integration tests against it, publishing the 
new installer to Artifactory if the integration tests succeed.  This installer 
can then be picked up by automated QA jobs that further test the quality of the 
nightly build. 

The current properties in maven.config are:

1.) The location of the "install directory" where the dev-install profile 
creates an installed version of the software.  For example, mine is currently 
set to -Da2c-home-parent-dir=c:\tmp on my laptop.  When running on my devops 
environment based on Linux, I cannot use c:\tmp.  My other developers use there 
own locations.

2.) Our "system-test" module that runs the integration tests for the software 
we are building depends on a large commercial software package and runs our 
tests against 3 different versions of that package, requiring 2 different 
versions of java (depending on which version a particular test uses).  The 
other commercial software package is the Oracle database.  As such, the 
maven.config file current has the locations where the three versions of the 
commercial software package and 2 different JDK versions are installed.  

3.) The integration tests also depend on an Oracle database, where some 
developers use an installation on their laptop but Jenkins (and my release 
process) use a centrally installed database.  In order to make sure that 
developers (and Jenkins) don't step on one another when they happen to run 
integration tests concurrently, the maven.config file contains the database 
connection information required by the test (e.g., connection URL, user name, 
and password).

4.) To make the integration tests work on both Windows and Linux, we ended up 
writing shell scripts that do the pre-integration-test setup and 
post-integration-test teardown of the environments required to run the 
commercial software package mentioned in step 2.  As such, the maven.config 
file also contains a property that tells the maven exec plugin executions the 
shell-script-extension to use for this particular build (i.e., cmd or sh).

What I was trying to say about the fred-system-test profile, etc. was that 
trying to push the environment-specific settings currently in maven.config into 
the profiles would mean that I would need to copy the existing profiles 
multiple times, one for each environment.  I see that as a non-starter.  I am 
not familiar enough with toolchains to know whether this would help me or not.  
My current thinking is that if I cannot use maven.config for these 
environment-specific configuration, I will be forced to drop back to 
environment variables--even though I see this as a more error-prone mechanism.

Is this real enough for you?  I am happy to show you all the detail but my 
employer might get upset if I posted the actual POMs and such to such a public 
forum...

Hope this helps,
Robert



was (Author: rhpatrick00):
Karl, 

I already explained why I need different environments for different developers. 
 We are building real-world software that depends on commercial software 
packages.  I have four profiles defined in my top-level POM:

dev - this is the default profile that developers use to build and run unit 
tests on the software we are building
dev-install - this profile that builds our "installer", which is a zip file, 
and "installs" it in a directory that developers can use to run manual tests.
system-test - this profile is what runs our integration tests.  These tests 
depend on complex setup for a commercial software package.
release - this profile is the one used for running the Maven release process, 
that includes all modules.

We have two main Jenkins job types.  One build the software and runs the un

[jira] [Comment Edited] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15462892#comment-15462892
 ] 

Robert Patrick edited comment on MNG-6083 at 9/4/16 1:03 PM:
-

Karl, 

I already explained why I need different environments for different developers. 
 We are building real-world software that depends on commercial software 
packages.  I have four profiles defined in my top-level POM:

dev - this is the default profile that developers use to build and run unit 
tests on the software we are building
dev-install - this profile that builds our "installer", which is a zip file, 
and "installs" it in a directory that developers can use to run manual tests.
system-test - this profile is what runs our integration tests.  These tests 
depend on complex setup for a commercial software package.
release - this profile is the one used for running the Maven release process, 
that includes all modules.

We have two main Jenkins job types.  One builds the software and runs the unit 
tests (using the default dev profile) and pushes the resulting SNAPSHOT JARs 
into Artifactory.  The other job runs nightly and runs our system-test profile 
to build our installer and run the integration tests against it, publishing the 
new installer to Artifactory if the integration tests succeed.  This installer 
can then be picked up by automated QA jobs that further test the quality of the 
nightly build. 

The current properties in maven.config are:

1.) The location of the "install directory" where the dev-install profile 
creates an installed version of the software.  For example, mine is currently 
set to -Da2c-home-parent-dir=c:\tmp on my laptop.  When running on my devops 
environment based on Linux, I cannot use c:\tmp.  My other developers use there 
own locations.

2.) Our "system-test" module that runs the integration tests for the software 
we are building depends on a large commercial software package and runs our 
tests against 3 different versions of that package, requiring 2 different 
versions of java (depending on which version a particular test uses).  The 
other commercial software package is the Oracle database.  As such, the 
maven.config file current has the locations where the three versions of the 
commercial software package and 2 different JDK versions are installed.  

3.) The integration tests also depend on an Oracle database, where some 
developers use an installation on their laptop but Jenkins (and my release 
process) use a centrally installed database.  In order to make sure that 
developers (and Jenkins) don't step on one another when they happen to run 
integration tests concurrently, the maven.config file contains the database 
connection information required by the test (e.g., connection URL, user name, 
and password).

4.) To make the integration tests work on both Windows and Linux, we ended up 
writing shell scripts that do the pre-integration-test setup and 
post-integration-test teardown of the environments required to run the 
commercial software package mentioned in step 2.  As such, the maven.config 
file also contains a property that tells the maven exec plugin executions the 
shell-script-extension to use for this particular build (i.e., cmd or sh).

What I was trying to say about the fred-system-test profile, etc. was that 
trying to push the environment-specific settings currently in maven.config into 
the profiles would mean that I would need to copy the existing profiles 
multiple times, one for each environment.  I see that as a non-starter.  I am 
not familiar enough with toolchains to know whether this would help me or not.  
My current thinking is that if I cannot use maven.config for these 
environment-specific configuration, I will be forced to drop back to 
environment variables--even though I see this as a more error-prone mechanism.

Is this real enough for you?  I am happy to show you all the detail but my 
employer might get upset if I posted the actual POMs and such to such a public 
forum...

Hope this helps,
Robert



was (Author: rhpatrick00):
Karl, 

I already explained why I need different environments for different developers. 
 We are building real-world software that depends on commercial software 
packages.  I have four profiles defined in my top-level POM:

dev - this is the default profile that developers use to build and run unit 
tests on the software we are building
dev-install - this profile that builds our "installer", which is a zip file, 
and "installs" it in a directory that developers can use to run manual tests.
system-test - this profile is what runs our integration tests.  These tests 
depend on complex setup for a commercial software package.
release - this profile is the one used for running the Maven release process, 
that includes all modules.

We have two main Jenkins job types.  One build the software and runs the 

[jira] [Comment Edited] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15462892#comment-15462892
 ] 

Robert Patrick edited comment on MNG-6083 at 9/4/16 1:07 PM:
-

Karl, 

I already explained why I need different environments for different developers. 
 We are building real-world software that depends on commercial software 
packages.  I have four profiles defined in my top-level POM:

dev - this is the default profile that developers use to build and run unit 
tests on the software we are building
dev-install - this profile that builds our "installer", which is a zip file, 
and "installs" it in a directory that developers can use to run manual tests.
system-test - this profile is what runs our integration tests.  These tests 
depend on complex setup for a commercial software package.
release - this profile is the one used for running the Maven release process, 
that includes all modules.

We have two main Jenkins job types.  One builds the software and runs the unit 
tests (using the default dev profile) and pushes the resulting SNAPSHOT JARs 
into Artifactory.  The other job runs nightly and runs our system-test profile 
to build our installer and run the integration tests against it, publishing the 
new installer to Artifactory if the integration tests succeed.  This installer 
can then be picked up by automated QA jobs that further test the quality of the 
nightly build. 

Our developers can also run the integration tests locally prior to checking in, 
if they choose.  I encourage this on large changes since I "fine" them every 
time they break a Jenkins nightly build job.

The current properties in maven.config are:

1.) The location of the "install directory" where the dev-install profile 
creates an installed version of the software.  For example, mine is currently 
set to -Da2c-home-parent-dir=c:\tmp on my laptop.  When running on my devops 
environment based on Linux, I cannot use c:\tmp.  My other developers use there 
own locations.

2.) Our "system-test" module that runs the integration tests for the software 
we are building depends on a large commercial software package and runs our 
tests against 3 different versions of that package, requiring 2 different 
versions of java (depending on which version a particular test uses).  The 
other commercial software package is the Oracle database.  As such, the 
maven.config file current has the locations where the three versions of the 
commercial software package and 2 different JDK versions are installed.  

3.) The integration tests also depend on an Oracle database, where some 
developers use an installation on their laptop but Jenkins (and my release 
process) use a centrally installed database.  In order to make sure that 
developers (and Jenkins) don't step on one another when they happen to run 
integration tests concurrently, the maven.config file contains the database 
connection information required by the test (e.g., connection URL, user name, 
and password).

4.) To make the integration tests work on both Windows and Linux, we ended up 
writing shell scripts that do the pre-integration-test setup and 
post-integration-test teardown of the environments required to run the 
commercial software package mentioned in step 2.  As such, the maven.config 
file also contains a property that tells the maven exec plugin executions the 
shell-script-extension to use for this particular build (i.e., cmd or sh).

What I was trying to say about the fred-system-test profile, etc. was that 
trying to push the environment-specific settings currently in maven.config into 
the profiles would mean that I would need to copy the existing profiles 
multiple times, one for each environment.  I see that as a non-starter.  I am 
not familiar enough with toolchains to know whether this would help me or not.  
My current thinking is that if I cannot use maven.config for these 
environment-specific configuration, I will be forced to drop back to 
environment variables--even though I see this as a more error-prone mechanism.

Is this real enough for you?  I am happy to show you all the detail but my 
employer might get upset if I posted the actual POMs and such to such a public 
forum...

Hope this helps,
Robert



was (Author: rhpatrick00):
Karl, 

I already explained why I need different environments for different developers. 
 We are building real-world software that depends on commercial software 
packages.  I have four profiles defined in my top-level POM:

dev - this is the default profile that developers use to build and run unit 
tests on the software we are building
dev-install - this profile that builds our "installer", which is a zip file, 
and "installs" it in a directory that developers can use to run manual tests.
system-test - this profile is what runs our integration tests.  These tests 
depend on complex setup for a comm

[jira] [Comment Edited] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15462892#comment-15462892
 ] 

Robert Patrick edited comment on MNG-6083 at 9/4/16 1:12 PM:
-

Karl, 

I already explained why I need different environments for different developers. 
 We are building real-world software that depends on commercial software 
packages.  I have four profiles defined in my top-level POM:

dev - this is the default profile that developers use to build and run unit 
tests on the software we are building
dev-install - this profile that builds our "installer", which is a zip file, 
and "installs" it in a directory that developers can use to run manual tests.
system-test - this profile is what runs our integration tests.  These tests 
depend on complex setup for a commercial software package.
release - this profile is the one used for running the Maven release process, 
which includes all modules.

We have two main Jenkins job types.  One builds the software and runs the unit 
tests (using the default dev profile) and pushes the resulting SNAPSHOT JARs 
into Artifactory.  The other job runs nightly and runs our system-test profile 
to build our installer and run the integration tests against it, publishing the 
new installer to Artifactory if the integration tests succeed.  This installer 
can then be picked up by automated QA jobs that further test the quality of the 
nightly build. 

Our developers can also run the integration tests locally prior to checking in, 
if they choose.  I encourage this on large changes since I "fine" them every 
time they break a Jenkins nightly build job.

The current properties in maven.config are:

1.) The location of the "install directory" where the dev-install profile 
creates an installed version of the software.  For example, mine is currently 
set to -Da2c-home-parent-dir=c:\tmp on my laptop.  When running on my devops 
environment based on Linux, I cannot use c:\tmp.  My other developers use there 
own locations.

2.) Our "system-test" module that runs the integration tests for the software 
we are building depends on a large commercial software package and runs our 
tests against 3 different versions of that package, requiring 2 different 
versions of java (depending on which version a particular test uses).  The 
other commercial software package is the Oracle database.  As such, the 
maven.config file current has the locations where the three versions of the 
commercial software package and 2 different JDK versions are installed.  

3.) The integration tests also depend on an Oracle database, where some 
developers use an installation on their laptop but Jenkins (and my release 
process) use a centrally installed database.  In order to make sure that 
developers (and Jenkins) don't step on one another when they happen to run 
integration tests concurrently, the maven.config file contains the database 
connection information required by the test (e.g., connection URL, user name, 
and password).

4.) To make the integration tests work on both Windows and Linux, we ended up 
writing shell scripts that do the pre-integration-test setup and 
post-integration-test teardown of the environments required to run the 
commercial software package mentioned in step 2.  As such, the maven.config 
file also contains a property that tells the maven exec plugin executions the 
shell-script-extension to use for this particular build (i.e., cmd or sh).

What I was trying to say about the fred-system-test profile, etc. was that 
trying to push the environment-specific settings currently in maven.config into 
the profiles would mean that I would need to copy the existing profiles 
multiple times, one for each environment.  I see that as a non-starter.  I am 
not familiar enough with toolchains to know whether this would help me or not.  
My current thinking is that if I cannot use maven.config for these 
environment-specific configuration, I will be forced to drop back to 
environment variables--even though I see this as a more error-prone mechanism.

Is this real enough for you?  I am happy to show you all the detail but my 
employer might get upset if I posted the actual POMs and such to such a public 
forum...

Hope this helps,
Robert



was (Author: rhpatrick00):
Karl, 

I already explained why I need different environments for different developers. 
 We are building real-world software that depends on commercial software 
packages.  I have four profiles defined in my top-level POM:

dev - this is the default profile that developers use to build and run unit 
tests on the software we are building
dev-install - this profile that builds our "installer", which is a zip file, 
and "installs" it in a directory that developers can use to run manual tests.
system-test - this profile is what runs our integration tests.  These tests 
depend on complex setup for a com

[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15463010#comment-15463010
 ] 

Robert Patrick commented on MNG-6083:
-

Karl,

Comments (mostly) in order...

1.) I only have a profile for it so that I can chain them actions together:

mvn clean install -Pdev,dev-install

or

mvn clean install -Pdev,system-test

The dev profile is active by default so yes, it could be removed at the expense 
of needing to run mvn twice to run it with one of the other profiles.

2.)  The dev-install profile runs our zipinstall and install-a2c-home 
modules--it does not include the core software modules built by the dev profile.

3.)  system-test uses the failsafe plugin so yes, it runs during the standard 
integration-test-related phases...

4.) I am not sure how your suggestion to move the removal of functionality down 
into the module POMs really helps.  It essentially just pushes the problem down 
a level at the expense of added complexity both in the POMs and for developers.

5.) Yes, we could move developer- and/or environment-specific information into 
settings.xml but that itself causes a problems.

- Typically, I like to keep project dependencies out of settings.xml because we 
work across multiple projects where the information might be conflicting.  I 
usually only define things that never change in my ~/.m2/settings.xml (e.g., 
mirrors, servers that require credentials and other such configuration).

- When putting project-specific settings in settings.xml without which the 
project will not build, I *believe* that the best practice is to put 
settings.xml under source control, typically inside the project source tree.  
In doing so, I end up with a similar problem to the one that I currently have 
with maven.config.  The only difference is that I can have as many 
settings-xxx.xml files in my source tree as I want--I just have to make sure 
that the developers (and IDEs) make sure to always add -s 
relative/path/ro/settings-rpatrick-laptop.xml to the mvn command-line.  This is 
a pain because I, for one, get distracted sometimes and forget.

5.) I will take a look at toolchain.xml to see if this will help.  

6.) Profiles for OSes don't help when the settings vary across environment.  
They also likely clash with our current use of profiles to segment the build.  
I could, for example, move system-test outside the main project into an 
integration-test project.  The problem with that is the added complexity of 
figuring out how to retain control all of the dependency, plugin, etc. 
management in a single location.  I have learned the hard way that parent POMs 
that are not the top-level aggregate POM for the project are problematic for 
things like the release plugin...

I think your suggestions are glossing over the complexities of managing 
numerous Maven projects across a real-world development organization.  At any 
point in time, I am working across a dozen or more projects and while you offer 
solutions like "push environment-specific settings into ~/.m2/settings.xml", 
you don't offer solutions for dealing with the complexities of managing 
multiple ~/.m2/settings.xml files that contain project-specific information 
(i.e., remembering to copy the right file to settings.xml and/or use 
remembering to use the right -s for each build).

Clearly, maven.config was made for Maven command-line properties.  This 
discussion seems to be about why Maven breaking compatibility between 3.3.3 and 
3.3.9 is ok because what I am doing is wrong and I need to do things in the way 
you are suggesting so that I do not care about Maven breaking compatibility 
across releases.  I wish my customers would accept this as an argument.  
Unfortunately, customers tend to use features in ways that you never expect and 
breaking compatibility for those features is a problem for customers. :-)

Unfortunately, the way you are suggesting seems to introduce other problems 
that:

- don't work well in real-world  development environments where at any point in 
time, developers are working on any number of projects, and
- most open-source projects using Maven (that I have looked at) avoid by not 
following some of your suggestions.  

Thanks,
Robert


> Maven 3.3.9 breaks release:perform by not including maven.config
> 
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.3.9
>Reporter: Robert Patrick
>Priority: Blocker
>
> Our release process runs both our build and our integration tests.  The 
> integration tests rely on our project root directory's .mvn/maven.config file 
> to run properly.  The maven.config file is NOT checked into the source tree 
> because it c

[jira] [Comment Edited] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15463010#comment-15463010
 ] 

Robert Patrick edited comment on MNG-6083 at 9/4/16 2:30 PM:
-

Karl,

Comments (mostly) in order...

1.) I only have a profile for it so that I can chain them actions together:

mvn clean install -Pdev,dev-install

or

mvn clean install -Pdev,system-test

The dev profile is active by default so yes, it could be removed at the expense 
of needing to run mvn twice to run it with one of the other profiles.

2.)  The dev-install profile runs our zipinstall and install-a2c-home 
modules--it does not include the core software modules built by the dev profile.

3.)  system-test uses the failsafe plugin so yes, it runs during the standard 
integration-test-related phases...

4.) I am not sure how your suggestion to move the removal of functionality down 
into the module POMs really helps.  It essentially just pushes the problem down 
a level at the expense of added complexity both in the POMs and for developers.

5.) Yes, we could move developer- and/or environment-specific information into 
settings.xml but that itself causes a problems.

- Typically, I like to keep project dependencies out of settings.xml because we 
work across multiple projects where the information might be conflicting.  I 
usually only define things that never change in my ~/.m2/settings.xml (e.g., 
mirrors, servers that require credentials and other such configuration).

- When putting project-specific settings in settings.xml without which the 
project will not build, I *believe* that the best practice is to put 
settings.xml under source control, typically inside the project source tree.  
In doing so, I end up with a similar problem to the one that I currently have 
with maven.config.  The only difference is that I can have as many 
settings-xxx.xml files in my source tree as I want--I just have to make sure 
that the developers (and IDEs) make sure to always add -s 
relative/path/ro/settings-rpatrick-laptop.xml to the mvn command-line.  This is 
a pain because I, for one, get distracted sometimes and forget.

5.) I will take a look at toolchain.xml to see if this will help.  

6.) Profiles for OSes don't help when the settings vary across environments.  
They also likely clash with our current use of profiles to segment the build.  
I could, for example, move system-test outside the main project into an 
integration-test project.  The problem with that is the added complexity of 
figuring out how to retain control all of the dependency, plugin, etc. 
management in a single location.  I have learned the hard way that parent POMs 
that are not the top-level aggregate POM for the project are problematic for 
things like the release plugin...

I think your suggestions are glossing over the complexities of managing 
numerous Maven projects across a real-world development organization.  At any 
point in time, I am working across a dozen or more projects and while you offer 
solutions like "push environment-specific settings into ~/.m2/settings.xml", 
you don't offer solutions for dealing with the complexities of managing 
multiple ~/.m2/settings.xml files that contain project-specific information 
(i.e., remembering to copy the right file to settings.xml and/or use 
remembering to use the right -s for each build).

Clearly, maven.config was made for Maven command-line properties.  This 
discussion seems to be about why Maven breaking compatibility between 3.3.3 and 
3.3.9 is ok because what I am doing is wrong and I need to do things in the way 
you are suggesting so that I do not care about Maven breaking compatibility 
across releases.  I wish my customers would accept this as an argument.  
Unfortunately, customers tend to use features in ways that you never expect and 
breaking compatibility for those features is a problem for customers. :-)

Unfortunately, the way you are suggesting seems to introduce other problems 
that:

- don't work well in real-world  development environments where at any point in 
time, developers are working on any number of projects, and
- most open-source projects using Maven (that I have looked at) avoid by not 
following some of your suggestions.  

Thanks,
Robert



was (Author: rhpatrick00):
Karl,

Comments (mostly) in order...

1.) I only have a profile for it so that I can chain them actions together:

mvn clean install -Pdev,dev-install

or

mvn clean install -Pdev,system-test

The dev profile is active by default so yes, it could be removed at the expense 
of needing to run mvn twice to run it with one of the other profiles.

2.)  The dev-install profile runs our zipinstall and install-a2c-home 
modules--it does not include the core software modules built by the dev profile.

3.)  system-test uses the failsafe plugin so yes, it runs during the standard 
integration-test-rela

[jira] [Comment Edited] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15463010#comment-15463010
 ] 

Robert Patrick edited comment on MNG-6083 at 9/4/16 2:41 PM:
-

Karl,

Comments (mostly) in order...

1.) I only have a profile for it so that I can chain them together:

mvn clean install -Pdev,dev-install

or

mvn clean install -Pdev,system-test

The dev profile is active by default so yes, it could be removed at the expense 
of needing to run mvn twice to run it with one of the other profiles.

2.)  The dev-install profile runs our zipinstall and install-a2c-home 
modules--it does not include the core software modules built by the dev profile.

3.)  system-test uses the failsafe plugin so yes, it runs during the standard 
integration-test-related phases...

4.) I am not sure how your suggestion to move the removal of functionality down 
into the module POMs really helps.  It essentially just pushes the problem down 
a level at the expense of added complexity both in the POMs and for developers.

5.) Yes, we could move developer- and/or environment-specific information into 
settings.xml but that itself causes a problems.

- Typically, I like to keep project dependencies out of settings.xml because we 
work across multiple projects where the information might be conflicting.  I 
usually only define things that never change in my ~/.m2/settings.xml (e.g., 
mirrors, servers that require credentials and other such configuration).

- When putting project-specific settings in settings.xml without which the 
project will not build, I *believe* that the best practice is to put 
settings.xml under source control, typically inside the project source tree.  
In doing so, I end up with a similar problem to the one that I currently have 
with maven.config.  The only difference is that I can have as many 
settings-xxx.xml files in my source tree as I want--I just have to make sure 
that the developers (and IDEs) make sure to always add -s 
relative/path/ro/settings-rpatrick-laptop.xml to the mvn command-line.  This is 
a pain because I, for one, get distracted sometimes and forget.

5.) I will take a look at toolchain.xml to see if this will help.  

6.) Profiles for OSes don't help when the settings vary across environments.  
They also likely clash with our current use of profiles to segment the build.  
I could, for example, move system-test outside the main project into an 
integration-test project.  The problem with that is the added complexity of 
figuring out how to retain control all of the dependency, plugin, etc. 
management in a single location.  I have learned the hard way that parent POMs 
that are not the top-level aggregate POM for the project are problematic for 
things like the release plugin...

I think your suggestions are glossing over the complexities of managing 
numerous Maven projects across a real-world development organization.  At any 
point in time, I am working across a dozen or more projects and while you offer 
solutions like "push environment-specific settings into ~/.m2/settings.xml", 
you don't offer solutions for dealing with the complexities of managing 
multiple ~/.m2/settings.xml files that contain project-specific information 
(i.e., remembering to copy the right file to settings.xml and/or use 
remembering to use the right -s for each build).

Clearly, maven.config was made for Maven command-line properties.  This 
discussion seems to be about why Maven breaking compatibility between 3.3.3 and 
3.3.9 is ok because what I am doing is wrong and I need to do things in the way 
you are suggesting so that I do not care about Maven breaking compatibility 
across releases.  I wish my customers would accept this as an argument.  
Unfortunately, customers tend to use features in ways that you never expect and 
breaking compatibility for those features is a problem for customers. :-)

Unfortunately, the way you are suggesting seems to introduce other problems 
that:

- don't work well in real-world  development environments where at any point in 
time, developers are working on any number of projects, and
- most open-source projects using Maven (that I have looked at) avoid by not 
following some of your suggestions.  

Thanks,
Robert



was (Author: rhpatrick00):
Karl,

Comments (mostly) in order...

1.) I only have a profile for it so that I can chain them actions together:

mvn clean install -Pdev,dev-install

or

mvn clean install -Pdev,system-test

The dev profile is active by default so yes, it could be removed at the expense 
of needing to run mvn twice to run it with one of the other profiles.

2.)  The dev-install profile runs our zipinstall and install-a2c-home 
modules--it does not include the core software modules built by the dev profile.

3.)  system-test uses the failsafe plugin so yes, it runs during the standard 
integration-test-related phas

[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15463053#comment-15463053
 ] 

Robert Patrick commented on MNG-6083:
-

>From my quick scan of the toolchains documentation, it will not help us.  It 
>seems that the definitions in toolchain.xml are really only exposed to plugins 
>that leverage them.  In our case, I need to invoke an external process (via 
>shell script) and pass it arguments to these environment-specific locations.  
>I don't see any documentation on how I can reference values defined in 
>toolchain.xml at any point in my POM.  For example, here is a greatly 
>simplified example of a Maven exec plugin execution from the POM that doe the 
>pre-integration-test setup for each test execution:


  org.codehaus.mojo
  exec-maven-plugin
  

  setup-environments-for-tests
  pre-integration-test
  
exec
  
  
${bash-executable}

  
${system-test-bin}/setupTestEnvironment.sh
  
${software.location.v1}
  
${software.location.v2}
  
${software.location.v3}
  ${path-to-java7}
  ${path-to-java8}
  
${script-to-call}

  

...
  


How would I reference those tools locations when they are defined in 
toolchain.xml?  I didn't see anything in the docs that covered such a use 
case...

> Maven 3.3.9 breaks release:perform by not including maven.config
> 
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.3.9
>Reporter: Robert Patrick
>Priority: Blocker
>
> Our release process runs both our build and our integration tests.  The 
> integration tests rely on our project root directory's .mvn/maven.config file 
> to run properly.  The maven.config file is NOT checked into the source tree 
> because it contains environment-specific values so each developer has their 
> own version of it on each machine on which they build.
> This has been working fine for months now but simply changing the version of 
> Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having 
> the -Ds defined in $PROJECT_ROOT/.mvn/maven.config.
> It appears that the release:perform goal checks out the release source in 
> another location and with Maven 3.3.9, the maven.config from the original 
> location is not being used.  The build specifies the release-plugin version 
> so the difference seems to be in the core Maven distribution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15463053#comment-15463053
 ] 

Robert Patrick edited comment on MNG-6083 at 9/4/16 3:07 PM:
-

>From my quick scan of the toolchains documentation, it will not help us.  It 
>seems that the definitions in toolchain.xml are really only exposed to plugins 
>that leverage them.  In our case, I need to invoke an external process (via 
>shell script) and pass it arguments to these environment-specific locations.  
>I don't see any documentation on how I can reference values defined in 
>toolchain.xml at any point in my POM.  For example, here is a greatly 
>simplified example of a Maven exec plugin execution from the POM that doe the 
>pre-integration-test setup for each test execution:



  org.codehaus.mojo
  exec-maven-plugin
  

  setup-environments-for-tests
  pre-integration-test
  
exec
  
  
${bash-executable}

  
${system-test-bin}/setupTestEnvironment.sh
  
${software.location.v1}
  
${software.location.v2}
  
${software.location.v3}
  ${path-to-java7}
  ${path-to-java8}
  
${script-to-call}

  

...
  



How would I reference those tools locations when they are defined in 
toolchain.xml?  I didn't see anything in the docs that covered such a use 
case...


was (Author: rhpatrick00):
>From my quick scan of the toolchains documentation, it will not help us.  It 
>seems that the definitions in toolchain.xml are really only exposed to plugins 
>that leverage them.  In our case, I need to invoke an external process (via 
>shell script) and pass it arguments to these environment-specific locations.  
>I don't see any documentation on how I can reference values defined in 
>toolchain.xml at any point in my POM.  For example, here is a greatly 
>simplified example of a Maven exec plugin execution from the POM that doe the 
>pre-integration-test setup for each test execution:


  org.codehaus.mojo
  exec-maven-plugin
  

  setup-environments-for-tests
  pre-integration-test
  
exec
  
  
${bash-executable}

  
${system-test-bin}/setupTestEnvironment.sh
  
${software.location.v1}
  
${software.location.v2}
  
${software.location.v3}
  ${path-to-java7}
  ${path-to-java8}
  
${script-to-call}

  

...
  


How would I reference those tools locations when they are defined in 
toolchain.xml?  I didn't see anything in the docs that covered such a use 
case...

> Maven 3.3.9 breaks release:perform by not including maven.config
> 
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.3.9
>Reporter: Robert Patrick
>Priority: Blocker
>
> Our release process runs both our build and our integration tests.  The 
> integration tests rely on our project root directory's .mvn/maven.config file 
> to run properly.  The maven.config file is NOT checked into the source tree 
> because it contains environment-specific values so each developer has their 
> own version of it on each machine on which they build.
> This has been working fine for months now but simply changing the version of 
> Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having 
> the -Ds defined in $PROJECT_ROOT/.mvn/maven.config.
> It appears that the release:perform goal checks out the release source in 
> another location and with Maven 3.3

[jira] [Comment Edited] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15463053#comment-15463053
 ] 

Robert Patrick edited comment on MNG-6083 at 9/4/16 3:08 PM:
-

>From my quick scan of the toolchains documentation, it will not help us.  It 
>seems that the definitions in toolchain.xml are really only exposed to plugins 
>that leverage them.  In our case, I need to invoke an external process (via 
>shell script) and pass it arguments to these environment-specific locations.  
>I don't see any documentation on how I can reference values defined in 
>toolchain.xml at any point in my POM.  For example, here is a greatly 
>simplified example of a Maven exec plugin execution from the POM that doe the 
>pre-integration-test setup for each test execution:



  org.codehaus.mojo
  exec-maven-plugin
  

  setup-environments-for-tests
  pre-integration-test
  
exec
  
  
${bash-executable}

  
${system-test-bin}/setupTestEnvironment.sh
  
${software.location.v1}
  
${software.location.v2}
  
${software.location.v3}
  ${path-to-java7}
  ${path-to-java8}
  
${script-to-call}

  

...
  


How would I reference those tools locations when they are defined in 
toolchain.xml?  I didn't see anything in the docs that covered such a use 
case...


was (Author: rhpatrick00):
>From my quick scan of the toolchains documentation, it will not help us.  It 
>seems that the definitions in toolchain.xml are really only exposed to plugins 
>that leverage them.  In our case, I need to invoke an external process (via 
>shell script) and pass it arguments to these environment-specific locations.  
>I don't see any documentation on how I can reference values defined in 
>toolchain.xml at any point in my POM.  For example, here is a greatly 
>simplified example of a Maven exec plugin execution from the POM that doe the 
>pre-integration-test setup for each test execution:



  org.codehaus.mojo
  exec-maven-plugin
  

  setup-environments-for-tests
  pre-integration-test
  
exec
  
  
${bash-executable}

  
${system-test-bin}/setupTestEnvironment.sh
  
${software.location.v1}
  
${software.location.v2}
  
${software.location.v3}
  ${path-to-java7}
  ${path-to-java8}
  
${script-to-call}

  

...
  



How would I reference those tools locations when they are defined in 
toolchain.xml?  I didn't see anything in the docs that covered such a use 
case...

> Maven 3.3.9 breaks release:perform by not including maven.config
> 
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.3.9
>Reporter: Robert Patrick
>Priority: Blocker
>
> Our release process runs both our build and our integration tests.  The 
> integration tests rely on our project root directory's .mvn/maven.config file 
> to run properly.  The maven.config file is NOT checked into the source tree 
> because it contains environment-specific values so each developer has their 
> own version of it on each machine on which they build.
> This has been working fine for months now but simply changing the version of 
> Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having 
> the -Ds defined in $PROJECT_ROOT/.mvn/maven.config.
> It appears that the release:perform goal checks out the release source in 
> another location and with Maven 3.

[jira] [Comment Edited] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15463053#comment-15463053
 ] 

Robert Patrick edited comment on MNG-6083 at 9/4/16 3:13 PM:
-

>From my quick scan of the toolchains documentation, it will not help us.  It 
>seems that the definitions in toolchain.xml are really only exposed to plugins 
>that leverage them.  In our case, I need to invoke an external process (via 
>shell script) and pass it arguments to these environment-specific locations.  
>I don't see any documentation on how I can reference values defined in 
>toolchain.xml at any point in my POM.  For example, here is a greatly 
>simplified example of a Maven exec plugin execution from the POM that doe the 
>pre-integration-test setup for each test execution:


  org.codehaus.mojo
  exec-maven-plugin
  

  setup-environments-for-tests
  pre-integration-test
  
exec
  
  
${bash-executable}

  ${system-test-bin}/setupTestEnvironment.sh
  ${software.location.v1}
  ${software.location.v2}
  ${software.location.v3}
  ${path-to-java7}
  ${path-to-java8}
  ${script-to-call}

  

...
  


How would I reference those tools locations when they are defined in 
toolchain.xml?  I didn't see anything in the docs that covered such a use 
case...


was (Author: rhpatrick00):
>From my quick scan of the toolchains documentation, it will not help us.  It 
>seems that the definitions in toolchain.xml are really only exposed to plugins 
>that leverage them.  In our case, I need to invoke an external process (via 
>shell script) and pass it arguments to these environment-specific locations.  
>I don't see any documentation on how I can reference values defined in 
>toolchain.xml at any point in my POM.  For example, here is a greatly 
>simplified example of a Maven exec plugin execution from the POM that doe the 
>pre-integration-test setup for each test execution:



  org.codehaus.mojo
  exec-maven-plugin
  

  setup-environments-for-tests
  pre-integration-test
  
exec
  
  
${bash-executable}

  
${system-test-bin}/setupTestEnvironment.sh
  
${software.location.v1}
  
${software.location.v2}
  
${software.location.v3}
  ${path-to-java7}
  ${path-to-java8}
  
${script-to-call}

  

...
  


How would I reference those tools locations when they are defined in 
toolchain.xml?  I didn't see anything in the docs that covered such a use 
case...

> Maven 3.3.9 breaks release:perform by not including maven.config
> 
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.3.9
>Reporter: Robert Patrick
>Priority: Blocker
>
> Our release process runs both our build and our integration tests.  The 
> integration tests rely on our project root directory's .mvn/maven.config file 
> to run properly.  The maven.config file is NOT checked into the source tree 
> because it contains environment-specific values so each developer has their 
> own version of it on each machine on which they build.
> This has been working fine for months now but simply changing the version of 
> Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having 
> the -Ds defined in $PROJECT_ROOT/.mvn/maven.config.
> It appears that the release:perform goal checks out the release source in 
> another location and with Maven 3.3.9, th

[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15463097#comment-15463097
 ] 

Robert Patrick commented on MNG-6083:
-

I understood how to set up the toolchain plugin and configure the exec plugin 
to use it.  

The issue with this page is that the details of what I need are omitted and 
replaced with "..." in the exec plugin declaration.  How do I reference a tool 
path defined in the toolchain.xml in a exec plugin execution?  For example, how 
do I fill in the  element used in the argument 
to the shell script that the exec plugin execution calls?



> Maven 3.3.9 breaks release:perform by not including maven.config
> 
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.3.9
>Reporter: Robert Patrick
>Priority: Blocker
>
> Our release process runs both our build and our integration tests.  The 
> integration tests rely on our project root directory's .mvn/maven.config file 
> to run properly.  The maven.config file is NOT checked into the source tree 
> because it contains environment-specific values so each developer has their 
> own version of it on each machine on which they build.
> This has been working fine for months now but simply changing the version of 
> Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having 
> the -Ds defined in $PROJECT_ROOT/.mvn/maven.config.
> It appears that the release:perform goal checks out the release source in 
> another location and with Maven 3.3.9, the maven.config from the original 
> location is not being used.  The build specifies the release-plugin version 
> so the difference seems to be in the core Maven distribution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15463231#comment-15463231
 ] 

Robert Patrick edited comment on MNG-6083 at 9/4/16 5:31 PM:
-

In playing with the paths toolchain, I see how I can specify a location for my 
shell scripts with it (this eliminates one of about a dozen variables I need 
for my system-test.  However, I cannot figure out how to reference a variable 
defined in a toolset to pass as an argument to my executable.  I tried the 
normal ${xxx} but that doesn't work.  Without this, it seems that the only 
option is a custom toolchain *and* a custom plugin to process it (e.g., a 
plugin that reads the toolchain and adds properties to the build so that they 
can referenced in the pom).  While I am not afraid of writing plugins, I am 
concerned that I am missing something obvious.

For example, how do I make this work when the xxxv1-home is defined in the 
toolchain?

  

  
org.codehaus.mojo
exec-maven-plugin
1.5.0
true

  

  jcs-las-system-test

  


  
validate

  exec


  echoMessage.cmd
  
${xxxv1-home}
  

  

  

  





was (Author: rhpatrick00):
In playing with the paths toolchain, I see how I can specify a location for my 
shell scripts with it (this eliminates one of about a dozen variables I need 
for my system-test.  However, I cannot figure out how to reference a variable 
defined in a toolset to pass as an argument to my executable.  I tried the 
normal ${xxx} but that doesn't work.  Without this, it seems that the only 
option is a custom toolchain *and* a custom plugin to process it (e.g., a 
plugin that reads the toolchain and adds properties to the build so that they 
can referenced in the pom).  While I am not afraid of writing plugins, I am 
concerned that I am missing something obvious.

For example, how do I make this work when the xxxv1-home is defined in the 
toolchain?

(quote)
  

  
org.codehaus.mojo
exec-maven-plugin
1.5.0
true

  

  jcs-las-system-test

  


  
validate

  exec


  echoMessage.cmd
  
${xxxv1-home}
  

  

  

  
(quote)



> Maven 3.3.9 breaks release:perform by not including maven.config
> 
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.3.9
>Reporter: Robert Patrick
>Priority: Blocker
>
> Our release process runs both our build and our integration tests.  The 
> integration tests rely on our project root directory's .mvn/maven.config file 
> to run properly.  The maven.config file is NOT checked into the source tree 
> because it contains environment-specific values so each developer has their 
> own version of it on each machine on which they build.
> This has been working fine for months now but simply changing the version of 
> Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having 
> the -Ds defined in $PROJECT_ROOT/.mvn/maven.config.
> It appears that the release:perform goal checks out the release source in 
> another location and with Maven 3.3.9, the maven.config from the original 
> location is not being used.  The build specifies the release-plugin version 
> so the difference seems to be in the core Maven distribution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15463231#comment-15463231
 ] 

Robert Patrick commented on MNG-6083:
-

In playing with the paths toolchain, I see how I can specify a location for my 
shell scripts with it (this eliminates one of about a dozen variables I need 
for my system-test.  However, I cannot figure out how to reference a variable 
defined in a toolset to pass as an argument to my executable.  I tried the 
normal ${xxx} but that doesn't work.  Without this, it seems that the only 
option is a custom toolchain *and* a custom plugin to process it (e.g., a 
plugin that reads the toolchain and adds properties to the build so that they 
can referenced in the pom).  While I am not afraid of writing plugins, I am 
concerned that I am missing something obvious.

For example, how do I make this work when the xxxv1-home is defined in the 
toolchain?

(quote)
  

  
org.codehaus.mojo
exec-maven-plugin
1.5.0
true

  

  jcs-las-system-test

  


  
validate

  exec


  echoMessage.cmd
  
${xxxv1-home}
  

  

  

  
(quote)



> Maven 3.3.9 breaks release:perform by not including maven.config
> 
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.3.9
>Reporter: Robert Patrick
>Priority: Blocker
>
> Our release process runs both our build and our integration tests.  The 
> integration tests rely on our project root directory's .mvn/maven.config file 
> to run properly.  The maven.config file is NOT checked into the source tree 
> because it contains environment-specific values so each developer has their 
> own version of it on each machine on which they build.
> This has been working fine for months now but simply changing the version of 
> Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having 
> the -Ds defined in $PROJECT_ROOT/.mvn/maven.config.
> It appears that the release:perform goal checks out the release source in 
> another location and with Maven 3.3.9, the maven.config from the original 
> location is not being used.  The build specifies the release-plugin version 
> so the difference seems to be in the core Maven distribution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15463231#comment-15463231
 ] 

Robert Patrick edited comment on MNG-6083 at 9/4/16 5:32 PM:
-

In playing with the paths toolchain, I see how I can specify a location for my 
shell scripts with it (this eliminates one of about a dozen variables I need 
for my system-test).  However, I cannot figure out how to reference a variable 
defined in a toolset to pass as an argument to my executable.  I tried the 
normal ${xxx} but that doesn't work.  Without this, it seems that the only 
option is a custom toolchain *and* a custom plugin to process it (e.g., a 
plugin that reads the toolchain and adds properties to the build so that they 
can referenced in the pom).  While I am not afraid of writing plugins, I am 
concerned that I am missing something obvious.

For example, how do I make this work when the xxxv1-home is defined in the 
toolchain?

  

  
org.codehaus.mojo
exec-maven-plugin
1.5.0
true

  

  jcs-las-system-test

  


  
validate

  exec


  echoMessage.cmd
  
${xxxv1-home}
  

  

  

  





was (Author: rhpatrick00):
In playing with the paths toolchain, I see how I can specify a location for my 
shell scripts with it (this eliminates one of about a dozen variables I need 
for my system-test.  However, I cannot figure out how to reference a variable 
defined in a toolset to pass as an argument to my executable.  I tried the 
normal ${xxx} but that doesn't work.  Without this, it seems that the only 
option is a custom toolchain *and* a custom plugin to process it (e.g., a 
plugin that reads the toolchain and adds properties to the build so that they 
can referenced in the pom).  While I am not afraid of writing plugins, I am 
concerned that I am missing something obvious.

For example, how do I make this work when the xxxv1-home is defined in the 
toolchain?

  

  
org.codehaus.mojo
exec-maven-plugin
1.5.0
true

  

  jcs-las-system-test

  


  
validate

  exec


  echoMessage.cmd
  
${xxxv1-home}
  

  

  

  




> Maven 3.3.9 breaks release:perform by not including maven.config
> 
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.3.9
>Reporter: Robert Patrick
>Priority: Blocker
>
> Our release process runs both our build and our integration tests.  The 
> integration tests rely on our project root directory's .mvn/maven.config file 
> to run properly.  The maven.config file is NOT checked into the source tree 
> because it contains environment-specific values so each developer has their 
> own version of it on each machine on which they build.
> This has been working fine for months now but simply changing the version of 
> Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having 
> the -Ds defined in $PROJECT_ROOT/.mvn/maven.config.
> It appears that the release:perform goal checks out the release source in 
> another location and with Maven 3.3.9, the maven.config from the original 
> location is not being used.  The build specifies the release-plugin version 
> so the difference seems to be in the core Maven distribution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15466136#comment-15466136
 ] 

Robert Patrick commented on MNG-6083:
-

It seems that at least a few others have complained over the years about the 
lack of functionality for Maven toolchains.  As such, I have written a custom 
toolchain and plugin to make toolchains work the way I hoped that they would.  
Assuming I don't hit any snags, I will eliminate .mvn/maven.config from my 
build and leverage the new "properties" toolchain type.  In case you are 
interested, you can see what I have done at 
https://github.com/rpatrick00/properties-toolchain-plugin


> Maven 3.3.9 breaks release:perform by not including maven.config
> 
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.3.9
>Reporter: Robert Patrick
>Priority: Blocker
>
> Our release process runs both our build and our integration tests.  The 
> integration tests rely on our project root directory's .mvn/maven.config file 
> to run properly.  The maven.config file is NOT checked into the source tree 
> because it contains environment-specific values so each developer has their 
> own version of it on each machine on which they build.
> This has been working fine for months now but simply changing the version of 
> Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having 
> the -Ds defined in $PROJECT_ROOT/.mvn/maven.config.
> It appears that the release:perform goal checks out the release source in 
> another location and with Maven 3.3.9, the maven.config from the original 
> location is not being used.  The build specifies the release-plugin version 
> so the difference seems to be in the core Maven distribution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (MNG-5889) .mvn directory should be picked when using --file

[Robert Patrick (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Patrick updated MNG-5889:

Comment: was deleted

(was: Pretty simple to fix the shell script to find the --file argument, if 
present, and set the MAVEN_PROJECTBASEDIR accordingly:

(quote)
--- a/apache-maven/src/bin/mvn
+++ b/apache-maven/src/bin/mvn
@@ -121,7 +121,7 @@ fi
 # first directory with .mvn subdirectory is considered project base directory
 find_maven_basedir() {
 (
-  basedir="`pwd`"
+  basedir=`find_file_argument_basedir "$@"`
   wdir="`pwd`"
   while [ "$wdir" != '/' ] ; do
 if [ -d "$wdir"/.mvn ] ; then
@@ -134,6 +134,26 @@ find_maven_basedir() {
 )
 }

+find_file_argument_basedir() {
+(
+  basedir="`pwd`"
+
+  found_file_switch=0
+  for arg in "$@"; do
+if [ ${found_file_switch} -eq 1 ]; then
+  if [ -f ${arg} ]; then
:+basedir=$(dirname $(readlink -f "${arg}"))
+  fi
+  break
+fi
+if [ "$arg" == "-f" -o "$arg" == "--file" ]; then
+  found_file_switch=1
+fi
+  done
+  echo "${basedir}"
+)
+}
+
 # concatenates all lines of a file
 concat_lines() {
   if [ -f "$1" ]; then
@@ -141,7 +161,7 @@ concat_lines() {
   fi
 }

-MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-`find_maven_basedir`}"
+MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-`find_maven_basedir "$@"`}"
 MAVEN_OPTS="`concat_lines "$MAVEN_PROJECTBASEDIR/.mvn/jvm.config"` $MAVEN_OPTS"


 # For Cygwin, switch project base directory path to Windows format before
(quote) )

> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap & Build
>Affects Versions: 3.3.3
>Reporter: Daniel Spilker
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to 
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of 
> the POM selected by {{--file}} and then go through the parent directories.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5889) .mvn directory should be picked when using --file

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15466256#comment-15466256
 ] 

Robert Patrick commented on MNG-5889:
-

Pretty simple to fix the shell script to find the --file argument, if present, 
and set the MAVEN_PROJECTBASEDIR accordingly:

(quote)
--- a/apache-maven/src/bin/mvn
+++ b/apache-maven/src/bin/mvn
@@ -121,7 +121,7 @@ fi
 # first directory with .mvn subdirectory is considered project base directory
 find_maven_basedir() {
 (
-  basedir="`pwd`"
+  basedir=`find_file_argument_basedir "$@"`
   wdir="`pwd`"
   while [ "$wdir" != '/' ] ; do
 if [ -d "$wdir"/.mvn ] ; then
@@ -134,6 +134,26 @@ find_maven_basedir() {
 )
 }

+find_file_argument_basedir() {
+(
+  basedir="`pwd`"
+
+  found_file_switch=0
+  for arg in "$@"; do
+if [ ${found_file_switch} -eq 1 ]; then
+  if [ -f ${arg} ]; then
:+basedir=$(dirname $(readlink -f "${arg}"))
+  fi
+  break
+fi
+if [ "$arg" == "-f" -o "$arg" == "--file" ]; then
+  found_file_switch=1
+fi
+  done
+  echo "${basedir}"
+)
+}
+
 # concatenates all lines of a file
 concat_lines() {
   if [ -f "$1" ]; then
@@ -141,7 +161,7 @@ concat_lines() {
   fi
 }

-MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-`find_maven_basedir`}"
+MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-`find_maven_basedir "$@"`}"
 MAVEN_OPTS="`concat_lines "$MAVEN_PROJECTBASEDIR/.mvn/jvm.config"` $MAVEN_OPTS"


 # For Cygwin, switch project base directory path to Windows format before
(quote) 

> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap & Build
>Affects Versions: 3.3.3
>Reporter: Daniel Spilker
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to 
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of 
> the POM selected by {{--file}} and then go through the parent directories.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5889) .mvn directory should be picked when using --file

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15467554#comment-15467554
 ] 

Robert Patrick commented on MNG-5889:
-

This is easy enough to fix by scanning the command-line arguments in the shell 
script.  I have a fix working for the sh script...still fighting with Windows 
to get something equivalent working in the cmd script.

> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap & Build
>Affects Versions: 3.3.3
>Reporter: Daniel Spilker
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to 
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of 
> the POM selected by {{--file}} and then go through the parent directories.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5889) .mvn directory should be picked when using --file

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15468761#comment-15468761
 ] 

Robert Patrick commented on MNG-5889:
-

I have a fix for this bug working in both mvn and mvn.cmd if anyone is 
interested.  How should I submit it?

> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap & Build
>Affects Versions: 3.3.3
>Reporter: Daniel Spilker
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to 
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of 
> the POM selected by {{--file}} and then go through the parent directories.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (MNG-5889) .mvn directory should be picked when using --file

[Robert Patrick (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Patrick updated MNG-5889:

Comment: was deleted

(was: I have a fix for this bug working in both mvn and mvn.cmd if anyone is 
interested.  How should I submit it?)

> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap & Build
>Affects Versions: 3.3.3
>Reporter: Daniel Spilker
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to 
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of 
> the POM selected by {{--file}} and then go through the parent directories.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MGPG-58) Encrypted Passphrase in settings.xml fails

[Robert Patrick (JIRA)]

Robert Patrick created MGPG-58:
--

 Summary: Encrypted Passphrase in settings.xml fails 
 Key: MGPG-58
 URL: https://issues.apache.org/jira/browse/MGPG-58
 Project: Maven GPG Plugin
  Issue Type: Bug
Affects Versions: 1.6
Reporter: Robert Patrick


I have my Maven build set up to automatically sign my artifacts and have 
everything working perfectly when the settings.xml profile entry has the clear 
text passphrase.

If I use mvn --encrypt-password to generate an encrypted version of the 
passphrase and substitute it for my clear-text passphrase, the gpg plugin fails 
with:

gpg: no default secret key: Bad passphrase
gpg: signing failed: Bad passphrase

My profile looks like this:

  

  ossrh
  
true
  
  
gpg

{rDYNQ7KHyZYHJogTS2ppwiLCu+ZJjJ4uEhsG8tLsadw=}
  

  

Replacing the encrypted passphrase with the clear text one makes the build work 
again...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MGPG-58) Encrypted Passphrase in settings.xml fails

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MGPG-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473778#comment-15473778
 ] 

Robert Patrick commented on MGPG-58:


Same problem if I move the profile into my project POM

> Encrypted Passphrase in settings.xml fails 
> ---
>
> Key: MGPG-58
> URL: https://issues.apache.org/jira/browse/MGPG-58
> Project: Maven GPG Plugin
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Robert Patrick
>
> I have my Maven build set up to automatically sign my artifacts and have 
> everything working perfectly when the settings.xml profile entry has the 
> clear text passphrase.
> If I use mvn --encrypt-password to generate an encrypted version of the 
> passphrase and substitute it for my clear-text passphrase, the gpg plugin 
> fails with:
> gpg: no default secret key: Bad passphrase
> gpg: signing failed: Bad passphrase
> My profile looks like this:
>   
> 
>   ossrh
>   
> true
>   
>   
> gpg
> 
> {rDYNQ7KHyZYHJogTS2ppwiLCu+ZJjJ4uEhsG8tLsadw=}
>   
> 
>   
> Replacing the encrypted passphrase with the clear text one makes the build 
> work again...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MRELEASE-951) Release plugin ignores release.properties developmentVersion property

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15786168#comment-15786168
 ] 

Robert Patrick commented on MRELEASE-951:
-

and not in batch mode and specified in the release.properties file.

> Release plugin ignores release.properties developmentVersion property
> -
>
> Key: MRELEASE-951
> URL: https://issues.apache.org/jira/browse/MRELEASE-951
> Project: Maven Release Plugin
>  Issue Type: Bug
> Environment: maven-release-plugin 2.5.3
>Reporter: Robert Patrick
>
> I created my release.properties file with the following content:
> tag=myproject-2.0.0
> releaseVersion=2.0.0
> developmentVersion=2.1.0-SNAPSHOT
> and invoked the release plugin with:
> mvn --batch-mode release:prepare
> After running the maven-release-plugin, the POM version was set to 
> 2.0.1-SNAPSHOT even though I told it to set it to 2.1.0-SNAPSHOT.
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5889) .mvn directory should be picked when using --file

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16726990#comment-16726990
 ] 

Robert Patrick commented on MNG-5889:
-

The code to resolve properly locating the .mvn directory is definitely in 3.5.x 
and 3.6.0 (I just verified by looking at the shell scripts).  If you believe it 
isn't working with the --file option, try putting some garbage argument that 
the JVM doesn't recognize in root/.mvn/maven.config and run mvn 
--file=/path/to/root/pom.xml and see what happens.  I would expect the JVM to 
fail to start if this issue is resolved.  For example, I added the -Y option 
and mvn fails to start:

 
{quote}
D:\projects>type weblogic-deploy-tooling\.mvn\maven.config
-Dunit-test-wlst-dir=/u01/oracle/oracle_common/common/bin
-Y

D:\projects>mvn -v
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
2018-10-24T13:41:47-05:00)
Maven home: c:\java\apache-maven-3.6.0\bin\..
Java version: 1.8.0_191, vendor: Oracle Corporation, runtime: 
c:\java\jdk1.8.0\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

D:\projects>mvn --file=weblogic-deploy-tooling\pom.xml
Unable to parse maven.config: Unrecognized option: -Y

usage: mvn [options] [] []

{quote}


> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap & Build
>Affects Versions: 3.3.3, 3.3.9
>Reporter: Daniel Spilker
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.5.0-alpha-1, 3.5.0
>
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to 
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of 
> the POM selected by {{--file}} and then go through the parent directories.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MNG-5889) .mvn directory should be picked when using --file

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16726990#comment-16726990
 ] 

Robert Patrick edited comment on MNG-5889 at 12/21/18 7:16 PM:
---

The code to resolve properly locating the .mvn directory is definitely in 3.5.x 
and 3.6.0 (I just verified by looking at the shell scripts).  If you believe it 
isn't working with the --file option, try putting some garbage argument that 
Maven doesn't recognize in root/.mvn/maven.config and run mvn 
--file=/path/to/root/pom.xml and see what happens.  I would expect Maven to 
fail to start if this issue is resolved.  For example, I added the -Y option 
and mvn fails to start:

 
{quote}D:\projects>type weblogic-deploy-tooling\.mvn\maven.config
 -Dunit-test-wlst-dir=/u01/oracle/oracle_common/common/bin
 -Y

D:\projects>mvn -v
 Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
2018-10-24T13:41:47-05:00)
 Maven home: c:\java\apache-maven-3.6.0\bin\..
 Java version: 1.8.0_191, vendor: Oracle Corporation, runtime: 
c:\java\jdk1.8.0\jre
 Default locale: en_US, platform encoding: Cp1252
 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

D:\projects>mvn --file=weblogic-deploy-tooling\pom.xml
 Unable to parse maven.config: Unrecognized option: -Y

usage: mvn [options] [] []
 
{quote}


was (Author: rhpatrick00):
The code to resolve properly locating the .mvn directory is definitely in 3.5.x 
and 3.6.0 (I just verified by looking at the shell scripts).  If you believe it 
isn't working with the --file option, try putting some garbage argument that 
the JVM doesn't recognize in root/.mvn/maven.config and run mvn 
--file=/path/to/root/pom.xml and see what happens.  I would expect the JVM to 
fail to start if this issue is resolved.  For example, I added the -Y option 
and mvn fails to start:

 
{quote}
D:\projects>type weblogic-deploy-tooling\.mvn\maven.config
-Dunit-test-wlst-dir=/u01/oracle/oracle_common/common/bin
-Y

D:\projects>mvn -v
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
2018-10-24T13:41:47-05:00)
Maven home: c:\java\apache-maven-3.6.0\bin\..
Java version: 1.8.0_191, vendor: Oracle Corporation, runtime: 
c:\java\jdk1.8.0\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

D:\projects>mvn --file=weblogic-deploy-tooling\pom.xml
Unable to parse maven.config: Unrecognized option: -Y

usage: mvn [options] [] []

{quote}


> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap & Build
>Affects Versions: 3.3.3, 3.3.9
>Reporter: Daniel Spilker
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.5.0-alpha-1, 3.5.0
>
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to 
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of 
> the POM selected by {{--file}} and then go through the parent directories.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MNG-5889) .mvn directory should be picked when using --file

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16727045#comment-16727045
 ] 

Robert Patrick edited comment on MNG-5889 at 12/21/18 8:52 PM:
---

So to me, this says that your issue has nothing to do with this issue and is 
somehow related to your use of the revision property.

Out of curiosity, I tried modifying an old project I had lying around to use 
the the revision property and it seems to be working fine--even with the 
-Drevision=xxx defined in maven.config.  Here is what I have:

weblogic-deploy-tooling\pom.xml:
{quote}
com.oracle.weblogic.lifecycle
weblogic-deploy
${revision}
pom
{quote}

weblogic-deploy-tooling/core/pom.xml:
{quote}
weblogic-deploy-core


weblogic-deploy
com.oracle.weblogic.lifecycle
${revision}
../pom.xml

{quote}

weblogic-deploy-tooling\installer\pom.xml:
{quote}
weblogic-deploy-installer
pom


com.oracle.weblogic.lifecycle
weblogic-deploy
${revision}
../pom.xml




${project.groupId}
weblogic-deploy-core
${project.version}


{quote}

And here is what happens:

{quote}
D:\projects>type weblogic-deploy-tooling\.mvn\maven.config
-Dunit-test-wlst-dir=c:/wls12213/oracle_common/common/bin
-Drevision=0.15

D:\projects>mvn --file weblogic-deploy-tooling\pom.xml validate
[INFO] Scanning for projects...
[INFO] 
[INFO] Reactor Build Order:
[INFO]
[INFO] Oracle WebLogic Server Deploy Tooling  [pom]
[INFO] weblogic-deploy-core   [jar]
[INFO] weblogic-deploy-installer  [pom]
[INFO]
[INFO] ---< com.oracle.weblogic.lifecycle:weblogic-deploy >
[INFO] Building Oracle WebLogic Server Deploy Tooling 0.15[1/3]
[INFO] [ pom ]-
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (enforce-build-environment) @ 
weblogic-deploy ---
[INFO]
[INFO] -< com.oracle.weblogic.lifecycle:weblogic-deploy-core >-
[INFO] Building weblogic-deploy-core 0.15 [2/3]
[INFO] [ jar ]-
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (enforce-build-environment) @ 
weblogic-deploy-core ---
[INFO]
[INFO] --< com.oracle.weblogic.lifecycle:weblogic-deploy-installer >---
[INFO] Building weblogic-deploy-installer 0.15[3/3]
[INFO] [ pom ]-
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (enforce-build-environment) @ 
weblogic-deploy-installer ---
[INFO] 
[INFO] Reactor Summary for Oracle WebLogic Server Deploy Tooling 0.15:
[INFO]
[INFO] Oracle WebLogic Server Deploy Tooling .. SUCCESS [  0.477 s]
[INFO] weblogic-deploy-core ... SUCCESS [  0.122 s]
[INFO] weblogic-deploy-installer .. SUCCESS [  0.019 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time:  0.784 s
[INFO] Finished at: 2018-12-21T14:48:21-06:00
[INFO] 

D:\projects>
{quote}



was (Author: rhpatrick00):
So to me, this says that your issue has nothing to do with this issue and is 
somehow related to your use of the revision property.

Out of curiosity, I tried modifying an old project I had lying around to use 
the the revision property and it seems to be working fine--even with the 
-Drevision=xxx defined in maven.config.  Here is what I have:

weblogic-deploy-tooling\pom.xml:
{{
com.oracle.weblogic.lifecycle
weblogic-deploy
${revision}
pom
}}

weblogic-deploy-tooling/core/pom.xml:
{{
weblogic-deploy-core


weblogic-deploy
com.oracle.weblogic.lifecycle
${revision}
../pom.xml

}}

weblogic-deploy-tooling\installer\pom.xml:
{{
weblogic-deploy-installer
pom


com.oracle.weblogic.lifecycle
weblogic-deploy
${revision}
../pom.xml




${project.groupId}
weblogic-deploy-core
${project.version}


}}

And here is what happens:

{quote}
D:\projects>type weblogic-deploy-tooling\.mvn\maven.config
-Dunit-test-wlst-dir=c:/wls12213/oracle_common/common/bin
-Drevision=0.15

D:\projects>mvn --file weblogic-deploy-tooling\pom.xml validate
[INFO

[jira] [Comment Edited] (MNG-5889) .mvn directory should be picked when using --file

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16727045#comment-16727045
 ] 

Robert Patrick edited comment on MNG-5889 at 12/21/18 8:58 PM:
---

So to me, this says that your issue has nothing to do with this issue and is 
somehow related to your use of the revision property.

Out of curiosity, I tried modifying an old project I had lying around to use 
the the revision property and it seems to be working fine--even with the 
-Drevision=xxx defined in maven.config. Here is what I have:

weblogic-deploy-tooling\pom.xml:

{{com.oracle.weblogic.lifecycle}}
{{ weblogic-deploy}}
{{ ${revision}}}
{{ pom}}

weblogic-deploy-tooling/core/pom.xml:

{{weblogic-deploy-core}}
{{}}
{{    weblogic-deploy}}
{{    com.oracle.weblogic.lifecycle}}
{{    ${revision}}}
{{    ../pom.xml}}
{{ }}

weblogic-deploy-tooling\installer\pom.xml:

{{weblogic-deploy-installer}}
{{pom}}
{{    com.oracle.weblogic.lifecycle}}
{{    weblogic-deploy}}
{{    ${revision}}}
{{    ../pom.xml}}
{{}}
{{}}

{{}}
{{    }}
{{        ${project.groupId}}}
{{        weblogic-deploy-core}}
{{        ${project.version}}}
{{    }}
{{ }}

And here is what happens:
{quote}D:\projects>type weblogic-deploy-tooling\.mvn\maven.config
 -Dunit-test-wlst-dir=c:/wls12213/oracle_common/common/bin
 -Drevision=0.15

D:\projects>mvn --file weblogic-deploy-tooling\pom.xml validate
 [INFO] Scanning for projects...
 [INFO] 
 [INFO] Reactor Build Order:
 [INFO]
 [INFO] Oracle WebLogic Server Deploy Tooling [pom]
 [INFO] weblogic-deploy-core [jar]
 [INFO] weblogic-deploy-installer [pom]
 [INFO]
 [INFO] ---< com.oracle.weblogic.lifecycle:weblogic-deploy >
 [INFO] Building Oracle WebLogic Server Deploy Tooling 0.15 [1/3]
 [INFO] [ pom ]-
 [INFO]
 [INFO] — maven-enforcer-plugin:3.0.0-M1:enforce (enforce-build-environment) @ 
weblogic-deploy —
 [INFO]
 [INFO] -< com.oracle.weblogic.lifecycle:weblogic-deploy-core >-
 [INFO] Building weblogic-deploy-core 0.15 [2/3]
 [INFO] [ jar ]-
 [INFO]
 [INFO] — maven-enforcer-plugin:3.0.0-M1:enforce (enforce-build-environment) @ 
weblogic-deploy-core —
 [INFO]
 [INFO] --< com.oracle.weblogic.lifecycle:weblogic-deploy-installer >---
 [INFO] Building weblogic-deploy-installer 0.15 [3/3]
 [INFO] [ pom ]-
 [INFO]
 [INFO] — maven-enforcer-plugin:3.0.0-M1:enforce (enforce-build-environment) @ 
weblogic-deploy-installer —
 [INFO] 
 [INFO] Reactor Summary for Oracle WebLogic Server Deploy Tooling 0.15:
 [INFO]
 [INFO] Oracle WebLogic Server Deploy Tooling .. SUCCESS [ 0.477 s]
 [INFO] weblogic-deploy-core ... SUCCESS [ 0.122 s]
 [INFO] weblogic-deploy-installer .. SUCCESS [ 0.019 s]
 [INFO] 
 [INFO] BUILD SUCCESS
 [INFO] 
 [INFO] Total time: 0.784 s
 [INFO] Finished at: 2018-12-21T14:48:21-06:00
 [INFO] 

D:\projects>
{quote}


was (Author: rhpatrick00):
So to me, this says that your issue has nothing to do with this issue and is 
somehow related to your use of the revision property.

Out of curiosity, I tried modifying an old project I had lying around to use 
the the revision property and it seems to be working fine--even with the 
-Drevision=xxx defined in maven.config.  Here is what I have:

weblogic-deploy-tooling\pom.xml:
{quote}
com.oracle.weblogic.lifecycle
weblogic-deploy
${revision}
pom
{quote}

weblogic-deploy-tooling/core/pom.xml:
{quote}
weblogic-deploy-core


weblogic-deploy
com.oracle.weblogic.lifecycle
${revision}
../pom.xml

{quote}

weblogic-deploy-tooling\installer\pom.xml:
{quote}
weblogic-deploy-installer
pom


com.oracle.weblogic.lifecycle
weblogic-deploy
${revision}
../pom.xml




${project.groupId}
weblogic-deploy-core
${project.version}


{quote}

And here is what happens:

{quote}
D:\projects>type weblogic-deploy-tooling\.mvn\maven.config
-Dunit-test-wlst-dir=c:/wls12213/oracle_common/common/bin
-Drevision=0.15

D:\projects>mvn --file weblogic-deploy-tooling\pom.xml validate
[INFO] Scanning for projects...
[INFO] 
[INFO] Reactor Build Order:
[INFO]
[INFO] Oracle WebLogic Server Deploy Tool

[jira] [Commented] (MNG-5889) .mvn directory should be picked when using --file

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16727045#comment-16727045
 ] 

Robert Patrick commented on MNG-5889:
-

So to me, this says that your issue has nothing to do with this issue and is 
somehow related to your use of the revision property.

Out of curiosity, I tried modifying an old project I had lying around to use 
the the revision property and it seems to be working fine--even with the 
-Drevision=xxx defined in maven.config.  Here is what I have:

weblogic-deploy-tooling\pom.xml:
{{
com.oracle.weblogic.lifecycle
weblogic-deploy
${revision}
pom
}}

weblogic-deploy-tooling/core/pom.xml:
{{
weblogic-deploy-core


weblogic-deploy
com.oracle.weblogic.lifecycle
${revision}
../pom.xml

}}

weblogic-deploy-tooling\installer\pom.xml:
{{
weblogic-deploy-installer
pom


com.oracle.weblogic.lifecycle
weblogic-deploy
${revision}
../pom.xml




${project.groupId}
weblogic-deploy-core
${project.version}


}}

And here is what happens:

{quote}
D:\projects>type weblogic-deploy-tooling\.mvn\maven.config
-Dunit-test-wlst-dir=c:/wls12213/oracle_common/common/bin
-Drevision=0.15

D:\projects>mvn --file weblogic-deploy-tooling\pom.xml validate
[INFO] Scanning for projects...
[INFO] 
[INFO] Reactor Build Order:
[INFO]
[INFO] Oracle WebLogic Server Deploy Tooling  [pom]
[INFO] weblogic-deploy-core   [jar]
[INFO] weblogic-deploy-installer  [pom]
[INFO]
[INFO] ---< com.oracle.weblogic.lifecycle:weblogic-deploy >
[INFO] Building Oracle WebLogic Server Deploy Tooling 0.15[1/3]
[INFO] [ pom ]-
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (enforce-build-environment) @ 
weblogic-deploy ---
[INFO]
[INFO] -< com.oracle.weblogic.lifecycle:weblogic-deploy-core >-
[INFO] Building weblogic-deploy-core 0.15 [2/3]
[INFO] [ jar ]-
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (enforce-build-environment) @ 
weblogic-deploy-core ---
[INFO]
[INFO] --< com.oracle.weblogic.lifecycle:weblogic-deploy-installer >---
[INFO] Building weblogic-deploy-installer 0.15[3/3]
[INFO] [ pom ]-
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (enforce-build-environment) @ 
weblogic-deploy-installer ---
[INFO] 
[INFO] Reactor Summary for Oracle WebLogic Server Deploy Tooling 0.15:
[INFO]
[INFO] Oracle WebLogic Server Deploy Tooling .. SUCCESS [  0.477 s]
[INFO] weblogic-deploy-core ... SUCCESS [  0.122 s]
[INFO] weblogic-deploy-installer .. SUCCESS [  0.019 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time:  0.784 s
[INFO] Finished at: 2018-12-21T14:48:21-06:00
[INFO] 

D:\projects>
{quote}


> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap & Build
>Affects Versions: 3.3.3, 3.3.9
>Reporter: Daniel Spilker
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.5.0-alpha-1, 3.5.0
>
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to 
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of 
> the POM selected by {{--file}} and then go through the parent directories.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MNG-5889) .mvn directory should be picked when using --file

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16727045#comment-16727045
 ] 

Robert Patrick edited comment on MNG-5889 at 12/21/18 8:59 PM:
---

So to me, this says that your issue has nothing to do with this issue and is 
somehow related to your use of the revision property.

Out of curiosity, I tried modifying an old project I had lying around to use 
the the revision property and it seems to be working fine--even with the 
-Drevision=xxx defined in maven.config. Here is what I have:

weblogic-deploy-tooling\pom.xml:

{{com.oracle.weblogic.lifecycle}}
weblogic-deploy
${revision}
pom

weblogic-deploy-tooling/core/pom.xml:

{{weblogic-deploy-core}}
 {{}}
 {{    weblogic-deploy}}
 {{    com.oracle.weblogic.lifecycle}}
 {{    ${revision}}}
 {{    ../pom.xml}}


weblogic-deploy-tooling\installer\pom.xml:

{{weblogic-deploy-installer}}
 {{pom}}
 {{    com.oracle.weblogic.lifecycle}}
 {{    weblogic-deploy}}
 {{    ${revision}}}
 {{    ../pom.xml}}
 {{}}


{{}}
 {{    }}
 {{        ${project.groupId}}}
 {{        weblogic-deploy-core}}
 {{        ${project.version}}}
 {{    }}


And here is what happens:
{quote}D:\projects>type weblogic-deploy-tooling\.mvn\maven.config
 -Dunit-test-wlst-dir=c:/wls12213/oracle_common/common/bin
 -Drevision=0.15

D:\projects>mvn --file weblogic-deploy-tooling\pom.xml validate
 [INFO] Scanning for projects...
 [INFO] 
 [INFO] Reactor Build Order:
 [INFO]
 [INFO] Oracle WebLogic Server Deploy Tooling [pom]
 [INFO] weblogic-deploy-core [jar]
 [INFO] weblogic-deploy-installer [pom]
 [INFO]
 [INFO] ---< com.oracle.weblogic.lifecycle:weblogic-deploy >
 [INFO] Building Oracle WebLogic Server Deploy Tooling 0.15 [1/3]
 [INFO] [ pom ]-
 [INFO]
 [INFO] — maven-enforcer-plugin:3.0.0-M1:enforce (enforce-build-environment) @ 
weblogic-deploy —
 [INFO]
 [INFO] -< com.oracle.weblogic.lifecycle:weblogic-deploy-core >-
 [INFO] Building weblogic-deploy-core 0.15 [2/3]
 [INFO] [ jar ]-
 [INFO]
 [INFO] — maven-enforcer-plugin:3.0.0-M1:enforce (enforce-build-environment) @ 
weblogic-deploy-core —
 [INFO]
 [INFO] --< com.oracle.weblogic.lifecycle:weblogic-deploy-installer >---
 [INFO] Building weblogic-deploy-installer 0.15 [3/3]
 [INFO] [ pom ]-
 [INFO]
 [INFO] — maven-enforcer-plugin:3.0.0-M1:enforce (enforce-build-environment) @ 
weblogic-deploy-installer —
 [INFO] 
 [INFO] Reactor Summary for Oracle WebLogic Server Deploy Tooling 0.15:
 [INFO]
 [INFO] Oracle WebLogic Server Deploy Tooling .. SUCCESS [ 0.477 s]
 [INFO] weblogic-deploy-core ... SUCCESS [ 0.122 s]
 [INFO] weblogic-deploy-installer .. SUCCESS [ 0.019 s]
 [INFO] 
 [INFO] BUILD SUCCESS
 [INFO] 
 [INFO] Total time: 0.784 s
 [INFO] Finished at: 2018-12-21T14:48:21-06:00
 [INFO] 

D:\projects>
{quote}


was (Author: rhpatrick00):
So to me, this says that your issue has nothing to do with this issue and is 
somehow related to your use of the revision property.

Out of curiosity, I tried modifying an old project I had lying around to use 
the the revision property and it seems to be working fine--even with the 
-Drevision=xxx defined in maven.config. Here is what I have:

weblogic-deploy-tooling\pom.xml:

{{com.oracle.weblogic.lifecycle}}
{{ weblogic-deploy}}
{{ ${revision}}}
{{ pom}}

weblogic-deploy-tooling/core/pom.xml:

{{weblogic-deploy-core}}
{{}}
{{    weblogic-deploy}}
{{    com.oracle.weblogic.lifecycle}}
{{    ${revision}}}
{{    ../pom.xml}}
{{ }}

weblogic-deploy-tooling\installer\pom.xml:

{{weblogic-deploy-installer}}
{{pom}}
{{    com.oracle.weblogic.lifecycle}}
{{    weblogic-deploy}}
{{    ${revision}}}
{{    ../pom.xml}}
{{}}
{{}}

{{}}
{{    }}
{{        ${project.groupId}}}
{{        weblogic-deploy-core}}
{{        ${project.version}}}
{{    }}
{{ }}

And here is what happens:
{quote}D:\projects>type weblogic-deploy-tooling\.mvn\maven.config
 -Dunit-test-wlst-dir=c:/wls12213/oracle_common/common/bin
 -Drevision=0.15

D:\projects>mvn --file weblogic-deploy-tooling\pom.xml validate
 [INFO] Scanning for projects...
 [INFO] 
 [INFO] Reactor Build Order:
 [INFO]
 [INFO] Oracle WebLogic Server Deploy Tooling [pom]
 [INFO] weblogic-deploy-core [jar]
 [INFO

[jira] [Comment Edited] (MNG-5889) .mvn directory should be picked when using --file

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16727058#comment-16727058
 ] 

Robert Patrick edited comment on MNG-5889 at 12/21/18 9:06 PM:
---

I am confused as to what problem you are trying to address.  Clearly, MNG-5889 
is resolved because mvn is able to find the .mvn directory when using the 
--file arg.  Perhaps you should open a separate defect with the details of your 
problem (make sure to tag me since I don't actively monitor Maven defects). 


was (Author: rhpatrick00):
I am confused as to what problem you are trying to address.  Clearly, MNG-5889 
is resolved because mvn is able to find the .mvn directory when using the 
--file arg.  Perhaps you should open a separate defect with the details of your 
problem (make sure to take me since I don't actively monitor Maven defects). 

> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap & Build
>Affects Versions: 3.3.3, 3.3.9
>Reporter: Daniel Spilker
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.5.0-alpha-1, 3.5.0
>
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to 
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of 
> the POM selected by {{--file}} and then go through the parent directories.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-5889) .mvn directory should be picked when using --file

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16727058#comment-16727058
 ] 

Robert Patrick commented on MNG-5889:
-

I am confused as to what problem you are trying to address.  Clearly, MNG-5889 
is resolved because mvn is able to find the .mvn directory when using the 
--file arg.  Perhaps you should open a separate defect with the details of your 
problem (make sure to take me since I don't actively monitor Maven defects). 

> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap & Build
>Affects Versions: 3.3.3, 3.3.9
>Reporter: Daniel Spilker
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.5.0-alpha-1, 3.5.0
>
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to 
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of 
> the POM selected by {{--file}} and then go through the parent directories.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-5889) .mvn directory should be picked when using --file

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16727066#comment-16727066
 ] 

Robert Patrick commented on MNG-5889:
-

[~jason.yo...@procentive.com]
 * 3.6.0
 * The revision property is only defined in the POMs where I showed it in the 
example and in .mvn/maven-config.  When I run the build, I see my build JAR and 
ZIP artifact file names foillow the xxx-0.15. naming pattern, as 
expected.  If I change the revision to 0.16, I see the file names change to 
xxx-0.15., as expected. 

> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap & Build
>Affects Versions: 3.3.3, 3.3.9
>Reporter: Daniel Spilker
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.5.0-alpha-1, 3.5.0
>
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to 
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of 
> the POM selected by {{--file}} and then go through the parent directories.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-5889) .mvn directory should be picked when using --file

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16727096#comment-16727096
 ] 

Robert Patrick commented on MNG-5889:
-

I see the issue now.  

On Windows 10, the mvn --file command seems to work with the following 
invocation styles:
 * mvn --file /path/to/pom.xml ...
 * mvn --file=/path/to/pom.xml ...

On Linux (e.g., in the official Docker container), the mvn --file command only 
works for the following invocation style:
 * mvn --file /path/to/pom.xml 

>From running mvn --help, it's not clear to me that --arg=value is intended to 
>be supported and I cannot seem to find the Maven doc that talks about the 
>command line options.  The reason for this difference has to do with Windows 
>CMD scripting behavior--not an intentional effort to support the 
>--file=/path/to/pom.xml syntax.

If the --file=/path/to/pom.xml syntax is supposed to be supported, the "mvn" 
shell script will require more work to detect both the --file /path/to/pom.xml 
and --file=/path/to/pom.xml usages.  



> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap & Build
>Affects Versions: 3.3.3, 3.3.9
>Reporter: Daniel Spilker
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.5.0-alpha-1, 3.5.0
>
> Attachments: reproduce_MNG-5889.bash
>
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to 
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of 
> the POM selected by {{--file}} and then go through the parent directories.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MNG-5889) .mvn directory should be picked when using --file

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16727096#comment-16727096
 ] 

Robert Patrick edited comment on MNG-5889 at 12/21/18 10:06 PM:


I see the issue now.  

On Windows 10, the mvn --file command seems to work with the following 
invocation styles:
 * mvn --file /path/to/pom.xml ...
 * mvn --file=/path/to/pom.xml ...

On Linux (e.g., in the official Docker container), the mvn --file command only 
works for the following invocation style:
 * mvn --file /path/to/pom.xml 

>From running {{mvn --help}}, it's not clear to me that --arg=value is intended 
>to be supported and I cannot seem to find the Maven doc that talks about the 
>command line options.  The reason for this difference has to do with Windows 
>CMD scripting behavior--not an intentional effort to support the 
>--file=/path/to/pom.xml syntax.

If the --file=/path/to/pom.xml syntax is supposed to be supported, the "mvn" 
shell script will require more work to detect both the --file /path/to/pom.xml 
and --file=/path/to/pom.xml usages.  




was (Author: rhpatrick00):
I see the issue now.  

On Windows 10, the mvn --file command seems to work with the following 
invocation styles:
 * mvn --file /path/to/pom.xml ...
 * mvn --file=/path/to/pom.xml ...

On Linux (e.g., in the official Docker container), the mvn --file command only 
works for the following invocation style:
 * mvn --file /path/to/pom.xml 

>From running mvn --help, it's not clear to me that --arg=value is intended to 
>be supported and I cannot seem to find the Maven doc that talks about the 
>command line options.  The reason for this difference has to do with Windows 
>CMD scripting behavior--not an intentional effort to support the 
>--file=/path/to/pom.xml syntax.

If the --file=/path/to/pom.xml syntax is supposed to be supported, the "mvn" 
shell script will require more work to detect both the --file /path/to/pom.xml 
and --file=/path/to/pom.xml usages.  



> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap & Build
>Affects Versions: 3.3.3, 3.3.9
>Reporter: Daniel Spilker
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.5.0-alpha-1, 3.5.0
>
> Attachments: reproduce_MNG-5889.bash
>
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to 
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of 
> the POM selected by {{--file}} and then go through the parent directories.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MNG-5889) .mvn directory should be picked when using --file

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16727096#comment-16727096
 ] 

Robert Patrick edited comment on MNG-5889 at 12/21/18 10:13 PM:


I see the issue now.  

On Windows 10, the mvn --file command seems to work with the following 
invocation styles:
 * mvn --file /path/to/pom.xml ...
 * mvn --file=/path/to/pom.xml ...

On Linux (e.g., in the official Docker container), the mvn --file command only 
works for the following invocation style:
 * mvn --file /path/to/pom.xml 

>From running mvn {{--help}}, it's not clear to me that --arg=value is intended 
>to be supported and I cannot seem to find the Maven doc that talks about the 
>command line options.  The reason for this difference has to do with Windows 
>CMD scripting behavior--not an intentional effort to support the 
>--file=/path/to/pom.xml syntax.

If the --file=/path/to/pom.xml syntax is supposed to be supported, the "mvn" 
shell script will require more work to detect both the --file /path/to/pom.xml 
and --file=/path/to/pom.xml usages.  




was (Author: rhpatrick00):
I see the issue now.  

On Windows 10, the mvn --file command seems to work with the following 
invocation styles:
 * mvn --file /path/to/pom.xml ...
 * mvn --file=/path/to/pom.xml ...

On Linux (e.g., in the official Docker container), the mvn --file command only 
works for the following invocation style:
 * mvn --file /path/to/pom.xml 

>From running mvn --help, it's not clear to me that --arg=value is intended to 
>be supported and I cannot seem to find the Maven doc that talks about the 
>command line options.  The reason for this difference has to do with Windows 
>CMD scripting behavior--not an intentional effort to support the 
>--file=/path/to/pom.xml syntax.

If the --file=/path/to/pom.xml syntax is supposed to be supported, the "mvn" 
shell script will require more work to detect both the --file /path/to/pom.xml 
and --file=/path/to/pom.xml usages.  



> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap & Build
>Affects Versions: 3.3.3, 3.3.9
>Reporter: Daniel Spilker
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.5.0-alpha-1, 3.5.0
>
> Attachments: reproduce_MNG-5889.bash
>
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to 
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of 
> the POM selected by {{--file}} and then go through the parent directories.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MNG-5889) .mvn directory should be picked when using --file

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16727096#comment-16727096
 ] 

Robert Patrick edited comment on MNG-5889 at 12/21/18 10:14 PM:


I see the issue now.  

On Windows 10, the mvn --file command seems to work with the following 
invocation styles:
 * mvn --file /path/to/pom.xml ...
 * mvn --file=/path/to/pom.xml ...

On Linux (e.g., in the official Docker container), the mvn --file command only 
works for the following invocation style:
 * mvn --file /path/to/pom.xml 

>From running mvn {{--help}}, it's not clear to me that --arg=value is intended 
>to be supported and I cannot seem to find the Maven doc that talks about the 
>command line options.  The reason for this difference has to do with Windows 
>CMD scripting behavior--not an intentional effort to support the 
>--file=/path/to/pom.xml syntax.

If the --file=/path/to/pom.xml syntax is supposed to be supported, the "mvn" 
shell script will require more work to detect both the --file /path/to/pom.xml 
and --file=/path/to/pom.xml usages.  

NOTE: To my knowledge, there is no way to change the Windows behavior of 
supporting both arguments styles for arguments processed in the shell script 
(most Maven arguments are processed in Java).



was (Author: rhpatrick00):
I see the issue now.  

On Windows 10, the mvn --file command seems to work with the following 
invocation styles:
 * mvn --file /path/to/pom.xml ...
 * mvn --file=/path/to/pom.xml ...

On Linux (e.g., in the official Docker container), the mvn --file command only 
works for the following invocation style:
 * mvn --file /path/to/pom.xml 

>From running mvn {{--help}}, it's not clear to me that --arg=value is intended 
>to be supported and I cannot seem to find the Maven doc that talks about the 
>command line options.  The reason for this difference has to do with Windows 
>CMD scripting behavior--not an intentional effort to support the 
>--file=/path/to/pom.xml syntax.

If the --file=/path/to/pom.xml syntax is supposed to be supported, the "mvn" 
shell script will require more work to detect both the --file /path/to/pom.xml 
and --file=/path/to/pom.xml usages.  



> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap & Build
>Affects Versions: 3.3.3, 3.3.9
>Reporter: Daniel Spilker
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.5.0-alpha-1, 3.5.0
>
> Attachments: reproduce_MNG-5889.bash
>
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to 
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of 
> the POM selected by {{--file}} and then go through the parent directories.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-5889) .mvn directory should be picked when using --file

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16727110#comment-16727110
 ] 

Robert Patrick commented on MNG-5889:
-

It makes it able to find the .mvn directory.  Prior to this bug fix, Maven 
always started the search in the current working directory even if the 
command-line argument told it to use the pom in another location.

> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap & Build
>Affects Versions: 3.3.3, 3.3.9
>Reporter: Daniel Spilker
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.5.0-alpha-1, 3.5.0
>
> Attachments: reproduce_MNG-5889.bash
>
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to 
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of 
> the POM selected by {{--file}} and then go through the parent directories.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MNG-5889) .mvn directory should be picked when using --file

[Robert Patrick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16727096#comment-16727096
 ] 

Robert Patrick edited comment on MNG-5889 at 12/21/18 10:12 PM:


I see the issue now.  

On Windows 10, the mvn --file command seems to work with the following 
invocation styles:
 * mvn --file /path/to/pom.xml ...
 * mvn --file=/path/to/pom.xml ...

On Linux (e.g., in the official Docker container), the mvn --file command only 
works for the following invocation style:
 * mvn --file /path/to/pom.xml 

>From running mvn --help, it's not clear to me that --arg=value is intended to 
>be supported and I cannot seem to find the Maven doc that talks about the 
>command line options.  The reason for this difference has to do with Windows 
>CMD scripting behavior--not an intentional effort to support the 
>--file=/path/to/pom.xml syntax.

If the --file=/path/to/pom.xml syntax is supposed to be supported, the "mvn" 
shell script will require more work to detect both the --file /path/to/pom.xml 
and --file=/path/to/pom.xml usages.  




was (Author: rhpatrick00):
I see the issue now.  

On Windows 10, the mvn --file command seems to work with the following 
invocation styles:
 * mvn --file /path/to/pom.xml ...
 * mvn --file=/path/to/pom.xml ...

On Linux (e.g., in the official Docker container), the mvn --file command only 
works for the following invocation style:
 * mvn --file /path/to/pom.xml 

>From running {{mvn --help}}, it's not clear to me that --arg=value is intended 
>to be supported and I cannot seem to find the Maven doc that talks about the 
>command line options.  The reason for this difference has to do with Windows 
>CMD scripting behavior--not an intentional effort to support the 
>--file=/path/to/pom.xml syntax.

If the --file=/path/to/pom.xml syntax is supposed to be supported, the "mvn" 
shell script will require more work to detect both the --file /path/to/pom.xml 
and --file=/path/to/pom.xml usages.  



> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap & Build
>Affects Versions: 3.3.3, 3.3.9
>Reporter: Daniel Spilker
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.5.0-alpha-1, 3.5.0
>
> Attachments: reproduce_MNG-5889.bash
>
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to 
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of 
> the POM selected by {{--file}} and then go through the parent directories.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MRELEASE-951) Release plugin ignores release.properties developmentVersion property

[Robert Patrick (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17002312#comment-17002312
 ] 

Robert Patrick commented on MRELEASE-951:
-

If it is not a bug, what is the purpose of the release.properties file and its 
ability to specify the development version if the plug does not honor it?

> Release plugin ignores release.properties developmentVersion property
> -
>
> Key: MRELEASE-951
> URL: https://issues.apache.org/jira/browse/MRELEASE-951
> Project: Maven Release Plugin
>  Issue Type: Bug
> Environment: maven-release-plugin 2.5.3
>Reporter: Robert Patrick
>Priority: Major
>
> I created my release.properties file with the following content:
> tag=myproject-2.0.0
> releaseVersion=2.0.0
> developmentVersion=2.1.0-SNAPSHOT
> and invoked the release plugin with:
> mvn --batch-mode release:prepare
> After running the maven-release-plugin, the POM version was set to 
> 2.0.1-SNAPSHOT even though I told it to set it to 2.1.0-SNAPSHOT.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MRELEASE-1060) release:prepare fails to pass system properties to build

[Robert Patrick (Jira)]

Robert Patrick created MRELEASE-1060:


 Summary: release:prepare fails to pass system properties to build
 Key: MRELEASE-1060
 URL: https://issues.apache.org/jira/browse/MRELEASE-1060
 Project: Maven Release Plugin
  Issue Type: Bug
  Components: perform, prepare
Affects Versions: 3.0.0-M1
 Environment: MacOS 10.15.7
Maven 3.6.3
MacBook Pro (16-inch, 2019) w/ 8-core i9 and 32 GB RAM
Reporter: Robert Patrick
 Attachments: release-prepare.log, release.properties, verify.log

I have a project with plugin that runs python tests and it requires 
configuration to tell it a directory path. The POM is set up to supply the 
value based on a Maven property defined in the POM. When I run the following 
command, everything works fine:

{{mvn -Dfoo=/path/to/directory verify}}

However, when I try to use the release plugin (after creating the 
release.properties file) using the following command:

{{mvn -B -Dfoo=/path/to/directory release:prepare}}

The process fails because the foo property is not defined.

I have created a simple 
[release-test|https://github.com/robertpatrick/release-test] reproducer to 
demonstrate the issue I am having. When I try to run the release:prepare (as 
shown above), I get:

{{...
[INFO] [INFO] — maven-surefire-plugin:2.20.1:test (default-test) @ release-test 
—}}
{{ [INFO] [INFO] }}
{{ [INFO] [INFO] ---}}
{{ [INFO] [INFO] T E S T S}}
{{ [INFO] [INFO] ---}}
{{ [INFO] [INFO] Running io.rhpatrick.test.ReleaseTesterTest}}
{{ [INFO] [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time 
elapsed: 0.075 s <<< FAILURE! - in io.rhpatrick.test.ReleaseTesterTest}}
{{ [INFO] [ERROR] 
TestAdd_WithPositiveNumbers_ReturnsExpectedNumber(io.rhpatrick.test.ReleaseTesterTest)
 Time elapsed: 0.01 s <<< ERROR!}}
{{ [INFO] java.lang.IllegalArgumentException: Java system property foo was 
empty}}
{{ [INFO] at 
io.rhpatrick.test.ReleaseTesterTest.ensurePropertySet(ReleaseTesterTest.java:15)}}
{{ [INFO] }}
{{ [INFO] [INFO] }}
{{ [INFO] [INFO] Results:}}
{{ [INFO] [INFO] }}
{{ [INFO] [ERROR] Errors: }}
{{ [INFO] [ERROR] ReleaseTesterTest.ensurePropertySet:15 IllegalArgument Java 
system property fo...}}
{{ [INFO] [INFO] }}
{{ [INFO] [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0}}
{{ [INFO] [INFO] }}
{{ [INFO] [INFO] 
}}
{{ [INFO] [INFO] BUILD FAILURE}}
{{ [INFO] [INFO] 
}}
{{ [INFO] [INFO] Total time: 2.536 s}}
{{ [INFO] [INFO] Finished at: 2021-02-27T09:59:26-06:00}}
{{ [INFO] [INFO] 
}}
{{ [INFO] [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on 
project release-test: There are test failures.}}
{{ [INFO] [ERROR] }}
{{ [INFO] [ERROR] Please refer to 
/Users/rpatrick/tmp/release-test/target/surefire-reports for the individual 
test results.}}
{{ [INFO] [ERROR] Please refer to dump files (if any exist) 
[date]-jvmRun[N].dump, [date].dumpstream and [date]-jvmRun[N].dumpstream.}}
{{ [INFO] [ERROR] -> [Help 1]}}
{{ [INFO] [ERROR] }}
{{ [INFO] [ERROR] To see the full stack trace of the errors, re-run Maven with 
the -e switch.}}
{{ [INFO] [ERROR] Re-run Maven using the -X switch to enable full debug 
logging.}}
{{ [INFO] [ERROR] }}
{{ [INFO] [ERROR] For more information about the errors and possible solutions, 
please read the following articles:}}
{{ [INFO] [ERROR] [Help 1] 
[http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException]}}
{{ [INFO] 
}}
{{ [INFO] BUILD FAILURE}}
{{ [INFO] 
}}
{{ [INFO] Total time: 4.588 s}}
{{ [INFO] Finished at: 2021-02-27T09:59:26-06:00}}
{{ [INFO] 
}}
{{ [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-release-plugin:3.0.0-M1:prepare (default-cli) on 
project release-test: Maven execution failed, exit code: '1' -> [Help 1]}}
{{ [ERROR] }}
{{ [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.}}
{{ [ERROR] Re-run Maven using the -X switch to enable full debug logging.}}
{{ [ERROR] }}
{{ [ERROR] For more information about the errors and possible solutions, please 
read the following articles:}}
{{ [ERROR] [Help 1] 
[http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException]}}

 

 

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] (MNGSITE-209) Doc error on Advanced Configuration of the HttpClient HTTP Wagon page

[Robert Patrick (JIRA)]

Robert Patrick created MNGSITE-209:
--

 Summary: Doc error on Advanced Configuration of the HttpClient 
HTTP Wagon page
 Key: MNGSITE-209
 URL: https://jira.codehaus.org/browse/MNGSITE-209
 Project: Maven Project Web Site
  Issue Type: Bug
Reporter: Robert Patrick


In section 
http://maven.apache.org/guides/mini/guide-http-settings.html#Fine-Tuning_HttpClient_Parameters,
 the examples are wrong.  For example, the Using Preemptive Authentication 
example shows the following XML:


  

  my-server
  

  

  
http.authentication.preemptive
%b,true
  

  

  

  


This does not work.  The  element is not recognized by the software, as 
the code expects the  element instead.  As such, the example should 
say:


  

  my-server
  

  

  
http.authentication.preemptive
%b,true
  

  

  

  





--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] [Created] (MRELEASE-951) Release plugin ignores release.properties developmentVersion property

[Robert Patrick (JIRA)]

Robert Patrick created MRELEASE-951:
---

 Summary: Release plugin ignores release.properties 
developmentVersion property
 Key: MRELEASE-951
 URL: https://issues.apache.org/jira/browse/MRELEASE-951
 Project: Maven Release Plugin
  Issue Type: Bug
 Environment: maven-release-plugin 2.5.3
Reporter: Robert Patrick


I created my release.properties file with the following content:

tag=myproject-2.0.0
releaseVersion=2.0.0
developmentVersion=2.1.0-SNAPSHOT

and invoked the release plugin with:

mvn --batch-mode release:prepare

After running the maven-release-plugin, the POM version was set to 
2.0.1-SNAPSHOT even though I told it to set it to 2.1.0-SNAPSHOT.
 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] (MNG-5518) @Parameter annotation requires property element to use command-line -D

[Robert Patrick (JIRA)]

Robert Patrick created MNG-5518:
---

 Summary: @Parameter annotation requires property element to use 
command-line -D
 Key: MNG-5518
 URL: https://jira.codehaus.org/browse/MNG-5518
 Project: Maven 2 & 3
  Issue Type: Bug
  Components: Plugin API
Affects Versions: 3.1.0, 3.0.4
 Environment: Windows 7 Pro 64 bit, JDK 1.7.0_40
Reporter: Robert Patrick
 Attachments: annotations.zip

When writing a plugin using the Maven Java annotations, the @Parameter 
annotation currently requires the property element to allow the goal to receive 
configuration information from the command-line using -DparamName=value even 
though the goal works fine without it when using a POM.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5518) @Parameter annotation requires property element to use command-line -D

[Robert Patrick (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-5518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=333062#comment-333062
 ] 

Robert Patrick commented on MNG-5518:
-

This is a behavior change from plugins using the javadoc-style annotations, 
which supported all parameters being expressed from the command-line.  Given 
that I can always specify them from a POM, I don't understand why it is 
important to not allow me to specify them from the command-line.

> @Parameter annotation requires property element to use command-line -D
> --
>
> Key: MNG-5518
> URL: https://jira.codehaus.org/browse/MNG-5518
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Plugin API
>Affects Versions: 3.0.4, 3.1.0
> Environment: Windows 7 Pro 64 bit, JDK 1.7.0_40
>Reporter: Robert Patrick
> Attachments: annotations.zip
>
>
> When writing a plugin using the Maven Java annotations, the @Parameter 
> annotation currently requires the property element to allow the goal to 
> receive configuration information from the command-line using 
> -DparamName=value even though the goal works fine without it when using a POM.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira