[jira] [Commented] (MJAVADOC-469) javadoc-plugin does not double backslashes in argument file
[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16730092#comment-16730092
]
Ilya Basin commented on MJAVADOC-469:
-
bq. additionalOptions-doc-improvement
looks fine.
I forgot: do and friends duplicate backslashes?
> javadoc-plugin does not double backslashes in argument file
> ---
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Ilya Basin
>Assignee: Michael Osipov
>Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] eolivelli commented on issue #3: [MWAR-371] Overlays break first-win rule for web resource with target path ending with '/'
eolivelli commented on issue #3: [MWAR-371] Overlays break first-win rule for web resource with target path ending with '/' URL: https://github.com/apache/maven-war-plugin/pull/3#issuecomment-450306404 @andretadeu this is the CI job https://builds.apache.org/job/maven-box/job/maven-war-plugin/job/MWAR-371/ I have squashed all of your commits into one, see branch MWAR-371 here on github 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] Pr0methean commented on issue #79: [SCM-318] Untag command, with Git implementations
Pr0methean commented on issue #79: [SCM-318] Untag command, with Git implementations URL: https://github.com/apache/maven-scm/pull/79#issuecomment-450293692 @michael-o Ping. 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] (WAGON-543) wagon-ssh download hangs
[ https://issues.apache.org/jira/browse/WAGON-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated WAGON-543: --- Description: To reproduce this issue 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 Assume your local account can ssh to same host with ssh key other notes: * No problem with maven 3.6.0 * I also have internal ssh library wrapper of wagon-ssh to perform sshexe/upload/download activities. Seeing the same issue with wagon 3.3.0 * The root cause likely is from WAGON-537 with changes at AbstractWagon which may have side effect on internal JSCH 32K buffer was: To reproduce this issue 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 Assume your local account can ssh to same host with ssh key other notes: * No problem with maven 3.6.0 * I also have internal ssh library wrapper of wagon-ssh to perform sshexe/upload/download activities. Seeing the same issue when pickup wagon 3.3.0 * The root cause likely is from WAGON-537 with changes at AbstractWagon which may have side effect on internal JSCH 32K buffer > wagon-ssh download hangs > > > Key: WAGON-543 > URL: https://issues.apache.org/jira/browse/WAGON-543 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh >Affects Versions: 3.3.0 >Reporter: Dan Tran >Priority: Major > > To reproduce this issue > 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git > 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with > 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 > Assume your local account can ssh to same host with ssh key > other notes: > * No problem with maven 3.6.0 > * I also have internal ssh library wrapper of wagon-ssh to perform > sshexe/upload/download activities. Seeing the same issue with wagon 3.3.0 > * The root cause likely is from WAGON-537 with changes at AbstractWagon > which may have side effect on internal JSCH 32K buffer -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (WAGON-543) wagon-ssh download hangs
[ https://issues.apache.org/jira/browse/WAGON-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated WAGON-543: --- Description: To reproduce this issue 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 Assume your local account can ssh to same host with ssh key other notes: * No problem with maven 3.6.0 * I also have internal ssh library wrapper of wagon-ssh to perform sshexe/upload/download activities. Seeing the same issue when pickup wagon 3.3.0 * The root cause likely is from WAGON-537 with changes at AbstractWagon which may have side effect on internal JSCH 32K buffer was: To reproduce this issue 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 Assume your local account can ssh to same host with ssh key other notes: * No problem with maven 3.6.0 * I also have internal ssh library wrapper of wagon-ssh to perform sshexe/upload/download activities. Seeing the same issue when pickup wagon 3.3.0 * The root cause likely is from WAGON-537 with changes at AbstractWagon which may have side effect on internal jcsh 32K buffer > wagon-ssh download hangs > > > Key: WAGON-543 > URL: https://issues.apache.org/jira/browse/WAGON-543 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh >Affects Versions: 3.3.0 >Reporter: Dan Tran >Priority: Major > > To reproduce this issue > 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git > 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with > 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 > Assume your local account can ssh to same host with ssh key > other notes: > * No problem with maven 3.6.0 > * I also have internal ssh library wrapper of wagon-ssh to perform > sshexe/upload/download activities. Seeing the same issue when pickup wagon > 3.3.0 > * The root cause likely is from WAGON-537 with changes at AbstractWagon > which may have side effect on internal JSCH 32K buffer -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (WAGON-543) wagon-ssh download hangs
[ https://issues.apache.org/jira/browse/WAGON-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated WAGON-543: --- Description: To reproduce this issue 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 Assume your local account can ssh to same host with ssh key other notes: * No problem with maven 3.6.0 * I also have internal ssh library wrapper of wagon-ssh to perform sshexe/upload/download activities. Seeing the same issue when pickup wagon 3.3.0 * The root cause likely is from WAGON-537 with changes at AbstractWagon which may have side effect on internal jcsh 32K buffer was: To reproduce this issue 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 Assume your local account can ssh to same host with ssh key No problem with maven 3.6.0 I also have internal ssh library wrapper of wagon-ssh to perform sshexe/upload/download activities. Seeing the same issue when pickup wagon 3.3.0 The root cause likely is from WAGON-537 with changes at AbstractWagon > wagon-ssh download hangs > > > Key: WAGON-543 > URL: https://issues.apache.org/jira/browse/WAGON-543 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh >Affects Versions: 3.3.0 >Reporter: Dan Tran >Priority: Major > > To reproduce this issue > 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git > 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with > 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 > Assume your local account can ssh to same host with ssh key > other notes: > * No problem with maven 3.6.0 > * I also have internal ssh library wrapper of wagon-ssh to perform > sshexe/upload/download activities. Seeing the same issue when pickup wagon > 3.3.0 > * The root cause likely is from WAGON-537 with changes at AbstractWagon > which may have side effect on internal jcsh 32K buffer -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (WAGON-543) wagon-ssh download hangs
[ https://issues.apache.org/jira/browse/WAGON-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated WAGON-543: --- Description: To reproduce this issue 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 Assume your local account can ssh to same host with ssh key No problem with maven 3.6.0 I also have internal ssh library wrapper of wagon-ssh to performce sshexe/upload/download. Seeing same issue when pickup wagon 3.3.0 The root cause likely is from WAGON-537 with changes at AbstractWagon was: To reproduce this issue 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 Assume your local account can ssh to same host with ssh key No problem with maven 3.6.0 The root cause likely is from WAGON-537 with changes at AbstractWagon > wagon-ssh download hangs > > > Key: WAGON-543 > URL: https://issues.apache.org/jira/browse/WAGON-543 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh >Affects Versions: 3.3.0 >Reporter: Dan Tran >Priority: Major > > To reproduce this issue > 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git > 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with > 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 > Assume your local account can ssh to same host with ssh key > No problem with maven 3.6.0 > I also have internal ssh library wrapper of wagon-ssh to performce > sshexe/upload/download. Seeing same issue when pickup wagon 3.3.0 > The root cause likely is from WAGON-537 with changes at AbstractWagon -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (WAGON-543) wagon-ssh download hangs
[ https://issues.apache.org/jira/browse/WAGON-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated WAGON-543: --- Description: To reproduce this issue 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 Assume your local account can ssh to same host with ssh key No problem with maven 3.6.0 I also have internal ssh library wrapper of wagon-ssh to perform sshexe/upload/download activities. Seeing the same issue when pickup wagon 3.3.0 The root cause likely is from WAGON-537 with changes at AbstractWagon was: To reproduce this issue 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 Assume your local account can ssh to same host with ssh key No problem with maven 3.6.0 I also have internal ssh library wrapper of wagon-ssh to performce sshexe/upload/download. Seeing same issue when pickup wagon 3.3.0 The root cause likely is from WAGON-537 with changes at AbstractWagon > wagon-ssh download hangs > > > Key: WAGON-543 > URL: https://issues.apache.org/jira/browse/WAGON-543 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh >Affects Versions: 3.3.0 >Reporter: Dan Tran >Priority: Major > > To reproduce this issue > 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git > 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with > 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 > Assume your local account can ssh to same host with ssh key > No problem with maven 3.6.0 > I also have internal ssh library wrapper of wagon-ssh to perform > sshexe/upload/download activities. Seeing the same issue when pickup wagon > 3.3.0 > The root cause likely is from WAGON-537 with changes at AbstractWagon -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (WAGON-543) wagon-ssh download hangs
[ https://issues.apache.org/jira/browse/WAGON-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated WAGON-543: --- Description: To reproduce this issue 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 Assume your local account can ssh to same host with ssh key No problem with maven 3.6.0 The root cause likely is from WAGON-537 with changes at AbstractWagon was: To reproduce this issue 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 Assume your local account can ssh to same host with ssh key No problem with maven 3.6.0 > wagon-ssh download hangs > > > Key: WAGON-543 > URL: https://issues.apache.org/jira/browse/WAGON-543 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh >Affects Versions: 3.3.0 >Reporter: Dan Tran >Priority: Major > > To reproduce this issue > 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git > 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with > 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 > Assume your local account can ssh to same host with ssh key > No problem with maven 3.6.0 > The root cause likely is from WAGON-537 with changes at AbstractWagon -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (WAGON-543) wagon-ssh download hangs
[ https://issues.apache.org/jira/browse/WAGON-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated WAGON-543: --- Description: To reproduce this issue 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 Assume your local account can ssh to same host with ssh key No problem with maven 3.6.0 was: To reproduce this issue 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 Assume your local account can ssh to same host with ssh key > wagon-ssh download hangs > > > Key: WAGON-543 > URL: https://issues.apache.org/jira/browse/WAGON-543 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh >Affects Versions: 3.3.0 >Reporter: Dan Tran >Priority: Major > > To reproduce this issue > 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git > 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with > 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 > Assume your local account can ssh to same host with ssh key > No problem with maven 3.6.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (WAGON-543) wagon-ssh download hangs
Dan Tran created WAGON-543: -- Summary: wagon-ssh download hangs Key: WAGON-543 URL: https://issues.apache.org/jira/browse/WAGON-543 Project: Maven Wagon Issue Type: Bug Components: wagon-ssh Affects Versions: 3.3.0 Reporter: Dan Tran To reproduce this issue 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 Assume your local account can ssh to same host with ssh key -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6544) Replace CacheUtils#{eq,hash} with Objects
[
https://issues.apache.org/jira/browse/MNG-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729963#comment-16729963
]
Hudson commented on MNG-6544:
-
Build succeeded in Jenkins: Maven TLP » maven » master #118
See https://builds.apache.org/job/maven-box/job/maven/job/master/118/
> Replace CacheUtils#{eq,hash} with Objects
> -
>
> Key: MNG-6544
> URL: https://issues.apache.org/jira/browse/MNG-6544
> Project: Maven
> Issue Type: Task
> Components: core
>Affects Versions: 3.6.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.6.1
>
>
> {{Objects}} now sports idiot-safe {{equals}} and {{hashCode}} just like
> {{CacheUtils}}. We can swap out and deprecate/delete our code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (SCM-843) New files added to index are not checked in when nothing else has been changed in the working copy
[
https://issues.apache.org/jira/browse/SCM-843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed SCM-843.
--
Resolution: Incomplete
Fix Version/s: (was: waiting-for-feedback)
No reaction for months.
> New files added to index are not checked in when nothing else has been
> changed in the working copy
> --
>
> Key: SCM-843
> URL: https://issues.apache.org/jira/browse/SCM-843
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-jgit
>Affects Versions: 1.9.5
>Reporter: Lothar Wendehals
>Priority: Major
>
> Scenario:
> Start with a clean working copy. Create a new file in the working copy and
> add it to the index. Now run a checkin with JGitCheckinCommand. It will not
> commit the new file when nothing else has changed (no modified file for
> example) in the working copy.
> This is the original code in 1.9.5:
> {code}
> protected CheckInScmResult executeCheckInCommand(ScmProviderRepository repo,
> ScmFileSet fileSet, String message, ScmVersion version) throws ScmException {
> Git git = null;
> try {
> File basedir = fileSet.getBasedir();
> git = JGitUtils.openRepo( basedir );
> boolean doCommit = false;
> if (!fileSet.getFileList().isEmpty()) {
> doCommit = JGitUtils.addAllFiles( git, fileSet ).size() > 0;
> }
> else {
> // add all tracked files which are modified manually
> Set changeds = git.status().call().getModified();
> if ( changeds.isEmpty() ) {
> // warn there is nothing to add
> // here is the bug: status().call().getModified() does
> not return files that have already been added to the index, it only returns
> files that have been modified but not added to the index
> getLogger().warn( "there are no files to be added" );
> doCommit = false;
> }
> else {
> AddCommand add = git.add();
> for ( String changed : changeds ) {
> getLogger().debug( "add manualy: " + changed );
> add.addFilepattern( changed );
> doCommit = true;
> }
> add.call();
> }
> }
> List checkedInFiles = Collections.emptyList();
> if ( doCommit ) {
>
> }
> ...
> }
> {code}
> A possible fix would be:
> {code:java}
> if (!fileSet.getFileList().isEmpty()) {
> doCommit = JGitUtils.addAllFiles(git, fileSet).size() > 0;
> } else {
> // Bugfix: Files that have been added in advance by
> // the user will not be committed if nothing else has changed.
> // add all tracked files which are modified manually
> Set changeds = git.status().call().getModified();
> if (!changeds.isEmpty()) {
> AddCommand add = git.add();
> for (String changed : changeds) {
>getLogger().debug("add manually: " + changed);
>add.addFilepattern(changed);
>doCommit = true;
> }
>add.call();
> }
> Status status = git.status().call();
> doCommit = !status.getUncommittedChanges().isEmpty();
> if (!doCommit) {
> getLogger().warn("there are no files to commit");
> }
> }
> List checkedInFiles = Collections.emptyList();
> if (doCommit) {
>...
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (SCM-651) HgChangeLogCommand ignores ScmBranch
[ https://issues.apache.org/jira/browse/SCM-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed SCM-651. -- Resolution: Incomplete Fix Version/s: (was: waiting-for-feedback) No reaction for months. > HgChangeLogCommand ignores ScmBranch > > > Key: SCM-651 > URL: https://issues.apache.org/jira/browse/SCM-651 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-mercurial (hg) >Affects Versions: 1.6 >Reporter: Henning Schmiedehausen >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Major > Attachments: hg-branch.patch > > > Passing an ScmBranch object into the HgChangeLogCommand has no effect. It > should select only the log messages for that branch. The attached patch fixes > that behaviour. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SCM-706) prepare-with-pom deletes release-pom.xml then tries to git add it (presumably so the next commit records the fact)
[ https://issues.apache.org/jira/browse/SCM-706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed SCM-706. -- Resolution: Incomplete Fix Version/s: (was: waiting-for-feedback) No reaction on the PR for months. > prepare-with-pom deletes release-pom.xml then tries to git add it (presumably > so the next commit records the fact) > -- > > Key: SCM-706 > URL: https://issues.apache.org/jira/browse/SCM-706 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-gitexe >Affects Versions: 1.8.1 >Reporter: Darryl L. Miles >Assignee: Mark Struberg >Priority: Major > Attachments: > 0001-MRELEASE-809-Use-git-correctly-when-removing-and-add.patch, pom.xml > > > When running: git release:prepare-with-pom > After the tag is created and pushed, it then runs the sequence: > git rm release-pom.xml > git add -- pom.xml release-pom.xml > But the "git add" fails because the "git rm" did the action of removing the > actual file and adding the file removal fact to the cached index ready for > the next commit to pickup. > The solution is to remove the "release-pom.xml" argument from the "git add" > it is unnecessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCM-807) JGit impl check-in fails unless the Maven project is in the working copy root
[ https://issues.apache.org/jira/browse/SCM-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729959#comment-16729959 ] Michael Osipov commented on SCM-807: Still waiting for answers... > JGit impl check-in fails unless the Maven project is in the working copy root > - > > Key: SCM-807 > URL: https://issues.apache.org/jira/browse/SCM-807 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-gitexe >Affects Versions: 1.9.4 >Reporter: Richard DiCroce >Priority: Major > Fix For: waiting-for-feedback > > Attachments: scm-807.txt > > > Another problem exposed by maven-release-plugin: the JGit SCM > implementation's check-in fails unless the Maven project is in the working > copy root because it confuses the working copy's location with the Maven > project's location. > The attached patch resolves the issue. Combined with the patch attached to > SCM-806, release:prepare now mostly succeeds with the JGit implementation. > There is still a problem with the POM not being transformed correctly, but > that's a problem in maven-release-plugin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCM-860) add goal creates creates wrong paths if parent pom is not at root directory
[
https://issues.apache.org/jira/browse/SCM-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729960#comment-16729960
]
Michael Osipov commented on SCM-860:
Still waiting for answers...
> add goal creates creates wrong paths if parent pom is not at root directory
> ---
>
> Key: SCM-860
> URL: https://issues.apache.org/jira/browse/SCM-860
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-jgit
>Affects Versions: 1.9.5
> Environment: Windows, mvn 3.5.2, mvn:scm 1.9.5
>Reporter: Michael Kutschke
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> For reference:
> [https://stackoverflow.com/questions/48689960/maven-scm-plugin-and-relative-paths]
>
> When the pom is not at the root directory, the add goal creates a command
> that includes a relative path from the pom's directory instead of the root
> directory. Either that, or relative paths like /.. are dropped.
> Directory structure of the project:
> * .git
> ** src
> *** parent
> pom.xml
> *** submodule
> pom.xml
> addme.product
> Example pom:
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
>
> scm:git:file://../../.git
>
> 4.0.0
> grp
> artif
> 1.0.0
> pom
>
> ../submodule
>
>
>
>
> org.apache.maven.plugins
> maven-release-plugin
> 2.5.3
>
> true
> true
>
>
> org.eclipse.tycho:tycho-versions-plugin:${tycho-version}:update-eclipse-metadata
>
> org.apache.maven.plugins:maven-scm-plugin:1.9.5:add
>
>
>
>
> org.eclipse.tycho:tycho-versions-plugin:${tycho-version}:update-eclipse-metadata
>
> org.apache.maven.plugins:maven-scm-plugin:1.9.5:add
>
>
>
>
>
>org.apache.maven.plugins
>maven-scm-plugin
>1.9.5
>
>
>default-cli
>
> add
> checkin
>
>
>
> **/META-INF/MANIFEST.MF,**/feature.xml,**/*.product
> **/target/**
>Changing the version to reflect the pom versions
> for the release
>${project.basedir}/../..
>
> ${project.basedir}/../..
>
>
>
>
>
>
> {code}
> Leads to output like this:
> [INFO] Executing: cmd.exe /X /C "git add --
> src\parent\src\submodule\addme.product"
> [INFO] Working directory: D:\git\project\src\parent\..\..
> [ERROR] Provider message:
> [ERROR] The git-add command failed.
> [ERROR] Command output:
> [ERROR] fatal: pathspec 'src\parent\src\submodule\addme.product' did not
> match any files
> I think this is the jgit provider, but am unsure how to check that it is not
> the gitexe provider.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (SCM-851) "isCheckinPoliciesEnabled" is treated as mandatory in TFS URL
[
https://issues.apache.org/jira/browse/SCM-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed SCM-851.
--
Resolution: Incomplete
Fix Version/s: (was: waiting-for-feedback)
No reaction for months.
> "isCheckinPoliciesEnabled" is treated as mandatory in TFS URL
> -
>
> Key: SCM-851
> URL: https://issues.apache.org/jira/browse/SCM-851
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-tfs
>Affects Versions: 1.9.5
> Environment: All
>Reporter: Jason
>Priority: Major
>
> If you have a scm definition like:
> {{scm:tfs:https//server_name:workspace:$/TeamProject/Path/To/Project}}
> Then you will receive the following error: {{TFS Url "https" is not a valid
> URL. The TFS Url syntax is
> [[domain\]username[;password]@]http[s]://server_name[:port][:isCheckinPoliciesEnabled]:workspace:$/TeamProject/Path/To/Project}}
> This is because the code treats "{{isCheckinPoliciesEnabled}}" as mandatory,
> rather than optional as stated in the error message.
> Workaround: Add "{{:false}}" to the URL declaration, just before the
> workspace.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (SCM-777) Maven plugin's scm:validate ignores scmCheckWorkingDirectoryUrl configuration in favor of system property
[
https://issues.apache.org/jira/browse/SCM-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed SCM-777.
--
Resolution: Cannot Reproduce
Fix Version/s: (was: waiting-for-feedback)
No reaction for months.
> Maven plugin's scm:validate ignores scmCheckWorkingDirectoryUrl configuration
> in favor of system property
> -
>
> Key: SCM-777
> URL: https://issues.apache.org/jira/browse/SCM-777
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-plugin
>Affects Versions: 1.9.1
> Environment: Java 7 x64 on Windows 7
>Reporter: Mark Herman
>Priority: Major
>
> org.apache.maven.scm.manager.AbstractScmManager.checkWorkingDirectoryUrl()
> uses... {code} Boolean.getBoolean( CHECK_WORKING_DIRECTORY_URL ) {code}
> ...in order to check if it should check the repository on scm:validate. This
> will only react to the system property, and not to the maven configuration.
> *Result:* no maven config will enable the check working directory option,
> only passing it in as a jvm argument.
> *Expected:* this should work:
> {code}
>
> org.apache.maven.plugins
> maven-scm-plugin
>
> true
>
>
>
> validate
>
> true
>
>
>
> validate
>
>
>
>
> {code}
> *Workaround:* Use section. Tried
> and for some reason that didn't appear to work.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6213) Maven doesn't check the validity of scope value
[
https://issues.apache.org/jira/browse/MNG-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729936#comment-16729936
]
Michael Osipov commented on MNG-6213:
-
[~khmarbaise], is it still an issue merging this one? It seems to make
sense.Specially because the PR is set to a warning, not an error.
> Maven doesn't check the validity of scope value
> ---
>
> Key: MNG-6213
> URL: https://issues.apache.org/jira/browse/MNG-6213
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.3.9
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-11T01:41:47+09:00)
> Maven home: /usr/local/Cellar/maven/3.3.9/libexec
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.4", arch: "x86_64", family: "mac"
>Reporter: Jin Kwon
>Priority: Minor
> Labels: scope
>
> I accidentally put a wrong value into the {{scope}} tag.
> {code:xml}
>
>
>
> org.glassfish.jersey
> jersey-bom
> 2.26-b03
> pom
> include
>
>
>
> {code}
> And, of course, my dependency doesn't work.
> {code:xml}
>
>
> org.glassfish.jersey.core
> jersey-common
> test
>
>
> {code}
> {code}
> 'dependencies.dependency.version' for
> org.glassfish.jersey.core:jersey-common:jar is missing.
> {code}
> Maven should complains about the wrong value of {{include}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (SCM-735) Blame result on branched file is incorrect
[ https://issues.apache.org/jira/browse/SCM-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed SCM-735. -- Resolution: Incomplete Fix Version/s: (was: waiting-for-feedback) No reaction for months. > Blame result on branched file is incorrect > -- > > Key: SCM-735 > URL: https://issues.apache.org/jira/browse/SCM-735 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-perforce >Affects Versions: 1.8.1 >Reporter: Gregory SSI-YAN-KAI >Priority: Major > Attachments: blame_result_fix.patch, scm.patch > > > When a file is branched, its revision id restarts from 1. > So, 2 different lines can have the same revision id even though they have > been submitted in 2 different changelists. > Since the perforce blame command is based on the revision id of each line, > the result might be incorrect. > The solution I'm proposing in the attached patch is to use changelist number > to identify the author of a line. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SCM-665) TfsChangeLogCommand does not display the change log for directories
[
https://issues.apache.org/jira/browse/SCM-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed SCM-665.
--
Resolution: Incomplete
Fix Version/s: (was: waiting-for-feedback)
No reaction for months.
> TfsChangeLogCommand does not display the change log for directories
> ---
>
> Key: SCM-665
> URL: https://issues.apache.org/jira/browse/SCM-665
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-tfs
>Affects Versions: 1.6
>Reporter: John Wu
>Priority: Major
>
> The {{TfsChangeLogCommand}} can get change log of specific file(s), but
> cannot work for directory.
> In {{TfsChangeLogCommand.java}} of version 1.6, line 83 is
> {code}command.addArgument( file.getName() ); {code}
> But I believe it should be
> {code}command.addArgument( file.getAbsolutePath() ); {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (SCM-643) release:branch in mercurial provider updates the version in the new branch
[ https://issues.apache.org/jira/browse/SCM-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed SCM-643. -- Resolution: Incomplete Fix Version/s: (was: waiting-for-feedback) No reaction for months. > release:branch in mercurial provider updates the version in the new branch > -- > > Key: SCM-643 > URL: https://issues.apache.org/jira/browse/SCM-643 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-mercurial (hg) >Affects Versions: 1.5, 1.6 >Reporter: Jared Bunting >Priority: Major > Attachments: hg-scm-branch-fix.patch > > > When running release:branch with a mercurial repository, and having all > properties set to defaults, I would expect the current version to be carried > over to the new branch, and the new "developmentVersion" to be set on the > original branch. This is the behavior that I have always seen in the > subversion provider (which is the only other one that I really have > experience with), and what I believe the documentation states. However, that > is not the behavior that I am seeing. I see the branch created, then the new > version set on the branch. > I believe the issue is that HgBranchCommand not only creates a new branch, > but updates the working copy to the new branch. This seems to be counter to > the behavior expected by maven-release-plugin, differs from the behavior in > the subversion provider, and also seems to not be the behavior described in > the ScmProvider interface. > Since this "updating to the new branch" behavior is inherent to mercurial, > I've written a patch that saves the original branch name prior to branching, > and after branching is complete updates to the original branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] michael-o commented on issue #33: Scm 775
michael-o commented on issue #33: Scm 775 URL: https://github.com/apache/maven-scm/pull/33#issuecomment-450254179 Please rebase and squash. 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 removed a comment on issue #33: Scm 775
michael-o removed a comment on issue #33: Scm 775 URL: https://github.com/apache/maven-scm/pull/33#issuecomment-450253773 Please create a JIRA issue, a test would be great. 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 issue #33: Scm 775
michael-o commented on issue #33: Scm 775 URL: https://github.com/apache/maven-scm/pull/33#issuecomment-450253773 Please create a JIRA issue, a test would be great. 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 issue #37: added recursive support with submodule clone
michael-o commented on issue #37: added recursive support with submodule clone URL: https://github.com/apache/maven-scm/pull/37#issuecomment-450253579 Please create a JIRA issue, a test would be great. 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] [Closed] (SCM-853) Bootstrap changes for checkout and update.
[ https://issues.apache.org/jira/browse/SCM-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed SCM-853. -- Resolution: Incomplete Fix Version/s: (was: waiting-for-feedback) No reaction for months. > Bootstrap changes for checkout and update. > -- > > Key: SCM-853 > URL: https://issues.apache.org/jira/browse/SCM-853 > Project: Maven SCM > Issue Type: Improvement > Components: maven-plugin >Affects Versions: 1.10.0 >Reporter: Yerko Israel Pino Garay >Priority: Minor > > The changes in the bootstrap functionality includes: execute the goals with > an update if checkout directory exists or just execute the goals without > checkout or update. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1542) Fractional per-core thread count
[ https://issues.apache.org/jira/browse/SUREFIRE-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729947#comment-16729947 ] Vidar Breivik commented on SUREFIRE-1542: - This is already supported as far as I know. You can set the forkCount to 0.5C to achieve what you want. See [https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#forkCount] > Fractional per-core thread count > > > Key: SUREFIRE-1542 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1542 > Project: Maven Surefire > Issue Type: Improvement >Reporter: Chris Hennick >Priority: Major > > I have a lot of tests that each use 2 threads at once, and timeouts become a > problem when I try to run 1 test thread per core (because that amounts to 2 > actual active threads per core). Why not make the thread count > floating-point, so that I could fix this by specifying 0.5 threads per core? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SCM-695) Mvn release plugin problems with too many - in name
[
https://issues.apache.org/jira/browse/SCM-695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed SCM-695.
--
Resolution: Incomplete
Fix Version/s: (was: waiting-for-feedback)
Unfortunately, no reactoin for 6 months.
> Mvn release plugin problems with too many - in name
> ---
>
> Key: SCM-695
> URL: https://issues.apache.org/jira/browse/SCM-695
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.7
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Maven home: /home/devent/apps/apache-maven-3.0.3
> Java version: 1.7.0_b147-icedtea, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.1/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.1.9-1.fc16.i686", arch: "i386", family: "unix"
>Reporter: Erwin Mueller
>Priority: Blocker
> Attachments: mvn-release-prepare.log
>
>
> Have maven problems with modules containing too many "-"?
> I have projects that are named:
> {noformat}
> globalpom-groovy/
> globalpom-groovy/globalpom-groovy/pom.xml < parent pom
> globalpom-groovy/globalpom-groovy-izpack/pom.xml
> globalpom-groovy/globalpom-groovy-izpack-snglejar/pom.xml
> globalpom-groovy/globalpom-groovy-testutils/pom.xml
> {noformat}
> But if I do mvn release:prepare inside of globalpom-groovy/globalpom-groovy/,
> then I get the error:
> {noformat}
> [INFO] Executing: /bin/sh -c cd
> /mnt/read/projects/com.anrisoftware/globalpom/globalpom-groovy/globalpom-
> groovy && git add -- pom.xml -izpack/pom.xml -izpack-singlejar/pom.xml -
> testutils/pom.xml
> [INFO] Working directory:
> /mnt/read/projects/com.anrisoftware/globalpom/globalpom-groovy/globalpom-
> groovy
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Global POM Groovy . FAILURE [12.365s]
> [INFO] Global POM Groovy IzPack .. SKIPPED
> [INFO] Global POM Groovy IzPack Single Jar ... SKIPPED
> [INFO] Global POM Groovy Test Utilities .. SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 13.066s
> [INFO] Finished at: Sat Jan 21 15:45:50 CET 2012
> [INFO] Final Memory: 12M/152M
> [INFO]
>
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-
> plugin:2.0:prepare (default-cli) on project globalpom-groovy: Unable to
> commit
> files
> [ERROR] Provider message:
> [ERROR] The git-add command failed.
> [ERROR] Command output:
> [ERROR] fatal: pathspec 'globalpom-groovy/-izpack/pom.xml' did not match any
> files
> {noformat}
> Of course that's wrong 'globalpom-groovy/-izpack/pom.xml' should be
> '../globalpom-groovy-izpack/pom.xml', or something like that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SCM-695) Mvn release plugin problems with too many - in name
[
https://issues.apache.org/jira/browse/SCM-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729943#comment-16729943
]
Michael Osipov edited comment on SCM-695 at 12/27/18 11:32 PM:
---
Unfortunately, no reaction for 6 months.
was (Author: michael-o):
Unfortunately, no reactoin for 6 months.
> Mvn release plugin problems with too many - in name
> ---
>
> Key: SCM-695
> URL: https://issues.apache.org/jira/browse/SCM-695
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.7
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Maven home: /home/devent/apps/apache-maven-3.0.3
> Java version: 1.7.0_b147-icedtea, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.1/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.1.9-1.fc16.i686", arch: "i386", family: "unix"
>Reporter: Erwin Mueller
>Priority: Blocker
> Attachments: mvn-release-prepare.log
>
>
> Have maven problems with modules containing too many "-"?
> I have projects that are named:
> {noformat}
> globalpom-groovy/
> globalpom-groovy/globalpom-groovy/pom.xml < parent pom
> globalpom-groovy/globalpom-groovy-izpack/pom.xml
> globalpom-groovy/globalpom-groovy-izpack-snglejar/pom.xml
> globalpom-groovy/globalpom-groovy-testutils/pom.xml
> {noformat}
> But if I do mvn release:prepare inside of globalpom-groovy/globalpom-groovy/,
> then I get the error:
> {noformat}
> [INFO] Executing: /bin/sh -c cd
> /mnt/read/projects/com.anrisoftware/globalpom/globalpom-groovy/globalpom-
> groovy && git add -- pom.xml -izpack/pom.xml -izpack-singlejar/pom.xml -
> testutils/pom.xml
> [INFO] Working directory:
> /mnt/read/projects/com.anrisoftware/globalpom/globalpom-groovy/globalpom-
> groovy
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Global POM Groovy . FAILURE [12.365s]
> [INFO] Global POM Groovy IzPack .. SKIPPED
> [INFO] Global POM Groovy IzPack Single Jar ... SKIPPED
> [INFO] Global POM Groovy Test Utilities .. SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 13.066s
> [INFO] Finished at: Sat Jan 21 15:45:50 CET 2012
> [INFO] Final Memory: 12M/152M
> [INFO]
>
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-
> plugin:2.0:prepare (default-cli) on project globalpom-groovy: Unable to
> commit
> files
> [ERROR] Provider message:
> [ERROR] The git-add command failed.
> [ERROR] Command output:
> [ERROR] fatal: pathspec 'globalpom-groovy/-izpack/pom.xml' did not match any
> files
> {noformat}
> Of course that's wrong 'globalpom-groovy/-izpack/pom.xml' should be
> '../globalpom-groovy-izpack/pom.xml', or something like that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MNG-6213) Maven doesn't check the validity of scope value
[
https://issues.apache.org/jira/browse/MNG-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-6213:
---
Assignee: Michael Osipov
> Maven doesn't check the validity of scope value
> ---
>
> Key: MNG-6213
> URL: https://issues.apache.org/jira/browse/MNG-6213
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.3.9
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-11T01:41:47+09:00)
> Maven home: /usr/local/Cellar/maven/3.3.9/libexec
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.4", arch: "x86_64", family: "mac"
>Reporter: Jin Kwon
>Assignee: Michael Osipov
>Priority: Minor
> Labels: scope
>
> I accidentally put a wrong value into the {{scope}} tag.
> {code:xml}
>
>
>
> org.glassfish.jersey
> jersey-bom
> 2.26-b03
> pom
> include
>
>
>
> {code}
> And, of course, my dependency doesn't work.
> {code:xml}
>
>
> org.glassfish.jersey.core
> jersey-common
> test
>
>
> {code}
> {code}
> 'dependencies.dependency.version' for
> org.glassfish.jersey.core:jersey-common:jar is missing.
> {code}
> Maven should complains about the wrong value of {{include}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MNG-6544) Replace CacheUtils#{eq,hash} with Objects
[
https://issues.apache.org/jira/browse/MNG-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6544.
---
Resolution: Fixed
Fixed with
[c7ab9876f578f43415970363396712bf3e17e34a|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=c7ab9876f578f43415970363396712bf3e17e34a].
> Replace CacheUtils#{eq,hash} with Objects
> -
>
> Key: MNG-6544
> URL: https://issues.apache.org/jira/browse/MNG-6544
> Project: Maven
> Issue Type: Task
> Components: core
>Affects Versions: 3.6.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.6.1
>
>
> {{Objects}} now sports idiot-safe {{equals}} and {{hashCode}} just like
> {{CacheUtils}}. We can swap out and deprecate/delete our code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] michael-o commented on issue #97: .travis and SonarQube.com support
michael-o commented on issue #97: .travis and SonarQube.com support URL: https://github.com/apache/maven/pull/97#issuecomment-450251512 I think we are good to close this one. Jenkins does a fine job for us. 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-6213) Maven doesn't check the validity of scope value
[
https://issues.apache.org/jira/browse/MNG-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729939#comment-16729939
]
Karl Heinz Marbaise commented on MNG-6213:
--
Ok lets try it...
> Maven doesn't check the validity of scope value
> ---
>
> Key: MNG-6213
> URL: https://issues.apache.org/jira/browse/MNG-6213
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.3.9
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-11T01:41:47+09:00)
> Maven home: /usr/local/Cellar/maven/3.3.9/libexec
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.4", arch: "x86_64", family: "mac"
>Reporter: Jin Kwon
>Priority: Minor
> Labels: scope
>
> I accidentally put a wrong value into the {{scope}} tag.
> {code:xml}
>
>
>
> org.glassfish.jersey
> jersey-bom
> 2.26-b03
> pom
> include
>
>
>
> {code}
> And, of course, my dependency doesn't work.
> {code:xml}
>
>
> org.glassfish.jersey.core
> jersey-common
> test
>
>
> {code}
> {code}
> 'dependencies.dependency.version' for
> org.glassfish.jersey.core:jersey-common:jar is missing.
> {code}
> Maven should complains about the wrong value of {{include}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] michael-o commented on issue #196: [MNG-6527] - Add unit tests for org.apache.maven.repository.MavenArtifactMetadata
michael-o commented on issue #196: [MNG-6527] - Add unit tests for org.apache.maven.repository.MavenArtifactMetadata URL: https://github.com/apache/maven/pull/196#issuecomment-450250278 I think that there is no benefit in merging this one. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] michael-o commented on issue #199: [MNG-6535] - Add unit tests for org.apache.maven.model.path.DefaultUrlNormalizer
michael-o commented on issue #199: [MNG-6535] - Add unit tests for org.apache.maven.model.path.DefaultUrlNormalizer URL: https://github.com/apache/maven/pull/199#issuecomment-450250069 What is the purpose of this test and what will it proof? 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] asfgit closed pull request #195: [MNG-6528] - Add unit tests for org.apache.maven.plugin.CacheUtils
asfgit closed pull request #195: [MNG-6528] - Add unit tests for
org.apache.maven.plugin.CacheUtils
URL: https://github.com/apache/maven/pull/195
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-core/src/test/java/org/apache/maven/plugin/CacheUtilsTest.java
b/maven-core/src/test/java/org/apache/maven/plugin/CacheUtilsTest.java
new file mode 100644
index 00..b1f7fa58a7
--- /dev/null
+++ b/maven-core/src/test/java/org/apache/maven/plugin/CacheUtilsTest.java
@@ -0,0 +1,70 @@
+package org.apache.maven.plugin;
+
+/*
+ * 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 org.apache.maven.plugin.CacheUtils;
+import org.junit.Assert;
+import org.junit.Test;
+
+public class CacheUtilsTest {
+
+@Test
+public void eqInputNegativeNegativeOutputFalse() {
+
+// Arrange
+final Object s1 = -268_435_457;
+final Object s2 = -242_043_397;
+
+// Act
+final boolean retval = CacheUtils.eq(s1, s2);
+
+// Assert result
+Assert.assertEquals(false, retval);
+}
+
+@Test
+public void eqInputNullNegativeOutputFalse() {
+
+// Arrange
+final Object s1 = null;
+final Object s2 = -2_147_483_647;
+
+// Act
+final boolean retval = CacheUtils.eq(s1, s2);
+
+// Assert result
+Assert.assertEquals(false, retval);
+}
+
+@Test
+public void eqInputNullNullOutputTrue() {
+
+// Arrange
+final Object s1 = null;
+final Object s2 = null;
+
+// Act
+final boolean retval = CacheUtils.eq(s1, s2);
+
+// Assert result
+Assert.assertEquals(true, retval);
+}
+
+}
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] (MJAVADOC-469) javadoc-plugin does not double backslashes in argument file
[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729918#comment-16729918
]
Michael Osipov commented on MJAVADOC-469:
-
I have pushed the branch {{additionalOptions-doc-improvement}} which changes
the documentation.
> javadoc-plugin does not double backslashes in argument file
> ---
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Ilya Basin
>Assignee: Michael Osipov
>Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-469) javadoc-plugin does not double backslashes in argument file
[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729913#comment-16729913
]
Michael Osipov commented on MJAVADOC-469:
-
You are right, I will change the documentation for that mentioning that options
will be passed as-is.
> javadoc-plugin does not double backslashes in argument file
> ---
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Ilya Basin
>Assignee: Michael Osipov
>Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-469) javadoc-plugin does not double backslashes in argument file
[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729912#comment-16729912
]
Ilya Basin commented on MJAVADOC-469:
-
Then it's wrong to have an array of additionalOptions, if we don't quote them.
It's misguiding.
> javadoc-plugin does not double backslashes in argument file
> ---
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Ilya Basin
>Assignee: Michael Osipov
>Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-469) javadoc-plugin does not double backslashes in argument file
[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729911#comment-16729911
]
Michael Osipov commented on MJAVADOC-469:
-
I have updated the branch with [~tschoening]'s changes (regex).
> javadoc-plugin does not double backslashes in argument file
> ---
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Ilya Basin
>Assignee: Michael Osipov
>Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-469) javadoc-plugin does not double backslashes in argument file
[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729905#comment-16729905
]
Ilya Basin commented on MJAVADOC-469:
-
passthrough to where? As far as I know, Runtime.exec(String[]) does not require
the args to be quoted.
> javadoc-plugin does not double backslashes in argument file
> ---
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Ilya Basin
>Assignee: Michael Osipov
>Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-469) javadoc-plugin does not double backslashes in argument file
[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729908#comment-16729908
]
Michael Osipov commented on MJAVADOC-469:
-
To the argfile.
> javadoc-plugin does not double backslashes in argument file
> ---
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Ilya Basin
>Assignee: Michael Osipov
>Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (WAGON-537) Maven transfer speed of large artifacts is slow due to unsuitable buffer strategy
[ https://issues.apache.org/jira/browse/WAGON-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729907#comment-16729907 ] Michael Osipov commented on WAGON-537: -- [~dantran], the upload improvement is not so big as for download. At least with my setup with a low power device hosting Nexus and upload from my Windows machine. How does download look for you? Better? How does curl perform with Artifactory? I am convinced that [~o.otto]s work is a great step forward, but not yet complete in terms of performance. > Maven transfer speed of large artifacts is slow due to unsuitable buffer > strategy > - > > Key: WAGON-537 > URL: https://issues.apache.org/jira/browse/WAGON-537 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-provider-api >Affects Versions: 3.2.0 > Environment: Windows 10, JDK 1.8, Nexus Artifact store > 100MB/s > network connection. >Reporter: Olaf Otto >Assignee: Michael Osipov >Priority: Major > Labels: perfomance > Fix For: 3.3.0 > > Attachments: wagon-issue.png > > > We are using maven for build process automation with docker. This sometimes > involves uploading and downloading artifacts with a few gigabytes in size. > Here, maven's transfer speed is consistently and reproducibly slow. For > instance, an artifact with 7,5 GB in size took almost two hours to transfer > in spite of a 100 MB/s connection with respective reproducible download speed > from the remote nexus artifact repository when using a browser to download. > The same is true when uploding such an artifact. > I have investigated the issue using JProfiler. The result shows an issue in > AbstractWagon's transfer( Resource resource, InputStream input, OutputStream > output, int requestType, long maxSize ) method used for remote artifacts and > the same issue in AbstractHttpClientWagon#writeTo(OutputStream). > Here, the input stream is read in a loop using a 4 Kb buffer. Whenever data > is received, the received data is pushed to downstream listeners via > fireTransferProgress. These listeners (or rather consumers) perform expensive > tasks. > Now, the underlying InputStream implementation used in transfer will return > calls to read(buffer, offset, length) as soon as *some* data is available. > That is, fireTransferProgress may well be invoked with an average number of > bytes less than half the buffer capacity (this varies with the underlying > network and hardware architecture). Consequently, fireTransferProgress is > invoked *millions of times* for large files. As this is a blocking operation, > the time spent in fireTransferProgress dominates and drastically slows down > the transfers by at least one order of magnitude. > !wagon-issue.png! > In our case, we found download speed reduced from a theoretical optimum of > ~80 seconds to to more than 3200 seconds. > From an architectural perspective, I would not want to make the consumers / > listeners invoked via fireTransferProgress aware of their potential impact on > download speed, but rather refactor the transfer method such that it uses a > buffer strategy reducing the the number of fireTransferProgress invocations. > This should be done with regard to the expected file size of the transfer, > such that fireTransferProgress is invoked often enough but not to frequent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (WAGON-537) Maven transfer speed of large artifacts is slow due to unsuitable buffer strategy
[ https://issues.apache.org/jira/browse/WAGON-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729907#comment-16729907 ] Michael Osipov edited comment on WAGON-537 at 12/27/18 10:07 PM: - [~dantran], the upload improvement is not so big as for download. At least with my setup with a low power device hosting Nexus and upload from my Windows machine. How does download look for you? Better? How does curl perform with Artifactory? I am convinced that [~o.otto]'s work is a great step forward, but not yet complete in terms of performance. was (Author: michael-o): [~dantran], the upload improvement is not so big as for download. At least with my setup with a low power device hosting Nexus and upload from my Windows machine. How does download look for you? Better? How does curl perform with Artifactory? I am convinced that [~o.otto]s work is a great step forward, but not yet complete in terms of performance. > Maven transfer speed of large artifacts is slow due to unsuitable buffer > strategy > - > > Key: WAGON-537 > URL: https://issues.apache.org/jira/browse/WAGON-537 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-provider-api >Affects Versions: 3.2.0 > Environment: Windows 10, JDK 1.8, Nexus Artifact store > 100MB/s > network connection. >Reporter: Olaf Otto >Assignee: Michael Osipov >Priority: Major > Labels: perfomance > Fix For: 3.3.0 > > Attachments: wagon-issue.png > > > We are using maven for build process automation with docker. This sometimes > involves uploading and downloading artifacts with a few gigabytes in size. > Here, maven's transfer speed is consistently and reproducibly slow. For > instance, an artifact with 7,5 GB in size took almost two hours to transfer > in spite of a 100 MB/s connection with respective reproducible download speed > from the remote nexus artifact repository when using a browser to download. > The same is true when uploding such an artifact. > I have investigated the issue using JProfiler. The result shows an issue in > AbstractWagon's transfer( Resource resource, InputStream input, OutputStream > output, int requestType, long maxSize ) method used for remote artifacts and > the same issue in AbstractHttpClientWagon#writeTo(OutputStream). > Here, the input stream is read in a loop using a 4 Kb buffer. Whenever data > is received, the received data is pushed to downstream listeners via > fireTransferProgress. These listeners (or rather consumers) perform expensive > tasks. > Now, the underlying InputStream implementation used in transfer will return > calls to read(buffer, offset, length) as soon as *some* data is available. > That is, fireTransferProgress may well be invoked with an average number of > bytes less than half the buffer capacity (this varies with the underlying > network and hardware architecture). Consequently, fireTransferProgress is > invoked *millions of times* for large files. As this is a blocking operation, > the time spent in fireTransferProgress dominates and drastically slows down > the transfers by at least one order of magnitude. > !wagon-issue.png! > In our case, we found download speed reduced from a theoretical optimum of > ~80 seconds to to more than 3200 seconds. > From an architectural perspective, I would not want to make the consumers / > listeners invoked via fireTransferProgress aware of their potential impact on > download speed, but rather refactor the transfer method such that it uses a > buffer strategy reducing the the number of fireTransferProgress invocations. > This should be done with regard to the expected file size of the transfer, > such that fireTransferProgress is invoked often enough but not to frequent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAVADOC-469) javadoc-plugin does not double backslashes in argument file
[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729899#comment-16729899
]
Michael Osipov commented on MJAVADOC-469:
-
You can ask git-blame about this, but I guess the purpose was to passthrough
the value w/o any further preprocessing. At the end, the plugin does not know
what is an option or an option arg. Therefore, it is your task to supply sane
values.
> javadoc-plugin does not double backslashes in argument file
> ---
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Ilya Basin
>Assignee: Michael Osipov
>Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MJAVADOC-469) javadoc-plugin does not double backslashes in argument file
[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729898#comment-16729898
]
Ilya Basin edited comment on MJAVADOC-469 at 12/27/18 9:52 PM:
---
bq. I don't agree with this. It is an array or args which has to be provided as
such. This is not a string.
If it's an array already, then how do you explain this:
https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#additionalOptions
bq. This value should include quotes as necessary for parameters that include
spaces.
Whose idea was it?
bq. I don't understand in general why the argfile syntax is different to the
command line.
Maybe they wanted to allow something like:
{code}
"really/stra \r\t\n\" nge/path/"
{code}
was (Author: basinilya):
bq. I don't agree with this. It is an array or args which has to be provided as
such. This is not a string.
If it's an array already, then how do you explain this:
https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#additionalOptions
bq. This value should include quotes as necessary for parameters that include
spaces.
Whose idea was it?
bq. I don't understand in general why the argfile syntax is different to the
command line.
Maybe they wanted to allow something like:
{code}
"really/stra \r\t\n\" nge/path/"
{code}
> javadoc-plugin does not double backslashes in argument file
> ---
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Ilya Basin
>Assignee: Michael Osipov
>Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (WAGON-537) Maven transfer speed of large artifacts is slow due to unsuitable buffer strategy
[ https://issues.apache.org/jira/browse/WAGON-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729902#comment-16729902 ] Dan Tran commented on WAGON-537: Tested with latest maven 3.6.1-SNAPSHOT with both latest wagon snapshot and wagon-2.3.0 currently at staging repo. Dont see upload improvement. Here one of my 7.1 GB .ova upload (7.1 GB at 35 MB/s) . Am I missing anything? Maybe due to my Artifactory and jenkins are 1 network hop away? > Maven transfer speed of large artifacts is slow due to unsuitable buffer > strategy > - > > Key: WAGON-537 > URL: https://issues.apache.org/jira/browse/WAGON-537 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-provider-api >Affects Versions: 3.2.0 > Environment: Windows 10, JDK 1.8, Nexus Artifact store > 100MB/s > network connection. >Reporter: Olaf Otto >Assignee: Michael Osipov >Priority: Major > Labels: perfomance > Fix For: 3.3.0 > > Attachments: wagon-issue.png > > > We are using maven for build process automation with docker. This sometimes > involves uploading and downloading artifacts with a few gigabytes in size. > Here, maven's transfer speed is consistently and reproducibly slow. For > instance, an artifact with 7,5 GB in size took almost two hours to transfer > in spite of a 100 MB/s connection with respective reproducible download speed > from the remote nexus artifact repository when using a browser to download. > The same is true when uploding such an artifact. > I have investigated the issue using JProfiler. The result shows an issue in > AbstractWagon's transfer( Resource resource, InputStream input, OutputStream > output, int requestType, long maxSize ) method used for remote artifacts and > the same issue in AbstractHttpClientWagon#writeTo(OutputStream). > Here, the input stream is read in a loop using a 4 Kb buffer. Whenever data > is received, the received data is pushed to downstream listeners via > fireTransferProgress. These listeners (or rather consumers) perform expensive > tasks. > Now, the underlying InputStream implementation used in transfer will return > calls to read(buffer, offset, length) as soon as *some* data is available. > That is, fireTransferProgress may well be invoked with an average number of > bytes less than half the buffer capacity (this varies with the underlying > network and hardware architecture). Consequently, fireTransferProgress is > invoked *millions of times* for large files. As this is a blocking operation, > the time spent in fireTransferProgress dominates and drastically slows down > the transfers by at least one order of magnitude. > !wagon-issue.png! > In our case, we found download speed reduced from a theoretical optimum of > ~80 seconds to to more than 3200 seconds. > From an architectural perspective, I would not want to make the consumers / > listeners invoked via fireTransferProgress aware of their potential impact on > download speed, but rather refactor the transfer method such that it uses a > buffer strategy reducing the the number of fireTransferProgress invocations. > This should be done with regard to the expected file size of the transfer, > such that fireTransferProgress is invoked often enough but not to frequent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAVADOC-469) javadoc-plugin does not double backslashes in argument file
[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729898#comment-16729898
]
Ilya Basin commented on MJAVADOC-469:
-
bq. I don't agree with this. It is an array or args which has to be provided as
such. This is not a string.
If it's an array already, then how do you explain this:
https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#additionalOptions
bq. This value should include quotes as necessary for parameters that include
spaces.
Whose idea was it?
bq. I don't understand in general why the argfile syntax is different to the
command line.
Maybe they wanted to allow something like:
{code}
"really/stra \r\t\n\" nge/path/"
{code}
> javadoc-plugin does not double backslashes in argument file
> ---
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Ilya Basin
>Assignee: Michael Osipov
>Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-469) javadoc-plugin does not double backslashes in argument file
[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729888#comment-16729888
]
Michael Osipov commented on MJAVADOC-469:
-
{quote}I think mjavadoc should change the code that writes the arguments to the
@argfile. It was the choice of the plugin authors to use this file. For Maven
users it should be transparent and look as if no @argfile was used.
{quote}
How is that supposed to work if the `@files` parser requires another syntax as
the command line args?
{quote}
Additionally, while filling the arguments array the plugin should properly
split the string treating quoted args as one and removing
the quotes.
{quote}
I don't agree with this. It is an array or args which has to be provided as
such. This is not a string.
I don't understand in general why the argfile syntax is different to the
command line.
> javadoc-plugin does not double backslashes in argument file
> ---
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Ilya Basin
>Assignee: Michael Osipov
>Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-469) javadoc-plugin does not double backslashes in argument file
[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729868#comment-16729868
]
Ilya Basin commented on MJAVADOC-469:
-
bq. Ilya Basin, what's your opinion about this?
I think mjavadoc should change the code that writes the arguments to the
@argfile. It was the choice of the plugin authors to use this file. For Maven
users it should be transparent and look as if no @argfile was used.
The plugin should write the arguments array to the file doubling backslashes
and double quoting those that contain spaces.
Additionally, while filling the arguments array the plugin should properly
split the string treating quoted args as one and removing
the quotes.
I found something that resembles the argfile parser. Check out the function
nextToken() here:
http://hg.openjdk.java.net/jdk/jdk/file/53a4760e9fcc/src/java.base/share/native/libjli/args.c#l148
http://hg.openjdk.java.net/jdk/jdk/file/53a4760e9fcc/src/java.base/windows/native/libjli/cmdtoargs.c
JLI_CmdToArgs() / JLI_PreprocessArg() / expandArgFile() / readArgFile() /
nextToken()
In short, nextToken() knows nothing about the nature of the argument it
extracts. It just removes the quotes and the escaping.
> javadoc-plugin does not double backslashes in argument file
> ---
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Ilya Basin
>Assignee: Michael Osipov
>Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-892) Upgrade maven-plugins parent to version 33
[ https://issues.apache.org/jira/browse/MASSEMBLY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729861#comment-16729861 ] Hudson commented on MASSEMBLY-892: -- Build succeeded in Jenkins: Maven TLP » maven-assembly-plugin » master #42 See https://builds.apache.org/job/maven-box/job/maven-assembly-plugin/job/master/42/ > Upgrade maven-plugins parent to version 33 > -- > > Key: MASSEMBLY-892 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-892 > Project: Maven Assembly 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] [Created] (MNG-6544) Replace CacheUtils#{eq,hash} with Objects
Michael Osipov created MNG-6544:
---
Summary: Replace CacheUtils#{eq,hash} with Objects
Key: MNG-6544
URL: https://issues.apache.org/jira/browse/MNG-6544
Project: Maven
Issue Type: Task
Components: core
Affects Versions: 3.6.0
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: 3.6.1
{{Objects}} now sports idiot-safe {{equals}} and {{hashCode}} just like
{{CacheUtils}}. We can swap out and deprecate/delete our code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-469) javadoc-plugin does not double backslashes in argument file
[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729847#comment-16729847
]
Michael Osipov commented on MJAVADOC-469:
-
I already responded to the SO question. I personally do not ask any questions
at SO anymore because my questions are so complex that most people aren't able
to answer them.
> javadoc-plugin does not double backslashes in argument file
> ---
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Ilya Basin
>Assignee: Michael Osipov
>Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MJAVADOC-469) javadoc-plugin does not double backslashes in argument file
[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729813#comment-16729813
]
Thorsten Schöning edited comment on MJAVADOC-469 at 12/27/18 8:01 PM:
--
In my opinion, the easiest solution is applying the regular expression and
replacement I proposed. That fixes this issue, doesn't seem to break too much
and more complex things can be implemented as really needed. [~basinilya],
what's your opinion about this? You actually created the bug, what would fit
your needs best?
Any more complex things, especially changing the schema and whatever stuff,
wouldn't be used easily anyway, because the containing pom.xml would need to be
migrated. In my case this issue is about a pom.xml from some 3rd party project
that worked on Linux and wasn't ever tested on Windows by the developers, so
failed for me. I'm not even sure if upstream accepted my patch with my
mentioned workaround yet, so they won't likely rewrite their pom.xml to use
newer stuff.
The only good solution is one that works without changing the pom.xml, by
relying only on people which are affected by the problem to simply update their
own Maven. That is something I have control of. If I need to rewrite the
pom.xml anyway, I could simply stick with my documented workaround. If you
think otherwise, [~rfscholte] is correct, simply don't do anything because it
won't help much.
bq. Are you willing to raise an issue with Oracle to at least clarify the
documentation.
I'm not sure who to write at currently, so started a question on SO first:
https://stackoverflow.com/questions/5394/who-is-responsible-for-docs-and-implementation-of-the-javadoc-tool
was (Author: tschoening):
In my opinion, the easiest solution is applying the regular expression and
replacement I proposed. That fixes this issue, doesn't seem to break too much
and more complex things can be implemented as really needed. [~basinilya],
what's your opinion about this? You actually created the bug, what would fit
you needs easiest?
Any more complex things, especially changing the schema and whatever stuff,
wouldn't be used easily anyway, because the containing pom.xml would need to be
migrated. In my case this issue is about a pom.xml from some 3rd party project
that worked on Linux and wasn't ever tested on Windows by the developers, so
failed for me. I'm not even sure if upstream accepted my patch with my
mentioned workaround yet, so they won't likely rewrite their pom.xml to use
newer stuff.
The only good solution is one that works without changing the pom.xml, by
relying only on people which are affected by the problem to simply update their
own Maven. That is something I have control of. If I need to rewrite the
pom.xml anyway, I could simply stick with my documented workaround. If you
think otherwise, [~rfscholte] is correct, simply don't do anything because it
won't help much.
bq. Are you willing to raise an issue with Oracle to at least clarify the
documentation.
I'm not sure who to write at currently, so started a question on SO first:
https://stackoverflow.com/questions/5394/who-is-responsible-for-docs-and-implementation-of-the-javadoc-tool
> javadoc-plugin does not double backslashes in argument file
> ---
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Ilya Basin
>Assignee: Michael Osipov
>Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-469) javadoc-plugin does not double backslashes in argument file
[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729813#comment-16729813
]
Thorsten Schöning commented on MJAVADOC-469:
In my opinion, the easiest solution is applying the regular expression and
replacement I proposed. That fixes this issue, doesn't seem to break too much
and more complex things can be implemented as really needed. [~basinilya],
what's your opinion about this? You actually created the bug, what would fit
you needs easiest?
Any more complex things, especially changing the schema and whatever stuff,
wouldn't be used easily anyway, because the containing pom.xml would need to be
migrated. In my case this issue is about a pom.xml from some 3rd party project
that worked on Linux and wasn't ever tested on Windows by the developers, so
failed for me. I'm not even sure if upstream accepted my patch with my
mentioned workaround yet, so they won't likely rewrite their pom.xml to use
newer stuff.
The only good solution is one that works without changing the pom.xml, by
relying only on people which are affected by the problem to simply update their
own Maven. That is something I have control of. If I need to rewrite the
pom.xml anyway, I could simply stick with my documented workaround. If you
think otherwise, [~rfscholte] is correct, simply don't do anything because it
won't help much.
bq. Are you willing to raise an issue with Oracle to at least clarify the
documentation.
I'm not sure who to write at currently, so started a question on SO first:
https://stackoverflow.com/questions/5394/who-is-responsible-for-docs-and-implementation-of-the-javadoc-tool
> javadoc-plugin does not double backslashes in argument file
> ---
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Ilya Basin
>Assignee: Michael Osipov
>Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] eolivelli commented on a change in pull request #212: [SUREFIRE-1546] JUnit 5 runner does not honor JUnit 5 display names
eolivelli commented on a change in pull request #212: [SUREFIRE-1546] JUnit 5
runner does not honor JUnit 5 display names
URL: https://github.com/apache/maven-surefire/pull/212#discussion_r244215312
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/RunListenerAdapter.java
##
@@ -185,88 +181,72 @@ private void reportFailedTest(
private SimpleReportEntry createTestSetReportEntry( TestIdentifier
testIdentifier )
{
-return new SimpleReportEntry(
-JUnitPlatformProvider.class.getName(),
testIdentifier.getLegacyReportingName() );
+String[] classMethodName = toClassMethodName( testIdentifier );
+String className = classMethodName[0];
+String methodName = classMethodName[1];
+return new SimpleReportEntry( className, methodName );
}
private SimpleReportEntry createReportEntry( TestIdentifier testIdentifier
)
{
return createReportEntry( testIdentifier, (StackTraceWriter) null );
}
-private SimpleReportEntry createReportEntry(
-TestIdentifier testIdentifier, TestExecutionResult
testExecutionResult )
-{
-return createReportEntry(
-testIdentifier, getStackTraceWriter( testIdentifier,
testExecutionResult ) );
-}
-
-private SimpleReportEntry createReportEntry(
-TestIdentifier testIdentifier, StackTraceWriter
stackTraceWriter )
-{
-String source = getLegacyReportingClassName( testIdentifier );
-String name = getLegacyReportingName( testIdentifier );
-
-return SimpleReportEntry.withException( source, name, stackTraceWriter
);
-}
-
-private String getLegacyReportingName( TestIdentifier testIdentifier )
+private SimpleReportEntry createReportEntry( TestIdentifier testIdentifier,
+ TestExecutionResult
testExecutionResult )
{
-// Surefire cuts off the name at the first '(' character. Thus, we
have to pick a different
-// character to represent parentheses. "()" are removed entirely to
maximize compatibility with
-// existing reporting tools because in the old days test methods used
to not have parameters.
-return testIdentifier
-.getLegacyReportingName()
-.replace( "()", "" )
-.replace( '(', '{' )
-.replace( ')', '}' );
+return createReportEntry( testIdentifier, toStackTraceWriter(
testIdentifier, testExecutionResult ) );
}
-private String getLegacyReportingClassName( TestIdentifier testIdentifier )
+private SimpleReportEntry createReportEntry( TestIdentifier
testIdentifier, StackTraceWriter stackTraceWriter )
{
-return LegacyReportingUtils.getClassName( testPlan, testIdentifier );
+String[] classMethodName = toClassMethodName( testIdentifier );
+String className = classMethodName[0];
+String methodName = classMethodName[1];
+return withException( className, methodName, stackTraceWriter );
}
-private StackTraceWriter getStackTraceWriter(
-TestIdentifier testIdentifier, TestExecutionResult
testExecutionResult )
+private StackTraceWriter toStackTraceWriter( TestIdentifier testIdentifier,
+ TestExecutionResult
testExecutionResult )
{
Optional throwable = testExecutionResult.getThrowable();
if ( testExecutionResult.getStatus() == FAILED )
{
// Failed tests must have a StackTraceWriter, otherwise Surefire
will fail
-return getStackTraceWriter( testIdentifier, throwable.orElse( null
) );
+return toStackTraceWriter( testIdentifier, throwable.orElse( null
) );
}
-return throwable.map( t -> getStackTraceWriter( testIdentifier, t )
).orElse( null );
+return throwable.map( t -> toStackTraceWriter( testIdentifier, t ) )
+.orElse( null );
}
-private StackTraceWriter getStackTraceWriter( TestIdentifier
testIdentifier, Throwable throwable )
+private StackTraceWriter toStackTraceWriter( TestIdentifier
testIdentifier, Throwable throwable )
{
-String className = getClassName( testIdentifier );
-String methodName = getMethodName( testIdentifier ).orElse( "" );
+String[] classMethodName = toClassMethodName( testIdentifier );
+String className = classMethodName[0];
+String methodName = classMethodName[1];
return new PojoStackTraceWriter( className, methodName, throwable );
}
-private String getClassName( TestIdentifier testIdentifier )
+private String[] toClassMethodName( TestIdentifier testIdentifier )
Review comment:
Is there any particular reason for using an array and not a struct?
[GitHub] eolivelli commented on a change in pull request #212: [SUREFIRE-1546] JUnit 5 runner does not honor JUnit 5 display names
eolivelli commented on a change in pull request #212: [SUREFIRE-1546] JUnit 5
runner does not honor JUnit 5 display names
URL: https://github.com/apache/maven-surefire/pull/212#discussion_r244215535
##
File path:
surefire-its/src/test/resources/junit-platform/src/test/java/junitplatform/DisplayNameTest.java
##
@@ -0,0 +1,37 @@
+package junitplatform_1_0_0;
+
+/*
+ * 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 org.junit.jupiter.api.DisplayName;
+import org.junit.jupiter.api.Test;
+
+import java.util.logging.Logger;
+
+class DisplayNameTest
+{
+private static final Logger LOGGER = Logger.getLogger(
DisplayNameTest.class.getName() );
+
+@Test
+@DisplayName( "Custom test name containing spaces" )
Review comment:
Would it be useful to have some unit test around display name which contains
'(' and ')' ?
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] (MASSEMBLY-892) Upgrade maven-plugins parent to version 33
[ https://issues.apache.org/jira/browse/MASSEMBLY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729808#comment-16729808 ] Karl Heinz Marbaise commented on MASSEMBLY-892: --- Done in [48252db477a35368be0c35bb2299494cf908986b|https://gitbox.apache.org/repos/asf?p=maven-assembly-plugin.git;a=commitdiff;h=48252db477a35368be0c35bb2299494cf908986b] > Upgrade maven-plugins parent to version 33 > -- > > Key: MASSEMBLY-892 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-892 > Project: Maven Assembly 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] [Closed] (MASSEMBLY-892) Upgrade maven-plugins parent to version 33
[ https://issues.apache.org/jira/browse/MASSEMBLY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MASSEMBLY-892. - Resolution: Done > Upgrade maven-plugins parent to version 33 > -- > > Key: MASSEMBLY-892 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-892 > Project: Maven Assembly 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] [Closed] (MNG-5705) NPE on parallel build in BuilderCommon.handleBuildError(BuilderCommon.java:147)
[
https://issues.apache.org/jira/browse/MNG-5705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-5705.
---
Resolution: Fixed
Implicitly fixed with MNG-5965:
{noformat}
$ /d/Entwicklung/Programme/apache-maven-3.6.1-SNAPSHOT/bin/mvn -V -T 1C clean
javadoc:aggregate -PjavadocDist
Apache Maven 3.6.1-SNAPSHOT (d92d874a37361723a22285e7e5673f7f27f3c0c8;
2018-12-26T14:13:05+01:00)
Maven home: D:\Entwicklung\Programme\apache-maven-3.6.1-SNAPSHOT
Java version: 1.7.0_191, vendor: Azul Systems, Inc., runtime: C:\Program
Files\Zulu\zulu-7\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
...
[INFO]
[INFO] Reactor Summary for Windup Parent 2.0.0-SNAPSHOT:
[INFO]
[INFO] Windup Parent .. SUCCESS [02:09 min]
[INFO] Windup Engine - Frames . SUCCESS [ 0.075 s]
[INFO] Windup Engine - Utils .. SUCCESS [ 0.045 s]
[INFO] Windup Engine - Graph Parent ... SUCCESS [ 0.030 s]
[INFO] Windup Engine - Graph API .. SUCCESS [ 0.072 s]
[INFO] Windup Engine - Graph Impl . SUCCESS [ 0.024 s]
[INFO] Windup Engine - Graph Addon SUCCESS [ 0.006 s]
[INFO] Windup Engine - Graph Tests SUCCESS [ 0.003 s]
[INFO] Windup Engine - Config Parent .. SUCCESS [ 0.030 s]
[INFO] Windup Engine - Config API . SUCCESS [ 0.041 s]
[INFO] Windup Engine - Config Impl SUCCESS [ 0.013 s]
[INFO] Windup Engine - Config Addon ... SUCCESS [ 0.007 s]
[INFO] Windup Engine - Decompiler . SUCCESS [ 0.006 s]
[INFO] Windup Engine - Decompiler API . SUCCESS [ 0.094 s]
[INFO] Windup Engine - Decompiler Procyon . SUCCESS [ 0.025 s]
[INFO] Windup Extension - Config - XML SUCCESS [ 0.017 s]
[INFO] Windup Engine - Reporting Parent ... SUCCESS [ 0.009 s]
[INFO] Windup Engine - Reporting API .. SUCCESS [ 0.025 s]
[INFO] Windup Engine - Reporting Impl . SUCCESS [ 0.053 s]
[INFO] Windup Engine - Reporting Addon SUCCESS [ 0.007 s]
[INFO] Windup Engine - Execution API Parent ... SUCCESS [ 0.014 s]
[INFO] Windup Engine - Execution API .. SUCCESS [ 0.016 s]
[INFO] Windup Engine - Execution API Impl . SUCCESS [ 0.015 s]
[INFO] Windup Engine - Execution API Addon SUCCESS [ 0.007 s]
[INFO] Windup Rules - XML - Basic . SUCCESS [ 0.020 s]
[INFO] Windup Extension - Config - Groovy . SUCCESS [ 0.012 s]
[INFO] Windup Rules - Java - Basic SUCCESS [ 0.029 s]
[INFO] Windup Engine - Config Tests ... SUCCESS [ 0.004 s]
[INFO] Windup Rules - Java EE - Basic . SUCCESS [ 0.017 s]
[INFO] Windup Engine - Execution API Tests SUCCESS [ 0.005 s]
[INFO] Windup Engine - Reporting Tests SUCCESS [ 0.003 s]
[INFO] Windup Engine - UI . SUCCESS [ 0.014 s]
[INFO] Windup Engine - Test Utilities . SUCCESS [ 0.030 s]
[INFO] Windup Engine - Tests .. SUCCESS [ 0.005 s]
[INFO] Windup - Bootstrap module .. SUCCESS [ 0.012 s]
[INFO] Windup - Distribution Build SUCCESS [ 0.085 s]
[INFO] Windup Rulesets BOM SUCCESS [ 0.121 s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 02:10 min (Wall Clock)
[INFO] Finished at: 2018-12-27T14:35:18+01:00
[INFO]
{noformat}
and the following changes:
{code}
diff --git a/frames/pom.xml b/frames/pom.xml
index bb72b76f3..411507dd8 100644
--- a/frames/pom.xml
+++ b/frames/pom.xml
@@ -182,7 +182,7 @@
org.apache.maven.plugins
maven-javadoc-plugin
-2.8
+3.0.1
attach-javadocs
diff --git a/pom.xml b/pom.xml
index 00e884da1..7eb66a8da 100644
--- a/pom.xml
+++ b/pom.xml
@@ -161,7 +161,7 @@
maven-javadoc-plugin
-2.10.1
+3.0.1
javadocs-dist
@@ -183,9 +183,7
[jira] [Commented] (MASSEMBLY-890) Upgrade plexus-interpolation to 1.25
[ https://issues.apache.org/jira/browse/MASSEMBLY-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729802#comment-16729802 ] Hudson commented on MASSEMBLY-890: -- Build succeeded in Jenkins: Maven TLP » maven-assembly-plugin » master #41 See https://builds.apache.org/job/maven-box/job/maven-assembly-plugin/job/master/41/ > Upgrade plexus-interpolation to 1.25 > > > Key: MASSEMBLY-890 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-890 > Project: Maven Assembly 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] [Updated] (MNG-5705) NPE on parallel build in BuilderCommon.handleBuildError(BuilderCommon.java:147)
[
https://issues.apache.org/jira/browse/MNG-5705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5705:
Fix Version/s: 3.6.1
> NPE on parallel build in
> BuilderCommon.handleBuildError(BuilderCommon.java:147)
> ---
>
> Key: MNG-5705
> URL: https://issues.apache.org/jira/browse/MNG-5705
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build
>Affects Versions: 3.2.1
>Reporter: Ondra Žižka
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.6.1
>
>
> STR:
> {code}
> git clone g...@github.com:OndraZizka/windup.git
> cd windup
> git checkout 91a454b # MavenNPE2
> mvn -T 1C clean javadoc:aggregate -PjavadocDist
> {code}
> {code}
> [INFO]
>
> [INFO] Windup Parent . SUCCESS [ 0.132 s]
> [INFO] Windup Engine - Frames SUCCESS [ 0.009 s]
> [INFO] Windup Engine - Utils . SUCCESS [ 0.035 s]
> [INFO] Windup Engine - Graph Parent .. SUCCESS [ 0.004 s]
> [INFO] Windup Engine - Graph API . FAILURE [ 0.003 s]
> [INFO] Windup Engine - Graph Impl SKIPPED
> [INFO] Windup Engine - Graph Addon ... SKIPPED
> [INFO] Windup Engine - Graph Tests ... SKIPPED
> [INFO] Windup Engine - Config Parent . SUCCESS [ 0.008 s]
> [INFO] Windup Engine - Config API SKIPPED
> [INFO] Windup Engine - Config Impl ... SKIPPED
> [INFO] Windup Engine - Config Addon .. SKIPPED
> [INFO] Windup Engine - Decompiler SUCCESS [ 0.011 s]
> [INFO] Windup Engine - Decompiler API SUCCESS [ 0.039 s]
> [INFO] Windup Engine - Decompiler Procyon SKIPPED
> [INFO] Windup Extension - Config - XML ... SKIPPED
> [INFO] Windup Engine - Reporting Parent .. SUCCESS [ 0.016 s]
> [INFO] Windup Engine - Reporting API . SKIPPED
> [INFO] Windup Engine - Reporting Impl SKIPPED
> [INFO] Windup Engine - Reporting Addon ... SKIPPED
> [INFO] Windup Engine - Execution API Parent .. SUCCESS [ 0.003 s]
> [INFO] Windup Engine - Execution API . SKIPPED
> [INFO] Windup Engine - Execution API Impl SKIPPED
> [INFO] Windup Engine - Execution API Addon ... SKIPPED
> [INFO] Windup Rules - XML - Basic SKIPPED
> [INFO] Windup Extension - Config - Groovy SKIPPED
> [INFO] Windup Rules - Java - Basic ... SKIPPED
> [INFO] Windup Engine - Config Tests .. SKIPPED
> [INFO] Windup Rules - Java EE - Basic SKIPPED
> [INFO] Windup Engine - Execution API Tests ... SKIPPED
> [INFO] Windup Engine - Reporting Tests ... SKIPPED
> [INFO] Windup Engine - UI SKIPPED
> [INFO] Windup Engine - Test Utilities SUCCESS [ 0.004 s]
> [INFO] Windup Engine - Tests . SKIPPED
> [INFO] Windup - Bootstrap module . SUCCESS [ 0.002 s]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ decompiler-api ---
> [INFO] Windup - Distribution Build ... FAILURE [ 0.008 s]
> [INFO] Windup Rulesets BOM ... SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 1.721 s (Wall Clock)
> [INFO] Finished at: 2014-10-22T16:39:30+01:00
> [INFO] Final Memory: 21M/211M
> [INFO]
>
> [ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at
> org.apache.maven.lifecycle.internal.builder.BuilderCommon.handleBuildError(BuilderCommon.java:147)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:188)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:184)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
>
[GitHub] Tibor17 opened a new pull request #212: [SUREFIRE-1546] JUnit 5 runner does not honor JUnit 5 display names
Tibor17 opened a new pull request #212: [SUREFIRE-1546] JUnit 5 runner does not honor JUnit 5 display names URL: https://github.com/apache/maven-surefire/pull/212 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] [Closed] (MASSEMBLY-890) Upgrade plexus-interpolation to 1.25
[ https://issues.apache.org/jira/browse/MASSEMBLY-890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MASSEMBLY-890. - Resolution: Done > Upgrade plexus-interpolation to 1.25 > > > Key: MASSEMBLY-890 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-890 > Project: Maven Assembly 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-890) Upgrade plexus-interpolation to 1.25
[ https://issues.apache.org/jira/browse/MASSEMBLY-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729785#comment-16729785 ] Karl Heinz Marbaise commented on MASSEMBLY-890: --- Done in [ce704227927f5c0ed8d3c1d493b1fc12976789b9|https://gitbox.apache.org/repos/asf?p=maven-assembly-plugin.git;a=commitdiff;h=ce704227927f5c0ed8d3c1d493b1fc12976789b9] > Upgrade plexus-interpolation to 1.25 > > > Key: MASSEMBLY-890 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-890 > Project: Maven Assembly 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] [Updated] (MASSEMBLY-892) Upgrade maven-plugins parent to version 33
[ https://issues.apache.org/jira/browse/MASSEMBLY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MASSEMBLY-892: -- Summary: Upgrade maven-plugins parent to version 33 (was: Upgrade maven-plugins parent to version 32) > Upgrade maven-plugins parent to version 33 > -- > > Key: MASSEMBLY-892 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-892 > Project: Maven Assembly 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] [Updated] (MASSEMBLY-762) Assembly plugin doesn't exclude transitive dependencies when excluded by wildcards in dependencies section
[
https://issues.apache.org/jira/browse/MASSEMBLY-762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enrico Olivelli updated MASSEMBLY-762:
--
Fix Version/s: 3.1.1
> Assembly plugin doesn't exclude transitive dependencies when excluded by
> wildcards in dependencies section
> --
>
> Key: MASSEMBLY-762
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-762
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.5.3
>Reporter: Denis Goihburg
>Priority: Major
> Fix For: 3.1.1
>
>
> On goal assembly:single with pom file:
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> MyTests
> Tests
> pom
> 1.0-SNAPSHOT
>
>
> org.springframework
> spring-core
> 4.1.0.RELEASE
>
>
> *
> *
>
>
>
>
>
>
>
> org.apache.maven.plugins
> maven-assembly-plugin
> 2.5.3
>
>
> jar-with-dependencies
>
>
>
>
>
>
> {code}
> transitive dependency commons-logging appears in resulting jar.
> When wildcard is replaced with specific dependency:
> {code:xml}
>
>
> org.springframework
> spring-core
> 4.1.0.RELEASE
>
>
> commons-logging
> commons-logging
>
>
>
>
>
> {code}
> the plugin works as expected and doesn't add this dependency.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6533) ProjectBuilder.build(list_of_projects,...) does not contain MavenProject in exception report
[
https://issues.apache.org/jira/browse/MNG-6533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729733#comment-16729733
]
Hudson commented on MNG-6533:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6533-2 #2
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6533-2/2/
> ProjectBuilder.build(list_of_projects,...) does not contain MavenProject in
> exception report
>
>
> Key: MNG-6533
> URL: https://issues.apache.org/jira/browse/MNG-6533
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.4, 3.6.0
>Reporter: Mickael Istria
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.6.1
>
>
> To save a lot of CPU and RAM in Eclipse m2e, we're trying to use
> {{ProjectBuilder.build(List projects ...)}} instead of sequencing
> multiple {{Projectbuilder.build(File singleProject...)}}. This has a big
> positive impact on m2e.
> However, we noticed that when the operation is failing in some case because
> pom is incomplete (which is a pretty usual state in the IDE), the
> multi-projects method does not return the MavenProject in the
> {{ProjectBuildingException.getResults()}}, while the single-project method
> does.
> Adding MavenProject for the multi-project {{ProjectBuilder.build(...)}} would
> allow m2e to use this method and save ~75% RAM and CPU in many operations.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-5965) Parallel build multiplies work if multiple goals are given
[ https://issues.apache.org/jira/browse/MNG-5965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729734#comment-16729734 ] Hudson commented on MNG-5965: - Build unstable in Jenkins: Maven TLP » maven » MNG-6533-2 #2 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6533-2/2/ > Parallel build multiplies work if multiple goals are given > -- > > Key: MNG-5965 > URL: https://issues.apache.org/jira/browse/MNG-5965 > Project: Maven > Issue Type: Bug > Components: Bootstrap Build >Affects Versions: 3.3.9 > Environment: Windows 7 64bit >Reporter: Matthias Schmalz >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.1 > > Attachments: parallel.test.zip > > Time Spent: 20m > Remaining Estimate: 0h > > When I run a parallel build which invokes multiple goals Maven multiplies the > work e.g. when I run > install sonar:sonar > Every phase is executed once as expected. However when I run > install sonar:sonar -T 4 > Every phase is executed twice. > The problem can be reproduced with a single simple Java project (of course > parallel builds are useless with a single module). Debugging showed that > every Mojo is really called twice per project. > Find attached a simple project and two build outputs, where you can see that > the parallel build is doing everything twice (you can ignore that Sonar fails > in the end, due to no server is up). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] eolivelli commented on issue #3: [MWAR-371] Overlays break first-win rule for web resource with target path ending with '/'
eolivelli commented on issue #3: [MWAR-371] Overlays break first-win rule for web resource with target path ending with '/' URL: https://github.com/apache/maven-war-plugin/pull/3#issuecomment-450191920 Okay. I will push to ASF repository so that we can move forward. I can do it only tomorrow 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] (MASSEMBLY-826) Assembly plugin is using Maven 2 dependency resolution algorithm even when used with Maven 3
[ https://issues.apache.org/jira/browse/MASSEMBLY-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729726#comment-16729726 ] Enrico Olivelli commented on MASSEMBLY-826: --- [~djelinski] are you sure that this issue is about "Maven Assembly Plugin" and not the "Dependency Plugin" ? > Assembly plugin is using Maven 2 dependency resolution algorithm even when > used with Maven 3 > > > Key: MASSEMBLY-826 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-826 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: dependencySet >Affects Versions: 2.6 > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00) > Maven home: C:\projects\build\apache-maven-3.3.9\bin\.. > Java version: 1.8.0_102, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.8.0_102\jre > Default locale: en_US, platform encoding: Cp1250 > OS name: "windows server 2008 r2", version: "6.1", arch: "amd64", family: > "dos" >Reporter: Daniel Jelinski >Priority: Major > Attachments: pom.xml > > > Assembly plugin is using Maven 2 dependency resolution algorithm even when > used with Maven 3. See attached POM. > For comparison, run: > mvn dependency:tree (returns Maven 3 dependencies) > mvn dependency:tree -Dverbose (returns Maven 2 dependencies) > The packages included in assembly should match the list returned by > non-verbose version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-875) Maven Assembly Plugin 3.X is about 10x slower than 2.6
[
https://issues.apache.org/jira/browse/MASSEMBLY-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729728#comment-16729728
]
Enrico Olivelli commented on MASSEMBLY-875:
---
as MASSEMBLY-900 has been merged I see a general improvement in overall
performances.
Is this issue still valid with current master (3.1.1-SNAPSHOT) ?
> Maven Assembly Plugin 3.X is about 10x slower than 2.6
> --
>
> Key: MASSEMBLY-875
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-875
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Reporter: Stu
>Priority: Minor
> Attachments: mvn_package_2.6.log, mvn_package_3.1.0.log
>
>
> In all our java projects, we have a fairly basic assembly configuration,
> something like this:
> {code:java}
>
> maven-assembly-plugin
> 2.6
>
>
>
> org.x.x.x
>
>
>
> jar-with-dependencies
>
>
>
>
> make-assembly
> package
>
> single
>
>
>
> {code}
> They all take about 10x longer with any 3.x.x version of the maven assembly
> plugin than the 2.6 version.
> This has been noticed by others:
> [https://stackoverflow.com/questions/9009232/what-sort-of-configuration-issues-or-problems-might-make-maven-assembly-plugin-g/24519615#24519615]
> But not reported as a bug that I could find.
> Although I could only justify "Minor" for the priority, this is really is a
> blocker for us moving to 3.x.x
> The upgrade is just not worth taking your build from < 10 sec to > 50 sec.
> (For this particular build, it went from about ~ 7 sec to ~ 57 sec.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-786) dependencySet with transitive dependencies doesn't honor dependency excludes.
[ https://issues.apache.org/jira/browse/MASSEMBLY-786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729727#comment-16729727 ] Enrico Olivelli commented on MASSEMBLY-786: --- [~anton.lundin] is this issue still valid ? > dependencySet with transitive dependencies doesn't honor dependency excludes. > - > > Key: MASSEMBLY-786 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-786 > Project: Maven Assembly Plugin > Issue Type: Bug >Reporter: Anton Lundin >Priority: Major > > We have some projects which dependencies "leaks" out which isn't necessary > there. > Thats why we use .. ... to > "prune" those off on the consuming site. > Later when assembly consumes artifacts which contains those exclusions it > doesn't exclude those and continues up the dependency tree. > That causes our assembly build which should consume about 3Gb of dependencies > to consume 30Gb. > I can make the final assembly look right with include/exclude-rules, but the > workspace needed is way to big. > The assembly plugin should honor exclusions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (MASSEMBLY-762) Assembly plugin doesn't exclude transitive dependencies when excluded by wildcards in dependencies section
[
https://issues.apache.org/jira/browse/MASSEMBLY-762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enrico Olivelli resolved MASSEMBLY-762.
---
Resolution: Fixed
> Assembly plugin doesn't exclude transitive dependencies when excluded by
> wildcards in dependencies section
> --
>
> Key: MASSEMBLY-762
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-762
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.5.3
>Reporter: Denis Goihburg
>Priority: Major
> Fix For: 3.1.1
>
>
> On goal assembly:single with pom file:
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> MyTests
> Tests
> pom
> 1.0-SNAPSHOT
>
>
> org.springframework
> spring-core
> 4.1.0.RELEASE
>
>
> *
> *
>
>
>
>
>
>
>
> org.apache.maven.plugins
> maven-assembly-plugin
> 2.5.3
>
>
> jar-with-dependencies
>
>
>
>
>
>
> {code}
> transitive dependency commons-logging appears in resulting jar.
> When wildcard is replaced with specific dependency:
> {code:xml}
>
>
> org.springframework
> spring-core
> 4.1.0.RELEASE
>
>
> commons-logging
> commons-logging
>
>
>
>
>
> {code}
> the plugin works as expected and doesn't add this dependency.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MASSEMBLY-799) Exclusion on wildcard, then the assembly would still package to include the excluded libraries
[ https://issues.apache.org/jira/browse/MASSEMBLY-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enrico Olivelli updated MASSEMBLY-799: -- Fix Version/s: 3.1.1 > Exclusion on wildcard, then the assembly would still package to include the > excluded libraries > -- > > Key: MASSEMBLY-799 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-799 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: filtering >Affects Versions: 2.6 >Reporter: Martin He >Priority: Major > Fix For: 3.1.1 > > > Assembly could not recognize the > ... > > > * > * > > > ... > in the , so would default assemble all the transitive jars to > the package. > I need to specify every exclusion to make this work... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (MASSEMBLY-799) Exclusion on wildcard, then the assembly would still package to include the excluded libraries
[ https://issues.apache.org/jira/browse/MASSEMBLY-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enrico Olivelli resolved MASSEMBLY-799. --- Resolution: Fixed > Exclusion on wildcard, then the assembly would still package to include the > excluded libraries > -- > > Key: MASSEMBLY-799 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-799 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: filtering >Affects Versions: 2.6 >Reporter: Martin He >Priority: Major > Fix For: 3.1.1 > > > Assembly could not recognize the > ... > > > * > * > > > ... > in the , so would default assemble all the transitive jars to > the package. > I need to specify every exclusion to make this work... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-883) Transitive dependencies with scope provided are included with jar-with-dependencies descriptor
[
https://issues.apache.org/jira/browse/MASSEMBLY-883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729724#comment-16729724
]
Enrico Olivelli commented on MASSEMBLY-883:
---
[~fanf42] this should have been fixed in current master (3.1.1-SNAPSHOT).
Can you try it ?
just clone the repo from Github and build it locally
{code:java}
mvn clean install -DskipTests{code}
> Transitive dependencies with scope provided are included with
> jar-with-dependencies descriptor
> --
>
> Key: MASSEMBLY-883
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-883
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: predefined descriptors
>Affects Versions: 3.1.0
>Reporter: Francois Armand
>Priority: Major
>
> In the following case as shown by {{mvn dependency:tree}}, with the
> predifined descriptor {{jar-with-dependencies}}:
>
> {{[INFO] +- com.jayway.jsonpath:json-path:jar:2.2.0:compile}}
> {{[INFO] | +- net.minidev:json-smart:jar:2.2.1:compile}}
> {{[INFO] | | - net.minidev:accessors-smart:jar:1.1:compile}}
> {{[INFO] | - org.slf4j:slf4j-api:jar:1.7.16:provided}}
>
> {{json-path}}, {{json-smart}}, {{accessors-smart}} are included, as expected.
> {{But slf4j-api}} is also included in the resulting jar.
> Other direct dependencies with scope `provided` are correctly excluded from
> the final jar.
> If this is the intendented behavior, which is highly surprising, could you
> document it in the corresponding descriptor documentation
> ([http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html#jar-with-dependencies).]
> Could you also explain what descriptor would allow to achieve the desired
> behavior (or point to a resource explaining it, I wasn't able to find one).
> Thanks.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-469) javadoc-plugin does not double backslashes in argument file
[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729716#comment-16729716
]
Robert Scholte commented on MJAVADOC-469:
-
So in short: my proposal won't fix it.
> javadoc-plugin does not double backslashes in argument file
> ---
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Ilya Basin
>Assignee: Michael Osipov
>Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] hboutemy edited a comment on issue #197: [MNG-6533] Test: ProjectBuildingException miss reference to MavenProject
hboutemy edited a comment on issue #197: [MNG-6533] Test: ProjectBuildingException miss reference to MavenProject URL: https://github.com/apache/maven/pull/197#issuecomment-450147594 I reworked the PR, creating 2 initial little refactoring commits that make the later modification a lot easier to understand IMHO: see MNG-6533-2 branch With that 2 commits, I now can understand the main "Prefer passing the interim project in ProjectBuildingResult" commit... One little thing that I feel is not good: catch(Exception) in the last commit. is catching InvalidArtifactRTException not sufficient? 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] (MASSEMBLY-873) Maven-Assembly-Plugin freezes when building jar-with-dependencies of project depending on org.bouncycastle:bcprov-jdk15on:1.58
[
https://issues.apache.org/jira/browse/MASSEMBLY-873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729692#comment-16729692
]
Enrico Olivelli commented on MASSEMBLY-873:
---
Great! I will mark this issue as Resolved in 3.1.1.
I hope we will be able to release 3.1.1 in the beginning of January.
> Maven-Assembly-Plugin freezes when building jar-with-dependencies of project
> depending on org.bouncycastle:bcprov-jdk15on:1.58
> --
>
> Key: MASSEMBLY-873
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-873
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
> Environment: Maven 3.5.2, Java 8u151 (32-bit) as well as 9.0
> (64-bit), Windows 10
>Reporter: Michael Schierl
>Priority: Major
> Fix For: 3.1.1
>
> Attachments: pom.xml
>
>
> To reproduce:
> 1. Create a new directory
> 2. Add attached pom.xml (no other sources required to reproduce; in real
> world you would add some source that uses BouncyCastle lib, too).
> 3. Run {{mvn package}}
> Actual result:
> Maven hangs after
> {{[INFO] Building jar:
> C:\Daten\Eigenes\svn\iota\hang\target\bug-1.0-SNAPSHOT-jar-with-dependencies.jar}}
> , consuming one CPU core.
> Expected result:
> Maven builds a package containing no own source and the dependency
> (bouncycastle)
> Workaround:
> In maven local repository, edit the .jar file of BouncyCastle and remove the
> `META-INF\BC*` files. Then the package can be built again. So it seems to be
> caused somehow by verifying signed jar files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MASSEMBLY-873) Maven-Assembly-Plugin freezes when building jar-with-dependencies of project depending on org.bouncycastle:bcprov-jdk15on:1.58
[
https://issues.apache.org/jira/browse/MASSEMBLY-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enrico Olivelli reassigned MASSEMBLY-873:
-
Assignee: Enrico Olivelli
> Maven-Assembly-Plugin freezes when building jar-with-dependencies of project
> depending on org.bouncycastle:bcprov-jdk15on:1.58
> --
>
> Key: MASSEMBLY-873
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-873
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
> Environment: Maven 3.5.2, Java 8u151 (32-bit) as well as 9.0
> (64-bit), Windows 10
>Reporter: Michael Schierl
>Assignee: Enrico Olivelli
>Priority: Major
> Fix For: 3.1.1
>
> Attachments: pom.xml
>
>
> To reproduce:
> 1. Create a new directory
> 2. Add attached pom.xml (no other sources required to reproduce; in real
> world you would add some source that uses BouncyCastle lib, too).
> 3. Run {{mvn package}}
> Actual result:
> Maven hangs after
> {{[INFO] Building jar:
> C:\Daten\Eigenes\svn\iota\hang\target\bug-1.0-SNAPSHOT-jar-with-dependencies.jar}}
> , consuming one CPU core.
> Expected result:
> Maven builds a package containing no own source and the dependency
> (bouncycastle)
> Workaround:
> In maven local repository, edit the .jar file of BouncyCastle and remove the
> `META-INF\BC*` files. Then the package can be built again. So it seems to be
> caused somehow by verifying signed jar files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (MASSEMBLY-873) Maven-Assembly-Plugin freezes when building jar-with-dependencies of project depending on org.bouncycastle:bcprov-jdk15on:1.58
[
https://issues.apache.org/jira/browse/MASSEMBLY-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enrico Olivelli resolved MASSEMBLY-873.
---
Resolution: Fixed
Fix Version/s: 3.1.1
> Maven-Assembly-Plugin freezes when building jar-with-dependencies of project
> depending on org.bouncycastle:bcprov-jdk15on:1.58
> --
>
> Key: MASSEMBLY-873
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-873
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
> Environment: Maven 3.5.2, Java 8u151 (32-bit) as well as 9.0
> (64-bit), Windows 10
>Reporter: Michael Schierl
>Assignee: Enrico Olivelli
>Priority: Major
> Fix For: 3.1.1
>
> Attachments: pom.xml
>
>
> To reproduce:
> 1. Create a new directory
> 2. Add attached pom.xml (no other sources required to reproduce; in real
> world you would add some source that uses BouncyCastle lib, too).
> 3. Run {{mvn package}}
> Actual result:
> Maven hangs after
> {{[INFO] Building jar:
> C:\Daten\Eigenes\svn\iota\hang\target\bug-1.0-SNAPSHOT-jar-with-dependencies.jar}}
> , consuming one CPU core.
> Expected result:
> Maven builds a package containing no own source and the dependency
> (bouncycastle)
> Workaround:
> In maven local repository, edit the .jar file of BouncyCastle and remove the
> `META-INF\BC*` files. Then the package can be built again. So it seems to be
> caused somehow by verifying signed jar files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-873) Maven-Assembly-Plugin freezes when building jar-with-dependencies of project depending on org.bouncycastle:bcprov-jdk15on:1.58
[
https://issues.apache.org/jira/browse/MASSEMBLY-873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729684#comment-16729684
]
Michael Schierl commented on MASSEMBLY-873:
---
I can confirm that the issue is indeed fixed with the latest
maven-assembly-plugin from GitHub.
> Maven-Assembly-Plugin freezes when building jar-with-dependencies of project
> depending on org.bouncycastle:bcprov-jdk15on:1.58
> --
>
> Key: MASSEMBLY-873
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-873
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
> Environment: Maven 3.5.2, Java 8u151 (32-bit) as well as 9.0
> (64-bit), Windows 10
>Reporter: Michael Schierl
>Priority: Major
> Attachments: pom.xml
>
>
> To reproduce:
> 1. Create a new directory
> 2. Add attached pom.xml (no other sources required to reproduce; in real
> world you would add some source that uses BouncyCastle lib, too).
> 3. Run {{mvn package}}
> Actual result:
> Maven hangs after
> {{[INFO] Building jar:
> C:\Daten\Eigenes\svn\iota\hang\target\bug-1.0-SNAPSHOT-jar-with-dependencies.jar}}
> , consuming one CPU core.
> Expected result:
> Maven builds a package containing no own source and the dependency
> (bouncycastle)
> Workaround:
> In maven local repository, edit the .jar file of BouncyCastle and remove the
> `META-INF\BC*` files. Then the package can be built again. So it seems to be
> caused somehow by verifying signed jar files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] eolivelli commented on a change in pull request #3: [MWAR-371] Overlays break first-win rule for web resource with target path ending with '/'
eolivelli commented on a change in pull request #3: [MWAR-371] Overlays break
first-win rule for web resource with target path ending with '/'
URL: https://github.com/apache/maven-war-plugin/pull/3#discussion_r244169699
##
File path: src/main/java/org/apache/maven/plugins/war/util/PathSet.java
##
@@ -42,25 +41,50 @@
public class PathSet
implements Iterable
{
-
+private static final String SEPARATOR = "/";
+private static final char SEPARATOR_CHAR = SEPARATOR.charAt(0);
/**
* Set of normalized paths
*/
-private Set pathsSet = new LinkedHashSet();
+private Set pathsSet = new LinkedHashSet<>();
-/**
- * The method normalizes the path.
- *
- * changes directory separator to unix's separator(/)
- * deletes all trailing slashes
- *
- *
- * @param path to normalization
- * @return normalized path
- */
-protected String normalizeFilePath( String path )
+static String normalizeSubPath( String path )
{
-return normalizeFilePathStatic( path );
+if ( path.isEmpty() )
+{
+return path;
+}
+/*String cleanPath = path.replaceAll( "[]+", SEPARATOR )
+.replaceAll( "[/]+" , SEPARATOR );*/
+
+String cleanPath = path.replace( File.separatorChar, SEPARATOR_CHAR );
+/*
+This results in the following test errors:
Review comment:
Okay. it is clear.
Let's leave
```
String cleanPath = path.replaceAll( "[]+", SEPARATOR )
.replaceAll( "[/]+" , SEPARATOR );
```
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] andretadeu commented on a change in pull request #3: [MWAR-371] Overlays break first-win rule for web resource with target path ending with '/'
andretadeu commented on a change in pull request #3: [MWAR-371] Overlays break
first-win rule for web resource with target path ending with '/'
URL: https://github.com/apache/maven-war-plugin/pull/3#discussion_r244163684
##
File path: src/main/java/org/apache/maven/plugins/war/util/PathSet.java
##
@@ -53,14 +52,14 @@ static String normalizeSubPath( String path )
{
return path;
}
-String cleanPath = path.replaceAll( "[]+", SEPARATOR )
-.replaceAll( "[/]+" , SEPARATOR );
-cleanPath = cleanPath.charAt( 0 ) == '/' ? cleanPath.substring( 1 ) :
cleanPath;
+String cleanPath = path.replaceAll( "[]+", File.separator )
+.replaceAll( "[/]+" , File.separator );
+cleanPath = cleanPath.charAt( 0 ) == File.separatorChar ?
cleanPath.substring( 1 ) : cleanPath;
if ( cleanPath.isEmpty() )
{
return cleanPath;
}
-if ( cleanPath.charAt( cleanPath.length() - 1 ) == '/' )
+if ( cleanPath.charAt( cleanPath.length() - 1 ) == File.separatorChar )
Review comment:
@eolivelli I will do as you said. Please, give me some minutes.
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] eolivelli commented on a change in pull request #3: [MWAR-371] Overlays break first-win rule for web resource with target path ending with '/'
eolivelli commented on a change in pull request #3: [MWAR-371] Overlays break
first-win rule for web resource with target path ending with '/'
URL: https://github.com/apache/maven-war-plugin/pull/3#discussion_r244162112
##
File path: src/main/java/org/apache/maven/plugins/war/util/PathSet.java
##
@@ -53,14 +52,14 @@ static String normalizeSubPath( String path )
{
return path;
}
-String cleanPath = path.replaceAll( "[]+", SEPARATOR )
-.replaceAll( "[/]+" , SEPARATOR );
-cleanPath = cleanPath.charAt( 0 ) == '/' ? cleanPath.substring( 1 ) :
cleanPath;
+String cleanPath = path.replaceAll( "[]+", File.separator )
+.replaceAll( "[/]+" , File.separator );
+cleanPath = cleanPath.charAt( 0 ) == File.separatorChar ?
cleanPath.substring( 1 ) : cleanPath;
if ( cleanPath.isEmpty() )
{
return cleanPath;
}
-if ( cleanPath.charAt( cleanPath.length() - 1 ) == '/' )
+if ( cleanPath.charAt( cleanPath.length() - 1 ) == File.separatorChar )
Review comment:
@andretadeu no, but only concern is about using File.separator as discussed
above.
If you please take into consideration about using File.separator instead of
hard coding the check for '\' and '/' then I will commit to ASF repo (still not
master branch yet) and we will see results of CI
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] andretadeu commented on a change in pull request #3: [MWAR-371] Overlays break first-win rule for web resource with target path ending with '/'
andretadeu commented on a change in pull request #3: [MWAR-371] Overlays break
first-win rule for web resource with target path ending with '/'
URL: https://github.com/apache/maven-war-plugin/pull/3#discussion_r244161498
##
File path: src/main/java/org/apache/maven/plugins/war/util/PathSet.java
##
@@ -53,14 +52,14 @@ static String normalizeSubPath( String path )
{
return path;
}
-String cleanPath = path.replaceAll( "[]+", SEPARATOR )
-.replaceAll( "[/]+" , SEPARATOR );
-cleanPath = cleanPath.charAt( 0 ) == '/' ? cleanPath.substring( 1 ) :
cleanPath;
+String cleanPath = path.replaceAll( "[]+", File.separator )
+.replaceAll( "[/]+" , File.separator );
+cleanPath = cleanPath.charAt( 0 ) == File.separatorChar ?
cleanPath.substring( 1 ) : cleanPath;
if ( cleanPath.isEmpty() )
{
return cleanPath;
}
-if ( cleanPath.charAt( cleanPath.length() - 1 ) == '/' )
+if ( cleanPath.charAt( cleanPath.length() - 1 ) == File.separatorChar )
Review comment:
Since I reverted the last modifications due to broken code, would you have
other remarks on 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] [Assigned] (MNG-5705) NPE on parallel build in BuilderCommon.handleBuildError(BuilderCommon.java:147)
[
https://issues.apache.org/jira/browse/MNG-5705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-5705:
---
Assignee: Michael Osipov
> NPE on parallel build in
> BuilderCommon.handleBuildError(BuilderCommon.java:147)
> ---
>
> Key: MNG-5705
> URL: https://issues.apache.org/jira/browse/MNG-5705
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build
>Affects Versions: 3.2.1
>Reporter: Ondra Žižka
>Assignee: Michael Osipov
>Priority: Major
>
> STR:
> {code}
> git clone g...@github.com:OndraZizka/windup.git
> cd windup
> git checkout 91a454b # MavenNPE2
> mvn -T 1C clean javadoc:aggregate -PjavadocDist
> {code}
> {code}
> [INFO]
>
> [INFO] Windup Parent . SUCCESS [ 0.132 s]
> [INFO] Windup Engine - Frames SUCCESS [ 0.009 s]
> [INFO] Windup Engine - Utils . SUCCESS [ 0.035 s]
> [INFO] Windup Engine - Graph Parent .. SUCCESS [ 0.004 s]
> [INFO] Windup Engine - Graph API . FAILURE [ 0.003 s]
> [INFO] Windup Engine - Graph Impl SKIPPED
> [INFO] Windup Engine - Graph Addon ... SKIPPED
> [INFO] Windup Engine - Graph Tests ... SKIPPED
> [INFO] Windup Engine - Config Parent . SUCCESS [ 0.008 s]
> [INFO] Windup Engine - Config API SKIPPED
> [INFO] Windup Engine - Config Impl ... SKIPPED
> [INFO] Windup Engine - Config Addon .. SKIPPED
> [INFO] Windup Engine - Decompiler SUCCESS [ 0.011 s]
> [INFO] Windup Engine - Decompiler API SUCCESS [ 0.039 s]
> [INFO] Windup Engine - Decompiler Procyon SKIPPED
> [INFO] Windup Extension - Config - XML ... SKIPPED
> [INFO] Windup Engine - Reporting Parent .. SUCCESS [ 0.016 s]
> [INFO] Windup Engine - Reporting API . SKIPPED
> [INFO] Windup Engine - Reporting Impl SKIPPED
> [INFO] Windup Engine - Reporting Addon ... SKIPPED
> [INFO] Windup Engine - Execution API Parent .. SUCCESS [ 0.003 s]
> [INFO] Windup Engine - Execution API . SKIPPED
> [INFO] Windup Engine - Execution API Impl SKIPPED
> [INFO] Windup Engine - Execution API Addon ... SKIPPED
> [INFO] Windup Rules - XML - Basic SKIPPED
> [INFO] Windup Extension - Config - Groovy SKIPPED
> [INFO] Windup Rules - Java - Basic ... SKIPPED
> [INFO] Windup Engine - Config Tests .. SKIPPED
> [INFO] Windup Rules - Java EE - Basic SKIPPED
> [INFO] Windup Engine - Execution API Tests ... SKIPPED
> [INFO] Windup Engine - Reporting Tests ... SKIPPED
> [INFO] Windup Engine - UI SKIPPED
> [INFO] Windup Engine - Test Utilities SUCCESS [ 0.004 s]
> [INFO] Windup Engine - Tests . SKIPPED
> [INFO] Windup - Bootstrap module . SUCCESS [ 0.002 s]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ decompiler-api ---
> [INFO] Windup - Distribution Build ... FAILURE [ 0.008 s]
> [INFO] Windup Rulesets BOM ... SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 1.721 s (Wall Clock)
> [INFO] Finished at: 2014-10-22T16:39:30+01:00
> [INFO] Final Memory: 21M/211M
> [INFO]
>
> [ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at
> org.apache.maven.lifecycle.internal.builder.BuilderCommon.handleBuildError(BuilderCommon.java:147)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:188)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:184)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
>
[GitHub] andretadeu commented on a change in pull request #3: [MWAR-371] Overlays break first-win rule for web resource with target path ending with '/'
andretadeu commented on a change in pull request #3: [MWAR-371] Overlays break
first-win rule for web resource with target path ending with '/'
URL: https://github.com/apache/maven-war-plugin/pull/3#discussion_r244158290
##
File path: src/main/java/org/apache/maven/plugins/war/util/PathSet.java
##
@@ -53,14 +52,14 @@ static String normalizeSubPath( String path )
{
return path;
}
-String cleanPath = path.replaceAll( "[]+", SEPARATOR )
-.replaceAll( "[/]+" , SEPARATOR );
-cleanPath = cleanPath.charAt( 0 ) == '/' ? cleanPath.substring( 1 ) :
cleanPath;
+String cleanPath = path.replaceAll( "[]+", File.separator )
+.replaceAll( "[/]+" , File.separator );
+cleanPath = cleanPath.charAt( 0 ) == File.separatorChar ?
cleanPath.substring( 1 ) : cleanPath;
if ( cleanPath.isEmpty() )
{
return cleanPath;
}
-if ( cleanPath.charAt( cleanPath.length() - 1 ) == '/' )
+if ( cleanPath.charAt( cleanPath.length() - 1 ) == File.separatorChar )
Review comment:
Ops, my last commit will break the code on Windows. File.separatorChar on
Windows is '\\', not '/'.
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] andretadeu commented on a change in pull request #3: [MWAR-371] Overlays break first-win rule for web resource with target path ending with '/'
andretadeu commented on a change in pull request #3: [MWAR-371] Overlays break
first-win rule for web resource with target path ending with '/'
URL: https://github.com/apache/maven-war-plugin/pull/3#discussion_r244160764
##
File path: src/main/java/org/apache/maven/plugins/war/util/PathSet.java
##
@@ -53,14 +52,14 @@ static String normalizeSubPath( String path )
{
return path;
}
-String cleanPath = path.replaceAll( "[]+", SEPARATOR )
-.replaceAll( "[/]+" , SEPARATOR );
-cleanPath = cleanPath.charAt( 0 ) == '/' ? cleanPath.substring( 1 ) :
cleanPath;
+String cleanPath = path.replaceAll( "[]+", File.separator )
Review comment:
I forgot to cite this link
https://stackoverflow.com/questions/5971964/file-separator-or-file-pathseparator
for reference.
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] eolivelli commented on a change in pull request #3: [MWAR-371] Overlays break first-win rule for web resource with target path ending with '/'
eolivelli commented on a change in pull request #3: [MWAR-371] Overlays break
first-win rule for web resource with target path ending with '/'
URL: https://github.com/apache/maven-war-plugin/pull/3#discussion_r244158490
##
File path: src/main/java/org/apache/maven/plugins/war/util/PathSet.java
##
@@ -53,14 +52,14 @@ static String normalizeSubPath( String path )
{
return path;
}
-String cleanPath = path.replaceAll( "[]+", SEPARATOR )
-.replaceAll( "[/]+" , SEPARATOR );
-cleanPath = cleanPath.charAt( 0 ) == '/' ? cleanPath.substring( 1 ) :
cleanPath;
+String cleanPath = path.replaceAll( "[]+", File.separator )
+.replaceAll( "[/]+" , File.separator );
+cleanPath = cleanPath.charAt( 0 ) == File.separatorChar ?
cleanPath.substring( 1 ) : cleanPath;
if ( cleanPath.isEmpty() )
{
return cleanPath;
}
-if ( cleanPath.charAt( cleanPath.length() - 1 ) == '/' )
+if ( cleanPath.charAt( cleanPath.length() - 1 ) == File.separatorChar )
Review comment:
Don't worry.
We will test your commit over all supported versions of Maven, Java and
Linux and Windows.
Hopefully if you are breaking things we will notice
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] andretadeu commented on a change in pull request #3: [MWAR-371] Overlays break first-win rule for web resource with target path ending with '/'
andretadeu commented on a change in pull request #3: [MWAR-371] Overlays break
first-win rule for web resource with target path ending with '/'
URL: https://github.com/apache/maven-war-plugin/pull/3#discussion_r244158290
##
File path: src/main/java/org/apache/maven/plugins/war/util/PathSet.java
##
@@ -53,14 +52,14 @@ static String normalizeSubPath( String path )
{
return path;
}
-String cleanPath = path.replaceAll( "[]+", SEPARATOR )
-.replaceAll( "[/]+" , SEPARATOR );
-cleanPath = cleanPath.charAt( 0 ) == '/' ? cleanPath.substring( 1 ) :
cleanPath;
+String cleanPath = path.replaceAll( "[]+", File.separator )
+.replaceAll( "[/]+" , File.separator );
+cleanPath = cleanPath.charAt( 0 ) == File.separatorChar ?
cleanPath.substring( 1 ) : cleanPath;
if ( cleanPath.isEmpty() )
{
return cleanPath;
}
-if ( cleanPath.charAt( cleanPath.length() - 1 ) == '/' )
+if ( cleanPath.charAt( cleanPath.length() - 1 ) == File.separatorChar )
Review comment:
Ops, my last commit will break the code on Windows. File.separatorChar on
Windows is '\', not '/'.
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] eolivelli commented on a change in pull request #3: [MWAR-371] Overlays break first-win rule for web resource with target path ending with '/'
eolivelli commented on a change in pull request #3: [MWAR-371] Overlays break
first-win rule for web resource with target path ending with '/'
URL: https://github.com/apache/maven-war-plugin/pull/3#discussion_r244158136
##
File path: src/main/java/org/apache/maven/plugins/war/util/PathSet.java
##
@@ -53,14 +52,14 @@ static String normalizeSubPath( String path )
{
return path;
}
-String cleanPath = path.replaceAll( "[]+", SEPARATOR )
-.replaceAll( "[/]+" , SEPARATOR );
-cleanPath = cleanPath.charAt( 0 ) == '/' ? cleanPath.substring( 1 ) :
cleanPath;
+String cleanPath = path.replaceAll( "[]+", File.separator )
Review comment:
Sorry for typo, I meant File.separator
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] andretadeu commented on a change in pull request #3: [MWAR-371] Overlays break first-win rule for web resource with target path ending with '/'
andretadeu commented on a change in pull request #3: [MWAR-371] Overlays break
first-win rule for web resource with target path ending with '/'
URL: https://github.com/apache/maven-war-plugin/pull/3#discussion_r244158004
##
File path: src/main/java/org/apache/maven/plugins/war/util/PathSet.java
##
@@ -53,14 +52,14 @@ static String normalizeSubPath( String path )
{
return path;
}
-String cleanPath = path.replaceAll( "[]+", SEPARATOR )
-.replaceAll( "[/]+" , SEPARATOR );
-cleanPath = cleanPath.charAt( 0 ) == '/' ? cleanPath.substring( 1 ) :
cleanPath;
+String cleanPath = path.replaceAll( "[]+", File.separator )
Review comment:
Sorry, but this won't work. path.replace( File.pathSeparator, "/" ) will
replace ';' with '/' and ':' with '/'.
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] (MJAVADOC-469) javadoc-plugin does not double backslashes in argument file
[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729613#comment-16729613
]
Ilya Basin commented on MJAVADOC-469:
-
{quote}The only "clean" way I can think of is solving this with a litte bit of
Plexus magic. Configuration would look something like this{quote}
Do you think that only "file" parameters should be escaped? It may happen that
when javadoc reads the parameters from a file instead of command line, it just
performs the initial escape processing and puts the results into the parameters
array.
> javadoc-plugin does not double backslashes in argument file
> ---
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Ilya Basin
>Assignee: Michael Osipov
>Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6543) Upgrade plexus classworld to support java 9+ ClassLoader.findClass(String moduleName, String name) in Mojos
[ https://issues.apache.org/jira/browse/MNG-6543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729606#comment-16729606 ] Hervé Boutemy commented on MNG-6543: you still didn't give me a classical plugin that fails, with a simple demo to show classical symptoms but once I read the ClassLoader javadoc, I can understand what can happen (now I understand it's related to modules in Java 9) > Upgrade plexus classworld to support java 9+ ClassLoader.findClass(String > moduleName, String name) in Mojos > --- > > Key: MNG-6543 > URL: https://issues.apache.org/jira/browse/MNG-6543 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.6.0 >Reporter: Romain Manni-Bucau >Priority: Major > Fix For: 3.6.1 > > > Goal is to include > https://github.com/codehaus-plexus/plexus-classworlds/pull/4 in Maven and > enable Mojos using this Java 9 new JPMS API to work under java 9+ > see [Java 9 ClassLoader.findClass(String moduleName,String > name)|https://docs.oracle.com/javase/9/docs/api/java/lang/ClassLoader.html#findClass-java.lang.String-java.lang.String-] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-5965) Parallel build multiplies work if multiple goals are given
[ https://issues.apache.org/jira/browse/MNG-5965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729611#comment-16729611 ] Hudson commented on MNG-5965: - Build succeeded in Jenkins: Maven TLP » maven » master #116 See https://builds.apache.org/job/maven-box/job/maven/job/master/116/ > Parallel build multiplies work if multiple goals are given > -- > > Key: MNG-5965 > URL: https://issues.apache.org/jira/browse/MNG-5965 > Project: Maven > Issue Type: Bug > Components: Bootstrap Build >Affects Versions: 3.3.9 > Environment: Windows 7 64bit >Reporter: Matthias Schmalz >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.1 > > Attachments: parallel.test.zip > > Time Spent: 20m > Remaining Estimate: 0h > > When I run a parallel build which invokes multiple goals Maven multiplies the > work e.g. when I run > install sonar:sonar > Every phase is executed once as expected. However when I run > install sonar:sonar -T 4 > Every phase is executed twice. > The problem can be reproduced with a single simple Java project (of course > parallel builds are useless with a single module). Debugging showed that > every Mojo is really called twice per project. > Find attached a simple project and two build outputs, where you can see that > the parallel build is doing everything twice (you can ignore that Sonar fails > in the end, due to no server is up). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] eolivelli commented on a change in pull request #3: [MWAR-371] Overlays break first-win rule for web resource with target path ending with '/'
eolivelli commented on a change in pull request #3: [MWAR-371] Overlays break
first-win rule for web resource with target path ending with '/'
URL: https://github.com/apache/maven-war-plugin/pull/3#discussion_r244155374
##
File path: src/main/java/org/apache/maven/plugins/war/util/PathSet.java
##
@@ -53,14 +52,14 @@ static String normalizeSubPath( String path )
{
return path;
}
-String cleanPath = path.replaceAll( "[]+", SEPARATOR )
-.replaceAll( "[/]+" , SEPARATOR );
-cleanPath = cleanPath.charAt( 0 ) == '/' ? cleanPath.substring( 1 ) :
cleanPath;
+String cleanPath = path.replaceAll( "[]+", File.separator )
Review comment:
sorry for late reply.
I was meaning mostly the opposite
`String cleanPath = path.replace(File.pathSeparator, "/")`
This will replace windows/linux stuff with a fixed separator ('/')
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
