Re: [VOTE] Release Doxia Tools parent version 2 and Doxia Integration Tools version 1.5
+1 -- Olivier Le 23 sept. 2012 15:42, Dennis Lundberg denn...@apache.org a écrit : Hi, This is the first release of the Doxia Tools parent after the restructuring of these components. It now works in the same way as the parents for Plugins and Shared Components. Doxia Integration Tools moved from Shared Components to Doxia Tools in this release. We solved 5 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12125component=15480version=18406styleName=Html There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=12125component=15480status=1 Staging repo: https://repository.apache.org/content/repositories/maven-023/ https://repository.apache.org/content/repositories/maven-023/org/apache/maven/doxia/doxia-tools/2/doxia-tools-2-source-release.ziphttps://repository.apache.org/content/repositories/maven-023/org/apache/maven/doxia/doxia-integration-tools/1.5/doxia-integration-tools-1.5-source-release.zip Staging sites (wait for the sync): http://maven.apache.org/doxia/doxia-tools/doxia-tools-2/ http://maven.apache.org/doxia/doxia-tools/doxia-integration-tools-1.5/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Doxia Tools parent version 2 and Doxia Integration Tools version 1.5
+1 -Lukas Dennis Lundberg wrote: Hi, This is the first release of the Doxia Tools parent after the restructuring of these components. It now works in the same way as the parents for Plugins and Shared Components. Doxia Integration Tools moved from Shared Components to Doxia Tools in this release. We solved 5 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12125component=15480version=18406styleName=Html There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=12125component=15480status=1 Staging repo: https://repository.apache.org/content/repositories/maven-023/ https://repository.apache.org/content/repositories/maven-023/org/apache/maven/doxia/doxia-tools/2/doxia-tools-2-source-release.ziphttps://repository.apache.org/content/repositories/maven-023/org/apache/maven/doxia/doxia-integration-tools/1.5/doxia-integration-tools-1.5-source-release.zip Staging sites (wait for the sync): http://maven.apache.org/doxia/doxia-tools/doxia-tools-2/ http://maven.apache.org/doxia/doxia-tools/doxia-integration-tools-1.5/ 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: Building plugins with java 1.7 and the test-harness
If that is the only reason for the release and it can be fixed in an earlier release, then I see no reason not too. This is also in line with the general Maven ethos of not forcing people to upgrade. -Chris Sent from my iPhone On 24/09/2012, at 6:44 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: At the moment, most of the plugin it's don't run under java 7 (dont know about 1.6). The reasons for this seems to be largely that the version of easymock that is used in all released versions of plugin-testing is incompatible with java 7. And since it's easymock classextension, it looks like upgrading has to be painstakingly synchronized between plugin-testing and the client (you can't just override in maven-assembly-plugin) Now version 2.0 of plugin-testing was released which required maven 3 to build. Right now I'm considering releasing 2.1 to fix the easymock situation, but I'm also contemplating releasing 1.3 instead to fix the easymock situation there. The thing is, if I only fix this in 2.1 I will effectively force about half our plugins to require maven 3 to build. How much of an issue will this be wrt maintaining 2.2.1 comptaibility ? I would very much appreciate your .02 euros on this one ;) Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
More git migrations
Just filed https://issues.apache.org/jira/browse/INFRA-5312 Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM5 suggestion (was Re: How to put a dependency in the classpath BEFORE jre.jar?)
On Mon, Sep 24, 2012 at 8:53 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 24 September 2012 12:58, Benson Margulies bimargul...@gmail.com wrote: Folks, Much electronic ink was spilt on the subject of POM5. One of the pools of ink was created by my attempt, some months ago, to move the design along. I wish someone would propose a concrete next step. Simples... Please add this to the wiki page that I started for POM5. A project built with pom5 can have as its parent (if it needs a parent pom) either a pom5 or a pom4 project. A project build with pom4 can only have as its parent (if it needs a parent pom) a pom4 project. A pom5 project will publish a compressed dependency pom4 version of the project. All sections other than parent, groupId,artifactId,version,packaging,dependencies will be in the compressed dependency pom. Dependencies in the compressed dependency pom will be resolved dependencies based on the pom5 build extensions and any project properties. The pom4 pom will be published as groupId:artifactId:version:pom and the pom5 pom will be published as groupId:artifactId:version:pom:dev (ie. with the classifier dev... if somebody has a better idea for the classifier, fine with that) We do not currently publish poms with classifiers, so should not cause an issue. When pom6 comes along it will not be a new classifier, but the same classifier... the rule will be that a project built with pom6 can have as its parent (if it needs a parent pom) one of a pom6, a pom5 or a pom4 project. The key here is that the requirement for the pom version matching only applies at build time. The only issue I remaining is where a pom5 project depends on a pom6 dependency and the features of pom5 do not map to pom4... e.g. if pom5 supports provides that will not be available in the reduced dependency pom4 project, and the pom6 project will be pushing pom4 - pom and pom6 - pom with classifier. To solve that issue I suggest we publish translation shims at well defined coordinates, e.g. org.apache.maven.compatibility:pom:version this can include shims for JVM, RVM, etc Those shims will know how to translate a pom [version] back to any other previous version (given a dependency resolution api, e.g. aether or such) so the pom5 project will download the pom with classifier, see it as a pom6, download the shim (if not already present) and convert the model back to an effective pom5 model and away we go! While that could support a parent with a newer model version than the project being built, I think it is too complex and far simpler to just mandate that your parent's model version is = your model version otherwise the parent cannot assume that all the features it enables will be supported in the child module that is inheriting from. Parent will also include mixins. In its simplest form, the shims could just be XSLT templates... that has the advantage of being cross platform... but the disadvantage of tying poms to XML. I know this is a collection of ideas both I and others have had... but I felt it was time to put it together as a single concept --benson On Mon, Sep 24, 2012 at 4:41 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Markus, perhaps you mis-understood my point. this is a hard problem, that does not mean we should shirk away... that does mean we have to solve it very close to right the great pom migration of Maven 1 to Maven 2 left deep scars... because it got some things wrong. When we do the next migration of Maven 2/3 to Maven 4 (personally I would prefer to call it Maven 5 so that the pom version and maven version align) we need to get that right. The model version 5 pom will likely be with us for quite some time... [snip] - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release maven plugin testing 1.3 2.1 (Take 2)
I'd like to release maven plugin testing 1.3 (maven 2.x) and 2.1 (maven 3.x) The main intent of this release is to modernize dependencies, so we can build on post 1.5 jdks for dependant projects. This includes especially upgrading to easymock 2.5.2, dependencies updating to this version should adjust their easymock dependency accordingly since there is little isolation. Also note that when using the maven 3.x version, the version of the core dependencies must be specified by your project pom, test scope may be considered used. We solved no issues There are still a few issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=MPLUGINTESTINGstatus=1 Staging repo: https://repository.apache.org/content/repositories/maven-029/ Staging site: http://maven.apache.org/plugin-testing/maven-plugin-testing-2.1/plugin-testing/ http://maven.apache.org/plugin-testing/maven-plugin-testing-1.3/plugin-testing/ Relative links appear off for staged sites, so here are links for modules documentation http://maven.apache.org/plugin-testing/maven-plugin-testing-harness-2.1/plugin-testing/maven-plugin-testing-harness/ http://maven.apache.org/plugin-testing/maven-plugin-testing-tools-2.1/plugin-testing/maven-plugin-testing-tools/ http://maven.apache.org/plugin-testing/maven-plugin-testing-harness-2.1/plugin-testing/maven-plugin-testing-harness/ http://maven.apache.org/plugin-testing/maven-plugin-testing-tools-3.1/plugin-testing/maven-plugin-testing-tools/ http://maven.apache.org/plugin-testing/maven-test-tools-3.1/plugin-testing/maven-test-tools/ http://maven.apache.org/plugin-testing/maven-test-tools-3.1/plugin-testing/maven-test-tools/ I am unsure which site will win when promoted ;) I will promote 2.1 last... Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 And here's my +1 Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Maven Surefire version 2.12.4
Hi, We solved 6 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18757styleName=HtmlprojectId=10541 2.12.4 is a minimal bugfix release and is intended to be the new parent-pom version. It's also our first git-based release. There are still lots of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+SUREFIRE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC Staging repo: https://repository.apache.org/content/repositories/maven-031 Staging site: (Sync pending) http://maven.apache.org/surefire/staging/ (Links to sub-sites work when transfered to production) http://maven.apache.org/plugins/maven-failsafe-plugin-2.12.4/ http://maven.apache.org/plugins/maven-surefire-plugin-2.12.4/ http://maven.apache.org/plugins/maven-surefire-reports-plugin-2.12.4/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 And here's my +1 Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Surefire version 2.12.4
+1 (non-binding) I tested this release using JDK 1.6.0_32-b05-420 as well as jdk1.7.0_07 with a small multi-module project, surefire as well as building the site including a cobertura report look good. Regards Mirko On Mon, Sep 24, 2012 at 8:30 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Hi, We solved 6 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18757styleName=HtmlprojectId=10541 2.12.4 is a minimal bugfix release and is intended to be the new parent-pom version. It's also our first git-based release. There are still lots of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+SUREFIRE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC Staging repo: https://repository.apache.org/content/repositories/maven-031 Staging site: (Sync pending) http://maven.apache.org/surefire/staging/ (Links to sub-sites work when transfered to production) http://maven.apache.org/plugins/maven-failsafe-plugin-2.12.4/ http://maven.apache.org/plugins/maven-surefire-plugin-2.12.4/ http://maven.apache.org/plugins/maven-surefire-reports-plugin-2.12.4/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 And here's my +1 Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: More git migrations
Hi Kristian I hate to be the one hitting the brakes on everything Git, but... ...I really think we shouldn't move our release component to Git until we have ironed out any possible problems related to doing Maven releases in Git. On 2012-09-24 10:24, Kristian Rosenvold wrote: Just filed https://issues.apache.org/jira/browse/INFRA-5312 Kristian - 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
Toolchains integration point
Hello, I am working on integration toolchains configuration files into Jenkins. In order to be compatible with distributed Jenkins, I need to be able to dynamically compute the path of the JDKs configured in the toolchains configuration file. Do you know if there is an integration point in Maven for the toolchains feature. Thanks Jeff -- Jeff MAURY Legacy code often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury
Re: More git migrations
+1 Sent from my iPhone On 25/09/2012, at 6:06 AM, Dennis Lundberg denn...@apache.org wrote: Hi Kristian I hate to be the one hitting the brakes on everything Git, but... ...I really think we shouldn't move our release component to Git until we have ironed out any possible problems related to doing Maven releases in Git. On 2012-09-24 10:24, Kristian Rosenvold wrote: Just filed https://issues.apache.org/jira/browse/INFRA-5312 Kristian - 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: More git migrations
Greetings, On Mon, Sep 24, 2012 at 8:57 PM, Chris Graham chrisgw...@gmail.com wrote: +1 On 25/09/2012, at 6:06 AM, Dennis Lundberg denn...@apache.org wrote: I hate to be the one hitting the brakes on everything Git, but... ...I really think we shouldn't move our release component to Git until we have ironed out any possible problems related to doing Maven releases in Git. I think it is fine to want to have (what will most likely be trivial) tests of the release process. But you can't reasonably (read: having logical consistency) vote -1 on releases, e.g. I believe on testing harness, and just in general, and then +1 mandating releases before moving everything over. It comes across as conflicted, and frankly speaking, anti-change. That is probably going to taint any sort of future posting you have regardless of whether or not you have good suggestions. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: More git migrations
Nothing conflicted at all. I was sims agreeing with what Dennis said. To paraphrase: let's make sure we've worked all the kinks out first before we move everything else over. Isn't that prudent? -Chris Sent from my iPhone On 25/09/2012, at 12:21 PM, Jesse Farinacci jie...@gmail.com wrote: Greetings, On Mon, Sep 24, 2012 at 8:57 PM, Chris Graham chrisgw...@gmail.com wrote: +1 On 25/09/2012, at 6:06 AM, Dennis Lundberg denn...@apache.org wrote: I hate to be the one hitting the brakes on everything Git, but... ...I really think we shouldn't move our release component to Git until we have ironed out any possible problems related to doing Maven releases in Git. I think it is fine to want to have (what will most likely be trivial) tests of the release process. But you can't reasonably (read: having logical consistency) vote -1 on releases, e.g. I believe on testing harness, and just in general, and then +1 mandating releases before moving everything over. It comes across as conflicted, and frankly speaking, anti-change. That is probably going to taint any sort of future posting you have regardless of whether or not you have good suggestions. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - 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: More git migrations
Sent from my iPhone On 25/09/2012, at 12:21 PM, Jesse Farinacci jie...@gmail.com wrote: Greetings, On Mon, Sep 24, 2012 at 8:57 PM, Chris Graham chrisgw...@gmail.com wrote: +1 On 25/09/2012, at 6:06 AM, Dennis Lundberg denn...@apache.org wrote: I hate to be the one hitting the brakes on everything Git, but... ...I really think we shouldn't move our release component to Git until we have ironed out any possible problems related to doing Maven releases in Git. I think it is fine to want to have (what will most likely be trivial) tests of the release process. But you can't reasonably (read: having logical consistency) vote -1 on releases, e.g. I believe on testing harness, and just in general, and then +1 mandating releases before moving everything over. It comes across as conflicted, and frankly speaking, anti-change. That is probably going to taint any sort of future posting you have regardless of whether or not you have good suggestions. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - 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: [VOTE] Release Maven Surefire version 2.12.4
+1(non-binding) Now toolchain is working with this release. Thanks. rgds, Markku On 09/24/2012 09:30 PM, Kristian Rosenvold wrote: Hi, We solved 6 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18757styleName=HtmlprojectId=10541 2.12.4 is a minimal bugfix release and is intended to be the new parent-pom version. It's also our first git-based release. There are still lots of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+SUREFIRE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC Staging repo: https://repository.apache.org/content/repositories/maven-031 Staging site: (Sync pending) http://maven.apache.org/surefire/staging/ (Links to sub-sites work when transfered to production) http://maven.apache.org/plugins/maven-failsafe-plugin-2.12.4/ http://maven.apache.org/plugins/maven-surefire-plugin-2.12.4/ http://maven.apache.org/plugins/maven-surefire-reports-plugin-2.12.4/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 And here's my +1 Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: More git migrations
Fair enough, I've put https://issues.apache.org/jira/browse/INFRA-5312 on hold until we also release wagon + scm to verify that it goes smoothly. Although it may seem like it, we're not in that big of a rush ;) Kristian 2012/9/24 Dennis Lundberg denn...@apache.org: Hi Kristian I hate to be the one hitting the brakes on everything Git, but... ...I really think we shouldn't move our release component to Git until we have ironed out any possible problems related to doing Maven releases in Git. On 2012-09-24 10:24, Kristian Rosenvold wrote: Just filed https://issues.apache.org/jira/browse/INFRA-5312 Kristian - 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
