[jira] [Created] (DOXIASITETOOLS-177) Use of commons-lang 2 causes failure with JDK 9 b175+
Anthony Vanelverdinghe created DOXIASITETOOLS-177: - Summary: Use of commons-lang 2 causes failure with JDK 9 b175+ Key: DOXIASITETOOLS-177 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-177 Project: Maven Doxia Sitetools Issue Type: Bug Components: Site renderer Affects Versions: 1.7.4 Reporter: Anthony Vanelverdinghe When doing a release of a Maven project, I get the stacktrace below. Since JDK 9 b175, the java.version system property is simply "9". However, Doxia depends on commons-lang 2.4, which assumes java.version has at least 3 characters. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:181) ... 21 more Caused by: java.lang.ExceptionInInitializerError at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.generateDocument(DefaultSiteRenderer.java:732) at org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:268) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:337) at org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:178) at org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:132) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) ... 21 more Caused by: java.lang.StringIndexOutOfBoundsException: begin 0, end 3, length 1 at java.base/java.lang.String.checkBoundsBeginEnd(String.java:3116) at java.base/java.lang.String.substring(String.java:1885) at org.apache.commons.lang.SystemUtils.getJavaVersionAsFloat(SystemUtils.java:1133) at org.apache.commons.lang.SystemUtils.(SystemUtils.java:818) ... 27 more -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6216) ArrayIndexOutOfBoundsException when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070348#comment-16070348 ] Brian Fox commented on MNG-6216: I'm bumping into this on Mac with 3.5.0 and https://github.com/jeremylong/DependencyCheck/blob/master/pom.xml > ArrayIndexOutOfBoundsException when parsing POM > > > Key: MNG-6216 > URL: https://issues.apache.org/jira/browse/MNG-6216 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Marc Savy > Fix For: 3.5.1 > > Attachments: log > > > When building apiman https://github.com/apiman/apiman.git on Maven 3.5.0 the > XML parser seems to have some issues parsing the apiman-test-common module. > If you want to reproduce, you can simply use mvn clean install, no profiles > needed. > Log: https://gist.github.com/msavy/a1b4307fb238a543dfd6af426b42d446 > Also attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-6246) Inconsistent override behaivor with BOM vs dependency
[ https://issues.apache.org/jira/browse/MNG-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay mann updated MNG-6246: -- Description: Consider we have 2 BOM files: bom1 - dependency version 1 bom2 - dependency version 2' When a bom1 is imported into a parent and bom2 is imported into a child of parernt, child correctly overrides the dependency and uses "verision 2". When parent does not import bom1 but explicitly states "dependency 1" in the section, and child imports bom2, "version 1" of dependency is used (bom2 in child does not override the dependency) This seems like inconsistent behavior as documentation explains that a BOM basically imports the section of the bom into the current pom. If this is expected behavior it should be documented as we recently moved all our dependencyManagement section into a BOM for organizational reasons and it did not work as expected. Attached is a sample, to test simply extract and run: mvn install -f bom1/pom.xml mvn install -f bom2/pom.xml mvn dependency:tree -f project/child/pom.xml mvn dependency:tree -f project2/child/pom.xml project uses bom in parent and child and is overridden correctly. project2 parent uses dependency instead of bom, child uses bom but dependency is NOT overridden. was: Consider we have 2 BOM files: bom1 - dependency version 1 bom2 - dependency version 2' When a bom1 is imported into a parent and bom2 is imported into a child of parernt, child correctly overrides the dependency and uses "verision 2". When parent does not import bom1 but explicitly states "dependency 1" in the section, and child imports bom2, "version 1" of dependency is used (bom2 in child does not override the dependency) This seems like inconsistent behavior as documentation explains that a BOM basically imports the section of the bom into the pom current pom. If this is expected behavior it should be documented as we recently moved all our dependencyManagement section into a BOM for organizational reasons and it did not work as expected. Attached is a sample, to test simply extract and run: mvn install -f bom1/pom.xml mvn install -f bom2/pom.xml mvn dependency:tree -f project/child/pom.xml mvn dependency:tree -f project2/child/pom.xml project uses bom in parent and child and is overridden correctly. project2 parent uses dependency instead of bom, child uses bom but dependency is NOT overridden. > Inconsistent override behaivor with BOM vs dependency > - > > Key: MNG-6246 > URL: https://issues.apache.org/jira/browse/MNG-6246 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.5.0 > Environment: osx jdk 1.8 >Reporter: Jay mann > Attachments: mvn-bug.tar.gz > > > Consider we have 2 BOM files: > bom1 - dependency version 1 > bom2 - dependency version 2' > When a bom1 is imported into a parent and bom2 is imported into a child of > parernt, child correctly overrides the dependency and uses "verision 2". > When parent does not import bom1 but explicitly states "dependency 1" in the > section, and child imports bom2, "version 1" of > dependency is used (bom2 in child does not override the dependency) > This seems like inconsistent behavior as documentation explains that a BOM > basically imports the section of the bom into the > current pom. > If this is expected behavior it should be documented as we recently moved all > our dependencyManagement section into a BOM for organizational reasons and it > did not work as expected. > Attached is a sample, to test simply extract and run: > mvn install -f bom1/pom.xml > mvn install -f bom2/pom.xml > mvn dependency:tree -f project/child/pom.xml > mvn dependency:tree -f project2/child/pom.xml > project uses bom in parent and child and is overridden correctly. > project2 parent uses dependency instead of bom, child uses bom but dependency > is NOT overridden. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-875) testng-results contains only last suite execute in forkmode = always
[ https://issues.apache.org/jira/browse/SUREFIRE-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070064#comment-16070064 ] Elias Balasis commented on SUREFIRE-875: I could solve the problem only by explicitly moving the testng-results.xml file as part of a custom TestNG listener. This is not the most elegant way though. Any thoughts? > testng-results contains only last suite execute in forkmode = always > > > Key: SUREFIRE-875 > URL: https://issues.apache.org/jira/browse/SUREFIRE-875 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 2.12 > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) > Java version: 1.6.0_30, vendor: Sun Microsystems Inc. > OS name: "linux", version: "3.0.0-20-generic", arch: "amd64", family: "unix" >Reporter: Michał Kalisz > Attachments: misiu.test-0.0.1-SNAPSHOT-test-sources.jar, pom.xml > > > Every fork creates new testng-results.xml by replacing previous one. > If there are two tests class - to suite will be created and only last one > will be visible in testng-results.xml. > In attached project: > Two test classes: > SimpleIT, CopyOfCopyOfSimpleIT > running: mvn verify > Generates two sites: > Running pl.misiu.CopyOfCopyOfSimpleIT > Configuring TestNG with: > org.apache.maven.surefire.testng.conf.TestNGMapConfigurator@771c8a71 > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.362 sec > Running pl.misiu.SimpleIT > Configuring TestNG with: > org.apache.maven.surefire.testng.conf.TestNGMapConfigurator@72c53dce > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.326 sec > In target/failsafe-reports/testng-results.xml > there is only one test SimpleIT (the last execute site) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MNG-6246) Inconsistent override behaivor with BOM vs dependency
Jay mann created MNG-6246: - Summary: Inconsistent override behaivor with BOM vs dependency Key: MNG-6246 URL: https://issues.apache.org/jira/browse/MNG-6246 Project: Maven Issue Type: Bug Components: Dependencies Affects Versions: 3.5.0 Environment: osx jdk 1.8 Reporter: Jay mann Attachments: mvn-bug.tar.gz Consider we have 2 BOM files: bom1 - dependency version 1 bom2 - dependency version 2' When a bom1 is imported into a parent and bom2 is imported into a child of parernt, child correctly overrides the dependency and uses "verision 2". When parent does not import bom1 but explicitly states "dependency 1" in the section, and child imports bom2, "version 1" of dependency is used (bom2 in child does not override the dependency) This seems like inconsistent behavior as documentation explains that a BOM basically imports the section of the bom into the pom current pom. If this is expected behavior it should be documented as we recently moved all our dependencyManagement section into a BOM for organizational reasons and it did not work as expected. Attached is a sample, to test simply extract and run: mvn install -f bom1/pom.xml mvn install -f bom2/pom.xml mvn dependency:tree -f project/child/pom.xml mvn dependency:tree -f project2/child/pom.xml project uses bom in parent and child and is overridden correctly. project2 parent uses dependency instead of bom, child uses bom but dependency is NOT overridden. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WAGON-487) Saved password with french accent breaks deployment
[
https://issues.apache.org/jira/browse/WAGON-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069954#comment-16069954
]
Michael Osipov commented on WAGON-487:
--
That's a common HTTP header problem. The spec did not define any encoding or
implied ISO-8859-1. Stick to ASCII, this will always do.
> Saved password with french accent breaks deployment
> ---
>
> Key: WAGON-487
> URL: https://issues.apache.org/jira/browse/WAGON-487
> Project: Maven Wagon
> Issue Type: New Feature
> Components: wagon-http
>Affects Versions: 2.12
>Reporter: Dominique Jean-Prost
>Priority: Critical
>
> I cannot deploy any artifact to my sonatype nexus instance when using a
> pasword with french accetn, like 'é'.
> This instance needs authentication to deploy.
> My test :
> # Check authentication against nexus directly with a password containing
> accent : OK
> # Check deploy with clear password in {{settings.xml}} with no accent : OK
> # Check deploy with encrypted password in {{settings.xml}} with no accent : OK
> # Check deploy with clear password in {{settings.xml}} with accent : KO
> # Check deploy with encrypted password in {{settings.xml}} with accent : KO
> After many minutes of debugging, I managed to verify that my password is
> correctly "read" in the settings {{org.apache.maven.settings.Server}} : it
> has nothing to do with {{settings.xml}} XML encoding.
> When finally wagon enters the game, the http header with authentication basic
> contains a '? ' instead of my 'é'. I managed to narrow the problem to
> {{org.apache.maven.wagon.providers.http.httpclient.impl.auth.BasicScheme}}
> which I think is the cuplrit by not dealing correctly with charset encoding
> in the {{authenticate}} method.
> I came to the end of what I can do for the moment, appart of changing my
> password to remove the accent.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WAGON-488) upgrade webdav wagon to a more recent httpclient version
[ https://issues.apache.org/jira/browse/WAGON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069704#comment-16069704 ] Hudson commented on WAGON-488: -- SUCCESS: Integrated in Jenkins build maven-wagon #1347 (See [https://builds.apache.org/job/maven-wagon/1347/]) [WAGON-488] ensure httpclient with correct GA is used. (rfscholte: [http://git-wip-us.apache.org/repos/asf/?p=maven-wagon.git=commit=e485f03e6e00dcbb12695236d9fb3415dc81f2be]) * (edit) wagon-providers/wagon-webdav-jackrabbit/pom.xml > upgrade webdav wagon to a more recent httpclient version > > > Key: WAGON-488 > URL: https://issues.apache.org/jira/browse/WAGON-488 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-webdav >Reporter: Olivier Lamy (*$^¨%`£) >Assignee: Olivier Lamy (*$^¨%`£) > Fix For: 2.13 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WAGON-487) Saved password with french accent breaks deployment
[
https://issues.apache.org/jira/browse/WAGON-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069619#comment-16069619
]
Dominique Jean-Prost commented on WAGON-487:
thank you [~michael-o], I will give a try the patch as soon as possible.
Anyhow, I find a bit weird that the protocol used to transport password to
nexus is such that you can't choose your password as you want. But it's not a
maven problem.
> Saved password with french accent breaks deployment
> ---
>
> Key: WAGON-487
> URL: https://issues.apache.org/jira/browse/WAGON-487
> Project: Maven Wagon
> Issue Type: New Feature
> Components: wagon-http
>Affects Versions: 2.12
>Reporter: Dominique Jean-Prost
>Priority: Critical
>
> I cannot deploy any artifact to my sonatype nexus instance when using a
> pasword with french accetn, like 'é'.
> This instance needs authentication to deploy.
> My test :
> # Check authentication against nexus directly with a password containing
> accent : OK
> # Check deploy with clear password in {{settings.xml}} with no accent : OK
> # Check deploy with encrypted password in {{settings.xml}} with no accent : OK
> # Check deploy with clear password in {{settings.xml}} with accent : KO
> # Check deploy with encrypted password in {{settings.xml}} with accent : KO
> After many minutes of debugging, I managed to verify that my password is
> correctly "read" in the settings {{org.apache.maven.settings.Server}} : it
> has nothing to do with {{settings.xml}} XML encoding.
> When finally wagon enters the game, the http header with authentication basic
> contains a '? ' instead of my 'é'. I managed to narrow the problem to
> {{org.apache.maven.wagon.providers.http.httpclient.impl.auth.BasicScheme}}
> which I think is the cuplrit by not dealing correctly with charset encoding
> in the {{authenticate}} method.
> I came to the end of what I can do for the moment, appart of changing my
> password to remove the accent.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (WAGON-488) upgrade webdav wagon to a more recent httpclient version
Olivier Lamy (*$^¨%`£) created WAGON-488: Summary: upgrade webdav wagon to a more recent httpclient version Key: WAGON-488 URL: https://issues.apache.org/jira/browse/WAGON-488 Project: Maven Wagon Issue Type: Improvement Components: wagon-webdav Reporter: Olivier Lamy (*$^¨%`£) Assignee: Olivier Lamy (*$^¨%`£) Fix For: 2.13 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
