[ANN] Maven Skins Parent 8 Released
The Apache Maven team is pleased to announce the release of the Maven Skins Parent version 8 http://maven.apache.org/pom/skins/ You should specify the version in your project's configuration: plugin groupIdorg.apache.maven.skins/groupId artifactIdmaven-skins/artifactId version8/version /plugin Enjoy, -The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Maven Fluido Skin version 1.3.1 released
The Apache Maven team is pleased to announce the release of the Maven Fluido Skin, version 1.3.1 http://maven.apache.org/skins/maven-fluido-skin/ You should specify the version in your project's site configuration: skin groupIdorg.apache.maven.skins/groupId artifactIdmaven-fluido-skin/artifactId version1.3.1/version /skin Release Notes - Maven Fluido Skin - Version 1.3.1 ** Bug * [MSKINS-67] - upgrade to bootstrap 2.2.0 * [MSKINS-68] - clean for ?xml version=1.0 encoding=UTF-8? in footer * [MSKINS-70] - external.png is used in css but not present in code base * [MSKINS-78] - Do not generate line with doxia timestamp * [MSKINS-79] - pull-right class compresses listitem * [MSKINS-85] - Unify breadcrumb chevron of Fluido with other skins ** Improvement * [MSKINS-77] - Add Github ribbon for maven-skins to fluido site * [MSKINS-80] - Upgrade to Bootstrap 2.3 breaks design ** New Feature * [MSKINS-72] - Add copyright notice position option * [MSKINS-75] - Add Piwik web analytics tracking code integration to Fluido skin * [MSKINS-76] - Add Flattr button integration to Fluido skin ** Task * [MSKINS-73] - Upgrade Bootstrap to Version 2.3.0 * [MSKINS-74] - Upgrade jQuery to v1.9.1 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Release Maven JXR version 2.4
Hi, The vote has passed with the following result: +1 (binding): Olivier Lamy, Hervé Boutemy, Kristian Rosenvold +1 (non-binding): Maarten Storm I will promote the artifacts to the central repo. PMCs please promote the source release ZIP file and add this release the board report. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Apache Maven JXR 2.4 released
The Apache Maven team is pleased to announce the release of the Apache Maven JXR, version 2.4 This module generates browsable HTML pages from Java source code. http://maven.apache.org/jxr/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jxr-plugin/artifactId version2.4/version /plugin Release Notes - Maven JXR - Version 2.4 ** Bug * [JXR-63] - Bottom line in jxr report does not correspond to Javadoc style * [JXR-85] - JXR generates files with inconsistent line ending style * [JXR-93] - aggregate goal creates blank top-level report * [JXR-96] - [PATCH] JXR Comment handling has several shortcomings * [JXR-103] - All DTD XHTML 1.0 Transitional references are incorrect ** Improvement * [JXR-61] - Include bottom text in all pages * [JXR-87] - Change line number anchor name pattern * [JXR-99] - Improve linguistic style of bottom * [JXR-104] - Remove NOTICE footer/bottom altogether because no other writes this one too * [JXR-106] - Remove Maven 1.x from docs ** Task * [JXR-94] - use the maven-plugins pom as the parent of the maven-jxr-plugin Enjoy, -The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: My promotion on Apache JIRA
Am 2013-12-22 01:58, schrieb Olivier Lamy: done. Merci! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 3.2.0 Bug Scrub
Am 2014-01-07 16:25, schrieb Stephen Connolly: OK we are now at 38 open issues anyone else feel like scrubbing some more? I'd like to add another issue to 3.2: https://jira.codehaus.org/browse/MNG-5176 Print build times in an ISO 8601-style manner It adds readability to the time output. Mike - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 3.2.0 Bug Scrub
Am 2014-01-07 22:38, schrieb Stephen Connolly: Add it if you promise to implement it, otherwise put it against 3.2.x for the patch releases. That is not going to be a problem because I have a patch and can commit right away. On Tuesday, 7 January 2014, Michael Osipov wrote: Am 2014-01-07 16:25, schrieb Stephen Connolly: OK we are now at 38 open issues anyone else feel like scrubbing some more? I'd like to add another issue to 3.2: https://jira.codehaus.org/browse/MNG-5176 Print build times in an ISO 8601-style manner It adds readability to the time output. Mike - 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: JIRA Cleanup
Am 2014-01-20 18:32, schrieb Stephen Connolly: If we are going wholesale dumping issues (and I am not against that), I have a more radical suggestion... let's just move core to the ASF JIRA... with next to no issues needing migration it would be easy ;-) +1 I head this idea in mind for several months. Make a clean cut. Read only. Period. New issues in ASF JIRA only. If someone has found an issue which is already in Codehaus JIRA that should be migrated of course. On 20 January 2014 17:23, Jason van Zyl ja...@takari.io wrote: Really, it's more about dropping a nuclear bomb on JIRA. While trying to sift through it this weekend it's clear to me it's less than ideal in there. There are issues that are 12 years old and while there might be some useful information in there that we hand select, I think anything that is older than 5 years we should just close as incomplete because with the great deal of change that's happened with 3.x most of it isn't relevant and if it is, and someone cares that much then it can be reopened with a stand-alone working example of the problem. Now, as to the requirements for a stand-alone working example I think we should enforce this because personally I'm not going to check out someone's project, figure out how to interpret it in relation to the actual problem in Maven and then create a project I can turn into an IT. I'm just not going to do it generally. There might be exceptions but I don't want to read a textual examples or try to figure out snippets of a production project that can't be shared. In m2e we require a working example project to even look at a problem and if the issue sits there for a year with a working sample project we close it. Having an issue tracking system with 700 open issues is useless, so I would like to do a mass purge. It shouldn't really get beyond 50 open issues or it's just impossible to manage effectively. Not sure what anyone else thinks but our JIRA situation is just not effective. I'm thinking anything over 5 years old that isn't assigned to a core developer we just close as incomplete and then see what we're left with. If anyone complains then we point them at doco (I'll write it) about creating a stand-alone project because otherwise it become impossible. I spent 8 hours over the weekend looking at issues trying to interpret what someone was trying to say and I don't want to guess. If the user cares enough they can make an example project. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: parent poms release
Am 2014-02-02 11:42, schrieb Hervé BOUTEMY: good idea: at least, it give good hints on what updates are available so here is it: $ mvn versions:display-plugin-updates [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building The Apache Software Foundation 14-SNAPSHOT [INFO] [INFO] [INFO] --- versions-maven-plugin:2.1:display-plugin-updates (default-cli) @ apache --- [INFO] [INFO] The following plugin updates are available: [INFO] maven-compiler-plugin .. 2.5.1 - 3.1 [INFO] maven-deploy-plugin 2.8 - 2.8.1 [INFO] maven-enforcer-plugin .. 1.2 - 1.3.1 [INFO] maven-failsafe-plugin 2.14.1 - 2.16 [INFO] maven-install-plugin ... 2.5 - 2.5.1 [INFO] maven-remote-resources-plugin 1.4 - 1.5 [INFO] maven-scm-plugin ... 1.8.1 - 1.9 [INFO] maven-surefire-plugin 2.14.1 - 2.16 [INFO] org.codehaus.mojo:clirr-maven-plugin ... 2.5 - 2.6.1 [INFO] [INFO] All plugins have a version specified. [INFO] [INFO] Project defines minimum Maven version as: 2.2.1 [INFO] Plugins require minimum Maven version of: 2.2.1 [INFO] [INFO] No plugins require a newer version of Maven than specified by the pom. [INFO] [INFO] Require Maven 3.0 to use the following plugin updates: [INFO] maven-scm-publish-plugin 1.0 [INFO] Looks good. Do we want to raise base line to 2.2.1 and enforce it with m-enforcer-p? Probably this done already. As a side note, the versions plugin does not check the reporting plugins for updates. This has to happen manually. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: parent poms release
Am 2014-02-03 22:59, schrieb Hervé BOUTEMY: I just updated some plugins now, we have: $ mvn versions:display-plugin-updates [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building The Apache Software Foundation 14-SNAPSHOT [INFO] [INFO] [INFO] --- versions-maven-plugin:2.1:display-plugin-updates (default-cli) @ apache --- [INFO] [INFO] The following plugin updates are available: [INFO] maven-compiler-plugin .. 2.5.1 - 3.1 [INFO] maven-enforcer-plugin .. 1.2 - 1.3.1 [INFO] maven-failsafe-plugin 2.14.1 - 2.16 [INFO] maven-remote-resources-plugin 1.4 - 1.5 [INFO] maven-surefire-plugin 2.14.1 - 2.16 [INFO] org.codehaus.mojo:clirr-maven-plugin ... 2.5 - 2.6.1 [INFO] [INFO] All plugins have a version specified. [INFO] [INFO] Project defines minimum Maven version as: 2.2.1 [INFO] Plugins require minimum Maven version of: 2.2.1 [INFO] [INFO] No plugins require a newer version of Maven than specified by the pom. [INFO] [INFO] Require Maven 3.0 to use the following plugin updates: [INFO] maven-scm-publish-plugin 1.0 [INFO] [INFO] [INFO] BUILD SUCCESS [INFO] Any objection to upgrade the last ones before I start the release tomorrow? Please update reporting plugins too. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 2.x is end of life
+1 with a side remark. For those, who still rely on Maven 2 one should first annouce an EOL roadmap like this: 1. Make the announcement 2. Release 2.2.2 (only one open ticket in JIRA which can me dismissed) say 4 weeks later and announce that as the last version of 2.x 3. Encourage to switch to 3.1.x/3.2.x Take Apache Tomcat as an example, they announced 5.5.x as EOL with several months in advance. I think, it's unfair to announce something as EOL straight away. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Towards faster releases
Am 2014-02-18 16:26, schrieb Stephen Connolly: I have set up a chain of build jobs in Jenkins. The root of the chain is https://builds.apache.org/job/maven-3.2-release-status/ The certificate has expired today, hopefully infra will fix this ASAP. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: A release of maven-checkstyle-plugin is coming shortly
Am 2014-02-22 00:58, schrieb Dennis Lundberg: Hi, If anyone wants to add something to the next release of the Checkstyle plugin, now would be a good time to do it, as I intend to make a release next week. If you need more time to squeeze something in, just let me know. Thanks for that notification. I have fixed several issues recently and have tested the code again -- it seems I have missed some issues which I will address shortly. Some are translation-related and some xref linking. I will update as soon as the issues have been addressed. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Branch the parent pom hierarchy for Java 1.6 + Maven 3
Am 2014-02-23 19:06, schrieb Benson Margulies: I propose to make releases of our parent stack that are suitable for components and plugins that are making the leap to Java 1.6 and Maven 3 as their base requirements. What do people think is the right approach in terms of what stays on trunk and what goes on a branch, and whether to do anything distinctive to the version numbers? Finally, someone's stepping up for such a good change. Though, I think some important stuff needs to be considered first: 1. Announce 2.x EOL and give people at least 3 months to switch. 2. If you align plugins with a 3.0 baseline, I would bump at least a minor version, maybe even a major one. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: parent poms release
Am 2014-02-01 11:20, schrieb Hervé BOUTEMY: after m-scm-publish-p 1.0 is released, I intend to release ASF parent pom Then every Maven parent poms please have a look at these if you want to be sure your favorite plugin version + configuration, or you position, is correct Hervé, did you check Maven Parent already? Some plugins are worth upgrading: D:\workspace-4.2\maven-parentmvn versions:display-plugin-updates [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building Apache Maven 24-SNAPSHOT [INFO] [INFO] [INFO] --- versions-maven-plugin:2.1:display-plugin-updates (default-cli) @ maven-parent --- [INFO] [INFO] The following plugin updates are available: [INFO] maven-checkstyle-plugin 2.10 - 2.11 [INFO] maven-jxr-plugin . 2.3 - 2.4 [INFO] maven-release-plugin . 2.4.1 - 2.4.2 [INFO] maven-surefire-report-plugin . 2.14.1 - 2.16 [INFO] org.codehaus.mojo:findbugs-maven-plugin .. 2.5.2 - 2.5.3 [INFO] [WARNING] The following plugins do not have their version specified: [WARNING] maven-scm-publish-plugin . 1.0 [WARNING] org.apache.rat:apache-rat-plugin 0.10 [INFO] [INFO] Project inherits minimum Maven version as: 3.0 [INFO] Plugins require minimum Maven version of: 3.0 [INFO] [INFO] No plugins require a newer version of Maven than specified by the pom. [INFO] [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 8.219 s [INFO] Finished at: 2014-02-23T21:24:11+01:00 [INFO] Final Memory: 11M/27M [INFO] Shall I update those? Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Branch the parent pom hierarchy for Java 1.6 + Maven 3
Am 2014-02-23 21:20, schrieb Stephen Connolly: On Sunday, 23 February 2014, Michael Osipov micha...@apache.org wrote: Am 2014-02-23 19:06, schrieb Benson Margulies: I propose to make releases of our parent stack that are suitable for components and plugins that are making the leap to Java 1.6 and Maven 3 as their base requirements. What do people think is the right approach in terms of what stays on trunk and what goes on a branch, and whether to do anything distinctive to the version numbers? Finally, someone's stepping up for such a good change. Though, I think some important stuff needs to be considered first: 1. Announce 2.x EOL and give people at least 3 months to switch. Already done and site updated Just had a hard time to find this information on the (front) page. I think a mere: 2014-02-18 End of Life EoL notes, announce is not enough. I would have expected something like this on the front page: Looking for Maven 2? // Either some text // or the link to the EoL announcement. 2. If you align plugins with a 3.0 baseline, I would bump at least a minor version, maybe even a major one. I think bumping a major version would be fair and proper... But we don't have a formal policy yet, and a minor version bump might be valid too. Beside the general draft [1] we do already have two good policies. Even one at Apache APR [2], and semver.org. Micahel [1] https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy [2] https://apr.apache.org/versioning.html#strategy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Release notes for 3.2.1 lost on the Maven homepage
Hi folks, did anyone already check http://maven.apache.org/docs/3.2.1/release-notes.html? The link See complete release notes for all versions links to http://maven.apache.org/ and is missing a period. Release notes not available. http://maven.apache.org/ref/3.2.1/ is a 404. http://maven.apache.org/release-notes-all.html does not include 3.2.x, neither does http://maven.apache.org/release-notes-3.x.html. http://maven.apache.org/download.cgi says: Maven 3.1.1 This is a stable version 3.0.x of Maven for projects that can't upgrade to Maven 3.1 yet. This is obviously, incorrect. AND Windows 2000/XP + C:\Program Files\Java\jdk1.5.0_02, seriously? Who has a good overview over that content to fix it? Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Release notes for 3.2.1 lost on the Maven homepage
I forgot: System Requirements: JDK 1.5 or above Depends on the Mavn version. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven-assembly-plugin / Maven default folder layout
Am 2014-03-07 20:25, schrieb Robert Scholte: Hi, This is the standard (preferred) directory layout, so it doesn't have to be the default. I actually think that src/main/assembly/ should be src/assembly/, otherwise it would imply that there can also be a src/test/assembly/. I wouldn't separate the descriptors into different folders. +1 That's the first thing which came to my mind too. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven-assembly-plugin / Maven default folder layout
Am 2014-03-07 20:25, schrieb Robert Scholte: Hi, This is the standard (preferred) directory layout, so it doesn't have to be the default. I actually think that src/main/assembly/ should be src/assembly/, otherwise it would imply that there can also be a src/test/assembly/. I wouldn't separate the descriptors into different folders. +1 That's the first thing which came to my mind too. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven-assembly-plugin / Maven default folder layout
Am 2014-03-08 22:24, schrieb Dennis Lundberg: Hi I agree with Karl Heinz that the Assembly Plugin should support the documented default directory. It seems that we disagree about what the preferred directory should be. I think it should be src/main/assembly/ because almost all assemblies I have ever seen are for the main part of a project. If someone wanted to create an assembly for the test part of a project I would recommend to place the assembly descriptor in src/test/assembly. Dennis, neither do you have src/main/site and other resembling structures. There is no way to enforce that this assembly is part of a test cycle, moreover such a notion does not exist for assemblies. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Checkstyle Plugin version 2.12
Am 2014-03-08 23:49, schrieb Dennis Lundberg: Hi, We solved 15 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11127styleName=Htmlversion=19723 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11127status=1 Staging repo: https://repository.apache.org/content/repositories/maven-1010/ https://repository.apache.org/content/repositories/maven-1010/org/apache/maven/plugins/maven-checkstyle-plugin/2.12/maven-checkstyle-plugin-2.12-source-release.zip Source release checksum(s): maven-checkstyle-plugin-2.12-source-release.zip sha1: 1d2c6435e214daa9bedce6d32871a8b7ac3f Staging site: http://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote is open for 72 hours. +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 PMD Plugin version 3.1
+1, but why not upgrade to 5.1 (MPMD-182) first? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven PMD Plugin version 3.1
Am 2014-03-12 06:43, schrieb Dennis Lundberg: I want this release to be Java 5 compatible. PMD 5.1 requires Java 6, even though it is not mentioned in their release notes. Fair enough but unprofessional from the PMD guys. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RFC: maven-enforcer-rule: http://jira.codehaus.org/browse/MENFORCER-186
Am 2014-03-16 14:52, schrieb Mirko Friedenhagen: RequireReactorProjectsHaveUniqueVersion? This does not imply that they have the same version but only unique. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Releasing maven-buildnumber-plugin as-is?
Am 2014-03-18 15:29, schrieb Baptiste Mathus: Hi, There seems to be a need for a release for buildnumber with @threadSafe added. https://jira.codehaus.org/browse/MBUILDNUM-115 and its dups. I can act as RM if nobody objects against this release now. That'll help users. If anyone wants to try and tackle some more things on this plugin, just let me know we can obviously wait. Actually, I would want to fix one issue but I do not have the permission in JIRA nor do I have write access to that repo. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Welcome Mirko Friedenhagen to the Apache Maven Team
Am 2014-03-17 20:53, schrieb Robert Scholte: Hi, On behalf of the Apache Maven PMC I am pleased to announce that Mirko Friedenhagen (mfriedenhagen) has been voted in as a new Apache Maven committer. Mirko, welcome on board and have a lot of fun! Ein herzliches Willkommen -- schön weitere Verstärkung aus Deutschland zu sehen. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-5626 and the need for a log file
Am 2014-05-05 16:20, schrieb Paul Benedict: One thing that I like about Eclipse is that it contains a log file to capture the unexpected warning or error. These warnings or errors may not kill the program but at least I can peer inside to see what's going on. With regard to MNG-5626, it makes me wonder should Maven have a default logging location. There are situations that shouldn't kill a build (like negative build times) but are extraordinary enough that they should be dumped to a log file for studying. I think plugins should have the ability to do such things for the sake of diagnosing out unfavorable conditions/bugs in the code. BTW, this is a different feature than debug info and stack traces. I don't want to bug the user with more on their screen. I just want normal builds to run like they do except introduce a warning log. Paul, how would a log file help to solve the above mentioned problem (MNG-5626). I guess Logback relies on currentMillis too. Moreover, what should be logged and to what extent? I do think, it's worth investigating but quite hard to decide what should be printed to such a file. Using SLF4J markers and a distinct Logback configuration may be a good help. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Processing Pull Request
Hi, does it take special permissions on Github to process pull requests? Neither am I allowed to perform the merge from the website directly, nor does it display the command line steps as described in the GH help. Close is not available to me too. I simply pulled (PL 14) into my local repo and then pushed, asfgit processed but the PL is still on merged but not closed. Is there any writeup how a PL should happen in the project? Maven Git Convention [1] does not provide any valueable information. Michael [1] http://maven.apache.org/developers/conventions/git.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Processing Pull Request
Am 2014-05-24 17:38, schrieb Alexander Kriegisch: As for necessary permissions: https://help.github.com/articles/what-are-the-different-access-permissions That's good but how does one know whether he as Write Access Teams Repository Access' or not. Especially for mirrored repos. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Processing Pull Request
Am 2014-05-24 18:57, schrieb Igor Fedorenko: Please don't use Github PL merge functionality. This will create merge commits... and I seriously dislike merge commits, hate them, actually. Are you able to share your experience by improving the Git Convention on the Maven website? Me and others want a patch merged and not fiddling with Git issues actually. Thanks, Michael On 2014-05-24, 12:39, Jason van Zyl wrote: The mechanics of processing PRs from repos we have access to is all good. But the Apache repos on Github I'm not sure who actually owns them, I assume ASF infra. For any moderately sized PR I add the PR as a remote and process it locally. But for simple patches I really would just like to hit the merge button. Our current setup doesn't allow this which is sub-optimal. On May 24, 2014, at 11:09 AM, Alexander Kriegisch alexan...@kriegisch.name wrote: Does this help? https://help.github.com/articles/using-pull-requests -- Alexander Kriegisch Am 24.05.2014 um 16:07 schrieb Jason van Zyl ja...@takari.io: Yes, I'm interested as well. On May 24, 2014, at 9:33 AM, Michael Osipov micha...@apache.org wrote: Hi, does it take special permissions on Github to process pull requests? Neither am I allowed to perform the merge from the website directly, nor does it display the command line steps as described in the GH help. Close is not available to me too. I simply pulled (PL 14) into my local repo and then pushed, asfgit processed but the PL is still on merged but not closed. Is there any writeup how a PL should happen in the project? Maven Git Convention [1] does not provide any valueable information. Michael [1] http://maven.apache.org/developers/conventions/git.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann - 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
Processing Pull Request
Hi, does it take special permissions on Github to process pull requests? Neither am I allowed to perform the merge from the website directly, nor does it display the command line steps as described in the GH help. Close is not available to me too. I simply pulled (PL 14) into my local repo and then pushed, asfgit processed but the PL is still on merged but not closed. Is there any writeup how a PL should happen in the project? Maven Git Convention [1] does not provide any valueable information. Michael [1] http://maven.apache.org/developers/conventions/git.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Processing Pull Request
Am 2014-05-26 14:54, schrieb Daniel Kulp: On May 24, 2014, at 9:18 AM, Michael Osipov mosi...@gmx.de wrote: Hi, does it take special permissions on Github to process pull requests? Neither am I allowed to perform the merge from the website directly, nor does it display the command line steps as described in the GH help. Close is not available to me too. I simply pulled (PL 14) into my local repo and then pushed, asfgit processed but the PL is still on merged but not closed. Is there any writeup how a PL should happen in the project? Maven Git Convention [1] does not provide any valueable information. If it doesn’t auto close for whatever reason (likely a rebase or something), then you would need to put a comment on the pull request like: Can you verify that the functionality ha been merged correctly and close this if it has. or similar to get the requestor to close it. OR Make a simple commit with: This closes #14 in the log message and the asf bot will close it. OR File a request with INFRA to close it. In general, if you pull a pull request and it ends up rebating or similar so the sha1 is different, then you should likely do a “git -a —amend” and edit the commit message to to add the “This closes #XX” line to the message before you push. Hi Daniel, I have amended the last commit, see https://github.com/apache/maven/pull/14#ref-commit-0499d1d. But I have simply merged that PR manually and then pushed to git.apache.org. Thus, I cannot have an additional commit w/o doing bogus. There must be some better way to process PRs. The best solution is to produce a commit like this [1] but I do not have the knowledge how to perform this with git means. That's is why I have for an improvements of the docs. Michael [1] https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=bef7fac6e3495dae57a44e6a5902afd89c74b196 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Github pull requests for Maven Core
Am 2014-05-30 15:57, schrieb Jason van Zyl: I'm happy to look at pull requests but in the future can anyone making a pull request please squash your commits before making the pull request. Eventually I want to use Gerrit and create a mechanism where pull requests can be tested against the ITs to make it easier for contributors to know they haven't broken anything. Issue created: https://issues.apache.org/jira/browse/INFRA-7836 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven 3.2.2
Am 2014-06-17 18:03, schrieb Jason van Zyl: Hi, Time to release Maven 3.2.2! I am confused?! There are nine unresolved issues for that release. If you are not going to fix, remove the 'Fix Version' please. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
MNG Roadmap in JIRA
Hi folks, has anyone of you ever check the roadmap in JIRA lately? There are several versions which will probably never be released. Moveover, all tickets for 2.2.2 are fixed. Can we clean up upcoming versions? Are we going to release a EOL 2.2.2? Thanks, Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MNG Roadmap in JIRA
Am 2014-06-17 21:17, schrieb Karl Heinz Marbaise: Hi, has anyone of you ever check the roadmap in JIRA lately? There are several versions which will probably never be released. Moveover, all tickets for 2.2.2 are fixed. Can we clean up upcoming versions? Are we going to release a EOL 2.2.2? In february we had decided not to release any 2.X version (EoL).. but who will us detain? Right, just found the mail you wrote to the list. It's EOL -- just checked the tickets. Hervé and others invested valueable time to fix them. We should honor that and cut a final release, though it is EOL. WDYT? Michael PS: I have removed '2.2.x (to be reviewed)' because no one will ever touch it again. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MNG Roadmap in JIRA
Am 2014-06-17 21:14, schrieb Jason van Zyl: Just start nuking/moving/cleaning if you think it makes sense. Just did for 2.2.x. But are we going to relase 3.0.6 or 3.1.2? I don't think so because all energy is being put into 3.2.x. If so, should we declare at least 3.0.x as EOL? If not, people and me would assume that it is still being worked on. On Jun 17, 2014, at 3:05 PM, Michael Osipov micha...@apache.org wrote: Hi folks, has anyone of you ever check the roadmap in JIRA lately? There are several versions which will probably never be released. Moveover, all tickets for 2.2.2 are fixed. Can we clean up upcoming versions? Are we going to release a EOL 2.2.2? Thanks, Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MNG Roadmap in JIRA
Am 2014-06-17 21:57, schrieb Jason van Zyl: On Jun 17, 2014, at 3:47 PM, Michael Osipov micha...@apache.org wrote: Am 2014-06-17 21:14, schrieb Jason van Zyl: Just start nuking/moving/cleaning if you think it makes sense. Just did for 2.2.x. But are we going to relase 3.0.6 or 3.1.2? I don't think so because all energy is being put into 3.2.x. If so, should we declare at least 3.0.x as EOL? If not, people and me would assume that it is still being worked on. Unlike more 3.0.x or 3.1.x as it's really all been rolled into 3.2.x. Aside from the Aether debacle with the APIs most things work the same, and I think I'm just going to be more judicious while working on master as if I change a few signatures here and there I'm probably not going to roll major or minor versions. It's just confusing and no one cares for the most part. 98% of our users are just users and it's the features that matter. For the remaining 2% who are integrators it's unfortunate what happened with Aether but it probably affect 20 plugins, not the end of the world. Great, I'd discontinue both in JIRA. On Jun 17, 2014, at 3:05 PM, Michael Osipov micha...@apache.org wrote: Hi folks, has anyone of you ever check the roadmap in JIRA lately? There are several versions which will probably never be released. Moveover, all tickets for 2.2.2 are fixed. Can we clean up upcoming versions? Are we going to release a EOL 2.2.2? Thanks, Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MNG Roadmap in JIRA
Am 2014-06-18 04:25, schrieb Paul Benedict: Since 2.x is discontinued, this is our opportunity to rename the JIRA project too. Right now it's Maven 2 3. It can either be Maven 3 or simply Maven. Thoughts? Good point, clean up the JIRA frontpage of MNG. Do you have the permission to do so? If yes, please proceed for Maven. Michael On Tue, Jun 17, 2014 at 3:03 PM, Michael Osipov micha...@apache.org wrote: Am 2014-06-17 21:57, schrieb Jason van Zyl: On Jun 17, 2014, at 3:47 PM, Michael Osipov micha...@apache.org wrote: Am 2014-06-17 21:14, schrieb Jason van Zyl: Just start nuking/moving/cleaning if you think it makes sense. Just did for 2.2.x. But are we going to relase 3.0.6 or 3.1.2? I don't think so because all energy is being put into 3.2.x. If so, should we declare at least 3.0.x as EOL? If not, people and me would assume that it is still being worked on. Unlike more 3.0.x or 3.1.x as it's really all been rolled into 3.2.x. Aside from the Aether debacle with the APIs most things work the same, and I think I'm just going to be more judicious while working on master as if I change a few signatures here and there I'm probably not going to roll major or minor versions. It's just confusing and no one cares for the most part. 98% of our users are just users and it's the features that matter. For the remaining 2% who are integrators it's unfortunate what happened with Aether but it probably affect 20 plugins, not the end of the world. Great, I'd discontinue both in JIRA. On Jun 17, 2014, at 3:05 PM, Michael Osipov micha...@apache.org wrote: Hi folks, has anyone of you ever check the roadmap in JIRA lately? There are several versions which will probably never be released. Moveover, all tickets for 2.2.2 are fixed. Can we clean up upcoming versions? Are we going to release a EOL 2.2.2? Thanks, Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Simplex sigillum veri. (Simplicity is the seal of truth.) - 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: [RESULT] [VOTE] Release Maven 3.2.2
Am 2014-06-24 13:08, schrieb Jason van Zyl: Hi, The vote passed with the following result: +1 (binding): Jason van Zyl, Hervé Boutemy, Olivier Lamy, Arnaud Héritier, Robert Scholte +1 (non-binding): Karl-Heinz Marbaise, Mirko Friedenhagen, Mark Derricutt, Igor Fedorenko, Baptiste Mathus I will finish the writeup of the release notes and promote to Maven Central. Hervé can you publish the site please? http://maven.apache.org/release-notes-all.html still refers to 3.1. No word about 3.2.1 or 3.2.2. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM 5.0 and Maven.next idea - re: repository's
Am 2014-06-26 14:34, schrieb Mark Derricutt: In last weeks dev hangout I raised the idea of removing repository elements due to some issues with them regarding mirrors etc which was somewhat negatively received, however I've been thinking about this a bit and came up with an interesting idea earlier in the night whilst at a gig. One of the problems I'm often seeing is that: 1) a project uploads their artefact to a repository ( mostly maven central ) 2) 90% of their dependencies are available from the repository in question 3) 1 critical dependency is not - which ultimately means you can't build..if you have a mirror setup (usually because you've not noticed a repository declaration which you need to configure in your nexus/arifactory/archiva etc. ) The idea I had is three fold: 1) Fallback on original repository when a mirror doesn't resolve When maven is checking for a repository for an artefact, and using a mirror - if that artefact can't be found, maven should retry using the original repository directly with builds warnings. Not going to work if you are behing a MRM instance and proxied in a company like me. 2) Deploy transitive runtime dependencies along with your release This beats DRY and reinvents the wheel. I would obstain doing either one. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM 5.0 and Maven.next idea - re: repository's
Am 2014-06-26 21:41, schrieb Mark Derricutt: On 27 Jun 2014, at 7:27, Michael Osipov wrote: 2) Deploy transitive runtime dependencies along with your release This beats DRY and reinvents the wheel. I would obstain doing either one. I don't see this as repeating oneself, just about populating a repository with required dependencies - not bundling dependencies inside your artefact or anything. Still - it's only an idea for discussion around a common problem. Mark, let me rephrase your intention: you want to re-upload dependencies -- even if they are already in a repo?! Am I wrong? Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Doxia base and Site Tools version 1.6
Am 2014-06-28 00:38, schrieb Hervé BOUTEMY: Hi, We solved 6 issues in Doxia base and 7 issues in Doxia Site Tools: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10780styleName=Htmlversion=19820 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11624styleName=Htmlversion=19925 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10780status=1 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11624status=1 Staging repo: https://repository.apache.org/content/repositories/maven-1030/ http://repository.apache.org/content/repositories/maven-1030/org/apache/maven/doxia/doxia/1.6/doxia-1.6-source-release.zip http://repository.apache.org/content/repositories/maven-1030/org/apache/maven/doxia/doxia-sitetools/1.6/doxia-sitetools-1.6-source-release.zip Source release checksum(s): doxia-1.6-source-release.zip sha1: 0ae9b9a09bfdc9d0aada1cbc5571c710805abae6 doxia-sitetools-1.6-source-release.zip sha1: 9a166407b659452379fc680a25e43b3a162ed27e Staging site: http://maven.apache.org/doxia/doxia-archives/doxia-LATEST/ http://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html +1 Are you going to release the site plugin as well with this new changes? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Doxia base and Site Tools version 1.6
Am 2014-06-28 14:16, schrieb Karl Heinz Marbaise: Hi, so after Hervé and I identified the problem of the failing test which is caused by my ISP (Deutsche Telekom ;-)) which shows me a nice HTML page instead of simply failing the request to an unknown page(dns failure). This crap is also done by Alice/O2 instead of NXDOMAIN and probably other ISPs. You can and should turn this off in T-Home Kundencenter. This is what I did years ago. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Issues to be reviewed for 3.x
Am 2014-07-01 18:21, schrieb Paul Benedict: I was just about to bulk change these and but could not find the Send Email for this Update checkbox. Based on what I read, it's an option only available to project admins. So... either someone with more karma can do this change or we just accept 200 email updates :-) I don't like the latter. Thoughts? I'd do it anyway! On Tue, Jul 1, 2014 at 3:28 AM, Michael-O 1983-01...@gmx.net wrote: Hi Paul, There are about 295 closed issues in Issues to be reviews for 3.x, presumably all closed due to the massive issue cleanup. I can do a query to find out for sure. For the ones I can verify, does anyone care if I remove the version from these tickets? They aren't being released and that's our policy now -- not to set the Fix Version for issues that are incomplete/invalid. this is a very good idea. I have done that already for all pre-3.3.2 versions which aren't going to come. I think, we strictly follow that no-fix-version-for-incomplete/invalid/wontfix. If you are able to assign to real versions that's great. 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: [MJAVADOC-398] pull request
Am 2014-07-01 12:59, schrieb Michal Srb: Hello, I filed a bug [1] and opened pull request [2] for maven-javadoc-plugin. Please see links below for context. The real problem seems to be in javadoc tool, but it can be avoided by not putting compiled project classes on javadoc's -classpath. The question is: can such change break something? All comments and suggestions are appreciated. Thanks Michal [1]: http://jira.codehaus.org/browse/MJAVADOC-398 [2]: https://github.com/apache/maven-plugins/pull/25 For what it's worth, I have asked Michal to do so because this is a change in behavior. If no one opposes, I will perform the merge. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Doxia Tools version 3 + Doxia Integartion Tools version 1.6
Am 2014-07-03 21:47, schrieb Hervé BOUTEMY: nobody? this is the last intermediate components release before releasing the main objective: maven-site-plugin 3.4 +2 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Site Plugin version 3.4 (take 2)
Am 2014-07-07 21:24, schrieb Hervé BOUTEMY: Hi, We solved 13 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=19228 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repo: http://repository.apache.org/content/repositories/maven-1038/ http://repository.apache.org/content/repositories/maven-1038/org/apache/maven/plugins/maven-site-plugin/3.4/maven-site-plugin-3.4-source-release.zip Source release checksum(s): maven-site-plugin-3.4-source-release.zip sha1: 1829a518c037334b4fd6bde40b33a34344ff1af6 Staging site: http://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html +1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Providing settings to Aether from global and user file
Am 2014-09-05 um 12:32 schrieb WonderCsabo: Hi guys! I already posted my question http://maven.40175.n5.nabble.com/Providing-settings-to-Aether-from-global-and-user-file-td5803227.html to the users list, but i did not get any answers. I am posting now here, maybe this kind of question better fits to this list. If not, sorry for spamming. Wrong list, go here https://dev.eclipse.org/mailman/listinfo/aether-users - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1627863 - /maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java
Am 2014-09-26 um 21:28 schrieb Robert Scholte:
Hi Michael,
I'm missing action on the wise words from Hervé.
Are you planning to add an IT?
Actually, yes.
Concerning populateCompileArtifactMap, I guess it suffices to create a
sample project with some dependencies and have javadoc link to those
javadoc URLs.
I am about to prepare the release to ease the bug I have introduced.
Shoudl I stall it and creae the IT first?
Michael
Op Fri, 26 Sep 2014 21:14:37 +0200 schreef micha...@apache.org:
Author: michaelo
Date: Fri Sep 26 19:14:36 2014
New Revision: 1627863
URL: http://svn.apache.org/r1627863
Log:
[MJAVADOC-406] + [MJAVADOC-407] Regression by MJAVADOC-398
Modified:
maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java
Modified:
maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java
URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java?rev=1627863r1=1627862r2=1627863view=diff
==
---
maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java
(original)
+++
maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java
Fri Sep 26 19:14:36 2014
@@ -2436,7 +2436,7 @@ public abstract class AbstractJavadocMoj
ListString classpathElements = new ArrayListString();
MapString, Artifact compileArtifactMap = new
HashMapString, Artifact();
-classpathElements.addAll( getProjectBuildOutputDirs( project
) );
+populateCompileArtifactMap( compileArtifactMap,
getProjectArtifacts( project ) );
if ( isAggregator() project.isExecutionRoot() )
{
-
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: svn commit: r1627863 - /maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java
Am 2014-09-26 um 21:28 schrieb Robert Scholte:
Hi Michael,
I'm missing action on the wise words from Hervé.
Are you planning to add an IT?
I am already on it.
Op Fri, 26 Sep 2014 21:14:37 +0200 schreef micha...@apache.org:
Author: michaelo
Date: Fri Sep 26 19:14:36 2014
New Revision: 1627863
URL: http://svn.apache.org/r1627863
Log:
[MJAVADOC-406] + [MJAVADOC-407] Regression by MJAVADOC-398
Modified:
maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java
Modified:
maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java
URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java?rev=1627863r1=1627862r2=1627863view=diff
==
---
maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java
(original)
+++
maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java
Fri Sep 26 19:14:36 2014
@@ -2436,7 +2436,7 @@ public abstract class AbstractJavadocMoj
ListString classpathElements = new ArrayListString();
MapString, Artifact compileArtifactMap = new
HashMapString, Artifact();
-classpathElements.addAll( getProjectBuildOutputDirs( project
) );
+populateCompileArtifactMap( compileArtifactMap,
getProjectArtifacts( project ) );
if ( isAggregator() project.isExecutionRoot() )
{
-
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: svn commit: r1627863 - /maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java
Am 2014-09-26 um 21:28 schrieb Robert Scholte: Hi Michael, I'm missing action on the wise words from Hervé. Are you planning to add an IT? I have created an IT based off a real project I host on sourceforge. It replicates MJAVADOC-407. If that is fine, I'd like to roll 2.10.1 on Saturday. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Maven Javadoc Plugin version 2.10.1
Hi, We solved 3 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11138version=20644 There are still a couple of issues left in JIRA: http://jira.codehaus.org/issues/?jql=project%20%3D%20MJAVADOC%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1069/ http://repository.apache.org/content/repositories/maven-1069/org/apache/maven/plugins/maven-javadoc-plugin/2.10.1/maven-javadoc-plugin-2.10.1-source-release.zip Source release checksum(s): maven-javadoc-plugin-2.10.1-source-release.zip sha1: 991cf644f9ec95a53899ca6a53dba0d14b74799b Staging site: http://maven.apache.org/plugins-archives/maven-javadoc-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: [DISCUSS] Move everything to 1.6
We moved core to 1.6 some time ago. Time to move everything else as well ? Kristian (Who's ready to say 1.7 but we stop by 1.6 first :) I would favor the move to Java 1.7 if we make strong use of NIO2 for file operations. A lot of pain should go away. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Javadoc Plugin version 2.10.1
Guys, I need one more binding vote! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Release Maven Javadoc Plugin version 2.10.1
Hi, The vote has passed with the following result: +1 (binding): Karl-Heinz Marbaise, Robert Scholte, Hervé Boutemy, Olivier Lamy +1 (non-binding): Mirko Friedenhagen I will promote the artifacts to the central repo. PMCs please promote the source release ZIP file and add this release the board report. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Maven Javadoc Plugin 2.10.1 released
The Apache Maven team is pleased to announce the release of the Maven Javadoc Plugin, version 2.10.1. This module generates browsable HTML pages from Java source code. http://maven.apache.org/plugins/maven-javadoc-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId version2.10.1/version /plugin Release Notes - Maven Javadoc Plugin - Version 2.10.1 ** Bug * [MJAVADOC-406] - Regression: MJAVADOC-398 commit changed wrong line * [MJAVADOC-407] - Cannot parse annotations when generating javadoc * [MJAVADOC-416] - java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl cannot be cast to com.sun.javadoc.AnnotationTypeDoc ** Improvement * [MJAVADOC-412] - Update version of plexus-archiver to 2.5 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Maven plugin naming pattern
Hi folks, how do we actually proceed with third-party plugins which do not comply to our naming pattern [1]? Given that a plugin has been created before this document has beeen first published 2013-01-02. Should they simply add a disclaimer for legacy reasons? What about plugins on Central created after that date? Michael [1] http://maven.apache.org/guides/plugin/guide-java-plugin-development.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Re: Maven plugin naming pattern
They should rename going forward. At some point (probably we could do so now) we will turn on enforcement in the maven-plugin-plugin. This will of course piss of a lot of people. Wouldn't it? There are, of course, several reasons why people can't: 1. Popularity of the old name 2. Technical reasons 3. Name collisions etc. Even if we enforce this, this should not happen before Maven 4 and should be added to the plugin dev center. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Re: Re: Maven plugin naming pattern
If you do a quick search on Central, you'll that even other Apache project don't adhere to this convention. Should they receive a CD too? Michael We just need to show best effort to defend our trademark... if we *see* anyone doing that then we have to send them CD letters... Note: my understanding is that we only have to send CD letters when we know somebody is abusing our mark... we don't necessarily have to go actively looking for people abusing our mark... just if we went looking and found any then we have to send them CDs quite quickly On 10 October 2014 12:45, Benson Margulies bimargul...@gmail.com wrote: On Fri, Oct 10, 2014 at 7:42 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We, the PMC, agreed to allow permitted usage of the form ___-maven-plugin as that clarified that the plugin was a plugin for maven not one produced by maven Yea, I know, and I'm not opposed to making the tooling more obstreperous. I'm just warning people not to have high hopes of enforcement for anyone who chooses to hack the tooling and not cooperate. On 10 October 2014 12:40, Benson Margulies bimargul...@gmail.com wrote: Keep in mind that what we have here is almost certainly a _convention_, not a point of trademark law. As I understand it, we'd as likely be laughed at for the suggestion that reversing the order of the components of a name leads to 'marketplace confusion' at the level at which trademarks can be enforced. On Fri, Oct 10, 2014 at 7:25 AM, Michael Osipov 1983-01...@gmx.net wrote: They should rename going forward. At some point (probably we could do so now) we will turn on enforcement in the maven-plugin-plugin. This will of course piss of a lot of people. Wouldn't it? There are, of course, several reasons why people can't: 1. Popularity of the old name 2. Technical reasons 3. Name collisions etc. Even if we enforce this, this should not happen before Maven 4 and should be added to the plugin dev center. 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 - 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: Re: Re: Re: Maven plugin naming pattern
Yes, resposibility isn't always good. Shouldn't simply make the build fail instead of log when such a collision happens? Michael Thankfully for you, you are not on the PMC... if you were on the PMC and you did such a search you would then have to go and send CDs. /me runs away from this thread in case I happen to be made aware of any trademark misuse ;-) On 10 October 2014 13:39, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Yes On 10 October 2014 13:12, Michael Osipov 1983-01...@gmx.net wrote: If you do a quick search on Central, you'll that even other Apache project don't adhere to this convention. Should they receive a CD too? Michael We just need to show best effort to defend our trademark... if we *see* anyone doing that then we have to send them CD letters... Note: my understanding is that we only have to send CD letters when we know somebody is abusing our mark... we don't necessarily have to go actively looking for people abusing our mark... just if we went looking and found any then we have to send them CDs quite quickly On 10 October 2014 12:45, Benson Margulies bimargul...@gmail.com wrote: On Fri, Oct 10, 2014 at 7:42 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We, the PMC, agreed to allow permitted usage of the form ___-maven-plugin as that clarified that the plugin was a plugin for maven not one produced by maven Yea, I know, and I'm not opposed to making the tooling more obstreperous. I'm just warning people not to have high hopes of enforcement for anyone who chooses to hack the tooling and not cooperate. On 10 October 2014 12:40, Benson Margulies bimargul...@gmail.com wrote: Keep in mind that what we have here is almost certainly a _convention_, not a point of trademark law. As I understand it, we'd as likely be laughed at for the suggestion that reversing the order of the components of a name leads to 'marketplace confusion' at the level at which trademarks can be enforced. On Fri, Oct 10, 2014 at 7:25 AM, Michael Osipov 1983-01...@gmx.net wrote: They should rename going forward. At some point (probably we could do so now) we will turn on enforcement in the maven-plugin-plugin. This will of course piss of a lot of people. Wouldn't it? There are, of course, several reasons why people can't: 1. Popularity of the old name 2. Technical reasons 3. Name collisions etc. Even if we enforce this, this should not happen before Maven 4 and should be added to the plugin dev center. 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 - 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: Re: Re: Re: Re: Maven plugin naming pattern
Fine, I'd like to note that first: 1. Shouldn't we announce this publically on the users mailing list? 2. I think that this deserves a major bump in plugin version. WDYT? Michael Gesendet: Freitag, 10. Oktober 2014 um 15:23 Uhr Von: Stephen Connolly stephen.alan.conno...@gmail.com An: Maven Developers List dev@maven.apache.org Betreff: Re: Re: Re: Re: Maven plugin naming pattern That was the plan 3 years ago we decided to warn first and then switch on failing after a while... now is a good time, perhaps you could commit the change to fail the build? On 10 October 2014 13:48, Michael Osipov 1983-01...@gmx.net wrote: Yes, resposibility isn't always good. Shouldn't simply make the build fail instead of log when such a collision happens? Michael Thankfully for you, you are not on the PMC... if you were on the PMC and you did such a search you would then have to go and send CDs. /me runs away from this thread in case I happen to be made aware of any trademark misuse ;-) On 10 October 2014 13:39, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Yes On 10 October 2014 13:12, Michael Osipov 1983-01...@gmx.net wrote: If you do a quick search on Central, you'll that even other Apache project don't adhere to this convention. Should they receive a CD too? Michael We just need to show best effort to defend our trademark... if we *see* anyone doing that then we have to send them CD letters... Note: my understanding is that we only have to send CD letters when we know somebody is abusing our mark... we don't necessarily have to go actively looking for people abusing our mark... just if we went looking and found any then we have to send them CDs quite quickly On 10 October 2014 12:45, Benson Margulies bimargul...@gmail.com wrote: On Fri, Oct 10, 2014 at 7:42 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We, the PMC, agreed to allow permitted usage of the form ___-maven-plugin as that clarified that the plugin was a plugin for maven not one produced by maven Yea, I know, and I'm not opposed to making the tooling more obstreperous. I'm just warning people not to have high hopes of enforcement for anyone who chooses to hack the tooling and not cooperate. On 10 October 2014 12:40, Benson Margulies bimargul...@gmail.com wrote: Keep in mind that what we have here is almost certainly a _convention_, not a point of trademark law. As I understand it, we'd as likely be laughed at for the suggestion that reversing the order of the components of a name leads to 'marketplace confusion' at the level at which trademarks can be enforced. On Fri, Oct 10, 2014 at 7:25 AM, Michael Osipov 1983-01...@gmx.net wrote: They should rename going forward. At some point (probably we could do so now) we will turn on enforcement in the maven-plugin-plugin. This will of course piss of a lot of people. Wouldn't it? There are, of course, several reasons why people can't: 1. Popularity of the old name 2. Technical reasons 3. Name collisions etc. Even if we enforce this, this should not happen before Maven 4 and should be added to the plugin dev center. 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 - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Re: Maven plugin naming pattern
Hi, On 10/10/14 3:41 PM, Paul Benedict wrote: I would prefer this should be part of Maven Core's warning system. If the plugin starts with maven- and it's not an org.apache.maven.plugins group, then we should spit out the error. I am not sure enforcer is the right place for this rule; this is more of a global problem than a suggestion for good practice. In my opinion this should be part of Maven Core (Maven itself within the next version 3.2.4 ?) otherwise we can't be sure that those warnings (possible breaks) will ever happen... Located in the lifecycle phase of 'maven-plugin'? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins: Maven 2.2.1 prerequesites / Maven 3.0 Prerequisites
Am 2014-10-11 um 18:39 schrieb Karl Heinz Marbaise: Hi, i want to summarize the current state of the maven plugins which can be found here: http://maven.apache.org/plugins/ which are currently at the Maven 2.2.1 minimum prerequesites state and which are not. The following list of plugins do not have a Maven 2.2.1 prerequisites they have the prerequisites in parentheses given: maven-compiler-plugin(2.0.9) maven-failsafe-plugin(2.0.9) maven-surefire-plugin(2.0.9) maven-verifier-plugin(2.0.6) maven-ear-plugin (2.0.6) maven-jar-plugin (2.0.6) maven-war-plugin (2.0.6) maven-doap-plugin(2.2.0) maven-docck-plugin (2.0.6) maven-jxr-plugin (2.0.9) maven-surefire-report-plugin (2.0.9) maven-ant-plugin (2.0.6) maven-antrun-plugin (2.0.11) maven-archetype-plugin (2.0.7) maven-enforcer-plugin(2.0) maven-gpg-plugin (2.0.6) maven-jarsigner-plugin (2.1.0) maven-patch-plugin (2.0.6) maven-pdf-plugin (2.0.9) maven-plugin-plugin (2.0.6) maven-repository-plugin (2.0.6) scm (2.0) maven-stage-plugin (2.0.5) maven-toolchains-plugin (2.0.9) maven-eclipse-plugin (2.0.8) I think of the above plugins we should make a final release with Maven 2.2.1 JDK 5 prerequisites... The following plugins have Maven 2.2.1 prerequisites and JDK 6: maven-pmd-plugin The following plugins have Maven 3.0 prerequisites and JDK 1.5 maven-shade-plugin maven-scm-publish-plugin If the above release cycle has been done i would say to start with creating Maven 3.0.5 prerequisites only pluginswhich should be represented by the plugin version number starting with 3.X... Profound and very well-thought work, thank you! Please keep doing, Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] Re: Maven plugin naming pattern
I'd like to sum up the consensus we have hopefully reached already: 1. Make maven-plugin-plugin fail the build if the plugin being build does not adhere to our convention (next minor version). 2. Warn a user when a build is performed with a plugin which violates the naming convention, just like with deps w/o versions. 3. Create an appropriate enforcer rule. 4. Break build with Maven 4 if an illegally named plugin is used Does that fit? Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [RESULT] Re: Maven plugin naming pattern
Am 2014-10-11 um 21:03 schrieb Benson Margulies: I am very tempted to reopen the trademark question here. It seems to me that this whole business ignores the groupId component of the name, which distinguishes pretty clearly, and I would argue is enough to avoid trademark dillution. Well said... I guess it is all about the order of the words: Maven X Plugin. It simply implies that is provided by the Maven team. Which is not. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [RESULT] Re: Maven plugin naming pattern
Am 2014-10-11 um 21:28 schrieb Robert Munteanu: On Sat, Oct 11, 2014 at 10:23 PM, Michael Osipov micha...@apache.org wrote: Well said... I guess it is all about the order of the words: Maven X Plugin. It simply implies that is provided by the Maven team. Which is not. But is the order relevant in the artifactId or in the public display name? I think it's simpler to convince plugin maintainers to change the public display name ( Maven X Plugin - X Plugin for Maven ) rather than the artifactId. I do not hang on the specific order, a correct display name should suffices but Stephen was pretty obvious about trademark violation. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1631098 - /maven/site/trunk/content/apt/guides/plugin/guide-java-plugin-development.apt
Am 2014-10-11 um 21:51 schrieb Robert Scholte:
[...]
maven/site/trunk/content/apt/guides/plugin/guide-java-plugin-development.apt
(original)
+++
maven/site/trunk/content/apt/guides/plugin/guide-java-plugin-development.apt
Sat Oct 11 18:31:32 2014
@@ -508,6 +508,44 @@ mvn archetype:generate \
Once the type for the element is defined, the text in the XML file is
converted to the appropriate type of object
+*** Enums
+
+ Enumeration type parameters can also be used. First you need to define
+ your enumeration type and afterwards you can use the enumeration type
+ in the parameter definition:
+
++-+
+public enum Color {
+ green,
+ rot,
+ blue
+}
In the spirit of convention, Java enum values are always uppercase.
Willing to change?
Michael
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven plugin naming pattern
Am 2014-10-12 um 00:30 schrieb Stephen Connolly: On Saturday, 11 October 2014, Michael Osipov micha...@apache.org wrote: Am 2014-10-11 um 21:28 schrieb Robert Munteanu: On Sat, Oct 11, 2014 at 10:23 PM, Michael Osipov micha...@apache.org wrote: Well said... I guess it is all about the order of the words: Maven X Plugin. It simply implies that is provided by the Maven team. Which is not. But is the order relevant in the artifactId or in the public display name? I think it's simpler to convince plugin maintainers to change the public display name ( Maven X Plugin - X Plugin for Maven ) rather than the artifactId. I do not hang on the specific order, a correct display name should suffices but Stephen was pretty obvious about trademark violation. Look, if we - as the PMC - want to open things up and allow other usages, that's fine by me. We should run it by trademarks@a.o and if they are fine with us opening the scope more then we put it to a vote and decide. Right now, what I recall, is we only voted ___ maven plugin as the form of use that we allowed for our mark. Projects own their marks, and are allowed to grant usage forms that they decide to grant. So far we have only granted one from, we can grant others, but it would need to be a conscious decision. I do not think that the display name is a real problem but just the artifact id name pattern. Restriction has been made by the PMC and not by trademarks@a.o, right? The question is, does the PMC insist on that pattern even if, as Benson has mentioned, the group id is different? Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Next Maven prerequisite for Maven Plugins
Am 2014-10-12 um 16:10 schrieb Benson Margulies: On Sun, Oct 12, 2014 at 9:25 AM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi Robert, from my point of view minimum to 3.0.5 ...nothing below...afterwards 3.1.1.and then 3.2.1...the latest releases from the appropriate release lines 3.0.X, 3.1.X, 3.2.X, I wouldn't go to 3.1.0 at the moment cause that could be confusingfrom user point of view...than there is a gap... 2.2.1 3.1.1 From my side... Here's what I _think_ is going on here. Two issues. First, Maven 3.0 was a bit of a camel; there are a number of issues with how Aether and such are plugged in that lead to problems in plugin development. Witness the mess in the dependency plugin as it tried/tries to straddle. So, there's a desire to pull the floor up on the plugins in the hopes of getting to the point where, in general, plugin developers are dealing with a rationalized view of artifacts, dependencies, the like. Second. this group made a decision to stop supporting Maven 2.x core, period. So, it seemed that a reasonable sequel to that was to pull the floor up to, at least, the lowest supported version of the core. Is anyone here committed to making 3.0 alpha-x bugfix releases? No; at most, someone might be willing to make another 3.0.x. So requiring 3.0.x to get new versions of plugins makes logical sense to me. If, in fact, no one is willing to make even a 3.0.x release, we should 'unsupport' 3.0.x in the same way we unsupported 2.2.x. I'm not _advocating_ here. +2 I have started a discussion here several months ago and all upcoming releaes of 3.0.x and 3.1.x have been removed from MNG by me. I second your opinion, Karl Heinz should complete 2.2.1 upgrade for plugins and some time later (e.g. 2015-01) we should announce EOL of 3.0.x. Sthis would make split code for Aether and probably other issues way easier. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven plugin naming pattern
Have you received any respone from trademarks@a.o? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Maven baseline for non-plugins
Hi folks, do we have a policy for Maven dependencies for non-plugins after Karl Heinz has raised the baseline to 2.2.1? I'd like to release Maven Archiver and raise dependency versions, especially Maven to 2.2.1. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven baseline for non-plugins
Am 2014-10-26 um 17:32 schrieb Dennis Lundberg: Hi, In my opinion the new minimum level of Maven (2.2.1) should cover all of our projects, not just plugins. Standardizing on a single base version will also mean less artifacts to download for new Maven installations. This reminds me of something I've been meaning to do for a while now. We have a dependency plugin at my day job, that is a bit like the dependency convergence report, but it works on a much larger scale. We run it on a trunks checkout from svn, that contains an aggregator pom and externals for all our code. The plugin reports all usages of all dependencies across the entire code base, sorted in different ways. Let me see if I can set it up to run on all of Maven, at least the parts that are in svn. It should help us with our minimum Maven version updates. That sounds really good. A report would be helpful. I will proceed with the updates on Maven Archiver. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Maven Archiver version 2.6
Hi, We solved 9 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=18325projectId=11761 There are still a couple of issues left in JIRA: http://jira.codehaus.org/browse/MSHARED-168?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1086/ http://repository.apache.org/content/repositories/maven-1086/org/apache/maven/maven-archiver/2.6/maven-archiver-2.6-source-release.zip Source release checksum(s): maven-archiver-2.6-source-release.zip sha1: 1abc6527f6a3ce037db8c3bc549bb07876f4347a Staging site: http://maven.apache.org/shared-archives/maven-archiver-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 JXR version 2.5
Am 2014-10-26 um 23:15 schrieb Karl Heinz Marbaise: Hi, We solved 10 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11085version=19853 JXR-116: Doxia is already at 1.6. Shouldn't we upgrade first? Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Re: [VOTE] Release Apache Maven JXR version 2.5
Hi Michael, On 10/27/14 7:23 AM, Michael Osipov wrote: Am 2014-10-26 um 23:15 schrieb Karl Heinz Marbaise: Hi, We solved 10 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11085version=19853 JXR-116: Doxia is already at 1.6. Shouldn't we upgrade first? Yes this is true, but the consequence is that the code has to be changed...which took...who knows how long...first i would get a release out of the door... Fine! Furthermore you have claimed to take care of JXR-108 which is three weeks ago...which is no problem... Yes, shame on me. I simply forgot that. This is on my agenda already. If you like to work on some of those issue i would appreciate to create a an other release within two or three weeks...or earlier...for a BugFix... That is OK too. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Re: [VOTE] Release Maven Archiver version 2.6
Hi Michael, there had gone something completely wrongcause the staging repository is empty...from the given url as well as from the Nexus... On 10/27/14 10:45 AM, Mikolaj Izdebski wrote: On 10/26/2014 10:06 PM, Michael Osipov wrote: Staging repo: https://repository.apache.org/content/repositories/maven-1086/ http://repository.apache.org/content/repositories/maven-1086/org/apache/maven/maven-archiver/2.6/maven-archiver-2.6-source-release.zip The repository appears to be empty. source-release.zip doesn't exist. Thanks! As it turns out, something is wrong the the repo on r.a.o. I was able to browse it yesterday. If I try to browse it in the Nexus UI, I get HTTP 500. Repos 1085 and 1087 are broken too. I will have to file an issue with INFRA. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Re: Re: [VOTE] Release Maven Archiver version 2.6
Hi Michael, there had gone something completely wrongcause the staging repository is empty...from the given url as well as from the Nexus... On 10/27/14 10:45 AM, Mikolaj Izdebski wrote: On 10/26/2014 10:06 PM, Michael Osipov wrote: Staging repo: https://repository.apache.org/content/repositories/maven-1086/ http://repository.apache.org/content/repositories/maven-1086/org/apache/maven/maven-archiver/2.6/maven-archiver-2.6-source-release.zip The repository appears to be empty. source-release.zip doesn't exist. Thanks! As it turns out, something is wrong the the repo on r.a.o. I was able to browse it yesterday. If I try to browse it in the Nexus UI, I get HTTP 500. Repos 1085 and 1087 are broken too. I will have to file an issue with INFRA. Issue created: https://issues.apache.org/jira/browse/INFRA-8530 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Re: [VOTE] Release Apache Maven JXR version 2.5
On 10/27/14 11:02 AM, Michael Osipov wrote: Hi Michael, On 10/27/14 7:23 AM, Michael Osipov wrote: Am 2014-10-26 um 23:15 schrieb Karl Heinz Marbaise: Hi, We solved 10 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11085version=19853 JXR-116: Doxia is already at 1.6. Shouldn't we upgrade first? Yes this is true, but the consequence is that the code has to be changed...which took...who knows how long...first i would get a release out of the door... Fine! Furthermore you have claimed to take care of JXR-108 which is three weeks ago...which is no problem... Yes, shame on me. I simply forgot that. This is on my agenda already. Dont feel blamed or something... It's ok ..sometimes you didn't have the time you have thoughthappens to me as well... A working sample project has been attached already. Please check. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Upgrade maven-jar-plugin to have minimum maven 2.2.1 runtime?
Am 2014-10-27 um 21:21 schrieb Karl Heinz Marbaise: Hi Dan, On 10/27/14 9:01 PM, Dan Tran wrote: @Karl Are you planing to release a new maven-jar-plugin? Thanks Yeah...working on a missging single issue...apart from the current down issue of the nexus ... http://jira.codehaus.org/browse/MJAR Please wait until I have released Maven Archiver 2.6. I'd like to update this dependency. Michael PS: Still waiting for RAO... - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [BUG] spell mistake, Log4JLoggerFactory should be Log4jLoggerFactory
Am 2014-10-28 um 03:17 schrieb yanshuai: hi, all, I found a mistake in slf4j-configuration.properties of maven-embedder project, org.slf4j.helpers.Log4JLoggerFactory should be org.slf4j.helpers.Log4jLoggerFactory. Otherwise, when I use log4j2 instead of slf4j-simple, it will not find the class org.slf4j.helpers.Log4JLoggerFactory and generate some unexpected warnings. Hope to fix it in the next version, thanks. http://jira.codehaus.org/browse/MNG - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Archiver version 2.6
Nexus operation has been resumed. Please vote/test. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Who evaluates menu ref=parent|modules / in site.xml?
Hi, I'd like to fix MPIR-279 and by applying the logic from above. I am having a hard time to find that spot which actually evalutes the snippet above. Does someone know? Thanks, Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Archiver version 2.6
Am 2014-10-28 um 20:31 schrieb Karl Heinz Marbaise: Hi, checked SHA1 Ok.. tested 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... Unfortunately the number of checkstyle errors has increased from 29 in version 2.5 to 39 in version 2.6...created an appropriate jira for it http://jira.codehaus.org/browse/MSHARED-380 I'll have a look after the release. Why below 29? Is that a magic number? Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Archiver version 2.6
Am 2014-10-26 um 22:06 schrieb Michael Osipov: Hi, We solved 9 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=18325projectId=11761 There are still a couple of issues left in JIRA: http://jira.codehaus.org/browse/MSHARED-168?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1086/ http://repository.apache.org/content/repositories/maven-1086/org/apache/maven/maven-archiver/2.6/maven-archiver-2.6-source-release.zip Source release checksum(s): maven-archiver-2.6-source-release.zip sha1: 1abc6527f6a3ce037db8c3bc549bb07876f4347a Staging site: http://maven.apache.org/shared-archives/maven-archiver-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. I'll keep the vote another day open because of the interruption in service of RAO. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Who evaluates menu ref=parent|modules / in site.xml?
Am 2014-10-29 um 02:39 schrieb Hervé BOUTEMY: see doxia-integration-tools DefaultSiteTool populateParentMenu(...) [1] and populateModulesMenu(...) [2] called by getDecorationModel(...) then getDecorationModel(...) is called from AbstractSiteRenderingMojo.createSiteRenderingContext(...) But looking at MPIR-279, I fear you're fighting against a non-bug, just some unexpected consequences of not using the standard directory layout from modules (ie directory = artifactId) without manually updating a serie of POM elements which are calculated with the convention Perhaps what can help is documenting what POM elements to be manually defined in case of non-standard module directory path: I never tried to do so, always fighting about what was told as a bug Regards, Hervé [1] http://maven.apache.org/doxia/doxia-tools/doxia-integration-tools/xref/org/apache/maven/doxia/tools/DefaultSiteTool.html#L638 [2] http://maven.apache.org/doxia/doxia-tools/doxia-integration-tools/xref/org/apache/maven/doxia/tools/DefaultSiteTool.html#L733 Salut Hervé, the code snippets look like the stuff I was looking for. I don't think that MPIR-279 follows some non-default layout therefore I have marked two issues as duplicates. I ran into this issue at work, so I have a bigger project to test with. I'll take a look at some demo code in the next couple of days. Thanks for the pointers, Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] removing Maven 3.1.1 from proposed downloads
Am 2014-10-29 um 03:24 schrieb Hervé BOUTEMY: we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3 which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future I see why we would release 3.0.6: Aether change force some users to stay to 3.0.x, and I started to define some backports I'd like to put in it [1] But I don't see why we would release 3.1.2: AFAIK, there is no outstanding change in 3.2.x that blocks 3.1.x users from upgrading to 3.2.x, isn't it? Then IMHO, we should remove 3.1.1 from top download links, and only propose 3.0.5 and 3.2.3 This wouldn't only make our roadmap easier to understand Any objection? While this sounds like a good idea, I am strongly opposed by changing the JDK version or fundemental dependencies (e.g. Aether) in patch versions. This is unexpected behavior. If you have necessary patches for bugs to deliver, do it. But don't EOL 3.1 if you want to upgrade (!) 3.0.x. But yes, if we do not intend to roll 3.1.2, we should send it to end of life officially. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Who evaluates menu ref=parent|modules / in site.xml?
Am 2014-10-29 um 02:39 schrieb Hervé BOUTEMY: see doxia-integration-tools DefaultSiteTool populateParentMenu(...) [1] and populateModulesMenu(...) [2] called by getDecorationModel(...) then getDecorationModel(...) is called from AbstractSiteRenderingMojo.createSiteRenderingContext(...) But looking at MPIR-279, I fear you're fighting against a non-bug, just some unexpected consequences of not using the standard directory layout from modules (ie directory = artifactId) without manually updating a serie of POM elements which are calculated with the convention Perhaps what can help is documenting what POM elements to be manually defined in case of non-standard module directory path: I never tried to do so, always fighting about what was told as a bug I did a code analysis now. At first glace, the SiteTool code is exactly what I need to adapt. The problem lays in the ModulesReport. It should be an exact copy of ref=modules/SiteTool behavior. I'll try a patch to report to the watches, additionally, I'll try to create a IT for that. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Who evaluates menu ref=parent|modules / in site.xml?
Am 2014-10-29 um 22:48 schrieb Barrie Treloar: On 30 October 2014 07:33, Michael Osipov micha...@apache.org wrote: [del] I did a code analysis now. [del] Is that a manual inspection - or are you using tooling? Purely manual - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Release Maven Archiver version 2.6
Hi, The vote has passed with the following result: +1 (binding): Karl Heinz Marbaise, Hervé Boutemy, Kristian Rosenvold +1 (non-binding): Anders Hammar I will promote the artifacts to the central repo. PMCs please promote the source release ZIP file and add this release the board report. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Maven Archiver version 2.6
The Apache Maven team is pleased to announce the release of the Maven Archiver, version 2.6. This module generates browsable HTML pages from Java source code. http://maven.apache.org/shared/maven-archiver/ You should specify the version in your project's dependency configuration: dependency groupIdorg.apache.maven/groupId artifactIdmaven-archiver/artifactId version2.6/version /dependency Release Notes - Maven Archiver - Version 2.6 ** Bug * [MSHARED-241] - Use last plexus-archiver version * [MSHARED-360] - Upgrade plexus-archiver to 2.6.1 (was 2.6) and plexus-utils to 3.0.18 for java7+ symlink support * [MSHARED-368] - Update plexus-interpolation to 1.21 to avoid potential thread safety issues ** Improvement * [MSHARED-224] - Add documentation on the useUniqueVersions to the index page * [MSHARED-270] - Add Implementation-URL to DefaultImplementationEntries * [MSHARED-273] - Update documentation for the Created-By manifest entry * [MSHARED-363] - Update version of plexus-archiver to 2.7 ** Task * [MSHARED-373] - Upgrade Maven baseline to 2.2.1 * [MSHARED-374] - Upgrade Plexus Archiver to 2.8.1 * [MSHARED-375] - Upgrade Plexus Utils to 3.0.20 * [MSHARED-376] - Upgrade Maven Shared Utils to 0.7 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Surefire Plugin version 2.18
Am 2014-10-31 um 09:17 schrieb Hervé BOUTEMY: thank you for the feedback looks like you found issues for MPIR: 1. enhancement, to list only direct modules, not modules of modules MPIR-279. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Help needed with MPIR-279
Hi folks, I have prepared a working branch for that issue but cannot fix a test to pass. It signals a NPE whereas a normal execution works as expected. Is anyone able to figure out the cause? Otherwise I am not able to proceed with this issue. Branch: https://svn.apache.org/repos/asf/maven/plugins/branches/MPIR-279 Thanks, 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
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
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: parent groupIdorg.apache.maven.plugin.projectinfo.tests/groupId artifactIddependency-convergence/artifactId version1.0-SNAPSHOT/version /parent 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: relativePath../dependency-convergence-plugin-config.xml/relativePath 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: 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
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: What do if project.build.sourceEncoding is not provided?
Am 2014-11-14 um 04:02 schrieb Kristian Rosenvold: Isn't this handled by the content-type headers normally ? No, for two reasons: 1. The currect code does not inspect the content type 2. The server does send text/html but not the used encoding which is not necessary because it is located within the file itself The only option would be inspect the content type header and make further assumptions. Michael 2014-11-13 23:15 GMT+01:00 Michael Osipov micha...@apache.org: 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: What do if project.build.sourceEncoding is not provided?
Am 2014-11-14 um 17:47 schrieb Hervé BOUTEMY:
since it is the encoding of a downloaded license, it has nothing to do with
encoding of project sources: using ${project.build.sourceEncoding} is IMHO
wrong algorithm (which happen to give good results since a lot of people use
UTF-8)
then I'd go either for a parameter for the goal, or JSoup that does the magic
to detect effective content encoding
While this seems sound what about if the ressource is plain text and no
encoding can be deduced?
The parameter won't help if there are several licenses with several
encodings used.
Le vendredi 14 novembre 2014 10:37:22 Michael Osipov a écrit :
Am 2014-11-14 um 04:02 schrieb Kristian Rosenvold:
Isn't this handled by the content-type headers normally ?
No, for two reasons:
1. The currect code does not inspect the content type
2. The server does send text/html but not the used encoding which is not
necessary because it is located within the file itself
The only option would be inspect the content type header and make
further assumptions.
Michael
2014-11-13 23:15 GMT+01:00 Michael Osipov micha...@apache.org:
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
-
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
