[jira] [Commented] (SUREFIRE-1330) JUnit 5 surefire-provider code donation
[ https://issues.apache.org/jira/browse/SUREFIRE-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16474813#comment-16474813 ] Christian Stein commented on SUREFIRE-1330: --- Added initial documentation for the JUnit Platform. > JUnit 5 surefire-provider code donation > --- > > Key: SUREFIRE-1330 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1330 > Project: Maven Surefire > Issue Type: New Feature >Reporter: Benedikt Ritter >Assignee: Tibor Digana >Priority: Major > Labels: junit5 > Fix For: 2.22.0 > > Attachments: junit-platform-surefire-provider.zip > > > The JUnit team wishes to contribute their surefire provider implementation > for JUnit 5 to the Maven team. > The code is currently located at GitHub: > https://github.com/junit-team/junit5/tree/master/junit-platform-surefire-provider > They have recently relicensed the code under terms of Apache License 2.0: > https://github.com/junit-team/junit5/issues/541 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (SUREFIRE-1330) JUnit 5 surefire-provider code donation
[ https://issues.apache.org/jira/browse/SUREFIRE-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16474813#comment-16474813 ] Christian Stein edited comment on SUREFIRE-1330 at 5/14/18 9:18 PM: Added initial documentation for the JUnit Platform Surefire Provider. was (Author: sor): Added initial documentation for the JUnit Platform. > JUnit 5 surefire-provider code donation > --- > > Key: SUREFIRE-1330 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1330 > Project: Maven Surefire > Issue Type: New Feature >Reporter: Benedikt Ritter >Assignee: Tibor Digana >Priority: Major > Labels: junit5 > Fix For: 2.22.0 > > Attachments: junit-platform-surefire-provider.zip > > > The JUnit team wishes to contribute their surefire provider implementation > for JUnit 5 to the Maven team. > The code is currently located at GitHub: > https://github.com/junit-team/junit5/tree/master/junit-platform-surefire-provider > They have recently relicensed the code under terms of Apache License 2.0: > https://github.com/junit-team/junit5/issues/541 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCM-714) mvn release:prepare fails if the command line is too long on windows
[ https://issues.apache.org/jira/browse/SCM-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16474729#comment-16474729 ] ASF GitHub Bot commented on SCM-714: aharui commented on issue #30: Fix for SCM-714: mvn release:prepare fails if the command line is too long on windows URL: https://github.com/apache/maven-scm/pull/30#issuecomment-388942413 Is there an ETA for the release? Are there pre-release builds available we can try? 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 > mvn release:prepare fails if the command line is too long on windows > > > Key: SCM-714 > URL: https://issues.apache.org/jira/browse/SCM-714 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-gitexe >Affects Versions: 1.8.1 >Reporter: Felix Simmendinger >Assignee: Robert Scholte >Priority: Blocker > > The issue from SCM-697 does not solve the issue as the gitprovider is not > using the add command but the checkin command during a release. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] aharui commented on issue #30: Fix for SCM-714: mvn release:prepare fails if the command line is too long on windows
aharui commented on issue #30: Fix for SCM-714: mvn release:prepare fails if the command line is too long on windows URL: https://github.com/apache/maven-scm/pull/30#issuecomment-388942413 Is there an ETA for the release? Are there pre-release builds available we can try? 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] (SCM-868) gitexe add() does not return added files when invoked in subdir
[
https://issues.apache.org/jira/browse/SCM-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16474598#comment-16474598
]
Ilya Basin edited comment on SCM-868 at 5/14/18 6:45 PM:
-
[~michael-o] Done.
I modified GitCheckInCommandNoBranchTest to demonstrate the problem. The system
property "scm.test.tmpdir" now alters the test directory location. Default is
"target/".
Please checkout my branch, do "mvn install -Dmaven.test.skip", change dir to
{code}
maven-scm-providers\maven-scm-providers-git\maven-scm-provider-gitexe{code}
and run:
{code}
mvn test -Dtest="GitCheckInCommandNoBranchTest#testCheckinNoBranch"
-Dscm.test.tmpdir=D:\
{code}
It should succeed. Then revert the last commit (my fix) and repeat. Given that
your source tree is not on "D:\", It should fail with:
{code:java}
GitCheckInCommandNoBranchTest.testCheckinNoBranch:76 expected:<1> but was:<0>
{code}
was (Author: basinilya):
[~michael-o] Done.
I modified GitCheckInCommandNoBranchTest to demonstrate the problem. The system
property "scm.test.tmpdir" now alters the test directory location. Default is
"target/".
Please checkout my branch, do "mvn install", change dir to
{code}
maven-scm-providers\maven-scm-providers-git\maven-scm-provider-gitexe{code}
and run:
{code}
mvn test -Dtest="GitCheckInCommandNoBranchTest#testCheckinNoBranch"
-Dscm.test.tmpdir=D:\
{code}
It should succeed. Then revert the last commit (my fix) and repeat. Given that
your source tree is not on "D:\", It should fail with:
{code:java}
GitCheckInCommandNoBranchTest.testCheckinNoBranch:76 expected:<1> but was:<0>
{code}
> gitexe add() does not return added files when invoked in subdir
> ---
>
> Key: SCM-868
> URL: https://issues.apache.org/jira/browse/SCM-868
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5, 1.9.6
>Reporter: Ilya Basin
>Priority: Major
>
> I'm going to add a wagon-scm test suite for git. One of the test cases is
> calling the GitAddCommand command with:
> {code:java}
> repo:
> file:///C:/progs/maven/maven-wagon/wagon-providers/wagon-scm/target/test-classes/test-repo-git-test/
> fileSet: basedir =
> C:\Users\basin\AppData\Local\Temp\wagon-scm2020146470.checkout\file-list;
> files = [test-resource.txt]{code}
> After adding the files the command internally calls "git rev-parse
> --show-toplevel" which prints:
> {code:java}
> C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout{code}
> And on the next line it tries to do (pseudo code):
> {code:java}
> ("file:/C:/Users/basin/AppData/Local/Temp/wagon-scm1144102340.checkout/file-list/").relativize(URI.create(
> "C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout")){code}
> This is so wrong! What were those people from SCM-709 trying to get? A double
> dot ".."? The argument to the relativize() method MUST be a child, not a
> parent, otherwise the argument is returned unchanged.
> There are so many reasons why getting an absolute path from git is a bad
> idea: Symlinks, Windows paths.
> Nevertheless, there's a simple solution. The original problem was that "git
> status --porcelain" printed paths relative to the top level instead of
> relative to the base dir.
> So we should just call
> {code}
> git rev-parse --show-prefix
> {code} instead of "show-toplevel" and strip this prefix from the paths
> printed by "git status"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SCM-868) gitexe add() does not return added files when invoked in subdir
[
https://issues.apache.org/jira/browse/SCM-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16474598#comment-16474598
]
Ilya Basin edited comment on SCM-868 at 5/14/18 6:44 PM:
-
[~michael-o] Done.
I modified GitCheckInCommandNoBranchTest to demonstrate the problem. The system
property "scm.test.tmpdir" now alters the test directory location. Default is
"target/".
Please checkout my branch, do "mvn install", change dir to
{code}
maven-scm-providers\maven-scm-providers-git\maven-scm-provider-gitexe{code}
and run:
{code}
mvn test -Dtest="GitCheckInCommandNoBranchTest#testCheckinNoBranch"
-Dscm.test.tmpdir=D:\
{code}
It should succeed. Then revert the last commit (my fix) and repeat. Given that
your source tree is not on "D:\", It should fail with:
{code:java}
GitCheckInCommandNoBranchTest.testCheckinNoBranch:76 expected:<1> but was:<0>
{code}
was (Author: basinilya):
[~michael-o] Done.
I modified GitCheckInCommandNoBranchTest to demonstrate the problem. The system
property "scm.test.tmpdir" now alters the test directory location. Default is
"target/".
Please checkout my branch, change dir to
{code}
maven-scm-providers\maven-scm-providers-git\maven-scm-provider-gitexe{code}
and run:
{code}
mvn test -Dtest="GitCheckInCommandNoBranchTest#testCheckinNoBranch"
-Dscm.test.tmpdir=D:\
{code}
It should succeed. Then revert the last commit (my fix) and repeat. Given that
your source tree is not on "D:\", It should fail with:
{code:java}
GitCheckInCommandNoBranchTest.testCheckinNoBranch:76 expected:<1> but was:<0>
{code}
> gitexe add() does not return added files when invoked in subdir
> ---
>
> Key: SCM-868
> URL: https://issues.apache.org/jira/browse/SCM-868
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5, 1.9.6
>Reporter: Ilya Basin
>Priority: Major
>
> I'm going to add a wagon-scm test suite for git. One of the test cases is
> calling the GitAddCommand command with:
> {code:java}
> repo:
> file:///C:/progs/maven/maven-wagon/wagon-providers/wagon-scm/target/test-classes/test-repo-git-test/
> fileSet: basedir =
> C:\Users\basin\AppData\Local\Temp\wagon-scm2020146470.checkout\file-list;
> files = [test-resource.txt]{code}
> After adding the files the command internally calls "git rev-parse
> --show-toplevel" which prints:
> {code:java}
> C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout{code}
> And on the next line it tries to do (pseudo code):
> {code:java}
> ("file:/C:/Users/basin/AppData/Local/Temp/wagon-scm1144102340.checkout/file-list/").relativize(URI.create(
> "C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout")){code}
> This is so wrong! What were those people from SCM-709 trying to get? A double
> dot ".."? The argument to the relativize() method MUST be a child, not a
> parent, otherwise the argument is returned unchanged.
> There are so many reasons why getting an absolute path from git is a bad
> idea: Symlinks, Windows paths.
> Nevertheless, there's a simple solution. The original problem was that "git
> status --porcelain" printed paths relative to the top level instead of
> relative to the base dir.
> So we should just call
> {code}
> git rev-parse --show-prefix
> {code} instead of "show-toplevel" and strip this prefix from the paths
> printed by "git status"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SCM-868) gitexe add() does not return added files when invoked in subdir
[
https://issues.apache.org/jira/browse/SCM-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16474598#comment-16474598
]
Ilya Basin edited comment on SCM-868 at 5/14/18 6:43 PM:
-
[~michael-o] Done.
I modified GitCheckInCommandNoBranchTest to demonstrate the problem. The system
property "scm.test.tmpdir" now alters the test directory location. Default is
"target/".
Please checkout my branch, change dir to
{code}
maven-scm-providers\maven-scm-providers-git\maven-scm-provider-gitexe{code}
and run:
{code}
mvn test -Dtest="GitCheckInCommandNoBranchTest#testCheckinNoBranch"
-Dscm.test.tmpdir=D:\
{code}
It should succeed. Then revert the last commit (my fix) and repeat. Given that
your source tree is not on "D:\", It should fail with:
{code:java}
GitCheckInCommandNoBranchTest.testCheckinNoBranch:76 expected:<1> but was:<0>
{code}
was (Author: basinilya):
[~michael-o] Done.
I modified GitCheckInCommandNoBranchTest to demonstrate the problem. The system
property "scm.test.tmpdir" now alters the test directory location. Default is
"target/".
Please checkout my branch and run:
{code:java}
mvn test -Dtest="GitCheckInCommandNoBranchTest#testCheckinNoBranch"
-Dscm.test.tmpdir=D:\
{code}
It should succeed. Then revert the last commit (my fix) and repeat. Given that
your source tree is not on "D:\", It should fail with:
{code:java}
GitCheckInCommandNoBranchTest.testCheckinNoBranch:76 expected:<1> but was:<0>
{code}
> gitexe add() does not return added files when invoked in subdir
> ---
>
> Key: SCM-868
> URL: https://issues.apache.org/jira/browse/SCM-868
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5, 1.9.6
>Reporter: Ilya Basin
>Priority: Major
>
> I'm going to add a wagon-scm test suite for git. One of the test cases is
> calling the GitAddCommand command with:
> {code:java}
> repo:
> file:///C:/progs/maven/maven-wagon/wagon-providers/wagon-scm/target/test-classes/test-repo-git-test/
> fileSet: basedir =
> C:\Users\basin\AppData\Local\Temp\wagon-scm2020146470.checkout\file-list;
> files = [test-resource.txt]{code}
> After adding the files the command internally calls "git rev-parse
> --show-toplevel" which prints:
> {code:java}
> C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout{code}
> And on the next line it tries to do (pseudo code):
> {code:java}
> ("file:/C:/Users/basin/AppData/Local/Temp/wagon-scm1144102340.checkout/file-list/").relativize(URI.create(
> "C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout")){code}
> This is so wrong! What were those people from SCM-709 trying to get? A double
> dot ".."? The argument to the relativize() method MUST be a child, not a
> parent, otherwise the argument is returned unchanged.
> There are so many reasons why getting an absolute path from git is a bad
> idea: Symlinks, Windows paths.
> Nevertheless, there's a simple solution. The original problem was that "git
> status --porcelain" printed paths relative to the top level instead of
> relative to the base dir.
> So we should just call
> {code}
> git rev-parse --show-prefix
> {code} instead of "show-toplevel" and strip this prefix from the paths
> printed by "git status"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6405) Incorrect basedir in forked executions when using flatten-maven-plugin with custom outputDirectory
[
https://issues.apache.org/jira/browse/MNG-6405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16474611#comment-16474611
]
Jesse Glick commented on MNG-6405:
--
If you are using both {{flatten-maven-plugin}} and {{maven-release-plugin}},
_and_ any plugins which rely on the basedir (such as
{{frontend-maven-plugin}}), you may need to override the (poor?) choice in the
superpom:
{code:xml}
fix-superpom-source-fork
performRelease
true
maven-source-plugin
attach-sources
DO-NOT-ACTUALLY-RUN
attach-sources-no-fork
jar-no-fork
{code}
YMMV.
> Incorrect basedir in forked executions when using flatten-maven-plugin with
> custom outputDirectory
> --
>
> Key: MNG-6405
> URL: https://issues.apache.org/jira/browse/MNG-6405
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.3
>Reporter: Jesse Glick
>Priority: Major
>
> For [JENKINS-51247|https://issues.jenkins-ci.org/browse/JENKINS-51247] I am
> trying to use a variant of the tip shown
> [here|https://github.com/mojohaus/flatten-maven-plugin/issues/53#issuecomment-340366191]:
> using {{flatten-maven-plugin}} with a generated POM file in the {{target}}
> directory. This works fine in almost all cases, since the plugin calls
> {{MavenProject.setPomFile}}, which leaves the {{basedir}} untouched.
> Unfortunately it fails for mojos which rely on the basedir that are run
> inside a forked execution, as I found when accidentally using {{source:jar}}
> when {{source:jar-no-fork}} was what I wanted. (Ditto when using
> {{findbugs:check}}.) This seems to be because {{deepCopy}} still calls
> {{setFile}}, so the basedir of a cloned project is not the same as the
> original—it is always the parent directory of the POM file.
> Fixing this should be trivial
> {code}
> diff --git
> a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> index 80a51935e..ee7a68635 100644
> --- a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> +++ b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> @@ -1207,7 +1207,8 @@ private void deepCopy( MavenProject project )
> // disown the parent
>
> // copy fields
> -setFile( project.getFile() );
> +file = project.file;
> +basedir = project.basedir;
>
> // don't need a deep copy, they don't get modified or added/removed
> to/from - but make them unmodifiable to be
> // sure!
> {code}
> but I am unsure what the best approach is to validate the fix. A unit test in
> {{MavenProjectTest}}? An IT which calls {{flatten-maven-plugin}},
> {{source:jar}}, and some other mojo TBD which is sensitive to project
> basedir? Both?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SCM-868) gitexe add() does not return added files when invoked in subdir
[
https://issues.apache.org/jira/browse/SCM-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16474598#comment-16474598
]
Ilya Basin edited comment on SCM-868 at 5/14/18 6:39 PM:
-
[~michael-o] Done.
I modified GitCheckInCommandNoBranchTest to demonstrate the problem. The system
property "scm.test.tmpdir" now alters the test directory location. Default is
"target/".
Please checkout my branch and run:
{code:java}
mvn test -Dtest="GitCheckInCommandNoBranchTest#testCheckinNoBranch"
-Dscm.test.tmpdir=D:\
{code}
It should succeed. Then revert the last commit (my fix) and repeat. Given that
your source tree is not on "D:\", It should fail with:
{code:java}
GitCheckInCommandNoBranchTest.testCheckinNoBranch:76 expected:<1> but was:<0>
{code}
was (Author: basinilya):
[~michael-o] Done.
I modified GitCheckInCommandNoBranchTest to demonstrate the problem. The system
property "scm.test.tmpdir" now alters the test directory location. Default is
"target/".
Please checkout my branch and run:
{code:java}
mvn test -Dtest="GitCheckInCommandNoBranchTest#testCheckinNoBranch"
-Dscm.test.tmpdir=D:\
{code}
It should succeed. Then revert the last commit (my fix) and repeat. It should
fail with:
{code}
GitCheckInCommandNoBranchTest.testCheckinNoBranch:76 expected:<1> but was:<0>
{code}
> gitexe add() does not return added files when invoked in subdir
> ---
>
> Key: SCM-868
> URL: https://issues.apache.org/jira/browse/SCM-868
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5, 1.9.6
>Reporter: Ilya Basin
>Priority: Major
>
> I'm going to add a wagon-scm test suite for git. One of the test cases is
> calling the GitAddCommand command with:
> {code:java}
> repo:
> file:///C:/progs/maven/maven-wagon/wagon-providers/wagon-scm/target/test-classes/test-repo-git-test/
> fileSet: basedir =
> C:\Users\basin\AppData\Local\Temp\wagon-scm2020146470.checkout\file-list;
> files = [test-resource.txt]{code}
> After adding the files the command internally calls "git rev-parse
> --show-toplevel" which prints:
> {code:java}
> C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout{code}
> And on the next line it tries to do (pseudo code):
> {code:java}
> ("file:/C:/Users/basin/AppData/Local/Temp/wagon-scm1144102340.checkout/file-list/").relativize(URI.create(
> "C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout")){code}
> This is so wrong! What were those people from SCM-709 trying to get? A double
> dot ".."? The argument to the relativize() method MUST be a child, not a
> parent, otherwise the argument is returned unchanged.
> There are so many reasons why getting an absolute path from git is a bad
> idea: Symlinks, Windows paths.
> Nevertheless, there's a simple solution. The original problem was that "git
> status --porcelain" printed paths relative to the top level instead of
> relative to the base dir.
> So we should just call
> {code}
> git rev-parse --show-prefix
> {code} instead of "show-toplevel" and strip this prefix from the paths
> printed by "git status"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SCM-868) gitexe add() does not return added files when invoked in subdir
[
https://issues.apache.org/jira/browse/SCM-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16474598#comment-16474598
]
Ilya Basin edited comment on SCM-868 at 5/14/18 6:37 PM:
-
[~michael-o] Done.
I modified GitCheckInCommandNoBranchTest to demonstrate the problem. The system
property "scm.test.tmpdir" now alters the test directory location. Default is
"target/".
Please checkout my branch and run:
{code:java}
mvn test -Dtest="GitCheckInCommandNoBranchTest#testCheckinNoBranch"
-Dscm.test.tmpdir=D:\
{code}
It should succeed. Then revert the last commit (my fix) and repeat. It should
fail with:
{code}
GitCheckInCommandNoBranchTest.testCheckinNoBranch:76 expected:<1> but was:<0>
{code}
was (Author: basinilya):
[~michael-o] Done.
I modified GitCheckInCommandNoBranchTest to demonstrate the problem. The system
property "scm.test.tmpdir" now alters the test directory location. Default is
"target/".
Please checkout my branch and run:
{code:java}
mvn test -Dtest="GitCheckInCommandNoBranchTest#testCheckinNoBranch"
-Dscm.test.tmpdir=D:\{code}
It should succeed. Then revert the last commit (my fix) and repeat. It should
fail with:
{code:java}
GitCheckInCommandNoBranchTest.testCheckinNoBranch:76 expected:<1> but
was:<0>{code}
> gitexe add() does not return added files when invoked in subdir
> ---
>
> Key: SCM-868
> URL: https://issues.apache.org/jira/browse/SCM-868
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5, 1.9.6
>Reporter: Ilya Basin
>Priority: Major
>
> I'm going to add a wagon-scm test suite for git. One of the test cases is
> calling the GitAddCommand command with:
> {code:java}
> repo:
> file:///C:/progs/maven/maven-wagon/wagon-providers/wagon-scm/target/test-classes/test-repo-git-test/
> fileSet: basedir =
> C:\Users\basin\AppData\Local\Temp\wagon-scm2020146470.checkout\file-list;
> files = [test-resource.txt]{code}
> After adding the files the command internally calls "git rev-parse
> --show-toplevel" which prints:
> {code:java}
> C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout{code}
> And on the next line it tries to do (pseudo code):
> {code:java}
> ("file:/C:/Users/basin/AppData/Local/Temp/wagon-scm1144102340.checkout/file-list/").relativize(URI.create(
> "C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout")){code}
> This is so wrong! What were those people from SCM-709 trying to get? A double
> dot ".."? The argument to the relativize() method MUST be a child, not a
> parent, otherwise the argument is returned unchanged.
> There are so many reasons why getting an absolute path from git is a bad
> idea: Symlinks, Windows paths.
> Nevertheless, there's a simple solution. The original problem was that "git
> status --porcelain" printed paths relative to the top level instead of
> relative to the base dir.
> So we should just call
> {code}
> git rev-parse --show-prefix
> {code} instead of "show-toplevel" and strip this prefix from the paths
> printed by "git status"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCM-868) gitexe add() does not return added files when invoked in subdir
[
https://issues.apache.org/jira/browse/SCM-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16474598#comment-16474598
]
Ilya Basin commented on SCM-868:
[~michael-o] Done.
I modified GitCheckInCommandNoBranchTest to demonstrate the problem. The system
property "scm.test.tmpdir" now alters the test directory location. Default is
"target/".
Please checkout my branch and run:
{code:java}
mvn test -Dtest="GitCheckInCommandNoBranchTest#testCheckinNoBranch"
-Dscm.test.tmpdir=D:\{code}
It should succeed. Then revert the last commit (my fix) and repeat. It should
fail with:
{code:java}
GitCheckInCommandNoBranchTest.testCheckinNoBranch:76 expected:<1> but
was:<0>{code}
> gitexe add() does not return added files when invoked in subdir
> ---
>
> Key: SCM-868
> URL: https://issues.apache.org/jira/browse/SCM-868
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5, 1.9.6
>Reporter: Ilya Basin
>Priority: Major
>
> I'm going to add a wagon-scm test suite for git. One of the test cases is
> calling the GitAddCommand command with:
> {code:java}
> repo:
> file:///C:/progs/maven/maven-wagon/wagon-providers/wagon-scm/target/test-classes/test-repo-git-test/
> fileSet: basedir =
> C:\Users\basin\AppData\Local\Temp\wagon-scm2020146470.checkout\file-list;
> files = [test-resource.txt]{code}
> After adding the files the command internally calls "git rev-parse
> --show-toplevel" which prints:
> {code:java}
> C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout{code}
> And on the next line it tries to do (pseudo code):
> {code:java}
> ("file:/C:/Users/basin/AppData/Local/Temp/wagon-scm1144102340.checkout/file-list/").relativize(URI.create(
> "C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout")){code}
> This is so wrong! What were those people from SCM-709 trying to get? A double
> dot ".."? The argument to the relativize() method MUST be a child, not a
> parent, otherwise the argument is returned unchanged.
> There are so many reasons why getting an absolute path from git is a bad
> idea: Symlinks, Windows paths.
> Nevertheless, there's a simple solution. The original problem was that "git
> status --porcelain" printed paths relative to the top level instead of
> relative to the base dir.
> So we should just call
> {code}
> git rev-parse --show-prefix
> {code} instead of "show-toplevel" and strip this prefix from the paths
> printed by "git status"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCM-714) mvn release:prepare fails if the command line is too long on windows
[
https://issues.apache.org/jira/browse/SCM-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16474481#comment-16474481
]
ASF GitHub Bot commented on SCM-714:
McLuck closed pull request #41: SCM-714 fix git commit when command line got
too long
URL: https://github.com/apache/maven-scm/pull/41
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/GitCommandLineUtils.java
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/GitCommandLineUtils.java
index 2599273d9..9ffd69d0b 100644
---
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/GitCommandLineUtils.java
+++
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/GitCommandLineUtils.java
@@ -29,6 +29,7 @@
import java.io.File;
import java.io.IOException;
import java.util.List;
+import java.util.Set;
/**
* Command line construction utility.
@@ -80,6 +81,29 @@ public static void addTarget( Commandline cl, List
files )
+ workingDirectory + " or files=" + files, ex );
}
}
+
+/**
+ *
+ * @param cl
+ * @param files
+ */
+public static void addTargetPattern( Commandline cl, List files )
+{
+if ( files == null || files.isEmpty() )
+{
+return;
+}
+Set fileToAdd = new java.util.HashSet();
+
+for ( File file : files )
+{
+fileToAdd.add( file.getName() );
+}
+for ( String patternFile : fileToAdd )
+{
+cl.createArg().setValue( "*" + patternFile );
+}
+}
/**
*
diff --git
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/add/GitAddCommand.java
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/add/GitAddCommand.java
index 21ad47607..37980e538 100644
---
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/add/GitAddCommand.java
+++
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/add/GitAddCommand.java
@@ -19,6 +19,12 @@
* under the License.
*/
+import java.io.File;
+import java.net.URI;
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.List;
+
import org.apache.commons.io.FilenameUtils;
import org.apache.maven.scm.ScmException;
import org.apache.maven.scm.ScmFile;
@@ -36,12 +42,6 @@
import org.codehaus.plexus.util.cli.CommandLineUtils;
import org.codehaus.plexus.util.cli.Commandline;
-import java.io.File;
-import java.net.URI;
-import java.util.ArrayList;
-import java.util.Collections;
-import java.util.List;
-
/**
* @author mailto:strub...@yahoo.de;>Mark Struberg
*/
@@ -139,12 +139,11 @@ public static Commandline createCommandLine( File
workingDirectory, List f
// use this separator to make clear that the following parameters are
files and not revision info.
cl.createArg().setValue( "--" );
-
-GitCommandLineUtils.addTarget( cl, files );
+GitCommandLineUtils.addTargetPattern( cl, files );
return cl;
}
-
+
private AddScmResult executeAddFileSet( ScmFileSet fileSet )
throws ScmException
{
diff --git
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/checkin/GitCheckInCommand.java
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/checkin/GitCheckInCommand.java
index e30aae0c3..42c471880 100644
---
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/checkin/GitCheckInCommand.java
+++
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/checkin/GitCheckInCommand.java
@@ -251,7 +251,7 @@ public static Commandline createCommitCommandLine(
GitScmProviderRepository repo
else
{
// specify exactly which files to commit
-GitCommandLineUtils.addTarget( cl,
[GitHub] McLuck closed pull request #41: SCM-714 fix git commit when command line got too long
McLuck closed pull request #41: SCM-714 fix git commit when command line got
too long
URL: https://github.com/apache/maven-scm/pull/41
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/GitCommandLineUtils.java
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/GitCommandLineUtils.java
index 2599273d9..9ffd69d0b 100644
---
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/GitCommandLineUtils.java
+++
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/GitCommandLineUtils.java
@@ -29,6 +29,7 @@
import java.io.File;
import java.io.IOException;
import java.util.List;
+import java.util.Set;
/**
* Command line construction utility.
@@ -80,6 +81,29 @@ public static void addTarget( Commandline cl, List
files )
+ workingDirectory + " or files=" + files, ex );
}
}
+
+/**
+ *
+ * @param cl
+ * @param files
+ */
+public static void addTargetPattern( Commandline cl, List files )
+{
+if ( files == null || files.isEmpty() )
+{
+return;
+}
+Set fileToAdd = new java.util.HashSet();
+
+for ( File file : files )
+{
+fileToAdd.add( file.getName() );
+}
+for ( String patternFile : fileToAdd )
+{
+cl.createArg().setValue( "*" + patternFile );
+}
+}
/**
*
diff --git
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/add/GitAddCommand.java
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/add/GitAddCommand.java
index 21ad47607..37980e538 100644
---
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/add/GitAddCommand.java
+++
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/add/GitAddCommand.java
@@ -19,6 +19,12 @@
* under the License.
*/
+import java.io.File;
+import java.net.URI;
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.List;
+
import org.apache.commons.io.FilenameUtils;
import org.apache.maven.scm.ScmException;
import org.apache.maven.scm.ScmFile;
@@ -36,12 +42,6 @@
import org.codehaus.plexus.util.cli.CommandLineUtils;
import org.codehaus.plexus.util.cli.Commandline;
-import java.io.File;
-import java.net.URI;
-import java.util.ArrayList;
-import java.util.Collections;
-import java.util.List;
-
/**
* @author mailto:strub...@yahoo.de;>Mark Struberg
*/
@@ -139,12 +139,11 @@ public static Commandline createCommandLine( File
workingDirectory, List f
// use this separator to make clear that the following parameters are
files and not revision info.
cl.createArg().setValue( "--" );
-
-GitCommandLineUtils.addTarget( cl, files );
+GitCommandLineUtils.addTargetPattern( cl, files );
return cl;
}
-
+
private AddScmResult executeAddFileSet( ScmFileSet fileSet )
throws ScmException
{
diff --git
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/checkin/GitCheckInCommand.java
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/checkin/GitCheckInCommand.java
index e30aae0c3..42c471880 100644
---
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/checkin/GitCheckInCommand.java
+++
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/checkin/GitCheckInCommand.java
@@ -251,7 +251,7 @@ public static Commandline createCommitCommandLine(
GitScmProviderRepository repo
else
{
// specify exactly which files to commit
-GitCommandLineUtils.addTarget( cl, fileSet.getFileList() );
+GitCommandLineUtils.addTargetPattern( cl, fileSet.getFileList() );
}
if ( GitUtil.getSettings().isCommitNoVerify() )
[GitHub] Tibor17 commented on issue #112: Adding support for externally passed random seed and printing used seed on console
Tibor17 commented on issue #112: Adding support for externally passed random seed and printing used seed on console URL: https://github.com/apache/maven-surefire/pull/112#issuecomment-388873766 @joekienzle I need to read all this through after 2 years. @cardil Can you meanwhile rebase on master and resolve the git conflicts? Thx. 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] [Commented] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set
[
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16474286#comment-16474286
]
Matthieu Brouillard commented on SCM-885:
-
[~michael-o] I have provided another PR that keeps the git exe impl backward
compatible. But then it is the jgit one that I had to modify. see
https://github.com/apache/maven-scm/pull/72
> GitChangeLogCommand is wrong when only endVersion is set
>
>
> Key: SCM-885
> URL: https://issues.apache.org/jira/browse/SCM-885
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5
>Reporter: Matthieu Brouillard
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: scm-885-different-behavior-exe-jgit-patch.diff
>
>
> Invoking execution of a GitChangeLogCommand where only the end revision has
> been set produces a wrong out.
> +Actual result:+
> {{git whatchanged --date=iso ..END_REVISION_SHA1 -- PROJECT_PATH}}
> +Expected result:+ only the end revison SHA1 is used without the two dots
> {{git whatchanged --date=iso END_REVISION_SHA1 -- PROJECT_PATH}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set
[
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16474283#comment-16474283
]
ASF GitHub Bot commented on SCM-885:
McFoggy opened a new pull request #72: [SCM-885] second implementation with new
API
URL: https://github.com/apache/maven-scm/pull/72
this PR is a fix for SCM-885 which keeps the git exe implementation backard
compatible but thus introduces a new command parameter: START_FROM_ROOT
the PR also adds several TCK tests and provides corrections of existing
faulty behaviors of the jgit implementation
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
> GitChangeLogCommand is wrong when only endVersion is set
>
>
> Key: SCM-885
> URL: https://issues.apache.org/jira/browse/SCM-885
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5
>Reporter: Matthieu Brouillard
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: scm-885-different-behavior-exe-jgit-patch.diff
>
>
> Invoking execution of a GitChangeLogCommand where only the end revision has
> been set produces a wrong out.
> +Actual result:+
> {{git whatchanged --date=iso ..END_REVISION_SHA1 -- PROJECT_PATH}}
> +Expected result:+ only the end revison SHA1 is used without the two dots
> {{git whatchanged --date=iso END_REVISION_SHA1 -- PROJECT_PATH}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] McFoggy opened a new pull request #72: [SCM-885] second implementation with new API
McFoggy opened a new pull request #72: [SCM-885] second implementation with new API URL: https://github.com/apache/maven-scm/pull/72 this PR is a fix for SCM-885 which keeps the git exe implementation backard compatible but thus introduces a new command parameter: START_FROM_ROOT the PR also adds several TCK tests and provides corrections of existing faulty behaviors of the jgit implementation 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
[GitHub] joekienzle commented on issue #112: Adding support for externally passed random seed and printing used seed on console
joekienzle commented on issue #112: Adding support for externally passed random seed and printing used seed on console URL: https://github.com/apache/maven-surefire/pull/112#issuecomment-388826070 We would like this feature as well. Please update this pr 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] [Commented] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set
[
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16474197#comment-16474197
]
Matthieu Brouillard commented on SCM-885:
-
Another finding I have just made is that jgit implementation behaves as the PR
does (for the exe implementation), ie without startVersion it walks to the root
commits.
So now where is the truth? Do we consider the exe implementation as the truth
and say that the jgit one is buggy and thus provide a fix that will make the
jgit impl to behave like the git one introducing by that a "regression" or do
we consider the opposite exactly as the PR provides?
If you look at the patch attached and run it against master, then you will see
that the jgit impl passes the tck test whereas the git one does not.
So the question is now where to put the regression, in git impl or in jgit impl?
> GitChangeLogCommand is wrong when only endVersion is set
>
>
> Key: SCM-885
> URL: https://issues.apache.org/jira/browse/SCM-885
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5
>Reporter: Matthieu Brouillard
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: scm-885-different-behavior-exe-jgit-patch.diff
>
>
> Invoking execution of a GitChangeLogCommand where only the end revision has
> been set produces a wrong out.
> +Actual result:+
> {{git whatchanged --date=iso ..END_REVISION_SHA1 -- PROJECT_PATH}}
> +Expected result:+ only the end revison SHA1 is used without the two dots
> {{git whatchanged --date=iso END_REVISION_SHA1 -- PROJECT_PATH}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set
[
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthieu Brouillard updated SCM-885:
Attachment: scm-885-different-behavior-exe-jgit-patch.diff
> GitChangeLogCommand is wrong when only endVersion is set
>
>
> Key: SCM-885
> URL: https://issues.apache.org/jira/browse/SCM-885
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5
>Reporter: Matthieu Brouillard
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: scm-885-different-behavior-exe-jgit-patch.diff
>
>
> Invoking execution of a GitChangeLogCommand where only the end revision has
> been set produces a wrong out.
> +Actual result:+
> {{git whatchanged --date=iso ..END_REVISION_SHA1 -- PROJECT_PATH}}
> +Expected result:+ only the end revison SHA1 is used without the two dots
> {{git whatchanged --date=iso END_REVISION_SHA1 -- PROJECT_PATH}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set
[
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16473869#comment-16473869
]
Matthieu Brouillard commented on SCM-885:
-
[~michael-o] I checked on HG documentation
([https://www.selenic.com/mercurial/hg.1.html#revsets)] and it behaves like I
would have expected ie if you do not have a start revision then it means from
the initial commit. The git defaul behavior looks strange especially when it is
the start revision that is missing.
> GitChangeLogCommand is wrong when only endVersion is set
>
>
> Key: SCM-885
> URL: https://issues.apache.org/jira/browse/SCM-885
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5
>Reporter: Matthieu Brouillard
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Invoking execution of a GitChangeLogCommand where only the end revision has
> been set produces a wrong out.
> +Actual result:+
> {{git whatchanged --date=iso ..END_REVISION_SHA1 -- PROJECT_PATH}}
> +Expected result:+ only the end revison SHA1 is used without the two dots
> {{git whatchanged --date=iso END_REVISION_SHA1 -- PROJECT_PATH}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
