[jira] [Commented] (MNG-5607) Don't use M2_HOME anymore in mvn shell/batch file anymore
[
https://issues.apache.org/jira/browse/MNG-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118798#comment-15118798
]
Dan Tran commented on MNG-5607:
---
Lots of ppl use M2_HOME to switch their Maven installation locations
externally. May want to emphasize this in release notes
> Don't use M2_HOME anymore in mvn shell/batch file anymore
> -
>
> Key: MNG-5607
> URL: https://issues.apache.org/jira/browse/MNG-5607
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.1
> Environment: all
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
>
> Currently the {{mvn}} shell script and the {{mvn.bat}} using {{M2_HOME}}.
> This should be changed either to {{MAVEN_HOME}} or {{M3_HOME}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5607) Don't use M2_HOME anymore in mvn shell/batch file anymore
[
https://issues.apache.org/jira/browse/MNG-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118678#comment-15118678
]
Hudson commented on MNG-5607:
-
SUCCESS: Integrated in maven-3.x #1204 (See
[https://builds.apache.org/job/maven-3.x/1204/])
[MNG-5607] Don't use M2_HOME anymore in mvn shell/batch file anymore (schulte:
rev d3b4fb0c1e525bb1122c7e832279f1ef6fbd6efe)
* apache-maven/src/bin/mvn.cmd
* apache-maven/src/bin/mvn
> Don't use M2_HOME anymore in mvn shell/batch file anymore
> -
>
> Key: MNG-5607
> URL: https://issues.apache.org/jira/browse/MNG-5607
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.1
> Environment: all
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
>
> Currently the {{mvn}} shell script and the {{mvn.bat}} using {{M2_HOME}}.
> This should be changed either to {{MAVEN_HOME}} or {{M3_HOME}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5607) Don't use M2_HOME anymore in mvn shell/batch file anymore
[
https://issues.apache.org/jira/browse/MNG-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118637#comment-15118637
]
Hudson commented on MNG-5607:
-
SUCCESS: Integrated in maven-3.x #1203 (See
[https://builds.apache.org/job/maven-3.x/1203/])
[MNG-5607] Don't use M2_HOME anymore in mvn shell/batch file anymore (schulte:
rev 364df32335a9c36986418498f654bf744d466767)
* apache-maven/src/bin/mvn
* apache-maven/src/bin/mvnDebug
* apache-maven/src/bin/mvnyjp
* apache-maven/src/bin/mvn.cmd
> Don't use M2_HOME anymore in mvn shell/batch file anymore
> -
>
> Key: MNG-5607
> URL: https://issues.apache.org/jira/browse/MNG-5607
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.1
> Environment: all
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
>
> Currently the {{mvn}} shell script and the {{mvn.bat}} using {{M2_HOME}}.
> This should be changed either to {{MAVEN_HOME}} or {{M3_HOME}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MNG-5607) Don't use M2_HOME anymore in mvn shell/batch file anymore
[
https://issues.apache.org/jira/browse/MNG-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte closed MNG-5607.
--
Resolution: Fixed
Assignee: Christian Schulte
Fix Version/s: 3.4.0
> Don't use M2_HOME anymore in mvn shell/batch file anymore
> -
>
> Key: MNG-5607
> URL: https://issues.apache.org/jira/browse/MNG-5607
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.1
> Environment: all
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
>
> Currently the {{mvn}} shell script and the {{mvn.bat}} using {{M2_HOME}}.
> This should be changed either to {{MAVEN_HOME}} or {{M3_HOME}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5607) Don't use M2_HOME anymore in mvn shell/batch file anymore
[
https://issues.apache.org/jira/browse/MNG-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118583#comment-15118583
]
Dan Tran commented on MNG-5607:
---
even better if not using any var. the script already self discover its install
directory
> Don't use M2_HOME anymore in mvn shell/batch file anymore
> -
>
> Key: MNG-5607
> URL: https://issues.apache.org/jira/browse/MNG-5607
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.1
> Environment: all
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> Currently the {{mvn}} shell script and the {{mvn.bat}} using {{M2_HOME}}.
> This should be changed either to {{MAVEN_HOME}} or {{M3_HOME}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5517) Supporting semver like syntax for tag
[ https://issues.apache.org/jira/browse/MNG-5517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118568#comment-15118568 ] Christian Schulte commented on MNG-5517: I see no reason/benefit in changing anything about that syntax. See [Interval (mathematics)|https://en.wikipedia.org/wiki/Interval_(mathematics)] on why that syntax makes perfect sense. > Supporting semver like syntax for tag > --- > > Key: MNG-5517 > URL: https://issues.apache.org/jira/browse/MNG-5517 > Project: Maven > Issue Type: Improvement > Components: Dependencies, FDPFC, POM >Reporter: Vijay Dharap >Priority: Minor > Labels: close-pending > Fix For: Issues to be reviewed for 4.x > > > node js and its corresponding package manager - npm - follows semvar notation > to depict the dependencies. > The supported syntax variations for version specification can be seen here. > https://github.com/isaacs/node-semver#ranges > I find their syntax to be much more intuitive and subsequently user friendly > than what is followed in current maven dependency tag > (http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-project-dependencies.html#pom-relationships-sect-version-ranges). > Hope we can make the pom xml little more user friendly by adapting similar > version specification syntax. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5517) Supporting semver like syntax for tag
[ https://issues.apache.org/jira/browse/MNG-5517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte updated MNG-5517: --- Labels: close-pending (was: ) > Supporting semver like syntax for tag > --- > > Key: MNG-5517 > URL: https://issues.apache.org/jira/browse/MNG-5517 > Project: Maven > Issue Type: Improvement > Components: Dependencies, FDPFC, POM >Reporter: Vijay Dharap >Priority: Minor > Labels: close-pending > Fix For: Issues to be reviewed for 4.x > > > node js and its corresponding package manager - npm - follows semvar notation > to depict the dependencies. > The supported syntax variations for version specification can be seen here. > https://github.com/isaacs/node-semver#ranges > I find their syntax to be much more intuitive and subsequently user friendly > than what is followed in current maven dependency tag > (http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-project-dependencies.html#pom-relationships-sect-version-ranges). > Hope we can make the pom xml little more user friendly by adapting similar > version specification syntax. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DOXIA-521) Markdown: Allow using the standard "" for code blocks
[ https://issues.apache.org/jira/browse/DOXIA-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118557#comment-15118557 ] Hudson commented on DOXIA-521: -- SUCCESS: Integrated in doxia-all #233 (See [https://builds.apache.org/job/doxia-all/233/]) [DOXIA-521] fixed typo (hboutemy: [http://svn.apache.org/viewvc/?view=rev&rev=1726935]) * ./doxia/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownToDoxiaHtmlSerializer.java [DOXIA-521] improved comment to define why Pegdown html output has to be tweaked to match Doxia Xhtml Sink convention (hboutemy: [http://svn.apache.org/viewvc/?view=rev&rev=1726934]) * ./doxia/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownToDoxiaHtmlSerializer.java > Markdown: Allow using the standard "" for code blocks > > > Key: DOXIA-521 > URL: https://issues.apache.org/jira/browse/DOXIA-521 > Project: Maven Doxia > Issue Type: Improvement > Components: Module - Markdown >Affects Versions: 1.6 >Reporter: Santiago M. Mola > > Pegdown, as well as other Markdown parsers, translates code blocks to > . This is the standard as per the Markdown specifications and both > themes and tools (e.g. http://highlightjs.org/) rely on this syntax. > However, the doxia markdown module overrides this behaviour and uses " class="source">. It would be nice to revert the default behaviour to the > standard. If there are use cases for such an alternative syntax, it could be > provided as an option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5607) Don't use M2_HOME anymore in mvn shell/batch file anymore
[
https://issues.apache.org/jira/browse/MNG-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118555#comment-15118555
]
Christian Schulte commented on MNG-5607:
Command name is 'java' so environment variable should be 'JAVA_HOME' for
consistency. Tending to close MNG-5606 'won't fix'.
> Don't use M2_HOME anymore in mvn shell/batch file anymore
> -
>
> Key: MNG-5607
> URL: https://issues.apache.org/jira/browse/MNG-5607
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.1
> Environment: all
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> Currently the {{mvn}} shell script and the {{mvn.bat}} using {{M2_HOME}}.
> This should be changed either to {{MAVEN_HOME}} or {{M3_HOME}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5607) Don't use M2_HOME anymore in mvn shell/batch file anymore
[
https://issues.apache.org/jira/browse/MNG-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118549#comment-15118549
]
Christian Schulte commented on MNG-5607:
+1 for MVN_HOME
> Don't use M2_HOME anymore in mvn shell/batch file anymore
> -
>
> Key: MNG-5607
> URL: https://issues.apache.org/jira/browse/MNG-5607
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.1
> Environment: all
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> Currently the {{mvn}} shell script and the {{mvn.bat}} using {{M2_HOME}}.
> This should be changed either to {{MAVEN_HOME}} or {{M3_HOME}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5227) The 'optional' flag of a dependency should be manageable.
[
https://issues.apache.org/jira/browse/MNG-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118546#comment-15118546
]
Hudson commented on MNG-5227:
-
SUCCESS: Integrated in maven-3.x #1202 (See
[https://builds.apache.org/job/maven-3.x/1202/])
[MNG-5227] The 'optional' flag of a dependency should be manageable. (schulte:
rev 2fb5fd5e6b7ebded597329d1e87e255fb368ba73)
*
maven-model-builder/src/main/java/org/apache/maven/model/management/DefaultDependencyManagementInjector.java
> The 'optional' flag of a dependency should be manageable.
> -
>
> Key: MNG-5227
> URL: https://issues.apache.org/jira/browse/MNG-5227
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
>
> {code}
>
>
>
> groupId
> artifactId
> version
> false
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5940) Change the maven-source-plugin jar goal into jar-no-fork in Maven Super POM
[
https://issues.apache.org/jira/browse/MNG-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118547#comment-15118547
]
Hudson commented on MNG-5940:
-
SUCCESS: Integrated in maven-3.x #1202 (See
[https://builds.apache.org/job/maven-3.x/1202/])
[MNG-5940] Change the maven-source-plugin jar goal into jar-no-fork in
(schulte: rev b3ed29d541f45604eaf24219d119377476e3bbfe)
* maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml
> Change the maven-source-plugin jar goal into jar-no-fork in Maven Super POM
> ---
>
> Key: MNG-5940
> URL: https://issues.apache.org/jira/browse/MNG-5940
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
>
> At the moment the {{maven-source-plugin:jar}} goal is defined in the Maven
> super pom:
> {code:xml}
>
> true
> maven-source-plugin
>
>
> attach-sources
>
> jar
>
>
>
>
> {code}
> where the goal of {{maven-source-plugin}} should be changed from {{jar}} into
> {{jar-no-fork}}, cause most of the time you need to override this behaviour.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIA-521) Markdown: Allow using the standard "" for code blocks
[ https://issues.apache.org/jira/browse/DOXIA-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118512#comment-15118512 ] Hervé Boutemy commented on DOXIA-521: - in fact, the question is to define "better" :) for Kristian, better is "consistent with Doxia's XHTML Sink output" as coded for verbatim() Doxia event in http://maven.apache.org/doxia/doxia/doxia-core/xref/org/apache/maven/doxia/sink/XhtmlBaseSink.html#L1091 I understand that it's not how Pegdown renders html natively If we change the way Doxia renders Xhtml, we'll need to document this (which is clearly not easy to find currently), since this will have an impact on how to write a Doxia Sitetools skin that integrates a highlighting lib > Markdown: Allow using the standard "" for code blocks > > > Key: DOXIA-521 > URL: https://issues.apache.org/jira/browse/DOXIA-521 > Project: Maven Doxia > Issue Type: Improvement > Components: Module - Markdown >Affects Versions: 1.6 >Reporter: Santiago M. Mola > > Pegdown, as well as other Markdown parsers, translates code blocks to > . This is the standard as per the Markdown specifications and both > themes and tools (e.g. http://highlightjs.org/) rely on this syntax. > However, the doxia markdown module overrides this behaviour and uses " class="source">. It would be nice to revert the default behaviour to the > standard. If there are use cases for such an alternative syntax, it could be > provided as an option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MNG-5227) The 'optional' flag of a dependency should be manageable.
[
https://issues.apache.org/jira/browse/MNG-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte closed MNG-5227.
--
Resolution: Fixed
Fix Version/s: 3.4.0
> The 'optional' flag of a dependency should be manageable.
> -
>
> Key: MNG-5227
> URL: https://issues.apache.org/jira/browse/MNG-5227
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
>
> {code}
>
>
>
> groupId
> artifactId
> version
> false
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5227) The 'optional' flag of a dependency should be manageable.
[
https://issues.apache.org/jira/browse/MNG-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118503#comment-15118503
]
Christian Schulte commented on MNG-5227:
Fixed in Aether with
[d35844ccf9900c8d141cf796b67677a27830bec6|http://git.eclipse.org/c/aether/aether-core.git/commit/?id=d35844ccf9900c8d141cf796b67677a27830bec6].
> The 'optional' flag of a dependency should be manageable.
> -
>
> Key: MNG-5227
> URL: https://issues.apache.org/jira/browse/MNG-5227
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Minor
>
> {code}
>
>
>
> groupId
> artifactId
> version
> false
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5227) The 'optional' flag of a dependency should be manageable.
[
https://issues.apache.org/jira/browse/MNG-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MNG-5227:
---
Issue Type: Bug (was: Wish)
> The 'optional' flag of a dependency should be manageable.
> -
>
> Key: MNG-5227
> URL: https://issues.apache.org/jira/browse/MNG-5227
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Minor
>
> {code}
>
>
>
> groupId
> artifactId
> version
> false
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (MNG-5227) The 'optional' flag of a dependency should be manageable.
[
https://issues.apache.org/jira/browse/MNG-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reopened MNG-5227:
Assignee: Christian Schulte
This has been solved in Aether but not in Maven.
> The 'optional' flag of a dependency should be manageable.
> -
>
> Key: MNG-5227
> URL: https://issues.apache.org/jira/browse/MNG-5227
> Project: Maven
> Issue Type: Wish
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Minor
>
> {code}
>
>
>
> groupId
> artifactId
> version
> false
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MNG-5632) Optional tag in dependencyManagement not inherited - disallow and/or document
[
https://issues.apache.org/jira/browse/MNG-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte closed MNG-5632.
--
Resolution: Duplicate
> Optional tag in dependencyManagement not inherited - disallow and/or document
> -
>
> Key: MNG-5632
> URL: https://issues.apache.org/jira/browse/MNG-5632
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.1.1, 3.2.1
>Reporter: Sebastian Leske
>Priority: Minor
>
> As explained in MNG-1630 adn MNG-4600, specifying
> {code}
> true
> {code}
> in dependencyManagement has no effect. "optional" only takes effect when
> specified directly in the "dependencies" section of the POM.
> However, this is not documented anywhere, and rather unexpected, because both
> version and scope can be set from dependencyManagement.
> If the current behaviour is intentional, it should be documented. Ideally,
> Maven should also disallow the use of "" in dependencyManagement
> (or at least issue a warning).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5966) Add bash completion to delivery
[ https://issues.apache.org/jira/browse/MNG-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118485#comment-15118485 ] Hervé Boutemy commented on MNG-5966: our contribution documentation is http://maven.apache.org/guides/development/guide-helping.html The "Submit patches" doc is very svn-centric: Maven core being under git, "Maven GIT Convention" seems more adapted to current case Then doing a pull request on github for current MNG-5966 issue would be perfect Notice that I don't know how to write test suites for such bash completion script: that's one of the drawback of adding this feature, ie not easy to unit-test, then require careful updates > Add bash completion to delivery > --- > > Key: MNG-5966 > URL: https://issues.apache.org/jira/browse/MNG-5966 > Project: Maven > Issue Type: Improvement > Components: Command Line >Affects Versions: 3.4.0 >Reporter: Karl Heinz Marbaise >Priority: Minor > > I would like to suggest to add a bash completion to our maven delivery. > I would like to suggest to use the following one: > https://github.com/juven/maven-bash-completion (which is already under Apache > License)... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MNG-5810) "mvn compile" changes "/" to "." in ERROR messages in directory names
[ https://issues.apache.org/jira/browse/MNG-5810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MNG-5810. -- Resolution: Cannot Reproduce Assignee: Christian Schulte Fix Version/s: 3.4.0 > "mvn compile" changes "/" to "." in ERROR messages in directory names > - > > Key: MNG-5810 > URL: https://issues.apache.org/jira/browse/MNG-5810 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.1 > Environment: linux / gentoo. >Reporter: John Smith >Assignee: Christian Schulte >Priority: Minor > Fix For: 3.4.0 > > Attachments: MNG-5810.DOTS.IN.DIRECTORY.NAME.zip > > > First, it's incredible how long it takes until one can submit an issue here > ... searching for the right place, then registering ... takes substantially > longer than filing the issue itself. Pretty annoying. > Error description: when doing an "mvn compile", dots in directory names are > replaced by slashes. Now you can't just copy & paste the file name anymore to > the shell to do a "vi undo maven's replacement by changing back the "/" to "." whereever needed. > Example: > [ERROR] > /data/people//MINECRAFT/WORLD/TARZAN/1/8/src/spigot-1/8/3/Spigot/Spigot-Server/src/main/java/org/spigotmc/Metrics.java:[142] > blahfurz cannot be resolved to a variable > The directory names are "WORLD.TARZAN.1.8" and "spigot-1.8.3". > And NO, telling me to "well, don't use dots in directory names" or "well, > don't use vi, use one of the fancy IDEs around" is not an option for me, > thanks a lot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5810) "mvn compile" changes "/" to "." in ERROR messages in directory names
[
https://issues.apache.org/jira/browse/MNG-5810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MNG-5810:
---
Attachment: MNG-5810.DOTS.IN.DIRECTORY.NAME.zip
Example project demonstrating the issue is not reproducible with
[3.4.0-SNAPSHOT|https://builds.apache.org/view/All/job/maven-3.3-release-status-build/].
{code}
Apache Maven 3.4.0-SNAPSHOT (5c98a4261f7e50ee0197902c5737ebfc0acac724;
2016-01-26T02:49:41+01:00)
{code}
{code}
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building MNG-5810 1.0
[INFO]
[INFO]
[INFO] --- maven-resources-plugin:2.7:resources (default-resources) @ MNG-5810
---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/tmp/MNG-5810.DOTS.IN.DIRECTORY.NAME/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.5:compile (default-compile) @ MNG-5810 ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to
/tmp/MNG-5810.DOTS.IN.DIRECTORY.NAME/target/classes
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/tmp/MNG-5810.DOTS.IN.DIRECTORY.NAME/src/main/java/localhost/App.java:[3,8]
class AppProducingCompilerError is public, should be declared in a file named
AppProducingCompilerError.java
[INFO] 1 error
[INFO] -
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 3.511 s
[INFO] Finished at: 2016-01-27T03:04:16+01:00
[INFO] Final Memory: 12M/41M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.5:compile (default-compile) on
project MNG-5810: Compilation failure
[ERROR]
/tmp/MNG-5810.DOTS.IN.DIRECTORY.NAME/src/main/java/localhost/App.java:[3,8]
class AppProducingCompilerError is public, should be declared in a file named
AppProducingCompilerError.java
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
{code}
Error output does not show translation of dots in directory names occuring.
> "mvn compile" changes "/" to "." in ERROR messages in directory names
> -
>
> Key: MNG-5810
> URL: https://issues.apache.org/jira/browse/MNG-5810
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.1
> Environment: linux / gentoo.
>Reporter: John Smith
>Priority: Minor
> Attachments: MNG-5810.DOTS.IN.DIRECTORY.NAME.zip
>
>
> First, it's incredible how long it takes until one can submit an issue here
> ... searching for the right place, then registering ... takes substantially
> longer than filing the issue itself. Pretty annoying.
> Error description: when doing an "mvn compile", dots in directory names are
> replaced by slashes. Now you can't just copy & paste the file name anymore to
> the shell to do a "vi undo maven's replacement by changing back the "/" to "." whereever needed.
> Example:
> [ERROR]
> /data/people//MINECRAFT/WORLD/TARZAN/1/8/src/spigot-1/8/3/Spigot/Spigot-Server/src/main/java/org/spigotmc/Metrics.java:[142]
> blahfurz cannot be resolved to a variable
> The directory names are "WORLD.TARZAN.1.8" and "spigot-1.8.3".
> And NO, telling me to "well, don't use dots in directory names" or "well,
> don't use vi, use one of the fancy IDEs around" is not an option for me,
> thanks a lot.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MNG-5940) Change the maven-source-plugin jar goal into jar-no-fork in Maven Super POM
[
https://issues.apache.org/jira/browse/MNG-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte closed MNG-5940.
--
Resolution: Fixed
Assignee: Christian Schulte
Fix Version/s: 3.4.0
> Change the maven-source-plugin jar goal into jar-no-fork in Maven Super POM
> ---
>
> Key: MNG-5940
> URL: https://issues.apache.org/jira/browse/MNG-5940
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
>
> At the moment the {{maven-source-plugin:jar}} goal is defined in the Maven
> super pom:
> {code:xml}
>
> true
> maven-source-plugin
>
>
> attach-sources
>
> jar
>
>
>
>
> {code}
> where the goal of {{maven-source-plugin}} should be changed from {{jar}} into
> {{jar-no-fork}}, cause most of the time you need to override this behaviour.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5966) Add bash completion to delivery
[ https://issues.apache.org/jira/browse/MNG-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118456#comment-15118456 ] Juven Xu commented on MNG-5966: --- can someone point me some basic docs on contribution workflow? like where to fork a branch, what test suites to run, code review etc. [~aheritier] yes I'm always in this community, currently working on a big company and apply maven in big scale :) thanks > Add bash completion to delivery > --- > > Key: MNG-5966 > URL: https://issues.apache.org/jira/browse/MNG-5966 > Project: Maven > Issue Type: Improvement > Components: Command Line >Affects Versions: 3.4.0 >Reporter: Karl Heinz Marbaise >Priority: Minor > > I would like to suggest to add a bash completion to our maven delivery. > I would like to suggest to use the following one: > https://github.com/juven/maven-bash-completion (which is already under Apache > License)... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1219) skipAfterFailureCount should not count flaky tests as failures when using rerunFailingTestsCount
[ https://issues.apache.org/jira/browse/SUREFIRE-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118455#comment-15118455 ] Sean Flanigan commented on SUREFIRE-1219: - (Wow, I haven't used that [~seanf] account in years. I'd like to delete it, but that email address is dead and my password isn't accepted.) [~tibor17], I certainly don't want to wait until all 100 tests have finished to implement fail-fast, or I wouldn't have submitted this bug! In fact, it's when you are forced to use rerun that fail-fast becomes even more important. Otherwise your test times can double or triple when there is a common root cause breaking every test. I'm sorry Tibor, but I'm finding your explanations very difficult to understand. I don't understand what it is about forking and surefire-junit4/surefire-junit47 which prevents us from incrementing the counter only when a test has failed _all its runs_ (instead of each time there is a failure). If we can only get the right behaviour in some cases, I think that's more important than having the same (wrong IMHO) behaviour in all cases. Even if we risk running an extra couple of unnecessary tests due to concurrency issues when the fail counter is triggered, that's got to be better than running all the tests, or turning off the rerun feature. But I haven't read that code, so I can't really suggest anything concrete. I gather that this all has to do with the fact that there is currently a separate rerun phase after the main testing phase, so it might take a lot of refactoring to make the sort of change I have in mind. In any case, what's implemented now is not good, because even though surefire-junit4 now in fact does run flaky tests multiple times, the XML file does not reflect this - it only reports the first run (a failure), and ignores the second run (which passed). (This is inferred from the logging in my real project's tests.) Not to mention the fact that the description here: https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html doesn't seem to describe what actually happens when both options are set (as I said in the original report above). I have had to disable the fail-fast feature to get flaky reruns to work as they should, which is a real shame because these two options would really complement each other. > skipAfterFailureCount should not count flaky tests as failures when using > rerunFailingTestsCount > > > Key: SUREFIRE-1219 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1219 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.19.1 >Reporter: Sean Flanigan > Attachments: SUREFIRE-1219-tests.zip > > > According to > https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html > "failed tests within re-run phase are not included in > skipAfterFailureCount". For instance, if skipAfterFailureCount is 1, but > every test passes on the second attempt, the tests are "flaky" but not > "failures". This should be reflected in summaries, in XML result files and > in fail fast (skipAfterFailureCount), but this is not the case. > If I have 10 flaky-but-not-failing tests, set rerunFailingTestsCount=1 and > skipAfterFailureCount=5: > 1. I would expect something like this to be printed on the console: > Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Flakes: 10 > 2. The XML report should list s but no . > 3. All tests should be run, not just 5 of them, in other words > skipAfterFailureCount should not count the flaky tests as part of the failure > count. > I have some tests demonstrating the problem, which I will attach to this > issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5966) Add bash completion to delivery
[ https://issues.apache.org/jira/browse/MNG-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118450#comment-15118450 ] Juven Xu commented on MNG-5966: --- 1. I did test the script on mac and linux, on idea if it works well on other unix 2. I think only possible on powshell, and that would be a big rewrite. > Add bash completion to delivery > --- > > Key: MNG-5966 > URL: https://issues.apache.org/jira/browse/MNG-5966 > Project: Maven > Issue Type: Improvement > Components: Command Line >Affects Versions: 3.4.0 >Reporter: Karl Heinz Marbaise >Priority: Minor > > I would like to suggest to add a bash completion to our maven delivery. > I would like to suggest to use the following one: > https://github.com/juven/maven-bash-completion (which is already under Apache > License)... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5846) Maven 3.3.3 ignores repository definition for "central"
[
https://issues.apache.org/jira/browse/MNG-5846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118422#comment-15118422
]
Christian Schulte commented on MNG-5846:
Regarding my 'not a regression' comment above. I am not sure how that project
has been working before. For example:
{code}
Apache Maven 3.4.0-SNAPSHOT (5c98a4261f7e50ee0197902c5737ebfc0acac724;
2016-01-26T02:49:41+01:00)
{code}
{code}
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building yyy 5.0-SNAPSHOT
[INFO]
Downloading:
http://www.liermann.ws/maven/org/apache/maven/plugins/maven-compiler-plugin/3.5/maven-compiler-plugin-3.5.pom
[WARNING] The POM for org.apache.maven.plugins:maven-compiler-plugin:jar:3.5 is
missing, no dependency information available
Downloading:
http://www.liermann.ws/maven/org/apache/maven/plugins/maven-compiler-plugin/3.5/maven-compiler-plugin-3.5.jar
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 2.599 s
[INFO] Finished at: 2016-01-27T02:22:53+01:00
[INFO] Final Memory: 6M/22M
[INFO]
[ERROR] Plugin org.apache.maven.plugins:maven-compiler-plugin:3.5 or one of its
dependencies could not be resolved: Could not find artifact
org.apache.maven.plugins:maven-compiler-plugin:jar:3.5 in central
(http://www.liermann.ws/maven/) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
{code}
And that is correct. There is no 'maven-compiler-plugin' available in the
overriden repository. This is produced using a recent
[3.4.0-SNAPSHOT|https://builds.apache.org/view/All/job/maven-3.3-release-status-build/].
> Maven 3.3.3 ignores repository definition for "central"
> ---
>
> Key: MNG-5846
> URL: https://issues.apache.org/jira/browse/MNG-5846
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.1
> Environment: n/a
>Reporter: Torsten Liermann
>
> Hi,
> The sample pom.xml works fine with maven 3.0.5 but shows a big problem while
> using maven 3.3.3.
> It's starts correctly and downloads a set of dependencies from the specified
> and overriden central repositories. The, suddenly, during a running build it
> starts downloading dependencies from the default "central" repository (which
> is actually overridden). This behaviour is problematic for us.
> In these log-statements you can see that initial downloads are done from the
> overridden definition and that later the default central repository is used.
> {quote}
>
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";
> xmlns="http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> 4.0.0
> xxx
> yyy
> 5.0-SNAPSHOT
>
>
> org.glassfish.main.appclient.client
> gf-client
> 3.1.2.2
>
>
>
>
> central
> http://www.liermann.ws/maven/
>
> true
>
>
> true
> always
>
>
>
>
>
> central
> http://www.liermann.ws/maven/
>
> true
>
>
> true
> always
>
>
>
>
> {quote}
> Log file snippet
> {quote}
> Downloading:
> http://www.liermann.ws/maven/org/glassfish/metro/metro-project/2.2.0-1/metro-project-2.2.0-1.pom
> Downloaded:
> http://www.liermann.ws/maven/org/glassfish/metro/metro-project/2.2.0-1/metro-project-2.2.0-1.pom
> (31 KB at 532.0 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/com/sun/xml/ws/jaxws-ri/2.2.6-2/jaxws-ri-2.2.6-2.pom
> Downloaded:
> http://repo1.maven.org/maven2/com/sun/xml/ws/jaxws-ri/2.2.6-2/jaxws-ri-2.2.6-2.pom
> (6 KB at 101.3 KB/sec)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5846) Maven 3.3.3 ignores repository definition for "central"
[
https://issues.apache.org/jira/browse/MNG-5846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118409#comment-15118409
]
Christian Schulte commented on MNG-5846:
Out of curiosity - which version of Maven has been used producing
{code}
Downloading:
http://repo1.maven.org/maven2/com/sun/xml/ws/jaxws-ri/2.2.6-2/jaxws-ri-2.2.6-2.pom
Downloaded:
http://repo1.maven.org/maven2/com/sun/xml/ws/jaxws-ri/2.2.6-2/jaxws-ri-2.2.6-2.pom
(6 KB at 101.3 KB/sec)
{code}
? That is not the default central repository URL since Maven 3.0.4.
I am not sure this is a regression. Do you know exactly what version was the
first no longer behaving the way described?
> Maven 3.3.3 ignores repository definition for "central"
> ---
>
> Key: MNG-5846
> URL: https://issues.apache.org/jira/browse/MNG-5846
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.1
> Environment: n/a
>Reporter: Torsten Liermann
>
> Hi,
> The sample pom.xml works fine with maven 3.0.5 but shows a big problem while
> using maven 3.3.3.
> It's starts correctly and downloads a set of dependencies from the specified
> and overriden central repositories. The, suddenly, during a running build it
> starts downloading dependencies from the default "central" repository (which
> is actually overridden). This behaviour is problematic for us.
> In these log-statements you can see that initial downloads are done from the
> overridden definition and that later the default central repository is used.
> {quote}
>
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";
> xmlns="http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> 4.0.0
> xxx
> yyy
> 5.0-SNAPSHOT
>
>
> org.glassfish.main.appclient.client
> gf-client
> 3.1.2.2
>
>
>
>
> central
> http://www.liermann.ws/maven/
>
> true
>
>
> true
> always
>
>
>
>
>
> central
> http://www.liermann.ws/maven/
>
> true
>
>
> true
> always
>
>
>
>
> {quote}
> Log file snippet
> {quote}
> Downloading:
> http://www.liermann.ws/maven/org/glassfish/metro/metro-project/2.2.0-1/metro-project-2.2.0-1.pom
> Downloaded:
> http://www.liermann.ws/maven/org/glassfish/metro/metro-project/2.2.0-1/metro-project-2.2.0-1.pom
> (31 KB at 532.0 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/com/sun/xml/ws/jaxws-ri/2.2.6-2/jaxws-ri-2.2.6-2.pom
> Downloaded:
> http://repo1.maven.org/maven2/com/sun/xml/ws/jaxws-ri/2.2.6-2/jaxws-ri-2.2.6-2.pom
> (6 KB at 101.3 KB/sec)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MNG-5955) [Regression] Module cannot resolve parent project version
[
https://issues.apache.org/jira/browse/MNG-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte closed MNG-5955.
--
Resolution: Won't Fix
Assignee: Christian Schulte
This is not a regression. Behaviour is correct. The parent version element has
not been taken into account while resolving parent projects locally before and
that has been fixed recently. Google will yield things like
[http://stackoverflow.com/questions/1981151/warning-on-using-project-parent-version-as-the-version-of-a-module-in-maven-3]
immediately. This has been restricted further in [Maven
3.4.0-SNAPSHOT|https://builds.apache.org/view/All/job/maven-3.3-release-status-build/].
> [Regression] Module cannot resolve parent project version
> -
>
> Key: MNG-5955
> URL: https://issues.apache.org/jira/browse/MNG-5955
> Project: Maven
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.3.9
>Reporter: Andrea Scarpino
>Assignee: Christian Schulte
>
> Starting with 3.3.9 modules cannot resolve parent.project.version anymore:
> {noformat}
> $ apache-maven-3.3.9/bin/mvn clean compile
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for org.foo:org.foo.api:[unknown-version]:
> Failure to find org.foo:org.foo.parent:pom:${parent.project.version} in
> http://artifactory.local/artifactory/libs-release was cached in the local
> repository, resolution will not be reattempted until the update interval of
> releases has elapsed or updates are forced and 'parent.relativePath' points
> at wrong local POM @ line 8, column 10
> {noformat}
> Parent POM contains:
> {noformat}
>0.0.1-SNAPSHOT
> {noformat}
> While modules POMs contains:
> {noformat}
>
> org.foo
> org.foo.parent
> ${parent.project.version}
>
> {noformat}
> It works fine with 3.3.1 and 3.3.3.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5955) [Regression] Module cannot resolve parent project version
[
https://issues.apache.org/jira/browse/MNG-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MNG-5955:
---
Labels: (was: regression)
> [Regression] Module cannot resolve parent project version
> -
>
> Key: MNG-5955
> URL: https://issues.apache.org/jira/browse/MNG-5955
> Project: Maven
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.3.9
>Reporter: Andrea Scarpino
>
> Starting with 3.3.9 modules cannot resolve parent.project.version anymore:
> {noformat}
> $ apache-maven-3.3.9/bin/mvn clean compile
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for org.foo:org.foo.api:[unknown-version]:
> Failure to find org.foo:org.foo.parent:pom:${parent.project.version} in
> http://artifactory.local/artifactory/libs-release was cached in the local
> repository, resolution will not be reattempted until the update interval of
> releases has elapsed or updates are forced and 'parent.relativePath' points
> at wrong local POM @ line 8, column 10
> {noformat}
> Parent POM contains:
> {noformat}
>0.0.1-SNAPSHOT
> {noformat}
> While modules POMs contains:
> {noformat}
>
> org.foo
> org.foo.parent
> ${parent.project.version}
>
> {noformat}
> It works fine with 3.3.1 and 3.3.3.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MNG-5475) [REGRESSION] repo and pluginRepo with different id's prevent resolution of common parent POM
[
https://issues.apache.org/jira/browse/MNG-5475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte closed MNG-5475.
--
Resolution: Fixed
Issue is not reproducible using
{code}
Apache Maven 3.4.0-SNAPSHOT (5c98a4261f7e50ee0197902c5737ebfc0acac724;
2016-01-26T02:49:41+01:00)
{code}
Looking at MNG-5163, the plugin repositories have not been used in Maven <
3.0.4. There also is MNG-5149 correcting a repository id issue in 3.0.4.
I guess the issue has been solved in Aether. Maybe the Aether bugzilla contains
a corresponding entry.
Please re-open, if the issue still exists.
> [REGRESSION] repo and pluginRepo with different id's prevent resolution of
> common parent POM
> -
>
> Key: MNG-5475
> URL: https://issues.apache.org/jira/browse/MNG-5475
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.4, 3.0.5, 3.1.0-alpha-1
> Environment: OS X (10.8.3), JDK 1.6
>Reporter: John Casey
>Priority: Critical
> Attachments: repo-id-squash.zip
>
>
> I have a settings.xml file with an activated profile that lists one
> repository and one pluginRepository, both pointing at the same repo (on disk)
> BUT using different repository id's.
> In this repository, I have deployed a parent POM and a plugin. The plugin
> lists the parent POM as its parent.
> I also have another jar project that uses the parent POM as its parent, and
> uses the plugin during its build.
> NOW:
> When building with Maven 3.0.3, the jar project build completes correctly.
> But, when I build with ANY VERSION AFTER 3.0.3 (3.0.4, 3.0.5, 3.1.0-alpha-1
> from March 30th, io.tesla.maven.apache-maven 3.1.2...even though that's not
> part of Apache Maven at all) IT FAILS.
> The specific failure is that it cannot find the common parent POM as it's
> trying to resolve the plugin. Looking closely at the build logs, you can see
> Maven resolve the parent POM using the non-plugin repository, and update
> _maven.repository (I've verified that this non-plugin repository's id is
> stored here). Then, Maven tries to resolve the plugin POM, sees that the
> parent POM is in the local repository and isn't set to be updated yet. So, it
> tries to verify that that parent POM is available via the plugin repositories
> it knows about...which is where _maven.repository seems to come in. It has
> the wrong value, and causes Maven to discard the locally cached parent POM.
> So, Maven won't update this parent POM in the local repo, but refuses to use
> the one that's there because it came from the wrong place.
> It seems like Aether is not smart enough to understand that the two
> repositories are the same, even though the repository-id is different. I
> suspect this could lead to VERY strange-seeming errors if two projects
> referenced the same parent POM and repository URL but with different
> repo-id's.
> I'm attaching a test case. It contains the repository with the parent POM and
> the plugin, along with the source projects for each. It also contains the jar
> project (bar-child) which has a settings.xml file in it. Finally, in the
> bar-child/ directory you'll find build-*.log files corresponding to each
> attempt I made with different Maven versions. The root directory is:
> repo-id-squash/
> NOTE: If you want to run the test case, you'll need to modify the paths in
> the bar-child/settings.xml since they're currently specific to my filesystem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MSHARED-448) testRecreation failure with OpenJDK 8 on Linux
[
https://issues.apache.org/jira/browse/MSHARED-448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118059#comment-15118059
]
Michael Osipov edited comment on MSHARED-448 at 1/26/16 10:58 PM:
--
Confirming on Ubuntu 14.04 LTS:
{noformat}
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: /opt/apache-maven-3.3.9
Java version: 1.8.0_66-internal, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-i386/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "linux", version: "3.13.0-24-generic", arch: "i386", family: "unix"
{noformat}
output:
{noformat}
testRecreation(org.apache.maven.archiver.MavenArchiverTest) Time elapsed:
0.036 sec <<< FAILURE!
junit.framework.AssertionFailedError: expected:<145384328> but
was:<145384322>
at junit.framework.Assert.fail(Assert.java:50)
at junit.framework.Assert.failNotEquals(Assert.java:287)
at junit.framework.Assert.assertEquals(Assert.java:67)
at junit.framework.Assert.assertEquals(Assert.java:134)
at junit.framework.Assert.assertEquals(Assert.java:140)
at
org.apache.maven.archiver.MavenArchiverTest.testRecreation(MavenArchiverTest.java:250)
Results :
Failed tests:
MavenArchiverTest.testRecreation:250 expected:<145384328> but
was:<145384322>
{noformat}
It must be some change in Java 8 which causes this. All I can see is that as
soon as Plexus Archiver creates a {{FileOutputStream}} {{mtime}} of that file
is changed. I think there is absolutely nothing we can do but skip this test
with Java 8. Maybe someone else has a better idea.
was (Author: michael-o):
Confirming on Ubuntu 14.04 LTS:
{noformat}
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: /opt/apache-maven-3.3.9
Java version: 1.8.0_66-internal, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-i386/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "linux", version: "3.13.0-24-generic", arch: "i386", family: "unix"
{noformat}
output:
{noformat}
testRecreation(org.apache.maven.archiver.MavenArchiverTest) Time elapsed:
0.036 sec <<< FAILURE!
junit.framework.AssertionFailedError: expected:<145384328> but
was:<145384322>
at junit.framework.Assert.fail(Assert.java:50)
at junit.framework.Assert.failNotEquals(Assert.java:287)
at junit.framework.Assert.assertEquals(Assert.java:67)
at junit.framework.Assert.assertEquals(Assert.java:134)
at junit.framework.Assert.assertEquals(Assert.java:140)
at
org.apache.maven.archiver.MavenArchiverTest.testRecreation(MavenArchiverTest.java:250)
Results :
Failed tests:
MavenArchiverTest.testRecreation:250 expected:<145384328> but
was:<145384322>
{noformat}
> testRecreation failure with OpenJDK 8 on Linux
> --
>
> Key: MSHARED-448
> URL: https://issues.apache.org/jira/browse/MSHARED-448
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: maven-archiver-3.0.0
> Environment: OpenJDK 1.8.0_60 (Linux, amd64)
> Maven 3.3.3
>Reporter: Mikolaj Izdebski
>
> testRecreation test of maven-archiver 3.0.0 fails with OpenJDK on Linux
> {code}
> testRecreation(org.apache.maven.archiver.MavenArchiverTest) Time elapsed:
> 0.026 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<144525731> but
> was:<144525725>
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.failNotEquals(Assert.java:287)
> at junit.framework.Assert.assertEquals(Assert.java:67)
> at junit.framework.Assert.assertEquals(Assert.java:134)
> at junit.framework.Assert.assertEquals(Assert.java:140)
> at
> org.apache.maven.archiver.MavenArchiverTest.testRecreation(MavenArchiverTest.java:248)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIA-224) Add source name in parser
[ https://issues.apache.org/jira/browse/DOXIA-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118180#comment-15118180 ] Hudson commented on DOXIA-224: -- SUCCESS: Integrated in doxia-all #232 (See [https://builds.apache.org/job/doxia-all/232/]) [DOXIA-224] Add source name in parser Parser has extra parse method, AbstractParser has a default implementation for it. Apt, Confluence and TWiki already pick up the reference of the source (rfscholte: [http://svn.apache.org/viewvc/?view=rev&rev=1726913]) * ./doxia/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractParser.java * ./doxia/doxia-core/src/main/java/org/apache/maven/doxia/parser/Parser.java * ./doxia/doxia-core/src/main/java/org/apache/maven/doxia/util/ByLineReaderSource.java * ./doxia/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptParser.java * ./doxia/doxia-modules/doxia-module-confluence/src/main/java/org/apache/maven/doxia/module/confluence/ConfluenceParser.java * ./doxia/doxia-modules/doxia-module-twiki/src/main/java/org/apache/maven/doxia/module/twiki/TWikiParser.java > Add source name in parser > - > > Key: DOXIA-224 > URL: https://issues.apache.org/jira/browse/DOXIA-224 > Project: Maven Doxia > Issue Type: New Feature > Components: Core >Affects Versions: 1.0-alpha-10 >Reporter: Siveton Vincent >Assignee: Robert Scholte > Fix For: 1.7 > > > Should be useful when warn log are call -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SCM-816) Can't bootstrap or checkout project with child module
[
https://issues.apache.org/jira/browse/SCM-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118158#comment-15118158
]
Robert Scholte commented on SCM-816:
What happens if you add {{-N}} to the arguments?
> Can't bootstrap or checkout project with child module
> -
>
> Key: SCM-816
> URL: https://issues.apache.org/jira/browse/SCM-816
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-plugin
>Affects Versions: 1.9.4
> Environment: Apache Maven 3.2.5
> (NON-CANONICAL_2015-04-01T06:42:27_mockbuild; 2015-04-01T08:42:27+02:00)
> Maven home: /usr/share/maven
> Java version: 1.8.0_65, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.fc22.x86_64/jre
> Default locale: fr_FR, platform encoding: UTF-8
> OS name: "linux", version: "4.2.6-200.fc22.x86_64", arch: "amd64", family:
> "unix"
>Reporter: franck bonin
>
> I don't know if it's a maven or a scm plugin issue.
> But, when we try to bootstrap or checkout a project using its single pom
> description, Maven fail complaining about missing child modules. Which is
> annoying since retrieving child modules is just why we try to boostrap the
> project...
> steps to reproduce :
> 1- lets say we get a pom file from nexus :
> mvn dependency:copy -Dartifact=my.organisation:sample-pack:1.0.0.0:pom
> -DoutputDirectory=.
> The retrieved pom file contains scm information and some sub-modules
> declaration
> 2- try to scm:bootstrap or scm:checkout it with maven :
> mvn scm:bootstrap -Dusername= -Dpassword= -f
> sample-pack-1.0.0.0.pom
> fail with maven error :
> [ERROR] Child module /path/to/some/where/./moduleb of
> /path/to/some/where/sample-pack-1.0.0.0.pom does not exist
> [ERROR] Child module /path/to/some/where/./sample of
> /path/to/some/where/sample-pack-1.0.0.0.pom does not exist
> [ERROR] Child module /path/to/some/where/./modulea of
> /path/to/some/where/sample-pack-1.0.0.0.pom does not exist
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (DOXIA-224) Add source name in parser
[ https://issues.apache.org/jira/browse/DOXIA-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed DOXIA-224. Resolution: Fixed Assignee: Robert Scholte Fix Version/s: 1.7 Fixed in [r1726913|http://svn.apache.org/r1726913], apt, confluence and twiki can use it already > Add source name in parser > - > > Key: DOXIA-224 > URL: https://issues.apache.org/jira/browse/DOXIA-224 > Project: Maven Doxia > Issue Type: New Feature > Components: Core >Affects Versions: 1.0-alpha-10 >Reporter: Siveton Vincent >Assignee: Robert Scholte > Fix For: 1.7 > > > Should be useful when warn log are call -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5963) mvn.cmd does not return ERROR_CODE
[ https://issues.apache.org/jira/browse/MNG-5963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118135#comment-15118135 ] Michael Osipov commented on MNG-5963: - Can you double-check this in your environment? If all is fine, I will remove that line. > mvn.cmd does not return ERROR_CODE > -- > > Key: MNG-5963 > URL: https://issues.apache.org/jira/browse/MNG-5963 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9 > Environment: Windows 10 >Reporter: Larry Singer > > mvn.cmd does not return an ERROR_CODE value to an enclosing script in > WIndows. Running this script: > @ECHO OFF > CALL mvn clean install > echo "%ERROR_CODE%" > Now shows "". Previously it showed "0" for success and "1" for error. > It appears that there is an @endlocal missing. A possible fix is to add > @endlocal & set ERROR_CODE=%ERROR_CODE% > before > exit /B %ERROR_CODE% -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5963) mvn.cmd does not return ERROR_CODE
[ https://issues.apache.org/jira/browse/MNG-5963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118121#comment-15118121 ] Larry Singer commented on MNG-5963: --- Michael, I agree that the @setlocal in line 56 appears to be redundant. If this is removed then the patch I posted should not be required. > mvn.cmd does not return ERROR_CODE > -- > > Key: MNG-5963 > URL: https://issues.apache.org/jira/browse/MNG-5963 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9 > Environment: Windows 10 >Reporter: Larry Singer > > mvn.cmd does not return an ERROR_CODE value to an enclosing script in > WIndows. Running this script: > @ECHO OFF > CALL mvn clean install > echo "%ERROR_CODE%" > Now shows "". Previously it showed "0" for success and "1" for error. > It appears that there is an @endlocal missing. A possible fix is to add > @endlocal & set ERROR_CODE=%ERROR_CODE% > before > exit /B %ERROR_CODE% -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSHARED-448) testRecreation failure with OpenJDK 8 on Linux
[
https://issues.apache.org/jira/browse/MSHARED-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSHARED-448:
---
Summary: testRecreation failure with OpenJDK 8 on Linux (was:
testRecreation failure with OpenJDK on Linux)
> testRecreation failure with OpenJDK 8 on Linux
> --
>
> Key: MSHARED-448
> URL: https://issues.apache.org/jira/browse/MSHARED-448
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: maven-archiver-3.0.0
> Environment: OpenJDK 1.8.0_60 (Linux, amd64)
> Maven 3.3.3
>Reporter: Mikolaj Izdebski
>
> testRecreation test of maven-archiver 3.0.0 fails with OpenJDK on Linux
> {code}
> testRecreation(org.apache.maven.archiver.MavenArchiverTest) Time elapsed:
> 0.026 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<144525731> but
> was:<144525725>
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.failNotEquals(Assert.java:287)
> at junit.framework.Assert.assertEquals(Assert.java:67)
> at junit.framework.Assert.assertEquals(Assert.java:134)
> at junit.framework.Assert.assertEquals(Assert.java:140)
> at
> org.apache.maven.archiver.MavenArchiverTest.testRecreation(MavenArchiverTest.java:248)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSHARED-448) testRecreation failure with OpenJDK 8 on Linux
[
https://issues.apache.org/jira/browse/MSHARED-448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118059#comment-15118059
]
Michael Osipov commented on MSHARED-448:
Confirming on Ubuntu 14.04 LTS:
{noformat}
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: /opt/apache-maven-3.3.9
Java version: 1.8.0_66-internal, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-i386/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "linux", version: "3.13.0-24-generic", arch: "i386", family: "unix"
{noformat}
output:
{noformat}
testRecreation(org.apache.maven.archiver.MavenArchiverTest) Time elapsed:
0.036 sec <<< FAILURE!
junit.framework.AssertionFailedError: expected:<145384328> but
was:<145384322>
at junit.framework.Assert.fail(Assert.java:50)
at junit.framework.Assert.failNotEquals(Assert.java:287)
at junit.framework.Assert.assertEquals(Assert.java:67)
at junit.framework.Assert.assertEquals(Assert.java:134)
at junit.framework.Assert.assertEquals(Assert.java:140)
at
org.apache.maven.archiver.MavenArchiverTest.testRecreation(MavenArchiverTest.java:250)
Results :
Failed tests:
MavenArchiverTest.testRecreation:250 expected:<145384328> but
was:<145384322>
{noformat}
> testRecreation failure with OpenJDK 8 on Linux
> --
>
> Key: MSHARED-448
> URL: https://issues.apache.org/jira/browse/MSHARED-448
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: maven-archiver-3.0.0
> Environment: OpenJDK 1.8.0_60 (Linux, amd64)
> Maven 3.3.3
>Reporter: Mikolaj Izdebski
>
> testRecreation test of maven-archiver 3.0.0 fails with OpenJDK on Linux
> {code}
> testRecreation(org.apache.maven.archiver.MavenArchiverTest) Time elapsed:
> 0.026 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<144525731> but
> was:<144525725>
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.failNotEquals(Assert.java:287)
> at junit.framework.Assert.assertEquals(Assert.java:67)
> at junit.framework.Assert.assertEquals(Assert.java:134)
> at junit.framework.Assert.assertEquals(Assert.java:140)
> at
> org.apache.maven.archiver.MavenArchiverTest.testRecreation(MavenArchiverTest.java:248)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIA-521) Markdown: Allow using the standard "" for code blocks
[ https://issues.apache.org/jira/browse/DOXIA-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118000#comment-15118000 ] Robert Scholte commented on DOXIA-521: -- According to [~krosenvold] in [r1465675|http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownToDoxiaHtmlSerializer.java?r1=1465675&r2=1465674&pathrev=1465675] this is better... > Markdown: Allow using the standard "" for code blocks > > > Key: DOXIA-521 > URL: https://issues.apache.org/jira/browse/DOXIA-521 > Project: Maven Doxia > Issue Type: Improvement > Components: Module - Markdown >Affects Versions: 1.6 >Reporter: Santiago M. Mola > > Pegdown, as well as other Markdown parsers, translates code blocks to > . This is the standard as per the Markdown specifications and both > themes and tools (e.g. http://highlightjs.org/) rely on this syntax. > However, the doxia markdown module overrides this behaviour and uses " class="source">. It would be nice to revert the default behaviour to the > standard. If there are use cases for such an alternative syntax, it could be > provided as an option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MPOM-102) Upgrade to FindBugs Maven Plugin 3.0.3
[
https://issues.apache.org/jira/browse/MPOM-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MPOM-102:
Description:
The currently used version (2.5.5) does not properly work on Java 8:
{noformat}
[WARNING] javadoc: warning - Error fetching URL: http://junit.org/javadoc/4.10/
[INFO] Generating "FindBugs" report ---
findbugs-maven-plugin:2.5.5:findbugs
[INFO] Locale is en
[INFO] Fork Value is true
[java] Jan 26, 2016 5:55:37 PM java.util.prefs.WindowsPreferences
[java] WARNUNG: Could not open/create prefs root node
Software\JavaSoft\Prefs at root 0x8002. Windows RegCreateKeyEx(...)
returned error code 5.
[java] The following errors occurred during analysis:
[java] Unable to get XClass for java/lang/StringBuilder
[java] java.lang.ArrayIndexOutOfBoundsException: 26721
[java] At org.objectweb.asm.ClassReader.readClass(Unknown Source)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At
edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At
edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:110)
[java] At
edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:587)
[java] At
edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:76)
[java] At
edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38)
[java] At
edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:268)
[java] At
edu.umd.cs.findbugs.ba.XFactory.getXClass(XFactory.java:652)
[java] At
edu.umd.cs.findbugs.ba.ch.Subtypes2.addInheritanceEdge(Subtypes2.java:1260)
[java] At
edu.umd.cs.findbugs.ba.ch.Subtypes2.addSupertypeEdges(Subtypes2.java:1233)
[java] At
edu.umd.cs.findbugs.ba.ch.Subtypes2.addClassAndGetClassVertex(Subtypes2.java:275)
[java] At
edu.umd.cs.findbugs.ba.ch.Subtypes2.addClass(Subtypes2.java:244)
[java] At
edu.umd.cs.findbugs.ba.AnalysisContext.setAppClassList(AnalysisContext.java:941)
[java] At
edu.umd.cs.findbugs.FindBugs2.setAppClassList(FindBugs2.java:997)
[java] At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:225)
[java] At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:393)
[java] At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1317)
[java] Unable to get XClass for java/lang/String
[java] java.lang.ArrayIndexOutOfBoundsException: 26721
[java] At org.objectweb.asm.ClassReader.readClass(Unknown Source)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At
edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At
edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:110)
[java] At
edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:587)
[java] At
edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:76)
[java] At
edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38)
[java] At
edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:268)
[java] At
edu.umd.cs.findbugs.ba.XFactory.getXClass(XFactory.java:652)
[java] At
edu.umd.cs.findbugs.ba.ch.Subtypes2.addInheritanceEdge(Subtypes2.java:1260)
[java] At
edu.umd.cs.findbugs.ba.ch.Subtypes2.addSupertypeEdges(Subtypes2.java:1233)
[java] At
edu.umd.cs.findbugs.ba.ch.Subtypes2.addClassAndGetClassVertex(Subtypes2.java:275)
[java] At
edu.umd.cs.findbugs.ba.ch.Subtypes2.addClass(Subtypes2.java:244)
[java] At
edu.umd.cs.findbugs.ba.AnalysisContext.setAppClassList(AnalysisContext.java:941)
[java] At
edu.umd.cs.findbugs.FindBugs2.setAppClassList(FindBugs2.java:997)
[java] At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:225)
[java] At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:393)
[java] At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1317)
[java] Unable to get XClass for java/util/Map$Entry
[java] java.lang.ArrayIndexOutOfBoundsException: 9216
[java] At org.objectweb.asm.ClassReader.readClass(Unknown Source)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At
edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44)
[jira] [Created] (MPOM-102) Upgrade to FindBugs Maven Plugin 3.0.3
Michael Osipov created MPOM-102:
---
Summary: Upgrade to FindBugs Maven Plugin 3.0.3
Key: MPOM-102
URL: https://issues.apache.org/jira/browse/MPOM-102
Project: Maven POMs
Issue Type: Improvement
Components: maven
Affects Versions: MAVEN-27
Environment: Apache Maven 3.3.9
(bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
Maven home: D:\Entwicklung\Programme\apache-maven-3.3.9\bin\..
Java version: 1.8.0_72, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_72\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"
Reporter: Michael Osipov
Fix For: MAVEN-30
The currently used version (2.5.5) does not properly work on Java 8:
{noformat}
[WARNING] javadoc: warning - Error fetching URL: http://junit.org/javadoc/4.10/
[INFO] Generating "FindBugs" report ---
findbugs-maven-plugin:2.5.5:findbugs
[INFO] Locale is en
[INFO] Fork Value is true
[java] Jan 26, 2016 5:55:37 PM java.util.prefs.WindowsPreferences
[java] WARNUNG: Could not open/create prefs root node
Software\JavaSoft\Prefs at root 0x8002. Windows RegCreateKeyEx(...)
returned error code 5.
[java] The following errors occurred during analysis:
[java] Unable to get XClass for java/lang/StringBuilder
[java] java.lang.ArrayIndexOutOfBoundsException: 26721
[java] At org.objectweb.asm.ClassReader.readClass(Unknown Source)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At
edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At
edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:110)
[java] At
edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:587)
[java] At
edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:76)
[java] At
edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38)
[java] At
edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:268)
[java] At
edu.umd.cs.findbugs.ba.XFactory.getXClass(XFactory.java:652)
[java] At
edu.umd.cs.findbugs.ba.ch.Subtypes2.addInheritanceEdge(Subtypes2.java:1260)
[java] At
edu.umd.cs.findbugs.ba.ch.Subtypes2.addSupertypeEdges(Subtypes2.java:1233)
[java] At
edu.umd.cs.findbugs.ba.ch.Subtypes2.addClassAndGetClassVertex(Subtypes2.java:275)
[java] At
edu.umd.cs.findbugs.ba.ch.Subtypes2.addClass(Subtypes2.java:244)
[java] At
edu.umd.cs.findbugs.ba.AnalysisContext.setAppClassList(AnalysisContext.java:941)
[java] At
edu.umd.cs.findbugs.FindBugs2.setAppClassList(FindBugs2.java:997)
[java] At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:225)
[java] At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:393)
[java] At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1317)
[java] Unable to get XClass for java/lang/String
[java] java.lang.ArrayIndexOutOfBoundsException: 26721
[java] At org.objectweb.asm.ClassReader.readClass(Unknown Source)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At
edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At
edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:110)
[java] At
edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:587)
[java] At
edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:76)
[java] At
edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38)
[java] At
edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:268)
[java] At
edu.umd.cs.findbugs.ba.XFactory.getXClass(XFactory.java:652)
[java] At
edu.umd.cs.findbugs.ba.ch.Subtypes2.addInheritanceEdge(Subtypes2.java:1260)
[java] At
edu.umd.cs.findbugs.ba.ch.Subtypes2.addSupertypeEdges(Subtypes2.java:1233)
[java] At
edu.umd.cs.findbugs.ba.ch.Subtypes2.addClassAndGetClassVertex(Subtypes2.java:275)
[java] At
edu.umd.cs.findbugs.ba.ch.Subtypes2.addClass(Subtypes2.java:244)
[java] At
edu.umd.cs.findbugs.ba.AnalysisContext.setAppClassList(AnalysisContext.java:941)
[java] At
edu.umd.cs.findbugs.FindBugs2.setAppClassList(FindB
[jira] [Created] (SCM-816) Can't bootstrap or checkout project with child module
franck bonin created SCM-816: Summary: Can't bootstrap or checkout project with child module Key: SCM-816 URL: https://issues.apache.org/jira/browse/SCM-816 Project: Maven SCM Issue Type: Bug Components: maven-plugin Affects Versions: 1.9.4 Environment: Apache Maven 3.2.5 (NON-CANONICAL_2015-04-01T06:42:27_mockbuild; 2015-04-01T08:42:27+02:00) Maven home: /usr/share/maven Java version: 1.8.0_65, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.fc22.x86_64/jre Default locale: fr_FR, platform encoding: UTF-8 OS name: "linux", version: "4.2.6-200.fc22.x86_64", arch: "amd64", family: "unix" Reporter: franck bonin I don't know if it's a maven or a scm plugin issue. But, when we try to bootstrap or checkout a project using its single pom description, Maven fail complaining about missing child modules. Which is annoying since retrieving child modules is just why we try to boostrap the project... steps to reproduce : 1- lets say we get a pom file from nexus : mvn dependency:copy -Dartifact=my.organisation:sample-pack:1.0.0.0:pom -DoutputDirectory=. The retrieved pom file contains scm information and some sub-modules declaration 2- try to scm:bootstrap or scm:checkout it with maven : mvn scm:bootstrap -Dusername= -Dpassword= -f sample-pack-1.0.0.0.pom fail with maven error : [ERROR] Child module /path/to/some/where/./moduleb of /path/to/some/where/sample-pack-1.0.0.0.pom does not exist [ERROR] Child module /path/to/some/where/./sample of /path/to/some/where/sample-pack-1.0.0.0.pom does not exist [ERROR] Child module /path/to/some/where/./modulea of /path/to/some/where/sample-pack-1.0.0.0.pom does not exist -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1219) skipAfterFailureCount should not count flaky tests as failures when using rerunFailingTestsCount
[ https://issues.apache.org/jira/browse/SUREFIRE-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117145#comment-15117145 ] Tibor Digana commented on SUREFIRE-1219: [~sflanigan] [~seanf] What can we do about this issue? Did you think about a proposal? > skipAfterFailureCount should not count flaky tests as failures when using > rerunFailingTestsCount > > > Key: SUREFIRE-1219 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1219 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.19.1 >Reporter: Sean Flanigan > Attachments: SUREFIRE-1219-tests.zip > > > According to > https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html > "failed tests within re-run phase are not included in > skipAfterFailureCount". For instance, if skipAfterFailureCount is 1, but > every test passes on the second attempt, the tests are "flaky" but not > "failures". This should be reflected in summaries, in XML result files and > in fail fast (skipAfterFailureCount), but this is not the case. > If I have 10 flaky-but-not-failing tests, set rerunFailingTestsCount=1 and > skipAfterFailureCount=5: > 1. I would expect something like this to be printed on the console: > Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Flakes: 10 > 2. The XML report should list s but no . > 3. All tests should be run, not just 5 of them, in other words > skipAfterFailureCount should not count the flaky tests as part of the failure > count. > I have some tests demonstrating the problem, which I will attach to this > issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5966) Add bash completion to delivery
[
https://issues.apache.org/jira/browse/MNG-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117014#comment-15117014
]
Michael Osipov commented on MNG-5966:
-
I wasn't referring to them but simply stating that {{command.com != cmd.exe}}.
People take them synonymously which they aren't.
> Add bash completion to delivery
> ---
>
> Key: MNG-5966
> URL: https://issues.apache.org/jira/browse/MNG-5966
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.4.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> I would like to suggest to add a bash completion to our maven delivery.
> I would like to suggest to use the following one:
> https://github.com/juven/maven-bash-completion (which is already under Apache
> License)...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5966) Add bash completion to delivery
[ https://issues.apache.org/jira/browse/MNG-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15116976#comment-15116976 ] Arnaud HERITIER commented on MNG-5966: -- Ahh we replaced or .bat by .cmd scripts ? ok it is a little bit more powerful :-) > Add bash completion to delivery > --- > > Key: MNG-5966 > URL: https://issues.apache.org/jira/browse/MNG-5966 > Project: Maven > Issue Type: Improvement > Components: Command Line >Affects Versions: 3.4.0 >Reporter: Karl Heinz Marbaise >Priority: Minor > > I would like to suggest to add a bash completion to our maven delivery. > I would like to suggest to use the following one: > https://github.com/juven/maven-bash-completion (which is already under Apache > License)... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5966) Add bash completion to delivery
[
https://issues.apache.org/jira/browse/MNG-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15116946#comment-15116946
]
Michael Osipov commented on MNG-5966:
-
Apparently, you are of those who don't know that {{cmd.exe}} is *not* DOS ;-)
> Add bash completion to delivery
> ---
>
> Key: MNG-5966
> URL: https://issues.apache.org/jira/browse/MNG-5966
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.4.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> I would like to suggest to add a bash completion to our maven delivery.
> I would like to suggest to use the following one:
> https://github.com/juven/maven-bash-completion (which is already under Apache
> License)...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5966) Add bash completion to delivery
[ https://issues.apache.org/jira/browse/MNG-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15116921#comment-15116921 ] Arnaud HERITIER commented on MNG-5966: -- Great [~juven] !!! I didn't see it was yours. Happy to see you always involved in our community. Thanks a lot [~hboutemy] For windows with a classical DOS session I think it's not possible. But within Cygwin or powershell yes .. > Add bash completion to delivery > --- > > Key: MNG-5966 > URL: https://issues.apache.org/jira/browse/MNG-5966 > Project: Maven > Issue Type: Improvement > Components: Command Line >Affects Versions: 3.4.0 >Reporter: Karl Heinz Marbaise >Priority: Minor > > I would like to suggest to add a bash completion to our maven delivery. > I would like to suggest to use the following one: > https://github.com/juven/maven-bash-completion (which is already under Apache > License)... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
