[jira] [Commented] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478564#comment-16478564
 ] 

ASF GitHub Bot commented on SCM-885:


McFoggy commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188845079
 
 

 ##
 File path: 
maven-scm-api/src/main/java/org/apache/maven/scm/CommandParameter.java
 ##
 @@ -50,6 +50,8 @@
 
 public static final CommandParameter BRANCH = new CommandParameter( 
"branch" );
 
+public static final CommandParameter START_FROM_ROOT = new 
CommandParameter( "startFromRoot" );
 
 Review comment:
   also I would then change the method parameter `startFromRoot ` to 
`fromRepositoryStart`


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 commented on a change in pull request #72: [SCM-885] second implementation with new API

[GitBox]

McFoggy commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188845079
 
 

 ##
 File path: 
maven-scm-api/src/main/java/org/apache/maven/scm/CommandParameter.java
 ##
 @@ -50,6 +50,8 @@
 
 public static final CommandParameter BRANCH = new CommandParameter( 
"branch" );
 
+public static final CommandParameter START_FROM_ROOT = new 
CommandParameter( "startFromRoot" );
 
 Review comment:
   also I would then change the method parameter `startFromRoot ` to 
`fromRepositoryStart`


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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478557#comment-16478557
 ] 

ASF GitHub Bot commented on SCM-885:


McFoggy commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188844431
 
 

 ##
 File path: 
maven-scm-api/src/main/java/org/apache/maven/scm/command/changelog/ChangeLogScmRequest.java
 ##
 @@ -130,6 +130,18 @@ public void setEndRevision( ScmVersion endRevision )
 parameters.setScmVersion( CommandParameter.END_SCM_VERSION, 
endRevision );
 }
 
+public boolean getStartFromRoot()
+throws ScmException
 
 Review comment:
   sorry I do not understand this one.


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 commented on a change in pull request #72: [SCM-885] second implementation with new API

[GitBox]

McFoggy commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188844431
 
 

 ##
 File path: 
maven-scm-api/src/main/java/org/apache/maven/scm/command/changelog/ChangeLogScmRequest.java
 ##
 @@ -130,6 +130,18 @@ public void setEndRevision( ScmVersion endRevision )
 parameters.setScmVersion( CommandParameter.END_SCM_VERSION, 
endRevision );
 }
 
+public boolean getStartFromRoot()
+throws ScmException
 
 Review comment:
   sorry I do not understand this one.


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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478548#comment-16478548
 ] 

ASF GitHub Bot commented on SCM-885:


McFoggy commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188843440
 
 

 ##
 File path: 
maven-scm-api/src/main/java/org/apache/maven/scm/CommandParameter.java
 ##
 @@ -50,6 +50,8 @@
 
 public static final CommandParameter BRANCH = new CommandParameter( 
"branch" );
 
+public static final CommandParameter START_FROM_ROOT = new 
CommandParameter( "startFromRoot" );
 
 Review comment:
   What about a rename of this command parameter to : `FROM_REPOSITORY_START`?


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 commented on a change in pull request #72: [SCM-885] second implementation with new API

[GitBox]

McFoggy commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188843440
 
 

 ##
 File path: 
maven-scm-api/src/main/java/org/apache/maven/scm/CommandParameter.java
 ##
 @@ -50,6 +50,8 @@
 
 public static final CommandParameter BRANCH = new CommandParameter( 
"branch" );
 
+public static final CommandParameter START_FROM_ROOT = new 
CommandParameter( "startFromRoot" );
 
 Review comment:
   What about a rename of this command parameter to : `FROM_REPOSITORY_START`?


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-868) gitexe add() does not return added files when invoked in subdir

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478131#comment-16478131
 ] 

ASF GitHub Bot commented on SCM-868:


michael-o commented on a change in pull request #66: [SCM-868] fix gitexe 
cannot deduce relative path
URL: https://github.com/apache/maven-scm/pull/66#discussion_r188777653
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/test/java/org/apache/maven/scm/provider/git/gitexe/command/status/GitStatusConsumerTest.java
 ##
 @@ -187,23 +187,33 @@ public void testConsumerModifiedFile()
 assertEquals("test file with spaces and a special \u007f 
character.xml", changedFiles.get( 0 ).getPath() );
 }
 
+public void testURI()
+throws Exception
+{
+String path = "Not%Scheme:/sub dir";
+URI u = GitStatusConsumer.uriFromPath( path );
+assertEquals( path, u.getPath() );
+}
+
// SCM-740
public void testConsumerModifiedFileInComplexDirectorySetup() throws 
IOException {
 
File dir = createTempDirectory();
-   File subdir = new File( dir.getAbsolutePath() + 
"/subDirectory/" );
+URI relativeCWD = URI.create( "" );
+   File subdir = new File( dir, "subDirectory" );
subdir.mkdir();
FileUtils.write( new File( subdir, "project.xml" ), "data" );
 
-   List changedFiles = getChangedFiles( "M  
subDirectory/project.xml", subdir, dir.toURI() );
+List changedFiles = getChangedFiles( "M  
subDirectory/project.xml", dir, relativeCWD );
 
 Review comment:
   check indentation


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


> 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)

[GitHub] michael-o commented on a change in pull request #66: [SCM-868] fix gitexe cannot deduce relative path

[GitBox]

michael-o commented on a change in pull request #66: [SCM-868] fix gitexe 
cannot deduce relative path
URL: https://github.com/apache/maven-scm/pull/66#discussion_r18879
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/test/java/org/apache/maven/scm/provider/git/gitexe/command/status/GitStatusConsumerTest.java
 ##
 @@ -215,19 +225,23 @@ public void 
testConsumerModifiedFileInComplexDirectorySetup() throws IOException
public void testConsumerModifiedFileInComplexDirectoryWithSpaces() 
throws IOException {
 
File dir = createTempDirectory();
-   File subdir = new File( dir.getAbsolutePath() + "/sub Directory 
déjà vu special/" );
+URI relativeCWD = URI.create( "" );
+   File subdir = new File( dir, "sub Directory déjà vu special" );
subdir.mkdir();
FileUtils.write( new File( subdir, "project.xml" ), "data" );
 
-   List changedFiles = getChangedFiles( "M  \"sub 
Directory déjà vu special/project.xml\"", subdir, dir.toURI() );
+List changedFiles =
+getChangedFiles( "M  \"sub Directory déjà vu 
special/project.xml\"", dir, relativeCWD );
 
assertNotNull( changedFiles );
assertEquals( 1, changedFiles.size() );
 assertEquals( "sub Directory déjà vu special/project.xml", 
changedFiles.get( 0 ).getPath() );
 
 FileUtils.write( new File( subdir, "test file with spaces and a déjà 
vu character.xml" ), "data" );
 
-   changedFiles = getChangedFiles( "M  \"sub Directory déjà vu 
special/test file with spaces and a déjà vu character.xml\"", subdir, 
dir.toURI() );
+changedFiles =
 
 Review comment:
   check indentation


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-868) gitexe add() does not return added files when invoked in subdir

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478135#comment-16478135
 ] 

ASF GitHub Bot commented on SCM-868:


michael-o commented on a change in pull request #66: [SCM-868] fix gitexe 
cannot deduce relative path
URL: https://github.com/apache/maven-scm/pull/66#discussion_r18879
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/test/java/org/apache/maven/scm/provider/git/gitexe/command/status/GitStatusConsumerTest.java
 ##
 @@ -215,19 +225,23 @@ public void 
testConsumerModifiedFileInComplexDirectorySetup() throws IOException
public void testConsumerModifiedFileInComplexDirectoryWithSpaces() 
throws IOException {
 
File dir = createTempDirectory();
-   File subdir = new File( dir.getAbsolutePath() + "/sub Directory 
déjà vu special/" );
+URI relativeCWD = URI.create( "" );
+   File subdir = new File( dir, "sub Directory déjà vu special" );
subdir.mkdir();
FileUtils.write( new File( subdir, "project.xml" ), "data" );
 
-   List changedFiles = getChangedFiles( "M  \"sub 
Directory déjà vu special/project.xml\"", subdir, dir.toURI() );
+List changedFiles =
+getChangedFiles( "M  \"sub Directory déjà vu 
special/project.xml\"", dir, relativeCWD );
 
assertNotNull( changedFiles );
assertEquals( 1, changedFiles.size() );
 assertEquals( "sub Directory déjà vu special/project.xml", 
changedFiles.get( 0 ).getPath() );
 
 FileUtils.write( new File( subdir, "test file with spaces and a déjà 
vu character.xml" ), "data" );
 
-   changedFiles = getChangedFiles( "M  \"sub Directory déjà vu 
special/test file with spaces and a déjà vu character.xml\"", subdir, 
dir.toURI() );
+changedFiles =
 
 Review comment:
   check indentation


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


> 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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478133#comment-16478133
 ] 

ASF GitHub Bot commented on SCM-868:


michael-o commented on a change in pull request #66: [SCM-868] fix gitexe 
cannot deduce relative path
URL: https://github.com/apache/maven-scm/pull/66#discussion_r18827
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/test/java/org/apache/maven/scm/provider/git/gitexe/command/status/GitStatusConsumerTest.java
 ##
 @@ -215,19 +225,23 @@ public void 
testConsumerModifiedFileInComplexDirectorySetup() throws IOException
public void testConsumerModifiedFileInComplexDirectoryWithSpaces() 
throws IOException {
 
File dir = createTempDirectory();
-   File subdir = new File( dir.getAbsolutePath() + "/sub Directory 
déjà vu special/" );
+URI relativeCWD = URI.create( "" );
 
 Review comment:
   check indentation


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


> 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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478132#comment-16478132
 ] 

ASF GitHub Bot commented on SCM-868:


michael-o commented on a change in pull request #66: [SCM-868] fix gitexe 
cannot deduce relative path
URL: https://github.com/apache/maven-scm/pull/66#discussion_r18804
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/test/java/org/apache/maven/scm/provider/git/gitexe/command/status/GitStatusConsumerTest.java
 ##
 @@ -187,23 +187,33 @@ public void testConsumerModifiedFile()
 assertEquals("test file with spaces and a special \u007f 
character.xml", changedFiles.get( 0 ).getPath() );
 }
 
+public void testURI()
+throws Exception
+{
+String path = "Not%Scheme:/sub dir";
+URI u = GitStatusConsumer.uriFromPath( path );
+assertEquals( path, u.getPath() );
+}
+
// SCM-740
public void testConsumerModifiedFileInComplexDirectorySetup() throws 
IOException {
 
File dir = createTempDirectory();
-   File subdir = new File( dir.getAbsolutePath() + 
"/subDirectory/" );
+URI relativeCWD = URI.create( "" );
+   File subdir = new File( dir, "subDirectory" );
subdir.mkdir();
FileUtils.write( new File( subdir, "project.xml" ), "data" );
 
-   List changedFiles = getChangedFiles( "M  
subDirectory/project.xml", subdir, dir.toURI() );
+List changedFiles = getChangedFiles( "M  
subDirectory/project.xml", dir, relativeCWD );
 
assertNotNull( changedFiles );
assertEquals( 1, changedFiles.size() );
 assertEquals( "subDirectory/project.xml", changedFiles.get( 0 
).getPath() );
 
 FileUtils.write( new File( subdir, "test file with spaces and a déjà 
vu character.xml" ), "data" );
 
-   changedFiles = getChangedFiles( "M  \"subDirectory/test file 
with spaces and a déjà vu character.xml\"", subdir, dir.toURI() );
+changedFiles =
 
 Review comment:
   check indentation


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


> 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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478134#comment-16478134
 ] 

ASF GitHub Bot commented on SCM-868:


michael-o commented on a change in pull request #66: [SCM-868] fix gitexe 
cannot deduce relative path
URL: https://github.com/apache/maven-scm/pull/66#discussion_r18845
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/test/java/org/apache/maven/scm/provider/git/gitexe/command/status/GitStatusConsumerTest.java
 ##
 @@ -215,19 +225,23 @@ public void 
testConsumerModifiedFileInComplexDirectorySetup() throws IOException
public void testConsumerModifiedFileInComplexDirectoryWithSpaces() 
throws IOException {
 
File dir = createTempDirectory();
-   File subdir = new File( dir.getAbsolutePath() + "/sub Directory 
déjà vu special/" );
+URI relativeCWD = URI.create( "" );
+   File subdir = new File( dir, "sub Directory déjà vu special" );
subdir.mkdir();
FileUtils.write( new File( subdir, "project.xml" ), "data" );
 
-   List changedFiles = getChangedFiles( "M  \"sub 
Directory déjà vu special/project.xml\"", subdir, dir.toURI() );
+List changedFiles =
 
 Review comment:
   check indentation


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


> 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)

[GitHub] michael-o commented on a change in pull request #66: [SCM-868] fix gitexe cannot deduce relative path

[GitBox]

michael-o commented on a change in pull request #66: [SCM-868] fix gitexe 
cannot deduce relative path
URL: https://github.com/apache/maven-scm/pull/66#discussion_r18845
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/test/java/org/apache/maven/scm/provider/git/gitexe/command/status/GitStatusConsumerTest.java
 ##
 @@ -215,19 +225,23 @@ public void 
testConsumerModifiedFileInComplexDirectorySetup() throws IOException
public void testConsumerModifiedFileInComplexDirectoryWithSpaces() 
throws IOException {
 
File dir = createTempDirectory();
-   File subdir = new File( dir.getAbsolutePath() + "/sub Directory 
déjà vu special/" );
+URI relativeCWD = URI.create( "" );
+   File subdir = new File( dir, "sub Directory déjà vu special" );
subdir.mkdir();
FileUtils.write( new File( subdir, "project.xml" ), "data" );
 
-   List changedFiles = getChangedFiles( "M  \"sub 
Directory déjà vu special/project.xml\"", subdir, dir.toURI() );
+List changedFiles =
 
 Review comment:
   check indentation


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] michael-o commented on a change in pull request #66: [SCM-868] fix gitexe cannot deduce relative path

[GitBox]

michael-o commented on a change in pull request #66: [SCM-868] fix gitexe 
cannot deduce relative path
URL: https://github.com/apache/maven-scm/pull/66#discussion_r18827
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/test/java/org/apache/maven/scm/provider/git/gitexe/command/status/GitStatusConsumerTest.java
 ##
 @@ -215,19 +225,23 @@ public void 
testConsumerModifiedFileInComplexDirectorySetup() throws IOException
public void testConsumerModifiedFileInComplexDirectoryWithSpaces() 
throws IOException {
 
File dir = createTempDirectory();
-   File subdir = new File( dir.getAbsolutePath() + "/sub Directory 
déjà vu special/" );
+URI relativeCWD = URI.create( "" );
 
 Review comment:
   check indentation


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] michael-o commented on a change in pull request #66: [SCM-868] fix gitexe cannot deduce relative path

[GitBox]

michael-o commented on a change in pull request #66: [SCM-868] fix gitexe 
cannot deduce relative path
URL: https://github.com/apache/maven-scm/pull/66#discussion_r188777542
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/test/java/org/apache/maven/scm/provider/git/gitexe/command/status/GitStatusConsumerTest.java
 ##
 @@ -187,23 +187,33 @@ public void testConsumerModifiedFile()
 assertEquals("test file with spaces and a special \u007f 
character.xml", changedFiles.get( 0 ).getPath() );
 }
 
+public void testURI()
+throws Exception
+{
+String path = "Not%Scheme:/sub dir";
+URI u = GitStatusConsumer.uriFromPath( path );
+assertEquals( path, u.getPath() );
+}
+
// SCM-740
public void testConsumerModifiedFileInComplexDirectorySetup() throws 
IOException {
 
File dir = createTempDirectory();
-   File subdir = new File( dir.getAbsolutePath() + 
"/subDirectory/" );
+URI relativeCWD = URI.create( "" );
 
 Review comment:
   check indentation


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] michael-o commented on a change in pull request #66: [SCM-868] fix gitexe cannot deduce relative path

[GitBox]

michael-o commented on a change in pull request #66: [SCM-868] fix gitexe 
cannot deduce relative path
URL: https://github.com/apache/maven-scm/pull/66#discussion_r188777653
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/test/java/org/apache/maven/scm/provider/git/gitexe/command/status/GitStatusConsumerTest.java
 ##
 @@ -187,23 +187,33 @@ public void testConsumerModifiedFile()
 assertEquals("test file with spaces and a special \u007f 
character.xml", changedFiles.get( 0 ).getPath() );
 }
 
+public void testURI()
+throws Exception
+{
+String path = "Not%Scheme:/sub dir";
+URI u = GitStatusConsumer.uriFromPath( path );
+assertEquals( path, u.getPath() );
+}
+
// SCM-740
public void testConsumerModifiedFileInComplexDirectorySetup() throws 
IOException {
 
File dir = createTempDirectory();
-   File subdir = new File( dir.getAbsolutePath() + 
"/subDirectory/" );
+URI relativeCWD = URI.create( "" );
+   File subdir = new File( dir, "subDirectory" );
subdir.mkdir();
FileUtils.write( new File( subdir, "project.xml" ), "data" );
 
-   List changedFiles = getChangedFiles( "M  
subDirectory/project.xml", subdir, dir.toURI() );
+List changedFiles = getChangedFiles( "M  
subDirectory/project.xml", dir, relativeCWD );
 
 Review comment:
   check indentation


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] michael-o commented on a change in pull request #66: [SCM-868] fix gitexe cannot deduce relative path

[GitBox]

michael-o commented on a change in pull request #66: [SCM-868] fix gitexe 
cannot deduce relative path
URL: https://github.com/apache/maven-scm/pull/66#discussion_r18804
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/test/java/org/apache/maven/scm/provider/git/gitexe/command/status/GitStatusConsumerTest.java
 ##
 @@ -187,23 +187,33 @@ public void testConsumerModifiedFile()
 assertEquals("test file with spaces and a special \u007f 
character.xml", changedFiles.get( 0 ).getPath() );
 }
 
+public void testURI()
+throws Exception
+{
+String path = "Not%Scheme:/sub dir";
+URI u = GitStatusConsumer.uriFromPath( path );
+assertEquals( path, u.getPath() );
+}
+
// SCM-740
public void testConsumerModifiedFileInComplexDirectorySetup() throws 
IOException {
 
File dir = createTempDirectory();
-   File subdir = new File( dir.getAbsolutePath() + 
"/subDirectory/" );
+URI relativeCWD = URI.create( "" );
+   File subdir = new File( dir, "subDirectory" );
subdir.mkdir();
FileUtils.write( new File( subdir, "project.xml" ), "data" );
 
-   List changedFiles = getChangedFiles( "M  
subDirectory/project.xml", subdir, dir.toURI() );
+List changedFiles = getChangedFiles( "M  
subDirectory/project.xml", dir, relativeCWD );
 
assertNotNull( changedFiles );
assertEquals( 1, changedFiles.size() );
 assertEquals( "subDirectory/project.xml", changedFiles.get( 0 
).getPath() );
 
 FileUtils.write( new File( subdir, "test file with spaces and a déjà 
vu character.xml" ), "data" );
 
-   changedFiles = getChangedFiles( "M  \"subDirectory/test file 
with spaces and a déjà vu character.xml\"", subdir, dir.toURI() );
+changedFiles =
 
 Review comment:
   check indentation


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-868) gitexe add() does not return added files when invoked in subdir

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478129#comment-16478129
 ] 

ASF GitHub Bot commented on SCM-868:


michael-o commented on a change in pull request #66: [SCM-868] fix gitexe 
cannot deduce relative path
URL: https://github.com/apache/maven-scm/pull/66#discussion_r188777542
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/test/java/org/apache/maven/scm/provider/git/gitexe/command/status/GitStatusConsumerTest.java
 ##
 @@ -187,23 +187,33 @@ public void testConsumerModifiedFile()
 assertEquals("test file with spaces and a special \u007f 
character.xml", changedFiles.get( 0 ).getPath() );
 }
 
+public void testURI()
+throws Exception
+{
+String path = "Not%Scheme:/sub dir";
+URI u = GitStatusConsumer.uriFromPath( path );
+assertEquals( path, u.getPath() );
+}
+
// SCM-740
public void testConsumerModifiedFileInComplexDirectorySetup() throws 
IOException {
 
File dir = createTempDirectory();
-   File subdir = new File( dir.getAbsolutePath() + 
"/subDirectory/" );
+URI relativeCWD = URI.create( "" );
 
 Review comment:
   check indentation


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


> 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-885) GitChangeLogCommand is wrong when only endVersion is set

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478061#comment-16478061
 ] 

Michael Osipov commented on SCM-885:


The more I think about it, the more I have the feeling that won't be able to 
cover all cases for Git anyway. We can reduce gitexe and jgit down to these 
three case where a new parameter is not necessary:

{noformat}
START..
START..END
END
{noformat}

{{START}}, {{END}} those are explicitly provided. The rest is omitted. WDYT?

> 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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478037#comment-16478037
 ] 

ASF GitHub Bot commented on SCM-885:


michael-o commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188758310
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/changelog/GitChangeLogCommand.java
 ##
 @@ -136,9 +160,18 @@ public static Commandline createCommandLine( 
GitScmProviderRepository repository
   null );
 }
 
+static Commandline createCommandLine( GitScmProviderRepository repository, 
File workingDirectory,
+  ScmBranch branch, Date startDate, 
Date endDate,
+  ScmVersion startVersion, ScmVersion 
endVersion, Integer limit )
+{
+return createCommandLine(
+repository, workingDirectory, branch, startDate, endDate, 
startVersion, endVersion, limit, false
 
 Review comment:
   Please reformat


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)

[jira] [Commented] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478035#comment-16478035
 ] 

ASF GitHub Bot commented on SCM-885:


michael-o commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188758267
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/changelog/GitChangeLogCommand.java
 ##
 @@ -89,17 +102,28 @@ protected ChangeLogScmResult executeChangeLogCommand( 
ChangeLogScmRequest reques
 final String datePattern = request.getDatePattern();
 return executeChangeLogCommand( 
request.getScmRepository().getProviderRepository(), fileSet,
 request.getStartDate(), request.getEndDate(), 
request.getScmBranch(), datePattern, startVersion,
-endVersion, request.getLimit() );
+endVersion, request.getLimit(), request.getStartFromRoot() );
 }
 
 protected ChangeLogScmResult executeChangeLogCommand( 
ScmProviderRepository repo, ScmFileSet fileSet,
   Date startDate, Date 
endDate, ScmBranch branch,
   String datePattern, 
ScmVersion startVersion,
   ScmVersion 
endVersion, Integer limit )
+throws ScmException
+{
+return executeChangeLogCommand(
+repo, fileSet, startDate, endDate, branch, datePattern, 
startVersion, endVersion, limit, false
 
 Review comment:
   Please reformat


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)

[jira] [Commented] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478034#comment-16478034
 ] 

ASF GitHub Bot commented on SCM-885:


michael-o commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188758228
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/changelog/GitChangeLogCommand.java
 ##
 @@ -89,17 +102,28 @@ protected ChangeLogScmResult executeChangeLogCommand( 
ChangeLogScmRequest reques
 final String datePattern = request.getDatePattern();
 return executeChangeLogCommand( 
request.getScmRepository().getProviderRepository(), fileSet,
 request.getStartDate(), request.getEndDate(), 
request.getScmBranch(), datePattern, startVersion,
-endVersion, request.getLimit() );
+endVersion, request.getLimit(), request.getStartFromRoot() );
 }
 
 protected ChangeLogScmResult executeChangeLogCommand( 
ScmProviderRepository repo, ScmFileSet fileSet,
   Date startDate, Date 
endDate, ScmBranch branch,
   String datePattern, 
ScmVersion startVersion,
   ScmVersion 
endVersion, Integer limit )
+throws ScmException
 
 Review comment:
   4 char


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] michael-o commented on a change in pull request #72: [SCM-885] second implementation with new API

[GitBox]

michael-o commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188758310
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/changelog/GitChangeLogCommand.java
 ##
 @@ -136,9 +160,18 @@ public static Commandline createCommandLine( 
GitScmProviderRepository repository
   null );
 }
 
+static Commandline createCommandLine( GitScmProviderRepository repository, 
File workingDirectory,
+  ScmBranch branch, Date startDate, 
Date endDate,
+  ScmVersion startVersion, ScmVersion 
endVersion, Integer limit )
+{
+return createCommandLine(
+repository, workingDirectory, branch, startDate, endDate, 
startVersion, endVersion, limit, false
 
 Review comment:
   Please reformat


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] michael-o commented on a change in pull request #72: [SCM-885] second implementation with new API

[GitBox]

michael-o commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188758267
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/changelog/GitChangeLogCommand.java
 ##
 @@ -89,17 +102,28 @@ protected ChangeLogScmResult executeChangeLogCommand( 
ChangeLogScmRequest reques
 final String datePattern = request.getDatePattern();
 return executeChangeLogCommand( 
request.getScmRepository().getProviderRepository(), fileSet,
 request.getStartDate(), request.getEndDate(), 
request.getScmBranch(), datePattern, startVersion,
-endVersion, request.getLimit() );
+endVersion, request.getLimit(), request.getStartFromRoot() );
 }
 
 protected ChangeLogScmResult executeChangeLogCommand( 
ScmProviderRepository repo, ScmFileSet fileSet,
   Date startDate, Date 
endDate, ScmBranch branch,
   String datePattern, 
ScmVersion startVersion,
   ScmVersion 
endVersion, Integer limit )
+throws ScmException
+{
+return executeChangeLogCommand(
+repo, fileSet, startDate, endDate, branch, datePattern, 
startVersion, endVersion, limit, false
 
 Review comment:
   Please reformat


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] michael-o commented on a change in pull request #72: [SCM-885] second implementation with new API

[GitBox]

michael-o commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188758228
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/changelog/GitChangeLogCommand.java
 ##
 @@ -89,17 +102,28 @@ protected ChangeLogScmResult executeChangeLogCommand( 
ChangeLogScmRequest reques
 final String datePattern = request.getDatePattern();
 return executeChangeLogCommand( 
request.getScmRepository().getProviderRepository(), fileSet,
 request.getStartDate(), request.getEndDate(), 
request.getScmBranch(), datePattern, startVersion,
-endVersion, request.getLimit() );
+endVersion, request.getLimit(), request.getStartFromRoot() );
 }
 
 protected ChangeLogScmResult executeChangeLogCommand( 
ScmProviderRepository repo, ScmFileSet fileSet,
   Date startDate, Date 
endDate, ScmBranch branch,
   String datePattern, 
ScmVersion startVersion,
   ScmVersion 
endVersion, Integer limit )
+throws ScmException
 
 Review comment:
   4 char


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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478031#comment-16478031
 ] 

ASF GitHub Bot commented on SCM-885:


michael-o commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188757948
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/changelog/GitChangeLogCommand.java
 ##
 @@ -57,7 +57,20 @@ protected ChangeLogScmResult executeChangeLogCommand( 
ScmProviderRepository repo
   String datePattern )
 throws ScmException
 {
-return executeChangeLogCommand( repo, fileSet, null, null, null, 
datePattern, startVersion, endVersion );
+return executeChangeLogCommand(
 
 Review comment:
   Drop this change.


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)

[jira] [Commented] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478032#comment-16478032
 ] 

ASF GitHub Bot commented on SCM-885:


michael-o commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188758147
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/changelog/GitChangeLogCommand.java
 ##
 @@ -57,7 +57,20 @@ protected ChangeLogScmResult executeChangeLogCommand( 
ScmProviderRepository repo
   String datePattern )
 throws ScmException
 {
-return executeChangeLogCommand( repo, fileSet, null, null, null, 
datePattern, startVersion, endVersion );
+return executeChangeLogCommand(
+repo, fileSet, null, null, null, datePattern, startVersion, 
endVersion
+);
+}
+
+/** {@inheritDoc} */
+protected ChangeLogScmResult executeChangeLogCommand( 
ScmProviderRepository repo, ScmFileSet fileSet,
+  ScmVersion 
endVersion, String datePattern,
+  boolean 
startFromRoot )
+throws ScmException
+{
+return executeChangeLogCommand(
 
 Review comment:
   Please reformat


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] michael-o commented on a change in pull request #72: [SCM-885] second implementation with new API

[GitBox]

michael-o commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188758147
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/changelog/GitChangeLogCommand.java
 ##
 @@ -57,7 +57,20 @@ protected ChangeLogScmResult executeChangeLogCommand( 
ScmProviderRepository repo
   String datePattern )
 throws ScmException
 {
-return executeChangeLogCommand( repo, fileSet, null, null, null, 
datePattern, startVersion, endVersion );
+return executeChangeLogCommand(
+repo, fileSet, null, null, null, datePattern, startVersion, 
endVersion
+);
+}
+
+/** {@inheritDoc} */
+protected ChangeLogScmResult executeChangeLogCommand( 
ScmProviderRepository repo, ScmFileSet fileSet,
+  ScmVersion 
endVersion, String datePattern,
+  boolean 
startFromRoot )
+throws ScmException
+{
+return executeChangeLogCommand(
 
 Review comment:
   Please reformat


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] michael-o commented on a change in pull request #72: [SCM-885] second implementation with new API

[GitBox]

michael-o commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188757948
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/changelog/GitChangeLogCommand.java
 ##
 @@ -57,7 +57,20 @@ protected ChangeLogScmResult executeChangeLogCommand( 
ScmProviderRepository repo
   String datePattern )
 throws ScmException
 {
-return executeChangeLogCommand( repo, fileSet, null, null, null, 
datePattern, startVersion, endVersion );
+return executeChangeLogCommand(
 
 Review comment:
   Drop this change.


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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478025#comment-16478025
 ] 

ASF GitHub Bot commented on SCM-885:


michael-o commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188757598
 
 

 ##
 File path: 
maven-scm-api/src/main/java/org/apache/maven/scm/command/changelog/ChangeLogScmRequest.java
 ##
 @@ -130,6 +130,18 @@ public void setEndRevision( ScmVersion endRevision )
 parameters.setScmVersion( CommandParameter.END_SCM_VERSION, 
endRevision );
 }
 
+public boolean getStartFromRoot()
 
 Review comment:
   Boolean return value should be `is...`.


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)

[jira] [Commented] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478029#comment-16478029
 ] 

ASF GitHub Bot commented on SCM-885:


michael-o commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188757715
 
 

 ##
 File path: 
maven-scm-api/src/main/java/org/apache/maven/scm/command/changelog/ChangeLogScmRequest.java
 ##
 @@ -130,6 +130,18 @@ public void setEndRevision( ScmVersion endRevision )
 parameters.setScmVersion( CommandParameter.END_SCM_VERSION, 
endRevision );
 }
 
+public boolean getStartFromRoot()
+throws ScmException
+{
+return parameters.getBoolean( CommandParameter.START_FROM_ROOT, false 
);
+}
+
+public void setStartFromRoot()
+throws ScmException
 
 Review comment:
   4 char indent


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)

[jira] [Commented] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478027#comment-16478027
 ] 

ASF GitHub Bot commented on SCM-885:


michael-o commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188757690
 
 

 ##
 File path: 
maven-scm-api/src/main/java/org/apache/maven/scm/command/changelog/ChangeLogScmRequest.java
 ##
 @@ -130,6 +130,18 @@ public void setEndRevision( ScmVersion endRevision )
 parameters.setScmVersion( CommandParameter.END_SCM_VERSION, 
endRevision );
 }
 
+public boolean getStartFromRoot()
+throws ScmException
 
 Review comment:
   4 char indent


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] michael-o commented on a change in pull request #72: [SCM-885] second implementation with new API

[GitBox]

michael-o commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188757598
 
 

 ##
 File path: 
maven-scm-api/src/main/java/org/apache/maven/scm/command/changelog/ChangeLogScmRequest.java
 ##
 @@ -130,6 +130,18 @@ public void setEndRevision( ScmVersion endRevision )
 parameters.setScmVersion( CommandParameter.END_SCM_VERSION, 
endRevision );
 }
 
+public boolean getStartFromRoot()
 
 Review comment:
   Boolean return value should be `is...`.


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] michael-o commented on a change in pull request #72: [SCM-885] second implementation with new API

[GitBox]

michael-o commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188757690
 
 

 ##
 File path: 
maven-scm-api/src/main/java/org/apache/maven/scm/command/changelog/ChangeLogScmRequest.java
 ##
 @@ -130,6 +130,18 @@ public void setEndRevision( ScmVersion endRevision )
 parameters.setScmVersion( CommandParameter.END_SCM_VERSION, 
endRevision );
 }
 
+public boolean getStartFromRoot()
+throws ScmException
 
 Review comment:
   4 char indent


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] michael-o commented on a change in pull request #72: [SCM-885] second implementation with new API

[GitBox]

michael-o commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188757715
 
 

 ##
 File path: 
maven-scm-api/src/main/java/org/apache/maven/scm/command/changelog/ChangeLogScmRequest.java
 ##
 @@ -130,6 +130,18 @@ public void setEndRevision( ScmVersion endRevision )
 parameters.setScmVersion( CommandParameter.END_SCM_VERSION, 
endRevision );
 }
 
+public boolean getStartFromRoot()
+throws ScmException
+{
+return parameters.getBoolean( CommandParameter.START_FROM_ROOT, false 
);
+}
+
+public void setStartFromRoot()
+throws ScmException
 
 Review comment:
   4 char indent


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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478024#comment-16478024
 ] 

ASF GitHub Bot commented on SCM-885:


michael-o commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188757458
 
 

 ##
 File path: 
maven-scm-api/src/main/java/org/apache/maven/scm/command/changelog/AbstractChangeLogCommand.java
 ##
 @@ -50,11 +50,20 @@ protected abstract ChangeLogScmResult 
executeChangeLogCommand( ScmProviderReposi
 protected ChangeLogScmResult executeChangeLogCommand( 
ScmProviderRepository repository, ScmFileSet fileSet,
   ScmVersion 
startVersion, ScmVersion endVersion,
   String datePattern )
-throws ScmException
+throws ScmException
 {
 throw new ScmException( "Unsupported method for this provider." );
 }
 
+protected ChangeLogScmResult executeChangeLogCommand( 
ScmProviderRepository repository, ScmFileSet fileSet,
+  ScmVersion 
endVersion,
+  String datePattern, 
boolean startFromRoot )
+throws ScmException
+{
+// by default let's just delegate to executeChangeLogCommand with both 
start and end versions
+return executeChangeLogCommand( repository, fileSet, null, endVersion, 
datePattern );
 
 Review comment:
   What is the purpose of this entire method if `startFromRoot` is not passed?


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] michael-o commented on a change in pull request #72: [SCM-885] second implementation with new API

[GitBox]

michael-o commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188757458
 
 

 ##
 File path: 
maven-scm-api/src/main/java/org/apache/maven/scm/command/changelog/AbstractChangeLogCommand.java
 ##
 @@ -50,11 +50,20 @@ protected abstract ChangeLogScmResult 
executeChangeLogCommand( ScmProviderReposi
 protected ChangeLogScmResult executeChangeLogCommand( 
ScmProviderRepository repository, ScmFileSet fileSet,
   ScmVersion 
startVersion, ScmVersion endVersion,
   String datePattern )
-throws ScmException
+throws ScmException
 {
 throw new ScmException( "Unsupported method for this provider." );
 }
 
+protected ChangeLogScmResult executeChangeLogCommand( 
ScmProviderRepository repository, ScmFileSet fileSet,
+  ScmVersion 
endVersion,
+  String datePattern, 
boolean startFromRoot )
+throws ScmException
+{
+// by default let's just delegate to executeChangeLogCommand with both 
start and end versions
+return executeChangeLogCommand( repository, fileSet, null, endVersion, 
datePattern );
 
 Review comment:
   What is the purpose of this entire method if `startFromRoot` is not passed?


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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478012#comment-16478012
 ] 

ASF GitHub Bot commented on SCM-885:


michael-o commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188757145
 
 

 ##
 File path: 
maven-scm-api/src/main/java/org/apache/maven/scm/CommandParameter.java
 ##
 @@ -50,6 +50,8 @@
 
 public static final CommandParameter BRANCH = new CommandParameter( 
"branch" );
 
+public static final CommandParameter START_FROM_ROOT = new 
CommandParameter( "startFromRoot" );
 
 Review comment:
   Why did you call it `root`. Looking at 
[gitvevisions](https://git-scm.com/docs/gitrevisions#_revision_range_summary) I 
fail to find a corresponding term. Does `startFromEnd` make more sense?


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] michael-o commented on a change in pull request #72: [SCM-885] second implementation with new API

[GitBox]

michael-o commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188757145
 
 

 ##
 File path: 
maven-scm-api/src/main/java/org/apache/maven/scm/CommandParameter.java
 ##
 @@ -50,6 +50,8 @@
 
 public static final CommandParameter BRANCH = new CommandParameter( 
"branch" );
 
+public static final CommandParameter START_FROM_ROOT = new 
CommandParameter( "startFromRoot" );
 
 Review comment:
   Why did you call it `root`. Looking at 
[gitvevisions](https://git-scm.com/docs/gitrevisions#_revision_range_summary) I 
fail to find a corresponding term. Does `startFromEnd` make more sense?


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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478006#comment-16478006
 ] 

ASF GitHub Bot commented on SCM-885:


michael-o commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188756408
 
 

 ##
 File path: 
maven-scm-api/src/main/java/org/apache/maven/scm/command/changelog/AbstractChangeLogCommand.java
 ##
 @@ -50,11 +50,20 @@ protected abstract ChangeLogScmResult 
executeChangeLogCommand( ScmProviderReposi
 protected ChangeLogScmResult executeChangeLogCommand( 
ScmProviderRepository repository, ScmFileSet fileSet,
   ScmVersion 
startVersion, ScmVersion endVersion,
   String datePattern )
-throws ScmException
+throws ScmException
 
 Review comment:
   Drop this change.


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] michael-o commented on a change in pull request #72: [SCM-885] second implementation with new API

[GitBox]

michael-o commented on a change in pull request #72: [SCM-885] second 
implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#discussion_r188756408
 
 

 ##
 File path: 
maven-scm-api/src/main/java/org/apache/maven/scm/command/changelog/AbstractChangeLogCommand.java
 ##
 @@ -50,11 +50,20 @@ protected abstract ChangeLogScmResult 
executeChangeLogCommand( ScmProviderReposi
 protected ChangeLogScmResult executeChangeLogCommand( 
ScmProviderRepository repository, ScmFileSet fileSet,
   ScmVersion 
startVersion, ScmVersion endVersion,
   String datePattern )
-throws ScmException
+throws ScmException
 
 Review comment:
   Drop this change.


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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478002#comment-16478002
 ] 

ASF GitHub Bot commented on SCM-885:


michael-o commented on issue #72: [SCM-885] second implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#issuecomment-389648916
 
 
   Please revise this PR for the conflict.


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] michael-o commented on issue #72: [SCM-885] second implementation with new API

[GitBox]

michael-o commented on issue #72: [SCM-885] second implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#issuecomment-389648916
 
 
   Please revise this PR for the conflict.


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

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477997#comment-16477997
 ] 

Michael Osipov commented on SCM-885:


[~McFoggy], looking into your patch. The documentation says:

bq. Returns the changes that have happend in the source control system in a 
certain period of time. This can be adding, removing, updating, ... of files

This does not concretely specify how it has to be implemented. It is at the 
descretion of the SCM. Look at svnexe, it does use {{:HEAD}}. We could probably 
add {{HEAD}} for the sake of completeness.

Regarding JGit, neither this is wrong or right because it is not specified. I 
think we need to do what makes most sense for Git.

> 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] Tibor17 commented on a change in pull request #184: Donate current sources from junit-platform-surefire-provider

[GitBox]

Tibor17 commented on a change in pull request #184: Donate current sources from 
junit-platform-surefire-provider
URL: https://github.com/apache/maven-surefire/pull/184#discussion_r188747241
 
 

 ##
 File path: maven-surefire-plugin/src/site/apt/index.apt.vm
 ##
 @@ -141,6 +141,8 @@ mvn verify
 
   * {{{./examples/testng.html}Using TestNG}}
 
+  * {{{./examples/junit-platform.html}Using JUnit Platform}}
 
 Review comment:
   Can we just mention `Using JUnit5 Platform` - added `5`.


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] Tibor17 commented on a change in pull request #184: Donate current sources from junit-platform-surefire-provider

[GitBox]

Tibor17 commented on a change in pull request #184: Donate current sources from 
junit-platform-surefire-provider
URL: https://github.com/apache/maven-surefire/pull/184#discussion_r188745820
 
 

 ##
 File path: maven-surefire-plugin/src/site/apt/examples/junit-platform.apt.vm
 ##
 @@ -0,0 +1,206 @@
+ --
+ Using JUnit Platform
+ --
+ JUnit Lambda Team 
+ --
+ 2018-05-14
+ --
+ 
+ ~~ Licensed to the Apache Software Foundation (ASF) under one
+ ~~ or more contributor license agreements.  See the NOTICE file
+ ~~ distributed with this work for additional information
+ ~~ regarding copyright ownership.  The ASF licenses this file
+ ~~ to you under the Apache License, Version 2.0 (the
+ ~~ "License"); you may not use this file except in compliance
+ ~~ with the License.  You may obtain a copy of the License at
+ ~~
+ ~~   http://www.apache.org/licenses/LICENSE-2.0
+ ~~
+ ~~ Unless required by applicable law or agreed to in writing,
+ ~~ software distributed under the License is distributed on an
+ ~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ ~~ KIND, either express or implied.  See the License for the
+ ~~ specific language governing permissions and limitations
+ ~~ under the License.
+
+ ~~ NOTE: For help with the syntax of this file, see:
+ ~~ http://maven.apache.org/doxia/references/apt-format.html 
+
+Using JUnit Platform
+
+* Configuring JUnit Platform
+
+  To get started with JUnit Platform, you need to add at least a single 
<<>> implementation
+  to your project. For example, if you want to write tests with Jupiter, you 
must add the
+  <<>> to the dependencies like:
+
++---+
+
+  [...]
+
+  org.junit.jupiter
+  junit-jupiter-engine
+  5.2.0
+  test
+
+  [...]
+
++---+
+
+  This will pull in all required dependencies. Among those dependencies is 
<<>> which contains
+  the classes and interfaces your test source requires to compile. 
<<>> is also resolved and
+  added.
+
+  This is the only step that is required to get started - you can now create 
tests in your test source directory
+  (e.g., <<>>).
+
+  If you want to write and execute JUnit 3 or 4 tests via the JUnit Platform 
add the Vintage Engine to your projects'
+  dependencies:
+
++---+
+
+  [...]
+
+  org.junit.vintage
+  junit-vintage-engine
+  5.2.0
+  test
+
+  [...]
+
++---+
+
+* Provider Selection
+
+   If nothing is configured, Surefire detects which JUnit version to use by 
the following algorithm:
+
++---+
+if the JUnit Platform Engine is present in the project
+use junit-platform
+if the JUnit version in the project >= 4.7 and the parallel attribute has ANY 
value
 
 Review comment:
   Pls emphase with `<<>>` but the attribute should be rewritten to 
`configuration parameter`.


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] Tibor17 commented on a change in pull request #184: Donate current sources from junit-platform-surefire-provider

[GitBox]

Tibor17 commented on a change in pull request #184: Donate current sources from 
junit-platform-surefire-provider
URL: https://github.com/apache/maven-surefire/pull/184#discussion_r188745820
 
 

 ##
 File path: maven-surefire-plugin/src/site/apt/examples/junit-platform.apt.vm
 ##
 @@ -0,0 +1,206 @@
+ --
+ Using JUnit Platform
+ --
+ JUnit Lambda Team 
+ --
+ 2018-05-14
+ --
+ 
+ ~~ Licensed to the Apache Software Foundation (ASF) under one
+ ~~ or more contributor license agreements.  See the NOTICE file
+ ~~ distributed with this work for additional information
+ ~~ regarding copyright ownership.  The ASF licenses this file
+ ~~ to you under the Apache License, Version 2.0 (the
+ ~~ "License"); you may not use this file except in compliance
+ ~~ with the License.  You may obtain a copy of the License at
+ ~~
+ ~~   http://www.apache.org/licenses/LICENSE-2.0
+ ~~
+ ~~ Unless required by applicable law or agreed to in writing,
+ ~~ software distributed under the License is distributed on an
+ ~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ ~~ KIND, either express or implied.  See the License for the
+ ~~ specific language governing permissions and limitations
+ ~~ under the License.
+
+ ~~ NOTE: For help with the syntax of this file, see:
+ ~~ http://maven.apache.org/doxia/references/apt-format.html 
+
+Using JUnit Platform
+
+* Configuring JUnit Platform
+
+  To get started with JUnit Platform, you need to add at least a single 
<<>> implementation
+  to your project. For example, if you want to write tests with Jupiter, you 
must add the
+  <<>> to the dependencies like:
+
++---+
+
+  [...]
+
+  org.junit.jupiter
+  junit-jupiter-engine
+  5.2.0
+  test
+
+  [...]
+
++---+
+
+  This will pull in all required dependencies. Among those dependencies is 
<<>> which contains
+  the classes and interfaces your test source requires to compile. 
<<>> is also resolved and
+  added.
+
+  This is the only step that is required to get started - you can now create 
tests in your test source directory
+  (e.g., <<>>).
+
+  If you want to write and execute JUnit 3 or 4 tests via the JUnit Platform 
add the Vintage Engine to your projects'
+  dependencies:
+
++---+
+
+  [...]
+
+  org.junit.vintage
+  junit-vintage-engine
+  5.2.0
+  test
+
+  [...]
+
++---+
+
+* Provider Selection
+
+   If nothing is configured, Surefire detects which JUnit version to use by 
the following algorithm:
+
++---+
+if the JUnit Platform Engine is present in the project
+use junit-platform
+if the JUnit version in the project >= 4.7 and the parallel attribute has ANY 
value
 
 Review comment:
   Pls emphase with `<<>` but the attribute should be rewritten to 
`configuration parameter`.


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] Tibor17 commented on a change in pull request #184: Donate current sources from junit-platform-surefire-provider

[GitBox]

Tibor17 commented on a change in pull request #184: Donate current sources from 
junit-platform-surefire-provider
URL: https://github.com/apache/maven-surefire/pull/184#discussion_r188744366
 
 

 ##
 File path: maven-surefire-plugin/src/site/apt/examples/junit-platform.apt.vm
 ##
 @@ -0,0 +1,206 @@
+ --
+ Using JUnit Platform
+ --
+ JUnit Lambda Team 
+ --
+ 2018-05-14
+ --
+ 
+ ~~ Licensed to the Apache Software Foundation (ASF) under one
+ ~~ or more contributor license agreements.  See the NOTICE file
+ ~~ distributed with this work for additional information
+ ~~ regarding copyright ownership.  The ASF licenses this file
+ ~~ to you under the Apache License, Version 2.0 (the
+ ~~ "License"); you may not use this file except in compliance
+ ~~ with the License.  You may obtain a copy of the License at
+ ~~
+ ~~   http://www.apache.org/licenses/LICENSE-2.0
+ ~~
+ ~~ Unless required by applicable law or agreed to in writing,
+ ~~ software distributed under the License is distributed on an
+ ~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ ~~ KIND, either express or implied.  See the License for the
+ ~~ specific language governing permissions and limitations
+ ~~ under the License.
+
+ ~~ NOTE: For help with the syntax of this file, see:
+ ~~ http://maven.apache.org/doxia/references/apt-format.html 
+
+Using JUnit Platform
+
+* Configuring JUnit Platform
+
+  To get started with JUnit Platform, you need to add at least a single 
<<>> implementation
+  to your project. For example, if you want to write tests with Jupiter, you 
must add the
+  <<>> to the dependencies like:
+
++---+
+
+  [...]
+
+  org.junit.jupiter
+  junit-jupiter-engine
+  5.2.0
+  test
+
+  [...]
+
++---+
+
+  This will pull in all required dependencies. Among those dependencies is 
<<>> which contains
+  the classes and interfaces your test source requires to compile. 
<<>> is also resolved and
+  added.
+
+  This is the only step that is required to get started - you can now create 
tests in your test source directory
+  (e.g., <<>>).
+
+  If you want to write and execute JUnit 3 or 4 tests via the JUnit Platform 
add the Vintage Engine to your projects'
+  dependencies:
+
++---+
+
+  [...]
+
+  org.junit.vintage
+  junit-vintage-engine
+  5.2.0
+  test
+
+  [...]
+
++---+
+
+* Provider Selection
+
+   If nothing is configured, Surefire detects which JUnit version to use by 
the following algorithm:
+
++---+
+if the JUnit Platform Engine is present in the project
+use junit-platform
+if the JUnit version in the project >= 4.7 and the parallel attribute has ANY 
value
+use junit47 provider
+if JUnit >= 4.0 is present
+use junit4 provider
+else
+use junit3.8.1
++---+
+
+  When using this technique there is no check that the proper test-frameworks 
are present on your project's
+  classpath. Failing to add the proper test-frameworks will result in a build 
failure.
+
+* Running Tests in Parallel
+
+  From JUnit Platform does not support running tests in parallel.
+
+* Running a Single Test Class
+
+   The JUnit Platform Provider supports the <<>> JVM system property 
supported by
+   the Maven Surefire Plugin. For example, to run only test methods in the 
<<>> test class
+   you can execute <<>> from the command 
line.
+
+
+* Filtering by Test Class Names
+
+   The Maven Surefire Plugin will scan for test classes whose fully qualified 
names match
+   the following patterns.
+
+   * <<<**/Test*.java>>>
+
+   * <<<**/*Test.java>>>
+
+   * <<<**/*Tests.java>>>
+
+   * <<<**/*TestCase.java>>>
+
+Moreover, it will exclude all nested classes (including static member classes) 
by default.
+
+Note, however, that you can override this default behavior by configuring 
explicit
+`include` and `exclude` rules in your `pom.xml` file. For example, to keep 
Maven Surefire
+from excluding static member classes, you can override its exclude rules.
+
+Overriding exclude rules of Maven Surefire
+
++---+
+...
+
+
+...
+
+maven-surefire-plugin
+{surefire-version}
+
+
+
+
+
+...
+
+
+
+...
++---+
+
+
+* Filtering by Tags
+
+You can filter tests by tags or tag expressions using the following 
configuration properties.
+
+* to include <<>> or <<>>, use either <<>> 
or <<>>.
+
+* to exclude <<>> or <<>>, use either 
<<>> or <<>>.
+
++---+
+...
+
+
+...
+
+maven-surefire-plugin
+{surefire-version}
+
+
+acceptance | !feature-a
 
 Review comment:
   Why we did not utilize Surefire's parameters `groups` and `excludedGroups`?
   The same is in TestNG.


This is an automated message from the Apache Git Service.
To respond 

[GitHub] Tibor17 commented on a change in pull request #184: Donate current sources from junit-platform-surefire-provider

[GitBox]

Tibor17 commented on a change in pull request #184: Donate current sources from 
junit-platform-surefire-provider
URL: https://github.com/apache/maven-surefire/pull/184#discussion_r188743849
 
 

 ##
 File path: maven-surefire-plugin/src/site/apt/examples/junit-platform.apt.vm
 ##
 @@ -0,0 +1,206 @@
+ --
+ Using JUnit Platform
+ --
+ JUnit Lambda Team 
+ --
+ 2018-05-14
+ --
+ 
+ ~~ Licensed to the Apache Software Foundation (ASF) under one
+ ~~ or more contributor license agreements.  See the NOTICE file
+ ~~ distributed with this work for additional information
+ ~~ regarding copyright ownership.  The ASF licenses this file
+ ~~ to you under the Apache License, Version 2.0 (the
+ ~~ "License"); you may not use this file except in compliance
+ ~~ with the License.  You may obtain a copy of the License at
+ ~~
+ ~~   http://www.apache.org/licenses/LICENSE-2.0
+ ~~
+ ~~ Unless required by applicable law or agreed to in writing,
+ ~~ software distributed under the License is distributed on an
+ ~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ ~~ KIND, either express or implied.  See the License for the
+ ~~ specific language governing permissions and limitations
+ ~~ under the License.
+
+ ~~ NOTE: For help with the syntax of this file, see:
+ ~~ http://maven.apache.org/doxia/references/apt-format.html 
+
+Using JUnit Platform
+
+* Configuring JUnit Platform
+
+  To get started with JUnit Platform, you need to add at least a single 
<<>> implementation
+  to your project. For example, if you want to write tests with Jupiter, you 
must add the
+  <<>> to the dependencies like:
+
++---+
+
+  [...]
+
+  org.junit.jupiter
+  junit-jupiter-engine
+  5.2.0
+  test
+
+  [...]
+
++---+
+
+  This will pull in all required dependencies. Among those dependencies is 
<<>> which contains
+  the classes and interfaces your test source requires to compile. 
<<>> is also resolved and
+  added.
+
+  This is the only step that is required to get started - you can now create 
tests in your test source directory
+  (e.g., <<>>).
+
+  If you want to write and execute JUnit 3 or 4 tests via the JUnit Platform 
add the Vintage Engine to your projects'
+  dependencies:
+
++---+
+
+  [...]
+
+  org.junit.vintage
+  junit-vintage-engine
+  5.2.0
+  test
+
+  [...]
+
++---+
+
+* Provider Selection
+
+   If nothing is configured, Surefire detects which JUnit version to use by 
the following algorithm:
+
++---+
+if the JUnit Platform Engine is present in the project
+use junit-platform
+if the JUnit version in the project >= 4.7 and the parallel attribute has ANY 
value
+use junit47 provider
+if JUnit >= 4.0 is present
+use junit4 provider
+else
+use junit3.8.1
++---+
+
+  When using this technique there is no check that the proper test-frameworks 
are present on your project's
+  classpath. Failing to add the proper test-frameworks will result in a build 
failure.
+
+* Running Tests in Parallel
+
+  From JUnit Platform does not support running tests in parallel.
+
+* Running a Single Test Class
+
+   The JUnit Platform Provider supports the <<>> JVM system property 
supported by
+   the Maven Surefire Plugin. For example, to run only test methods in the 
<<>> test class
+   you can execute <<>> from the command 
line.
+
+
+* Filtering by Test Class Names
+
+   The Maven Surefire Plugin will scan for test classes whose fully qualified 
names match
+   the following patterns.
+
+   * <<<**/Test*.java>>>
+
+   * <<<**/*Test.java>>>
+
+   * <<<**/*Tests.java>>>
+
+   * <<<**/*TestCase.java>>>
+
+Moreover, it will exclude all nested classes (including static member classes) 
by default.
+
+Note, however, that you can override this default behavior by configuring 
explicit
+`include` and `exclude` rules in your `pom.xml` file. For example, to keep 
Maven Surefire
+from excluding static member classes, you can override its exclude rules.
+
+Overriding exclude rules of Maven Surefire
+
++---+
+...
+
+
+...
+
+maven-surefire-plugin
+{surefire-version}
+
+
+
+
+
+...
+
+
+
+...
++---+
+
+
+* Filtering by Tags
+
+You can filter tests by tags or tag expressions using the following 
configuration properties.
+
+* to include <<>> or <<>>, use either <<>> 
or <<>>.
+
+* to exclude <<>> or <<>>, use either 
<<>> or <<>>.
+
++---+
+...
+
+
+...
+
+maven-surefire-plugin
+{surefire-version}
+
+
+acceptance | !feature-a
+integration, regression
+
+
+
+...
+
+
+
+
+...
++---+
+
+
+* Configuration Parameters
+
+   You can set JUnit Platform configuration parameters to influence 

[GitHub] Tibor17 commented on a change in pull request #184: Donate current sources from junit-platform-surefire-provider

[GitBox]

Tibor17 commented on a change in pull request #184: Donate current sources from 
junit-platform-surefire-provider
URL: https://github.com/apache/maven-surefire/pull/184#discussion_r188742697
 
 

 ##
 File path: maven-surefire-plugin/src/site/site.xml
 ##
 @@ -40,6 +40,7 @@
 
   
   
+  
 
 Review comment:
   Perhaps here as well.


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] Tibor17 commented on a change in pull request #184: Donate current sources from junit-platform-surefire-provider

[GitBox]

Tibor17 commented on a change in pull request #184: Donate current sources from 
junit-platform-surefire-provider
URL: https://github.com/apache/maven-surefire/pull/184#discussion_r188742534
 
 

 ##
 File path: maven-surefire-plugin/src/site/apt/index.apt.vm
 ##
 @@ -141,6 +141,8 @@ mvn verify
 
   * {{{./examples/testng.html}Using TestNG}}
 
+  * {{{./examples/junit-platform.html}Using JUnit Platform}}
 
 Review comment:
   Not sure if users would realize this is JUnit5 provider.


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] Tibor17 commented on a change in pull request #184: Donate current sources from junit-platform-surefire-provider

[GitBox]

Tibor17 commented on a change in pull request #184: Donate current sources from 
junit-platform-surefire-provider
URL: https://github.com/apache/maven-surefire/pull/184#discussion_r188742279
 
 

 ##
 File path: maven-surefire-plugin/src/site/apt/featurematrix.apt.vm
 ##
 @@ -27,19 +27,19 @@ Feature Matrix
 Not all features are supported for all test frameworks, and the following 
table gives a brief overview
 of support status:
 
-*-+---+---++---+--+
-|| <>
||<>||<>||<>||<>||<> |
-*-++--++---+--+
-| groups/category support | N  |N |  Y 
|Y  |  N   |
-*-++--++---+--+
-| security manager support| Y  |N |  N 
|N  |  N   |
-*-++--++---+--+
-| runOrder support| Y  |Y |  Y 
|?  |  Y   |
-*-++--++---+--+
-| run >1 individual test method in a class| N  |Y |  Y 
|Y  |  N   |
-*-++--++---+--+
-| parallel support| N  |N |  Y 
|Y  |  N   |
-*-++--++---+--+
+*-+---+---++---+--++
+|| <>
||<>||<>||<>||<>||<> ||<> |
+*-++--++---+--++
+| groups/category/tags support| N  |N |  Y 
|Y  |  N   |  Y |
+*-++--++---+--++
+| security manager support| Y  |N |  N 
|N  |  N   |  N |
+*-++--++---+--++
+| runOrder support| Y  |Y |  Y 
|?  |  Y   |  N |
+*-++--++---+--++
+| run >1 individual test method in a class| N  |Y |  Y 
|Y  |  N   |  ? |
+*-++--++---+--++
+| parallel support| N  |N |  Y 
|Y  |  N   |  N |
 
 Review comment:
   In parallel support we have `N`. Can we utilize ParallelComputer from JUnit4?
   The PC covers parallelism. I would like to utilize it because it has a 
complex possibilities with configuration and I do not want to develop it again.


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] Tibor17 commented on a change in pull request #184: Donate current sources from junit-platform-surefire-provider

[GitBox]

Tibor17 commented on a change in pull request #184: Donate current sources from 
junit-platform-surefire-provider
URL: https://github.com/apache/maven-surefire/pull/184#discussion_r188741696
 
 

 ##
 File path: maven-surefire-plugin/src/site/apt/featurematrix.apt.vm
 ##
 @@ -27,19 +27,19 @@ Feature Matrix
 Not all features are supported for all test frameworks, and the following 
table gives a brief overview
 of support status:
 
-*-+---+---++---+--+
-|| <>
||<>||<>||<>||<>||<> |
-*-++--++---+--+
-| groups/category support | N  |N |  Y 
|Y  |  N   |
-*-++--++---+--+
-| security manager support| Y  |N |  N 
|N  |  N   |
-*-++--++---+--+
-| runOrder support| Y  |Y |  Y 
|?  |  Y   |
-*-++--++---+--+
-| run >1 individual test method in a class| N  |Y |  Y 
|Y  |  N   |
-*-++--++---+--+
-| parallel support| N  |N |  Y 
|Y  |  N   |
-*-++--++---+--+
+*-+---+---++---+--++
+|| <>
||<>||<>||<>||<>||<> ||<> |
+*-++--++---+--++
+| groups/category/tags support| N  |N |  Y 
|Y  |  N   |  Y |
+*-++--++---+--++
+| security manager support| Y  |N |  N 
|N  |  N   |  N |
+*-++--++---+--++
+| runOrder support| Y  |Y |  Y 
|?  |  Y   |  N |
+*-++--++---+--++
+| run >1 individual test method in a class| N  |Y |  Y 
|Y  |  N   |  ? |
 
 Review comment:
   Here we have question mark for `run >1 individual test method in a class`. I 
think this should be `Y`. WDYT?


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] [Updated] (MNG-6412) Exceeding project discovery time when using CI friendly versions

[Christoph Amshoff (JIRA)]

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

Christoph Amshoff updated MNG-6412:
---
Description: 
We are switching a larger project to CI friendly versions 
([https://maven.apache.org/maven-ci-friendly.html]), using properties 
_${revision}_ (fix) and _${changelist}_ (maps to the CI build number) to create 
the actual version. However, doing so, the project discovery time (right after 
Maven says “Scanning for projects...”) increases dramatically from few seconds 
to more than 3 minutes, and we had to double the maximum heap in order to avoid 
“GC overhead limit exceeded” exception.

The project root POM looks like this:
{noformat}
  test
  parent
  ${revision}-${changelist}
  pom
  ...
  
1.0.0
    UNDEFINED
   {noformat}
and is built by passing “-Dchangelist=123” to the Maven process for CI build 
123, for instance.

In debug output, we can see that for each POM of the reactor there are messages 
like these, repeatedly for every single parent POM up the complete hierarchy:
{noformat}
[DEBUG] Extension realms for project test:grandchild1-1:jar:1.0.0-123: (none)
[DEBUG] Looking up lifecycle mappings for packaging jar from 
ClassRealm[plexus.core, parent: null]
[DEBUG] Extension realms for project test:child1:pom:1.0.0-123: (none)
[DEBUG] Looking up lifecycle mappings for packaging pom from 
ClassRealm[plexus.core, parent: null]
[DEBUG] Extension realms for project test:parent:pom:1.0.0-123: (none)
[DEBUG] Looking up lifecycle mappings for packaging pom from 
ClassRealm[plexus.core, parent: null]
{noformat}
When using fix version string (release or SNAPSHOT), these messages are only 
present for the reactor POMs, but not their parents, grand-parents, etc. up to 
the root POM.

Looking up the lifecycle mapping for the same parent POMs over and over again 
seems wrong to me, and is probably the cause of high memory consumption. 
Altogether, there are more than 2,800 messages "Looking up lifecycle 
mappings..." in the logs for about 350 subprojects built in the reactor!

See attached test projects and logs for fix version vs. CI friendly versions. 
The test project structure is like this:
{noformat}
parent
  child1
    grandchild1-1
    grandchild1-2
  child2
    grandchild2-1
    grandchild2-2{noformat}
If you compare both log files, you'll see the difference in project resolving.

  was:
We are switching a larger project (> 350 subprojects) to CI friendly versions 
([https://maven.apache.org/maven-ci-friendly.html]), using properties 
_${revision}_ (fix) and _${changelist}_ (maps to the CI build number) to create 
the actual version. However, doing so, the project discovery time (right after 
Maven says “Scanning for projects...”) increases dramatically from few seconds 
to more than 3 minutes, and we had to double the maximum heap in order to avoid 
“GC overhead limit exceeded” exception.

The project root POM looks like this:
{noformat}
  test
  parent
  ${revision}-${changelist}
  pom
  ...
  
1.0.0
    UNDEFINED
   {noformat}
and is built by passing “-Dchangelist=123” to the Maven process for CI build 
123, for instance.

In debug output, we can see that for each POM of the reactor there are messages 
like these, repeatedly for every single parent POM up the complete hierarchy:
{noformat}
[DEBUG] Extension realms for project test:grandchild1-1:jar:1.0.0-123: (none)
[DEBUG] Looking up lifecycle mappings for packaging jar from 
ClassRealm[plexus.core, parent: null]
[DEBUG] Extension realms for project test:child1:pom:1.0.0-123: (none)
[DEBUG] Looking up lifecycle mappings for packaging pom from 
ClassRealm[plexus.core, parent: null]
[DEBUG] Extension realms for project test:parent:pom:1.0.0-123: (none)
[DEBUG] Looking up lifecycle mappings for packaging pom from 
ClassRealm[plexus.core, parent: null]
{noformat}
When using fix version string (release or SNAPSHOT), these messages are only 
present for the reactor POMs, but not their parents, grand-parents, etc. up to 
the root POM.

Looking up the lifecycle mapping for the same parent POMs over and over again 
seems wrong to me, and is probably the cause of high memory consumption.

See attached test projects and logs for fix version vs. CI friendly versions. 
The test project structure is like this:
{noformat}
parent
  child1
    grandchild1-1
    grandchild1-2
  child2
    grandchild2-1
    grandchild2-2{noformat}
If you compare both log files, you'll see the difference in project resolving.


> Exceeding project discovery time when using CI friendly versions
> 
>
> Key: MNG-6412
> URL: https://issues.apache.org/jira/browse/MNG-6412
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.3
>Reporter: Christoph Amshoff
>Priority: Critical
> Attachments: ci-version-validate.log, 

[jira] [Updated] (MNG-6412) Exceeding project discovery time when using CI friendly versions

[Christoph Amshoff (JIRA)]

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

Christoph Amshoff updated MNG-6412:
---
Description: 
We are switching a larger project (> 350 subprojects) to CI friendly versions 
([https://maven.apache.org/maven-ci-friendly.html]), using properties 
_${revision}_ (fix) and _${changelist}_ (maps to the CI build number) to create 
the actual version. However, doing so, the project discovery time (right after 
Maven says “Scanning for projects...”) increases dramatically from few seconds 
to more than 3 minutes, and we had to double the maximum heap in order to avoid 
“GC overhead limit exceeded” exception.

The project root POM looks like this:
{noformat}
  test
  parent
  ${revision}-${changelist}
  pom
  ...
  
1.0.0
    UNDEFINED
   {noformat}
and is built by passing “-Dchangelist=123” to the Maven process for CI build 
123, for instance.

In debug output, we can see that for each POM of the reactor there are messages 
like these, repeatedly for every single parent POM up the complete hierarchy:
{noformat}
[DEBUG] Extension realms for project test:grandchild1-1:jar:1.0.0-123: (none)
[DEBUG] Looking up lifecycle mappings for packaging jar from 
ClassRealm[plexus.core, parent: null]
[DEBUG] Extension realms for project test:child1:pom:1.0.0-123: (none)
[DEBUG] Looking up lifecycle mappings for packaging pom from 
ClassRealm[plexus.core, parent: null]
[DEBUG] Extension realms for project test:parent:pom:1.0.0-123: (none)
[DEBUG] Looking up lifecycle mappings for packaging pom from 
ClassRealm[plexus.core, parent: null]
{noformat}
When using fix version string (release or SNAPSHOT), these messages are only 
present for the reactor POMs, but not their parents, grand-parents, etc. up to 
the root POM.

Looking up the lifecycle mapping for the same parent POMs over and over again 
seems wrong to me, and is probably the cause of high memory consumption.

See attached test projects and logs for fix version vs. CI friendly versions. 
The test project structure is like this:
{noformat}
parent
  child1
    grandchild1-1
    grandchild1-2
  child2
    grandchild2-1
    grandchild2-2{noformat}
If you compare both log files, you'll see the difference in project resolving.

  was:
We are switching a larger project (> 350 subprojects) to CI friendly versions 
([https://maven.apache.org/maven-ci-friendly.html]), using properties 
_${revision}_ (fix) and _${changelist}_ (maps to the CI build number) to create 
the actual version. However, doing so, the project discovery time (right after 
Maven says “Scanning for projects...”) increases dramatically from few seconds 
to more than 3 minutes, and we had to double the maximum heap in order to avoid 
“GC overhead limit exceeded” exception.

The project root POM looks like this:
{noformat}
  test
  parent
  ${revision}-${changelist}
  pom
  ...
  
1.0.0
    UNDEFINED
   {noformat}
and is built by passing “-Dchangelist=123” to the Maven process for CI build 
123, for instance.

In debug output, we can see that for each POM of the reactor there are messages 
like these, repeatedly for every single parent POM up the complete hierarchy:
{noformat}
[DEBUG] Extension realms for project test:grandchild1-1:jar:1.0.0-123: (none)
[DEBUG] Looking up lifecycle mappings for packaging jar from 
ClassRealm[plexus.core, parent: null]
[DEBUG] Extension realms for project test:child1:pom:1.0.0-123: (none)
[DEBUG] Looking up lifecycle mappings for packaging pom from 
ClassRealm[plexus.core, parent: null]
[DEBUG] Extension realms for project test:parent:pom:1.0.0-123: (none)
[DEBUG] Looking up lifecycle mappings for packaging pom from 
ClassRealm[plexus.core, parent: null]
{noformat}
When using fix version string (release or SNAPSHOT), these messages are only 
present for the reactor POMs, but not their parents, grand-parents, etc. up to 
the root POM.

Looking up the lifecycle mapping for the same parent POMs over and over again 
seems wrong to me, and is probably the cause of high memory consumption.

See attached test projects and logs for fix version vs. CI friendly versions.


> Exceeding project discovery time when using CI friendly versions
> 
>
> Key: MNG-6412
> URL: https://issues.apache.org/jira/browse/MNG-6412
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.3
>Reporter: Christoph Amshoff
>Priority: Critical
> Attachments: ci-version-validate.log, fix-version-validate.log, 
> test-ci-project-scanning.zip
>
>
> We are switching a larger project (> 350 subprojects) to CI friendly versions 
> ([https://maven.apache.org/maven-ci-friendly.html]), using properties 
> _${revision}_ (fix) and _${changelist}_ (maps to the CI build number) to 
> create the actual version. However, doing so, the project discovery 

[jira] [Updated] (MNG-6412) Exceeding project discovery time when using CI friendly versions

[Christoph Amshoff (JIRA)]

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

Christoph Amshoff updated MNG-6412:
---
Attachment: fix-version-validate.log
ci-version-validate.log

> Exceeding project discovery time when using CI friendly versions
> 
>
> Key: MNG-6412
> URL: https://issues.apache.org/jira/browse/MNG-6412
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.3
>Reporter: Christoph Amshoff
>Priority: Critical
> Attachments: ci-version-validate.log, fix-version-validate.log, 
> test-ci-project-scanning.zip
>
>
> We are switching a larger project (> 350 subprojects) to CI friendly versions 
> ([https://maven.apache.org/maven-ci-friendly.html]), using properties 
> _${revision}_ (fix) and _${changelist}_ (maps to the CI build number) to 
> create the actual version. However, doing so, the project discovery time 
> (right after Maven says “Scanning for projects...”) increases dramatically 
> from few seconds to more than 3 minutes, and we had to double the maximum 
> heap in order to avoid “GC overhead limit exceeded” exception.
> The project root POM looks like this:
> {noformat}
>   test
>   parent
>   ${revision}-${changelist}
>   pom
>   ...
>   
> 1.0.0
>     UNDEFINED
>    {noformat}
> and is built by passing “-Dchangelist=123” to the Maven process for CI build 
> 123, for instance.
> In debug output, we can see that for each POM of the reactor there are 
> messages like these, repeatedly for every single parent POM up the complete 
> hierarchy:
> {noformat}
> [DEBUG] Extension realms for project test:grandchild1-1:jar:1.0.0-123: (none)
> [DEBUG] Looking up lifecycle mappings for packaging jar from 
> ClassRealm[plexus.core, parent: null]
> [DEBUG] Extension realms for project test:child1:pom:1.0.0-123: (none)
> [DEBUG] Looking up lifecycle mappings for packaging pom from 
> ClassRealm[plexus.core, parent: null]
> [DEBUG] Extension realms for project test:parent:pom:1.0.0-123: (none)
> [DEBUG] Looking up lifecycle mappings for packaging pom from 
> ClassRealm[plexus.core, parent: null]
> {noformat}
> When using fix version string (release or SNAPSHOT), these messages are only 
> present for the reactor POMs, but not their parents, grand-parents, etc. up 
> to the root POM.
> Looking up the lifecycle mapping for the same parent POMs over and over again 
> seems wrong to me, and is probably the cause of high memory consumption.
> See attached test projects and logs for fix version vs. CI friendly versions.



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

[jira] [Updated] (MNG-6412) Exceeding project discovery time when using CI friendly versions

[Christoph Amshoff (JIRA)]

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

Christoph Amshoff updated MNG-6412:
---
Attachment: (was: ci-version-validate.log)

> Exceeding project discovery time when using CI friendly versions
> 
>
> Key: MNG-6412
> URL: https://issues.apache.org/jira/browse/MNG-6412
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.3
>Reporter: Christoph Amshoff
>Priority: Critical
> Attachments: ci-version-validate.log, fix-version-validate.log, 
> test-ci-project-scanning.zip
>
>
> We are switching a larger project (> 350 subprojects) to CI friendly versions 
> ([https://maven.apache.org/maven-ci-friendly.html]), using properties 
> _${revision}_ (fix) and _${changelist}_ (maps to the CI build number) to 
> create the actual version. However, doing so, the project discovery time 
> (right after Maven says “Scanning for projects...”) increases dramatically 
> from few seconds to more than 3 minutes, and we had to double the maximum 
> heap in order to avoid “GC overhead limit exceeded” exception.
> The project root POM looks like this:
> {noformat}
>   test
>   parent
>   ${revision}-${changelist}
>   pom
>   ...
>   
> 1.0.0
>     UNDEFINED
>    {noformat}
> and is built by passing “-Dchangelist=123” to the Maven process for CI build 
> 123, for instance.
> In debug output, we can see that for each POM of the reactor there are 
> messages like these, repeatedly for every single parent POM up the complete 
> hierarchy:
> {noformat}
> [DEBUG] Extension realms for project test:grandchild1-1:jar:1.0.0-123: (none)
> [DEBUG] Looking up lifecycle mappings for packaging jar from 
> ClassRealm[plexus.core, parent: null]
> [DEBUG] Extension realms for project test:child1:pom:1.0.0-123: (none)
> [DEBUG] Looking up lifecycle mappings for packaging pom from 
> ClassRealm[plexus.core, parent: null]
> [DEBUG] Extension realms for project test:parent:pom:1.0.0-123: (none)
> [DEBUG] Looking up lifecycle mappings for packaging pom from 
> ClassRealm[plexus.core, parent: null]
> {noformat}
> When using fix version string (release or SNAPSHOT), these messages are only 
> present for the reactor POMs, but not their parents, grand-parents, etc. up 
> to the root POM.
> Looking up the lifecycle mapping for the same parent POMs over and over again 
> seems wrong to me, and is probably the cause of high memory consumption.
> See attached test projects and logs for fix version vs. CI friendly versions.



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

[jira] [Updated] (MNG-6412) Exceeding project discovery time when using CI friendly versions

[Christoph Amshoff (JIRA)]

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

Christoph Amshoff updated MNG-6412:
---
Attachment: (was: fix-version-validate.log)

> Exceeding project discovery time when using CI friendly versions
> 
>
> Key: MNG-6412
> URL: https://issues.apache.org/jira/browse/MNG-6412
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.3
>Reporter: Christoph Amshoff
>Priority: Critical
> Attachments: ci-version-validate.log, fix-version-validate.log, 
> test-ci-project-scanning.zip
>
>
> We are switching a larger project (> 350 subprojects) to CI friendly versions 
> ([https://maven.apache.org/maven-ci-friendly.html]), using properties 
> _${revision}_ (fix) and _${changelist}_ (maps to the CI build number) to 
> create the actual version. However, doing so, the project discovery time 
> (right after Maven says “Scanning for projects...”) increases dramatically 
> from few seconds to more than 3 minutes, and we had to double the maximum 
> heap in order to avoid “GC overhead limit exceeded” exception.
> The project root POM looks like this:
> {noformat}
>   test
>   parent
>   ${revision}-${changelist}
>   pom
>   ...
>   
> 1.0.0
>     UNDEFINED
>    {noformat}
> and is built by passing “-Dchangelist=123” to the Maven process for CI build 
> 123, for instance.
> In debug output, we can see that for each POM of the reactor there are 
> messages like these, repeatedly for every single parent POM up the complete 
> hierarchy:
> {noformat}
> [DEBUG] Extension realms for project test:grandchild1-1:jar:1.0.0-123: (none)
> [DEBUG] Looking up lifecycle mappings for packaging jar from 
> ClassRealm[plexus.core, parent: null]
> [DEBUG] Extension realms for project test:child1:pom:1.0.0-123: (none)
> [DEBUG] Looking up lifecycle mappings for packaging pom from 
> ClassRealm[plexus.core, parent: null]
> [DEBUG] Extension realms for project test:parent:pom:1.0.0-123: (none)
> [DEBUG] Looking up lifecycle mappings for packaging pom from 
> ClassRealm[plexus.core, parent: null]
> {noformat}
> When using fix version string (release or SNAPSHOT), these messages are only 
> present for the reactor POMs, but not their parents, grand-parents, etc. up 
> to the root POM.
> Looking up the lifecycle mapping for the same parent POMs over and over again 
> seems wrong to me, and is probably the cause of high memory consumption.
> See attached test projects and logs for fix version vs. CI friendly versions.



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

[jira] [Updated] (MNG-6412) Exceeding project discovery time when using CI friendly versions

[Christoph Amshoff (JIRA)]

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

Christoph Amshoff updated MNG-6412:
---
Description: 
We are switching a larger project (> 350 subprojects) to CI friendly versions 
([https://maven.apache.org/maven-ci-friendly.html]), using properties 
_${revision}_ (fix) and _${changelist}_ (maps to the CI build number) to create 
the actual version. However, doing so, the project discovery time (right after 
Maven says “Scanning for projects...”) increases dramatically from few seconds 
to more than 3 minutes, and we had to double the maximum heap in order to avoid 
“GC overhead limit exceeded” exception.

The project root POM looks like this:
{noformat}
  test
  parent
  ${revision}-${changelist}
  pom
  ...
  
1.0.0
    UNDEFINED
   {noformat}
and is built by passing “-Dchangelist=123” to the Maven process for CI build 
123, for instance.

In debug output, we can see that for each POM of the reactor there are messages 
like these, repeatedly for every single parent POM up the complete hierarchy:
{noformat}
[DEBUG] Extension realms for project test:grandchild1-1:jar:1.0.0-123: (none)
[DEBUG] Looking up lifecycle mappings for packaging jar from 
ClassRealm[plexus.core, parent: null]
[DEBUG] Extension realms for project test:child1:pom:1.0.0-123: (none)
[DEBUG] Looking up lifecycle mappings for packaging pom from 
ClassRealm[plexus.core, parent: null]
[DEBUG] Extension realms for project test:parent:pom:1.0.0-123: (none)
[DEBUG] Looking up lifecycle mappings for packaging pom from 
ClassRealm[plexus.core, parent: null]
{noformat}
When using fix version string (release or SNAPSHOT), these messages are only 
present for the reactor POMs, but not their parents, grand-parents, etc. up to 
the root POM.

Looking up the lifecycle mapping for the same parent POMs over and over again 
seems wrong to me, and is probably the cause of high memory consumption.

See attached test projects and logs for fix version vs. CI friendly versions.

  was:
We are switching a larger project (> 350 subprojects) to CI friendly versions 
([https://maven.apache.org/maven-ci-friendly.html]), using properties 
_${revision}_ (fix) and _${changelist}_ (maps to the CI build number) to create 
the actual version. However, doing so, the project discovery time (right after 
Maven says “Scanning for projects...”) increases dramatically from few seconds 
to more than 3 minutes, and we had to double the maximum heap in order to avoid 
“GC overhead limit exceeded” exception.

The project root POM looks like this:
{noformat}
  test
  parent
  ${revision}-${changelist}
  pom
  ...
  
1.0.0
    UNDEFINED
   {noformat}
and is built by passing “-Dchangelist=123” to the Maven process for CI build 
123, for instance.

In debug output, we can see that for each POM of the reactor there are messages 
like these, repeatedly for every single parent POM up the complete hierarchy:
{noformat}
[DEBUG] Extension realms for project test:grandchild1-1:jar:1.0.0-123: (none)
[DEBUG] Looking up lifecycle mappings for packaging jar from 
ClassRealm[plexus.core, parent: null]
[DEBUG] Extension realms for project test:child1:pom:1.0.0-123: (none)
[DEBUG] Looking up lifecycle mappings for packaging pom from 
ClassRealm[plexus.core, parent: null]
[DEBUG] Extension realms for project test:parent:pom:1.0.0-123: (none)
[DEBUG] Looking up lifecycle mappings for packaging pom from 
ClassRealm[plexus.core, parent: null]
{noformat}
When using fix version string (release or SNAPSHOT), these messages are only 
present for the reactor POMs, but not their parents, grand-parents, etc. up to 
the root POM.

Looking up the lifecycle mapping for the same parent POMs over and over again 
seems wrong to me, and is probably the cause of high memory consumption.


> Exceeding project discovery time when using CI friendly versions
> 
>
> Key: MNG-6412
> URL: https://issues.apache.org/jira/browse/MNG-6412
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.3
>Reporter: Christoph Amshoff
>Priority: Critical
> Attachments: ci-version-validate.log, fix-version-validate.log, 
> test-ci-project-scanning.zip
>
>
> We are switching a larger project (> 350 subprojects) to CI friendly versions 
> ([https://maven.apache.org/maven-ci-friendly.html]), using properties 
> _${revision}_ (fix) and _${changelist}_ (maps to the CI build number) to 
> create the actual version. However, doing so, the project discovery time 
> (right after Maven says “Scanning for projects...”) increases dramatically 
> from few seconds to more than 3 minutes, and we had to double the maximum 
> heap in order to avoid “GC overhead limit exceeded” exception.
> The project root POM looks like this:
> {noformat}
>   test
>   parent
>   

[jira] [Updated] (MNG-6412) Exceeding project discovery time when using CI friendly versions

[Christoph Amshoff (JIRA)]

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

Christoph Amshoff updated MNG-6412:
---
Attachment: ci-version-validate.log

> Exceeding project discovery time when using CI friendly versions
> 
>
> Key: MNG-6412
> URL: https://issues.apache.org/jira/browse/MNG-6412
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.3
>Reporter: Christoph Amshoff
>Priority: Critical
> Attachments: ci-version-validate.log, fix-version-validate.log, 
> test-ci-project-scanning.zip
>
>
> We are switching a larger project (> 350 subprojects) to CI friendly versions 
> ([https://maven.apache.org/maven-ci-friendly.html]), using properties 
> _${revision}_ (fix) and _${changelist}_ (maps to the CI build number) to 
> create the actual version. However, doing so, the project discovery time 
> (right after Maven says “Scanning for projects...”) increases dramatically 
> from few seconds to more than 3 minutes, and we had to double the maximum 
> heap in order to avoid “GC overhead limit exceeded” exception.
> The project root POM looks like this:
> {noformat}
>   test
>   parent
>   ${revision}-${changelist}
>   pom
>   ...
>   
> 1.0.0
>     UNDEFINED
>    {noformat}
> and is built by passing “-Dchangelist=123” to the Maven process for CI build 
> 123, for instance.
> In debug output, we can see that for each POM of the reactor there are 
> messages like these, repeatedly for every single parent POM up the complete 
> hierarchy:
> {noformat}
> [DEBUG] Extension realms for project test:grandchild1-1:jar:1.0.0-123: (none)
> [DEBUG] Looking up lifecycle mappings for packaging jar from 
> ClassRealm[plexus.core, parent: null]
> [DEBUG] Extension realms for project test:child1:pom:1.0.0-123: (none)
> [DEBUG] Looking up lifecycle mappings for packaging pom from 
> ClassRealm[plexus.core, parent: null]
> [DEBUG] Extension realms for project test:parent:pom:1.0.0-123: (none)
> [DEBUG] Looking up lifecycle mappings for packaging pom from 
> ClassRealm[plexus.core, parent: null]
> {noformat}
> When using fix version string (release or SNAPSHOT), these messages are only 
> present for the reactor POMs, but not their parents, grand-parents, etc. up 
> to the root POM.
> Looking up the lifecycle mapping for the same parent POMs over and over again 
> seems wrong to me, and is probably the cause of high memory consumption.



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

[jira] [Updated] (MNG-6412) Exceeding project discovery time when using CI friendly versions

[Christoph Amshoff (JIRA)]

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

Christoph Amshoff updated MNG-6412:
---
Attachment: test-ci-project-scanning.zip

> Exceeding project discovery time when using CI friendly versions
> 
>
> Key: MNG-6412
> URL: https://issues.apache.org/jira/browse/MNG-6412
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.3
>Reporter: Christoph Amshoff
>Priority: Critical
> Attachments: fix-version-validate.log, test-ci-project-scanning.zip
>
>
> We are switching a larger project (> 350 subprojects) to CI friendly versions 
> ([https://maven.apache.org/maven-ci-friendly.html]), using properties 
> _${revision}_ (fix) and _${changelist}_ (maps to the CI build number) to 
> create the actual version. However, doing so, the project discovery time 
> (right after Maven says “Scanning for projects...”) increases dramatically 
> from few seconds to more than 3 minutes, and we had to double the maximum 
> heap in order to avoid “GC overhead limit exceeded” exception.
> The project root POM looks like this:
> {noformat}
>   test
>   parent
>   ${revision}-${changelist}
>   pom
>   ...
>   
> 1.0.0
>     UNDEFINED
>    {noformat}
> and is built by passing “-Dchangelist=123” to the Maven process for CI build 
> 123, for instance.
> In debug output, we can see that for each POM of the reactor there are 
> messages like these, repeatedly for every single parent POM up the complete 
> hierarchy:
> {noformat}
> [DEBUG] Extension realms for project test:grandchild1-1:jar:1.0.0-123: (none)
> [DEBUG] Looking up lifecycle mappings for packaging jar from 
> ClassRealm[plexus.core, parent: null]
> [DEBUG] Extension realms for project test:child1:pom:1.0.0-123: (none)
> [DEBUG] Looking up lifecycle mappings for packaging pom from 
> ClassRealm[plexus.core, parent: null]
> [DEBUG] Extension realms for project test:parent:pom:1.0.0-123: (none)
> [DEBUG] Looking up lifecycle mappings for packaging pom from 
> ClassRealm[plexus.core, parent: null]
> {noformat}
> When using fix version string (release or SNAPSHOT), these messages are only 
> present for the reactor POMs, but not their parents, grand-parents, etc. up 
> to the root POM.
> Looking up the lifecycle mapping for the same parent POMs over and over again 
> seems wrong to me, and is probably the cause of high memory consumption.



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

[jira] [Created] (MNG-6412) Exceeding project discovery time when using CI friendly versions

[Christoph Amshoff (JIRA)]

Christoph Amshoff created MNG-6412:
--

 Summary: Exceeding project discovery time when using CI friendly 
versions
 Key: MNG-6412
 URL: https://issues.apache.org/jira/browse/MNG-6412
 Project: Maven
  Issue Type: Bug
Affects Versions: 3.5.3
Reporter: Christoph Amshoff
 Attachments: fix-version-validate.log, test-ci-project-scanning.zip

We are switching a larger project (> 350 subprojects) to CI friendly versions 
([https://maven.apache.org/maven-ci-friendly.html]), using properties 
_${revision}_ (fix) and _${changelist}_ (maps to the CI build number) to create 
the actual version. However, doing so, the project discovery time (right after 
Maven says “Scanning for projects...”) increases dramatically from few seconds 
to more than 3 minutes, and we had to double the maximum heap in order to avoid 
“GC overhead limit exceeded” exception.

The project root POM looks like this:
{noformat}
  test
  parent
  ${revision}-${changelist}
  pom
  ...
  
1.0.0
    UNDEFINED
   {noformat}
and is built by passing “-Dchangelist=123” to the Maven process for CI build 
123, for instance.

In debug output, we can see that for each POM of the reactor there are messages 
like these, repeatedly for every single parent POM up the complete hierarchy:
{noformat}
[DEBUG] Extension realms for project test:grandchild1-1:jar:1.0.0-123: (none)
[DEBUG] Looking up lifecycle mappings for packaging jar from 
ClassRealm[plexus.core, parent: null]
[DEBUG] Extension realms for project test:child1:pom:1.0.0-123: (none)
[DEBUG] Looking up lifecycle mappings for packaging pom from 
ClassRealm[plexus.core, parent: null]
[DEBUG] Extension realms for project test:parent:pom:1.0.0-123: (none)
[DEBUG] Looking up lifecycle mappings for packaging pom from 
ClassRealm[plexus.core, parent: null]
{noformat}
When using fix version string (release or SNAPSHOT), these messages are only 
present for the reactor POMs, but not their parents, grand-parents, etc. up to 
the root POM.

Looking up the lifecycle mapping for the same parent POMs over and over again 
seems wrong to me, and is probably the cause of high memory consumption.



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

[jira] [Updated] (MNG-6412) Exceeding project discovery time when using CI friendly versions

[Christoph Amshoff (JIRA)]

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

Christoph Amshoff updated MNG-6412:
---
Attachment: fix-version-validate.log

> Exceeding project discovery time when using CI friendly versions
> 
>
> Key: MNG-6412
> URL: https://issues.apache.org/jira/browse/MNG-6412
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.3
>Reporter: Christoph Amshoff
>Priority: Critical
> Attachments: fix-version-validate.log, test-ci-project-scanning.zip
>
>
> We are switching a larger project (> 350 subprojects) to CI friendly versions 
> ([https://maven.apache.org/maven-ci-friendly.html]), using properties 
> _${revision}_ (fix) and _${changelist}_ (maps to the CI build number) to 
> create the actual version. However, doing so, the project discovery time 
> (right after Maven says “Scanning for projects...”) increases dramatically 
> from few seconds to more than 3 minutes, and we had to double the maximum 
> heap in order to avoid “GC overhead limit exceeded” exception.
> The project root POM looks like this:
> {noformat}
>   test
>   parent
>   ${revision}-${changelist}
>   pom
>   ...
>   
> 1.0.0
>     UNDEFINED
>    {noformat}
> and is built by passing “-Dchangelist=123” to the Maven process for CI build 
> 123, for instance.
> In debug output, we can see that for each POM of the reactor there are 
> messages like these, repeatedly for every single parent POM up the complete 
> hierarchy:
> {noformat}
> [DEBUG] Extension realms for project test:grandchild1-1:jar:1.0.0-123: (none)
> [DEBUG] Looking up lifecycle mappings for packaging jar from 
> ClassRealm[plexus.core, parent: null]
> [DEBUG] Extension realms for project test:child1:pom:1.0.0-123: (none)
> [DEBUG] Looking up lifecycle mappings for packaging pom from 
> ClassRealm[plexus.core, parent: null]
> [DEBUG] Extension realms for project test:parent:pom:1.0.0-123: (none)
> [DEBUG] Looking up lifecycle mappings for packaging pom from 
> ClassRealm[plexus.core, parent: null]
> {noformat}
> When using fix version string (release or SNAPSHOT), these messages are only 
> present for the reactor POMs, but not their parents, grand-parents, etc. up 
> to the root POM.
> Looking up the lifecycle mapping for the same parent POMs over and over again 
> seems wrong to me, and is probably the cause of high memory consumption.



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

[jira] [Commented] (SUREFIRE-1512) ProcessInfo for Windows is prone to timezone offset changes

[Jan Mosig (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477505#comment-16477505
 ] 

Jan Mosig commented on SUREFIRE-1512:
-

FYI I did encounter this bug while using surefire 2.19.1 with failsafe 2.20.1. 
In this case a workaround for this bug is to disable JVM forking in failsafe:
{code:java}



org.apache.maven.plugins
maven-failsafe-plugin

none



{code}
 

> ProcessInfo for Windows is prone to timezone offset changes
> ---
>
> Key: SUREFIRE-1512
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1512
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.21.0
>Reporter: Julian Reschke
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.0
>
>
> For some reason, on one of my machines, the current DST offset changes 
> between calls. See 
> .
>  This will cause surefire to think the forked VM terminated, as the string 
> compare of time stamps detects a change.
> It would be good if the comparison code would actually parse the string value 
> into a DST/TZ agnostic value for comparison. 



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

[jira] [Comment Edited] (MJAR-238) Allow setting of module main class

[Leonardo Zanivan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477264#comment-16477264
 ] 

Leonardo Zanivan edited comment on MJAR-238 at 5/16/18 11:37 AM:
-

[~rfscholte], ASM 6.1.1+ has support for Java 9 and 10.

Please also support setting module version.

Example:
{code:java}
jar --update --file=myapp.jar --main-class=Main --module-version=1.0.0{code}


was (Author: panga):
[~rfscholte], ASM 6.1.1+ has support for Java 9 and 10.

> Allow setting of module main class
> --
>
> Key: MJAR-238
> URL: https://issues.apache.org/jira/browse/MJAR-238
> Project: Maven JAR Plugin
>  Issue Type: Improvement
> Environment: Java9 build 9+176, MacOS
>Reporter: Machiel Groeneveld
>Assignee: Robert Scholte
>Priority: Minor
>
> When a Java9 module is created using the maven-jar plugin, setting the 
> manifest/mainclass does not set the module main class. Therefore the module 
> is not executable without specifying the main class. Executing the module 
> using java -m domain.app gives the following error:
> _module jigsaw.app does not have a MainClass attribute_
> According to the module specification a module (jar) can have a main class 
> set. If I understand correctly it's inside the module-info.class as a 
> property called ModuleMainClass
> When using the JDK9 jar command it will update the jar and the 
> module-info.class.
> {noformat}
>   -e, --main-class=CLASSNAME The application entry point for stand-alone
>  applications bundled into a modular, or 
> executable,
>  jar archive
> {noformat}
> I guess it would make sense to have this as a separate configuration item 
> since the mainclass entry in the manifest file is not needed in 'module mode' 
> and vice versa.
> If this is a duplicate of another issue, please close this one, I couldn't 
> find any existing issues related to this.



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

[jira] [Commented] (MJAR-238) Allow setting of module main class

[Leonardo Zanivan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477264#comment-16477264
 ] 

Leonardo Zanivan commented on MJAR-238:
---

[~rfscholte], ASM 6.1.1+ has support for Java 9 and 10.

> Allow setting of module main class
> --
>
> Key: MJAR-238
> URL: https://issues.apache.org/jira/browse/MJAR-238
> Project: Maven JAR Plugin
>  Issue Type: Improvement
> Environment: Java9 build 9+176, MacOS
>Reporter: Machiel Groeneveld
>Assignee: Robert Scholte
>Priority: Minor
>
> When a Java9 module is created using the maven-jar plugin, setting the 
> manifest/mainclass does not set the module main class. Therefore the module 
> is not executable without specifying the main class. Executing the module 
> using java -m domain.app gives the following error:
> _module jigsaw.app does not have a MainClass attribute_
> According to the module specification a module (jar) can have a main class 
> set. If I understand correctly it's inside the module-info.class as a 
> property called ModuleMainClass
> When using the JDK9 jar command it will update the jar and the 
> module-info.class.
> {noformat}
>   -e, --main-class=CLASSNAME The application entry point for stand-alone
>  applications bundled into a modular, or 
> executable,
>  jar archive
> {noformat}
> I guess it would make sense to have this as a separate configuration item 
> since the mainclass entry in the manifest file is not needed in 'module mode' 
> and vice versa.
> If this is a duplicate of another issue, please close this one, I couldn't 
> find any existing issues related to this.



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

[jira] [Created] (MPLUGIN-339) maven-plugin-tools-javadoc broken by com.sun.tools.doclets removal in Java 10

[Emmanuel Bourg (JIRA)]

Emmanuel Bourg created MPLUGIN-339:
--

 Summary: maven-plugin-tools-javadoc broken by 
com.sun.tools.doclets removal in Java 10
 Key: MPLUGIN-339
 URL: https://issues.apache.org/jira/browse/MPLUGIN-339
 Project: Maven Plugin Tools
  Issue Type: Bug
  Components: maven-plugin-tools-javadoc
Affects Versions: 3.5.1
Reporter: Emmanuel Bourg


The com.sun.tools.doclets API is no longer available in Java 10, this breaks 
the maven-plugin-tools-javadoc module.



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

[jira] [Commented] (SUREFIRE-1330) JUnit 5 surefire-provider code donation

[Christian Stein (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476921#comment-16476921
 ] 

Christian Stein commented on SUREFIRE-1330:
---

Restart worked out.

Is the documentation in a good shape? See 
[https://github.com/apache/maven-surefire/pull/184/files#diff-794c5135083cc0a67561991ccd77fa43]
 and the files below.

> 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] (MJAVADOC-520) Upgrade plexus-utils/qdox/plexus-archiver/

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476895#comment-16476895
 ] 

Hudson commented on MJAVADOC-520:
-

Build unstable in Jenkins: Maven TLP » maven-javadoc-plugin » MJAVADOC-520 #5

See 
https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/MJAVADOC-520/5/

> Upgrade plexus-utils/qdox/plexus-archiver/
> --
>
> Key: MJAVADOC-520
> URL: https://issues.apache.org/jira/browse/MJAVADOC-520
> Project: Maven Javadoc Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.1
>
>
> * plexus-utils to 3.1.0
> * qdox to 2.0-M8
> * plexus-archiver 3.5, 3.6.0
> * plexus-utils-3.1.0
> * maven-archiver 3.2.0
> * plexus-interactivity-api 1.0-alpha-6



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