[jira] [Comment Edited] (MNG-6399) Lift JDK minimum to JDK 8
[ https://issues.apache.org/jira/browse/MNG-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661436#comment-16661436 ] Arjan Tijms edited comment on MNG-6399 at 10/23/18 11:03 PM: - I also think it would be a good idea to say something about baseline version updated in some formal way. Before long we'll be on Java 24, and if Maven would still be restricted to Java 7 it would feel completely antiquated, which on its turn would hinder new developers coming into the project. Just think of you wanting to contribute to a project today. You clone its source, ready to inspect it and find out where to start. Then horrors of horrors, it appears to be Java 1.0! Not even the collection framework would be there, everything being Vector and Hashtable, and that all because the maintainer 15 years ago saw zero benefit in updating tot Java 1.1. was (Author: arjan.tijms): I also think it would be a good idea to say something about baseline version updated in some formal way. Before long we'll be on Java 24, and if Maven would still be restricted to Java 7 it would feel completely antiquated, which on its turn would hinder new developers coming into the project. Just think of you wanting to contribute to a project today. You clone its source, ready to inspect it and find out where to start. Then horrors of horrors, it appears to be Java 1.0! Not even the collection framework would be there, everyone being Vector and Hashtable, and that all because the maintainer 15 years ago saw zero benefit in updating tot Java 1.1. > Lift JDK minimum to JDK 8 > - > > Key: MNG-6399 > URL: https://issues.apache.org/jira/browse/MNG-6399 > Project: Maven > Issue Type: Task >Affects Versions: 3.6.0 >Reporter: Karl Heinz Marbaise >Priority: Critical > Fix For: 3.6.x-candidate > > > I would like to lift the minimum of Maven Core to JDK 8 (I think it's time).. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6399) Lift JDK minimum to JDK 8
[ https://issues.apache.org/jira/browse/MNG-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661436#comment-16661436 ] Arjan Tijms commented on MNG-6399: -- I also think it would be a good idea to say something about baseline version updated in some formal way. Before long we'll be on Java 24, and if Maven would still be restricted to Java 7 it would feel completely antiquated, which on its turn would hinder new developers coming into the project. Just think of you wanting to contribute to a project today. You clone its source, ready to inspect it and find out where to start. Then horrors of horrors, it appears to be Java 1.0! Not even the collection framework would be there, everyone being Vector and Hashtable, and that all because the maintainer 15 years ago saw zero benefit in updating tot Java 1.1. > Lift JDK minimum to JDK 8 > - > > Key: MNG-6399 > URL: https://issues.apache.org/jira/browse/MNG-6399 > Project: Maven > Issue Type: Task >Affects Versions: 3.6.0 >Reporter: Karl Heinz Marbaise >Priority: Critical > Fix For: 3.6.x-candidate > > > I would like to lift the minimum of Maven Core to JDK 8 (I think it's time).. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] turbanoff opened a new pull request #8: Cleanup code using java 7 features
turbanoff opened a new pull request #8: Cleanup code using java 7 features URL: https://github.com/apache/maven-javadoc-plugin/pull/8 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Comment Edited] (SUREFIRE-1531) Option to switch-off Java 9 modules
[
https://issues.apache.org/jira/browse/SUREFIRE-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661262#comment-16661262
]
Petr Dolezal edited comment on SUREFIRE-1531 at 10/23/18 8:50 PM:
--
I hope my two cents hits the right target: I experienced very similar problem
with {{IllegalAccessError}} as described above as well, but it was plain JUnit
5 test.
After a while of exploring, I found out that the problem disappears when
anything that JUnit needs to touch with reflection, e.g., {{@Test}} methods or
methods for {{@MethodSource}} is public and the package is exported. Of course,
this is not very good and for not exported packages it is completely useless.
However, I peeked at the command line that Surefire produces to run the tests
and I tried to run the commands manually. I believe that the problem could be
fixed actually quite easily. Instead of just {{\-\-add-exports}} a more
powerful {{\-\-add-opens}} switch can do the trick as it effectively enables
almighty reflection for the code. Then JUnit worked fine again and could access
even non-public members.
was (Author: pdolezal):
I hope my two cents hits the right target: I experienced very similar problem
with {{IllegalAccessError}} as described above as well, but it was plain JUnit
5 test.
After a while of exploring, I found out that the problem disappears when
anything that JUnit needs to touch with reflection, e.g., {{@Test}} methods or
methods for {{@MethodSource}} is public and the package is exported. Of course,
this is not very good and for not exported packages it is completely useless.
However, I peeked at the command line that Surefire produces to run the tests
and I tried to run the commands manually. I believe that the problem could be
fixed actually quite easily. Instead of just {{--add-exports}} a more powerful
{{--add-opens}} switch can do the trick as it effectively enables almighty
reflection for the code. Then JUnit worked fine again and could access even
non-public members.
> Option to switch-off Java 9 modules
> ---
>
> Key: SUREFIRE-1531
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1531
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Lukáš Křečan
>Priority: Major
>
> I am working on a library and I am adding support for Java 9 modules.
> Surefire 2.21.0 by default executes tests with Java 9 modules switched-on if
> it detects module-info.java While it may make sense in some cases, in my case
> I'd like the switch it off.
> The reason is simple. I am using Mockito to mock an interface that extends a
> Spring interface. Mockito has to create an implementation of this interface
> (proxy or subclass) and for this it needs to have access to the Spring
> interfaces. If Java 9 modules are enabled for the tests I have to manually
> add each such dependencies to Surefire configuration, which does not make
> much sense. To makes things worse, the interface actually extends two Spring
> interfaces form two different Spring modules so the configuration is almost
> impossible to get right.
> So far I am at ( and I am still getting IllegalAccessErrors)
> {code:java}
> --add-exports spring.context/org.springframework.scheduling=org.mockito
> --add-exports spring.beans/org.springframework.beans.factory=org.mockito
> {code}
> I would prefer to switch-off the Java 9 modules for the test module
> altogether (same behavior as pre 2.21.0)
>
> The test is here
> [https://github.com/lukas-krecan/ShedLock/blob/java9/shedlock-spring/src/test/java/net/javacrumbs/shedlock/spring/CleanupTest.java]
>
> If you want, I can send a pull request.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1531) Option to switch-off Java 9 modules
[
https://issues.apache.org/jira/browse/SUREFIRE-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661262#comment-16661262
]
Petr Dolezal commented on SUREFIRE-1531:
I hope my two cents hits the right target: I experienced very similar problem
with {{IllegalAccessError}} as described above as well, but it was plain JUnit
5 test.
After a while of exploring, I found out that the problem disappears when
anything that JUnit needs to touch with reflection, e.g., {{@Test}} methods or
methods for {{@MethodSource}} is public and the package is exported. Of course,
this is not very good and for not exported packages it is completely useless.
However, I peeked at the command line that Surefire produces to run the tests
and I tried to run the commands manually. I believe that the problem could be
fixed actually quite easily. Instead of just {{--add-exports}} a more powerful
{{--add-opens}} switch can do the trick as it effectively enables almighty
reflection for the code. Then JUnit worked fine again and could access even
non-public members.
> Option to switch-off Java 9 modules
> ---
>
> Key: SUREFIRE-1531
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1531
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Lukáš Křečan
>Priority: Major
>
> I am working on a library and I am adding support for Java 9 modules.
> Surefire 2.21.0 by default executes tests with Java 9 modules switched-on if
> it detects module-info.java While it may make sense in some cases, in my case
> I'd like the switch it off.
> The reason is simple. I am using Mockito to mock an interface that extends a
> Spring interface. Mockito has to create an implementation of this interface
> (proxy or subclass) and for this it needs to have access to the Spring
> interfaces. If Java 9 modules are enabled for the tests I have to manually
> add each such dependencies to Surefire configuration, which does not make
> much sense. To makes things worse, the interface actually extends two Spring
> interfaces form two different Spring modules so the configuration is almost
> impossible to get right.
> So far I am at ( and I am still getting IllegalAccessErrors)
> {code:java}
> --add-exports spring.context/org.springframework.scheduling=org.mockito
> --add-exports spring.beans/org.springframework.beans.factory=org.mockito
> {code}
> I would prefer to switch-off the Java 9 modules for the test module
> altogether (same behavior as pre 2.21.0)
>
> The test is here
> [https://github.com/lukas-krecan/ShedLock/blob/java9/shedlock-spring/src/test/java/net/javacrumbs/shedlock/spring/CleanupTest.java]
>
> If you want, I can send a pull request.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRELEASE-1016) mvn release:branch fails on Windows to commit changed pom in branch
[
https://issues.apache.org/jira/browse/MRELEASE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661210#comment-16661210
]
Anthony Whitford commented on MRELEASE-1016:
Another observation is that I can see that the local {{pom.xml}} file is being
modified correctly, but then reverting. The modified {{pom.xml}} does not
appear to be committed to Git – each branch simply is a synonym for the tag.
> mvn release:branch fails on Windows to commit changed pom in branch
> ---
>
> Key: MRELEASE-1016
> URL: https://issues.apache.org/jira/browse/MRELEASE-1016
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: branch
>Affects Versions: 2.5.3
> Environment: Apache Maven 3.3.9
> Java version: 1.8.0_60, vendor: Oracle Corporation
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
> git version 2.16.2.windows.1
>Reporter: Anthony Whitford
>Assignee: Robert Scholte
>Priority: Blocker
>
> I need to create a branch from a tag. Imagine branching from a 1.0 tag, the
> following should work:
> {noformat}
> git checkout project-1.0
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT
> git checkout 1.0.x
> {noformat}
> Alas, the {{pom.xml}} in the new branch still references version 1.0 (not
> 1.0.1-SNAPSHOT), and the {{}} references the tag, not the branch.
> (!) This looks like MRELEASE-881 was simply never resolved.
> If I run a _Dry Run_, like:
> {noformat}
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT -DpushChanges=false
> -DdryRun=true
> {noformat}
> I can see the correct updates in {{pom.xml.branch}}.
> Note that there are no differences between {{pom.xml}} and {{pom.xml.next}}.
> _Why is {{pom.xml.branch}} not being captured in the branch?_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRELEASE-1016) mvn release:branch fails on Windows to commit changed pom in branch
[
https://issues.apache.org/jira/browse/MRELEASE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661202#comment-16661202
]
Anthony Whitford commented on MRELEASE-1016:
I noticed this output looks odd:
{noformat}
[INFO] Modified POMs are not committed because suppressCommitBeforeTagOrBranch
is set to false.
[INFO] Branching release with the label null...{noformat}
* There is no property for {{suppressCommitBeforeTagOrBranch}} (there is
{{suppressCommitBeforeBranch}}, but setting that to {{true}} has no impact).
* It also reads weird that a {{false}} _suppress_ does _not_ commit.
* Finally, the release label is _null_?
> mvn release:branch fails on Windows to commit changed pom in branch
> ---
>
> Key: MRELEASE-1016
> URL: https://issues.apache.org/jira/browse/MRELEASE-1016
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: branch
>Affects Versions: 2.5.3
> Environment: Apache Maven 3.3.9
> Java version: 1.8.0_60, vendor: Oracle Corporation
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
> git version 2.16.2.windows.1
>Reporter: Anthony Whitford
>Assignee: Robert Scholte
>Priority: Blocker
>
> I need to create a branch from a tag. Imagine branching from a 1.0 tag, the
> following should work:
> {noformat}
> git checkout project-1.0
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT
> git checkout 1.0.x
> {noformat}
> Alas, the {{pom.xml}} in the new branch still references version 1.0 (not
> 1.0.1-SNAPSHOT), and the {{}} references the tag, not the branch.
> (!) This looks like MRELEASE-881 was simply never resolved.
> If I run a _Dry Run_, like:
> {noformat}
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT -DpushChanges=false
> -DdryRun=true
> {noformat}
> I can see the correct updates in {{pom.xml.branch}}.
> Note that there are no differences between {{pom.xml}} and {{pom.xml.next}}.
> _Why is {{pom.xml.branch}} not being captured in the branch?_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MRELEASE-1016) mvn release:branch fails on Windows to commit changed pom in branch
[
https://issues.apache.org/jira/browse/MRELEASE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-1016:
-
Fix Version/s: (was: 2.5.3)
> mvn release:branch fails on Windows to commit changed pom in branch
> ---
>
> Key: MRELEASE-1016
> URL: https://issues.apache.org/jira/browse/MRELEASE-1016
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: branch
>Affects Versions: 2.5.3
> Environment: Apache Maven 3.3.9
> Java version: 1.8.0_60, vendor: Oracle Corporation
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
> git version 2.16.2.windows.1
>Reporter: Anthony Whitford
>Assignee: Robert Scholte
>Priority: Blocker
>
> I need to create a branch from a tag. Imagine branching from a 1.0 tag, the
> following should work:
> {noformat}
> git checkout project-1.0
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT
> git checkout 1.0.x
> {noformat}
> Alas, the {{pom.xml}} in the new branch still references version 1.0 (not
> 1.0.1-SNAPSHOT), and the {{}} references the tag, not the branch.
> (!) This looks like MRELEASE-881 was simply never resolved.
> If I run a _Dry Run_, like:
> {noformat}
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT -DpushChanges=false
> -DdryRun=true
> {noformat}
> I can see the correct updates in {{pom.xml.branch}}.
> Note that there are no differences between {{pom.xml}} and {{pom.xml.next}}.
> _Why is {{pom.xml.branch}} not being captured in the branch?_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MRELEASE-1016) mvn release:branch fails on Windows to commit changed pom in branch
[
https://issues.apache.org/jira/browse/MRELEASE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Whitford updated MRELEASE-1016:
---
Environment:
Apache Maven 3.3.9
Java version: 1.8.0_60, vendor: Oracle Corporation
OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
git version 2.16.2.windows.1
was:
git version 1.9.4.msysgit.0;
Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T18:37:5
2+01:00)
Maven home: D:\Dev\maven\apache-maven-3.2.1\bin\..
Java version: 1.7.0_51, vendor: Oracle Corporation
Java home: D:\Dev\Java\jdk7_51_x64\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
> mvn release:branch fails on Windows to commit changed pom in branch
> ---
>
> Key: MRELEASE-1016
> URL: https://issues.apache.org/jira/browse/MRELEASE-1016
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: branch
>Affects Versions: 2.5.3
> Environment: Apache Maven 3.3.9
> Java version: 1.8.0_60, vendor: Oracle Corporation
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
> git version 2.16.2.windows.1
>Reporter: Anthony Whitford
>Assignee: Robert Scholte
>Priority: Blocker
> Fix For: 2.5.3
>
>
> I need to create a branch from a tag. Imagine branching from a 1.0 tag, the
> following should work:
> {noformat}
> git checkout project-1.0
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT
> git checkout 1.0.x
> {noformat}
> Alas, the {{pom.xml}} in the new branch still references version 1.0 (not
> 1.0.1-SNAPSHOT), and the {{}} references the tag, not the branch.
> (!) This looks like MRELEASE-881 was simply never resolved.
> If I run a _Dry Run_, like:
> {noformat}
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT -DpushChanges=false
> -DdryRun=true
> {noformat}
> I can see the correct updates in {{pom.xml.branch}}.
> Note that there are no differences between {{pom.xml}} and {{pom.xml.next}}.
> _Why is {{pom.xml.branch}} not being captured in the branch?_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRELEASE-1016) mvn release:branch fails on Windows to commit changed pom in branch
[
https://issues.apache.org/jira/browse/MRELEASE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661137#comment-16661137
]
Anthony Whitford commented on MRELEASE-1016:
The _Fix Version_ needs to be updated, but I do not have permission.
> mvn release:branch fails on Windows to commit changed pom in branch
> ---
>
> Key: MRELEASE-1016
> URL: https://issues.apache.org/jira/browse/MRELEASE-1016
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: branch
>Affects Versions: 2.5.3
> Environment: git version 1.9.4.msysgit.0;
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
> 2014-02-14T18:37:5
> 2+01:00)
> Maven home: D:\Dev\maven\apache-maven-3.2.1\bin\..
> Java version: 1.7.0_51, vendor: Oracle Corporation
> Java home: D:\Dev\Java\jdk7_51_x64\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Anthony Whitford
>Assignee: Robert Scholte
>Priority: Blocker
> Fix For: 2.5.3
>
>
> I need to create a branch from a tag. Imagine branching from a 1.0 tag, the
> following should work:
> {noformat}
> git checkout project-1.0
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT
> git checkout 1.0.x
> {noformat}
> Alas, the {{pom.xml}} in the new branch still references version 1.0 (not
> 1.0.1-SNAPSHOT), and the {{}} references the tag, not the branch.
> (!) This looks like MRELEASE-881 was simply never resolved.
> If I run a _Dry Run_, like:
> {noformat}
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT -DpushChanges=false
> -DdryRun=true
> {noformat}
> I can see the correct updates in {{pom.xml.branch}}.
> Note that there are no differences between {{pom.xml}} and {{pom.xml.next}}.
> _Why is {{pom.xml.branch}} not being captured in the branch?_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MRELEASE-1016) mvn release:branch fails on Windows to commit changed pom in branch
[
https://issues.apache.org/jira/browse/MRELEASE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Whitford updated MRELEASE-1016:
---
Description:
I need to create a branch from a tag. Imagine branching from a 1.0 tag, the
following should work:
{noformat}
git checkout project-1.0
mvn release:branch -DupdateBranchVersions=true
-DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
-DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT
git checkout 1.0.x
{noformat}
Alas, the {{pom.xml}} in the new branch still references version 1.0 (not
1.0.1-SNAPSHOT), and the {{}} references the tag, not the branch.
(!) This looks like MRELEASE-881 was simply never resolved.
If I run a _Dry Run_, like:
{noformat}
mvn release:branch -DupdateBranchVersions=true
-DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
-DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT -DpushChanges=false
-DdryRun=true
{noformat}
I can see the correct updates in {{pom.xml.branch}}.
Note that there are no differences between {{pom.xml}} and {{pom.xml.next}}.
_Why is {{pom.xml.branch}} not being captured in the branch?_
was:
I have tried this with 2.5 version ... also with 1.9 git:scm dependency.
I guess it has to do with the WARNINGS shown below. Git itself works without
any problems.
The branch is created, but still has the version 1.0-SNAPSHOT. It should have
the version 1.0-copy-SNAPSHOT. The version was correct updated in the
pom.xml.branch has the correct version information (which I can see with
-DdryRun=true)
Following command fails to commit the "next pom" into the branch:
{noformat}
mvn release:branch -DbranchName=copy-repo-settings -DremoteTagging=false
-DupdateBranchVersions=true -DupdateWorking
CopyVersions=false -DreleaseVersion=1.0-copy-SNAPSHOT
.
[INFO] --- maven-release-plugin:2.5:branch (default-cli) @ monthly-update ---
[INFO] Verifying that there are no local modifications...
[INFO] ignoring changes on: **\release.properties, **\pom.xml.next, **\pom.xml
.releaseBackup, **\pom.xml.backup, **\pom.xml.branch, **\pom.xml.tag
[INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git status --porcelain ."
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Transforming 'montly DevOpts Plugin'...
[INFO] Checking in modified POMs...
[INFO] Executing: cmd.exe /X /C "git add -- pom.xml"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git status --porcelain ."
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[WARNING] Ignoring unrecognized line: ?? monthly-update/pom.xml.releaseBackup
[INFO] Branching release with the label null...
[INFO] Executing: cmd.exe /X /C "git branch copy-repo-settings"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git push https://user:pass@dev/git/devopts.git
refs/heads/copy-repo-settings"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git ls-files"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Transforming 'montly DevOpts Plugin'...
[INFO] Checking in modified POMs...
[INFO] Executing: cmd.exe /X /C "git add -- pom.xml"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git status --porcelain ."
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[WARNING] Ignoring unrecognized line: ?? monthly-update/pom.xml.releaseBackup
[INFO] Release preparation complete.
[INFO] Cleaning up after release...
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 11.853 s
[INFO] Finished at: 2014-07-09T09:03:58+01:00
[INFO] Final Memory: 11M/307M
[INFO]
{noformat}
> mvn release:branch fails on Windows to commit changed pom in branch
> ---
>
> Key: MRELEASE-1016
> URL: https://issues.apache.org/jira/browse/MRELEASE-1016
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: branch
>Affects Versions: 2.5.3
> Environment: git version 1.9.4.msysgit.0;
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
> 2014-02-14T18:37:5
> 2+01:00)
> Maven home:
[jira] [Updated] (MRELEASE-1016) mvn release:branch fails on Windows to commit changed pom in branch
[
https://issues.apache.org/jira/browse/MRELEASE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Whitford updated MRELEASE-1016:
---
Affects Version/s: (was: 2.5)
(was: 2.3.2)
2.5.3
> mvn release:branch fails on Windows to commit changed pom in branch
> ---
>
> Key: MRELEASE-1016
> URL: https://issues.apache.org/jira/browse/MRELEASE-1016
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: branch
>Affects Versions: 2.5.3
> Environment: git version 1.9.4.msysgit.0;
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
> 2014-02-14T18:37:5
> 2+01:00)
> Maven home: D:\Dev\maven\apache-maven-3.2.1\bin\..
> Java version: 1.7.0_51, vendor: Oracle Corporation
> Java home: D:\Dev\Java\jdk7_51_x64\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Anthony Whitford
>Assignee: Robert Scholte
>Priority: Blocker
> Fix For: 2.5.3
>
>
> I have tried this with 2.5 version ... also with 1.9 git:scm dependency.
> I guess it has to do with the WARNINGS shown below. Git itself works without
> any problems.
> The branch is created, but still has the version 1.0-SNAPSHOT. It should have
> the version 1.0-copy-SNAPSHOT. The version was correct updated in the
> pom.xml.branch has the correct version information (which I can see with
> -DdryRun=true)
> Following command fails to commit the "next pom" into the branch:
> {noformat}
> mvn release:branch -DbranchName=copy-repo-settings -DremoteTagging=false
> -DupdateBranchVersions=true -DupdateWorking
> CopyVersions=false -DreleaseVersion=1.0-copy-SNAPSHOT
> .
> [INFO] --- maven-release-plugin:2.5:branch (default-cli) @ monthly-update ---
> [INFO] Verifying that there are no local modifications...
> [INFO] ignoring changes on: **\release.properties, **\pom.xml.next,
> **\pom.xml
> .releaseBackup, **\pom.xml.backup, **\pom.xml.branch, **\pom.xml.tag
> [INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git status --porcelain ."
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Transforming 'montly DevOpts Plugin'...
> [INFO] Checking in modified POMs...
> [INFO] Executing: cmd.exe /X /C "git add -- pom.xml"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git status --porcelain ."
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [WARNING] Ignoring unrecognized line: ?? monthly-update/pom.xml.releaseBackup
> [INFO] Branching release with the label null...
> [INFO] Executing: cmd.exe /X /C "git branch copy-repo-settings"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git push
> https://user:pass@dev/git/devopts.git refs/heads/copy-repo-settings"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git ls-files"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Transforming 'montly DevOpts Plugin'...
> [INFO] Checking in modified POMs...
> [INFO] Executing: cmd.exe /X /C "git add -- pom.xml"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git status --porcelain ."
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [WARNING] Ignoring unrecognized line: ?? monthly-update/pom.xml.releaseBackup
> [INFO] Release preparation complete.
> [INFO] Cleaning up after release...
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 11.853 s
> [INFO] Finished at: 2014-07-09T09:03:58+01:00
> [INFO] Final Memory: 11M/307M
> [INFO]
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MRELEASE-1016) mvn release:branch fails on Windows to commit changed pom in branch
Anthony Whitford created MRELEASE-1016:
--
Summary: mvn release:branch fails on Windows to commit changed pom
in branch
Key: MRELEASE-1016
URL: https://issues.apache.org/jira/browse/MRELEASE-1016
Project: Maven Release Plugin
Issue Type: Bug
Components: branch
Affects Versions: 2.3.2, 2.5
Environment: git version 1.9.4.msysgit.0;
Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T18:37:5
2+01:00)
Maven home: D:\Dev\maven\apache-maven-3.2.1\bin\..
Java version: 1.7.0_51, vendor: Oracle Corporation
Java home: D:\Dev\Java\jdk7_51_x64\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Reporter: Anthony Whitford
Assignee: Robert Scholte
Fix For: 2.5.3
I have tried this with 2.5 version ... also with 1.9 git:scm dependency.
I guess it has to do with the WARNINGS shown below. Git itself works without
any problems.
The branch is created, but still has the version 1.0-SNAPSHOT. It should have
the version 1.0-copy-SNAPSHOT. The version was correct updated in the
pom.xml.branch has the correct version information (which I can see with
-DdryRun=true)
Following command fails to commit the "next pom" into the branch:
{noformat}
mvn release:branch -DbranchName=copy-repo-settings -DremoteTagging=false
-DupdateBranchVersions=true -DupdateWorking
CopyVersions=false -DreleaseVersion=1.0-copy-SNAPSHOT
.
[INFO] --- maven-release-plugin:2.5:branch (default-cli) @ monthly-update ---
[INFO] Verifying that there are no local modifications...
[INFO] ignoring changes on: **\release.properties, **\pom.xml.next, **\pom.xml
.releaseBackup, **\pom.xml.backup, **\pom.xml.branch, **\pom.xml.tag
[INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git status --porcelain ."
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Transforming 'montly DevOpts Plugin'...
[INFO] Checking in modified POMs...
[INFO] Executing: cmd.exe /X /C "git add -- pom.xml"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git status --porcelain ."
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[WARNING] Ignoring unrecognized line: ?? monthly-update/pom.xml.releaseBackup
[INFO] Branching release with the label null...
[INFO] Executing: cmd.exe /X /C "git branch copy-repo-settings"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git push https://user:pass@dev/git/devopts.git
refs/heads/copy-repo-settings"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git ls-files"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Transforming 'montly DevOpts Plugin'...
[INFO] Checking in modified POMs...
[INFO] Executing: cmd.exe /X /C "git add -- pom.xml"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git status --porcelain ."
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[WARNING] Ignoring unrecognized line: ?? monthly-update/pom.xml.releaseBackup
[INFO] Release preparation complete.
[INFO] Cleaning up after release...
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 11.853 s
[INFO] Finished at: 2014-07-09T09:03:58+01:00
[INFO] Final Memory: 11M/307M
[INFO]
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRELEASE-881) mvn release:branch fails on Windows to commit changed pom in branch
[
https://issues.apache.org/jira/browse/MRELEASE-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661117#comment-16661117
]
Anthony Whitford commented on MRELEASE-881:
---
This is not working for me, and I am using version 2.5.3, Maven 3.3.9, and Git
version 2.16.2.windows.1 on Windows 7.
> mvn release:branch fails on Windows to commit changed pom in branch
> ---
>
> Key: MRELEASE-881
> URL: https://issues.apache.org/jira/browse/MRELEASE-881
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: branch
>Affects Versions: 2.3.2, 2.5
> Environment: git version 1.9.4.msysgit.0;
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
> 2014-02-14T18:37:5
> 2+01:00)
> Maven home: D:\Dev\maven\apache-maven-3.2.1\bin\..
> Java version: 1.7.0_51, vendor: Oracle Corporation
> Java home: D:\Dev\Java\jdk7_51_x64\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Thomas Wabner
>Assignee: Robert Scholte
>Priority: Blocker
> Fix For: 2.5.3
>
>
> I have tried this with 2.5 version ... also with 1.9 git:scm dependency.
> I guess it has to do with the WARNINGS shown below. Git itself works without
> any problems.
> The branch is created, but still has the version 1.0-SNAPSHOT. It should have
> the version 1.0-copy-SNAPSHOT. The version was correct updated in the
> pom.xml.branch has the correct version information (which I can see with
> -DdryRun=true)
> Following command fails to commit the "next pom" into the branch:
> {noformat}
> mvn release:branch -DbranchName=copy-repo-settings -DremoteTagging=false
> -DupdateBranchVersions=true -DupdateWorking
> CopyVersions=false -DreleaseVersion=1.0-copy-SNAPSHOT
> .
> [INFO] --- maven-release-plugin:2.5:branch (default-cli) @ monthly-update ---
> [INFO] Verifying that there are no local modifications...
> [INFO] ignoring changes on: **\release.properties, **\pom.xml.next,
> **\pom.xml
> .releaseBackup, **\pom.xml.backup, **\pom.xml.branch, **\pom.xml.tag
> [INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git status --porcelain ."
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Transforming 'montly DevOpts Plugin'...
> [INFO] Checking in modified POMs...
> [INFO] Executing: cmd.exe /X /C "git add -- pom.xml"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git status --porcelain ."
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [WARNING] Ignoring unrecognized line: ?? monthly-update/pom.xml.releaseBackup
> [INFO] Branching release with the label null...
> [INFO] Executing: cmd.exe /X /C "git branch copy-repo-settings"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git push
> https://user:pass@dev/git/devopts.git refs/heads/copy-repo-settings"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git ls-files"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Transforming 'montly DevOpts Plugin'...
> [INFO] Checking in modified POMs...
> [INFO] Executing: cmd.exe /X /C "git add -- pom.xml"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git status --porcelain ."
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [WARNING] Ignoring unrecognized line: ?? monthly-update/pom.xml.releaseBackup
> [INFO] Release preparation complete.
> [INFO] Cleaning up after release...
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 11.853 s
> [INFO] Finished at: 2014-07-09T09:03:58+01:00
> [INFO] Final Memory: 11M/307M
> [INFO]
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARCHETYPE-528) Archetype:generate from repos besides central does not work
[
https://issues.apache.org/jira/browse/ARCHETYPE-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661095#comment-16661095
]
Robert Scholte commented on ARCHETYPE-528:
--
The Maven team has other priorities and it seems that no user thinks this is
important enough to have a look at, trying to find the bug and provide a patch
we can apply. Hence it is still open.
> Archetype:generate from repos besides central does not work
> ---
>
> Key: ARCHETYPE-528
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-528
> Project: Maven Archetype
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: João Cabrita
>Priority: Critical
> Attachments: settings.xml
>
>
> {noformat}
> mvn -X -P camunda -DarchetypeCatalog=remote
> org.apache.maven.plugins:maven-archetype-plugin:3.0.1:generate
> -Dfilter=org.camunda.bpm.archetype:
> {noformat}
> Results in the following:
> {noformat}
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-archetype-plugin:3.0.1:generate' with basic
> configurator -->
> [DEBUG] (f) archetypeCatalog = remote
> [DEBUG] (f) basedir = C:\Users\joao.cabrita\projects\bpm
> [DEBUG] (f) filter = org.camunda.bpm.archetype:
> [DEBUG] (f) interactiveMode = true
> [DEBUG] (f) localRepository = id: local
> url: file:///C:/Users/joao.cabrita/.m2/repository/
>layout: default
> snapshots: [enabled => true, update => always]
> releases: [enabled => true, update => always]
> [DEBUG] (f) remoteArtifactRepositories = [ id: central
> url: https://app.camunda.com/nexus/content/repositories/camunda-bpm
>layout: default
> proxy: proxy.brisa.pt:3128
> snapshots: [enabled => true, update => daily]
> releases: [enabled => true, update => daily]
> , id: archetype
> url: https://app.camunda.com/nexus/content/repositories/camunda-bpm
>layout: default
> proxy: proxy.brisa.pt:3128
> snapshots: [enabled => true, update => daily]
> releases: [enabled => true, update => daily]
> ]
> [DEBUG] (f) session = org.apache.maven.execution.MavenSession@325f7fa9
> [DEBUG] -- end configuration --
> [INFO] Generating project in Interactive mode
> [DEBUG] Searching for remote catalog:
> https://repo.maven.apache.org/maven2/archetype-catalog.xml
> [WARNING] No archetype found in remote catalog. Defaulting to internal catalog
> [INFO] Your filter doesn't match any archetype, so try again with another
> value.
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {noformat}
> I've attached my settings.xml file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6495) ModelResolver cannot be null
[
https://issues.apache.org/jira/browse/MNG-6495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661094#comment-16661094
]
Elliotte Rusty Harold commented on MNG-6495:
I'll have to see if I can repro this. This as not a command line invocation of
Maven. It happened because some of my own code attempted to pass null for an
argument.
> ModelResolver cannot be null
>
>
> Key: MNG-6495
> URL: https://issues.apache.org/jira/browse/MNG-6495
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build
>Affects Versions: 3.5.4
>Reporter: Elliotte Rusty Harold
>Priority: Major
>
> Got this exception stacktrace while writing some of my own code today:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException:
> request.modelResolver cannot be null (parent POM
> com.google.guava:guava-parent:26.0-jre and POM
> com.google.guava:guava:[unknown-version])
> at org.apache.commons.lang3.Validate.notNull(Validate.java:225)
> at
> org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:1046)
> at
> org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:830)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:332)
> at
> com.google.cloud.tools.opensource.dependencies.MetadataExplorer.main(MetadataExplorer.java:50)
> {noformat}
> No big deal except that the JavaDoc at
> [ModelBuildingRequest|http://maven.apache.org/ref/3.5.4/maven-model-builder/apidocs/org/apache/maven/model/building/ModelBuildingRequest.html]
> says "The model resolver to use, may be null."
> Not sure whether to update the docs or the code here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6495) ModelResolver cannot be null
[
https://issues.apache.org/jira/browse/MNG-6495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661080#comment-16661080
]
Robert Scholte commented on MNG-6495:
-
I don't understand the {{[unknown-version]}}-part. As if the parent-pom is
invalid. Do you have a minimal pom to reproduce this issue?
> ModelResolver cannot be null
>
>
> Key: MNG-6495
> URL: https://issues.apache.org/jira/browse/MNG-6495
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build
>Affects Versions: 3.5.4
>Reporter: Elliotte Rusty Harold
>Priority: Major
>
> Got this exception stacktrace while writing some of my own code today:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException:
> request.modelResolver cannot be null (parent POM
> com.google.guava:guava-parent:26.0-jre and POM
> com.google.guava:guava:[unknown-version])
> at org.apache.commons.lang3.Validate.notNull(Validate.java:225)
> at
> org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:1046)
> at
> org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:830)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:332)
> at
> com.google.cloud.tools.opensource.dependencies.MetadataExplorer.main(MetadataExplorer.java:50)
> {noformat}
> No big deal except that the JavaDoc at
> [ModelBuildingRequest|http://maven.apache.org/ref/3.5.4/maven-model-builder/apidocs/org/apache/maven/model/building/ModelBuildingRequest.html]
> says "The model resolver to use, may be null."
> Not sure whether to update the docs or the code here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6495) ModelResolver cannot be null
[
https://issues.apache.org/jira/browse/MNG-6495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-6495:
Description:
Got this exception stacktrace while writing some of my own code today:
{noformat}
Exception in thread "main" java.lang.NullPointerException:
request.modelResolver cannot be null (parent POM
com.google.guava:guava-parent:26.0-jre and POM
com.google.guava:guava:[unknown-version])
at org.apache.commons.lang3.Validate.notNull(Validate.java:225)
at
org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:1046)
at
org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:830)
at
org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:332)
at
com.google.cloud.tools.opensource.dependencies.MetadataExplorer.main(MetadataExplorer.java:50)
{noformat}
No big deal except that the JavaDoc at
[ModelBuildingRequest|http://maven.apache.org/ref/3.5.4/maven-model-builder/apidocs/org/apache/maven/model/building/ModelBuildingRequest.html]
says "The model resolver to use, may be null."
Not sure whether to update the docs or the code here.
was:
Got this exception stacktrace while writing some of my own code today:
Exception in thread "main" java.lang.NullPointerException:
request.modelResolver cannot be null (parent POM
com.google.guava:guava-parent:26.0-jre and POM
com.google.guava:guava:[unknown-version])
at org.apache.commons.lang3.Validate.notNull(Validate.java:225)
at
org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:1046)
at
org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:830)
at
org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:332)
at
com.google.cloud.tools.opensource.dependencies.MetadataExplorer.main(MetadataExplorer.java:50)
No big deal except that the JavaDoc at
http://maven.apache.org/ref/3.5.4/maven-model-builder/apidocs/org/apache/maven/model/building/ModelBuildingRequest.html
says "The model resolver to use, may be null."
Not sure whether to update the docs or the code here.
> ModelResolver cannot be null
>
>
> Key: MNG-6495
> URL: https://issues.apache.org/jira/browse/MNG-6495
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build
>Affects Versions: 3.5.4
>Reporter: Elliotte Rusty Harold
>Priority: Major
>
> Got this exception stacktrace while writing some of my own code today:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException:
> request.modelResolver cannot be null (parent POM
> com.google.guava:guava-parent:26.0-jre and POM
> com.google.guava:guava:[unknown-version])
> at org.apache.commons.lang3.Validate.notNull(Validate.java:225)
> at
> org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:1046)
> at
> org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:830)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:332)
> at
> com.google.cloud.tools.opensource.dependencies.MetadataExplorer.main(MetadataExplorer.java:50)
> {noformat}
> No big deal except that the JavaDoc at
> [ModelBuildingRequest|http://maven.apache.org/ref/3.5.4/maven-model-builder/apidocs/org/apache/maven/model/building/ModelBuildingRequest.html]
> says "The model resolver to use, may be null."
> Not sure whether to update the docs or the code here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6399) Lift JDK minimum to JDK 8
[
https://issues.apache.org/jira/browse/MNG-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16660998#comment-16660998
]
Matt Nelson commented on MNG-6399:
--
{quote}The deploy plugin problem has nothing to do with JDK 8 or not
{quote}
I provided that example to illustrate where some of the new language feature
would've made the implementation easier. I don't want to get off topic and
debate the details of the fix here.
I would like to stay focused on advocating for the JDK uplift or at a minimum
as [~nhoj.patrick] suggested a formalization of process of when Maven will be
uplifted
For reference, the current baseline of 7 was uplifted with
[3.3.1|https://maven.apache.org/docs/history.html] on {{2015-03-18}} which was
1 month before [7 was publicly end of
life|https://en.wikipedia.org/wiki/Java_version_history#Java_7_updates] on
{{2015-04-14}}
> Lift JDK minimum to JDK 8
> -
>
> Key: MNG-6399
> URL: https://issues.apache.org/jira/browse/MNG-6399
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.6.0
>Reporter: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 3.6.x-candidate
>
>
> I would like to lift the minimum of Maven Core to JDK 8 (I think it's time)..
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARCHETYPE-528) Archetype:generate from repos besides central does not work
[
https://issues.apache.org/jira/browse/ARCHETYPE-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16660882#comment-16660882
]
Amélie Deltour commented on ARCHETYPE-528:
--
Hi,
Any news about this issue?
There is obviously a bug here (see also email thread
[https://lists.apache.org/thread.html/b66d57e332f0d982d976307b8c9fd66c01dcd8b35d702459da3af659@%3Cdev.maven.apache.org%3E)]
The issue has been open for quite a while now...
> Archetype:generate from repos besides central does not work
> ---
>
> Key: ARCHETYPE-528
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-528
> Project: Maven Archetype
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: João Cabrita
>Priority: Critical
> Attachments: settings.xml
>
>
> {noformat}
> mvn -X -P camunda -DarchetypeCatalog=remote
> org.apache.maven.plugins:maven-archetype-plugin:3.0.1:generate
> -Dfilter=org.camunda.bpm.archetype:
> {noformat}
> Results in the following:
> {noformat}
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-archetype-plugin:3.0.1:generate' with basic
> configurator -->
> [DEBUG] (f) archetypeCatalog = remote
> [DEBUG] (f) basedir = C:\Users\joao.cabrita\projects\bpm
> [DEBUG] (f) filter = org.camunda.bpm.archetype:
> [DEBUG] (f) interactiveMode = true
> [DEBUG] (f) localRepository = id: local
> url: file:///C:/Users/joao.cabrita/.m2/repository/
>layout: default
> snapshots: [enabled => true, update => always]
> releases: [enabled => true, update => always]
> [DEBUG] (f) remoteArtifactRepositories = [ id: central
> url: https://app.camunda.com/nexus/content/repositories/camunda-bpm
>layout: default
> proxy: proxy.brisa.pt:3128
> snapshots: [enabled => true, update => daily]
> releases: [enabled => true, update => daily]
> , id: archetype
> url: https://app.camunda.com/nexus/content/repositories/camunda-bpm
>layout: default
> proxy: proxy.brisa.pt:3128
> snapshots: [enabled => true, update => daily]
> releases: [enabled => true, update => daily]
> ]
> [DEBUG] (f) session = org.apache.maven.execution.MavenSession@325f7fa9
> [DEBUG] -- end configuration --
> [INFO] Generating project in Interactive mode
> [DEBUG] Searching for remote catalog:
> https://repo.maven.apache.org/maven2/archetype-catalog.xml
> [WARNING] No archetype found in remote catalog. Defaulting to internal catalog
> [INFO] Your filter doesn't match any archetype, so try again with another
> value.
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {noformat}
> I've attached my settings.xml file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6399) Lift JDK minimum to JDK 8
[ https://issues.apache.org/jira/browse/MNG-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16660855#comment-16660855 ] Karl Heinz Marbaise commented on MNG-6399: -- The problem is simply that you can't really solve the problem in deploy plugin...There are several problems. Not only one. One is solvable [by an extension|https://github.com/khmarbaise/maven-deployer-extension] and the other is based on the problems in code for resolver (If I correctly understand that)...The deploy plugin problem has nothing to do with JDK 8 or not ... > Lift JDK minimum to JDK 8 > - > > Key: MNG-6399 > URL: https://issues.apache.org/jira/browse/MNG-6399 > Project: Maven > Issue Type: Task >Affects Versions: 3.6.0 >Reporter: Karl Heinz Marbaise >Priority: Critical > Fix For: 3.6.x-candidate > > > I would like to lift the minimum of Maven Core to JDK 8 (I think it's time).. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6399) Lift JDK minimum to JDK 8
[ https://issues.apache.org/jira/browse/MNG-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16660751#comment-16660751 ] Matt Nelson commented on MNG-6399: -- I was experimenting with the deploy plugin which I would not be in control of uplifting the baseline. This is under the assumption that the core plugins can not uplift the minimums before core. [https://github.com/mattnelson/maven-deploy-plugin/commit/fef2a4db1e30cfbf81a414317f5a678f1df3e84f] https://issues.apache.org/jira/browse/MDEPLOY-206 > Lift JDK minimum to JDK 8 > - > > Key: MNG-6399 > URL: https://issues.apache.org/jira/browse/MNG-6399 > Project: Maven > Issue Type: Task >Affects Versions: 3.6.0 >Reporter: Karl Heinz Marbaise >Priority: Critical > Fix For: 3.6.x-candidate > > > I would like to lift the minimum of Maven Core to JDK 8 (I think it's time).. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MJAR-258) Build fails on test-jar
[ https://issues.apache.org/jira/browse/MJAR-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MJAR-258. Resolution: Not A Problem Done as requested by reporter. > Build fails on test-jar > --- > > Key: MJAR-258 > URL: https://issues.apache.org/jira/browse/MJAR-258 > Project: Maven JAR Plugin > Issue Type: New Feature >Reporter: Antoine Duprat >Priority: Major > > The build fails sometimes on test-jars dependencies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAR-258) Build fails on test-jar
[ https://issues.apache.org/jira/browse/MJAR-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16660656#comment-16660656 ] Antoine Duprat commented on MJAR-258: - Sorry for the noise, wrong project... Can someone with enough rights close/delete this issue. > Build fails on test-jar > --- > > Key: MJAR-258 > URL: https://issues.apache.org/jira/browse/MJAR-258 > Project: Maven JAR Plugin > Issue Type: New Feature >Reporter: Antoine Duprat >Priority: Major > > The build fails sometimes on test-jars dependencies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MJAR-258) Build fails on test-jar
Antoine Duprat created MJAR-258: --- Summary: Build fails on test-jar Key: MJAR-258 URL: https://issues.apache.org/jira/browse/MJAR-258 Project: Maven JAR Plugin Issue Type: New Feature Reporter: Antoine Duprat The build fails sometimes on test-jars dependencies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MRAR-30) Filtering of RA.xml
[
https://issues.apache.org/jira/browse/MRAR-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16660418#comment-16660418
]
M G commented on MRAR-30:
-
The issue still exists in 2.4 version. It's not possible to filter {{ra.xml}}
file.
> Filtering of RA.xml
> ---
>
> Key: MRAR-30
> URL: https://issues.apache.org/jira/browse/MRAR-30
> Project: Maven Rar Plugin
> Issue Type: New Feature
>Affects Versions: 2.2
> Environment: Win7 64Bit JDK1.6.0_26
>Reporter: Markus Karg
>Priority: Minor
> Attachments: MRAR-30-maven-rar-plugin.patch
>
>
> It would be great if one could specify true in the
> pom.xml to make the RAR plugin filter the custom RA.xml file provided in src.
> Using this feature, one could put ${project.version} into the custom RA.xml's
> section.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6399) Lift JDK minimum to JDK 8
[ https://issues.apache.org/jira/browse/MNG-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16660337#comment-16660337 ] Michael Osipov commented on MNG-6399: - [~MattNelson], no one hinders you to raise the baseline for your plugin. It is decoupled from Maven Core. > Lift JDK minimum to JDK 8 > - > > Key: MNG-6399 > URL: https://issues.apache.org/jira/browse/MNG-6399 > Project: Maven > Issue Type: Task >Affects Versions: 3.6.0 >Reporter: Karl Heinz Marbaise >Priority: Critical > Fix For: 3.6.x-candidate > > > I would like to lift the minimum of Maven Core to JDK 8 (I think it's time).. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
