[jira] [Commented] (MPIR-252) Dependency Management report doesn't exclude system scoped dependencies
[
https://issues.apache.org/jira/browse/MPIR-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15126873#comment-15126873
]
Martijn Verburg commented on MPIR-252:
--
I can no longer repeat this problem either - many apologies for wasting time
here.
> Dependency Management report doesn't exclude system scoped dependencies
> ---
>
> Key: MPIR-252
> URL: https://issues.apache.org/jira/browse/MPIR-252
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.5.1
> Environment: Mac OS X 10.7.2, Maven 3.0.4, JDK 1.7.0_06 / JDK 1.6.0_34
>Reporter: Martijn Verburg
>
> {noformat}
> [WARNING] Unable to create Maven project for com.sun:tools:pom:localVersion
> from repository.
> org.apache.maven.project.ProjectBuildingException: Error resolving project
> artifact: Failure to find com.sun:tools:pom:localVersion in
> http://ci.jclarity.com:8081/nexus/content/groups/public/ was cached in the
> local repository, resolution will not be reattempted until the update
> interval of jclarity-central has elapsed or updates are forced for project
> com.sun:tools:pom:localVersion
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:296)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:236)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:251)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository(RepositoryUtils.java:298)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.getDependencyRow(DependencyManagementRenderer.java:237)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForScope(DependencyManagementRenderer.java:204)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForAllScopes(DependencyManagementRenderer.java:157)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderSectionProjectDependencies(DependencyManagementRenderer.java:146)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderBody(DependencyManagementRenderer.java:132)
> at
> org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:79)
> at
> org.apache.maven.report.projectinfo.DependencyManagementReport.executeReport(DependencyManagementReport.java:112)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:219)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
[jira] [Closed] (MPIR-252) Dependency Management report doesn't exclude system scoped dependencies
[
https://issues.apache.org/jira/browse/MPIR-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Verburg closed MPIR-252.
> Dependency Management report doesn't exclude system scoped dependencies
> ---
>
> Key: MPIR-252
> URL: https://issues.apache.org/jira/browse/MPIR-252
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.5.1
> Environment: Mac OS X 10.7.2, Maven 3.0.4, JDK 1.7.0_06 / JDK 1.6.0_34
>Reporter: Martijn Verburg
>
> {noformat}
> [WARNING] Unable to create Maven project for com.sun:tools:pom:localVersion
> from repository.
> org.apache.maven.project.ProjectBuildingException: Error resolving project
> artifact: Failure to find com.sun:tools:pom:localVersion in
> http://ci.jclarity.com:8081/nexus/content/groups/public/ was cached in the
> local repository, resolution will not be reattempted until the update
> interval of jclarity-central has elapsed or updates are forced for project
> com.sun:tools:pom:localVersion
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:296)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:236)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:251)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository(RepositoryUtils.java:298)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.getDependencyRow(DependencyManagementRenderer.java:237)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForScope(DependencyManagementRenderer.java:204)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForAllScopes(DependencyManagementRenderer.java:157)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderSectionProjectDependencies(DependencyManagementRenderer.java:146)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderBody(DependencyManagementRenderer.java:132)
> at
> org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:79)
> at
> org.apache.maven.report.projectinfo.DependencyManagementReport.executeReport(DependencyManagementReport.java:112)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:219)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>
[jira] [Commented] (SUREFIRE-1137) Problem with Umlauts in stdout
[
https://issues.apache.org/jira/browse/SUREFIRE-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15126899#comment-15126899
]
Andreas Gudian commented on SUREFIRE-1137:
--
[~michael-o], well, that's too long ago for me to remember. What I do remember
is that I kept trying out different approaches and it took more than one
iteration to get it to the point where it was then.
OK, I checked the commit as well. I think one problem that I had was that
specifying {{-Dfile.encoding}} didn't always have the desired effect. That's
also kind of what the docs say, which is: don't trust that thing - it's more of
an internal piece of information that may be used by some of the JRE classes,
but it is never guaranteed that it is actually obeyed. Other information from
the installation, the system or the environment variables can come into play as
well.
So why using {{ISO-8859-1}}? It's pretty arbitrary, but it is one of the
canonical charsets that contain ASCII in unchanged form. It's just a fixture to
transport the ASCII-fied information between the forks. Byte arrays are to be
transferred as they are (but printable), CharSequences are transported using
their unicode codepoints in ASCII. All of them are reconstructed on the other
side hopefully to their original state. For some output variants, Strings
encoded as byte-arrays need to be re-coded to fit a target encoding (e.g. the
XML files need to be UTF-8)... So far for the idea...
But you're right with the StreamPumpers... The intention was to pass the
charset in {{CommandLineUtils.executeCommandLineAsCallable}} to the
{{StreamPumper}} instances. If the host process uses a charset that doesn't
start with the ASCII table, we're in trouble. No idea if that wouldn't break
even more things than just some glitches in the output, though...
> Problem with Umlauts in stdout
> --
>
> Key: SUREFIRE-1137
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1137
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.18
> Environment: Linux
>Reporter: Jürgen Zeller
>Assignee: Andreas Gudian
> Fix For: 2.19
>
> Attachments: TEST-eu.jzeller.AppTest.xml, surefire-test.zip,
> surefire-test.zip
>
>
> When using Cp1252 as file encoding, the generated Surefire stdout report
> contains invalid characters when run on Linux. When running the same test on
> Windows, everything is fine.
> A simular Problem was reported in SUREFIRE-998
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1220) Surefire never outputs UTF-8 under Windows
[
https://issues.apache.org/jira/browse/SUREFIRE-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15126922#comment-15126922
]
Andreas Gudian commented on SUREFIRE-1220:
--
> 3. if redirectTestOutputToFile is used, apply the child VM encoding to the
> file and not the parent's one.
I think that this is how it's currently done. At least that's the expectation:
* XML-Report: UTF-8.
* TestOutput file (.txt): unchanged bytes as written by the forked VM.
* Console-Out: Possibly recoded to the default encoding of the main process
(may lose some characters).
I hoped that we got at least the first two right so far, but I'm not so sure on
the third... It's been a while since I looked into classes... :)
> Surefire never outputs UTF-8 under Windows
> --
>
> Key: SUREFIRE-1220
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1220
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
> Environment: Windows 10, 64-bit
> DejaVu Sans font
>Reporter: Gili
> Attachments: 2016-01-29_113906.png, exec_exec.png, output.exec.txt,
> output.test.txt, surefire-1220.zip, test.png
>
>
> I'm having problems getting Surefire to output UTF-8 fonts under Windows.
> When I run a unit test that outputs a Guava Range ("10‥20") the TWO DOT
> LEADER unicode character always gets rendered as a question mark.
> If I run the exact same code outside of Surefire (using a main() entry point)
> the UTF-8 character renders just fine. The repro steps are quite simple:
> # Create a Maven project.
> # Run {code}System.out.println(Range.closed(10, 30));{code} in a Java class
> with a main() entry point, and from a JUnit test.
> # The main() entry point will output UTF-8 just fine. The JUnit test will
> output a question mark in place of the unicode.
> Here is my pom.xml file:
> {code}
>
> 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
> com.mycompany
> mavenproject1
> 1.0-SNAPSHOT
> jar
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> -Dfile.encoding=UTF-8
>
>
>
> org.codehaus.mojo
> exec-maven-plugin
> 1.4.0
>
>
>
> java
>
>
>
>
> foo.Main
>
>
>
>
>
>
> com.google.guava
> guava
> 19.0
>
>
> junit
> junit
> 4.12
> test
>
>
>
> UTF-8
> 1.8
> 1.8
>
>
> {code}
> I tried the same thing using TestNG tests and noticed that although output to
> console was still wrong, the outputted testng-results.xml file contained the
> correct character.
> Can you reproduce this on your end?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (MPIR-252) Dependency Management report doesn't exclude system scoped dependencies
[
https://issues.apache.org/jira/browse/MPIR-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Verburg resolved MPIR-252.
--
Resolution: Cannot Reproduce
> Dependency Management report doesn't exclude system scoped dependencies
> ---
>
> Key: MPIR-252
> URL: https://issues.apache.org/jira/browse/MPIR-252
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.5.1
> Environment: Mac OS X 10.7.2, Maven 3.0.4, JDK 1.7.0_06 / JDK 1.6.0_34
>Reporter: Martijn Verburg
>
> {noformat}
> [WARNING] Unable to create Maven project for com.sun:tools:pom:localVersion
> from repository.
> org.apache.maven.project.ProjectBuildingException: Error resolving project
> artifact: Failure to find com.sun:tools:pom:localVersion in
> http://ci.jclarity.com:8081/nexus/content/groups/public/ was cached in the
> local repository, resolution will not be reattempted until the update
> interval of jclarity-central has elapsed or updates are forced for project
> com.sun:tools:pom:localVersion
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:296)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:236)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:251)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository(RepositoryUtils.java:298)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.getDependencyRow(DependencyManagementRenderer.java:237)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForScope(DependencyManagementRenderer.java:204)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForAllScopes(DependencyManagementRenderer.java:157)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderSectionProjectDependencies(DependencyManagementRenderer.java:146)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderBody(DependencyManagementRenderer.java:132)
> at
> org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:79)
> at
> org.apache.maven.report.projectinfo.DependencyManagementReport.executeReport(DependencyManagementReport.java:112)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:219)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
>
[jira] [Created] (MNG-5969) Multiple times attaching the same artifact should fail the build
Karl Heinz Marbaise created MNG-5969:
Summary: Multiple times attaching the same artifact should fail
the build
Key: MNG-5969
URL: https://issues.apache.org/jira/browse/MNG-5969
Project: Maven
Issue Type: Bug
Components: core
Affects Versions: 3.2.5, 3.2.3, 3.2.2, 3.2.1, 3.1.1, 3.4.0
Reporter: Karl Heinz Marbaise
Priority: Minor
If i take a look at [MNG-5939|MNG-5939] and use the example project and test it
with the current version of Maven on master
(f467d9142fa6c928bdae25253350915728fef286) i will get the following:
{noformat}
[INFO] --- maven-source-plugin:2.4:jar (attach-sources) @ bar ---
[INFO] Building jar: /Users/kama/Downloads/foo.bar/target/bar-0.0.1-sources.jar
[INFO]
[INFO] --- maven-source-plugin:2.4:jar-no-fork (attach-sources) @ bar ---
[INFO] Building jar: /Users/kama/Downloads/foo.bar/target/bar-0.0.1-sources.jar
[INFO] Replaced artifact foo:bar:java-source:sources:0.0.1.
[INFO]
{noformat}
First the previous behaviour (Maven 3.0.5) was to emit a {{WARNING}} which is
not the case anymore. At the moment it only creates a simple output:
{noformat}
[INFO] Replaced artifact foo:bar:java-source:sources:0.0.1.
{noformat}
which is not enough.
Furthermore I'm the opinion that in this case the build should be broken, cause
this build is wrongly configured (twice executions of maven-source-plugin
without changing the classifier it could also be several executions of other
plugins).
Maven 3.1.1, 3.2.1, 3.2.2, will ignore it completely without any message nor a
warning etc.
Maven 3.2.3, 3.2.5 will produce no warning but will attach the artifacts twice
times {{-sources}} which would fail a release like this:
{noformat}
[INFO] Installing /Users/kama/Downloads/foo.bar/target/bar-0.0.1-sources.jar to
/Users/kama/.m2/repository/foo/bar/0.0.1/bar-0.0.1-sources.jar
[INFO] Installing /Users/kama/Downloads/foo.bar/target/bar-0.0.1-sources.jar to
/Users/kama/.m2/repository/foo/bar/0.0.1/bar-0.0.1-sources.jar
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPIR-252) Dependency Management report doesn't exclude system scoped dependencies
[
https://issues.apache.org/jira/browse/MPIR-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15127066#comment-15127066
]
Michael Osipov commented on MPIR-252:
-
Bedankt!
> Dependency Management report doesn't exclude system scoped dependencies
> ---
>
> Key: MPIR-252
> URL: https://issues.apache.org/jira/browse/MPIR-252
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.5.1
> Environment: Mac OS X 10.7.2, Maven 3.0.4, JDK 1.7.0_06 / JDK 1.6.0_34
>Reporter: Martijn Verburg
>
> {noformat}
> [WARNING] Unable to create Maven project for com.sun:tools:pom:localVersion
> from repository.
> org.apache.maven.project.ProjectBuildingException: Error resolving project
> artifact: Failure to find com.sun:tools:pom:localVersion in
> http://ci.jclarity.com:8081/nexus/content/groups/public/ was cached in the
> local repository, resolution will not be reattempted until the update
> interval of jclarity-central has elapsed or updates are forced for project
> com.sun:tools:pom:localVersion
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:296)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:236)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:251)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository(RepositoryUtils.java:298)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.getDependencyRow(DependencyManagementRenderer.java:237)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForScope(DependencyManagementRenderer.java:204)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForAllScopes(DependencyManagementRenderer.java:157)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderSectionProjectDependencies(DependencyManagementRenderer.java:146)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderBody(DependencyManagementRenderer.java:132)
> at
> org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:79)
> at
> org.apache.maven.report.projectinfo.DependencyManagementReport.executeReport(DependencyManagementReport.java:112)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:219)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
>
[jira] [Created] (MNG-5970) Directory path set in mojo by Maven is lowercased, causing it to not match actual directory
Jim Showalter created MNG-5970: -- Summary: Directory path set in mojo by Maven is lowercased, causing it to not match actual directory Key: MNG-5970 URL: https://issues.apache.org/jira/browse/MNG-5970 Project: Maven Issue Type: Bug Components: Plugin API Affects Versions: 3.0.3 Environment: Linux Reporter: Jim Showalter We have a custom mojo. It has this field: /** * Location of the directory containing the pom. * @parameter default-value="project.basedir" * @required */ private String baseDir; Our unit test for the mojo works fine locally, but fails in Jenkins CI. The reason it fails is that the value of baseDir set by the Maven framework is all lowercase, but the directory path on the Jenkins server has some uppercase. We are not touching the value of baseDir, just taking it and immediately trying File[] files = new File(baseDir).listFiles(), which blows up because baseDir lowercase doesn't exist. Why is Maven not passing the directory path in as-is, instead of all lowercase? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MPMD-220) Upgrade to PMD 5.4.1
[ https://issues.apache.org/jira/browse/MPMD-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPMD-220: Issue Type: Task (was: Improvement) > Upgrade to PMD 5.4.1 > > > Key: MPMD-220 > URL: https://issues.apache.org/jira/browse/MPMD-220 > Project: Maven PMD Plugin > Issue Type: Task >Reporter: Mathieu BONIFACE > > As 5.4.1 is out and provide some interesting improvements and bugfixes, it > would be great for us to upgrade the maven plugin with this new version of > PMD. > Another important change is pmd > 5.4.0 requires Java >= 1.7.0 (see APi > Changes [here|http://sourceforge.net/projects/pmd/files/pmd/5.4.0/]) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MPMD-220) Upgrade to PMD 5.4.1
[ https://issues.apache.org/jira/browse/MPMD-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPMD-220: Issue Type: Improvement (was: Bug) > Upgrade to PMD 5.4.1 > > > Key: MPMD-220 > URL: https://issues.apache.org/jira/browse/MPMD-220 > Project: Maven PMD Plugin > Issue Type: Improvement >Reporter: Mathieu BONIFACE > > As 5.4.1 is out and provide some interesting improvements and bugfixes, it > would be great for us to upgrade the maven plugin with this new version of > PMD. > Another important change is pmd > 5.4.0 requires Java >= 1.7.0 (see APi > Changes [here|http://sourceforge.net/projects/pmd/files/pmd/5.4.0/]) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1222) ForkClient attempts to consume unrelated lines
[
https://issues.apache.org/jira/browse/SUREFIRE-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15127128#comment-15127128
]
Tibor Digana commented on SUREFIRE-1222:
[~mkouba]
The code has already changed. Please provide a project where we can reproduce
this issue. Thx.
> ForkClient attempts to consume unrelated lines
> --
>
> Key: SUREFIRE-1222
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1222
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.17
> Environment: Oracle JDK7 (build 1.7.0_79-b15)
> Linux 3.13 x86_64 with default locale cs_CZ
>Reporter: Martin Kouba
>
> This month the [Weld
> SE|https://github.com/weld/core/tree/2.3/environments/se/tests] test suite
> suddenly started to fail on a Linux machine with Oracle JDK7 and the default
> locale {{cs_CZ}}:
> {code}
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of
> range: -1
> at java.lang.String.substring(String.java:1911)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:128)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> A {{java.util.logging.Logger}} is used in the forked process. The exception
> occurs when the following log message is written to the standard output:
> {code}
> I 29, 2016 2:01:43 ODP. org.jboss.arquillian.container.se.server.Main main
> {code}
> We have found out that the timestamp *I 29, 2016 2:01:43* (i.e. 2016-01-29
> 14:01:43) is incorrectly parsed as {{ForkingRunListener.BOOTERCODE_SYSPROPS}}
> operation.
> I think the protocol should be robust enough to avoid similar collisions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MNG-5969) Multiple times attaching the same artifact should fail the build
[
https://issues.apache.org/jira/browse/MNG-5969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15127161#comment-15127161
]
Christian Schulte edited comment on MNG-5969 at 2/1/16 10:48 PM:
-
I agree that this is how Maven should behave and I committed the corresponding
changes in
[020e35816f184c10c3f87f103336fed4516f7af6|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=020e35816f184c10c3f87f103336fed4516f7af6].
I then noticed there are a lot of historic issues regarding the behaviour of
that method and reverted everything to what I think consensus had been reached.
See all the issues I added to the Javadoc of method
'MavenProject.addAttachedArtifact' in
[5f048234ff44dbf70fcad9f17834c64866f452e1|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=5f048234ff44dbf70fcad9f17834c64866f452e1].
Is it correct that you want Maven to behave as was done in the first commit?
Please see the Javadoc of the methods in interface 'MavenProjectHelper'. "Add
or replace an artifact to the current project." That's how the 'attach
artifact' use case is defined. Is your use case really "attach artifact" or is
it "add an attached artifact"? Changing the way the "attach artifact" use case
is defined needs discussion with the people who introduced that API that way.
Adding a new use case "add attached artifact" with different semantic would be
no problem.
was (Author: schulte77):
I agree that this is how Maven should behave and I committed the corresponding
changes in
[020e35816f184c10c3f87f103336fed4516f7af6|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=020e35816f184c10c3f87f103336fed4516f7af6].
I then noticed there are a lot of historic issues regarding the behaviour of
that method and reverted everything to what I think consensus had been reached.
See all the issues I added to the Javadoc of method
'MavenProject.addAttachedArtifact' in
[5f048234ff44dbf70fcad9f17834c64866f452e1|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=5f048234ff44dbf70fcad9f17834c64866f452e1].
Is it correct that you want Maven to behave as was done in the first commit?
> Multiple times attaching the same artifact should fail the build
>
>
> Key: MNG-5969
> URL: https://issues.apache.org/jira/browse/MNG-5969
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.3, 3.2.5, 3.4.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> If i take a look at [MNG-5939|MNG-5939] and use the example project and test
> it with the current version of Maven on master
> (f467d9142fa6c928bdae25253350915728fef286) i will get the following:
> {noformat}
> [INFO] --- maven-source-plugin:2.4:jar (attach-sources) @ bar ---
> [INFO] Building jar:
> /Users/kama/Downloads/foo.bar/target/bar-0.0.1-sources.jar
> [INFO]
> [INFO] --- maven-source-plugin:2.4:jar-no-fork (attach-sources) @ bar ---
> [INFO] Building jar:
> /Users/kama/Downloads/foo.bar/target/bar-0.0.1-sources.jar
> [INFO] Replaced artifact foo:bar:java-source:sources:0.0.1.
> [INFO]
> {noformat}
> First the previous behaviour (Maven 3.0.5) was to emit a {{WARNING}} which is
> not the case anymore. At the moment it only creates a simple output:
> {noformat}
> [INFO] Replaced artifact foo:bar:java-source:sources:0.0.1.
> {noformat}
> which is not enough.
> Furthermore I'm the opinion that in this case the build should be broken,
> cause this build is wrongly configured (twice executions of
> maven-source-plugin without changing the classifier it could also be several
> executions of other plugins).
> Maven 3.1.1, 3.2.1, 3.2.2, will ignore it completely without any message nor
> a warning etc.
> Maven 3.2.3, 3.2.5 will produce no warning but will attach the artifacts
> twice times {{-sources}} which would fail a release like this:
> {noformat}
> [INFO] Installing /Users/kama/Downloads/foo.bar/target/bar-0.0.1-sources.jar
> to /Users/kama/.m2/repository/foo/bar/0.0.1/bar-0.0.1-sources.jar
> [INFO] Installing /Users/kama/Downloads/foo.bar/target/bar-0.0.1-sources.jar
> to /Users/kama/.m2/repository/foo/bar/0.0.1/bar-0.0.1-sources.jar
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5969) Multiple times attaching the same artifact should fail the build
[
https://issues.apache.org/jira/browse/MNG-5969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15127161#comment-15127161
]
Christian Schulte commented on MNG-5969:
I agree that this is how Maven should behave and I committed the corresponding
changes in
[020e35816f184c10c3f87f103336fed4516f7af6|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=020e35816f184c10c3f87f103336fed4516f7af6].
I then noticed there are a lot of historic issues regarding the behaviour of
that method and reverted everything to what I think consensus had been reached.
See all the issues I added to the Javadoc of method
'MavenProject.addAttachedArtifact' in
[5f048234ff44dbf70fcad9f17834c64866f452e1|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=5f048234ff44dbf70fcad9f17834c64866f452e1].
Is it correct that you want Maven to behave as was done in the first commit?
> Multiple times attaching the same artifact should fail the build
>
>
> Key: MNG-5969
> URL: https://issues.apache.org/jira/browse/MNG-5969
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.3, 3.2.5, 3.4.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> If i take a look at [MNG-5939|MNG-5939] and use the example project and test
> it with the current version of Maven on master
> (f467d9142fa6c928bdae25253350915728fef286) i will get the following:
> {noformat}
> [INFO] --- maven-source-plugin:2.4:jar (attach-sources) @ bar ---
> [INFO] Building jar:
> /Users/kama/Downloads/foo.bar/target/bar-0.0.1-sources.jar
> [INFO]
> [INFO] --- maven-source-plugin:2.4:jar-no-fork (attach-sources) @ bar ---
> [INFO] Building jar:
> /Users/kama/Downloads/foo.bar/target/bar-0.0.1-sources.jar
> [INFO] Replaced artifact foo:bar:java-source:sources:0.0.1.
> [INFO]
> {noformat}
> First the previous behaviour (Maven 3.0.5) was to emit a {{WARNING}} which is
> not the case anymore. At the moment it only creates a simple output:
> {noformat}
> [INFO] Replaced artifact foo:bar:java-source:sources:0.0.1.
> {noformat}
> which is not enough.
> Furthermore I'm the opinion that in this case the build should be broken,
> cause this build is wrongly configured (twice executions of
> maven-source-plugin without changing the classifier it could also be several
> executions of other plugins).
> Maven 3.1.1, 3.2.1, 3.2.2, will ignore it completely without any message nor
> a warning etc.
> Maven 3.2.3, 3.2.5 will produce no warning but will attach the artifacts
> twice times {{-sources}} which would fail a release like this:
> {noformat}
> [INFO] Installing /Users/kama/Downloads/foo.bar/target/bar-0.0.1-sources.jar
> to /Users/kama/.m2/repository/foo/bar/0.0.1/bar-0.0.1-sources.jar
> [INFO] Installing /Users/kama/Downloads/foo.bar/target/bar-0.0.1-sources.jar
> to /Users/kama/.m2/repository/foo/bar/0.0.1/bar-0.0.1-sources.jar
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1222) ForkClient attempts to consume unrelated lines
[
https://issues.apache.org/jira/browse/SUREFIRE-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15126041#comment-15126041
]
Martin Kouba commented on SUREFIRE-1222:
[~tibor17] I get the same error for 2.19.1. By the way, 2.17 does not look that
old (12-Mar-2014). A lot of projects out there probably don't use the most
recent versions of dependencies.
> ForkClient attempts to consume unrelated lines
> --
>
> Key: SUREFIRE-1222
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1222
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.17
> Environment: Oracle JDK7 (build 1.7.0_79-b15)
> Linux 3.13 x86_64 with default locale cs_CZ
>Reporter: Martin Kouba
>
> This month the [Weld
> SE|https://github.com/weld/core/tree/2.3/environments/se/tests] test suite
> suddenly started to fail on a Linux machine with Oracle JDK7 and the default
> locale {{cs_CZ}}:
> {code}
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of
> range: -1
> at java.lang.String.substring(String.java:1911)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:128)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> A {{java.util.logging.Logger}} is used in the forked process. The exception
> occurs when the following log message is written to the standard output:
> {code}
> I 29, 2016 2:01:43 ODP. org.jboss.arquillian.container.se.server.Main main
> {code}
> We have found out that the timestamp *I 29, 2016 2:01:43* (i.e. 2016-01-29
> 14:01:43) is incorrectly parsed as {{ForkingRunListener.BOOTERCODE_SYSPROPS}}
> operation.
> I think the protocol should be robust enough to avoid similar collisions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MPMD-220) Upgrade to PMD 5.4.1
Mathieu BONIFACE created MPMD-220: - Summary: Upgrade to PMD 5.4.1 Key: MPMD-220 URL: https://issues.apache.org/jira/browse/MPMD-220 Project: Maven PMD Plugin Issue Type: Bug Reporter: Mathieu BONIFACE As 5.4.1 is out and provide some interesting improvements and bugfixes, it would be great for us to upgrade the maven plugin with this new version of PMD. Another important change is pmd > 5.4.0 requires Java >= 1.7.0 (see APi Changes [here|http://sourceforge.net/projects/pmd/files/pmd/5.4.0/]) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (MNG-5760) All `-rf` to automatically resume from the last failure point
[
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivange Larry Ndumbe updated MNG-5760:
-
Comment: was deleted
(was: Is this really a good idea. Say i have a five module project and during
the build there was an error in the third. Say in fixing the problem i decided
to make significant changes to previous modules that already built
successfully. Would this suggested behavior not brake my new build? I mean,
would it not ignore the changes i made to the other modules that had build
successfully and just continue building the module that failed?)
> All `-rf` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Priority: Trivial
>
> Currently when a multi-module build fails the {{mvn}} command line prints the
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be
> very useful if you could type {{mvn -rf}} and have the project name
> inferred from the last failure rather than needing to copy/paste from the
> terminal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5760) All `-rf` to automatically resume from the last failure point
[
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15127720#comment-15127720
]
Ivange Larry Ndumbe commented on MNG-5760:
--
Is this really a good idea. Say i have a five module project and during the
build there was an error in the third. Say in fixing the problem i decided to
make significant changes to previous modules that already built successfully.
Would this suggested behavior not brake my new build? I mean, would it not
ignore the changes i made to the other modules that had build successfully and
just continue building the module that failed?
> All `-rf` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Priority: Trivial
>
> Currently when a multi-module build fails the {{mvn}} command line prints the
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be
> very useful if you could type {{mvn -rf}} and have the project name
> inferred from the last failure rather than needing to copy/paste from the
> terminal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
