[jira] [Commented] (MNG-6410) When a reactor build fails on an artifactId which is not unique, Maven should provide the groupId when suggesting where build should restart from
[
https://issues.apache.org/jira/browse/MNG-6410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479954#comment-16479954
]
ASF GitHub Bot commented on MNG-6410:
-
splatch commented on issue #166: [MNG-6410] Clean suggestion on build resume.
URL: https://github.com/apache/maven/pull/166#issuecomment-390057948
Sure, no problem - I will just strip this commit and update PR. The 6028 was
open for some time so I decided to work on it while I was around.
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
> When a reactor build fails on an artifactId which is not unique, Maven should
> provide the groupId when suggesting where build should restart from
> -
>
> Key: MNG-6410
> URL: https://issues.apache.org/jira/browse/MNG-6410
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.3
>Reporter: Łukasz Dywicki
>Priority: Minor
> Fix For: 3.5.4-candidate
>
>
> In multi module builds same artifact id can be repeated with different group
> id. For example if project strategy is to use nesting of modules, instead of
> using long artifact names, {{ap}} or {{model}} module can occur multiple
> times with different group id.
> By default maven, upon failed build, prints out only {{-rf :artifactId}}.
> When developer will copy given suggestion and run build again then his build
> will be started from first module which have given artifact id.
> While severity of this bug is quite low, it affects productivity in bigger
> projects big time. To improve usability of returned message a Maven should
> return {{-rf groupId:artifactId}} once artifact id is not unique.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] splatch commented on issue #166: [MNG-6410] Clean suggestion on build resume.
splatch commented on issue #166: [MNG-6410] Clean suggestion on build resume. URL: https://github.com/apache/maven/pull/166#issuecomment-390057948 Sure, no problem - I will just strip this commit and update PR. The 6028 was open for some time so I decided to work on it while I was around. 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-6411) Improve readability of project list returned when resume from flag is invalid
[
https://issues.apache.org/jira/browse/MNG-6411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MNG-6411:
---
Description:
When value passed for {{-rf}} option is invalid, a full list of details of all
projects in build is returned.
This list contains too much information. For every project it includes groupId,
artifactId, version and pom location. While it is useful for debugging purposes
many, if not most, developers are interested in specific coordinate
(groupId:artifactId) which should be passed to next execution, and which is
valid {{-rf}} optional value.
*Note that below outputs contain new lines for ease of read*. This could be
also added to exception message to make it more readable.
Assuming, that I've passed -rf :x Current output in case of failure:
{noformat}
ERROR] Could not find project to resume reactor build from: :x vs [
MavenProject: com.example:foobar:1.0.0-SNAPSHOT @
~/sources/foobar/pom.xml,
MavenProject: com.example.foobar:parent:1.0.0-SNAPSHOT @
~/sources/foobar/parent/pom.xml,
MavenProject: com.example.foobar:api:1.0.0-SNAPSHOT @
~/sources/foobar/api/pom.xml,
MavenProject: com.example.foobar:model:1.0.0-SNAPSHOT @
~/sources/foobar/model/pom.xml,
MavenProject: com.example.foobar:csv:1.0.0-SNAPSHOT @
~/sources/foobar/csv/pom.xml,
MavenProject: com.example.foobar.csv:model:1.0.0-SNAPSHOT @
~/sources/foobar/csv/model/pom.xml,
MavenProject: com.example.foobar.csv:api:1.0.0-SNAPSHOT @
~/sources/foobar/csv/api/pom.xml,
MavenProject: com.example.foobar:json:1.0.0-SNAPSHOT @
~/sources/foobar/json/pom.xml,
MavenProject: com.example.foobar.json:model:1.0.0-SNAPSHOT @
~/sources/foobar/json/model/pom.xml,
MavenProject: com.example.foobar.json:api:1.0.0-SNAPSHOT @
~/sources/foobar/json/api/pom.xml,
MavenProject: com.example.foobar.json:core:1.0.0-SNAPSHOT @
~/sources/foobar/json/core/pom.xml,
MavenProject: com.example.foobar:fax:1.0.0-SNAPSHOT @
~/sources/foobar/fax/pom.xml,
MavenProject: com.example.foobar.fax:api:1.0.0-SNAPSHOT @
~/sources/foobar/fax/api/pom.xml,
MavenProject: com.example.foobar.fax:model:1.0.0-SNAPSHOT @
~/sources/foobar/fax/model/pom.xml,
MavenProject: com.example.foobar.fax:web:1.0.0-SNAPSHOT @
~/sources/foobar/fax/web/pom.xml,
MavenProject: com.example.foobar.fax.web:api:1.0.0-SNAPSHOT @
~/sources/foobar/fax/web/api/pom.xml,
MavenProject: com.example.foobar.fax.web:core:1.0.0-SNAPSHOT @
~/sources/foobar/fax/web/core/pom.xml] -> [Help 1]
{noformat}
Additional information about pom locations is irrelevant from message point of
view, because valid input for -rf option is presented below:
{noformat}
ERROR] Could not find project to resume reactor build from: :x vs [
com.example:foobar,
com.example.foobar:parent,
com.example.foobar:api,
com.example.foobar:model,
com.example.foobar:csv,
com.example.foobar.csv:model,
com.example.foobar.csv:api,
com.example.foobar:json,
com.example.foobar.json:model,
com.example.foobar.json:api,
com.example.foobar.json:core,
com.example.foobar:fax,
com.example.foobar.fax:api,
com.example.foobar.fax:model,
com.example.foobar.fax:web,
com.example.foobar.fax.web:api,
com.example.foobar.fax.web:core] -> [Help 1]
{noformat}
was:
When value passed for {{-rf}} option is invalid a full list of details of all
projects in build is returned.
This list contains too much information. For every project it includes groupId,
artifactId, version and pom location. While it is useful for debugging purposes
many, if not most, developers are interested in specific coordinate
(groupId:artifactId) which should be passed to next execution, and which is
valid {{-rf}} optiona value.
Note tat below outputs contain new lines for ease of read. This could be also
added to exception message to make it more readable.
Assuming, that I've passed -rf :x Current output in case of failure:
{noformat}
ERROR] Could not find project to resume reactor build from: :x vs [
MavenProject: com.example:foobar:1.0.0-SNAPSHOT @
~/sources/foobar/pom.xml,
MavenProject: com.example.foobar:parent:1.0.0-SNAPSHOT @
~/sources/foobar/parent/pom.xml,
MavenProject: com.example.foobar:api:1.0.0-SNAPSHOT @
~/sources/foobar/api/pom.xml,
MavenProject: com.example.foobar:model:1.0.0-SNAPSHOT @
~/sources/foobar/model/pom.xml,
MavenProject: com.example.foobar:csv:1.0.0-SNAPSHOT @
~/sources/foobar/csv/pom.xml,
MavenProject: com.example.foobar.csv:model:1.0.0-SNAPSHOT @
~/sources/foobar/csv/model/pom.xml,
MavenProject: com.example.foobar.csv:api:1.0.0-SNAPSHOT @
~/sources/foobar/csv/api/pom.xml,
MavenProject: com.example.foobar:json:1.0.0-SNAPSHOT @
[jira] [Commented] (MNG-6410) When a reactor build fails on an artifactId which is not unique, Maven should provide the groupId when suggesting where build should restart from
[
https://issues.apache.org/jira/browse/MNG-6410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479774#comment-16479774
]
ASF GitHub Bot commented on MNG-6410:
-
splatch commented on issue #166: [MNG-6410] Clean suggestion on build resume.
URL: https://github.com/apache/maven/pull/166#issuecomment-390022505
Sure, no problem - I will just strip this commit and update PR. The 6028 was
open for some time so I decided to work on it while I was around. All CLI
parameters are available in cliRequest. Whole command may be printed with -rf,
if there will be such requirement.
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
> When a reactor build fails on an artifactId which is not unique, Maven should
> provide the groupId when suggesting where build should restart from
> -
>
> Key: MNG-6410
> URL: https://issues.apache.org/jira/browse/MNG-6410
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.3
>Reporter: Łukasz Dywicki
>Priority: Minor
> Fix For: 3.5.4-candidate
>
>
> In multi module builds same artifact id can be repeated with different group
> id. For example if project strategy is to use nesting of modules, instead of
> using long artifact names, {{ap}} or {{model}} module can occur multiple
> times with different group id.
> By default maven, upon failed build, prints out only {{-rf :artifactId}}.
> When developer will copy given suggestion and run build again then his build
> will be started from first module which have given artifact id.
> While severity of this bug is quite low, it affects productivity in bigger
> projects big time. To improve usability of returned message a Maven should
> return {{-rf groupId:artifactId}} once artifact id is not unique.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] splatch commented on issue #166: [MNG-6410] Clean suggestion on build resume.
splatch commented on issue #166: [MNG-6410] Clean suggestion on build resume. URL: https://github.com/apache/maven/pull/166#issuecomment-390022505 Sure, no problem - I will just strip this commit and update PR. The 6028 was open for some time so I decided to work on it while I was around. All CLI parameters are available in cliRequest. Whole command may be printed with -rf, if there will be such requirement. 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] (MNG-6410) When a reactor build fails on an artifactId which is not unique, Maven should provide the groupId when suggesting where build should restart from
[
https://issues.apache.org/jira/browse/MNG-6410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479771#comment-16479771
]
ASF GitHub Bot commented on MNG-6410:
-
hboutemy commented on issue #166: [MNG-6410] Clean suggestion on build resume.
URL: https://github.com/apache/maven/pull/166#issuecomment-390020869
I'm not convinced by MNG-6028: can you create the patch for MNG-6410 without
MNG-6028, please?
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
> When a reactor build fails on an artifactId which is not unique, Maven should
> provide the groupId when suggesting where build should restart from
> -
>
> Key: MNG-6410
> URL: https://issues.apache.org/jira/browse/MNG-6410
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.3
>Reporter: Łukasz Dywicki
>Priority: Minor
> Fix For: 3.5.4-candidate
>
>
> In multi module builds same artifact id can be repeated with different group
> id. For example if project strategy is to use nesting of modules, instead of
> using long artifact names, {{ap}} or {{model}} module can occur multiple
> times with different group id.
> By default maven, upon failed build, prints out only {{-rf :artifactId}}.
> When developer will copy given suggestion and run build again then his build
> will be started from first module which have given artifact id.
> While severity of this bug is quite low, it affects productivity in bigger
> projects big time. To improve usability of returned message a Maven should
> return {{-rf groupId:artifactId}} once artifact id is not unique.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] hboutemy commented on issue #166: [MNG-6410] Clean suggestion on build resume.
hboutemy commented on issue #166: [MNG-6410] Clean suggestion on build resume. URL: https://github.com/apache/maven/pull/166#issuecomment-390020869 I'm not convinced by MNG-6028: can you create the patch for MNG-6410 without MNG-6028, please? 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 #112: Adding support for externally passed random seed and printing used seed on console
Tibor17 commented on a change in pull request #112: Adding support for externally passed random seed and printing used seed on console URL: https://github.com/apache/maven-surefire/pull/112#discussion_r189106324 ## File path: maven-surefire-common/src/test/java/org/apache/maven/plugin/surefire/CommonReflectorTest.java ## @@ -0,0 +1,103 @@ +package org.apache.maven.plugin.surefire; + +/* + * 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. + */ + +import java.io.File; +import java.io.IOException; + +import junit.framework.TestCase; +import org.apache.maven.plugin.surefire.report.DefaultReporterFactory; +import org.apache.maven.shared.utils.io.FileUtils; +import org.apache.maven.surefire.testset.RunOrderParameters; +import org.apache.maven.surefire.util.Randomizer; +import org.apache.maven.surefire.util.RunOrder; + +/** + * @author Krzysztof Suszyński + * @since 2016-04-03 + */ +public class CommonReflectorTest extends TestCase Review comment: Have you registered every new unit test in `JUnit4SuiteTest.java`? If you have not, please do it and run the build `mvn install`. The integration test may take one hour to complete. 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 #112: Adding support for externally passed random seed and printing used seed on console
Tibor17 commented on a change in pull request #112: Adding support for externally passed random seed and printing used seed on console URL: https://github.com/apache/maven-surefire/pull/112#discussion_r189106324 ## File path: maven-surefire-common/src/test/java/org/apache/maven/plugin/surefire/CommonReflectorTest.java ## @@ -0,0 +1,103 @@ +package org.apache.maven.plugin.surefire; + +/* + * 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. + */ + +import java.io.File; +import java.io.IOException; + +import junit.framework.TestCase; +import org.apache.maven.plugin.surefire.report.DefaultReporterFactory; +import org.apache.maven.shared.utils.io.FileUtils; +import org.apache.maven.surefire.testset.RunOrderParameters; +import org.apache.maven.surefire.util.Randomizer; +import org.apache.maven.surefire.util.RunOrder; + +/** + * @author Krzysztof Suszyński + * @since 2016-04-03 + */ +public class CommonReflectorTest extends TestCase Review comment: Have you registered every new unit test in `JUnit4SuiteTest.java`? If you have not, please do it and run the build `mvn install`. The integration test may take obe hour to complete. 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 #112: Adding support for externally passed random seed and printing used seed on console
Tibor17 commented on a change in pull request #112: Adding support for externally passed random seed and printing used seed on console URL: https://github.com/apache/maven-surefire/pull/112#discussion_r189099902 ## File path: maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java ## @@ -283,6 +288,22 @@ @Parameter( property = "failsafe.runOrder", defaultValue = "filesystem" ) private String runOrder; +/** + * When using a random order with runOrder parameter it is useful to be able to pass a seed. + * + * + * This is because, when tests fails to execution order binding, one can use the seed printed in + * reports to execute tests with exact same order as they where when they failed. This effectively reproduce + * the error. To reproduce a given seed most useful is to use command line option: + * + * + * -Dfailsafe.randomSeed=325119 + * + * @since 2.19.2 + */ +@Parameter( property = "failsafe.randomSeed", defaultValue = Randomizer.DEFAULT_SEED ) +private String randomSeed; Review comment: Can we include this in the already existing parameter `runOrder`? For instance, the usage can be `-Dfailsafe.runOrder=random:325119`. 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] (MDEP-612) Upgrade maven-dependency-analyzer to 1.10
[ https://issues.apache.org/jira/browse/MDEP-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479697#comment-16479697 ] Hudson commented on MDEP-612: - Build succeeded in Jenkins: Maven TLP » maven-dependency-plugin » master #15 See https://builds.apache.org/job/maven-box/job/maven-dependency-plugin/job/master/15/ > Upgrade maven-dependency-analyzer to 1.10 > - > > Key: MDEP-612 > URL: https://issues.apache.org/jira/browse/MDEP-612 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.1.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Blocker > Fix For: 3.1.1 > > > We have to wait for the successful VOTE for maven-dependency-analyzer 1.10 > see MSHARED-718 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAR-252) Upgrade plexus-archiver to 3.6.0
[ https://issues.apache.org/jira/browse/MJAR-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479695#comment-16479695 ] Hudson commented on MJAR-252: - Build succeeded in Jenkins: Maven TLP » maven-jar-plugin » master #15 See https://builds.apache.org/job/maven-box/job/maven-jar-plugin/job/master/15/ > Upgrade plexus-archiver to 3.6.0 > > > Key: MJAR-252 > URL: https://issues.apache.org/jira/browse/MJAR-252 > Project: Maven JAR Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.1.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.1.1 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-884) Upgrade plexus-archiver to 3.6.0
[ https://issues.apache.org/jira/browse/MASSEMBLY-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479619#comment-16479619 ] Hudson commented on MASSEMBLY-884: -- Build succeeded in Jenkins: Maven TLP » maven-assembly-plugin » master #9 See https://builds.apache.org/job/maven-box/job/maven-assembly-plugin/job/master/9/ > Upgrade plexus-archiver to 3.6.0 > > > Key: MASSEMBLY-884 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-884 > Project: Maven Assembly Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.1.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Critical > Fix For: 3.1.1 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1522) IndexOutOfBoundsException for System.out.write
[
https://issues.apache.org/jira/browse/SUREFIRE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479609#comment-16479609
]
ASF GitHub Bot commented on SUREFIRE-1522:
--
Tibor17 commented on issue #185: [SUREFIRE-1522] fix escapeBytesToPrintable
bounds check
URL: https://github.com/apache/maven-surefire/pull/185#issuecomment-389987091
@docrjp Great job! I want it but there is a problem with your checkstyle
error because you did not run the build `mvn install`. Simply fix `off+len` and
use white space `off + len`. Override the commit with `git amend`.
This is the error from build log:
```
[INFO] --- maven-checkstyle-plugin:2.15:check (checkstyle-check) @
surefire-api ---
[INFO] There are 2 errors reported by Checkstyle 6.1.1 with
config/maven_checks.xml ruleset.
[ERROR]
src\main\java\org\apache\maven\surefire\util\internal\StringUtils.java[246:84]
(whitespace) WhitespaceAround: '+' is not preceded with whitespace.
[ERROR]
src\main\java\org\apache\maven\surefire\util\internal\StringUtils.java[246:85]
(whitespace) WhitespaceAround: '+' is not followed by whitespace.
```
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
> IndexOutOfBoundsException for System.out.write
> --
>
> Key: SUREFIRE-1522
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1522
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Affects Versions: 2.21.0
>Reporter: Rob Platt
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.0
>
>
> There is a regression, I believe caused by -SUREFIRE-1454-. Git blame seems
> to confirm this; and there was a related regression for empty arrays
> SUREFIRE-1515.
> It can be easily reproduced with the following test:
>
> {code:java}
> import org.junit.jupiter.api.Test;
> import java.nio.charset.StandardCharsets;
> public class SurefireLoggingTest {
> private final byte[] aNiceString = "what fun times, standard out is
> broken\n".getBytes(StandardCharsets.US_ASCII);
> @Test
> public void fun() {
> System.out.write(aNiceString, 5, 3);
> }
> @Test
> public void fun_times() {
> System.out.write(aNiceString, 5, 9);
> }
> }
> {code}
>
> Both tests will pass under Intellij, writing "fun" and "fun times" to
> System.out. Whereas, with Surefire capturing standard out when running from
> maven, only fun_times() passes. fun() will fail with:
>
> {noformat}
> java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >=
> input.length || len > input.length || off > len{noformat}
>
> If you look at the Javadoc contract for PrintStream.write(byte buf[], int
> off, int len), you can see that len is "Number of bytes to write", so you can
> see that it should be fine to print the substring "fun", of length 3, at
> offset 5. And indeed that is what happens in Intellij.
>
> I suspect that the failing test isolates the problem to when the offset
> "exceeds" the length of the substring. The wrong length is being checked in
> StringUtils.escapeBytesToPrintable(). I think that the check intended to
> ensure the offset didn't exceed the end of the byte array, not the length of
> the slice. But that is already covered by "off >= input.length". So there is
> no benefit to also checking "off > len".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] Tibor17 commented on issue #185: [SUREFIRE-1522] fix escapeBytesToPrintable bounds check
Tibor17 commented on issue #185: [SUREFIRE-1522] fix escapeBytesToPrintable bounds check URL: https://github.com/apache/maven-surefire/pull/185#issuecomment-389987091 @docrjp Great job! I want it but there is a problem with your checkstyle error because you did not run the build `mvn install`. Simply fix `off+len` and use white space `off + len`. Override the commit with `git amend`. This is the error from build log: ``` [INFO] --- maven-checkstyle-plugin:2.15:check (checkstyle-check) @ surefire-api --- [INFO] There are 2 errors reported by Checkstyle 6.1.1 with config/maven_checks.xml ruleset. [ERROR] src\main\java\org\apache\maven\surefire\util\internal\StringUtils.java[246:84] (whitespace) WhitespaceAround: '+' is not preceded with whitespace. [ERROR] src\main\java\org\apache\maven\surefire\util\internal\StringUtils.java[246:85] (whitespace) WhitespaceAround: '+' is not followed by whitespace. ``` 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] (MCOMPILER-323) Support multi-release jars
[ https://issues.apache.org/jira/browse/MCOMPILER-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479603#comment-16479603 ] Mike Drob commented on MCOMPILER-323: - Mapping the source directories to unique output directories and compiling them in a separate pass makes sense to me (as described in his next blog post). bq. Creating mrjars will be complex and should be avoided Agree with the first part. Disagree that it needs to be avoided... That's why folks are coming out and asking for tooling for it. We don't have to wait for the unit testing to get easy, or IDE support to get there before we figure out how to support MR jars. If we make MR jars possible, then I believe that surefire executions and IntelliJ integration and all the other missing pieces will follow eventually. As is right now, nobody knows how to take the first step. > Support multi-release jars > -- > > Key: MCOMPILER-323 > URL: https://issues.apache.org/jira/browse/MCOMPILER-323 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: Mike Drob >Priority: Major > > Java 9 allows for JRE version specific code in the form of "multi-release > jars" > Older JREs will treat them as normal jars, while newer JREs will load the > appropriate specific classes. AFAICT, maven does not currently support this. > Compiler plugin should automatically detect when there are multiple source > levels and set MRJAR=True in the manifest. > Source directories could potentially be src/main/java, src/main/java9, > src/main/java10, etc. These probably need to be configurable as well, or some > deeper discussion about what makes sense and is intuitive for users. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1522) IndexOutOfBoundsException for System.out.write
[
https://issues.apache.org/jira/browse/SUREFIRE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1522:
---
Fix Version/s: 2.22.0
> IndexOutOfBoundsException for System.out.write
> --
>
> Key: SUREFIRE-1522
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1522
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Affects Versions: 2.21.0
>Reporter: Rob Platt
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.0
>
>
> There is a regression, I believe caused by -SUREFIRE-1454-. Git blame seems
> to confirm this; and there was a related regression for empty arrays
> SUREFIRE-1515.
> It can be easily reproduced with the following test:
>
> {code:java}
> import org.junit.jupiter.api.Test;
> import java.nio.charset.StandardCharsets;
> public class SurefireLoggingTest {
> private final byte[] aNiceString = "what fun times, standard out is
> broken\n".getBytes(StandardCharsets.US_ASCII);
> @Test
> public void fun() {
> System.out.write(aNiceString, 5, 3);
> }
> @Test
> public void fun_times() {
> System.out.write(aNiceString, 5, 9);
> }
> }
> {code}
>
> Both tests will pass under Intellij, writing "fun" and "fun times" to
> System.out. Whereas, with Surefire capturing standard out when running from
> maven, only fun_times() passes. fun() will fail with:
>
> {noformat}
> java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >=
> input.length || len > input.length || off > len{noformat}
>
> If you look at the Javadoc contract for PrintStream.write(byte buf[], int
> off, int len), you can see that len is "Number of bytes to write", so you can
> see that it should be fine to print the substring "fun", of length 3, at
> offset 5. And indeed that is what happens in Intellij.
>
> I suspect that the failing test isolates the problem to when the offset
> "exceeds" the length of the substring. The wrong length is being checked in
> StringUtils.escapeBytesToPrintable(). I think that the check intended to
> ensure the offset didn't exceed the end of the byte array, not the length of
> the slice. But that is already covered by "off >= input.length". So there is
> no benefit to also checking "off > len".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (SUREFIRE-1522) IndexOutOfBoundsException for System.out.write
[
https://issues.apache.org/jira/browse/SUREFIRE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned SUREFIRE-1522:
--
Assignee: Tibor Digana
> IndexOutOfBoundsException for System.out.write
> --
>
> Key: SUREFIRE-1522
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1522
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Affects Versions: 2.21.0
>Reporter: Rob Platt
>Assignee: Tibor Digana
>Priority: Major
>
> There is a regression, I believe caused by -SUREFIRE-1454-. Git blame seems
> to confirm this; and there was a related regression for empty arrays
> SUREFIRE-1515.
> It can be easily reproduced with the following test:
>
> {code:java}
> import org.junit.jupiter.api.Test;
> import java.nio.charset.StandardCharsets;
> public class SurefireLoggingTest {
> private final byte[] aNiceString = "what fun times, standard out is
> broken\n".getBytes(StandardCharsets.US_ASCII);
> @Test
> public void fun() {
> System.out.write(aNiceString, 5, 3);
> }
> @Test
> public void fun_times() {
> System.out.write(aNiceString, 5, 9);
> }
> }
> {code}
>
> Both tests will pass under Intellij, writing "fun" and "fun times" to
> System.out. Whereas, with Surefire capturing standard out when running from
> maven, only fun_times() passes. fun() will fail with:
>
> {noformat}
> java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >=
> input.length || len > input.length || off > len{noformat}
>
> If you look at the Javadoc contract for PrintStream.write(byte buf[], int
> off, int len), you can see that len is "Number of bytes to write", so you can
> see that it should be fine to print the substring "fun", of length 3, at
> offset 5. And indeed that is what happens in Intellij.
>
> I suspect that the failing test isolates the problem to when the offset
> "exceeds" the length of the substring. The wrong length is being checked in
> StringUtils.escapeBytesToPrintable(). I think that the check intended to
> ensure the offset didn't exceed the end of the byte array, not the length of
> the slice. But that is already covered by "off >= input.length". So there is
> no benefit to also checking "off > len".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAR-252) Upgrade plexus-archiver to 3.6.0
Karl Heinz Marbaise created MJAR-252: Summary: Upgrade plexus-archiver to 3.6.0 Key: MJAR-252 URL: https://issues.apache.org/jira/browse/MJAR-252 Project: Maven JAR Plugin Issue Type: Dependency upgrade Affects Versions: 3.1.1 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: 3.1.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MCOMPILER-323) Support multi-release jars
[ https://issues.apache.org/jira/browse/MCOMPILER-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479551#comment-16479551 ] Robert Scholte commented on MCOMPILER-323: -- I've been inspired by Russels http://www.russgold.net/sw/2018/03/looking-for-mr-good-jar/ while improving https://github.com/codehaus-plexus/plexus-languages/issues/5 and it works quite well. There's only one huge BUT: the fix for plexus-languages works because we have a Travis CI-server which verifies multiple Java versions. And this also means that the unittests are verified for a specific Java version as well. Downside: IDE doesn't understand it and sees it as a duplicate class. Please take a look at the blog and see what matches your situation best. Creating mrjars will be complex and should be avoided. However, if you need it we should be able to configure several execution blocks properly to reach the goal. I'm still interested in the solutions others have. And this should be possible without buildhelper-maven-plugin, just maven-compiler-plugin and execution-blocks (and ignore the testing part, that's an issue for another plugin) > Support multi-release jars > -- > > Key: MCOMPILER-323 > URL: https://issues.apache.org/jira/browse/MCOMPILER-323 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: Mike Drob >Priority: Major > > Java 9 allows for JRE version specific code in the form of "multi-release > jars" > Older JREs will treat them as normal jars, while newer JREs will load the > appropriate specific classes. AFAICT, maven does not currently support this. > Compiler plugin should automatically detect when there are multiple source > levels and set MRJAR=True in the manifest. > Source directories could potentially be src/main/java, src/main/java9, > src/main/java10, etc. These probably need to be configurable as well, or some > deeper discussion about what makes sense and is intuitive for users. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAR-238) Allow setting of module main class
[
https://issues.apache.org/jira/browse/MJAR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479528#comment-16479528
]
Robert Scholte commented on MJAR-238:
-
Plexus Archiver has been changed to support this. Final step would be to
rewrite the plugin a bit to support those new features.
> 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] [Assigned] (MDEP-612) Upgrade maven-dependency-analyzer to 1.10
[ https://issues.apache.org/jira/browse/MDEP-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise reassigned MDEP-612: Assignee: Karl Heinz Marbaise > Upgrade maven-dependency-analyzer to 1.10 > - > > Key: MDEP-612 > URL: https://issues.apache.org/jira/browse/MDEP-612 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.1.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Blocker > Fix For: 3.1.1 > > > We have to wait for the successful VOTE for maven-dependency-analyzer 1.10 > see MSHARED-718 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAR-238) Allow setting of module main class
[
https://issues.apache.org/jira/browse/MJAR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479507#comment-16479507
]
Roberto Araujo commented on MJAR-238:
-
Can I help with this issue? If so, how can I proceed?
> 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] (MJLINK-6) Allow set the jmods path
[ https://issues.apache.org/jira/browse/MJLINK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479508#comment-16479508 ] Roberto Araujo commented on MJLINK-6: - Can I help with this issue? If so, how can I proceed? > Allow set the jmods path > > > Key: MJLINK-6 > URL: https://issues.apache.org/jira/browse/MJLINK-6 > Project: Maven JLink Plugin > Issue Type: Improvement >Affects Versions: 3.0.0-alpha-2 >Reporter: Roberto Araujo >Priority: Minor > > The current version of the plugin hard-coded the `jmods` folder (based on > `jlink` binary location). But, for instance, if I want to build a runtime > image for Linux running the build in a OSX the runtime image will not be > compatible. > I suggest to allow users define the JDK `jmods` folder, and if nothing is > set, use the one based on the JAVA_HOME/Toolchain configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1522) IndexOutOfBoundsException for System.out.write
[
https://issues.apache.org/jira/browse/SUREFIRE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479470#comment-16479470
]
Rob Platt commented on SUREFIRE-1522:
-
I've opened a PR as the friendly bot reports, this is my first ASF pull request
so let me know if I got any details wrong :)
> IndexOutOfBoundsException for System.out.write
> --
>
> Key: SUREFIRE-1522
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1522
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Affects Versions: 2.21.0
>Reporter: Rob Platt
>Priority: Major
>
> There is a regression, I believe caused by -SUREFIRE-1454-. Git blame seems
> to confirm this; and there was a related regression for empty arrays
> SUREFIRE-1515.
> It can be easily reproduced with the following test:
>
> {code:java}
> import org.junit.jupiter.api.Test;
> import java.nio.charset.StandardCharsets;
> public class SurefireLoggingTest {
> private final byte[] aNiceString = "what fun times, standard out is
> broken\n".getBytes(StandardCharsets.US_ASCII);
> @Test
> public void fun() {
> System.out.write(aNiceString, 5, 3);
> }
> @Test
> public void fun_times() {
> System.out.write(aNiceString, 5, 9);
> }
> }
> {code}
>
> Both tests will pass under Intellij, writing "fun" and "fun times" to
> System.out. Whereas, with Surefire capturing standard out when running from
> maven, only fun_times() passes. fun() will fail with:
>
> {noformat}
> java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >=
> input.length || len > input.length || off > len{noformat}
>
> If you look at the Javadoc contract for PrintStream.write(byte buf[], int
> off, int len), you can see that len is "Number of bytes to write", so you can
> see that it should be fine to print the substring "fun", of length 3, at
> offset 5. And indeed that is what happens in Intellij.
>
> I suspect that the failing test isolates the problem to when the offset
> "exceeds" the length of the substring. The wrong length is being checked in
> StringUtils.escapeBytesToPrintable(). I think that the check intended to
> ensure the offset didn't exceed the end of the byte array, not the length of
> the slice. But that is already covered by "off >= input.length". So there is
> no benefit to also checking "off > len".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1522) IndexOutOfBoundsException for System.out.write
[
https://issues.apache.org/jira/browse/SUREFIRE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Platt updated SUREFIRE-1522:
External issue URL: https://github.com/apache/maven-surefire/pull/185
> IndexOutOfBoundsException for System.out.write
> --
>
> Key: SUREFIRE-1522
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1522
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Affects Versions: 2.21.0
>Reporter: Rob Platt
>Priority: Major
>
> There is a regression, I believe caused by -SUREFIRE-1454-. Git blame seems
> to confirm this; and there was a related regression for empty arrays
> SUREFIRE-1515.
> It can be easily reproduced with the following test:
>
> {code:java}
> import org.junit.jupiter.api.Test;
> import java.nio.charset.StandardCharsets;
> public class SurefireLoggingTest {
> private final byte[] aNiceString = "what fun times, standard out is
> broken\n".getBytes(StandardCharsets.US_ASCII);
> @Test
> public void fun() {
> System.out.write(aNiceString, 5, 3);
> }
> @Test
> public void fun_times() {
> System.out.write(aNiceString, 5, 9);
> }
> }
> {code}
>
> Both tests will pass under Intellij, writing "fun" and "fun times" to
> System.out. Whereas, with Surefire capturing standard out when running from
> maven, only fun_times() passes. fun() will fail with:
>
> {noformat}
> java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >=
> input.length || len > input.length || off > len{noformat}
>
> If you look at the Javadoc contract for PrintStream.write(byte buf[], int
> off, int len), you can see that len is "Number of bytes to write", so you can
> see that it should be fine to print the substring "fun", of length 3, at
> offset 5. And indeed that is what happens in Intellij.
>
> I suspect that the failing test isolates the problem to when the offset
> "exceeds" the length of the substring. The wrong length is being checked in
> StringUtils.escapeBytesToPrintable(). I think that the check intended to
> ensure the offset didn't exceed the end of the byte array, not the length of
> the slice. But that is already covered by "off >= input.length". So there is
> no benefit to also checking "off > len".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1522) IndexOutOfBoundsException for System.out.write
[
https://issues.apache.org/jira/browse/SUREFIRE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479466#comment-16479466
]
ASF GitHub Bot commented on SUREFIRE-1522:
--
docrjp opened a new pull request #185: [SUREFIRE-1522] fix
escapeBytesToPrintable bounds check
URL: https://github.com/apache/maven-surefire/pull/185
Proposed new regression test and accompanying fix for SUREFIRE-1522:
https://issues.apache.org/jira/browse/SUREFIRE-1522
The array bounds check now compares off+len to the source length, rather
than off to len.
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
> IndexOutOfBoundsException for System.out.write
> --
>
> Key: SUREFIRE-1522
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1522
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Affects Versions: 2.21.0
>Reporter: Rob Platt
>Priority: Major
>
> There is a regression, I believe caused by -SUREFIRE-1454-. Git blame seems
> to confirm this; and there was a related regression for empty arrays
> SUREFIRE-1515.
> It can be easily reproduced with the following test:
>
> {code:java}
> import org.junit.jupiter.api.Test;
> import java.nio.charset.StandardCharsets;
> public class SurefireLoggingTest {
> private final byte[] aNiceString = "what fun times, standard out is
> broken\n".getBytes(StandardCharsets.US_ASCII);
> @Test
> public void fun() {
> System.out.write(aNiceString, 5, 3);
> }
> @Test
> public void fun_times() {
> System.out.write(aNiceString, 5, 9);
> }
> }
> {code}
>
> Both tests will pass under Intellij, writing "fun" and "fun times" to
> System.out. Whereas, with Surefire capturing standard out when running from
> maven, only fun_times() passes. fun() will fail with:
>
> {noformat}
> java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >=
> input.length || len > input.length || off > len{noformat}
>
> If you look at the Javadoc contract for PrintStream.write(byte buf[], int
> off, int len), you can see that len is "Number of bytes to write", so you can
> see that it should be fine to print the substring "fun", of length 3, at
> offset 5. And indeed that is what happens in Intellij.
>
> I suspect that the failing test isolates the problem to when the offset
> "exceeds" the length of the substring. The wrong length is being checked in
> StringUtils.escapeBytesToPrintable(). I think that the check intended to
> ensure the offset didn't exceed the end of the byte array, not the length of
> the slice. But that is already covered by "off >= input.length". So there is
> no benefit to also checking "off > len".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] docrjp opened a new pull request #185: [SUREFIRE-1522] fix escapeBytesToPrintable bounds check
docrjp opened a new pull request #185: [SUREFIRE-1522] fix escapeBytesToPrintable bounds check URL: https://github.com/apache/maven-surefire/pull/185 Proposed new regression test and accompanying fix for SUREFIRE-1522: https://issues.apache.org/jira/browse/SUREFIRE-1522 The array bounds check now compares off+len to the source length, rather than off to len. 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] (MCOMPILER-323) Support multi-release jars
[
https://issues.apache.org/jira/browse/MCOMPILER-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479408#comment-16479408
]
Mikaël Geljić commented on MCOMPILER-323:
-
Hi there, I'm adding my vote to this one.
I also don't expect a single compiler execution. What's annoying me is that
typically those additional source directories are added through the
build-helper plugin; and the compiler plugin just eats it all and passes that
to the javac {{sourcepath}}
({{…/src/main/java:…/src/main/java9:…/target/generated-sources/annotations:}}).
All we have is exclude filters, which may work for {{module-infos}}, but by
splitting the source dirs we already shift to compile arbitrary java9 sources
\*with jdk9 apis\*; filtering by package/class-name is not an option,
especially as with JEP-238 sources are supposed to overlay one another.
Excludes are only relative to source roots and this is what's limiting here.
Would the compiler plugin consider more awareness of source dirs? Or would it
be kept away as a build-helper plugin concern?
Re: the multi-module approach, I don't buy it, as it generates tons of fuss
maven-wise and slightly ruins the purpose of the JEP which was to address those
different artifact coordinates per java target release.
Long term maybe we can come up with high level config/convention to trigger
multiple compilations & test-runs. Yet for now re: unit-testing, I'd say that's
as much a concern of separate surefire executions upon src/test/java vs.
src/test/java9... in case that's what's blocking here. :)
Cheers,
Mika
> Support multi-release jars
> --
>
> Key: MCOMPILER-323
> URL: https://issues.apache.org/jira/browse/MCOMPILER-323
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Mike Drob
>Priority: Major
>
> Java 9 allows for JRE version specific code in the form of "multi-release
> jars"
> Older JREs will treat them as normal jars, while newer JREs will load the
> appropriate specific classes. AFAICT, maven does not currently support this.
> Compiler plugin should automatically detect when there are multiple source
> levels and set MRJAR=True in the manifest.
> Source directories could potentially be src/main/java, src/main/java9,
> src/main/java10, etc. These probably need to be configurable as well, or some
> deeper discussion about what makes sense and is intuitive for users.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SUREFIRE-1522) IndexOutOfBoundsException for System.out.write
[
https://issues.apache.org/jira/browse/SUREFIRE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479364#comment-16479364
]
Rob Platt edited comment on SUREFIRE-1522 at 5/17/18 5:15 PM:
--
Proposed new tests to cover these regressions in StringUtilsTest:
{code:java}
public void testSubstringSmall()
{
byte[] header = { (byte) 'a' };
byte[] input = "PleaseLookAfterThisBear".getBytes();
EncodedArray encodedArray = StringUtils.escapeBytesToPrintable( header,
input, "Please".length(), "Look".length() );
assertEquals( "Look",
new String(encodedArray.getArray(), 1,
encodedArray.getArray().length-1).trim());
}
public void testSubstringLarge()
{
byte[] header = { (byte) 'a' };
byte[] input = "TheQuickBrownFoxJumpsOverTheLazyDog".getBytes();
EncodedArray encodedArray = StringUtils.escapeBytesToPrintable( header,
input, "The".length(), "QuickBrownFoxJumpsOverTheLazy".length() );
assertEquals( "QuickBrownFoxJumpsOverTheLazy",
new String(encodedArray.getArray(), 1,
encodedArray.getArray().length-1).trim());
}
{code}
Just going to try the tests to ensure that testSubstringSmall() fails with the
current implementation of StringUtils. testSubstringLarge() should already pass.
was (Author: rob.platt):
Proposed new tests to cover these regressions in StringUtilsTest:
{code:java}
public void testSubstringSmall()
{
byte[] header = { (byte) 'a' };
byte[] input = "PleaseLookAfterThisBear".getBytes();
EncodedArray encodedArray = StringUtils.escapeBytesToPrintable( header,
input, "Please".length(), "Look".length() );
assertEquals( "Please".length(), encodedArray.getSize() );
assertEquals( "Look".length(), encodedArray.getArray().length );
}
public void testSubstringLarge()
{
byte[] header = { (byte) 'a' };
byte[] input = "TheQuickBrownFoxJumpsOverTheLazyDog".getBytes();
EncodedArray encodedArray = StringUtils.escapeBytesToPrintable( header,
input, "The".length(), "QuickBrownFoxJumpsOverTheLazy".length() );
assertEquals( "The".length(), encodedArray.getSize() );
assertEquals( "QuickBrownFoxJumpsOverTheLazy".length(),
encodedArray.getArray().length );
}
{code}
Just going to try the tests to ensure that testSubstringSmall() fails with the
current implementation of StringUtils.
> IndexOutOfBoundsException for System.out.write
> --
>
> Key: SUREFIRE-1522
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1522
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Affects Versions: 2.21.0
>Reporter: Rob Platt
>Priority: Major
>
> There is a regression, I believe caused by -SUREFIRE-1454-. Git blame seems
> to confirm this; and there was a related regression for empty arrays
> SUREFIRE-1515.
> It can be easily reproduced with the following test:
>
> {code:java}
> import org.junit.jupiter.api.Test;
> import java.nio.charset.StandardCharsets;
> public class SurefireLoggingTest {
> private final byte[] aNiceString = "what fun times, standard out is
> broken\n".getBytes(StandardCharsets.US_ASCII);
> @Test
> public void fun() {
> System.out.write(aNiceString, 5, 3);
> }
> @Test
> public void fun_times() {
> System.out.write(aNiceString, 5, 9);
> }
> }
> {code}
>
> Both tests will pass under Intellij, writing "fun" and "fun times" to
> System.out. Whereas, with Surefire capturing standard out when running from
> maven, only fun_times() passes. fun() will fail with:
>
> {noformat}
> java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >=
> input.length || len > input.length || off > len{noformat}
>
> If you look at the Javadoc contract for PrintStream.write(byte buf[], int
> off, int len), you can see that len is "Number of bytes to write", so you can
> see that it should be fine to print the substring "fun", of length 3, at
> offset 5. And indeed that is what happens in Intellij.
>
> I suspect that the failing test isolates the problem to when the offset
> "exceeds" the length of the substring. The wrong length is being checked in
> StringUtils.escapeBytesToPrintable(). I think that the check intended to
> ensure the offset didn't exceed the end of the byte array, not the length of
> the slice. But that is already covered by "off >= input.length". So there is
> no benefit to also checking "off > len".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1522) IndexOutOfBoundsException for System.out.write
[
https://issues.apache.org/jira/browse/SUREFIRE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479364#comment-16479364
]
Rob Platt commented on SUREFIRE-1522:
-
Proposed new tests to cover these regressions in StringUtilsTest:
{code:java}
public void testSubstringSmall()
{
byte[] header = { (byte) 'a' };
byte[] input = "PleaseLookAfterThisBear".getBytes();
EncodedArray encodedArray = StringUtils.escapeBytesToPrintable( header,
input, "Please".length(), "Look".length() );
assertEquals( "Please".length(), encodedArray.getSize() );
assertEquals( "Look".length(), encodedArray.getArray().length );
}
public void testSubstringLarge()
{
byte[] header = { (byte) 'a' };
byte[] input = "TheQuickBrownFoxJumpsOverTheLazyDog".getBytes();
EncodedArray encodedArray = StringUtils.escapeBytesToPrintable( header,
input, "The".length(), "QuickBrownFoxJumpsOverTheLazy".length() );
assertEquals( "The".length(), encodedArray.getSize() );
assertEquals( "QuickBrownFoxJumpsOverTheLazy".length(),
encodedArray.getArray().length );
}
{code}
Just going to try the tests to ensure that testSubstringSmall() fails with the
current implementation of StringUtils.
> IndexOutOfBoundsException for System.out.write
> --
>
> Key: SUREFIRE-1522
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1522
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Affects Versions: 2.21.0
>Reporter: Rob Platt
>Priority: Major
>
> There is a regression, I believe caused by -SUREFIRE-1454-. Git blame seems
> to confirm this; and there was a related regression for empty arrays
> SUREFIRE-1515.
> It can be easily reproduced with the following test:
>
> {code:java}
> import org.junit.jupiter.api.Test;
> import java.nio.charset.StandardCharsets;
> public class SurefireLoggingTest {
> private final byte[] aNiceString = "what fun times, standard out is
> broken\n".getBytes(StandardCharsets.US_ASCII);
> @Test
> public void fun() {
> System.out.write(aNiceString, 5, 3);
> }
> @Test
> public void fun_times() {
> System.out.write(aNiceString, 5, 9);
> }
> }
> {code}
>
> Both tests will pass under Intellij, writing "fun" and "fun times" to
> System.out. Whereas, with Surefire capturing standard out when running from
> maven, only fun_times() passes. fun() will fail with:
>
> {noformat}
> java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >=
> input.length || len > input.length || off > len{noformat}
>
> If you look at the Javadoc contract for PrintStream.write(byte buf[], int
> off, int len), you can see that len is "Number of bytes to write", so you can
> see that it should be fine to print the substring "fun", of length 3, at
> offset 5. And indeed that is what happens in Intellij.
>
> I suspect that the failing test isolates the problem to when the offset
> "exceeds" the length of the substring. The wrong length is being checked in
> StringUtils.escapeBytesToPrintable(). I think that the check intended to
> ensure the offset didn't exceed the end of the byte array, not the length of
> the slice. But that is already covered by "off >= input.length". So there is
> no benefit to also checking "off > len".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1522) IndexOutOfBoundsException for System.out.write
[
https://issues.apache.org/jira/browse/SUREFIRE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Platt updated SUREFIRE-1522:
Description:
There is a regression, I believe caused by -SUREFIRE-1454-. Git blame seems to
confirm this; and there was a related regression for empty arrays SUREFIRE-1515.
It can be easily reproduced with the following test:
{code:java}
import org.junit.jupiter.api.Test;
import java.nio.charset.StandardCharsets;
public class SurefireLoggingTest {
private final byte[] aNiceString = "what fun times, standard out is
broken\n".getBytes(StandardCharsets.US_ASCII);
@Test
public void fun() {
System.out.write(aNiceString, 5, 3);
}
@Test
public void fun_times() {
System.out.write(aNiceString, 5, 9);
}
}
{code}
Both tests will pass under Intellij, writing "fun" and "fun times" to
System.out. Whereas, with Surefire capturing standard out when running from
maven, only fun_times() passes. fun() will fail with:
{noformat}
java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >= input.length
|| len > input.length || off > len{noformat}
If you look at the Javadoc contract for PrintStream.write(byte buf[], int off,
int len), you can see that len is "Number of bytes to write", so you can see
that it should be fine to print the substring "fun", of length 3, at offset 5.
And indeed that is what happens in Intellij.
I suspect that the failing test isolates the problem to when the offset
"exceeds" the length of the substring. The wrong length is being checked in
StringUtils.escapeBytesToPrintable(). I think that the check intended to ensure
the offset didn't exceed the end of the byte array, not the length of the
slice. But that is already covered by "off >= input.length". So there is no
benefit to also checking "off > len".
was:
There is a regression, I believe caused by -SUREFIRE-1454-. Git blame seems to
confirm this; and there was a related regression for empty arrays SUREFIRE-1515.
It can be easily reproduced with the following test:
{code:java}
import org.junit.jupiter.api.Test;
import java.nio.charset.StandardCharsets;
public class SurefireLoggingTest {
private final byte[] aNiceString = "what fun times, standard out is
broken\n".getBytes(StandardCharsets.US_ASCII);
@Test
public void fun() {
System.out.write(aNiceString, 5, 3);
}
@Test
public void fun_times() {
System.out.write(aNiceString, 5, 9);
}
}
{code}
Both tests will pass under Intellij, writing "fun" and "fun times" to
System.out. Whereas, with Surefire capturing standard out when running from
maven, only fun_times() passes. fun() will fail with:
{noformat}
java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >= input.length
|| len > input.length || off > len{noformat}
If you look at the contract for PrintStream.write(byte buf[], int off, int
len), you can see that len is "Number of bytes to write", so you can see that
it should be fine to print the substring "fun", of length 3, at offset 5. And
indeed that is what happens in Intellij.
I suspect that the failing test isolates the problem to when the offset
"exceeds" the length of the substring. The wrong length is being checked in
StringUtils.escapeBytesToPrintable(). I think that the check intended to ensure
the offset didn't exceed the end of the byte array, not the length of the
slice. But that is already covered by "off >= input.length". So there is no
benefit to also checking "off > len".
> IndexOutOfBoundsException for System.out.write
> --
>
> Key: SUREFIRE-1522
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1522
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Affects Versions: 2.21.0
>Reporter: Rob Platt
>Priority: Major
>
> There is a regression, I believe caused by -SUREFIRE-1454-. Git blame seems
> to confirm this; and there was a related regression for empty arrays
> SUREFIRE-1515.
> It can be easily reproduced with the following test:
>
> {code:java}
> import org.junit.jupiter.api.Test;
> import java.nio.charset.StandardCharsets;
> public class SurefireLoggingTest {
> private final byte[] aNiceString = "what fun times, standard out is
> broken\n".getBytes(StandardCharsets.US_ASCII);
> @Test
> public void fun() {
> System.out.write(aNiceString, 5, 3);
> }
> @Test
> public void fun_times() {
> System.out.write(aNiceString, 5, 9);
> }
> }
> {code}
>
> Both tests will pass under Intellij, writing "fun" and "fun times" to
> System.out. Whereas, with Surefire capturing standard out when running from
> maven, only fun_times() passes. fun() will fail with:
>
>
[jira] [Updated] (SUREFIRE-1522) IndexOutOfBoundsException for System.out.write
[
https://issues.apache.org/jira/browse/SUREFIRE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Platt updated SUREFIRE-1522:
Description:
There is a regression, I believe caused by -SUREFIRE-1454-. Git blame seems to
confirm this; and there was a related regression for empty arrays SUREFIRE-1515.
It can be easily reproduced with the following test:
{code:java}
import org.junit.jupiter.api.Test;
import java.nio.charset.StandardCharsets;
public class SurefireLoggingTest {
private final byte[] aNiceString = "what fun times, standard out is
broken\n".getBytes(StandardCharsets.US_ASCII);
@Test
public void fun() {
System.out.write(aNiceString, 5, 3);
}
@Test
public void fun_times() {
System.out.write(aNiceString, 5, 9);
}
}
{code}
Both tests will pass under Intellij, writing "fun" and "fun times" to
System.out. Whereas, with Surefire capturing standard out when running from
maven, only fun_times() passes. fun() will fail with:
{noformat}
java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >= input.length
|| len > input.length || off > len{noformat}
If you look at the contract for PrintStream.write(byte buf[], int off, int
len), you can see that len is "Number of bytes to write", so you can see that
it should be fine to print the substring "fun", of length 3, at offset 5. And
indeed that is what happens in Intellij.
I suspect that the failing test isolates the problem to when the offset
"exceeds" the length of the substring. The wrong length is being checked in
StringUtils.escapeBytesToPrintable(). I think that the check intended to ensure
the offset didn't exceed the end of the byte array, not the length of the
slice. But that is already covered by "off >= input.length". So there is no
benefit to also checking "off > len".
was:
There is a regression, I believe caused by -SUREFIRE-1454-. Git blame seems to
confirm this; and there was a related regression for empty arrays SUREFIRE-1515.
It can be easily reproduced with the following test:
{code:java}
import org.junit.jupiter.api.Test;
import java.nio.charset.StandardCharsets;
public class SurefireLoggingTest {
private final byte[] aNiceString = "what fun times, standard out is
broken\n".getBytes(StandardCharsets.US_ASCII);
@Test
public void fun() {
System.out.write(aNiceString, 5, 3);
}
@Test
public void fun_times() {
System.out.write(aNiceString, 5, 9);
}
}
{code}
Both tests will pass under Intellij, writing "fun" and "fun times" to
System.out. Whereas, with Surefire capturing standard out when running from
maven, only fun_times() passes. fun() will fail with:
{noformat}
java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >= input.length
|| len > input.length || off > len{noformat}
If you look at the contract for PrintStream.write(), you can see that len is
"Number of bytes to write", so you can see that it should be fine to print the
substring "fun", of length 3, at offset 5. And indeed that is what happens in
Intellij.
I suspect that the failing test isolates the problem to when the offset
"exceeds" the length of the substring. The wrong length is being checked in
StringUtils.escapeBytesToPrintable(). I think that the check intended to ensure
the offset didn't exceed the end of the byte array, not the length of the
slice. But that is already covered by "off >= input.length". So there is no
benefit to also checking "off > len".
> IndexOutOfBoundsException for System.out.write
> --
>
> Key: SUREFIRE-1522
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1522
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Affects Versions: 2.21.0
>Reporter: Rob Platt
>Priority: Major
>
> There is a regression, I believe caused by -SUREFIRE-1454-. Git blame seems
> to confirm this; and there was a related regression for empty arrays
> SUREFIRE-1515.
> It can be easily reproduced with the following test:
>
> {code:java}
> import org.junit.jupiter.api.Test;
> import java.nio.charset.StandardCharsets;
> public class SurefireLoggingTest {
> private final byte[] aNiceString = "what fun times, standard out is
> broken\n".getBytes(StandardCharsets.US_ASCII);
> @Test
> public void fun() {
> System.out.write(aNiceString, 5, 3);
> }
> @Test
> public void fun_times() {
> System.out.write(aNiceString, 5, 9);
> }
> }
> {code}
>
> Both tests will pass under Intellij, writing "fun" and "fun times" to
> System.out. Whereas, with Surefire capturing standard out when running from
> maven, only fun_times() passes. fun() will fail with:
>
> {noformat}
>
[jira] [Updated] (SUREFIRE-1522) IndexOutOfBoundsException for System.out.write
[
https://issues.apache.org/jira/browse/SUREFIRE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Platt updated SUREFIRE-1522:
Description:
There is a regression, I believe caused by -SUREFIRE-1454-. Git blame seems to
confirm this; and there was a related regression for empty arrays SUREFIRE-1515.
It can be easily reproduced with the following test:
{code:java}
import org.junit.jupiter.api.Test;
import java.nio.charset.StandardCharsets;
public class SurefireLoggingTest {
private final byte[] aNiceString = "what fun times, standard out is
broken\n".getBytes(StandardCharsets.US_ASCII);
@Test
public void fun() {
System.out.write(aNiceString, 5, 3);
}
@Test
public void fun_times() {
System.out.write(aNiceString, 5, 9);
}
}
{code}
Both tests will pass under Intellij, writing "fun" and "fun times" to
System.out. Whereas, with Surefire capturing standard out when running from
maven, only fun_times() passes. fun() will fail with:
{noformat}
java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >= input.length
|| len > input.length || off > len{noformat}
If you look at the contract for PrintStream.write(), you can see that len is
"Number of bytes to write", so you can see that it should be fine to print the
substring "fun", of length 3, at offset 5. And indeed that is what happens in
Intellij.
I suspect that the failing test isolates the problem to when the offset
"exceeds" the length of the substring. The wrong length is being checked in
StringUtils.escapeBytesToPrintable(). I think that the check intended to ensure
the offset didn't exceed the end of the byte array, not the length of the
slice. But that is already covered by "off >= input.length". So there is no
benefit to also checking "off > len".
was:
There is a regression, I believe caused by -SUREFIRE-1454-. Git blame seems to
confirm this; and there was a related regression for empty arrays SUREFIRE-1515.
It can be easily reproduced with the following test:
{code:java}
import org.junit.jupiter.api.Test;
import java.nio.charset.StandardCharsets;
public class SurefireLoggingTest {
private final byte[] aNiceString = "what fun times, standard out is
broken\n".getBytes(StandardCharsets.US_ASCII);
@Test
public void fun() {
System.out.write(aNiceString, 5, 3);
}
@Test
public void fun_times() {
System.out.write(aNiceString, 5, 9);
}
}
{code}
Both tests will pass under Intellij, writing "fun" and "fun times" to
System.out. Whereas, with Surefire capturing standard out when running from
maven, only fun_times() passes. fun() will fail with:
{noformat}
java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >= input.length
|| len > input.length || off > len{noformat}
If you look at the contract for PrintStream.write(), you can see that len is
"Number of bytes to write", so you can see that it should be fine to print the
substring "fun", of length 3, at offset 5. And indeed that is what happens in
Intellij.
I suspect that the failing test isolates the problem to when the offset
"exceeds" the length of the substring. The wrong length is being checked in
StringUtils.escapeBytesToPrintable(). I think that the check intended to ensure
the offset didn't exceed the end of the byte array, not the length of the slice.
> IndexOutOfBoundsException for System.out.write
> --
>
> Key: SUREFIRE-1522
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1522
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Affects Versions: 2.21.0
>Reporter: Rob Platt
>Priority: Major
>
> There is a regression, I believe caused by -SUREFIRE-1454-. Git blame seems
> to confirm this; and there was a related regression for empty arrays
> SUREFIRE-1515.
> It can be easily reproduced with the following test:
>
> {code:java}
> import org.junit.jupiter.api.Test;
> import java.nio.charset.StandardCharsets;
> public class SurefireLoggingTest {
> private final byte[] aNiceString = "what fun times, standard out is
> broken\n".getBytes(StandardCharsets.US_ASCII);
> @Test
> public void fun() {
> System.out.write(aNiceString, 5, 3);
> }
> @Test
> public void fun_times() {
> System.out.write(aNiceString, 5, 9);
> }
> }
> {code}
>
> Both tests will pass under Intellij, writing "fun" and "fun times" to
> System.out. Whereas, with Surefire capturing standard out when running from
> maven, only fun_times() passes. fun() will fail with:
>
> {noformat}
> java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >=
> input.length || len > input.length || off > len{noformat}
>
> If you look at the contract
[jira] [Updated] (SUREFIRE-1522) IndexOutOfBoundsException for System.out.write
[
https://issues.apache.org/jira/browse/SUREFIRE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Platt updated SUREFIRE-1522:
Description:
There is a regression, I believe caused by -SUREFIRE-1454-. Git blame seems to
confirm this; and there was a related regression for empty arrays SUREFIRE-1515.
It can be easily reproduced with the following test:
{code:java}
import org.junit.jupiter.api.Test;
import java.nio.charset.StandardCharsets;
public class SurefireLoggingTest {
private final byte[] aNiceString = "what fun times, standard out is
broken\n".getBytes(StandardCharsets.US_ASCII);
@Test
public void fun() {
System.out.write(aNiceString, 5, 3);
}
@Test
public void fun_times() {
System.out.write(aNiceString, 5, 9);
}
}
{code}
Both tests will pass under Intellij, writing "fun" and "fun times" to
System.out. Whereas, with Surefire capturing standard out when running from
maven, only fun_times() passes. fun() will fail with:
{noformat}
java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >= input.length
|| len > input.length || off > len{noformat}
If you look at the contract for PrintStream.write(), you can see that len is
"Number of bytes to write", so you can see that it should be fine to print the
substring "fun", of length 3, at offset 5. And indeed that is what happens in
Intellij.
I suspect that the failing test isolates the problem to when the offset
"exceeds" the length of the substring. The wrong length is being checked in
StringUtils.escapeBytesToPrintable(). I think that the check intended to ensure
the offset didn't exceed the end of the byte array, not the length of the slice.
was:
There is a regression, I believe caused by SUREFIRE-1454. It can be easily
reproduced with the following test:
{code:java}
import org.junit.jupiter.api.Test;
import java.nio.charset.StandardCharsets;
public class SurefireLoggingTest {
private final byte[] aNiceString = "what fun times, standard out is
broken\n".getBytes(StandardCharsets.US_ASCII);
@Test
public void fun() {
System.out.write(aNiceString, 5, 3);
}
@Test
public void fun_times() {
System.out.write(aNiceString, 5, 9);
}
}
{code}
Both tests will pass under Intellij, writing "fun" and "fun times" to
System.out. Whereas, with Surefire capturing standard out when running from
maven, only fun_times() passes. fun() will fail with:
{noformat}
java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >= input.length
|| len > input.length || off > len{noformat}
If you look at the contract for PrintStream.write(), you can see that len is
"Number of bytes to write", so you can see that it should be fine to print the
substring "fun", of length 3, at offset 5. And indeed that is what happens in
Intellij.
I suspect that the failing test isolates the problem to when the offset
"exceeds" the length of the substring. The wrong length is being checked in
StringUtils.escapeBytesToPrintable(). I think that the check intended to ensure
the offset didn't exceed the end of the byte array, not the length of the slice.
> IndexOutOfBoundsException for System.out.write
> --
>
> Key: SUREFIRE-1522
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1522
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Affects Versions: 2.21.0
>Reporter: Rob Platt
>Priority: Major
>
> There is a regression, I believe caused by -SUREFIRE-1454-. Git blame seems
> to confirm this; and there was a related regression for empty arrays
> SUREFIRE-1515.
> It can be easily reproduced with the following test:
>
> {code:java}
> import org.junit.jupiter.api.Test;
> import java.nio.charset.StandardCharsets;
> public class SurefireLoggingTest {
> private final byte[] aNiceString = "what fun times, standard out is
> broken\n".getBytes(StandardCharsets.US_ASCII);
> @Test
> public void fun() {
> System.out.write(aNiceString, 5, 3);
> }
> @Test
> public void fun_times() {
> System.out.write(aNiceString, 5, 9);
> }
> }
> {code}
>
> Both tests will pass under Intellij, writing "fun" and "fun times" to
> System.out. Whereas, with Surefire capturing standard out when running from
> maven, only fun_times() passes. fun() will fail with:
>
> {noformat}
> java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >=
> input.length || len > input.length || off > len{noformat}
>
> If you look at the contract for PrintStream.write(), you can see that len is
> "Number of bytes to write", so you can see that it should be fine to print
> the substring "fun", of length 3, at offset 5. And indeed that is what
> happens in
[jira] [Updated] (SUREFIRE-1522) IndexOutOfBoundsException for System.out.write
[
https://issues.apache.org/jira/browse/SUREFIRE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Platt updated SUREFIRE-1522:
Description:
There is a regression, I believe caused by SUREFIRE-1454. It can be easily
reproduced with the following test:
{code:java}
import org.junit.jupiter.api.Test;
import java.nio.charset.StandardCharsets;
public class SurefireLoggingTest {
private final byte[] aNiceString = "what fun times, standard out is
broken\n".getBytes(StandardCharsets.US_ASCII);
@Test
public void fun() {
System.out.write(aNiceString, 5, 3);
}
@Test
public void fun_times() {
System.out.write(aNiceString, 5, 9);
}
}
{code}
Both tests will pass under Intellij, writing "fun" and "fun times" to
System.out. Whereas, with Surefire capturing standard out when running from
maven, only fun_times() passes. fun() will fail with:
{noformat}
java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >= input.length
|| len > input.length || off > len{noformat}
If you look at the contract for PrintStream.write(), you can see that len is
"Number of bytes to write", so you can see that it should be fine to print the
substring "fun", of length 3, at offset 5. And indeed that is what happens in
Intellij.
I suspect that the failing test isolates the problem to when the offset
"exceeds" the length of the substring. The wrong length is being checked in
StringUtils.escapeBytesToPrintable(). I think that the check intended to ensure
the offset didn't exceed the end of the byte array, not the length of the slice.
was:
There is a regression, I believe caused by SUREFIRE-1454. It can be easily
reproduced with the following test:
{code:java}
import org.junit.jupiter.api.Test;
import java.nio.charset.StandardCharsets;
public class SurefireLoggingTest {
private final byte[] aNiceString = "what fun times, standard out it
broken\n".getBytes(StandardCharsets.US_ASCII);
@Test
public void fun() {
System.out.write(aNiceString, 5, 3);
}
@Test
public void fun_times() {
System.out.write(aNiceString, 5, 9);
}
}
{code}
Both tests will pass under Intellij, writing "fun" and "fun times" to
System.out. Whereas, with Surefire capturing standard out when running from
maven, only fun_times() passes. fun() will fail with:
{noformat}
java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >= input.length
|| len > input.length || off > len{noformat}
If you look at the contract for PrintStream.write(), you can see that len is
"Number of bytes to write", so you can see that it should be fine to print the
substring "fun", of length 3, at offset 5. And indeed that is what happens in
Intellij.
I suspect that the failing test isolates the problem to when the offset
"exceeds" the length of the substring. The wrong length is being checked in
StringUtils.escapeBytesToPrintable(). I think that the check intended to ensure
the offset didn't exceed the end of the byte array, not the length of the slice.
> IndexOutOfBoundsException for System.out.write
> --
>
> Key: SUREFIRE-1522
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1522
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Affects Versions: 2.21.0
>Reporter: Rob Platt
>Priority: Major
>
> There is a regression, I believe caused by SUREFIRE-1454. It can be easily
> reproduced with the following test:
>
> {code:java}
> import org.junit.jupiter.api.Test;
> import java.nio.charset.StandardCharsets;
> public class SurefireLoggingTest {
> private final byte[] aNiceString = "what fun times, standard out is
> broken\n".getBytes(StandardCharsets.US_ASCII);
> @Test
> public void fun() {
> System.out.write(aNiceString, 5, 3);
> }
> @Test
> public void fun_times() {
> System.out.write(aNiceString, 5, 9);
> }
> }
> {code}
> Both tests will pass under Intellij, writing "fun" and "fun times" to
> System.out. Whereas, with Surefire capturing standard out when running from
> maven, only fun_times() passes. fun() will fail with:
> {noformat}
> java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >=
> input.length || len > input.length || off > len{noformat}
>
> If you look at the contract for PrintStream.write(), you can see that len is
> "Number of bytes to write", so you can see that it should be fine to print
> the substring "fun", of length 3, at offset 5. And indeed that is what
> happens in Intellij.
>
> I suspect that the failing test isolates the problem to when the offset
> "exceeds" the length of the substring. The wrong length is being checked in
> StringUtils.escapeBytesToPrintable(). I think that the
[jira] [Updated] (SUREFIRE-1522) IndexOutOfBoundsException for System.out.write
[
https://issues.apache.org/jira/browse/SUREFIRE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Platt updated SUREFIRE-1522:
Component/s: process forking
Maven Surefire Plugin
Maven Failsafe Plugin
> IndexOutOfBoundsException for System.out.write
> --
>
> Key: SUREFIRE-1522
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1522
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Affects Versions: 2.21.0
>Reporter: Rob Platt
>Priority: Major
>
> There is a regression, I believe caused by SUREFIRE-1454. It can be easily
> reproduced with the following test:
>
> {code:java}
> import org.junit.jupiter.api.Test;
> import java.nio.charset.StandardCharsets;
> public class SurefireLoggingTest {
> private final byte[] aNiceString = "what fun times, standard out it
> broken\n".getBytes(StandardCharsets.US_ASCII);
> @Test
> public void fun() {
> System.out.write(aNiceString, 5, 3);
> }
> @Test
> public void fun_times() {
> System.out.write(aNiceString, 5, 9);
> }
> }
> {code}
> Both tests will pass under Intellij, writing "fun" and "fun times" to
> System.out. Whereas, with Surefire capturing standard out when running from
> maven, only fun_times() passes. fun() will fail with:
> {noformat}
> java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >=
> input.length || len > input.length || off > len{noformat}
>
> If you look at the contract for PrintStream.write(), you can see that len is
> "Number of bytes to write", so you can see that it should be fine to print
> the substring "fun", of length 3, at offset 5. And indeed that is what
> happens in Intellij.
>
> I suspect that the failing test isolates the problem to when the offset
> "exceeds" the length of the substring. The wrong length is being checked in
> StringUtils.escapeBytesToPrintable(). I think that the check intended to
> ensure the offset didn't exceed the end of the byte array, not the length of
> the slice.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1522) IndexOutOfBoundsException for System.out.write
[
https://issues.apache.org/jira/browse/SUREFIRE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Platt updated SUREFIRE-1522:
Description:
There is a regression, I believe caused by SUREFIRE-1454. It can be easily
reproduced with the following test:
{code:java}
import org.junit.jupiter.api.Test;
import java.nio.charset.StandardCharsets;
public class SurefireLoggingTest {
private final byte[] aNiceString = "what fun times, standard out it
broken\n".getBytes(StandardCharsets.US_ASCII);
@Test
public void fun() {
System.out.write(aNiceString, 5, 3);
}
@Test
public void fun_times() {
System.out.write(aNiceString, 5, 9);
}
}
{code}
Both tests will pass under Intellij, writing "fun" and "fun times" to
System.out. Whereas, with Surefire capturing standard out when running from
maven, only fun_times() passes. fun() will fail with:
{noformat}
java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >= input.length
|| len > input.length || off > len{noformat}
If you look at the contract for PrintStream.write(), you can see that len is
"Number of bytes to write", so you can see that it should be fine to print the
substring "fun", of length 3, at offset 5. And indeed that is what happens in
Intellij.
I suspect that the failing test isolates the problem to when the offset
"exceeds" the length of the substring. The wrong length is being checked in
StringUtils.escapeBytesToPrintable(). I think that the check intended to ensure
the offset didn't exceed the end of the byte array, not the length of the slice.
was:
There is a regression, I believe caused by SUREFIRE-1454. It can be easily
reproduced with the following test:
{code:java}
import org.junit.jupiter.api.Test;
import java.nio.charset.StandardCharsets;
public class SurefireLoggingTest {
private final byte[] aNiceString = "what fun times, standard out it
broken\n".getBytes(StandardCharsets.US_ASCII);
@Test
public void fun() {
System.out.write(aNiceString, 5, 3);
}
@Test
public void fun_times() {
System.out.write(aNiceString, 5, 9);
}
}
{code}
Both tests will pass under Intellij, writing "fun" and "fun times" to
System.out. Whereas, with Surefire capturing standard out when running from
maven, only fun_times() passes. fun() will fail. If you look at the contract
for PrintStream.write(), you can see that len is "Number of bytes to write", so
you can see that it should be fine to print the substring "fun", of length 3,
at offset 5. And indeed that is what happens in Intellij.
I suspect that the failing test isolates the problem to when the offset
"exceeds" the length of the substring. The wrong length is being checked in
StringUtils.escapeBytesToPrintable(). I think that the check intended to ensure
the offset didn't exceed the end of the byte array, not the length of the slice.
> IndexOutOfBoundsException for System.out.write
> --
>
> Key: SUREFIRE-1522
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1522
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.21.0
>Reporter: Rob Platt
>Priority: Major
>
> There is a regression, I believe caused by SUREFIRE-1454. It can be easily
> reproduced with the following test:
>
> {code:java}
> import org.junit.jupiter.api.Test;
> import java.nio.charset.StandardCharsets;
> public class SurefireLoggingTest {
> private final byte[] aNiceString = "what fun times, standard out it
> broken\n".getBytes(StandardCharsets.US_ASCII);
> @Test
> public void fun() {
> System.out.write(aNiceString, 5, 3);
> }
> @Test
> public void fun_times() {
> System.out.write(aNiceString, 5, 9);
> }
> }
> {code}
> Both tests will pass under Intellij, writing "fun" and "fun times" to
> System.out. Whereas, with Surefire capturing standard out when running from
> maven, only fun_times() passes. fun() will fail with:
> {noformat}
> java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >=
> input.length || len > input.length || off > len{noformat}
>
> If you look at the contract for PrintStream.write(), you can see that len is
> "Number of bytes to write", so you can see that it should be fine to print
> the substring "fun", of length 3, at offset 5. And indeed that is what
> happens in Intellij.
>
> I suspect that the failing test isolates the problem to when the offset
> "exceeds" the length of the substring. The wrong length is being checked in
> StringUtils.escapeBytesToPrintable(). I think that the check intended to
> ensure the offset didn't exceed the end of the byte array, not the length of
> the slice.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SUREFIRE-1522) IndexOutOfBoundsException for System.out.write
Rob Platt created SUREFIRE-1522:
---
Summary: IndexOutOfBoundsException for System.out.write
Key: SUREFIRE-1522
URL: https://issues.apache.org/jira/browse/SUREFIRE-1522
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.21.0
Reporter: Rob Platt
There is a regression, I believe caused by SUREFIRE-1454. It can be easily
reproduced with the following test:
{code:java}
import org.junit.jupiter.api.Test;
import java.nio.charset.StandardCharsets;
public class SurefireLoggingTest {
private final byte[] aNiceString = "what fun times, standard out it
broken\n".getBytes(StandardCharsets.US_ASCII);
@Test
public void fun() {
System.out.write(aNiceString, 5, 3);
}
@Test
public void fun_times() {
System.out.write(aNiceString, 5, 9);
}
}
{code}
Both tests will pass under Intellij, writing "fun" and "fun times" to
System.out. Whereas, with Surefire capturing standard out when running from
maven, only fun_times() passes. fun() will fail. If you look at the contract
for PrintStream.write(), you can see that len is "Number of bytes to write", so
you can see that it should be fine to print the substring "fun", of length 3,
at offset 5. And indeed that is what happens in Intellij.
I suspect that the failing test isolates the problem to when the offset
"exceeds" the length of the substring. The wrong length is being checked in
StringUtils.escapeBytesToPrintable(). I think that the check intended to ensure
the offset didn't exceed the end of the byte array, not the length of the slice.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MNGSITE-335) missing artifact microsoft :sqljlib42
[ https://issues.apache.org/jira/browse/MNGSITE-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MNGSITE-335. --- Resolution: Not A Problem Assuming you have a network / configuration error. Apart from this. This is not related to the Maven Apache Website ...this is a usage error. Please ask on the users mailing list of in Stackoverflow... > missing artifact microsoft :sqljlib42 > - > > Key: MNGSITE-335 > URL: https://issues.apache.org/jira/browse/MNGSITE-335 > Project: Maven Project Web Site > Issue Type: Bug > Environment: jre 1.8 >Reporter: antonio bucciero >Priority: Minor > Labels: documentation > Attachments: pom.xml > > Original Estimate: 504h > Remaining Estimate: 504h > > java code project in eclipse shows this missing > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd;> -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNGSITE-335) missing artifact microsoft :sqljlib42
antonio bucciero created MNGSITE-335: Summary: missing artifact microsoft :sqljlib42 Key: MNGSITE-335 URL: https://issues.apache.org/jira/browse/MNGSITE-335 Project: Maven Project Web Site Issue Type: Bug Environment: jre 1.8 Reporter: antonio bucciero Attachments: pom.xml java code project in eclipse shows this missing xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd;> -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] cardil commented on issue #112: Adding support for externally passed random seed and printing used seed on console
cardil commented on issue #112: Adding support for externally passed random seed and printing used seed on console URL: https://github.com/apache/maven-surefire/pull/112#issuecomment-389904049 Yes. I'll rebase the code. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set
[
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479030#comment-16479030
]
Matthieu Brouillard commented on SCM-885:
-
{quote}The usecase ..END is covered by START..END where START hast to be
provided as HEAD explicitly
{quote}
you refused the initial PR that was assuming the same for both {{..END}} &
{{START..}} because it was introducing a non compatible change. I do not
understand anymore.
{quote}The last usecase for is that SCM_VERSION is END_SCM_VERSION, I'd expect
users to provide HEAD to avoid ambiguity.
{quote}
I don't understand the sentence. Given the table above there is no ambiguity
anymore because if any of the {{START_SCM_VERSION}} or {{END_SCM_VERSION}} is
provided then it is the syntax {{A..B}} that will be used even if any of A or B
is ommited (null).
{{git whatchanged VERSION}} will only be issued when and only when both
{{START_SCM_VERSION}} and {{END_SCM_VERSION}} are null
I'll provide another PR that implements the table.
> 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] (MENFORCER-185) Require Release Dependencies ignorant about aggregator build
[
https://issues.apache.org/jira/browse/MENFORCER-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478938#comment-16478938
]
ASF GitHub Bot commented on MENFORCER-185:
--
gmshake opened a new pull request #34: [MENFORCER-185] [WIP] Excludes take
reactorProjects into account
URL: https://github.com/apache/maven-enforcer/pull/34
TODO require IT
Enforce only when release
```xml
maven-enforcer-plugin
enforce-no-snapshots
enforce
true
```
Or
```xml
maven-enforcer-plugin
enforce-no-snapshots
enforce
false
${project.groupId}:*
```
ref: https://stackoverflow.com/q/40591346/942671
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
> Require Release Dependencies ignorant about aggregator build
>
>
> Key: MENFORCER-185
> URL: https://issues.apache.org/jira/browse/MENFORCER-185
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.3.1
>Reporter: Thomas Diesler
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: MENFORCER-185.patch, seuss.zip
>
>
> If A depends on B it is ok for A-1.0.0-SNAPSHOT to have snapshot dependency
> on B-1.0.0-SNAPSHOT if B was build before A during the same reactor build.
> Using the requireReleaseDeps rule it seems that SNAPSHOTS are generally not
> allowed even when they belong to the same project and were built during the
> same reactor build.
> We have a complex project with 100+ modules. I want to enforce that no module
> has dependencies on project SNAPSHOTS that were not included in the build. In
> such case A would use a stale version of B that happened to be available in
> the local/remote maven repository.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] gmshake opened a new pull request #34: [MENFORCER-185] [WIP] Excludes take reactorProjects into account
gmshake opened a new pull request #34: [MENFORCER-185] [WIP] Excludes take
reactorProjects into account
URL: https://github.com/apache/maven-enforcer/pull/34
TODO require IT
Enforce only when release
```xml
maven-enforcer-plugin
enforce-no-snapshots
enforce
true
```
Or
```xml
maven-enforcer-plugin
enforce-no-snapshots
enforce
false
${project.groupId}:*
```
ref: https://stackoverflow.com/q/40591346/942671
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set
[
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478896#comment-16478896
]
Michael Osipov commented on SCM-885:
Looks better now, but I do think that we don't need three commands. The usecase
{{..END}} is covered by {{START..END}} where {{START}} hast to be provided as
{{HEAD}} explicitly. The last usecase for is that {{SCM_VERSION}} is
{{END_SCM_VERSION}}, I'd expect users to provide {{HEAD}} to avoid ambiguity.
> GitChangeLogCommand is wrong when only endVersion is set
>
>
> Key: SCM-885
> URL: https://issues.apache.org/jira/browse/SCM-885
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5
>Reporter: Matthieu Brouillard
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: scm-885-different-behavior-exe-jgit-patch.diff
>
>
> Invoking execution of a GitChangeLogCommand where only the end revision has
> been set produces a wrong out.
> +Actual result:+
> {{git whatchanged --date=iso ..END_REVISION_SHA1 -- PROJECT_PATH}}
> +Expected result:+ only the end revison SHA1 is used without the two dots
> {{git whatchanged --date=iso END_REVISION_SHA1 -- PROJECT_PATH}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set
[
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478794#comment-16478794
]
Matthieu Brouillard commented on SCM-885:
-
{quote}The more I think about it
{noformat}
START..
START..END
END
{noformat}{quote}
That's a bit what I initialy wanted to do with the initial PR.
But then how would you differenciate {{..END}} from {{END}} by the usage for
the later of {{CommandParameter.SCM_VERSION}} instead of
{{CommandParameter.END_SCM_VERSION}}?
Now that I have a better overview of the code, I think it could be the best
solution.
This will end for changelog command in git world:
||START_SCM_VERSION||END_SCM_VERSION||SCM_VERSION||git whatchanged
parameters||Description||
| A | B | any, not used | A..B | commits between B and A, A being an ancestor
of B otherwise empty, without A |
| null | B | any, not used | ..B | commits between B and HEAD, HEAD being an
ancestor of B otherwise empty, without HEAD |
| A | null | any, not used | A.. | commits between HEAD and A, A being an
ancestor of HEAD otherwise empty, without A |
| null | null | V | V | all ancestor commits starting from V |
Do you agree that it is the way to go?
> 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-868) gitexe add() does not return added files when invoked in subdir
[
https://issues.apache.org/jira/browse/SCM-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478718#comment-16478718
]
ASF GitHub Bot commented on SCM-868:
basinilya 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_r188872607
##
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:
checked.
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] basinilya commented on a change in pull request #66: [SCM-868] fix gitexe cannot deduce relative path
basinilya 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_r188872607
##
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:
checked.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set
[
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478681#comment-16478681
]
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-389775821
Please also note my comment in the JIRA ticket.
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
michael-o commented on issue #72: [SCM-885] second implementation with new API URL: https://github.com/apache/maven-scm/pull/72#issuecomment-389775821 Please also note my comment in the JIRA ticket. 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] [Created] (MCHANGES-389) ${release.description} is not set for JIRA
Thomas Scheffler created MCHANGES-389:
-
Summary: ${release.description} is not set for JIRA
Key: MCHANGES-389
URL: https://issues.apache.org/jira/browse/MCHANGES-389
Project: Maven Changes Plugin
Issue Type: Bug
Affects Versions: 2.12.1
Reporter: Thomas Scheffler
[Using a Custom Announcement
Template|https://maven.apache.org/plugins/maven-changes-plugin/examples/using-a-custom-announcement-template.html]
states that {{$\{release.description}}} can be used in templates. This does
not work with Jira where the release has a description set.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set
[
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478678#comment-16478678
]
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_r188864492
##
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:
Just throw `UnsupportedOperationException`.
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
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_r188864492
##
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:
Just throw `UnsupportedOperationException`.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set
[
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478673#comment-16478673
]
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_r188864134
##
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:
But isn't that the end, not the start? You are giving one ref from which log
goes back in time, doesn't it?
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
[
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478672#comment-16478672
]
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_r188864134
##
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:
But isn't that the end, not the start? You are giving one ref from which log
goes back in time. Doesn't it?
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
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_r188864134 ## 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: But isn't that the end, not the start? You are giving one ref from which log goes back in time, doesn't it? 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
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_r188864134 ## 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: But isn't that the end, not the start? You are giving one ref from which log goes back in time. Doesn't it? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set
[
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478638#comment-16478638
]
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_r188856738
##
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:
My bad, it is already indented with four chars. All is fine.
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
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_r188856738 ## 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: My bad, it is already indented with four chars. All is fine. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set
[
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478627#comment-16478627
]
ASF GitHub Bot commented on SCM-885:
McFoggy commented on issue #72: [SCM-885] second implementation with new API
URL: https://github.com/apache/maven-scm/pull/72#issuecomment-389764542
@michael-o I have taken your remarks into account and rebased to resolve the
conflicts.
If you want I can squash the commits.
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 issue #72: [SCM-885] second implementation with new API
McFoggy commented on issue #72: [SCM-885] second implementation with new API URL: https://github.com/apache/maven-scm/pull/72#issuecomment-389764542 @michael-o I have taken your remarks into account and rebased to resolve the conflicts. If you want I can squash the commits. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set
[
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478603#comment-16478603
]
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_r188849611
##
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:
was to have a default non throwing exception behavior ; i'll use `throw new
ScmException( "Unsupported method for this provider." );` instead
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
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_r188849611
##
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:
was to have a default non throwing exception behavior ; i'll use `throw new
ScmException( "Unsupported method for this provider." );` instead
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
