Re: What do if project.build.sourceEncoding is not provided?
Isn't this handled by the content-type headers normally ? Kristian 2014-11-13 23:15 GMT+01:00 Michael Osipov : > Hi folks, > > I'd like to know if we have a general concensus on this: > > I am investigating MPIR-242 and figured out the cause. The input stream is > obtained from the HTTP URL and no encoding is given, so ISO-8859-1 is > provided as default (yuck!). While I know that some reporting related > modules have default values for input/output encoding, this contradicts our > general approach to use platform encoding when project.build.sourceEncoding > is not given. > > In that special case, the behavior would be consistent if changed. Setting > project.build.sourceEncoding to UTF-8 would solve the problem but is just a > workaround. HTML resources carry their encoding with them but the > ProjectInfoReportUtils treats everything as input streams (not helpful with > XML/HTML). I would really like to avoid peeking with a pushback input > stream. > > How is your opinion on this? > > I have two solutions in mind for the issue above: > > 1. Easy: remove ISO-8859-1, assume platform encoding if > project.build.sourceEncoding is not provided. > 2. Complex: use an HTML parser (JSoup is awesome and license-compatible [1]) > to get correctly encoded content. > But how do you know that this URL really points to an HTML file and not a > license.txt inspect content type? > > [1] http://apache.org/legal/resolved.html#category-a > > Michael > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven shared build failing ?
Yeah. But in this case the project itself builds fine with JDK1.5, and the problem appears to be within jenkins itself. Or maybe jenkins stopped supporting 1.5 like we should do too :) Kristian 2014-11-13 22:02 GMT+01:00 Greg Trasuk : > > That error usually means that you’re running under an older JVM. One of the > jar files has a class version number that is higher than the running JVM > knows about. e.g. compiled under JDK8, running under JDK6 or something like > that. > > If you have access to the Jenkins build configuration, have a look and see if > there’s an option for what JVM to use for the build. > > Cheers, > > Greg Trasuk > > On Nov 13, 2014, at 3:45 PM, Kristian Rosenvold > wrote: > >> Life with jenkins is interesting as always; this one is new to me >> https://builds.apache.org/job/maven-shared/ >> >> Kristian >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
What do if project.build.sourceEncoding is not provided?
Hi folks, I'd like to know if we have a general concensus on this: I am investigating MPIR-242 and figured out the cause. The input stream is obtained from the HTTP URL and no encoding is given, so ISO-8859-1 is provided as default (yuck!). While I know that some reporting related modules have default values for input/output encoding, this contradicts our general approach to use platform encoding when project.build.sourceEncoding is not given. In that special case, the behavior would be consistent if changed. Setting project.build.sourceEncoding to UTF-8 would solve the problem but is just a workaround. HTML resources carry their encoding with them but the ProjectInfoReportUtils treats everything as input streams (not helpful with XML/HTML). I would really like to avoid peeking with a pushback input stream. How is your opinion on this? I have two solutions in mind for the issue above: 1. Easy: remove ISO-8859-1, assume platform encoding if project.build.sourceEncoding is not provided. 2. Complex: use an HTML parser (JSoup is awesome and license-compatible [1]) to get correctly encoded content. But how do you know that this URL really points to an HTML file and not a license.txt inspect content type? [1] http://apache.org/legal/resolved.html#category-a Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MPMD-192: Just skip the IT with Maven 2.2.1
Hi Mirko, sounds good to me.. Go for it... On 11/13/14 10:01 PM, Mirko Friedenhagen wrote: Hello everybody. I am really out of ideas here. MPMD-89 is a test to ensure that test classes whose name *does not* end on Test are recognized as tests by inspecting their inheritage. I do not think that this is a a major use case. Succeeds with Maven >= 3, but fails with Maven 2.2.1. I have spent 6 hours, downloaded PMD itself and ran it on the CLI. PMD 5.2.1 did not detect the errors from the CLI either. PMD 5.1.2 did, so users of the maven plugin are even better off as long as the use Maven >= 3. To get maven-pmd-plugin-3.3 out of the door I would like to skip this test for Maven 2.2.1 by means of invoker.properties. I would guess anyone still using Maven 2.2.1 does not need the JDK 8 ability of PMD 5.2.1 and should either stay with maven-pmd-plugin-3.2 or adapt her test cases. I would reference MPMD-192 in MPMD-89. What do you think? Kind Regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MPMD-192: Just skip the IT with Maven 2.2.1
Am 2014-11-13 um 22:01 schrieb Mirko Friedenhagen: Hello everybody. I am really out of ideas here. MPMD-89 is a test to ensure that test classes whose name *does not* end on Test are recognized as tests by inspecting their inheritage. I do not think that this is a a major use case. Succeeds with Maven >= 3, but fails with Maven 2.2.1. I have spent 6 hours, downloaded PMD itself and ran it on the CLI. PMD 5.2.1 did not detect the errors from the CLI either. PMD 5.1.2 did, so users of the maven plugin are even better off as long as the use Maven >= 3. To get maven-pmd-plugin-3.3 out of the door I would like to skip this test for Maven 2.2.1 by means of invoker.properties. I would guess anyone still using Maven 2.2.1 does not need the JDK 8 ability of PMD 5.2.1 and should either stay with maven-pmd-plugin-3.2 or adapt her test cases. I would reference MPMD-192 in MPMD-89. What do you think? +1. Especially "I would guess anyone still using Maven 2.2.1 does not need the JDK 8..." Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven shared build failing ?
That error usually means that you’re running under an older JVM. One of the jar files has a class version number that is higher than the running JVM knows about. e.g. compiled under JDK8, running under JDK6 or something like that. If you have access to the Jenkins build configuration, have a look and see if there’s an option for what JVM to use for the build. Cheers, Greg Trasuk On Nov 13, 2014, at 3:45 PM, Kristian Rosenvold wrote: > Life with jenkins is interesting as always; this one is new to me > https://builds.apache.org/job/maven-shared/ > > Kristian > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
MPMD-192: Just skip the IT with Maven 2.2.1
Hello everybody. I am really out of ideas here. MPMD-89 is a test to ensure that test classes whose name *does not* end on Test are recognized as tests by inspecting their inheritage. I do not think that this is a a major use case. Succeeds with Maven >= 3, but fails with Maven 2.2.1. I have spent 6 hours, downloaded PMD itself and ran it on the CLI. PMD 5.2.1 did not detect the errors from the CLI either. PMD 5.1.2 did, so users of the maven plugin are even better off as long as the use Maven >= 3. To get maven-pmd-plugin-3.3 out of the door I would like to skip this test for Maven 2.2.1 by means of invoker.properties. I would guess anyone still using Maven 2.2.1 does not need the JDK 8 ability of PMD 5.2.1 and should either stay with maven-pmd-plugin-3.2 or adapt her test cases. I would reference MPMD-192 in MPMD-89. What do you think? Regards Mirko http://jira.codehaus.org/browse/MPMD-192 http://jira.codehaus.org/browse/MPMD-89 -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Maven shared build failing ?
Life with jenkins is interesting as always; this one is new to me https://builds.apache.org/job/maven-shared/ Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT][VOTE] Release maven-repository-builder 1.0
Hi, The vote has passed with the following result: +1 (binding): Karl, Hervé, Kristian I will promote the artifacts to the central repo and try not to further botch the site. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Toolchains Plugin version 1.1
Hi, check sha1, Ok. Checked with Maven 2.2.1, 3.0.5, 3.1.1, 3.2.1, 3.2.2, 3.2.3 no issues found. So +1 from me. Kind regards Karl Heinz Marbaise On 11/11/14 11:26 PM, Hervé BOUTEMY wrote: Hi, We solved 8 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12063&styleName=Html&version=15920 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=12063&status=1 Staging repo: https://repository.apache.org/content/repositories/maven-1096/ http://repository.apache.org/content/repositories/maven-1096/org/apache/maven/plugins/maven-toolchains-plugin/1.1/maven-toolchains-plugin-1.1-source-release.zip Source release checksum(s): maven-toolchains-plugin-1.1-source-release.zip sha1: 823bcd6be51eebe063c0771dc9c20124028a0713 Staging site: http://maven.apache.org/plugins-archives/maven-toolchains-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Toolchains Plugin version 1.1
+1 Op Tue, 11 Nov 2014 23:26:45 +0100 schreef Hervé BOUTEMY : Hi, We solved 8 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12063&styleName=Html&version=15920 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=12063&status=1 Staging repo: https://repository.apache.org/content/repositories/maven-1096/ http://repository.apache.org/content/repositories/maven-1096/org/apache/maven/plugins/maven-toolchains-plugin/1.1/maven-toolchains-plugin-1.1-source-release.zip Source release checksum(s): maven-toolchains-plugin-1.1-source-release.zip sha1: 823bcd6be51eebe063c0771dc9c20124028a0713 Staging site: http://maven.apache.org/plugins-archives/maven-toolchains-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release ASF Parent POM 16, Maven Parent POM 26, Maven Plugins Parent POM 27
Hi, We solved 1/4/1 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250&version=12328739 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250&version=12328928 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250&version=12328929 Staging repos: http://repository.apache.org/content/repositories/orgapacheapache-1003/org/apache/apache/16/apache-16-source-release.zip http://repository.apache.org/content/repositories/maven-1098/org/apache/maven/maven-parent/26/maven-parent-26-source-release.zip http://repository.apache.org/content/repositories/maven-1099/org/apache/maven/plugins/maven-plugins/27/maven-plugins-27-source-release.zip Source release checksum(s): apache-16-source-release.zip sha1: 8eee9333962241fa93c024368e1dc3f05b9baa9a maven-parent-26-source-release.zip sha1: 02d4211edeb41c3e44faa6b82228c2c60fd8338b maven-plugins-27-source-release.zip sha1: 9c3db01177310eb45826f6fc742e613f50470e79 Staging site: http://maven.apache.org/pom-archives/asf-LATEST/ http://maven.apache.org/pom-archives/maven-LATEST/ http://maven.apache.org/pom-archives/maven-plugins-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release maven-repository-builder 1.0
+1 from me too :) Thanks for publishing the Site properly, Hervé ! Kristian 2014-11-12 0:12 GMT+01:00 Hervé BOUTEMY : > +1 > > I published the site, which was apparently built without -Preporting > > A better index page would be useful, or at least better description > > Regards, > > Hervé > > Le lundi 10 novembre 2014 21:39:47 Kristian Rosenvold a écrit : >> We solved 4 issues, including an enourmously irritating stacktrace >> this component has been logging with -X. >> >> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761&version=171 >> 40 >> >> There are no issues left in JIRA. >> >> http://repository.apache.org/content/repositories/maven-1095/org/apache/mave >> n/shared/maven-repository-builder/1.0/maven-repository-builder-1.0-source-re >> lease.zip source checksum: 5b3e49626aa960d132286b51d55d4ec3d9317383 (sha1) >> >> Staging site: >> http://maven.apache.org/shared-archives/maven-repository-builder-LATEST/ >> >> Staging repository: >> http://repository.apache.org/content/repositories/maven-1095/ >> >> Guide to testing staged releases: >> http://maven.apache.org/guides/development/guide-testing-releases.html >> >> Vote open for 72 hours. >> >> [ ] +1 >> [ ] +0 >> [ ] -1 >> >> Kristian >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Help needed with MPIR-279
Am 2014-11-13 um 12:07 schrieb Stuart McCulloch: On Thursday, 13 November 2014 at 09:43, Michael Osipov wrote: Am 2014-11-13 um 01:40 schrieb Hervé BOUTEMY: Sorry, I tried but I'm stuck with maven-plugin-testing-harness too... I have committed another changed where I have missed to assigned the localRepository. Though it gives me now: testReport(org.apache.maven.report.projectinfo.ModulesReportTest) Time elapsed: 0.328 sec <<< ERROR! java.lang.IllegalStateException: Unable to read local module POM Both subproject1/pom.xml and subproject2/pom.xml declare the following as their parent: org.apache.maven.plugin.projectinfo.tests dependency-convergence 1.0-SNAPSHOT While this artifact is located in the parent directory, it’s in a file called dependency-convergence-plugin-config.xml so it won't be discovered by the normal parent rule of looking for ../pom.xml. Neither is it installed in the local repository (test or otherwise) which is why the error occurs about the missing dependency-convergence project. I verified this by adding the following line to the parent config in subproject1/pom.xml and subproject2/pom.xml: ../dependency-convergence-plugin-config.xml I also had to change the packaging of dependency-convergence-plugin-config.xml from ‘jar’ to ‘pom’ otherwise it would complain about the parent having the wrong packaging. Once that was done the tests all passed. I’m not familiar with these tests, so I’m not sure whether these subprojects are really meant to have the dependency-convergence artifact as their parent? (if not then a simpler fix would be to create a new parent pom at the expected location, and perhaps move it and the subproject modules below a ’moduletest’ folder to make the hierarchy a bit cleaner). Anyway, hope this helps... Absolutely magnificent. This did it. The POMs were incorrect in the first place but this issue wasn't simply triggered. I have committed to the branch and will proceed with the merge into trunk.. Thank you very much! Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Help needed with MPIR-279
On Thursday, 13 November 2014 at 09:43, Michael Osipov wrote: > Am 2014-11-13 um 01:40 schrieb Hervé BOUTEMY: > > Sorry, I tried but I'm stuck with maven-plugin-testing-harness too... > > > I have committed another changed where I have missed to assigned the > localRepository. Though it gives me now: > > testReport(org.apache.maven.report.projectinfo.ModulesReportTest) Time > elapsed: 0.328 sec <<< ERROR! > java.lang.IllegalStateException: Unable to read local module POM > > Both subproject1/pom.xml and subproject2/pom.xml declare the following as their parent: org.apache.maven.plugin.projectinfo.tests dependency-convergence 1.0-SNAPSHOT While this artifact is located in the parent directory, it’s in a file called dependency-convergence-plugin-config.xml so it won't be discovered by the normal parent rule of looking for ../pom.xml. Neither is it installed in the local repository (test or otherwise) which is why the error occurs about the missing dependency-convergence project. I verified this by adding the following line to the parent config in subproject1/pom.xml and subproject2/pom.xml: ../dependency-convergence-plugin-config.xml I also had to change the packaging of dependency-convergence-plugin-config.xml from ‘jar’ to ‘pom’ otherwise it would complain about the parent having the wrong packaging. Once that was done the tests all passed. I’m not familiar with these tests, so I’m not sure whether these subprojects are really meant to have the dependency-convergence artifact as their parent? (if not then a simpler fix would be to create a new parent pom at the expected location, and perhaps move it and the subproject modules below a ’moduletest’ folder to make the hierarchy a bit cleaner). Anyway, hope this helps... > > Thanks for your help. > > Maybe someone else has a clue. > > Michael > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > (mailto:dev-unsubscr...@maven.apache.org) > For additional commands, e-mail: dev-h...@maven.apache.org > (mailto:dev-h...@maven.apache.org) > >
Re: Help needed with MPIR-279
Am 2014-11-13 um 01:40 schrieb Hervé BOUTEMY: Sorry, I tried but I'm stuck with maven-plugin-testing-harness too... I have committed another changed where I have missed to assigned the localRepository. Though it gives me now: testReport(org.apache.maven.report.projectinfo.ModulesReportTest) Time elapsed: 0.328 sec <<< ERROR! java.lang.IllegalStateException: Unable to read local module POM Thanks for your help. Maybe someone else has a clue. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
