[jira] [Commented] (MPLUGIN-335) Support JDK 10 for plugin generation
[ https://issues.apache.org/jira/browse/MPLUGIN-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464546#comment-16464546 ] Hudson commented on MPLUGIN-335: Build failed in Jenkins: Maven TLP » maven-plugin-tools » master #22 See https://builds.apache.org/job/maven-box/job/maven-plugin-tools/job/master/22/ > Support JDK 10 for plugin generation > > > Key: MPLUGIN-335 > URL: https://issues.apache.org/jira/browse/MPLUGIN-335 > Project: Maven Plugin Tools > Issue Type: Dependency upgrade > Components: Plugin Plugin >Affects Versions: 3.5.1 >Reporter: Peter Major >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Major > Fix For: 3.6 > > > The Maven Plugin Plugin currently does not support JDK 10, because the ASM > dependency is currently on 6.0_ALPHA, which does not support class version > 54.0. By upgrading ASM to the latest version, the plugin would be able to > process class files compiled with JDK10. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MPLUGIN-335) Support JDK 10 for plugin generation
[ https://issues.apache.org/jira/browse/MPLUGIN-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy (*$^¨%`£) closed MPLUGIN-335. -- Resolution: Fixed pr merged. Thanks for your contribution! > Support JDK 10 for plugin generation > > > Key: MPLUGIN-335 > URL: https://issues.apache.org/jira/browse/MPLUGIN-335 > Project: Maven Plugin Tools > Issue Type: Dependency upgrade > Components: Plugin Plugin >Affects Versions: 3.5.1 >Reporter: Peter Major >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Major > Fix For: 3.6 > > > The Maven Plugin Plugin currently does not support JDK 10, because the ASM > dependency is currently on 6.0_ALPHA, which does not support class version > 54.0. By upgrading ASM to the latest version, the plugin would be able to > process class files compiled with JDK10. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] olamy closed pull request #9: upgrade to ASM 6.1.1
olamy closed pull request #9: upgrade to ASM 6.1.1 URL: https://github.com/apache/maven-plugin-tools/pull/9 This is a PR merged from a forked repository. As GitHub hides the original diff on merge, it is displayed below for the sake of provenance: As this is a foreign pull request (from a fork), the diff is supplied below (as it won't show otherwise due to GitHub magic): diff --git a/pom.xml b/pom.xml index eb2f0d3f..37b58f95 100644 --- a/pom.xml +++ b/pom.xml @@ -221,12 +221,10 @@ org.ow2.asm asm -5.0.2 org.ow2.asm asm-commons -5.0.2 @@ -432,12 +430,12 @@ org.ow2.asm asm -6.0_ALPHA +6.1.1 org.ow2.asm asm-commons -6.0_ALPHA +6.1.1 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] (MPLUGIN-335) Support JDK 10 for plugin generation
[ https://issues.apache.org/jira/browse/MPLUGIN-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy (*$^¨%`£) updated MPLUGIN-335: --- Fix Version/s: 3.6 > Support JDK 10 for plugin generation > > > Key: MPLUGIN-335 > URL: https://issues.apache.org/jira/browse/MPLUGIN-335 > Project: Maven Plugin Tools > Issue Type: Dependency upgrade > Components: Plugin Plugin >Affects Versions: 3.5.1 >Reporter: Peter Major >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Major > Fix For: 3.6 > > > The Maven Plugin Plugin currently does not support JDK 10, because the ASM > dependency is currently on 6.0_ALPHA, which does not support class version > 54.0. By upgrading ASM to the latest version, the plugin would be able to > process class files compiled with JDK10. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MPLUGIN-335) Support JDK 10 for plugin generation
[ https://issues.apache.org/jira/browse/MPLUGIN-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy (*$^¨%`£) reassigned MPLUGIN-335: -- Assignee: Olivier Lamy (*$^¨%`£) > Support JDK 10 for plugin generation > > > Key: MPLUGIN-335 > URL: https://issues.apache.org/jira/browse/MPLUGIN-335 > Project: Maven Plugin Tools > Issue Type: Dependency upgrade > Components: Plugin Plugin >Affects Versions: 3.5.1 >Reporter: Peter Major >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Major > Fix For: 3.6 > > > The Maven Plugin Plugin currently does not support JDK 10, because the ASM > dependency is currently on 6.0_ALPHA, which does not support class version > 54.0. By upgrading ASM to the latest version, the plugin would be able to > process class files compiled with JDK10. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (WAGON-212) Make FileWagonTest deterministic
[
https://issues.apache.org/jira/browse/WAGON-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated WAGON-212:
-
Affects Version/s: (was: 1.1)
1.0-beta-2
> Make FileWagonTest deterministic
>
>
> Key: WAGON-212
> URL: https://issues.apache.org/jira/browse/WAGON-212
> Project: Maven Wagon
> Issue Type: Task
> Components: wagon-file
>Affects Versions: 1.0-beta-2
> Environment: WinXP, Sun JDK 1.6.0_04, Maven 2.0.9
>Reporter: Benjamin Bentmann
>Assignee: Brett Porter
>Priority: Major
> Fix For: 1.0-beta-3
>
> Attachments: org.apache.maven.wagon.providers.file.FileWagonTest.txt
>
>
> On a random basis, I observe the attached test failure
> {noformat}
> Failed tests:
> testWagon(org.apache.maven.wagon.providers.file.FileWagonTest)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (WAGON-346) LightWeight http wagon not thread-safe
[ https://issues.apache.org/jira/browse/WAGON-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated WAGON-346: - Fix Version/s: (was: 1.1) > LightWeight http wagon not thread-safe > -- > > Key: WAGON-346 > URL: https://issues.apache.org/jira/browse/WAGON-346 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http-lightweight >Affects Versions: 1.0 > Environment: maven 3 with Aether >Reporter: nicolas de loof >Priority: Major > Fix For: 2.0 > > > Aether (maven3) by default parallelized metadata resolution on 4 threads > (aether.metadataResolver.threads) and artifacts downloading on 5 > (maven.artifact.threads). > In such context, Wagon is not used sequentially. > LightWeightHttpWagon is designed for mono-thread, sequential usage. It rely > on system properties and on setting/resetting java.net.Authenticator > singleton. > The result is that, in some cases (typically : when settings defines many > repositories with various credentials), credentials may not apply and > download will fail > A potential fix is > - to use Java5 URL.openConnection(Proxy) instead of using system properties > - to use a shared, singleton java.net.Authenticator that lookup repositories > to match the requested URL -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (WAGON-347) Support preemtive authentication
[ https://issues.apache.org/jira/browse/WAGON-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated WAGON-347: - Fix Version/s: (was: 1.1) > Support preemtive authentication > > > Key: WAGON-347 > URL: https://issues.apache.org/jira/browse/WAGON-347 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http-lightweight >Reporter: nicolas de loof >Assignee: nicolas de loof >Priority: Minor > Fix For: 2.0 > > > Set Authorization header on HttpUrlConnection to get preemptive > authentication and avoid unnecessary network traffic -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (WAGON-89) When you use a call that doesn not use authentication the call should not throw an authentication exception
[ https://issues.apache.org/jira/browse/WAGON-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed WAGON-89. --- Resolution: Won't Fix Fix Version/s: (was: 1.1) Since no one worked on this for ten years, I don't expect this to happen anytime soon. > When you use a call that doesn not use authentication the call should not > throw an authentication exception > > > Key: WAGON-89 > URL: https://issues.apache.org/jira/browse/WAGON-89 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-provider-api >Affects Versions: 1.0-beta-2 >Reporter: Jason van Zyl >Priority: Major > > A general problem with the way we make requests. We should differentiate > between authenticated and non-authenticated requests. To make a call that > requires no authentication like a simple file or http retrieval and have to > trap an authentication error makes no sense and is confusing to consumers of > the API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (WAGON-68) Separate the interfaces for GET vs PUT
[ https://issues.apache.org/jira/browse/WAGON-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed WAGON-68. --- Resolution: Won't Fix Fix Version/s: (was: 1.1) Since no one worked on this for ten years, I don't expect this to happen anytime soon. > Separate the interfaces for GET vs PUT > -- > > Key: WAGON-68 > URL: https://issues.apache.org/jira/browse/WAGON-68 > Project: Maven Wagon > Issue Type: New Feature > Components: wagon-provider-api >Affects Versions: 1.0-beta-2 >Reporter: Jason van Zyl >Priority: Major > > There are cases where I could see simply wanting the GET aspect of a Wagon. > Two cases come to mind: a Grizzly wagon for high-speed GETs from a Jetty > instance running the Grizzly connector; a BT client that would just be doing > GETs. So maybe we could keep the original interfaces and add > WagonRetriever/Getter and WagonPublisher/Putter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCM-714) mvn release:prepare fails if the command line is too long on windows
[ https://issues.apache.org/jira/browse/SCM-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464466#comment-16464466 ] ASF GitHub Bot commented on SCM-714: michael-o commented on issue #30: Fix for SCM-714: mvn release:prepare fails if the command line is too long on windows URL: https://github.com/apache/maven-scm/pull/30#issuecomment-386751463 The line in question produces: Results : Failed tests: GitExeCheckInCommandTckTest>CheckInCommandTckTest.testCheckInCommandPartialFileset:180 check readme.txt contents expected:<[/readme.txt]> but was:<[changed file]> Removing the change makes the test pass. Waiting for comment. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > mvn release:prepare fails if the command line is too long on windows > > > Key: SCM-714 > URL: https://issues.apache.org/jira/browse/SCM-714 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-gitexe >Affects Versions: 1.8.1 >Reporter: Felix Simmendinger >Assignee: Robert Scholte >Priority: Blocker > > The issue from SCM-697 does not solve the issue as the gitprovider is not > using the add command but the checkin command during a release. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] michael-o commented on issue #30: Fix for SCM-714: mvn release:prepare fails if the command line is too long on windows
michael-o commented on issue #30: Fix for SCM-714: mvn release:prepare fails if the command line is too long on windows URL: https://github.com/apache/maven-scm/pull/30#issuecomment-386751463 The line in question produces: Results : Failed tests: GitExeCheckInCommandTckTest>CheckInCommandTckTest.testCheckInCommandPartialFileset:180 check readme.txt contents expected:<[/readme.txt]> but was:<[changed file]> Removing the change makes the test pass. Waiting for comment. 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] (SCM-797) gitexe checkIn() fails due to Windows command line length limitation
[ https://issues.apache.org/jira/browse/SCM-797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated SCM-797: --- Summary: gitexe checkIn() fails due to Windows command line length limitation (was: gitexe add() fails due to Windows command line length limitation) > gitexe checkIn() fails due to Windows command line length limitation > > > Key: SCM-797 > URL: https://issues.apache.org/jira/browse/SCM-797 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-gitexe >Affects Versions: 1.9.4 > Environment: Windows >Reporter: Radovan Murin >Assignee: Michael Osipov >Priority: Critical > Labels: Maven, SCM > Fix For: 1.9.6 > > > Hello, > I noticed that for a project with a large amount of pom files the prepare > command of the release plugin fails when it tries to git add all of the poms. > The failure happens because the SCM plugin attempts to git add all of the > files at once which fails on Windows machines due to the command line length > limitation. > I have written a small fix and created a pull request > https://github.com/apache/maven-scm/pull/30 > Basicaly, with the fix, the command git add iterates on all files rather than > adding them in one command. The fix was already present in the code in > the GitAddCommand.java. However there was one more place in the code with the > bug. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCM-714) mvn release:prepare fails if the command line is too long on windows
[
https://issues.apache.org/jira/browse/SCM-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464439#comment-16464439
]
ASF GitHub Bot commented on SCM-714:
michael-o commented on a change in pull request #30: Fix for SCM-714: mvn
release:prepare fails if the command line is too long on windows
URL: https://github.com/apache/maven-scm/pull/30#discussion_r186231262
##
File path:
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/checkin/GitCheckInCommand.java
##
@@ -144,8 +165,11 @@ protected CheckInScmResult executeCheckInCommand(
ScmProviderRepository repo, Sc
{
return new CheckInScmResult( null,
statusConsumer.getChangedFiles() );
}
-
-Commandline clCommit = createCommitCommandLine( repository,
fileSet, messageFile );
+
+//SCM-714: Workaround for the Windows terminal command limit
+//
+Commandline clCommit = createCommitCommandLine( repository, new
ScmFileSet( fileSet.getBasedir() ),
Review comment:
What is the purpose of this change? This affects `-a` to be added, but we
did already add untracked changes...
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> mvn release:prepare fails if the command line is too long on windows
>
>
> Key: SCM-714
> URL: https://issues.apache.org/jira/browse/SCM-714
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.8.1
>Reporter: Felix Simmendinger
>Assignee: Robert Scholte
>Priority: Blocker
>
> The issue from SCM-697 does not solve the issue as the gitprovider is not
> using the add command but the checkin command during a release.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] michael-o commented on a change in pull request #30: Fix for SCM-714: mvn release:prepare fails if the command line is too long on windows
michael-o commented on a change in pull request #30: Fix for SCM-714: mvn
release:prepare fails if the command line is too long on windows
URL: https://github.com/apache/maven-scm/pull/30#discussion_r186231262
##
File path:
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/checkin/GitCheckInCommand.java
##
@@ -144,8 +165,11 @@ protected CheckInScmResult executeCheckInCommand(
ScmProviderRepository repo, Sc
{
return new CheckInScmResult( null,
statusConsumer.getChangedFiles() );
}
-
-Commandline clCommit = createCommitCommandLine( repository,
fileSet, messageFile );
+
+//SCM-714: Workaround for the Windows terminal command limit
+//
+Commandline clCommit = createCommitCommandLine( repository, new
ScmFileSet( fileSet.getBasedir() ),
Review comment:
What is the purpose of this change? This affects `-a` to be added, but we
did already add untracked changes...
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] (SCM-797) gitexe add() fails due to Windows command line length limitation
[ https://issues.apache.org/jira/browse/SCM-797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated SCM-797: --- Summary: gitexe add() fails due to Windows command line length limitation (was: Fix for windows command line length limitation) > gitexe add() fails due to Windows command line length limitation > > > Key: SCM-797 > URL: https://issues.apache.org/jira/browse/SCM-797 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-gitexe >Affects Versions: 1.9.4 > Environment: Windows >Reporter: Radovan Murin >Assignee: Michael Osipov >Priority: Critical > Labels: Maven, SCM > Fix For: 1.9.6 > > > Hello, > I noticed that for a project with a large amount of pom files the prepare > command of the release plugin fails when it tries to git add all of the poms. > The failure happens because the SCM plugin attempts to git add all of the > files at once which fails on Windows machines due to the command line length > limitation. > I have written a small fix and created a pull request > https://github.com/apache/maven-scm/pull/30 > Basicaly, with the fix, the command git add iterates on all files rather than > adding them in one command. The fix was already present in the code in > the GitAddCommand.java. However there was one more place in the code with the > bug. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SCM-797) Fix for windows command line length limitation
[ https://issues.apache.org/jira/browse/SCM-797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated SCM-797: --- Fix Version/s: 1.9.6 > Fix for windows command line length limitation > -- > > Key: SCM-797 > URL: https://issues.apache.org/jira/browse/SCM-797 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-gitexe >Affects Versions: 1.9.4 > Environment: Windows >Reporter: Radovan Murin >Assignee: Michael Osipov >Priority: Critical > Labels: Maven, SCM > Fix For: 1.9.6 > > > Hello, > I noticed that for a project with a large amount of pom files the prepare > command of the release plugin fails when it tries to git add all of the poms. > The failure happens because the SCM plugin attempts to git add all of the > files at once which fails on Windows machines due to the command line length > limitation. > I have written a small fix and created a pull request > https://github.com/apache/maven-scm/pull/30 > Basicaly, with the fix, the command git add iterates on all files rather than > adding them in one command. The fix was already present in the code in > the GitAddCommand.java. However there was one more place in the code with the > bug. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (SCM-797) Fix for windows command line length limitation
[ https://issues.apache.org/jira/browse/SCM-797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reopened SCM-797: Assignee: Michael Osipov (was: Robert Scholte) Reassigning and reopening as discussed in PR #30. > Fix for windows command line length limitation > -- > > Key: SCM-797 > URL: https://issues.apache.org/jira/browse/SCM-797 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-gitexe >Affects Versions: 1.9.4 > Environment: Windows >Reporter: Radovan Murin >Assignee: Michael Osipov >Priority: Critical > Labels: Maven, SCM > Fix For: 1.9.6 > > > Hello, > I noticed that for a project with a large amount of pom files the prepare > command of the release plugin fails when it tries to git add all of the poms. > The failure happens because the SCM plugin attempts to git add all of the > files at once which fails on Windows machines due to the command line length > limitation. > I have written a small fix and created a pull request > https://github.com/apache/maven-scm/pull/30 > Basicaly, with the fix, the command git add iterates on all files rather than > adding them in one command. The fix was already present in the code in > the GitAddCommand.java. However there was one more place in the code with the > bug. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCM-886) Tests with checkin rely on global git config
[
https://issues.apache.org/jira/browse/SCM-886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464407#comment-16464407
]
Michael Osipov commented on SCM-886:
I added this param to my global config and cannot reproduce it on Windows in
PowerShell. Any advises?
> Tests with checkin rely on global git config
>
>
> Key: SCM-886
> URL: https://issues.apache.org/jira/browse/SCM-886
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5
>Reporter: Matthieu Brouillard
>Priority: Major
>
> Inside maven-scm-provider-gitexe project, the two following tests
> `GitCheckInCommandNoBranchTest.testCheckinNoBranch` and
> `GitCheckInCommandTest.testCheckinAfterRename` expect a global user.name and
> user.email to be set.
> On installations where .gitconfig contains the following:
> {{[user]}}
> {{useConfigOnly = true}}
> The tests will fail.
> It would be better after repository creation to configure a user name & email
> at project level.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (SCM-824) Upgrade Plexus Utils to 3.0.24
[ https://issues.apache.org/jira/browse/SCM-824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed SCM-824. -- Resolution: Fixed Fixed with [04b4c9db64535aa973c4b5a2c02aad562456daa2|https://gitbox.apache.org/repos/asf?p=maven-scm.git;a=commit;h=04b4c9db64535aa973c4b5a2c02aad562456daa2]. Runs like a charm now. > Upgrade Plexus Utils to 3.0.24 > -- > > Key: SCM-824 > URL: https://issues.apache.org/jira/browse/SCM-824 > Project: Maven SCM > Issue Type: Dependency upgrade >Reporter: Christian Schulte >Assignee: Karl Heinz Marbaise >Priority: Trivial > Fix For: 1.9.6 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SCM-869) gitexe list() implemented incorrectly
[ https://issues.apache.org/jira/browse/SCM-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed SCM-869. -- Resolution: Fixed Fixed with [9be3bf0d54f8fde5f2f6f668f5047c1174e7c9d7|https://gitbox.apache.org/repos/asf?p=maven-scm.git;a=commit;h=9be3bf0d54f8fde5f2f6f668f5047c1174e7c9d7]. > gitexe list() implemented incorrectly > - > > Key: SCM-869 > URL: https://issues.apache.org/jira/browse/SCM-869 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-gitexe >Affects Versions: 1.9.5, 1.9.6 >Reporter: Ilya Basin >Assignee: Michael Osipov >Priority: Major > Fix For: 1.9.6 > > > Taking the Svn implementation as a model, ScmProvider.list() should be > implemented as follows: > * The command must directly query the remote repository for files > * A local working copy is unnecessary and if it doesn't exist, the remote > repository must not be checked out. > * fileSet.getBasedir() indicates where to run the scm binary. The > recommended value is ".". > * fileSet.getFileList() indicates the files to list > * repository indicates the repo URL > Git (among other SCMs) does not support listing remote files, so the command > should just fail. > For listing files in a working copy, users should call the > ScmProvider.status() method instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCM-869) gitexe list() implemented incorrectly
[
https://issues.apache.org/jira/browse/SCM-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464371#comment-16464371
]
ASF GitHub Bot commented on SCM-869:
asfgit closed pull request #67: [SCM-869] fix gitexe list() implemented
incorrectly
URL: https://github.com/apache/maven-scm/pull/67
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-git-commons/src/main/java/org/apache/maven/scm/provider/git/AbstractGitScmProvider.java
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-git-commons/src/main/java/org/apache/maven/scm/provider/git/AbstractGitScmProvider.java
index 3609335cd..b26f2688c 100644
---
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-git-commons/src/main/java/org/apache/maven/scm/provider/git/AbstractGitScmProvider.java
+++
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-git-commons/src/main/java/org/apache/maven/scm/provider/git/AbstractGitScmProvider.java
@@ -291,17 +291,6 @@ protected ScmResult executeCommand( GitCommand command,
ScmProviderRepository re
return command.execute( repository, fileSet, parameters );
}
-protected abstract GitCommand getListCommand();
-
-/** {@inheritDoc} */
-public ListScmResult list( ScmProviderRepository repository, ScmFileSet
fileSet, CommandParameters parameters )
-throws ScmException
-{
-GitCommand cmd = getListCommand();
-
-return (ListScmResult) executeCommand( cmd, repository, fileSet,
parameters );
-}
-
protected abstract GitCommand getInfoCommand();
public InfoScmResult info( ScmProviderRepository repository, ScmFileSet
fileSet, CommandParameters parameters )
diff --git
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-git-commons/src/test/java/org/apache/maven/scm/provider/git/TestGitScmProvider.java
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-git-commons/src/test/java/org/apache/maven/scm/provider/git/TestGitScmProvider.java
index 2f596b8b5..3f07e9a31 100644
---
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-git-commons/src/test/java/org/apache/maven/scm/provider/git/TestGitScmProvider.java
+++
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-git-commons/src/test/java/org/apache/maven/scm/provider/git/TestGitScmProvider.java
@@ -81,11 +81,6 @@ protected GitCommand getUpdateCommand()
return null;
}
-protected GitCommand getListCommand()
-{
-return null;
-}
-
protected GitCommand getInfoCommand()
{
return null;
diff --git
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/GitExeScmProvider.java
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/GitExeScmProvider.java
index 24283772f..8f61e86d0 100644
---
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/GitExeScmProvider.java
+++
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/GitExeScmProvider.java
@@ -117,12 +117,6 @@ protected GitCommand getUpdateCommand()
return new GitUpdateCommand();
}
-/** {@inheritDoc} */
-protected GitCommand getListCommand()
-{
-return new GitListCommand();
-}
-
/** {@inheritDoc} */
public GitCommand getInfoCommand()
{
diff --git
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/list/GitListCommand.java
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/list/GitListCommand.java
index 27a90f84e..ffe573347 100644
---
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/list/GitListCommand.java
+++
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/list/GitListCommand.java
@@ -19,63 +19,18 @@
* under the License.
*/
-import org.apache.maven.scm.ScmException;
-import org.apache.maven.scm.ScmFileSet;
-import org.apache.maven.scm.ScmFileStatus;
-import org.apache.maven.scm.ScmVersion;
-import org.apache.maven.scm.command.list.AbstractListCommand;
-import org.apache.maven.scm.command.list.ListScmResult;
-import
[GitHub] asfgit closed pull request #67: [SCM-869] fix gitexe list() implemented incorrectly
asfgit closed pull request #67: [SCM-869] fix gitexe list() implemented
incorrectly
URL: https://github.com/apache/maven-scm/pull/67
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-git-commons/src/main/java/org/apache/maven/scm/provider/git/AbstractGitScmProvider.java
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-git-commons/src/main/java/org/apache/maven/scm/provider/git/AbstractGitScmProvider.java
index 3609335cd..b26f2688c 100644
---
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-git-commons/src/main/java/org/apache/maven/scm/provider/git/AbstractGitScmProvider.java
+++
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-git-commons/src/main/java/org/apache/maven/scm/provider/git/AbstractGitScmProvider.java
@@ -291,17 +291,6 @@ protected ScmResult executeCommand( GitCommand command,
ScmProviderRepository re
return command.execute( repository, fileSet, parameters );
}
-protected abstract GitCommand getListCommand();
-
-/** {@inheritDoc} */
-public ListScmResult list( ScmProviderRepository repository, ScmFileSet
fileSet, CommandParameters parameters )
-throws ScmException
-{
-GitCommand cmd = getListCommand();
-
-return (ListScmResult) executeCommand( cmd, repository, fileSet,
parameters );
-}
-
protected abstract GitCommand getInfoCommand();
public InfoScmResult info( ScmProviderRepository repository, ScmFileSet
fileSet, CommandParameters parameters )
diff --git
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-git-commons/src/test/java/org/apache/maven/scm/provider/git/TestGitScmProvider.java
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-git-commons/src/test/java/org/apache/maven/scm/provider/git/TestGitScmProvider.java
index 2f596b8b5..3f07e9a31 100644
---
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-git-commons/src/test/java/org/apache/maven/scm/provider/git/TestGitScmProvider.java
+++
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-git-commons/src/test/java/org/apache/maven/scm/provider/git/TestGitScmProvider.java
@@ -81,11 +81,6 @@ protected GitCommand getUpdateCommand()
return null;
}
-protected GitCommand getListCommand()
-{
-return null;
-}
-
protected GitCommand getInfoCommand()
{
return null;
diff --git
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/GitExeScmProvider.java
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/GitExeScmProvider.java
index 24283772f..8f61e86d0 100644
---
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/GitExeScmProvider.java
+++
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/GitExeScmProvider.java
@@ -117,12 +117,6 @@ protected GitCommand getUpdateCommand()
return new GitUpdateCommand();
}
-/** {@inheritDoc} */
-protected GitCommand getListCommand()
-{
-return new GitListCommand();
-}
-
/** {@inheritDoc} */
public GitCommand getInfoCommand()
{
diff --git
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/list/GitListCommand.java
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/list/GitListCommand.java
index 27a90f84e..ffe573347 100644
---
a/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/list/GitListCommand.java
+++
b/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/list/GitListCommand.java
@@ -19,63 +19,18 @@
* under the License.
*/
-import org.apache.maven.scm.ScmException;
-import org.apache.maven.scm.ScmFileSet;
-import org.apache.maven.scm.ScmFileStatus;
-import org.apache.maven.scm.ScmVersion;
-import org.apache.maven.scm.command.list.AbstractListCommand;
-import org.apache.maven.scm.command.list.ListScmResult;
-import org.apache.maven.scm.provider.ScmProviderRepository;
-import org.apache.maven.scm.provider.git.command.GitCommand;
-import org.apache.maven.scm.provider.git.repository.GitScmProviderRepository;
+import java.io.File;
+
import
[GitHub] sormuras commented on issue #184: Donate current sources from junit-platform-surefire-provider
sormuras commented on issue #184: Donate current sources from junit-platform-surefire-provider URL: https://github.com/apache/maven-surefire/pull/184#issuecomment-386728323 @Tibor17 Can you please integrate the last two commits as well? The build was successful on my machine and before I write more integration tests, I'd like to know whether I'm on the right track. 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] don-vip commented on issue #9: upgrade to ASM 6.1.1
don-vip commented on issue #9: upgrade to ASM 6.1.1 URL: https://github.com/apache/maven-plugin-tools/pull/9#issuecomment-386717150 Done. 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] (MRAR-53) Upgrade maven-archiver to 3.0.1
[ https://issues.apache.org/jira/browse/MRAR-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MRAR-53: Issue Type: Dependency upgrade (was: Improvement) > Upgrade maven-archiver to 3.0.1 > --- > > Key: MRAR-53 > URL: https://issues.apache.org/jira/browse/MRAR-53 > Project: Maven Rar Plugin > Issue Type: Dependency upgrade >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MRAR-42) Upgrade maven-filtering to 1.3
[ https://issues.apache.org/jira/browse/MRAR-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MRAR-42: Issue Type: Dependency upgrade (was: Improvement) > Upgrade maven-filtering to 1.3 > -- > > Key: MRAR-42 > URL: https://issues.apache.org/jira/browse/MRAR-42 > Project: Maven Rar Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > > Upgrade maven-filtering to 1.3 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] khmarbaise commented on issue #9: upgrade to ASM 6.1.1
khmarbaise commented on issue #9: upgrade to ASM 6.1.1 URL: https://github.com/apache/maven-plugin-tools/pull/9#issuecomment-386714132 Hi, could you please squash your commits and make a commit message like: ``` [MPLUGIN-335] - Support JDK 10 for plugin generation o More description if needed ``` So I would appreciate to merge this into 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] (MPLUGIN-335) Support JDK 10 for plugin generation
Peter Major created MPLUGIN-335: --- Summary: Support JDK 10 for plugin generation Key: MPLUGIN-335 URL: https://issues.apache.org/jira/browse/MPLUGIN-335 Project: Maven Plugin Tools Issue Type: Dependency upgrade Components: Plugin Plugin Affects Versions: 3.5.1 Reporter: Peter Major The Maven Plugin Plugin currently does not support JDK 10, because the ASM dependency is currently on 6.0_ALPHA, which does not support class version 54.0. By upgrading ASM to the latest version, the plugin would be able to process class files compiled with JDK10. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] aldaris commented on issue #9: upgrade to ASM 6.1.1
aldaris commented on issue #9: upgrade to ASM 6.1.1 URL: https://github.com/apache/maven-plugin-tools/pull/9#issuecomment-386712591 Here you go: https://issues.apache.org/jira/browse/MPLUGIN-335 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Comment Edited] (SCM-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=16464228#comment-16464228
]
Michael Osipov edited comment on SCM-885 at 5/4/18 6:18 PM:
You probably misunderstood me. Your patch would take away the ability to do
{{..END}}.
was (Author: michael-o):
You probably misunderstood me. Your patch would take away the ability do do
{{..END}}.
> 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
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.9.6
>
>
> 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=16464228#comment-16464228
]
Michael Osipov commented on SCM-885:
You probably misunderstood me. Your patch would take away the ability do do
{{..END}}.
> 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
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.9.6
>
>
> Invoking execution of a GitChangeLogCommand where only the end revision has
> been set produces a wrong out.
> +Actual result:+
> {{git whatchanged --date=iso ..END_REVISION_SHA1 -- PROJECT_PATH}}
> +Expected result:+ only the end revison SHA1 is used without the two dots
> {{git whatchanged --date=iso END_REVISION_SHA1 -- PROJECT_PATH}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6392) Add Project Settings .mvn/settings.xml
[
https://issues.apache.org/jira/browse/MNG-6392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Z.M. Gao updated MNG-6392:
Description:
Maven originally have two settings slots, user and global. But the project need
and should have more ability to control how itself built by maven. Just follow
the core-extension way, we can add a new settings slot, project settings at
{code:java}
${maven.multiModuleProjectDirectory}/.mvn/settings.xml{code}
Then the settings merge order from high priority to low is
* project level
* user level
* global level
This order is widely used in many projects such as git.
h2. Special fields in projects settings
Some fields should be controlled only by the user, not any project, so they are
always ignored and copied back from user or global level settings:
* localRepository
* interactiveMode
* offline
* usePluginRegistry
* proxies
*
servers.server[].\{username,password,privateKey,passphrase,filePermissions,directoryPermissions}
- ignored and copied from user/global settings
With this feature, many things become easy. When we developing multiply
projects from different organizations/companies/envrionments, the maven
configurations may conflict, and are annoying to manage (edit manually or use
some switch scripts each time we switch the project or environment). Another
problem is when using some corp maven repositories or mirros for bootstraping
the team common root poms or core-extensions, the developers have to do some
setup actions. But the projects should be `mvn verify`-ed out of box.
Here is a [fast implementation via
core-extension|https://github.com/gzm55/project-settings-maven-extension], but
this feature should woks before loading extensions.
was:
Maven originally have two settings slots, user and global. But the project need
and should have more ability to control how itself built by maven. Just follow
the core-extension way, we can add a new settings slot, project settings at
{code:java}
${maven.multiModuleProjectDirectory}/.mvn/settings.xml{code}
Then the settings merge order from high priority to low is
* project level
* user level
* global level
This order is widely used in many projects such as git.
h2. Special fields in projects settings
{{servers.server[].configuration}} will be merged deeply, and prefer ones in
project settings.
Some fields should be controlled only by the user, not any project, so they are
always ignored and copied back from user or global level settings:
* localRepository
* interactiveMode
* offline
* usePluginRegistry
* proxies
*
servers.server[].\{username,password,privateKey,passphrase,filePermissions,directoryPermissions}
With this feature, many things become easy. When we developing multiply
projects from different organizations/companies/envrionments, the maven
configurations may conflict, and are annoying to manage (edit manually or use
some switch scripts each time we switch the project or environment). Another
problem is when using some corp maven repositories or mirros for bootstraping
the team common root poms or core-extensions, the developers have to do some
setup actions. But the projects should be `mvn verify`-ed out of box.
Here is a [fast implementation via
core-extension|https://github.com/gzm55/project-settings-maven-extension], but
this feature should woks before loading extensions.
> Add Project Settings .mvn/settings.xml
> --
>
> Key: MNG-6392
> URL: https://issues.apache.org/jira/browse/MNG-6392
> Project: Maven
> Issue Type: New Feature
> Components: Bootstrap Build, Settings
>Affects Versions: 3.5.3
>Reporter: James Z.M. Gao
>Priority: Major
>
> Maven originally have two settings slots, user and global. But the project
> need and should have more ability to control how itself built by maven. Just
> follow the core-extension way, we can add a new settings slot, project
> settings at
>
> {code:java}
> ${maven.multiModuleProjectDirectory}/.mvn/settings.xml{code}
>
>
> Then the settings merge order from high priority to low is
> * project level
> * user level
> * global level
> This order is widely used in many projects such as git.
>
> h2. Special fields in projects settings
> Some fields should be controlled only by the user, not any project, so they
> are always ignored and copied back from user or global level settings:
> * localRepository
> * interactiveMode
> * offline
> * usePluginRegistry
> * proxies
> *
> servers.server[].\{username,password,privateKey,passphrase,filePermissions,directoryPermissions}
> - ignored and copied from user/global settings
>
>
> With this feature, many things become easy. When we developing multiply
> projects from different organizations/companies/envrionments, the
[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=16464059#comment-16464059
]
Matthieu Brouillard commented on SCM-885:
-
I have no problem with the fact that `git log` interprets `..VERSION` as
`HEAD..VERSION`, my issue is that I want, using the API, to express
`FIRST_COMMIT_OF_REPO..VERSION` ie provide a endVersion but no startVersion.
If a user wants to express `HEAD..VERSION` he has the ability to do so by
explicitly providing a startVersion of HEAD.
With my change you can then express both `FIRST_COMMIT_OF_REPO..VERSION` and
`HEAD..VERSION`.
> 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
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.9.6
>
>
> 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] [Comment Edited] (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=16464007#comment-16464007
]
Michael Osipov edited comment on SCM-885 at 5/4/18 3:24 PM:
It is not per sé wrong:
bq. You can also leave off one side of the syntax to have Git assume HEAD. For
example, you can get the same results as in the previous example by typing git
log origin/master.. — Git substitutes HEAD if one side is missing.
So this will be wrong? Does it make sense to call {{...END}} at all?
Works for me:
{noformat}
osipovmi@blnn719x:~/var/krb5 (master *%>)
$ git log --date=iso ..origin/krb5-1.8 -- . | head
commit 33af1767f876ff4a13f28513dede75e71544523f
Author: Greg Hudson
Date: 2012-02-21 18:57:44 +
Fix kvno ASN.1 encoding interop with Windows RODCs
RFC 4120 defines the EncryptedData kvno field as an integer in the
range of unsigned 32-bit numbers. Windows encodes and decodes the
field as a signed 32-bit integer. Historically we do the same in our
encoder in 1.6 and prior, and in our decoder through 1.10. (Actually,
{noformat}
was (Author: michael-o):
It is not per sé wrong:
bq. You can also leave off one side of the syntax to have Git assume HEAD. For
example, you can get the same results as in the previous example by typing git
log origin/master.. — Git substitutes HEAD if one side is missing.
So this will be wrong? Does it make sense to call {{...END}} at all?
> 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
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.9.6
>
>
> 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=16464007#comment-16464007
]
Michael Osipov commented on SCM-885:
It is not per sé wrong:
bq. You can also leave off one side of the syntax to have Git assume HEAD. For
example, you can get the same results as in the previous example by typing git
log origin/master.. — Git substitutes HEAD if one side is missing.
So this will be wrong? Does it make sense to call {{...END}} at all?
> 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
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.9.6
>
>
> Invoking execution of a GitChangeLogCommand where only the end revision has
> been set produces a wrong out.
> +Actual result:+
> {{git whatchanged --date=iso ..END_REVISION_SHA1 -- PROJECT_PATH}}
> +Expected result:+ only the end revison SHA1 is used without the two dots
> {{git whatchanged --date=iso END_REVISION_SHA1 -- PROJECT_PATH}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set
[
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated SCM-885:
---
Fix Version/s: 1.9.6
> 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
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.9.6
>
>
> 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] [Assigned] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set
[
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned SCM-885:
--
Assignee: Michael Osipov
> 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
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.9.6
>
>
> Invoking execution of a GitChangeLogCommand where only the end revision has
> been set produces a wrong out.
> +Actual result:+
> {{git whatchanged --date=iso ..END_REVISION_SHA1 -- PROJECT_PATH}}
> +Expected result:+ only the end revison SHA1 is used without the two dots
> {{git whatchanged --date=iso END_REVISION_SHA1 -- PROJECT_PATH}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6402) Version of imported POM in DependencyMangement not visible
[
https://issues.apache.org/jira/browse/MNG-6402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6402:
Summary: Version of imported POM in DependencyMangement not visible (was:
Maven Projekt do not see the version of imported POM in DependencyMangement)
> Version of imported POM in DependencyMangement not visible
> --
>
> Key: MNG-6402
> URL: https://issues.apache.org/jira/browse/MNG-6402
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.5.2
>Reporter: Rong Li
>Priority: Major
>
> We have following imported dependency in our pom.xml:
> {code:java}
>
>
>
> my.company
> company-dependency-management
> 1.0.0-SNAPSHOT
> pom
> import
>
>
>
> {code}
> We want to use some plugins to ensure that this dependency should not be
> SNAPSHOT-version before release, but this dependency will be resolved with
> the list of imported dependencies in the effective pom.xml. There is no
> chance to get this SNAPSHOT-version.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] robseidel commented on issue #1: fix DeployAtEnd failures
robseidel commented on issue #1: fix DeployAtEnd failures URL: https://github.com/apache/maven-deploy-plugin/pull/1#issuecomment-386595160 The serialization seems the easiest approach. I've written a quick & dirty modification to serialize/deserialize with XMLEncoder/XMLDecoder - which works with surefire. For the serialization of the MavenProject I've used simply the filename and retrieve the correct MavenProject from the reactorProjects at deserialization. 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] robseidel commented on issue #1: fix DeployAtEnd failures
robseidel commented on issue #1: fix DeployAtEnd failures URL: https://github.com/apache/maven-deploy-plugin/pull/1#issuecomment-386595160 The serialization seems the easiest approach. I've written a quick & dirty modification to serialize/deserialize with XMLEncoder/XMLDecoder - which works with surefire. For the serialization of the MavenProject I've used simply the filename and retrieve the correct Project from the reactorProjects at deserialization. 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] robseidel commented on issue #1: fix DeployAtEnd failures
robseidel commented on issue #1: fix DeployAtEnd failures URL: https://github.com/apache/maven-deploy-plugin/pull/1#issuecomment-386595160 The serialization seems the easiest approach. I've written a quick & dirty modification to serialize/deserialize with XMLEncoder/XMLDecoder - which works with surefire. 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-6386) ${project.baseUri} is not a valid URI (according to RFC 3986)
[
https://issues.apache.org/jira/browse/MNG-6386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6386:
Fix Version/s: (was: 3.5.4-candidate)
3.6.0-candidate
> ${project.baseUri} is not a valid URI (according to RFC 3986)
> -
>
> Key: MNG-6386
> URL: https://issues.apache.org/jira/browse/MNG-6386
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.6.0-candidate
>
>
> {{File#toURI}} produces an invalid URI on Windows:
> {noformat}
> file:/C:/path/to/basedir{noformat}
> A valid URI has to be:
> {noformat}
> file:///C:/path/to/basedir{noformat}
> Same issue for Unix-like OSes:
> {noformat}
> file:/path/to/basedir{noformat}
> A valid URI has to be:
> {noformat}
> file:///path/to/basedir{noformat}
> Using {{Path#toUri}} we can easily solve that problem because it creates
> compliant URIs. The failure occurs when interacting with local Git and
> Subversion repos:
> {noformat}
> PS D:\Entwicklung\Projekte\maven-scm> svn ls
> file:/D:/Entwicklung/svn-repos/scm-svn-test-at-sign
> svn: E020024: Error resolving case of
> 'file:\D:\Entwicklung\svn-repos\scm-svn-test-at-sign'
> while the proper (new) havior will produce a valid URI:
> PS D:\Entwicklung\Projekte\maven-scm> svn ls
> file:///D:/Entwicklung/svn-repos/scm-svn-test-at-sign
> branches/
> tags/
> trunk/
> {noformat}
> {noformat}
> PS D:\Entwicklung\Projekte> git clone file:///D:/Entwicklung/git-repos/toll
> tlll2
> Cloning into 'tlll2'...
> warning: You appear to have cloned an empty repository.
> PS D:\Entwicklung\Projekte> git clone file:/D:/Entwicklung/git-repos/toll
> tlll2
> Cloning into 'tlll2'...
> ssh: Could not resolve hostname file: Name or service not known
> fatal: Could not read from remote repository.
> {noformat}
> or Subversion repo at: {{D:\Entwicklung\svn-repos\это по-русский}}:
> {noformat}
> PS D:\Entwicklung\Projekte> svn ls
> file:/D:/Entwicklung/svn-repos/это%20по-русский/
> svn: E020024: Error resolving case of
> 'file:\D:\Entwicklung\svn-repos\???%20??-???\'
> {noformat}
> proper URI gives:
> {noformat}
> PS D:\Entwicklung\Projekte> svn ls
> file:///D:/Entwicklung/svn-repos/%D1%8D%D1%82%D0%BE%20%D0%BF%D0%BE-%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9/
> branches/
> tags/
> trunk/
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MCHECKSTYLE-351) Plugin execution fails on error when using google_checks
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Schneider updated MCHECKSTYLE-351:
-
Description:
I'm using the version 3.0.0 with Checkstyle 6.18.
This is my initial configuration:
{noformat}
org.apache.maven.plugins
maven-checkstyle-plugin
${maven.checkstyle.plugin.version}
true
true
{noformat}
Running {{mvn checkstyle:checkstyle}} will fail the build since there are
checkstyle errors. This is expected.
{{[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:3.0.0:check (default-cli) on
project demo: Failed during checkstyle execution: There are 311 errors reported
by Checkstyle 6.18 with sun_checks.xml ruleset. -> [Help 1]}}
However, when I use {{google_checks.xml the build succeeds without any error
(checkstyle-report.xml}} still shows the issues).
{noformat}
org.apache.maven.plugins
maven-checkstyle-plugin
${maven.checkstyle.plugin.version}
google_checks.xml
true
true
{noformat}
My expectation would be that the build fails when I use the
{{google_checks.xml}} configuration.
[https://stackoverflow.com/questions/50040980/checkstyle-maven-plugin-doesnt-fail-on-error-when-using-google-checks]
was:
I'm using the version 3.0.0 with Checkstyle 6.18.
This is my initial configuration:
{noformat}
org.apache.maven.plugins
maven-checkstyle-plugin
${maven.checkstyle.plugin.version}
true
true
{noformat}
Running {{mvn checkstyle:checkstyle}} will fail the build since there are
checkstyle errors. This is expected.
{{[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:3.0.0:check (default-cli) on
project demo: Failed during checkstyle execution: There are 311 errors reported
by Checkstyle 6.18 with sun_checks.xml ruleset. -> [Help 1]}}
However, when I use {{google_checks.xml }}the build succeeds without any error
({{checkstyle-report.xml}} still shows the issues).
{noformat}
org.apache.maven.plugins
maven-checkstyle-plugin
${maven.checkstyle.plugin.version}
google_checks.xml
true
true
{noformat}
My expectation would be that the build fails when I use the
{{google_checks.xml}} configuration.
https://stackoverflow.com/questions/50040980/checkstyle-maven-plugin-doesnt-fail-on-error-when-using-google-checks
> Plugin execution fails on error when using google_checks
>
>
> Key: MCHECKSTYLE-351
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-351
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Reporter: Martin Schneider
>Priority: Major
>
>
> I'm using the version 3.0.0 with Checkstyle 6.18.
> This is my initial configuration:
> {noformat}
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
> ${maven.checkstyle.plugin.version}
>
> true
> true
>
> {noformat}
> Running {{mvn checkstyle:checkstyle}} will fail the build since there are
> checkstyle errors. This is expected.
> {{[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:3.0.0:check (default-cli) on
> project demo: Failed during checkstyle execution: There are 311 errors
> reported by Checkstyle 6.18 with sun_checks.xml ruleset. -> [Help 1]}}
> However, when I use {{google_checks.xml the build succeeds without any error
> (checkstyle-report.xml}} still shows the issues).
>
> {noformat}
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
> ${maven.checkstyle.plugin.version}
>
> google_checks.xml
> true
> true
>
> {noformat}
>
> My expectation would be that the build fails when I use the
> {{google_checks.xml}} configuration.
> [https://stackoverflow.com/questions/50040980/checkstyle-maven-plugin-doesnt-fail-on-error-when-using-google-checks]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-526) aggregate goal fails while javadoc goal passes
Leonid Rozenblyum created MJAVADOC-526: -- Summary: aggregate goal fails while javadoc goal passes Key: MJAVADOC-526 URL: https://issues.apache.org/jira/browse/MJAVADOC-526 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 3.0.0 Reporter: Leonid Rozenblyum SCENARIO: (NOTE: see the repository: https://github.com/lrozenblyum/maven-javadoc-plugin-aggregate-bug) Parent and a child project. Child project has dependency with scope: runtime. One of its transitive dependencies is overriden in dependencyManagement with scope: compile The transitive dependency is used in Java code of the chold project and is referred in @throws tag EXPECTED: mvn javadoc:aggregate on the parent project succeeds ACTUALLY: mvn javadoc:aggregate on the parent project fails with error: error: reference not found [ERROR] * @throws BadCredentialsException) mvn javadoc:javaoc on the child project succeeds NOTE: the workaround is rollback to maven-javadoc-plugin 2.10.4 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] sormuras commented on issue #184: Donate current sources from junit-platform-surefire-provider
sormuras commented on issue #184: Donate current sources from junit-platform-surefire-provider URL: https://github.com/apache/maven-surefire/pull/184#issuecomment-386521173 Working-around it for now by ``` [...] org.junit.platform.commons.* ``` 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] sormuras commented on issue #184: Donate current sources from junit-platform-surefire-provider
sormuras commented on issue #184: Donate current sources from junit-platform-surefire-provider URL: https://github.com/apache/maven-surefire/pull/184#issuecomment-386519453 Nice. But `animal-sniffer-maven-plugin` still fails either by not finding a bunch of methods, like: ``` surefire-providers\surefire-junit-platform\src\main\java\org\apache\maven\surefire\junitplatform\JUnitPlatformProvider.java:213: Undefined reference: boolean org.junit.platform.commons.util.StringUtils.isNotBlank(String) surefire-providers\surefire-junit-platform\src\main\java\org\apache\maven\surefire\junitplatform\JUnitPlatformProvider.java:228: Undefined reference: void org.junit.platform.commons.util.Preconditions.condition(boolean, String) ``` or if I comment the exclude for `org.junit.platform:junit-platform-commons` out, it seems to choke due to an out-dated ASM version: ``` org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.15:check (signature-check) on project surefire-junit-platform: Execution signature-check of goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.15:check failed. [...] Caused by: java.lang.IllegalArgumentException at org.objectweb.asm.ClassReader.(Unknown Source) at org.objectweb.asm.ClassReader.(Unknown Source) at org.objectweb.asm.ClassReader.(Unknown Source) at org.codehaus.mojo.animal_sniffer.ClassListBuilder.process(ClassListBuilder.java:71) ``` How do I fix those build errors? 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] sormuras commented on issue #184: Donate current sources from junit-platform-surefire-provider
sormuras commented on issue #184: Donate current sources from junit-platform-surefire-provider URL: https://github.com/apache/maven-surefire/pull/184#issuecomment-386519453 Nice. But `animal-sniffer-maven-plugin` still fails either by not finding a bunch of methods, like: ``` surefire-providers\surefire-junit-platform\src\main\java\org\apache\maven\surefire\junitplatform\JUnitPlatformProvider.java:213: Undefined reference: boolean org.junit.platform.commons.util.StringUtils.isNotBlank(String) surefire-providers\surefire-junit-platform\src\main\java\org\apache\maven\surefire\junitplatform\JUnitPlatformProvider.java:228: Undefined reference: void org.junit.platform.commons.util.Preconditions.condition(boolean, String) ``` or if I comment the exclude for `` out, it seems to choke due to an out-dated ASM version: ``` org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.15:check (signature-check) on project surefire-junit-platform: Execution signature-check of goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.15:check failed. [...] Caused by: java.lang.IllegalArgumentException at org.objectweb.asm.ClassReader.(Unknown Source) at org.objectweb.asm.ClassReader.(Unknown Source) at org.objectweb.asm.ClassReader.(Unknown Source) at org.codehaus.mojo.animal_sniffer.ClassListBuilder.process(ClassListBuilder.java:71) ``` How do I fix those build errors? 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] (MCHECKSTYLE-351) Plugin execution fails on error when using google_checks
Martin Schneider created MCHECKSTYLE-351:
Summary: Plugin execution fails on error when using google_checks
Key: MCHECKSTYLE-351
URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-351
Project: Maven Checkstyle Plugin
Issue Type: Bug
Reporter: Martin Schneider
I'm using the version 3.0.0 with Checkstyle 6.18.
This is my initial configuration:
{noformat}
org.apache.maven.plugins
maven-checkstyle-plugin
${maven.checkstyle.plugin.version}
true
true
{noformat}
Running {{mvn checkstyle:checkstyle}} will fail the build since there are
checkstyle errors. This is expected.
{{[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:3.0.0:check (default-cli) on
project demo: Failed during checkstyle execution: There are 311 errors reported
by Checkstyle 6.18 with sun_checks.xml ruleset. -> [Help 1]}}
However, when I use {{google_checks.xml }}the build succeeds without any error
({{checkstyle-report.xml}} still shows the issues).
{noformat}
org.apache.maven.plugins
maven-checkstyle-plugin
${maven.checkstyle.plugin.version}
google_checks.xml
true
true
{noformat}
My expectation would be that the build fails when I use the
{{google_checks.xml}} configuration.
https://stackoverflow.com/questions/50040980/checkstyle-maven-plugin-doesnt-fail-on-error-when-using-google-checks
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
