[RESULT] [VOTE] Release Apache Maven Shared Component: Maven Dependency Analyzer Version 1.6
Hi, The vote has passed with the following result: +1 (binding): Jason van Zyl, Karl Heinz Marbaise, Hervé Boutemy +1 (non binding): Anders Hammar I will promote the artifacts to the central repo. Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Release Apache Maven Shared Component: Maven JarSigner Version 1.4
Hi, The vote has passed with the following result: +1 (binding): Benson Margulies, Hervé Boutemy, Karl Heinz Marbaise +1 (non binding): none I will promote the artifacts to the central repo. Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Releasing the dependency plugin?
Well, you're doing a good job so...;-) /Anders On Wed, Jan 21, 2015 at 10:02 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, So maven-dependency-analyzer is released... Should i start with Maven Dependency Plugin or would someone else take the chance ;-)... Kind regards Karl Heinz Marbaise On 1/18/15 3:04 PM, Karl Heinz Marbaise wrote: Hi, On 1/18/15 2:42 PM, Anders Hammar wrote: MDEP-466 [1] is the regression I was talking about. The issue has been fixed in source but it requires a new release of maven-dependency-analyzer. Ok...Than i will start VOTE for maven-dependency-analyzer... First ... [1] https://jira.codehaus.org/browse/MDEP-466 /Anders On Sun, Jan 18, 2015 at 10:22 AM, Anders Hammar and...@hammar.net mailto:and...@hammar.net wrote: There's a regression in the last release that would be great to have fixed as well. I'm not by a computer right now though to dig up the jira. /Anders (mobile) Den 17 jan 2015 09:41 skrev Karl Heinz Marbaise khmarba...@gmx.de mailto:khmarba...@gmx.de: Hi, On 1/17/15 6:16 AM, Henning Schmiedehausen wrote: Hi, any chance to do a dependency plugin release? Just release it or special issue to be fixed ?
[ANN] Apache Maven Shared Component: Maven JarSigner Version 1.4 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shared Component: Maven JarSigner Version 1.4 This component provides some utilities to sign/verify jars/files in your Mojos. http://maven.apache.org/shared/maven-jarsigner/ You should specify the version in your project's dependency list: dependency groupIdorg.apache.maven.shared/groupId artifactIdmaven-jarsigner/artifactId version1.4/version /dependency Release Notes - Maven JarSigner Version 1.4 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761version=19864 Improvements: * [MSHARED-371] - Increase chance of java8 compliance by updating to plexus-component-* 1.6 * [MSHARED-395] - Upgrade to Maven 2.2.1 compatiblity * [MSHARED-397] - Upgrade maven-shared-utils to 0.7 * [MSHARED-398] - Removed dependency plexus-container-default:1.0-alpha-9-stable-1 Enjoy, -The Apache Maven team Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Apache Maven Shared Component: Maven Dependency Analzyer Version 1.6 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shared Component: Maven Dependency Analyzer Version 1.6 Analyzes the dependencies of a project for undeclared or unused artifacts. http://maven.apache.org/shared/maven-dependency-analyzer/ You should specify the version in your project's dependency list: dependency groupIdorg.apache.maven.shared/groupId artifactIdmaven-dependency-analyzer/artifactId version1.6/version /dependency Release Notes - Maven Dependency Analzyer Version 1.6 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761version=20721 Bugs: * [MSHARED-361] - DefaultProjectDependencyAnalyzer.buildArtifactClassMap assumes dependencies are jar files (regression) * [MSHARED-382] - JarFile object is not being closed Improvement: * [MSHARED-371] - Increase chance of java8 compliance by updating to plexus-component-* 1.6 Enjoy, -The Apache Maven team Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Apache Maven JarSigner Plugin version 1.4
Hi, We solved 5 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11990version=19865 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=XXXstatus=1 Staging repo: https://repository.apache.org/content/repositories/maven-1128/ https://repository.apache.org/content/repositories/maven-1128/org/apache/maven/plugins/maven-jarsigner-plugin/1.4/maven-jarsigner-plugin-1.4-source-release.zip Source release checksum(s): maven-jarsigner-plugin-source-release.zip sha1: b8ae60a45abe11c4c6b8befaf077e0fa47bc9107 Staging site: http://maven.apache.org/plugins-archives/maven-jarsigner-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 Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Apache Maven JarSigner Plugin version 1.4
Hi, We solved 5 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11990version=19865 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=XXXstatus=1 Staging repo: https://repository.apache.org/content/repositories/maven-1128/ https://repository.apache.org/content/repositories/maven-1128/org/apache/maven/plugins/maven-jarsigner-plugin/1.4/maven-jarsigner-plugin-1.4-source-release.zip Source release checksum(s): maven-jarsigner-plugin-source-release.zip sha1: b8ae60a45abe11c4c6b8befaf077e0fa47bc9107 Staging site: http://maven.apache.org/plugins-archives/maven-jarsigner-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 Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Releasing the dependency plugin?
Hi, So maven-dependency-analyzer is released... Should i start with Maven Dependency Plugin or would someone else take the chance ;-)... Kind regards Karl Heinz Marbaise On 1/18/15 3:04 PM, Karl Heinz Marbaise wrote: Hi, On 1/18/15 2:42 PM, Anders Hammar wrote: MDEP-466 [1] is the regression I was talking about. The issue has been fixed in source but it requires a new release of maven-dependency-analyzer. Ok...Than i will start VOTE for maven-dependency-analyzer... First ... [1] https://jira.codehaus.org/browse/MDEP-466 /Anders On Sun, Jan 18, 2015 at 10:22 AM, Anders Hammar and...@hammar.net mailto:and...@hammar.net wrote: There's a regression in the last release that would be great to have fixed as well. I'm not by a computer right now though to dig up the jira. /Anders (mobile) Den 17 jan 2015 09:41 skrev Karl Heinz Marbaise khmarba...@gmx.de mailto:khmarba...@gmx.de: Hi, On 1/17/15 6:16 AM, Henning Schmiedehausen wrote: Hi, any chance to do a dependency plugin release? Just release it or special issue to be fixed ? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Apache Maven Dependency Plugin version 2.10
Hi, We solved 9 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11214version=20646 There are still a couple of issues left in JIRA: https://jira.codehaus.org/issues/?jql=project%20%3D%20MDEP%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1131 https://repository.apache.org/content/repositories/maven-1131/org/apache/maven/plugins/maven-dependency-plugin/2.10/maven-dependency-plugin-2.10-source-release.zip Source release checksum(s): maven-dependency-plugin-2.10-source-release.zip sha1: 8efe98c98bc0804fa8eea602a813374a8a1e1c74 Staging site: http://maven.apache.org/plugins-archives/maven-dependency-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 Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Releasing the dependency plugin?
Hi Anders, On 1/21/15 10:05 PM, Anders Hammar wrote: Well, you're doing a good job so...;-) Ok Ok...I'll take it ;-)... Karl Heinz /Anders On Wed, Jan 21, 2015 at 10:02 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, So maven-dependency-analyzer is released... Should i start with Maven Dependency Plugin or would someone else take the chance ;-)... Kind regards Karl Heinz Marbaise On 1/18/15 3:04 PM, Karl Heinz Marbaise wrote: Hi, On 1/18/15 2:42 PM, Anders Hammar wrote: MDEP-466 [1] is the regression I was talking about. The issue has been fixed in source but it requires a new release of maven-dependency-analyzer. Ok...Than i will start VOTE for maven-dependency-analyzer... First ... [1] https://jira.codehaus.org/browse/MDEP-466 /Anders On Sun, Jan 18, 2015 at 10:22 AM, Anders Hammar and...@hammar.net mailto:and...@hammar.net wrote: There's a regression in the last release that would be great to have fixed as well. I'm not by a computer right now though to dig up the jira. /Anders (mobile) Den 17 jan 2015 09:41 skrev Karl Heinz Marbaise khmarba...@gmx.de mailto:khmarba...@gmx.de: Hi, On 1/17/15 6:16 AM, Henning Schmiedehausen wrote: Hi, any chance to do a dependency plugin release? Just release it or special issue to be fixed ? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven-surefire pull request: SUREFIRE-1136 Current working directo...
GitHub user norbertwnuk opened a pull request: https://github.com/apache/maven-surefire/pull/82 SUREFIRE-1136 Current working directory propagation in forked mode remove JDK 1.7 API usages in tests, integration test extended to justify deferred directory creation in AbstractSurefireMojo.ensureWorkingDirectoryExists You can merge this pull request into a Git repository by running: $ git pull https://github.com/norbertwnuk/maven-surefire SUREFIRE-1136 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-surefire/pull/82.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #82 commit 15da3495d5c7be46cf247e4edc0d0c519f1848b6 Author: Norbert Wnuk norbert.w...@sabre.com Date: 2015-01-21T23:53:02Z SUREFIRE-1136 Current working directory propagation in forked mode - remove JDK 1.7 API usage in tests, integration test extended to justify deferred directory creation in AbstractSurefireMojo.ensureWorkingDirectoryExists --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven pull request: [MNG-5686] Use /usr/libexec/java_home to find ...
GitHub user ecki opened a pull request: https://github.com/apache/maven/pull/35 [MNG-5686] Use /usr/libexec/java_home to find JAVA_HOME This fixes the /usr/libexec/java_home choser (OSX) for the main script and adds the missing section to the other tows (ASF Commiter Signoff: ecki) You can merge this pull request into a Git repository by running: $ git pull https://github.com/ecki/maven mng-5686 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven/pull/35.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #35 commit fbd6e53e838d3c77d689adeae19fa6de6ecc050f Author: Bernd Eckenfels be...@eckenfels.net Date: 2015-01-21T23:54:33Z [MNG-5686] Use /usr/libexec/java_home to find JAVA_HOME --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Surefire Plugin does not handle workingDirectory in fork mode properly
Pull request with the fix - https://github.com/apache/maven-surefire/pull/82 NW On Wed, Jan 21, 2015 at 9:27 PM, Tibor Digana tibordig...@apache.org wrote: This is a traditional problem with animal-sniffer-maven-plugin. We had the same issue in JUnit project. Alrerady reported in JIRA http://jira.codehaus.org/browse/MANIMALSNIFFER-54 http://jira.codehaus.org/browse/MANIMALSNIFFER-40 I would like to have the check-test goal or a new parameter. It's still assigned to @stephenc. I would appreciate it working and utilized in Maven and JUnit projects. -- View this message in context: http://maven.40175.n5.nabble.com/Surefire-Plugin-does-not-handle-workingDirectory-in-fork-mode-properly-tp5824054p5824348.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: problem with AAR dependency
On Jan 20, 2015, at 6:03 PM, William Ferguson william.fergu...@xandar.com.au wrote: Been thinking about this a little more. The TLDR version: I am suggesting that we provide more information and place a stricter syntax requirement of the POM *generated* by the build. This allows the generated POM to be a clear contract between the deployed artifact and it's consumers, regardless of which build system is consuming the artifact. ... Our problem: POMs provided by the Android support repo contain dependencies that have no type information which is syntactically valid. But the dependencies are assumed to be 'aar' resources by Gradle but not by Maven. We need the correct type information to be provided with the dependency. We have to make a strict requirement for type information because the Android SDK team isn't going to help the Maven community have POMs that are correct? Really? We don't actually need the *source* POM syntax to change to require types to be specified for all dependencies. We would just need the POM that is generated as part of the build (ie output POM) include type for each dependency. For Maven this would mean adding a type of 'jar' for any missing types into the generated POM. In our use case this would mean that the POMs being generated by the Android team could be identified as being invalid as they are missing type information. And the Android team were to fix them up and include type information then they would include the correct type info 'aar' and we could build our projects without needing to manually hack 2 dozen POMs they are providing. It would also allow us to confirm that the generated POM is valid during - dependency consumption - deployment to Maven central @Jason where is the generated POM (think you had another name for it) concept at? We called it the consumer POM in the hangout. Does this suggestion fit in with your thoughts on it? Can we not just make a tool that corrects all the POMs by augmenting the tool that already exists? William ᐧ On Sat, Dec 20, 2014 at 11:59 AM, William Ferguson william.fergu...@xandar.com.au wrote: It's not the repository layout that Google is not honouring. It's the semantics of the unspecified dependency type in the POMs in that repository. If the POM syntax were changed to require that deps had a type then Maven itself could fail the build because it could determine that the inputs were invalid. And yes, this wouldn't stop Google from publishing a POM that had incorrect dependency types (eg explicitly specifying jar type when no such artifact exists), but at that point it is an explicit choice during construction and it is clear where the fault lies. NB this is all caused by a bug in Gradle http://forums.gradle.org/gradle/topics/missing-in-deployed-pom-files-if-different-than-jar-artifact-is-used Here is the report against AOSP https://code.google.com/p/android/issues/detail?id=72807 While this isn't a bug in Maven, Maven owns the POM format. By not placing stricter controls around the ecosystem we are letting that ecosystem deteriorate. I don't want to see Maven slide into oblivion because new tools/processes are pissing into the common pot. At the very least it would help if the community starred the Gradle issue to try to get them to fix their problem. [image: photo] *William Ferguson* Founder and CEO, XandarMob m:+61 425 716 870 +61%20425%20716%20870 | e: william.fergu...@xandar.com.au | w:https://wylas-timing.com http://lexathon.com ᐧ On Sat, Dec 20, 2014 at 9:13 AM, Igor Fedorenko i...@ifedorenko.com wrote: On 2014-12-19, 17:40, William Ferguson wrote: I'd love to go the first route, but unfortunately Google is only making the Android libraries available via a repository that is downloaded (and updated) via the Android SDK. So they are not visible on Maven Central and Maven Central obviously couldn't vet them. If Google deploys these artifacts to a separate repository and does not honour current Maven repository layout, why do you think they will treat the new layout differently? The second option would work, but I'd argue that it lends itself to convention clouding the expected behaviour as you'd need a map to know how each packaging type impacted the behaviour of unspecified dependency types. UNLESS the convention was that all dependencies with no type information get the packaging type of their project. But this would massively break existing build (think of all the war POMs). No, I didn't mean to use project packaging type as default type for all dependencies. I meant to associate default dependency type with project packaging type. Packaging type, or, rather, build extension that defines the packaging type, can provide the default value. Theoretically, Maven could use components from the build extensions to during dependency resolution. Another option, if all these
Re: Releasing the Checkstyle Plugin
Le mercredi 21 janvier 2015 14:44:27 Dennis Lundberg a écrit : There is some piece of code in Checkstyle 5.9 that uses Java 6+ classes/methods. I don't remember where, but it isn't covered by our integration tests. since our ITs use the 3 integrated rulesets, I suppose this is in a rule that isn't used by these rulesets Notice: the animalsniffer check you added doesn't check dependency jars full content? I'll have a look at it tomorrow evening, and see if I can produce an IT that catches it. yes, and if we find it, we'll open an issue to Checkstyle since that was not supposed to happen: that's what's told on release notes for Checkstyle 6.0 Another thing that I have been thinking about is whether we should move maven_checks.xml out of maven-checkstyle-plugin and into a separate resource jar. The rationale being that we (the Maven project) will probably be stuck using maven-checkstyle-plugin 2.14 (for Java 5 projects) and 2.15 (for Java 6 projects) just for sake of discussion about minimum Maven and Java requirements, I'd say it as: - maven-checkstyle-plugin 2.14 for projects built with Maven 2.2.1+Java 5 requirements - maven-checkstyle-plugin 2.15 (or 3.0) for projects built with Maven 3+Java 6 requirement, which is our next plugin requirement level (and associated numbering) . What happens when 2.16 is released and we want to change maven_checks.xml? I don't like the idea to have a plugin forcing Java requirement upgrade, especially when mostly a reporting plugin (since not everybody do Checkstyle checked builds) But that's another discussion: to be done later yes, moving maven_checks.xml out of the plugin would be a solution. For our Maven projects, moving the file to Maven parent POM would be IMHO a good target: that's what others are supposed to do when they write their own ruleset, then why don't we do the same? Since Checkstyle 6.2 provides Sun (and Google) rulesets (see MCHECKSTYLE-268), removing maven_checks while removing sun_checks would fit, IMHO And this could even fix my previous comment on 2.16: IMHO, our plugin should stay with Checkstyle 6.1 as default since it is the last with Java 6 requirement, and end-users can upgrade Checkstyle independently as they want then definitely, yes, moving maven_checks.xml out of maven-checkstyle-plugin is definitely a good plan to me Just avoid a new resource jar: just use Maven parent POM. Regards, Hervé On Wed, Jan 21, 2015 at 9:04 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le vendredi 9 janvier 2015 13:29:06 Dennis Lundberg a écrit : I've started going through the open issues and have found a problem that I need som help with. It turns out that Checkstyle 5.9 uses Java 6 classes, even though it is not mentioned in the release notes. How do we want to handle this? I see two possible options: 1. Make version 2.14 of the plugin require Java 6, and update it to use the latest available version of Checkstyle that runs on Java 6. 2. Revert the plugin back to Checkstyle 5.8 and release 2.14 of the plugin with a Java 5 requirement. After that release 2.15 of the plugin fairly straight away with a Java 6 requirement, and using the latest available version of Checkstyle that runs on Java 6. It should be noted that Checkstyle 5.8 does NOT work on Java 8 source code. Perhaps there are other alternatives? What do you think? I just built and ran ITs with Checkstyle 5.9 on JDK5 without any issue: can you check too? Since Checkstyle 5.9 supports Java 8 syntax, upgrading would be really great while keeping our plan for minimum Java version This is key before releasing Everyting else I wanted to fix/improve for the next release is done I'll be happy to vote on a release I'm not managing myself :) Regards, Hervé On Thu, Jan 8, 2015 at 3:51 PM, Dennis Lundberg denn...@apache.org wrote: Hi, I'd like to release version 2.14 of Maven Checkstyle Plugin. The main motive for 2.14 is the ability to check Java 8 source code. According to the road map there are 5 unresolved issues scheduled for 2.14. https://jira.codehaus.org/browse/MCHECKSTYLE#selectedTab=com.atlassian. jir a.plugin.system.project%3Aroadmap-panel If anyone is interested in fixing one or more of these for 2.14 now would be a good time to do it. Just reply here with an estimated time frame. If noone has the time for this now, I'll reschedule those issues for 2.15, which will require Java 6. -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Dev Hangout Topics
Can anyone talk about the meta datas inside the repository? Such as, who is responsible(repository manager or specific plugins) to generate which? Which plugin will use what meta data resouces? How? etc. Thanks Guo Yingshou On Wed, Jan 21, 2015 at 11:14 PM, Jason van Zyl ja...@takari.io wrote: Anyone have anything they want me to throw on the list. So far we have: - Henning and the Basepom project - Igor talking about how to develop Maven plugins in M2E - Jason talking about better configuration for Maven plugins Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - A master in the art of living draws no sharp distinction between his work and his play; his labor and his leisure; his mind and his body; his education and his recreation. He hardly knows which is which. He simply pursues his vision of excellence through whatever he is doing, and leaves others to determine whether he is working or playing. To himself, he always appears to be doing both. -- François-René de Chateaubriand - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: problem with AAR dependency
Well, at the moment it's the Android SDK team, but in the future it could be anybody. I look at the deployed POMs are as form of contract between the deployed artifact and it's consumers. So when the contract isn't explicit (eg dependency type info) then its open to misinterpretation. Maven convention is 'jar' as the dependency type and that's convenient when declaring a POM as it makes it smaller (when there are mainly jar dependencies) and easier for a human to get their head around. But it's inconvenient in a generated POM (which is machine constructed and largely machine read) because it creates ambiguity. Especially as more/different tools make use of Maven repositories and as other artifacts types dilute the existing high concentration of Java artifacts. And being too Java centric is one of the reasons that Maven adoption hasn't been more widespread. For what it's worth, I think dependency type should only be the first plank of the deployed POM that we should lock down better. ᐧ On Thu, Jan 22, 2015 at 12:13 PM, Jason van Zyl ja...@takari.io wrote: On Jan 20, 2015, at 6:03 PM, William Ferguson william.fergu...@xandar.com.au wrote: Been thinking about this a little more. The TLDR version: I am suggesting that we provide more information and place a stricter syntax requirement of the POM *generated* by the build. This allows the generated POM to be a clear contract between the deployed artifact and it's consumers, regardless of which build system is consuming the artifact. ... Our problem: POMs provided by the Android support repo contain dependencies that have no type information which is syntactically valid. But the dependencies are assumed to be 'aar' resources by Gradle but not by Maven. We need the correct type information to be provided with the dependency. We have to make a strict requirement for type information because the Android SDK team isn't going to help the Maven community have POMs that are correct? Really? We don't actually need the *source* POM syntax to change to require types to be specified for all dependencies. We would just need the POM that is generated as part of the build (ie output POM) include type for each dependency. For Maven this would mean adding a type of 'jar' for any missing types into the generated POM. In our use case this would mean that the POMs being generated by the Android team could be identified as being invalid as they are missing type information. And the Android team were to fix them up and include type information then they would include the correct type info 'aar' and we could build our projects without needing to manually hack 2 dozen POMs they are providing. It would also allow us to confirm that the generated POM is valid during - dependency consumption - deployment to Maven central @Jason where is the generated POM (think you had another name for it) concept at? We called it the consumer POM in the hangout. Does this suggestion fit in with your thoughts on it? Can we not just make a tool that corrects all the POMs by augmenting the tool that already exists? William ᐧ On Sat, Dec 20, 2014 at 11:59 AM, William Ferguson william.fergu...@xandar.com.au wrote: It's not the repository layout that Google is not honouring. It's the semantics of the unspecified dependency type in the POMs in that repository. If the POM syntax were changed to require that deps had a type then Maven itself could fail the build because it could determine that the inputs were invalid. And yes, this wouldn't stop Google from publishing a POM that had incorrect dependency types (eg explicitly specifying jar type when no such artifact exists), but at that point it is an explicit choice during construction and it is clear where the fault lies. NB this is all caused by a bug in Gradle http://forums.gradle.org/gradle/topics/missing-in-deployed-pom-files-if-different-than-jar-artifact-is-used Here is the report against AOSP https://code.google.com/p/android/issues/detail?id=72807 While this isn't a bug in Maven, Maven owns the POM format. By not placing stricter controls around the ecosystem we are letting that ecosystem deteriorate. I don't want to see Maven slide into oblivion because new tools/processes are pissing into the common pot. At the very least it would help if the community starred the Gradle issue to try to get them to fix their problem. [image: photo] *William Ferguson* Founder and CEO, XandarMob m:+61 425 716 870 +61%20425%20716%20870 | e: william.fergu...@xandar.com.au | w:https://wylas-timing.com http://lexathon.com ᐧ On Sat, Dec 20, 2014 at 9:13 AM, Igor Fedorenko i...@ifedorenko.com wrote: On 2014-12-19, 17:40, William Ferguson wrote: I'd love to go the first route, but unfortunately Google is only making the Android libraries available via a
Re: Releasing the Checkstyle Plugin
On Thu, Jan 22, 2015 at 5:29 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le mercredi 21 janvier 2015 14:44:27 Dennis Lundberg a écrit : There is some piece of code in Checkstyle 5.9 that uses Java 6+ classes/methods. I don't remember where, but it isn't covered by our integration tests. since our ITs use the 3 integrated rulesets, I suppose this is in a rule that isn't used by these rulesets Notice: the animalsniffer check you added doesn't check dependency jars full content? No, and I don't think we can get that from our end. We had newer Java versions leaking into Apache Rat, and I solved those by adding a combination of animal-sniffer and enforcer plugin. But I don't think that can check the sources of the dependencies. It's a mystery to me how they managed to build Checkstyle 5.9 at all. When I check out the 5.9 tag from git and try to build it using Java 1.5 I get these errors: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project checkstyle: Compilation failure: Compilation failure: [ERROR] \Users\dlg01\git\checkstyle\src\main\java\com\puppycrawl\tools\checkstyle\checks\DeclarationCollector.java:[29,17] cannot find symbol [ERROR] symbol : class Deque [ERROR] location: package java.util [ERROR] \Users\dlg01\git\checkstyle\src\main\java\com\puppycrawl\tools\checkstyle\checks\DeclarationCollector.java:[99,37] cannot find symbol [ERROR] symbol : class Deque [ERROR] location: class com.puppycrawl.tools.checkstyle.checks.DeclarationCollector [ERROR] \Users\dlg01\git\checkstyle\src\main\java\com\puppycrawl\tools\checkstyle\checks\coding\VariableDeclarationUsageDistanceCheck.java:[21,29] java.util.AbstractMap.SimpleEntry is not public in java.util.AbstractMap; cannot be accessed from outside package [ERROR] \Users\dlg01\git\checkstyle\src\main\java\com\puppycrawl\tools\checkstyle\checks\indentation\LineWrappingHandler.java:[23,17] cannot find symbol [ERROR] symbol : class NavigableMap [ERROR] location: package java.util [ERROR] \Users\dlg01\git\checkstyle\src\main\java\com\puppycrawl\tools\checkstyle\checks\indentation\LineWrappingHandler.java:[188,12] cannot find symbol [ERROR] symbol : class NavigableMap [ERROR] location: class com.puppycrawl.tools.checkstyle.checks.indentation.LineWrappingHandler [ERROR] \Users\dlg01\git\checkstyle\src\main\java\com\puppycrawl\tools\checkstyle\checks\indentation\LineWrappingHandler.java:[244,12] cannot find symbol [ERROR] symbol : class NavigableMap [ERROR] location: class com.puppycrawl.tools.checkstyle.checks.indentation.LineWrappingHandler [ERROR] \Users\dlg01\git\checkstyle\src\main\java\com\puppycrawl\tools\checkstyle\checks\whitespace\EmptyLineSeparatorCheck.java:[208,30] cannot find symbol [ERROR] symbol : method isEmpty() [ERROR] location: class java.lang.String [ERROR] \Users\dlg01\git\checkstyle\src\main\java\com\puppycrawl\tools\checkstyle\checks\indentation\LineWrappingHandler.java:[119,14] cannot find symbol [ERROR] symbol : class NavigableMap [ERROR] location: class com.puppycrawl.tools.checkstyle.checks.indentation.LineWrappingHandler [ERROR] \Users\dlg01\git\checkstyle\src\main\java\com\puppycrawl\tools\checkstyle\checks\indentation\LineWrappingHandler.java:[190,14] cannot find symbol [ERROR] symbol : class NavigableMap [ERROR] location: class com.puppycrawl.tools.checkstyle.checks.indentation.LineWrappingHandler [ERROR] \Users\dlg01\git\checkstyle\src\main\java\com\puppycrawl\tools\checkstyle\checks\DeclarationCollector.java:[55,14] cannot find symbol [ERROR] symbol : class Deque [ERROR] location: class com.puppycrawl.tools.checkstyle.checks.DeclarationCollector [ERROR] \Users\dlg01\git\checkstyle\src\main\java\com\puppycrawl\tools\checkstyle\checks\coding\VariableDeclarationUsageDistanceCheck.java:[348,36] cannot find symbol [ERROR] symbol : method isEmpty() [ERROR] location: class java.lang.String [ERROR] \Users\dlg01\git\checkstyle\src\main\java\com\puppycrawl\tools\checkstyle\checks\coding\VariableDeclarationUsageDistanceCheck.java:[353,45] cannot find symbol [ERROR] symbol : method isEmpty() [ERROR] location: class java.lang.String [ERROR] \Users\dlg01\git\checkstyle\src\main\java\com\puppycrawl\tools\checkstyle\checks\coding\VariableDeclarationUsageDistanceCheck.java:[453,19] cannot find symbol [ERROR] symbol : class SimpleEntry [ERROR] location: class com.puppycrawl.tools.checkstyle.checks.coding.VariableDeclarationUsageDistanceCheck [ERROR] \Users\dlg01\git\checkstyle\src\main\java\com\puppycrawl\tools\checkstyle\checks\coding\VariableDeclarationUsageDistanceCheck.java:[544,19] cannot find symbol [ERROR] symbol : class SimpleEntry [ERROR] location: class com.puppycrawl.tools.checkstyle.checks.coding.VariableDeclarationUsageDistanceCheck [ERROR] \Users\dlg01\git\checkstyle\src\main\java\com\puppycrawl\tools\checkstyle\checks\imports\CustomImportOrderCheck.java:[616,30] cannot find symbol [ERROR] symbol : method isEmpty() [ERROR] location:
Re: Surefire Plugin does not handle workingDirectory in fork mode properly
This is a traditional problem with animal-sniffer-maven-plugin. We had the same issue in JUnit project. Alrerady reported in JIRA http://jira.codehaus.org/browse/MANIMALSNIFFER-54 http://jira.codehaus.org/browse/MANIMALSNIFFER-40 I would like to have the check-test goal or a new parameter. It's still assigned to @stephenc. I would appreciate it working and utilized in Maven and JUnit projects. -- View this message in context: http://maven.40175.n5.nabble.com/Surefire-Plugin-does-not-handle-workingDirectory-in-fork-mode-properly-tp5824054p5824348.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Releasing the Checkstyle Plugin
Le vendredi 9 janvier 2015 13:29:06 Dennis Lundberg a écrit : I've started going through the open issues and have found a problem that I need som help with. It turns out that Checkstyle 5.9 uses Java 6 classes, even though it is not mentioned in the release notes. How do we want to handle this? I see two possible options: 1. Make version 2.14 of the plugin require Java 6, and update it to use the latest available version of Checkstyle that runs on Java 6. 2. Revert the plugin back to Checkstyle 5.8 and release 2.14 of the plugin with a Java 5 requirement. After that release 2.15 of the plugin fairly straight away with a Java 6 requirement, and using the latest available version of Checkstyle that runs on Java 6. It should be noted that Checkstyle 5.8 does NOT work on Java 8 source code. Perhaps there are other alternatives? What do you think? I just built and ran ITs with Checkstyle 5.9 on JDK5 without any issue: can you check too? Since Checkstyle 5.9 supports Java 8 syntax, upgrading would be really great while keeping our plan for minimum Java version This is key before releasing Everyting else I wanted to fix/improve for the next release is done I'll be happy to vote on a release I'm not managing myself :) Regards, Hervé On Thu, Jan 8, 2015 at 3:51 PM, Dennis Lundberg denn...@apache.org wrote: Hi, I'd like to release version 2.14 of Maven Checkstyle Plugin. The main motive for 2.14 is the ability to check Java 8 source code. According to the road map there are 5 unresolved issues scheduled for 2.14. https://jira.codehaus.org/browse/MCHECKSTYLE#selectedTab=com.atlassian.jir a.plugin.system.project%3Aroadmap-panel If anyone is interested in fixing one or more of these for 2.14 now would be a good time to do it. Just reply here with an estimated time frame. If noone has the time for this now, I'll reschedule those issues for 2.15, which will require Java 6. -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Releasing the Checkstyle Plugin
There is some piece of code in Checkstyle 5.9 that uses Java 6+ classes/methods. I don't remember where, but it isn't covered by our integration tests. I'll have a look at it tomorrow evening, and see if I can produce an IT that catches it. Another thing that I have been thinking about is whether we should move maven_checks.xml out of maven-checkstyle-plugin and into a separate resource jar. The rationale being that we (the Maven project) will probably be stuck using maven-checkstyle-plugin 2.14 (for Java 5 projects) and 2.15 (for Java 6 projects). What happens when 2.16 is released and we want to change maven_checks.xml? On Wed, Jan 21, 2015 at 9:04 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le vendredi 9 janvier 2015 13:29:06 Dennis Lundberg a écrit : I've started going through the open issues and have found a problem that I need som help with. It turns out that Checkstyle 5.9 uses Java 6 classes, even though it is not mentioned in the release notes. How do we want to handle this? I see two possible options: 1. Make version 2.14 of the plugin require Java 6, and update it to use the latest available version of Checkstyle that runs on Java 6. 2. Revert the plugin back to Checkstyle 5.8 and release 2.14 of the plugin with a Java 5 requirement. After that release 2.15 of the plugin fairly straight away with a Java 6 requirement, and using the latest available version of Checkstyle that runs on Java 6. It should be noted that Checkstyle 5.8 does NOT work on Java 8 source code. Perhaps there are other alternatives? What do you think? I just built and ran ITs with Checkstyle 5.9 on JDK5 without any issue: can you check too? Since Checkstyle 5.9 supports Java 8 syntax, upgrading would be really great while keeping our plan for minimum Java version This is key before releasing Everyting else I wanted to fix/improve for the next release is done I'll be happy to vote on a release I'm not managing myself :) Regards, Hervé On Thu, Jan 8, 2015 at 3:51 PM, Dennis Lundberg denn...@apache.org wrote: Hi, I'd like to release version 2.14 of Maven Checkstyle Plugin. The main motive for 2.14 is the ability to check Java 8 source code. According to the road map there are 5 unresolved issues scheduled for 2.14. https://jira.codehaus.org/browse/MCHECKSTYLE#selectedTab=com.atlassian.jir a.plugin.system.project%3Aroadmap-panel If anyone is interested in fixing one or more of these for 2.14 now would be a good time to do it. Just reply here with an estimated time frame. If noone has the time for this now, I'll reschedule those issues for 2.15, which will require Java 6. -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Releasing the Checkstyle Plugin
I'm confused. The current version of checkstyle is 6.2. Why is this discussion about 5.9? Should we make a branch that requires java whatever and is actually current? On Wed, Jan 21, 2015 at 8:44 AM, Dennis Lundberg denn...@apache.org wrote: There is some piece of code in Checkstyle 5.9 that uses Java 6+ classes/methods. I don't remember where, but it isn't covered by our integration tests. I'll have a look at it tomorrow evening, and see if I can produce an IT that catches it. Another thing that I have been thinking about is whether we should move maven_checks.xml out of maven-checkstyle-plugin and into a separate resource jar. The rationale being that we (the Maven project) will probably be stuck using maven-checkstyle-plugin 2.14 (for Java 5 projects) and 2.15 (for Java 6 projects). What happens when 2.16 is released and we want to change maven_checks.xml? On Wed, Jan 21, 2015 at 9:04 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le vendredi 9 janvier 2015 13:29:06 Dennis Lundberg a écrit : I've started going through the open issues and have found a problem that I need som help with. It turns out that Checkstyle 5.9 uses Java 6 classes, even though it is not mentioned in the release notes. How do we want to handle this? I see two possible options: 1. Make version 2.14 of the plugin require Java 6, and update it to use the latest available version of Checkstyle that runs on Java 6. 2. Revert the plugin back to Checkstyle 5.8 and release 2.14 of the plugin with a Java 5 requirement. After that release 2.15 of the plugin fairly straight away with a Java 6 requirement, and using the latest available version of Checkstyle that runs on Java 6. It should be noted that Checkstyle 5.8 does NOT work on Java 8 source code. Perhaps there are other alternatives? What do you think? I just built and ran ITs with Checkstyle 5.9 on JDK5 without any issue: can you check too? Since Checkstyle 5.9 supports Java 8 syntax, upgrading would be really great while keeping our plan for minimum Java version This is key before releasing Everyting else I wanted to fix/improve for the next release is done I'll be happy to vote on a release I'm not managing myself :) Regards, Hervé On Thu, Jan 8, 2015 at 3:51 PM, Dennis Lundberg denn...@apache.org wrote: Hi, I'd like to release version 2.14 of Maven Checkstyle Plugin. The main motive for 2.14 is the ability to check Java 8 source code. According to the road map there are 5 unresolved issues scheduled for 2.14. https://jira.codehaus.org/browse/MCHECKSTYLE#selectedTab=com.atlassian.jir a.plugin.system.project%3Aroadmap-panel If anyone is interested in fixing one or more of these for 2.14 now would be a good time to do it. Just reply here with an estimated time frame. If noone has the time for this now, I'll reschedule those issues for 2.15, which will require Java 6. -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - 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: Releasing the Checkstyle Plugin
Benson, please have a look at the road map in JIRA. The talk about Checkstyle 5.9 regards the 2.14 release that we have been preparing for during the last couple of weeks. On Wed, Jan 21, 2015 at 2:52 PM, Benson Margulies bimargul...@gmail.com wrote: I'm confused. The current version of checkstyle is 6.2. Why is this discussion about 5.9? Should we make a branch that requires java whatever and is actually current? On Wed, Jan 21, 2015 at 8:44 AM, Dennis Lundberg denn...@apache.org wrote: There is some piece of code in Checkstyle 5.9 that uses Java 6+ classes/methods. I don't remember where, but it isn't covered by our integration tests. I'll have a look at it tomorrow evening, and see if I can produce an IT that catches it. Another thing that I have been thinking about is whether we should move maven_checks.xml out of maven-checkstyle-plugin and into a separate resource jar. The rationale being that we (the Maven project) will probably be stuck using maven-checkstyle-plugin 2.14 (for Java 5 projects) and 2.15 (for Java 6 projects). What happens when 2.16 is released and we want to change maven_checks.xml? On Wed, Jan 21, 2015 at 9:04 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le vendredi 9 janvier 2015 13:29:06 Dennis Lundberg a écrit : I've started going through the open issues and have found a problem that I need som help with. It turns out that Checkstyle 5.9 uses Java 6 classes, even though it is not mentioned in the release notes. How do we want to handle this? I see two possible options: 1. Make version 2.14 of the plugin require Java 6, and update it to use the latest available version of Checkstyle that runs on Java 6. 2. Revert the plugin back to Checkstyle 5.8 and release 2.14 of the plugin with a Java 5 requirement. After that release 2.15 of the plugin fairly straight away with a Java 6 requirement, and using the latest available version of Checkstyle that runs on Java 6. It should be noted that Checkstyle 5.8 does NOT work on Java 8 source code. Perhaps there are other alternatives? What do you think? I just built and ran ITs with Checkstyle 5.9 on JDK5 without any issue: can you check too? Since Checkstyle 5.9 supports Java 8 syntax, upgrading would be really great while keeping our plan for minimum Java version This is key before releasing Everyting else I wanted to fix/improve for the next release is done I'll be happy to vote on a release I'm not managing myself :) Regards, Hervé On Thu, Jan 8, 2015 at 3:51 PM, Dennis Lundberg denn...@apache.org wrote: Hi, I'd like to release version 2.14 of Maven Checkstyle Plugin. The main motive for 2.14 is the ability to check Java 8 source code. According to the road map there are 5 unresolved issues scheduled for 2.14. https://jira.codehaus.org/browse/MCHECKSTYLE#selectedTab=com.atlassian.jir a.plugin.system.project%3Aroadmap-panel If anyone is interested in fixing one or more of these for 2.14 now would be a good time to do it. Just reply here with an estimated time frame. If noone has the time for this now, I'll reschedule those issues for 2.15, which will require Java 6. -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - 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 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Maven Dev Hangout Topics
Anyone have anything they want me to throw on the list. So far we have: - Henning and the Basepom project - Igor talking about how to develop Maven plugins in M2E - Jason talking about better configuration for Maven plugins Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - A master in the art of living draws no sharp distinction between his work and his play; his labor and his leisure; his mind and his body; his education and his recreation. He hardly knows which is which. He simply pursues his vision of excellence through whatever he is doing, and leaves others to determine whether he is working or playing. To himself, he always appears to be doing both. -- François-René de Chateaubriand - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
