Overall principles of POM inheritance, or, MSITE-600
I think that there's a general principle at work in MSITE-600, so I wonder whether anyone else agrees. Quick summary: Pom 1 has a distributionManagement/site/url element and a modules/module element. Pom 2 has a parent that indicates pom 1, with a relativePath. it also has a distribution/site/url element. My view is that a child value should override a parent value, period, unless some other mechanism (c.f. the attributes on plugin configuration elements) states otherwise. The current implementation of the trunk of m-s-p is that the values in the child and parent should be combined if there's a relativePath that reaches the parent, even if the parent isn't in the reactor. More details are available in the JIRA. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Overall principles of POM inheritance, or, MSITE-600
I have to correct my own email. The behavior here is independent of relativePath and the presence or absence of modules. As things are now, a pom like the global asf or maven pom dare not have a site declared, or it will interact with poms that use it as a parent, even if those poms fully specify the distribution management for site. On Thu, Jul 28, 2011 at 7:06 AM, Benson Margulies bimargul...@gmail.com wrote: I think that there's a general principle at work in MSITE-600, so I wonder whether anyone else agrees. Quick summary: Pom 1 has a distributionManagement/site/url element and a modules/module element. Pom 2 has a parent that indicates pom 1, with a relativePath. it also has a distribution/site/url element. My view is that a child value should override a parent value, period, unless some other mechanism (c.f. the attributes on plugin configuration elements) states otherwise. The current implementation of the trunk of m-s-p is that the values in the child and parent should be combined if there's a relativePath that reaches the parent, even if the parent isn't in the reactor. More details are available in the JIRA. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Apache Maven distribution with fixes
I'll assume that this is fine and no one objects. I'll announce this on the user list later today. On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build is available here: http://people.apache.org/~jvanzyl Summary of the issues Fixes pushed back to the ASF: [MNG-5064][1] mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds) [MNG-5131][2] Wrong encoding for encrypted passwords [MNG-5113][3] NullPointerException on javadoc site generation [MNG-5137][4] Reactor resolution does not work for forked multi module builds [MNG-5096][5] exclusion on dependency with typetest-jar/type doesn't work in maven 3 [MNG-5135][6] Regression: in some cases aggregator mojo is unable to resolve dependencies with custom packaging Fixes not pushed back to the ASF as these are dependent on fixes in Eclipse Aether and Eclipse Sisu: [MNG-5042][7] Regression: CloningClassLoader causes StackOverflowError in groovy [MNG-5056][8] Test dependencies get packaged into WAR file. [MNG-5084][9] Resolver for plugins failing [MNG-5087][10] Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted [MNG-5125] [11]Regression: mvn 3.0.3 is extreemly slow with a large number of dependencies [MNG-5138][12] Dependency conflicts are extremely opaque [1]: http://jira.codehaus.org/browse/MNG-5064 [2]: http://jira.codehaus.org/browse/MNG-5131 [3]: http://jira.codehaus.org/browse/MNG-5113 [4]: http://jira.codehaus.org/browse/MNG-5137 [5]: http://jira.codehaus.org/browse/MNG-5096 [6]: http://jira.codehaus.org/browse/MNG-5135 [7]: http://jira.codehaus.org/browse/MNG-5042 [8]: http://jira.codehaus.org/browse/MNG-5056 [9]: http://jira.codehaus.org/browse/MNG-5084 [10]: http://jira.codehaus.org/browse/MNG-5087 [11]: http://jira.codehaus.org/browse/MNG-5125 [12]: http://jira.codehaus.org/browse/MNG-5138 [a]: http://eclipse.org/proposals/technology.aether/ [b]: http://eclipse.org/proposals/technology.sisu/ Thanks, Jason -- Jason van Zyl Eclipse Board Member Founder, Apache Maven http://twitter.com/jvanzyl - If I find ten thousand ways something won't work, I haven't failed. I am not discouraged, because every wrong attempt discarded is just one more step forward. -- Thomas Edison Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition
POM design principles: what qualifies for the model?
I'm trying to think about the questions of what might go into pom5, and I realized that I am confused about the current design. M3 deprecated 'reporting' but not 'scm'. I don't see the logic. I propose to divide all POM content into two categories: things read by the core of maven, and things read by plugins. The rationale for eliminating reporting, as I thought I understood it, was that it was 'only read by a plugin.' Well, scm, licensing, distribution management, resources, ... most of the POM is 'only read by a plugin.' Sometimes by plugins that are called out in the superpom, and sometimes not. scm strikes me particularly as a target: It's used for three things, and those things can be in conflict. One is to produce a human-readable report about where humans can find the source, another is to give the release plugin enough information to tag a release, and the third is to provide defaults to the maven-scm-plugin. We wouldn't be having this painful discussion about how to make git work if the second item had just been handled by configuration in the release plugin itself instead of being a top-level element. On the other hand, we'd be having a problem allowing for the 'base my url on my parent's url'. Can someone clarify this for me? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Maven 2/3 and Cobetura plugin with both TestNG and JUnit tests (with Surefire plugin configuration)
Larry-
try loading both dependencies in your local repository and running offline with
mvn -o (at least your dependencies will be found)
did you check cobertura for errors?
mvn -e -X cobertura:cobertura -Dquiet=true
take junit out of the mix and run testng as solo Test dependency then check
output folders
${project.reporting.outputDirectory}/cobertura.
if these tests fail you may have found a bug in which cause you need to file a
JIRA at
http://jira.codehaus.org/browse/MCOBERTURA
hth
Martin-
__
Jogi és Bizalmassági kinyilatkoztatás/Verzicht und
Vertraulichkeitanmerkung/Note de déni et de confidentialité
Ez az
üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy
jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának
készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és
semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek
könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet
ezen üzenet tartalma miatt.
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
Date: Wed, 27 Jul 2011 19:32:43 -0600
Subject: Maven 2/3 and Cobetura plugin with both TestNG and JUnit tests (with
Surefire plugin configuration)
From: lar...@gmail.com
To: dev@maven.apache.org
I did send this to the users list, but got no response in over a week.
I know dev lists are not a magical escalation path, but this might be
a better venue for this email.
I have an example project at https://gist.github.com/1090223
This project has both a JUnit test and a TestNG test. Following some
instructions online to get surefire be able to run both I added lines
19-45 in the pom.
This works fine when running mvn test, except it runs the TestNG
tests twice. I can fix that by commenting out lines 34-43.
Now when I run mvn cobertura:cobertura, this is where things get weird.
In Maven 2.2.1, it runs both TestNG and JUnit just fine, and produces
the correct coverage.
Now in Maven 3.0.3 it just runs the JUnit tests. (With lines 34-43
still commented out). When I bring those back, this is the output:
---
T E S T S
---
Running com.company.JUnitTest
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
Running com.company.TestNGTest
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
There are no tests to run.
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
So it appears to try to run both tests, but fails to actually run any
tests, and gets 0% coverage.
It appears there is something odd between Maven 2.2.1 and Maven 3.0.3
when the cobertura plugin runs, and its reading of the Surefire plugin
configuration.
Ideally I would only use JUnit or TestNG, and this would not be a
problem. However, we are using TestNG exclusively, and wanted to
introduce a tool that currently only is executed as a JUnit test
(Spock). I wanted to avoid changing all our tests from TestNG to JUnit
unless absolutely necessary.
It appears to be a regression from Maven 2.2.1 to Maven 3.0.3, unless
it was a bug in Maven 2 that was fixed.
-- Larry
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Apache Maven distribution with fixes
mom jason. Before we ship 3.0.4 I'd like to fix the SCM URL postfix problem which exists in lots of DSCMs. Will do this in the next week. LieGrue, strub --- On Thu, 7/28/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 11:41 AM I'll assume that this is fine and no one objects. I'll announce this on the user list later today. On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build is available here: http://people.apache.org/~jvanzyl Summary of the issues Fixes pushed back to the ASF: [MNG-5064][1] mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds) [MNG-5131][2] Wrong encoding for encrypted passwords [MNG-5113][3] NullPointerException on javadoc site generation [MNG-5137][4] Reactor resolution does not work for forked multi module builds [MNG-5096][5] exclusion on dependency with typetest-jar/type doesn't work in maven 3 [MNG-5135][6] Regression: in some cases aggregator mojo is unable to resolve dependencies with custom packaging Fixes not pushed back to the ASF as these are dependent on fixes in Eclipse Aether and Eclipse Sisu: [MNG-5042][7] Regression: CloningClassLoader causes StackOverflowError in groovy [MNG-5056][8] Test dependencies get packaged into WAR file. [MNG-5084][9] Resolver for plugins failing [MNG-5087][10] Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted [MNG-5125] [11]Regression: mvn 3.0.3 is extreemly slow with a large number of dependencies [MNG-5138][12] Dependency conflicts are extremely opaque [1]: http://jira.codehaus.org/browse/MNG-5064 [2]: http://jira.codehaus.org/browse/MNG-5131 [3]: http://jira.codehaus.org/browse/MNG-5113 [4]: http://jira.codehaus.org/browse/MNG-5137 [5]: http://jira.codehaus.org/browse/MNG-5096 [6]: http://jira.codehaus.org/browse/MNG-5135 [7]: http://jira.codehaus.org/browse/MNG-5042 [8]: http://jira.codehaus.org/browse/MNG-5056 [9]: http://jira.codehaus.org/browse/MNG-5084 [10]: http://jira.codehaus.org/browse/MNG-5087 [11]: http://jira.codehaus.org/browse/MNG-5125 [12]: http://jira.codehaus.org/browse/MNG-5138 [a]: http://eclipse.org/proposals/technology.aether/ [b]: http://eclipse.org/proposals/technology.sisu/ Thanks, Jason -- Jason van Zyl Eclipse Board Member Founder, Apache Maven http://twitter.com/jvanzyl - If I find ten thousand ways something won't work, I haven't failed. I am not discouraged, because every wrong attempt discarded is just one more step forward. -- Thomas Edison Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Apache Maven distribution with fixes
On Thu, Jul 28, 2011 at 8:25 AM, Mark Struberg strub...@yahoo.de wrote: mom jason. Before we ship 3.0.4 I'd like to fix the SCM URL postfix problem which exists in lots of DSCMs. Will do this in the next week. Unless there are a lot of pmc members hiding under a rock who aren't voting +1, 3.0.4 can't incorporate the new Aether, and one of the important bug fixes is in there. So we either hold for the Eclipse stand-up of aether, or release without fixing that problem. LieGrue, strub --- On Thu, 7/28/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 11:41 AM I'll assume that this is fine and no one objects. I'll announce this on the user list later today. On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build is available here: http://people.apache.org/~jvanzyl Summary of the issues Fixes pushed back to the ASF: [MNG-5064][1] mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds) [MNG-5131][2] Wrong encoding for encrypted passwords [MNG-5113][3] NullPointerException on javadoc site generation [MNG-5137][4] Reactor resolution does not work for forked multi module builds [MNG-5096][5] exclusion on dependency with typetest-jar/type doesn't work in maven 3 [MNG-5135][6] Regression: in some cases aggregator mojo is unable to resolve dependencies with custom packaging Fixes not pushed back to the ASF as these are dependent on fixes in Eclipse Aether and Eclipse Sisu: [MNG-5042][7] Regression: CloningClassLoader causes StackOverflowError in groovy [MNG-5056][8] Test dependencies get packaged into WAR file. [MNG-5084][9] Resolver for plugins failing [MNG-5087][10] Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted [MNG-5125] [11]Regression: mvn 3.0.3 is extreemly slow with a large number of dependencies [MNG-5138][12] Dependency conflicts are extremely opaque [1]: http://jira.codehaus.org/browse/MNG-5064 [2]: http://jira.codehaus.org/browse/MNG-5131 [3]: http://jira.codehaus.org/browse/MNG-5113 [4]: http://jira.codehaus.org/browse/MNG-5137 [5]: http://jira.codehaus.org/browse/MNG-5096 [6]: http://jira.codehaus.org/browse/MNG-5135 [7]: http://jira.codehaus.org/browse/MNG-5042 [8]: http://jira.codehaus.org/browse/MNG-5056 [9]: http://jira.codehaus.org/browse/MNG-5084 [10]: http://jira.codehaus.org/browse/MNG-5087 [11]: http://jira.codehaus.org/browse/MNG-5125 [12]: http://jira.codehaus.org/browse/MNG-5138 [a]: http://eclipse.org/proposals/technology.aether/ [b]: http://eclipse.org/proposals/technology.sisu/ Thanks, Jason -- Jason van Zyl Eclipse Board Member Founder, Apache Maven http://twitter.com/jvanzyl - If I find ten thousand ways something won't work, I haven't failed. I am not discouraged, because every wrong attempt discarded is just one more step forward. -- Thomas Edison Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail:
Re: Apache Maven distribution with fixes
On 28/07/2011, at 10:32 PM, Jason van Zyl wrote: On Jul 28, 2011, at 8:25 AM, Mark Struberg wrote: mom jason. Before we ship 3.0.4 I'd like to fix the SCM URL postfix problem which exists in lots of DSCMs. Will do this in the next week. You probably have 6-7 weeks before an official 3.0.4 release would be made so you have plenty of time. If you are going to wait for Aether and Sisu to be provisioned at Eclipse then the total time for both of those to pass into that state is about 7 weeks. The build I proposed could not be an official release until such a time because there are fixes which rely on Sisu and Aether which are important for users. Would you consider dual licensing them again so we can just keep moving forward as we had been? It makes no changes to your plans and reduces the amount of uncertainty everyone has. It's changed license 3 times in the last year, one more won't hurt. There'd be no hold up if the current release had kept the license that it had when it was incorporated a year ago, and the 3.0.4 release process could start straight away. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Apache Maven distribution with fixes
On Thursday, July 28, 2011 7:41:16 AM Jason van Zyl wrote: I'll assume that this is fine and no one objects. I'll announce this on the user list later today. *THAT* I have a problem with.I don't consider these any different than our nightly snapshots or a different commercial build of an Apache project. In both of those cases, announcements about them or promoting them over the official project supplied releases is, IMO, not acceptable on the *users* list. If you want to point a couple of your users at them to help test things or similar, fine as a lead up to 3.0.4. But they cannot be considered general available things similar to releases. Dan On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build is available here: http://people.apache.org/~jvanzyl Summary of the issues Fixes pushed back to the ASF: [MNG-5064][1] mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds) [MNG-5131][2] Wrong encoding for encrypted passwords [MNG-5113][3] NullPointerException on javadoc site generation [MNG-5137][4] Reactor resolution does not work for forked multi module builds [MNG-5096][5] exclusion on dependency with typetest-jar/type doesn't work in maven 3 [MNG-5135][6] Regression: in some cases aggregator mojo is unable to resolve dependencies with custom packaging Fixes not pushed back to the ASF as these are dependent on fixes in Eclipse Aether and Eclipse Sisu: [MNG-5042][7] Regression: CloningClassLoader causes StackOverflowError in groovy [MNG-5056][8] Test dependencies get packaged into WAR file. [MNG-5084][9] Resolver for plugins failing [MNG-5087][10] Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted [MNG-5125] [11]Regression: mvn 3.0.3 is extreemly slow with a large number of dependencies [MNG-5138][12] Dependency conflicts are extremely opaque [1]: http://jira.codehaus.org/browse/MNG-5064 [2]: http://jira.codehaus.org/browse/MNG-5131 [3]: http://jira.codehaus.org/browse/MNG-5113 [4]: http://jira.codehaus.org/browse/MNG-5137 [5]: http://jira.codehaus.org/browse/MNG-5096 [6]: http://jira.codehaus.org/browse/MNG-5135 [7]: http://jira.codehaus.org/browse/MNG-5042 [8]: http://jira.codehaus.org/browse/MNG-5056 [9]: http://jira.codehaus.org/browse/MNG-5084 [10]: http://jira.codehaus.org/browse/MNG-5087 [11]: http://jira.codehaus.org/browse/MNG-5125 [12]: http://jira.codehaus.org/browse/MNG-5138 [a]: http://eclipse.org/proposals/technology.aether/ [b]: http://eclipse.org/proposals/technology.sisu/ Thanks, Jason -- Jason van Zyl Eclipse Board Member Founder, Apache Maven http://twitter.com/jvanzyl - If I find ten thousand ways something won't work, I haven't failed. I am not discouraged, because every wrong attempt discarded is just one more step forward. -- Thomas Edison Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Apache Maven distribution with fixes
Humm, guess there are only 3 options left in this case 1.) We wait 7 weeks or whatever time it takes (most probably it _will_ take more) 2.) You ship an ALv2 licensed version of Aether and Sisu which we can incorporate into an upcoming maven-3.0.4. 3.) We fork the last ALv2 licensed Aether version back to the Maven project and fix the bugs ourself. LieGrue, strub --- On Thu, 7/28/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 12:32 PM On Jul 28, 2011, at 8:25 AM, Mark Struberg wrote: mom jason. Before we ship 3.0.4 I'd like to fix the SCM URL postfix problem which exists in lots of DSCMs. Will do this in the next week. You probably have 6-7 weeks before an official 3.0.4 release would be made so you have plenty of time. If you are going to wait for Aether and Sisu to be provisioned at Eclipse then the total time for both of those to pass into that state is about 7 weeks. The build I proposed could not be an official release until such a time because there are fixes which rely on Sisu and Aether which are important for users. LieGrue, strub --- On Thu, 7/28/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 11:41 AM I'll assume that this is fine and no one objects. I'll announce this on the user list later today. On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build is available here: http://people.apache.org/~jvanzyl Summary of the issues Fixes pushed back to the ASF: [MNG-5064][1] mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds) [MNG-5131][2] Wrong encoding for encrypted passwords [MNG-5113][3] NullPointerException on javadoc site generation [MNG-5137][4] Reactor resolution does not work for forked multi module builds [MNG-5096][5] exclusion on dependency with typetest-jar/type doesn't work in maven 3 [MNG-5135][6] Regression: in some cases aggregator mojo is unable to resolve dependencies with custom packaging Fixes not pushed back to the ASF as these are dependent on fixes in Eclipse Aether and Eclipse Sisu: [MNG-5042][7] Regression: CloningClassLoader causes StackOverflowError in groovy [MNG-5056][8] Test dependencies get packaged into WAR file. [MNG-5084][9] Resolver for plugins failing [MNG-5087][10] Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted [MNG-5125] [11]Regression: mvn 3.0.3 is extreemly slow with a large number of dependencies [MNG-5138][12] Dependency conflicts are extremely opaque [1]: http://jira.codehaus.org/browse/MNG-5064 [2]: http://jira.codehaus.org/browse/MNG-5131 [3]: http://jira.codehaus.org/browse/MNG-5113 [4]: http://jira.codehaus.org/browse/MNG-5137 [5]: http://jira.codehaus.org/browse/MNG-5096 [6]: http://jira.codehaus.org/browse/MNG-5135 [7]: http://jira.codehaus.org/browse/MNG-5042 [8]: http://jira.codehaus.org/browse/MNG-5056 [9]: http://jira.codehaus.org/browse/MNG-5084 [10]: http://jira.codehaus.org/browse/MNG-5087 [11]: http://jira.codehaus.org/browse/MNG-5125 [12]: http://jira.codehaus.org/browse/MNG-5138 [a]: http://eclipse.org/proposals/technology.aether/ [b]: http://eclipse.org/proposals/technology.sisu/ Thanks, Jason -- Jason van Zyl Eclipse Board Member Founder, Apache Maven http://twitter.com/jvanzyl - If I find ten thousand ways something won't work, I haven't failed. I am not discouraged, because every wrong attempt discarded is just one more step forward. -- Thomas Edison Thanks, Jason
Re: Apache Maven distribution with fixes
On Jul 28, 2011, at 8:49 AM, Daniel Kulp wrote: On Thursday, July 28, 2011 7:41:16 AM Jason van Zyl wrote: I'll assume that this is fine and no one objects. I'll announce this on the user list later today. *THAT* I have a problem with.I don't consider these any different than our nightly snapshots or a different commercial build of an Apache project. In both of those cases, announcements about them or promoting them over the official project supplied releases is, IMO, not acceptable on the *users* list. I'm not promoting them over official project releases because there is no official project release, or nightly, that incorporates the fixes users have been asking for. This is a build Benjamin and I created to help users. I will not post anything on the user list, if as a PMC member you're telling me I can't. If you want to point a couple of your users at them to help test things or similar, fine as a lead up to 3.0.4. But they cannot be considered general available things similar to releases. Dan On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build is available here: http://people.apache.org/~jvanzyl Summary of the issues Fixes pushed back to the ASF: [MNG-5064][1] mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds) [MNG-5131][2] Wrong encoding for encrypted passwords [MNG-5113][3] NullPointerException on javadoc site generation [MNG-5137][4] Reactor resolution does not work for forked multi module builds [MNG-5096][5] exclusion on dependency with typetest-jar/type doesn't work in maven 3 [MNG-5135][6] Regression: in some cases aggregator mojo is unable to resolve dependencies with custom packaging Fixes not pushed back to the ASF as these are dependent on fixes in Eclipse Aether and Eclipse Sisu: [MNG-5042][7] Regression: CloningClassLoader causes StackOverflowError in groovy [MNG-5056][8] Test dependencies get packaged into WAR file. [MNG-5084][9] Resolver for plugins failing [MNG-5087][10] Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted [MNG-5125] [11]Regression: mvn 3.0.3 is extreemly slow with a large number of dependencies [MNG-5138][12] Dependency conflicts are extremely opaque [1]: http://jira.codehaus.org/browse/MNG-5064 [2]: http://jira.codehaus.org/browse/MNG-5131 [3]: http://jira.codehaus.org/browse/MNG-5113 [4]: http://jira.codehaus.org/browse/MNG-5137 [5]: http://jira.codehaus.org/browse/MNG-5096 [6]: http://jira.codehaus.org/browse/MNG-5135 [7]: http://jira.codehaus.org/browse/MNG-5042 [8]: http://jira.codehaus.org/browse/MNG-5056 [9]: http://jira.codehaus.org/browse/MNG-5084 [10]: http://jira.codehaus.org/browse/MNG-5087 [11]: http://jira.codehaus.org/browse/MNG-5125 [12]: http://jira.codehaus.org/browse/MNG-5138 [a]: http://eclipse.org/proposals/technology.aether/ [b]: http://eclipse.org/proposals/technology.sisu/ Thanks, Jason -- Jason van Zyl Eclipse Board Member Founder, Apache Maven http://twitter.com/jvanzyl - If I find ten thousand ways something won't work, I haven't failed. I am not discouraged, because every wrong attempt discarded is just one more step forward. -- Thomas Edison Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: Apache Maven distribution with fixes
Mark, No we cannot fork back. It is too large of a body of code to absorb without a grant, AL or no AL. I'm always happy to be proved stupid by consultation with legal. Until then, however, the policy seems perfectly clear to me. Only small amounts of code can be absorbed without a grant. --benson On Thu, Jul 28, 2011 at 8:52 AM, Mark Struberg strub...@yahoo.de wrote: Humm, guess there are only 3 options left in this case 1.) We wait 7 weeks or whatever time it takes (most probably it _will_ take more) 2.) You ship an ALv2 licensed version of Aether and Sisu which we can incorporate into an upcoming maven-3.0.4. 3.) We fork the last ALv2 licensed Aether version back to the Maven project and fix the bugs ourself. LieGrue, strub --- On Thu, 7/28/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 12:32 PM On Jul 28, 2011, at 8:25 AM, Mark Struberg wrote: mom jason. Before we ship 3.0.4 I'd like to fix the SCM URL postfix problem which exists in lots of DSCMs. Will do this in the next week. You probably have 6-7 weeks before an official 3.0.4 release would be made so you have plenty of time. If you are going to wait for Aether and Sisu to be provisioned at Eclipse then the total time for both of those to pass into that state is about 7 weeks. The build I proposed could not be an official release until such a time because there are fixes which rely on Sisu and Aether which are important for users. LieGrue, strub --- On Thu, 7/28/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 11:41 AM I'll assume that this is fine and no one objects. I'll announce this on the user list later today. On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build is available here: http://people.apache.org/~jvanzyl Summary of the issues Fixes pushed back to the ASF: [MNG-5064][1] mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds) [MNG-5131][2] Wrong encoding for encrypted passwords [MNG-5113][3] NullPointerException on javadoc site generation [MNG-5137][4] Reactor resolution does not work for forked multi module builds [MNG-5096][5] exclusion on dependency with typetest-jar/type doesn't work in maven 3 [MNG-5135][6] Regression: in some cases aggregator mojo is unable to resolve dependencies with custom packaging Fixes not pushed back to the ASF as these are dependent on fixes in Eclipse Aether and Eclipse Sisu: [MNG-5042][7] Regression: CloningClassLoader causes StackOverflowError in groovy [MNG-5056][8] Test dependencies get packaged into WAR file. [MNG-5084][9] Resolver for plugins failing [MNG-5087][10] Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted [MNG-5125] [11]Regression: mvn 3.0.3 is extreemly slow with a large number of dependencies [MNG-5138][12] Dependency conflicts are extremely opaque [1]: http://jira.codehaus.org/browse/MNG-5064 [2]: http://jira.codehaus.org/browse/MNG-5131 [3]: http://jira.codehaus.org/browse/MNG-5113 [4]: http://jira.codehaus.org/browse/MNG-5137 [5]: http://jira.codehaus.org/browse/MNG-5096 [6]: http://jira.codehaus.org/browse/MNG-5135 [7]: http://jira.codehaus.org/browse/MNG-5042 [8]: http://jira.codehaus.org/browse/MNG-5056 [9]: http://jira.codehaus.org/browse/MNG-5084 [10]: http://jira.codehaus.org/browse/MNG-5087 [11]: http://jira.codehaus.org/browse/MNG-5125 [12]: http://jira.codehaus.org/browse/MNG-5138 [a]: http://eclipse.org/proposals/technology.aether/ [b]: http://eclipse.org/proposals/technology.sisu/ Thanks, Jason -- Jason van Zyl Eclipse Board Member
Re: Apache Maven distribution with fixes
Benson, you are wrong. The answer to this question is really not clear and depends on a much more then just the pure amount of code. There are lots of discussions around that lately on legal and we have lots of detailed if/whens. If we have the history, then we can do the check. Gladly github provides those. Also there is still the option to fork it over to apache-extras and fix it there. LieGrue, strub --- On Thu, 7/28/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 1:06 PM Mark, No we cannot fork back. It is too large of a body of code to absorb without a grant, AL or no AL. I'm always happy to be proved stupid by consultation with legal. Until then, however, the policy seems perfectly clear to me. Only small amounts of code can be absorbed without a grant. --benson On Thu, Jul 28, 2011 at 8:52 AM, Mark Struberg strub...@yahoo.de wrote: Humm, guess there are only 3 options left in this case 1.) We wait 7 weeks or whatever time it takes (most probably it _will_ take more) 2.) You ship an ALv2 licensed version of Aether and Sisu which we can incorporate into an upcoming maven-3.0.4. 3.) We fork the last ALv2 licensed Aether version back to the Maven project and fix the bugs ourself. LieGrue, strub --- On Thu, 7/28/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 12:32 PM On Jul 28, 2011, at 8:25 AM, Mark Struberg wrote: mom jason. Before we ship 3.0.4 I'd like to fix the SCM URL postfix problem which exists in lots of DSCMs. Will do this in the next week. You probably have 6-7 weeks before an official 3.0.4 release would be made so you have plenty of time. If you are going to wait for Aether and Sisu to be provisioned at Eclipse then the total time for both of those to pass into that state is about 7 weeks. The build I proposed could not be an official release until such a time because there are fixes which rely on Sisu and Aether which are important for users. LieGrue, strub --- On Thu, 7/28/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 11:41 AM I'll assume that this is fine and no one objects. I'll announce this on the user list later today. On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build is available here: http://people.apache.org/~jvanzyl Summary of the issues Fixes pushed back to the ASF: [MNG-5064][1] mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds) [MNG-5131][2] Wrong encoding for encrypted passwords [MNG-5113][3] NullPointerException on javadoc site generation [MNG-5137][4] Reactor resolution does not work for forked multi module builds [MNG-5096][5] exclusion on dependency with typetest-jar/type doesn't work in maven 3 [MNG-5135][6] Regression: in some cases aggregator mojo is unable to resolve dependencies with custom packaging Fixes not pushed back to the ASF as these are dependent on fixes in Eclipse Aether and Eclipse Sisu: [MNG-5042][7] Regression: CloningClassLoader causes StackOverflowError in groovy [MNG-5056][8] Test dependencies get packaged into WAR file. [MNG-5084][9] Resolver for plugins failing [MNG-5087][10] Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted [MNG-5125] [11]Regression: mvn 3.0.3 is extreemly slow with a large number of dependencies [MNG-5138][12]
Re: Apache Maven distribution with fixes
On Thursday, July 28, 2011 8:59:09 AM Jason van Zyl wrote: On Jul 28, 2011, at 8:49 AM, Daniel Kulp wrote: On Thursday, July 28, 2011 7:41:16 AM Jason van Zyl wrote: I'll assume that this is fine and no one objects. I'll announce this on the user list later today. *THAT* I have a problem with.I don't consider these any different than our nightly snapshots or a different commercial build of an Apache project. In both of those cases, announcements about them or promoting them over the official project supplied releases is, IMO, not acceptable on the *users* list. I'm not promoting them over official project releases because there is no official project release, or nightly, that incorporates the fixes users have been asking for. This is a build Benjamin and I created to help users. I will not post anything on the user list, if as a PMC member you're telling me I can't. I'm saying you can't make a general announcement about it as it would be no different than making announcements of commercial versions of projects (that contain things like fixes and features not available from Apache builds) on other projects users lists. The fact that builds are specifically labeled sonatype really emphasizes the commercial nature of these builds. In this particular case, if a specific user asks a question or has an issue, in a reply to that user, you can mention it, but make clear in the response: 1) There are non-sanctioned builds of Maven not endorsed by the Maven project. 2) It contains code and fixes that have not been incorporated into Apache Maven, not even to trunk. 3) As such, any fixes (or new bugs) may not be present in a future version of Maven. 4) They are using such builds at their own risk. 5) Due to the above, it's not recommend to use these builds in any sort of production scenario. At the end of the day, if you really cared about the Maven users, you'd help us get an official Apache version of 3.0.4 out. The fact that you are unwilling to do what is necessary to make that happen is very frustrating to me. Dan If you want to point a couple of your users at them to help test things or similar, fine as a lead up to 3.0.4. But they cannot be considered general available things similar to releases. Dan On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build is available here: http://people.apache.org/~jvanzyl Summary of the issues Fixes pushed back to the ASF: [MNG-5064][1] mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds) [MNG-5131][2] Wrong encoding for encrypted passwords [MNG-5113][3] NullPointerException on javadoc site generation [MNG-5137][4] Reactor resolution does not work for forked multi module builds [MNG-5096][5] exclusion on dependency with typetest-jar/type doesn't work in maven 3 [MNG-5135][6] Regression: in some cases aggregator mojo is unable to resolve dependencies with custom packaging Fixes not pushed back to the ASF as these are dependent on fixes in Eclipse Aether and Eclipse Sisu: [MNG-5042][7] Regression: CloningClassLoader causes StackOverflowError in groovy [MNG-5056][8] Test dependencies get packaged into WAR file. [MNG-5084][9] Resolver for plugins failing [MNG-5087][10] Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted [MNG-5125] [11]Regression: mvn 3.0.3 is extreemly slow with a large number of dependencies [MNG-5138][12] Dependency conflicts are extremely opaque [1]: http://jira.codehaus.org/browse/MNG-5064 [2]: http://jira.codehaus.org/browse/MNG-5131 [3]: http://jira.codehaus.org/browse/MNG-5113 [4]: http://jira.codehaus.org/browse/MNG-5137 [5]: http://jira.codehaus.org/browse/MNG-5096 [6]: http://jira.codehaus.org/browse/MNG-5135 [7]: http://jira.codehaus.org/browse/MNG-5042 [8]: http://jira.codehaus.org/browse/MNG-5056 [9]: http://jira.codehaus.org/browse/MNG-5084 [10]: http://jira.codehaus.org/browse/MNG-5087 [11]: http://jira.codehaus.org/browse/MNG-5125
Re: Apache Maven distribution with fixes
On Thu, Jul 28, 2011 at 9:10 AM, Mark Struberg strub...@yahoo.de wrote: Benson, you are wrong. The answer to this question is really not clear and depends on a much more then just the pure amount of code. There are lots of discussions around that lately on legal and we have lots of detailed if/whens. If we have the history, then we can do the check. Gladly github provides those. Also there is still the option to fork it over to apache-extras and fix it there. Mark, It seems to me that the net of your paragraph is to support my argument. If the committers slapped an AL dual license on Aether today, we could not just grab that code, with no further discussion, examination, and clearance, and fork it back into Apache. I spend a lot of time in the incubator, and the IP clearance policies have been hashed on this subject very recently. A podling I'm trying to launch has been told, in no uncertain terms, more or less what I wrote, by the lead legal advisor. Sure, if some of the code of some version of AEther was at ASF originally, that code could be teased out and brought back. But that's very different from 'oh, a dual license, we can grab it instantly.' Want to send some thread references? --benson LieGrue, strub --- On Thu, 7/28/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 1:06 PM Mark, No we cannot fork back. It is too large of a body of code to absorb without a grant, AL or no AL. I'm always happy to be proved stupid by consultation with legal. Until then, however, the policy seems perfectly clear to me. Only small amounts of code can be absorbed without a grant. --benson On Thu, Jul 28, 2011 at 8:52 AM, Mark Struberg strub...@yahoo.de wrote: Humm, guess there are only 3 options left in this case 1.) We wait 7 weeks or whatever time it takes (most probably it _will_ take more) 2.) You ship an ALv2 licensed version of Aether and Sisu which we can incorporate into an upcoming maven-3.0.4. 3.) We fork the last ALv2 licensed Aether version back to the Maven project and fix the bugs ourself. LieGrue, strub --- On Thu, 7/28/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 12:32 PM On Jul 28, 2011, at 8:25 AM, Mark Struberg wrote: mom jason. Before we ship 3.0.4 I'd like to fix the SCM URL postfix problem which exists in lots of DSCMs. Will do this in the next week. You probably have 6-7 weeks before an official 3.0.4 release would be made so you have plenty of time. If you are going to wait for Aether and Sisu to be provisioned at Eclipse then the total time for both of those to pass into that state is about 7 weeks. The build I proposed could not be an official release until such a time because there are fixes which rely on Sisu and Aether which are important for users. LieGrue, strub --- On Thu, 7/28/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 11:41 AM I'll assume that this is fine and no one objects. I'll announce this on the user list later today. On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build is available here: http://people.apache.org/~jvanzyl Summary of the issues Fixes pushed back to the ASF: [MNG-5064][1] mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds) [MNG-5131][2] Wrong encoding for encrypted passwords [MNG-5113][3] NullPointerException on javadoc site generation [MNG-5137][4] Reactor resolution does not work for forked multi
Re: Apache Maven distribution with fixes
On Jul 28, 2011, at 8:52 AM, Mark Struberg wrote: Humm, guess there are only 3 options left in this case 1.) We wait 7 weeks or whatever time it takes (most probably it _will_ take more) Not likely, it will probably be shorter as I was being conservative. The scheduling at Eclipse is like a clockwork. Once the review period of over the creation review is immediately scheduled. The creation review and initial legal review will have no issues because nearly 100% of the code was written by Sonatype employees and we're all cleared at Eclipse. The code will start the parallel IP immediately and probably clear IP review very fast given it's all Sonatype code and there is already precedent for a lot of our code going into Eclipse. 2.) You ship an ALv2 licensed version of Aether and Sisu which we can incorporate into an upcoming maven-3.0.4. The proposals are posted, I'm not changing the licenses now. 3.) We fork the last ALv2 licensed Aether version back to the Maven project and fix the bugs ourself. I believe this will never happen and you will put the project in a very bad place if you attempt to do that. Since our last release not a single Maven committer outside of Sonatype has made any bug fixes or patches to the core (Paul made one small feature addition). You guys are talking about a new wagon, POM5 formats, new logging, artifact lookup indirection, but the day to day of actually patching and bug fixing is entirely absent and things like the plugin ITs are failing day after day in CI. Looking at the situation empirically, the probability that you will have the time and energy to try and patch Aether and Sisu given no one has patched any of the normal core code here I find a highly impractical and dangerous proposal. Path 1) doesn't preclude your participation and we've done nothing to hinder Kristian or Herve from participating. LieGrue, strub --- On Thu, 7/28/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 12:32 PM On Jul 28, 2011, at 8:25 AM, Mark Struberg wrote: mom jason. Before we ship 3.0.4 I'd like to fix the SCM URL postfix problem which exists in lots of DSCMs. Will do this in the next week. You probably have 6-7 weeks before an official 3.0.4 release would be made so you have plenty of time. If you are going to wait for Aether and Sisu to be provisioned at Eclipse then the total time for both of those to pass into that state is about 7 weeks. The build I proposed could not be an official release until such a time because there are fixes which rely on Sisu and Aether which are important for users. LieGrue, strub --- On Thu, 7/28/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 11:41 AM I'll assume that this is fine and no one objects. I'll announce this on the user list later today. On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build is available here: http://people.apache.org/~jvanzyl Summary of the issues Fixes pushed back to the ASF: [MNG-5064][1] mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds) [MNG-5131][2] Wrong encoding for encrypted passwords [MNG-5113][3] NullPointerException on javadoc site generation [MNG-5137][4] Reactor resolution does not work for forked multi module builds [MNG-5096][5] exclusion on dependency with typetest-jar/type doesn't work in maven 3 [MNG-5135][6] Regression: in some cases aggregator mojo is unable to resolve dependencies with custom packaging Fixes not pushed back to the ASF as these are dependent on fixes in Eclipse Aether and Eclipse Sisu: [MNG-5042][7] Regression: CloningClassLoader causes StackOverflowError in groovy [MNG-5056][8] Test dependencies get packaged into WAR file. [MNG-5084][9] Resolver for plugins failing
Re: Apache Maven distribution with fixes
Correct me if I'm wrong, but it's not okay to even call the binary maven-XXX or apache-maven-XXX (unless it's a snapshot) at all without getting a PMC vote. I thought there were rules in our ASF release protocols about that. On 7/28/11 9:18 AM, Daniel Kulp wrote: On Thursday, July 28, 2011 8:59:09 AM Jason van Zyl wrote: On Jul 28, 2011, at 8:49 AM, Daniel Kulp wrote: On Thursday, July 28, 2011 7:41:16 AM Jason van Zyl wrote: I'll assume that this is fine and no one objects. I'll announce this on the user list later today. *THAT* I have a problem with.I don't consider these any different than our nightly snapshots or a different commercial build of an Apache project. In both of those cases, announcements about them or promoting them over the official project supplied releases is, IMO, not acceptable on the *users* list. I'm not promoting them over official project releases because there is no official project release, or nightly, that incorporates the fixes users have been asking for. This is a build Benjamin and I created to help users. I will not post anything on the user list, if as a PMC member you're telling me I can't. I'm saying you can't make a general announcement about it as it would be no different than making announcements of commercial versions of projects (that contain things like fixes and features not available from Apache builds) on other projects users lists. The fact that builds are specifically labeled sonatype really emphasizes the commercial nature of these builds. In this particular case, if a specific user asks a question or has an issue, in a reply to that user, you can mention it, but make clear in the response: 1) There are non-sanctioned builds of Maven not endorsed by the Maven project. 2) It contains code and fixes that have not been incorporated into Apache Maven, not even to trunk. 3) As such, any fixes (or new bugs) may not be present in a future version of Maven. 4) They are using such builds at their own risk. 5) Due to the above, it's not recommend to use these builds in any sort of production scenario. At the end of the day, if you really cared about the Maven users, you'd help us get an official Apache version of 3.0.4 out. The fact that you are unwilling to do what is necessary to make that happen is very frustrating to me. Dan If you want to point a couple of your users at them to help test things or similar, fine as a lead up to 3.0.4. But they cannot be considered general available things similar to releases. Dan On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build is available here: http://people.apache.org/~jvanzyl Summary of the issues Fixes pushed back to the ASF: [MNG-5064][1] mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds) [MNG-5131][2] Wrong encoding for encrypted passwords [MNG-5113][3] NullPointerException on javadoc site generation [MNG-5137][4] Reactor resolution does not work for forked multi module builds [MNG-5096][5]exclusion ondependency with typetest-jar/type doesn't work in maven 3 [MNG-5135][6] Regression: in some cases aggregator mojo is unable to resolve dependencies with custom packaging Fixes not pushed back to the ASF as these are dependent on fixes in Eclipse Aether and Eclipse Sisu: [MNG-5042][7] Regression: CloningClassLoader causes StackOverflowError in groovy [MNG-5056][8] Test dependencies get packaged into WAR file. [MNG-5084][9] Resolver for plugins failing [MNG-5087][10] Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted [MNG-5125] [11]Regression: mvn 3.0.3 is extreemly slow with a large number of dependencies [MNG-5138][12] Dependency conflicts are extremely opaque [1]: http://jira.codehaus.org/browse/MNG-5064 [2]: http://jira.codehaus.org/browse/MNG-5131 [3]: http://jira.codehaus.org/browse/MNG-5113 [4]: http://jira.codehaus.org/browse/MNG-5137 [5]: http://jira.codehaus.org/browse/MNG-5096 [6]: http://jira.codehaus.org/browse/MNG-5135 [7]: http://jira.codehaus.org/browse/MNG-5042 [8]: http://jira.codehaus.org/browse/MNG-5056 [9]: http://jira.codehaus.org/browse/MNG-5084 [10]:
Re: Apache Maven distribution with fixes
On Jul 28, 2011, at 9:18 AM, Daniel Kulp wrote: On Thursday, July 28, 2011 8:59:09 AM Jason van Zyl wrote: On Jul 28, 2011, at 8:49 AM, Daniel Kulp wrote: On Thursday, July 28, 2011 7:41:16 AM Jason van Zyl wrote: I'll assume that this is fine and no one objects. I'll announce this on the user list later today. *THAT* I have a problem with.I don't consider these any different than our nightly snapshots or a different commercial build of an Apache project. In both of those cases, announcements about them or promoting them over the official project supplied releases is, IMO, not acceptable on the *users* list. I'm not promoting them over official project releases because there is no official project release, or nightly, that incorporates the fixes users have been asking for. This is a build Benjamin and I created to help users. I will not post anything on the user list, if as a PMC member you're telling me I can't. I'm saying you can't make a general announcement about it as it would be no different than making announcements of commercial versions of projects (that contain things like fixes and features not available from Apache builds) on other projects users lists. The fact that builds are specifically labeled sonatype really emphasizes the commercial nature of these builds. I'm honestly confused about how to label it which is why I asked. There's nothing commercial in the build, and we'll call it or label it however you like. I'm not particular worried about the names, I just want to get the build to users. In this particular case, if a specific user asks a question or has an issue, in a reply to that user, you can mention it, but make clear in the response: 1) There are non-sanctioned builds of Maven not endorsed by the Maven project. I think that was clear from my initial email. But if you have some text you want included I'm happy to include it. 2) It contains code and fixes that have not been incorporated into Apache Maven, not even to trunk. I think that was also clear from the email. 3) As such, any fixes (or new bugs) may not be present in a future version of Maven. Sure, I can add that explaining the Aether and Sisu situation. 4) They are using such builds at their own risk. Aren't they always? 5) Due to the above, it's not recommend to use these builds in any sort of production scenario. I'm not going to say that. I wouldn't build anything and offer it to users if I didn't think it was good. None of the above has anything to do with its production readiness. At the end of the day, if you really cared about the Maven users, you'd help us get an official Apache version of 3.0.4 out. The fact that you are unwilling to do what is necessary to make that happen is very frustrating to me. It's entirely within your control as a PMC member to accept the use of industry accept license from a world-class open source organization. I think personally and others from Sonatype have shown they care. We've done vast majority of work along the path of 3.x. Even with all the recent events we still just pushed back a slew of fixes across several code bases and produced a build because no one else here is stepping up to do any of the work necessary to keep the project going. Dan If you want to point a couple of your users at them to help test things or similar, fine as a lead up to 3.0.4. But they cannot be considered general available things similar to releases. Dan On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build is available here: http://people.apache.org/~jvanzyl Summary of the issues Fixes pushed back to the ASF: [MNG-5064][1] mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds) [MNG-5131][2] Wrong encoding for encrypted passwords [MNG-5113][3] NullPointerException on javadoc site generation [MNG-5137][4] Reactor resolution does not work for forked multi module builds [MNG-5096][5] exclusion on dependency with typetest-jar/type doesn't work in maven 3 [MNG-5135][6] Regression: in some cases aggregator mojo is unable
Re: Apache Maven distribution with fixes
We will rebuild it and call it whatever you guys want. I don't know what the rules are because they always seem to change, or what code has to be in a build to be called this or that. In this case we are just like anyone else in the community making a build to fix problems because there is nothing available officially. I'll call it whatever and then I'd like to tell people exactly what's in it, incorporate whatever you want us to say about it and then let users have it. On Jul 28, 2011, at 9:32 AM, John Casey wrote: Correct me if I'm wrong, but it's not okay to even call the binary maven-XXX or apache-maven-XXX (unless it's a snapshot) at all without getting a PMC vote. I thought there were rules in our ASF release protocols about that. On 7/28/11 9:18 AM, Daniel Kulp wrote: On Thursday, July 28, 2011 8:59:09 AM Jason van Zyl wrote: On Jul 28, 2011, at 8:49 AM, Daniel Kulp wrote: On Thursday, July 28, 2011 7:41:16 AM Jason van Zyl wrote: I'll assume that this is fine and no one objects. I'll announce this on the user list later today. *THAT* I have a problem with.I don't consider these any different than our nightly snapshots or a different commercial build of an Apache project. In both of those cases, announcements about them or promoting them over the official project supplied releases is, IMO, not acceptable on the *users* list. I'm not promoting them over official project releases because there is no official project release, or nightly, that incorporates the fixes users have been asking for. This is a build Benjamin and I created to help users. I will not post anything on the user list, if as a PMC member you're telling me I can't. I'm saying you can't make a general announcement about it as it would be no different than making announcements of commercial versions of projects (that contain things like fixes and features not available from Apache builds) on other projects users lists. The fact that builds are specifically labeled sonatype really emphasizes the commercial nature of these builds. In this particular case, if a specific user asks a question or has an issue, in a reply to that user, you can mention it, but make clear in the response: 1) There are non-sanctioned builds of Maven not endorsed by the Maven project. 2) It contains code and fixes that have not been incorporated into Apache Maven, not even to trunk. 3) As such, any fixes (or new bugs) may not be present in a future version of Maven. 4) They are using such builds at their own risk. 5) Due to the above, it's not recommend to use these builds in any sort of production scenario. At the end of the day, if you really cared about the Maven users, you'd help us get an official Apache version of 3.0.4 out. The fact that you are unwilling to do what is necessary to make that happen is very frustrating to me. Dan If you want to point a couple of your users at them to help test things or similar, fine as a lead up to 3.0.4. But they cannot be considered general available things similar to releases. Dan On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build is available here: http://people.apache.org/~jvanzyl Summary of the issues Fixes pushed back to the ASF: [MNG-5064][1] mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds) [MNG-5131][2] Wrong encoding for encrypted passwords [MNG-5113][3] NullPointerException on javadoc site generation [MNG-5137][4] Reactor resolution does not work for forked multi module builds [MNG-5096][5]exclusion ondependency with typetest-jar/type doesn't work in maven 3 [MNG-5135][6] Regression: in some cases aggregator mojo is unable to resolve dependencies with custom packaging Fixes not pushed back to the ASF as these are dependent on fixes in Eclipse Aether and Eclipse Sisu: [MNG-5042][7] Regression: CloningClassLoader causes StackOverflowError in groovy [MNG-5056][8] Test dependencies get packaged into WAR file. [MNG-5084][9] Resolver for plugins failing [MNG-5087][10] Maven 3 dependency resolution fails until
Re: Apache Maven distribution with fixes
On Thursday, July 28, 2011 9:32:07 AM John Casey wrote: Correct me if I'm wrong, but it's not okay to even call the binary maven-XXX or apache-maven-XXX (unless it's a snapshot) at all without getting a PMC vote. I thought there were rules in our ASF release protocols about that. That's actually a good point. In this case, the build contains stuff that is NOT part of any Apache Maven build, changes that are not in SVN, etc Thus, it's not Maven and cannot use those marks as part of the name.It can be Jason's build thingy based on Apache Maven, but not just Maven or Apache Maven. Also, as it is NOT a snapshot of code available in trunk/svn or part of the project, I also believe it's not something that can be distributed or promoted from Apache hardware or the Apache lists. Basically, it's not Maven and thus it cannot be treated as such. Dan On 7/28/11 9:18 AM, Daniel Kulp wrote: On Thursday, July 28, 2011 8:59:09 AM Jason van Zyl wrote: On Jul 28, 2011, at 8:49 AM, Daniel Kulp wrote: On Thursday, July 28, 2011 7:41:16 AM Jason van Zyl wrote: I'll assume that this is fine and no one objects. I'll announce this on the user list later today. *THAT* I have a problem with.I don't consider these any different than our nightly snapshots or a different commercial build of an Apache project. In both of those cases, announcements about them or promoting them over the official project supplied releases is, IMO, not acceptable on the *users* list. I'm not promoting them over official project releases because there is no official project release, or nightly, that incorporates the fixes users have been asking for. This is a build Benjamin and I created to help users. I will not post anything on the user list, if as a PMC member you're telling me I can't. I'm saying you can't make a general announcement about it as it would be no different than making announcements of commercial versions of projects (that contain things like fixes and features not available from Apache builds) on other projects users lists. The fact that builds are specifically labeled sonatype really emphasizes the commercial nature of these builds. In this particular case, if a specific user asks a question or has an issue, in a reply to that user, you can mention it, but make clear in the response: 1) There are non-sanctioned builds of Maven not endorsed by the Maven project. 2) It contains code and fixes that have not been incorporated into Apache Maven, not even to trunk. 3) As such, any fixes (or new bugs) may not be present in a future version of Maven. 4) They are using such builds at their own risk. 5) Due to the above, it's not recommend to use these builds in any sort of production scenario. At the end of the day, if you really cared about the Maven users, you'd help us get an official Apache version of 3.0.4 out. The fact that you are unwilling to do what is necessary to make that happen is very frustrating to me. Dan If you want to point a couple of your users at them to help test things or similar, fine as a lead up to 3.0.4. But they cannot be considered general available things similar to releases. Dan On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build is available here: http://people.apache.org/~jvanzyl Summary of the issues Fixes pushed back to the ASF: [MNG-5064][1] mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds) [MNG-5131][2] Wrong encoding for encrypted passwords [MNG-5113][3] NullPointerException on javadoc site generation [MNG-5137][4] Reactor resolution does not work for forked multi module builds [MNG-5096][5]exclusion ondependency with typetest-jar/type doesn't work in maven 3 [MNG-5135][6] Regression: in some cases aggregator mojo is unable to resolve dependencies with custom packaging Fixes not pushed back to the ASF as these are dependent on fixes in Eclipse Aether and Eclipse Sisu: [MNG-5042][7] Regression:
Re: Apache Maven distribution with fixes
On Jul 28, 2011, at 9:18 AM, Daniel Kulp wrote: At the end of the day, if you really cared about the Maven users, you'd help us get an official Apache version of 3.0.4 out. The fact that you are unwilling to do what is necessary to make that happen is very frustrating to me. How about you take the fixes we did push into SVN and do a 3.0.4 and then I can make another build with the rest of the fixes. Dan If you want to point a couple of your users at them to help test things or similar, fine as a lead up to 3.0.4. But they cannot be considered general available things similar to releases. Dan On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build is available here: http://people.apache.org/~jvanzyl Summary of the issues Fixes pushed back to the ASF: [MNG-5064][1] mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds) [MNG-5131][2] Wrong encoding for encrypted passwords [MNG-5113][3] NullPointerException on javadoc site generation [MNG-5137][4] Reactor resolution does not work for forked multi module builds [MNG-5096][5] exclusion on dependency with typetest-jar/type doesn't work in maven 3 [MNG-5135][6] Regression: in some cases aggregator mojo is unable to resolve dependencies with custom packaging Fixes not pushed back to the ASF as these are dependent on fixes in Eclipse Aether and Eclipse Sisu: [MNG-5042][7] Regression: CloningClassLoader causes StackOverflowError in groovy [MNG-5056][8] Test dependencies get packaged into WAR file. [MNG-5084][9] Resolver for plugins failing [MNG-5087][10] Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted [MNG-5125] [11]Regression: mvn 3.0.3 is extreemly slow with a large number of dependencies [MNG-5138][12] Dependency conflicts are extremely opaque [1]: http://jira.codehaus.org/browse/MNG-5064 [2]: http://jira.codehaus.org/browse/MNG-5131 [3]: http://jira.codehaus.org/browse/MNG-5113 [4]: http://jira.codehaus.org/browse/MNG-5137 [5]: http://jira.codehaus.org/browse/MNG-5096 [6]: http://jira.codehaus.org/browse/MNG-5135 [7]: http://jira.codehaus.org/browse/MNG-5042 [8]: http://jira.codehaus.org/browse/MNG-5056 [9]: http://jira.codehaus.org/browse/MNG-5084 [10]: http://jira.codehaus.org/browse/MNG-5087 [11]: http://jira.codehaus.org/browse/MNG-5125 [12]: http://jira.codehaus.org/browse/MNG-5138 [a]: http://eclipse.org/proposals/technology.aether/ [b]: http://eclipse.org/proposals/technology.sisu/ Thanks, Jason -- Jason van Zyl Eclipse Board Member Founder, Apache Maven http://twitter.com/jvanzyl - If I find ten thousand ways something won't work, I haven't failed. I am not discouraged, because every wrong attempt discarded is just one more step forward. -- Thomas Edison Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com - To unsubscribe, e-mail:
Re: Apache Maven distribution with fixes
The reason why no one committed to Aether beside yourself is partly that it requires to sign some CLA which only unilaterally grants rights (as we can certainly see now!). Which is another reason why I consider a fork to apache-extras a good idea. And don't come me with the argument that the Maven community is not able to maintain Maven without your help. At least there IS now a CI environment. And remember who built the git stuff on which your whole company is based upon? The argument is not that we cannot fix it becaues we are dumb little bunnies, but because the code is not under our control anymore! LieGrue, strub --- On Thu, 7/28/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 1:23 PM On Jul 28, 2011, at 8:52 AM, Mark Struberg wrote: Humm, guess there are only 3 options left in this case 1.) We wait 7 weeks or whatever time it takes (most probably it _will_ take more) Not likely, it will probably be shorter as I was being conservative. The scheduling at Eclipse is like a clockwork. Once the review period of over the creation review is immediately scheduled. The creation review and initial legal review will have no issues because nearly 100% of the code was written by Sonatype employees and we're all cleared at Eclipse. The code will start the parallel IP immediately and probably clear IP review very fast given it's all Sonatype code and there is already precedent for a lot of our code going into Eclipse. 2.) You ship an ALv2 licensed version of Aether and Sisu which we can incorporate into an upcoming maven-3.0.4. The proposals are posted, I'm not changing the licenses now. 3.) We fork the last ALv2 licensed Aether version back to the Maven project and fix the bugs ourself. I believe this will never happen and you will put the project in a very bad place if you attempt to do that. Since our last release not a single Maven committer outside of Sonatype has made any bug fixes or patches to the core (Paul made one small feature addition). You guys are talking about a new wagon, POM5 formats, new logging, artifact lookup indirection, but the day to day of actually patching and bug fixing is entirely absent and things like the plugin ITs are failing day after day in CI. Looking at the situation empirically, the probability that you will have the time and energy to try and patch Aether and Sisu given no one has patched any of the normal core code here I find a highly impractical and dangerous proposal. Path 1) doesn't preclude your participation and we've done nothing to hinder Kristian or Herve from participating. LieGrue, strub --- On Thu, 7/28/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 12:32 PM On Jul 28, 2011, at 8:25 AM, Mark Struberg wrote: mom jason. Before we ship 3.0.4 I'd like to fix the SCM URL postfix problem which exists in lots of DSCMs. Will do this in the next week. You probably have 6-7 weeks before an official 3.0.4 release would be made so you have plenty of time. If you are going to wait for Aether and Sisu to be provisioned at Eclipse then the total time for both of those to pass into that state is about 7 weeks. The build I proposed could not be an official release until such a time because there are fixes which rely on Sisu and Aether which are important for users. LieGrue, strub --- On Thu, 7/28/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 11:41 AM I'll assume that this is fine and no one objects. I'll announce this on the user list later today. On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build
Do we want to push a Maven Release Plugin 2.2.1 to include MRELEASE-697?
Since it is a rather nasty bug due to a typo on my behalf, do we push a release (2.2.1) now to include the fix and push all the unfixed issues back to 2.3 (where they currently live) -Stephen
Re: Do we want to push a Maven Release Plugin 2.2.1 to include MRELEASE-697?
If you are volunteering on the build, then +1 :) LieGrue, strub --- On Thu, 7/28/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: Do we want to push a Maven Release Plugin 2.2.1 to include MRELEASE-697? To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 2:21 PM Since it is a rather nasty bug due to a typo on my behalf, do we push a release (2.2.1) now to include the fix and push all the unfixed issues back to 2.3 (where they currently live) -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Apache Maven distribution with fixes
From my POV it could be a good thing for users to at least push a 3.0.4 release with what Benj fixed. If Mark is sure to be able to fix next week the bug he mentioned let's wait him. For Aether/Sisu and additional fixes and required dependencies I let others active dev/pmcs decide what they want. For me it's a without end conflict (at without good end for users and the community). cheers Arnaud On Thu, Jul 28, 2011 at 4:01 PM, Jason van Zyl ja...@sonatype.com wrote: On Jul 28, 2011, at 9:18 AM, Daniel Kulp wrote: At the end of the day, if you really cared about the Maven users, you'd help us get an official Apache version of 3.0.4 out. The fact that you are unwilling to do what is necessary to make that happen is very frustrating to me. How about you take the fixes we did push into SVN and do a 3.0.4 and then I can make another build with the rest of the fixes. Dan If you want to point a couple of your users at them to help test things or similar, fine as a lead up to 3.0.4. But they cannot be considered general available things similar to releases. Dan On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build is available here: http://people.apache.org/~jvanzyl Summary of the issues Fixes pushed back to the ASF: [MNG-5064][1] mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds) [MNG-5131][2] Wrong encoding for encrypted passwords [MNG-5113][3] NullPointerException on javadoc site generation [MNG-5137][4] Reactor resolution does not work for forked multi module builds [MNG-5096][5] exclusion on dependency with typetest-jar/type doesn't work in maven 3 [MNG-5135][6] Regression: in some cases aggregator mojo is unable to resolve dependencies with custom packaging Fixes not pushed back to the ASF as these are dependent on fixes in Eclipse Aether and Eclipse Sisu: [MNG-5042][7] Regression: CloningClassLoader causes StackOverflowError in groovy [MNG-5056][8] Test dependencies get packaged into WAR file. [MNG-5084][9] Resolver for plugins failing [MNG-5087][10] Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted [MNG-5125] [11]Regression: mvn 3.0.3 is extreemly slow with a large number of dependencies [MNG-5138][12] Dependency conflicts are extremely opaque [1]: http://jira.codehaus.org/browse/MNG-5064 [2]: http://jira.codehaus.org/browse/MNG-5131 [3]: http://jira.codehaus.org/browse/MNG-5113 [4]: http://jira.codehaus.org/browse/MNG-5137 [5]: http://jira.codehaus.org/browse/MNG-5096 [6]: http://jira.codehaus.org/browse/MNG-5135 [7]: http://jira.codehaus.org/browse/MNG-5042 [8]: http://jira.codehaus.org/browse/MNG-5056 [9]: http://jira.codehaus.org/browse/MNG-5084 [10]: http://jira.codehaus.org/browse/MNG-5087 [11]: http://jira.codehaus.org/browse/MNG-5125 [12]: http://jira.codehaus.org/browse/MNG-5138 [a]: http://eclipse.org/proposals/technology.aether/ [b]: http://eclipse.org/proposals/technology.sisu/ Thanks, Jason -- Jason van Zyl Eclipse Board Member Founder, Apache Maven http://twitter.com/jvanzyl - If I find ten thousand ways something won't work, I haven't failed. I am not discouraged, because every wrong attempt discarded is just one more step forward. -- Thomas Edison Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition
Re: Do we want to push a Maven Release Plugin 2.2.1 to include MRELEASE-697?
well it was my typo in the first place, so yeah I'm willing to RM it... feck it... i'll do it On 28 July 2011 15:26, Mark Struberg strub...@yahoo.de wrote: If you are volunteering on the build, then +1 :) LieGrue, strub --- On Thu, 7/28/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: Do we want to push a Maven Release Plugin 2.2.1 to include MRELEASE-697? To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 2:21 PM Since it is a rather nasty bug due to a typo on my behalf, do we push a release (2.2.1) now to include the fix and push all the unfixed issues back to 2.3 (where they currently live) -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Apache Maven distribution with fixes
perfectly fine with me. LieGrue, strub --- On Thu, 7/28/11, Arnaud Héritier aherit...@gmail.com wrote: From: Arnaud Héritier aherit...@gmail.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 2:27 PM From my POV it could be a good thing for users to at least push a 3.0.4 release with what Benj fixed. If Mark is sure to be able to fix next week the bug he mentioned let's wait him. For Aether/Sisu and additional fixes and required dependencies I let others active dev/pmcs decide what they want. For me it's a without end conflict (at without good end for users and the community). cheers Arnaud On Thu, Jul 28, 2011 at 4:01 PM, Jason van Zyl ja...@sonatype.com wrote: On Jul 28, 2011, at 9:18 AM, Daniel Kulp wrote: At the end of the day, if you really cared about the Maven users, you'd help us get an official Apache version of 3.0.4 out. The fact that you are unwilling to do what is necessary to make that happen is very frustrating to me. How about you take the fixes we did push into SVN and do a 3.0.4 and then I can make another build with the rest of the fixes. Dan If you want to point a couple of your users at them to help test things or similar, fine as a lead up to 3.0.4. But they cannot be considered general available things similar to releases. Dan On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build is available here: http://people.apache.org/~jvanzyl Summary of the issues Fixes pushed back to the ASF: [MNG-5064][1] mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds) [MNG-5131][2] Wrong encoding for encrypted passwords [MNG-5113][3] NullPointerException on javadoc site generation [MNG-5137][4] Reactor resolution does not work for forked multi module builds [MNG-5096][5] exclusion on dependency with typetest-jar/type doesn't work in maven 3 [MNG-5135][6] Regression: in some cases aggregator mojo is unable to resolve dependencies with custom packaging Fixes not pushed back to the ASF as these are dependent on fixes in Eclipse Aether and Eclipse Sisu: [MNG-5042][7] Regression: CloningClassLoader causes StackOverflowError in groovy [MNG-5056][8] Test dependencies get packaged into WAR file. [MNG-5084][9] Resolver for plugins failing [MNG-5087][10] Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted [MNG-5125] [11]Regression: mvn 3.0.3 is extreemly slow with a large number of dependencies [MNG-5138][12] Dependency conflicts are extremely opaque [1]: http://jira.codehaus.org/browse/MNG-5064 [2]: http://jira.codehaus.org/browse/MNG-5131 [3]: http://jira.codehaus.org/browse/MNG-5113 [4]: http://jira.codehaus.org/browse/MNG-5137 [5]: http://jira.codehaus.org/browse/MNG-5096 [6]: http://jira.codehaus.org/browse/MNG-5135 [7]: http://jira.codehaus.org/browse/MNG-5042 [8]: http://jira.codehaus.org/browse/MNG-5056 [9]: http://jira.codehaus.org/browse/MNG-5084 [10]: http://jira.codehaus.org/browse/MNG-5087 [11]: http://jira.codehaus.org/browse/MNG-5125 [12]: http://jira.codehaus.org/browse/MNG-5138 [a]: http://eclipse.org/proposals/technology.aether/ [b]: http://eclipse.org/proposals/technology.sisu/ Thanks, Jason -- Jason van Zyl Eclipse Board Member Founder, Apache Maven http://twitter.com/jvanzyl - If I find ten thousand ways something won't work, I haven't failed. I am not discouraged, because every wrong attempt discarded is just one more step forward. -- Thomas Edison Thanks, Jason -- Jason van Zyl Founder, Apache Maven
Re: Apache Maven distribution with fixes
I think apache-extras would be the appropriate place, too. I understand that there are concerns about code grants, etc. but at the same time there are reasons to believe there would be practical limitations preventing us from maintaining the fixes we might need in aether or sisu...even leaving aside the CLA. The pace may not be what people outside of the project want, but at least if you're a committer, you have the option to contribute to the project in a constructive way. As opposed to just arriving on-stage a couple hours after a barrage of commits, with a binary in hand. On 7/28/11 10:23 AM, Mark Struberg wrote: The reason why no one committed to Aether beside yourself is partly that it requires to sign some CLA which only unilaterally grants rights (as we can certainly see now!). Which is another reason why I consider a fork to apache-extras a good idea. And don't come me with the argument that the Maven community is not able to maintain Maven without your help. At least there IS now a CI environment. And remember who built the git stuff on which your whole company is based upon? The argument is not that we cannot fix it becaues we are dumb little bunnies, but because the code is not under our control anymore! LieGrue, strub --- On Thu, 7/28/11, Jason van Zylja...@sonatype.com wrote: From: Jason van Zylja...@sonatype.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers Listdev@maven.apache.org Date: Thursday, July 28, 2011, 1:23 PM On Jul 28, 2011, at 8:52 AM, Mark Struberg wrote: Humm, guess there are only 3 options left in this case 1.) We wait 7 weeks or whatever time it takes (most probably it _will_ take more) Not likely, it will probably be shorter as I was being conservative. The scheduling at Eclipse is like a clockwork. Once the review period of over the creation review is immediately scheduled. The creation review and initial legal review will have no issues because nearly 100% of the code was written by Sonatype employees and we're all cleared at Eclipse. The code will start the parallel IP immediately and probably clear IP review very fast given it's all Sonatype code and there is already precedent for a lot of our code going into Eclipse. 2.) You ship an ALv2 licensed version of Aether and Sisu which we can incorporate into an upcoming maven-3.0.4. The proposals are posted, I'm not changing the licenses now. 3.) We fork the last ALv2 licensed Aether version back to the Maven project and fix the bugs ourself. I believe this will never happen and you will put the project in a very bad place if you attempt to do that. Since our last release not a single Maven committer outside of Sonatype has made any bug fixes or patches to the core (Paul made one small feature addition). You guys are talking about a new wagon, POM5 formats, new logging, artifact lookup indirection, but the day to day of actually patching and bug fixing is entirely absent and things like the plugin ITs are failing day after day in CI. Looking at the situation empirically, the probability that you will have the time and energy to try and patch Aether and Sisu given no one has patched any of the normal core code here I find a highly impractical and dangerous proposal. Path 1) doesn't preclude your participation and we've done nothing to hinder Kristian or Herve from participating. LieGrue, strub --- On Thu, 7/28/11, Jason van Zylja...@sonatype.com wrote: From: Jason van Zylja...@sonatype.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers Listdev@maven.apache.org Date: Thursday, July 28, 2011, 12:32 PM On Jul 28, 2011, at 8:25 AM, Mark Struberg wrote: mom jason. Before we ship 3.0.4 I'd like to fix the SCM URL postfix problem which exists in lots of DSCMs. Will do this in the next week. You probably have 6-7 weeks before an official 3.0.4 release would be made so you have plenty of time. If you are going to wait for Aether and Sisu to be provisioned at Eclipse then the total time for both of those to pass into that state is about 7 weeks. The build I proposed could not be an official release until such a time because there are fixes which rely on Sisu and Aether which are important for users. LieGrue, strub --- On Thu, 7/28/11, Jason van Zylja...@sonatype.com wrote: From: Jason van Zylja...@sonatype.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers Listdev@maven.apache.org Date: Thursday, July 28, 2011, 11:41 AM I'll assume that this is fine and no one objects. I'll announce this on the user list later today. On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official
Re: Apache Maven distribution with fixes
+1 Can bentmann's fixes be applied without adopting the updated version of Aether? On 7/28/11 10:27 AM, Arnaud Héritier wrote: From my POV it could be a good thing for users to at least push a 3.0.4 release with what Benj fixed. If Mark is sure to be able to fix next week the bug he mentioned let's wait him. For Aether/Sisu and additional fixes and required dependencies I let others active dev/pmcs decide what they want. For me it's a without end conflict (at without good end for users and the community). cheers Arnaud On Thu, Jul 28, 2011 at 4:01 PM, Jason van Zylja...@sonatype.com wrote: On Jul 28, 2011, at 9:18 AM, Daniel Kulp wrote: At the end of the day, if you really cared about the Maven users, you'd help us get an official Apache version of 3.0.4 out. The fact that you are unwilling to do what is necessary to make that happen is very frustrating to me. How about you take the fixes we did push into SVN and do a 3.0.4 and then I can make another build with the rest of the fixes. Dan If you want to point a couple of your users at them to help test things or similar, fine as a lead up to 3.0.4. But they cannot be considered general available things similar to releases. Dan On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote: Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build is available here: http://people.apache.org/~jvanzyl Summary of the issues Fixes pushed back to the ASF: [MNG-5064][1] mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds) [MNG-5131][2] Wrong encoding for encrypted passwords [MNG-5113][3] NullPointerException on javadoc site generation [MNG-5137][4] Reactor resolution does not work for forked multi module builds [MNG-5096][5]exclusion ondependency with typetest-jar/type doesn't work in maven 3 [MNG-5135][6] Regression: in some cases aggregator mojo is unable to resolve dependencies with custom packaging Fixes not pushed back to the ASF as these are dependent on fixes in Eclipse Aether and Eclipse Sisu: [MNG-5042][7] Regression: CloningClassLoader causes StackOverflowError in groovy [MNG-5056][8] Test dependencies get packaged into WAR file. [MNG-5084][9] Resolver for plugins failing [MNG-5087][10] Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted [MNG-5125] [11]Regression: mvn 3.0.3 is extreemly slow with a large number of dependencies [MNG-5138][12] Dependency conflicts are extremely opaque [1]: http://jira.codehaus.org/browse/MNG-5064 [2]: http://jira.codehaus.org/browse/MNG-5131 [3]: http://jira.codehaus.org/browse/MNG-5113 [4]: http://jira.codehaus.org/browse/MNG-5137 [5]: http://jira.codehaus.org/browse/MNG-5096 [6]: http://jira.codehaus.org/browse/MNG-5135 [7]: http://jira.codehaus.org/browse/MNG-5042 [8]: http://jira.codehaus.org/browse/MNG-5056 [9]: http://jira.codehaus.org/browse/MNG-5084 [10]: http://jira.codehaus.org/browse/MNG-5087 [11]: http://jira.codehaus.org/browse/MNG-5125 [12]: http://jira.codehaus.org/browse/MNG-5138 [a]: http://eclipse.org/proposals/technology.aether/ [b]: http://eclipse.org/proposals/technology.sisu/ Thanks, Jason -- Jason van Zyl Eclipse Board Member Founder, Apache Maven http://twitter.com/jvanzyl - If I find ten thousand ways something won't work, I haven't failed. I am not discouraged, because every wrong attempt discarded is just one more step forward. -- Thomas Edison Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition Thanks, Jason --
Re: Apache Maven distribution with fixes
On Jul 28, 2011, at 10:23 AM, Mark Struberg wrote: The reason why no one committed to Aether beside yourself is partly that it requires to sign some CLA which only unilaterally grants rights (as we can certainly see now!). Have you read the Sonatype CLA? The contributor keeps retains copyright and Sonatype is granted the license. Much the same way the Apache or Eclipse CLAs work. We changed that a long time ago when Brett pointed it out. Additionally Hervé and Kristian signed the CLA. It's not just Sonatype employees. Which is another reason why I consider a fork to apache-extras a good idea. And don't come me with the argument that the Maven community is not able to maintain Maven without your help. At least there IS now a CI environment. And remember who built the git stuff on which your whole company is based upon? I'm not sure what you're referring to, we don't even sell anything with git in it. m2eclipse has an m2eclipse-egit connector but we stopped using jgit-simple, if that's the work you're referring to, and use the JGit APIs directly now[1]. The argument is not that we cannot fix it becaues we are dumb little bunnies, but because the code is not under our control anymore! I specifically said that folks here, from empirical observation, do not have the time or energy. Additionally I would say you don't have much experience in the Aether and Sisu codebases. I most definitely did not say you were dumb, or didn't have the aptitude. But having the aptitude still puts you a long way from working with the code effectively. There's nothing magical about it, it's the same as any other body of code in that it takes time, and energy to learn and gain experience with a new codebase and become effective with it. [1]: https://github.com/sonatype/m2eclipse-egit/blob/master/org.sonatype.m2e.egit.target-platform/e37.target LieGrue, strub --- On Thu, 7/28/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 1:23 PM On Jul 28, 2011, at 8:52 AM, Mark Struberg wrote: Humm, guess there are only 3 options left in this case 1.) We wait 7 weeks or whatever time it takes (most probably it _will_ take more) Not likely, it will probably be shorter as I was being conservative. The scheduling at Eclipse is like a clockwork. Once the review period of over the creation review is immediately scheduled. The creation review and initial legal review will have no issues because nearly 100% of the code was written by Sonatype employees and we're all cleared at Eclipse. The code will start the parallel IP immediately and probably clear IP review very fast given it's all Sonatype code and there is already precedent for a lot of our code going into Eclipse. 2.) You ship an ALv2 licensed version of Aether and Sisu which we can incorporate into an upcoming maven-3.0.4. The proposals are posted, I'm not changing the licenses now. 3.) We fork the last ALv2 licensed Aether version back to the Maven project and fix the bugs ourself. I believe this will never happen and you will put the project in a very bad place if you attempt to do that. Since our last release not a single Maven committer outside of Sonatype has made any bug fixes or patches to the core (Paul made one small feature addition). You guys are talking about a new wagon, POM5 formats, new logging, artifact lookup indirection, but the day to day of actually patching and bug fixing is entirely absent and things like the plugin ITs are failing day after day in CI. Looking at the situation empirically, the probability that you will have the time and energy to try and patch Aether and Sisu given no one has patched any of the normal core code here I find a highly impractical and dangerous proposal. Path 1) doesn't preclude your participation and we've done nothing to hinder Kristian or Herve from participating. LieGrue, strub --- On Thu, 7/28/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 12:32 PM On Jul 28, 2011, at 8:25 AM, Mark Struberg wrote: mom jason. Before we ship 3.0.4 I'd like to fix the SCM URL postfix problem which exists in lots of DSCMs. Will do this in the next week. You probably have 6-7 weeks before an official 3.0.4 release would be made so you have plenty of time. If you are going to wait for Aether and Sisu to be provisioned at Eclipse then the total time for both of those to pass into that state is about 7 weeks. The build I proposed could not be an official release until such a time because there are fixes which rely on Sisu and Aether which are important for users. LieGrue, strub
Re: Do we want to push a Maven Release Plugin 2.2.1 to include MRELEASE-697?
+1 for a 2.2.1 Thanks - Mail original - De : Stephen Connolly stephen.alan.conno...@gmail.com À : Maven Developers List dev@maven.apache.org Cc : Envoyé le : Jeudi 28 Juillet 2011 16h28 Objet : Re: Do we want to push a Maven Release Plugin 2.2.1 to include MRELEASE-697? well it was my typo in the first place, so yeah I'm willing to RM it... feck it... i'll do it On 28 July 2011 15:26, Mark Struberg strub...@yahoo.de wrote: If you are volunteering on the build, then +1 :) LieGrue, strub --- On Thu, 7/28/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: Do we want to push a Maven Release Plugin 2.2.1 to include MRELEASE-697? To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 2:21 PM Since it is a rather nasty bug due to a typo on my behalf, do we push a release (2.2.1) now to include the fix and push all the unfixed issues back to 2.3 (where they currently live) -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Maven Release plugin version 2.2.1
Hi, This is a patch release to fix a particularly nasty regression: http://jira.codehaus.org/browse/MRELEASE-697 We solved 3 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11144styleName=Htmlversion=17502 Staging repo: https://repository.apache.org/content/repositories/maven-009/ Source distribution: https://repository.apache.org/content/repositories/maven-009/org/apache/maven/release/maven-release/2.2.1/maven-release-2.2.1-source-release.zip SCM tag: http://svn.apache.org/repos/asf/maven/release/tags/maven-release-2.2.1 Staging site: http://maven.apache.org/plugins/maven-release-plugin-2.2.1/ http://maven.apache.org/maven-release/staging/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Guide to previewing site content ahead of the sync: http://www.apache.org/dev/project-site.html (and search on the page for HTTP proxy) Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Apache Maven distribution with fixes
On 7/28/11 10:43 AM, Jason van Zyl wrote: On Jul 28, 2011, at 10:23 AM, Mark Struberg wrote: The reason why no one committed to Aether beside yourself is partly that it requires to sign some CLA which only unilaterally grants rights (as we can certainly see now!). Have you read the Sonatype CLA? The contributor keeps retains copyright and Sonatype is granted the license. Much the same way the Apache or Eclipse CLAs work. We changed that a long time ago when Brett pointed it out. Additionally Hervé and Kristian signed the CLA. It's not just Sonatype employees. So you had to get approval from all contributors before switching to EPl-only? Which is another reason why I consider a fork to apache-extras a good idea. And don't come me with the argument that the Maven community is not able to maintain Maven without your help. At least there IS now a CI environment. And remember who built the git stuff on which your whole company is based upon? I'm not sure what you're referring to, we don't even sell anything with git in it. m2eclipse has an m2eclipse-egit connector but we stopped using jgit-simple, if that's the work you're referring to, and use the JGit APIs directly now[1]. The argument is not that we cannot fix it becaues we are dumb little bunnies, but because the code is not under our control anymore! I specifically said that folks here, from empirical observation, do not have the time or energy. Additionally I would say you don't have much experience in the Aether and Sisu codebases. I most definitely did not say you were dumb, or didn't have the aptitude. But having the aptitude still puts you a long way from working with the code effectively. There's nothing magical about it, it's the same as any other body of code in that it takes time, and energy to learn and gain experience with a new codebase and become effective with it. [1]: https://github.com/sonatype/m2eclipse-egit/blob/master/org.sonatype.m2e.egit.target-platform/e37.target LieGrue, strub --- On Thu, 7/28/11, Jason van Zylja...@sonatype.com wrote: From: Jason van Zylja...@sonatype.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers Listdev@maven.apache.org Date: Thursday, July 28, 2011, 1:23 PM On Jul 28, 2011, at 8:52 AM, Mark Struberg wrote: Humm, guess there are only 3 options left in this case 1.) We wait 7 weeks or whatever time it takes (most probably it _will_ take more) Not likely, it will probably be shorter as I was being conservative. The scheduling at Eclipse is like a clockwork. Once the review period of over the creation review is immediately scheduled. The creation review and initial legal review will have no issues because nearly 100% of the code was written by Sonatype employees and we're all cleared at Eclipse. The code will start the parallel IP immediately and probably clear IP review very fast given it's all Sonatype code and there is already precedent for a lot of our code going into Eclipse. 2.) You ship an ALv2 licensed version of Aether and Sisu which we can incorporate into an upcoming maven-3.0.4. The proposals are posted, I'm not changing the licenses now. 3.) We fork the last ALv2 licensed Aether version back to the Maven project and fix the bugs ourself. I believe this will never happen and you will put the project in a very bad place if you attempt to do that. Since our last release not a single Maven committer outside of Sonatype has made any bug fixes or patches to the core (Paul made one small feature addition). You guys are talking about a new wagon, POM5 formats, new logging, artifact lookup indirection, but the day to day of actually patching and bug fixing is entirely absent and things like the plugin ITs are failing day after day in CI. Looking at the situation empirically, the probability that you will have the time and energy to try and patch Aether and Sisu given no one has patched any of the normal core code here I find a highly impractical and dangerous proposal. Path 1) doesn't preclude your participation and we've done nothing to hinder Kristian or Herve from participating. LieGrue, strub --- On Thu, 7/28/11, Jason van Zylja...@sonatype.com wrote: From: Jason van Zylja...@sonatype.com Subject: Re: Apache Maven distribution with fixes To: Maven Developers Listdev@maven.apache.org Date: Thursday, July 28, 2011, 12:32 PM On Jul 28, 2011, at 8:25 AM, Mark Struberg wrote: mom jason. Before we ship 3.0.4 I'd like to fix the SCM URL postfix problem which exists in lots of DSCMs. Will do this in the next week. You probably have 6-7 weeks before an official 3.0.4 release would be made so you have plenty of time. If you are going to wait for Aether and Sisu to be provisioned at Eclipse then the total time for both of those to pass into that state is about 7 weeks. The build I proposed could not be an official release until such a time because there are fixes which rely on Sisu and
Re: [VOTE] Release Maven Release plugin version 2.2.1
+1 On 7/28/11 10:56 AM, Stephen Connolly wrote: Hi, This is a patch release to fix a particularly nasty regression: http://jira.codehaus.org/browse/MRELEASE-697 We solved 3 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11144styleName=Htmlversion=17502 Staging repo: https://repository.apache.org/content/repositories/maven-009/ Source distribution: https://repository.apache.org/content/repositories/maven-009/org/apache/maven/release/maven-release/2.2.1/maven-release-2.2.1-source-release.zip SCM tag: http://svn.apache.org/repos/asf/maven/release/tags/maven-release-2.2.1 Staging site: http://maven.apache.org/plugins/maven-release-plugin-2.2.1/ http://maven.apache.org/maven-release/staging/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Guide to previewing site content ahead of the sync: http://www.apache.org/dev/project-site.html (and search on the page for HTTP proxy) Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM design principles: what qualifies for the model?
On 7/28/11 7:43 AM, Benson Margulies wrote: I'm trying to think about the questions of what might go into pom5, and I realized that I am confused about the current design. M3 deprecated 'reporting' but not 'scm'. I don't see the logic. I propose to divide all POM content into two categories: things read by the core of maven, and things read by plugins. I think you need another category: things that describe the project infrastructure. While there may not be plugins used in the project's build that require the scm/ tag, it would be a MAJOR problem for tooling that reads POMs from the repository not to have access to that information. Even though some projects don't provide it, it's possible to mandate within an organization that this section be present and correct. If we instead mandate that a particular plugin configuration be present and correct, this is a very different type of instruction. Plugins are the mechanism by which projects get built, and those use a mix of project-level information and plugin-level information. However, there's another aspect of the POM, which is purely descriptive...to give people a fair chance at interacting with project infrastructure if all they have is the POM. The rationale for eliminating reporting, as I thought I understood it, was that it was 'only read by a plugin.' Well, scm, licensing, distribution management, resources, ... most of the POM is 'only read by a plugin.' Sometimes by plugins that are called out in the superpom, and sometimes not. scm strikes me particularly as a target: It's used for three things, and those things can be in conflict. One is to produce a human-readable report about where humans can find the source, another is to give the release plugin enough information to tag a release, and the third is to provide defaults to the maven-scm-plugin. I also have tooling that relies on this section to checkout and perform a test build, for all dependencies of a given project. This external tooling should have access to project infrastructure. If we want to use a different - more flexible? - syntax to provide that information, that's totally cool...but we can't just ignore that use case of the POM. We wouldn't be having this painful discussion about how to make git work if the second item had just been handled by configuration in the release plugin itself instead of being a top-level element. On the other hand, we'd be having a problem allowing for the 'base my url on my parent's url'. Can someone clarify this for me? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Apache Maven distribution with fixes
On 28 July 2011 16:03, John Casey jdca...@commonjava.org wrote: On 7/28/11 10:43 AM, Jason van Zyl wrote: On Jul 28, 2011, at 10:23 AM, Mark Struberg wrote: The reason why no one committed to Aether beside yourself is partly that it requires to sign some CLA which only unilaterally grants rights (as we can certainly see now!). Have you read the Sonatype CLA? The contributor keeps retains copyright [OT] I've just read it now... it seems entirely one-sided it is all Contributor grants rights to Sonatype, but it seems to me that there is nothing return... IANAL, but AFAIK such one-sided contracts can become null and void... certainly I have been advised that in Ireland a 1-sided contract cannot be made to stand up in court... I do hope for Sonatype's sake that you have the contract rooted in a jurisdiction that permits 1-sided contracts. [/OT] and Sonatype is granted the license. Much the same way the Apache or Eclipse CLAs work. We changed that a long time ago when Brett pointed it out. Additionally Hervé and Kristian signed the CLA. It's not just Sonatype employees. So you had to get approval from all contributors before switching to EPl-only? I'm curious to hear your answer to this - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Release plugin version 2.2.1
+1 source looks ok, signing looks ok, did a quick run on my test project - also ok. LieGrue, strub --- On Thu, 7/28/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: [VOTE] Release Maven Release plugin version 2.2.1 To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 2:56 PM Hi, This is a patch release to fix a particularly nasty regression: http://jira.codehaus.org/browse/MRELEASE-697 We solved 3 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11144styleName=Htmlversion=17502 Staging repo: https://repository.apache.org/content/repositories/maven-009/ Source distribution: https://repository.apache.org/content/repositories/maven-009/org/apache/maven/release/maven-release/2.2.1/maven-release-2.2.1-source-release.zip SCM tag: http://svn.apache.org/repos/asf/maven/release/tags/maven-release-2.2.1 Staging site: http://maven.apache.org/plugins/maven-release-plugin-2.2.1/ http://maven.apache.org/maven-release/staging/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Guide to previewing site content ahead of the sync: http://www.apache.org/dev/project-site.html (and search on the page for HTTP proxy) Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, -Stephen - 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: Apache Maven distribution with fixes
On Thu, Jul 28, 2011 at 5:11 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 28 July 2011 16:03, John Casey jdca...@commonjava.org wrote: On 7/28/11 10:43 AM, Jason van Zyl wrote: On Jul 28, 2011, at 10:23 AM, Mark Struberg wrote: The reason why no one committed to Aether beside yourself is partly that it requires to sign some CLA which only unilaterally grants rights (as we can certainly see now!). Have you read the Sonatype CLA? The contributor keeps retains copyright [OT] I've just read it now... it seems entirely one-sided it is all Contributor grants rights to Sonatype, but it seems to me that there is nothing return... IANAL, but AFAIK such one-sided contracts can become null and void... certainly I have been advised that in Ireland a 1-sided contract cannot be made to stand up in court... I do hope for Sonatype's sake that you have the contract rooted in a jurisdiction that permits 1-sided contracts. [/OT] it seems unlikely. The same sort of agreement is signed by everyone contributing to netbeans and sun changed the license once or twice as well. same with eclipse I think. and Sonatype is granted the license. Much the same way the Apache or Eclipse CLAs work. We changed that a long time ago when Brett pointed it out. Additionally Hervé and Kristian signed the CLA. It's not just Sonatype employees. So you had to get approval from all contributors before switching to EPl-only? the point if CLA is not to have to hunt to all past contributors when changing license AFAIK. Milos I'm curious to hear your answer to this - 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: Apache Maven distribution with fixes
Not sure what version you're reading but we specifically changed so that said author retains copyright and Sonatype is granted a perpetual license. Changed specifically when Brett brought it up, we brought it in line with what Apache and Eclipse do. On Jul 28, 2011, at 11:11 AM, Stephen Connolly wrote: On 28 July 2011 16:03, John Casey jdca...@commonjava.org wrote: On 7/28/11 10:43 AM, Jason van Zyl wrote: On Jul 28, 2011, at 10:23 AM, Mark Struberg wrote: The reason why no one committed to Aether beside yourself is partly that it requires to sign some CLA which only unilaterally grants rights (as we can certainly see now!). Have you read the Sonatype CLA? The contributor keeps retains copyright [OT] I've just read it now... it seems entirely one-sided it is all Contributor grants rights to Sonatype, but it seems to me that there is nothing return... IANAL, but AFAIK such one-sided contracts can become null and void... certainly I have been advised that in Ireland a 1-sided contract cannot be made to stand up in court... I do hope for Sonatype's sake that you have the contract rooted in a jurisdiction that permits 1-sided contracts. [/OT] and Sonatype is granted the license. Much the same way the Apache or Eclipse CLAs work. We changed that a long time ago when Brett pointed it out. Additionally Hervé and Kristian signed the CLA. It's not just Sonatype employees. So you had to get approval from all contributors before switching to EPl-only? I'm curious to hear your answer to this - 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 -
Re: Apache Maven distribution with fixes
On Jul 28, 2011, at 11:03 AM, John Casey wrote: On 7/28/11 10:43 AM, Jason van Zyl wrote: On Jul 28, 2011, at 10:23 AM, Mark Struberg wrote: The reason why no one committed to Aether beside yourself is partly that it requires to sign some CLA which only unilaterally grants rights (as we can certainly see now!). Have you read the Sonatype CLA? The contributor keeps retains copyright and Sonatype is granted the license. Much the same way the Apache or Eclipse CLAs work. We changed that a long time ago when Brett pointed it out. Additionally Hervé and Kristian signed the CLA. It's not just Sonatype employees. So you had to get approval from all contributors before switching to EPl-only? Sonatype is granted perpetual rights which includes relicensing. But Hervé and Kristian are free do to whatever with their contributions i.e. push them into a fork of Aether or Sisu. I believe that we changed the contributor gets perpetual rights to Sonatype gets perpetual rights after most/all of their contributions but if they wanted to take their code and do whatever with it we'd grant it back regardless of the date of the license change. 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
Re: Apache Maven distribution with fixes
On 28 July 2011 16:18, Milos Kleint mkle...@gmail.com wrote: On Thu, Jul 28, 2011 at 5:11 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 28 July 2011 16:03, John Casey jdca...@commonjava.org wrote: On 7/28/11 10:43 AM, Jason van Zyl wrote: On Jul 28, 2011, at 10:23 AM, Mark Struberg wrote: The reason why no one committed to Aether beside yourself is partly that it requires to sign some CLA which only unilaterally grants rights (as we can certainly see now!). Have you read the Sonatype CLA? The contributor keeps retains copyright [OT] I've just read it now... it seems entirely one-sided it is all Contributor grants rights to Sonatype, but it seems to me that there is nothing return... IANAL, but AFAIK such one-sided contracts can become null and void... certainly I have been advised that in Ireland a 1-sided contract cannot be made to stand up in court... I do hope for Sonatype's sake that you have the contract rooted in a jurisdiction that permits 1-sided contracts. [/OT] it seems unlikely. The same sort of agreement is signed by everyone contributing to netbeans and sun changed the license once or twice as well. same with eclipse I think. The eclipse one grants the contributor write access in return for certain grants of rights to eclipse. same for sun and netbeans, but the sonatype cla that I found via google: http://www.sonatype.org/SonatypeCLA.pdf does not give commit access and specifically states that sonatype may never use the submitted patches... that is why I think it is one-sided... and that is where I have the question. If I am looking at the wrong CLA, fair enough and Sonatype is granted the license. Much the same way the Apache or Eclipse CLAs work. We changed that a long time ago when Brett pointed it out. Additionally Hervé and Kristian signed the CLA. It's not just Sonatype employees. So you had to get approval from all contributors before switching to EPl-only? the point if CLA is not to have to hunt to all past contributors when changing license AFAIK. Milos I'm curious to hear your answer to this - 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
[DISCUSS] SCM child-project URL composition
Hi! problem description --- SCM URLs currently automatically get extended for child modules. E.g. from svn://mycompany.com/myproject in the parent pom, a child module 'frontend' will result in getting a SCM URL svn://mycompany.com/myproject/frontend This is fine for SVN and CVS, but broken for GIT, HG, etc because the SCM URL is 'static' for them. proposal --- Since we cannot put this information into the various scm plugins (because of a 'definition cycle' as explained here [1]) we could split the URL construction into scmUrlAppendChild=true/false and make it configurable. The configuration could be controlled via a Modello config, my suggestion would be to just add them to toolchains.mdo. I'd just add a String property which holds a regular expression which parses the SCM URL and decides upon this whether the appending should get activated, e.g. for all SCMs which contain 'scm:svn:' or 'scm:cvs:' or the java-svn (olamy, you know the plexus key for that?) If there is a better place to put that config or a better way to get the info, then please speak up now :) I think this change would be backward compatible and doesn't need any pom changes. It also could easily get back-ported to mvn2 if needed. Are there other URLS which also need a similar distinction while building the model? WDYT? txs and LieGrue, strub [1] http://markmail.org/message/npw3hp6aloa55ctf - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM design principles: what qualifies for the model?
I'm not trying to argue to murder scm and friends, just to understand how we got here. I am now going to go to the wiki page and add some more thinking about the use of extensible (e.g. property-set) XML for things like scm. On Thu, Jul 28, 2011 at 11:10 AM, John Casey jdca...@commonjava.org wrote: On 7/28/11 7:43 AM, Benson Margulies wrote: I'm trying to think about the questions of what might go into pom5, and I realized that I am confused about the current design. M3 deprecated 'reporting' but not 'scm'. I don't see the logic. I propose to divide all POM content into two categories: things read by the core of maven, and things read by plugins. I think you need another category: things that describe the project infrastructure. While there may not be plugins used in the project's build that require the scm/ tag, it would be a MAJOR problem for tooling that reads POMs from the repository not to have access to that information. Even though some projects don't provide it, it's possible to mandate within an organization that this section be present and correct. If we instead mandate that a particular plugin configuration be present and correct, this is a very different type of instruction. Plugins are the mechanism by which projects get built, and those use a mix of project-level information and plugin-level information. However, there's another aspect of the POM, which is purely descriptive...to give people a fair chance at interacting with project infrastructure if all they have is the POM. The rationale for eliminating reporting, as I thought I understood it, was that it was 'only read by a plugin.' Well, scm, licensing, distribution management, resources, ... most of the POM is 'only read by a plugin.' Sometimes by plugins that are called out in the superpom, and sometimes not. scm strikes me particularly as a target: It's used for three things, and those things can be in conflict. One is to produce a human-readable report about where humans can find the source, another is to give the release plugin enough information to tag a release, and the third is to provide defaults to the maven-scm-plugin. I also have tooling that relies on this section to checkout and perform a test build, for all dependencies of a given project. This external tooling should have access to project infrastructure. If we want to use a different - more flexible? - syntax to provide that information, that's totally cool...but we can't just ignore that use case of the POM. We wouldn't be having this painful discussion about how to make git work if the second item had just been handled by configuration in the release plugin itself instead of being a top-level element. On the other hand, we'd be having a problem allowing for the 'base my url on my parent's url'. Can someone clarify this for me? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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: POM design principles: what qualifies for the model?
On 7/28/11 12:51 PM, Benson Margulies wrote: I'm not trying to argue to murderscm and friends, just to understand how we got here. murder nice. :-) I am now going to go to the wiki page and add some more thinking about the use of extensible (e.g. property-set) XML for things like scm. what about existing xml tools for this: namespaces, URNs, etc.? I know we'd have to re-solve the problem for other syntaxes, but that's minor compared to creating the other syntax in the first place, right? On Thu, Jul 28, 2011 at 11:10 AM, John Caseyjdca...@commonjava.org wrote: On 7/28/11 7:43 AM, Benson Margulies wrote: I'm trying to think about the questions of what might go into pom5, and I realized that I am confused about the current design. M3 deprecated 'reporting' but not 'scm'. I don't see the logic. I propose to divide all POM content into two categories: things read by the core of maven, and things read by plugins. I think you need another category: things that describe the project infrastructure. While there may not be plugins used in the project's build that require the scm/ tag, it would be a MAJOR problem for tooling that reads POMs from the repository not to have access to that information. Even though some projects don't provide it, it's possible to mandate within an organization that this section be present and correct. If we instead mandate that a particular plugin configuration be present and correct, this is a very different type of instruction. Plugins are the mechanism by which projects get built, and those use a mix of project-level information and plugin-level information. However, there's another aspect of the POM, which is purely descriptive...to give people a fair chance at interacting with project infrastructure if all they have is the POM. The rationale for eliminating reporting, as I thought I understood it, was that it was 'only read by a plugin.' Well, scm, licensing, distribution management, resources, ... most of the POM is 'only read by a plugin.' Sometimes by plugins that are called out in the superpom, and sometimes not. scm strikes me particularly as a target: It's used for three things, and those things can be in conflict. One is to produce a human-readable report about where humans can find the source, another is to give the release plugin enough information to tag a release, and the third is to provide defaults to the maven-scm-plugin. I also have tooling that relies on this section to checkout and perform a test build, for all dependencies of a given project. This external tooling should have access to project infrastructure. If we want to use a different - more flexible? - syntax to provide that information, that's totally cool...but we can't just ignore that use case of the POM. We wouldn't be having this painful discussion about how to make git work if the second item had just been handled by configuration in the release plugin itself instead of being a top-level element. On the other hand, we'd be having a problem allowing for the 'base my url on my parent's url'. Can someone clarify this for me? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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 -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM design principles: what qualifies for the model?
I am now going to go to the wiki page and add some more thinking about the use of extensible (e.g. property-set) XML for things like scm. what about existing xml tools for this: namespaces, URNs, etc.? Let me do some thinking and writing on the wiki. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Do we want to push a Maven Release Plugin 2.2.1 to include MRELEASE-697?
+1 Le 28 juil. 2011 à 16:49, Julien HENRY henr...@yahoo.fr a écrit : +1 for a 2.2.1 Thanks - Mail original - De : Stephen Connolly stephen.alan.conno...@gmail.com À : Maven Developers List dev@maven.apache.org Cc : Envoyé le : Jeudi 28 Juillet 2011 16h28 Objet : Re: Do we want to push a Maven Release Plugin 2.2.1 to include MRELEASE-697? well it was my typo in the first place, so yeah I'm willing to RM it... feck it... i'll do it On 28 July 2011 15:26, Mark Struberg strub...@yahoo.de wrote: If you are volunteering on the build, then +1 :) LieGrue, strub --- On Thu, 7/28/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: Do we want to push a Maven Release Plugin 2.2.1 to include MRELEASE-697? To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 2:21 PM Since it is a rather nasty bug due to a typo on my behalf, do we push a release (2.2.1) now to include the fix and push all the unfixed issues back to 2.3 (where they currently live) -Stephen - 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: [DISCUSS] SCM child-project URL composition
Would it be better to have a syntax to mark a URL as literal, not to be calculated or used as the basis of calculation? That way, we don't have to worry about adjusting to new SCMs or other places where we want to use it...new SCMs could be added via build extension, IIRC, so this is particularly important there. WDYT? On 7/28/11 12:46 PM, Mark Struberg wrote: Hi! problem description --- SCM URLs currently automatically get extended for child modules. E.g. from svn://mycompany.com/myproject in the parent pom, a child module 'frontend' will result in getting a SCM URL svn://mycompany.com/myproject/frontend This is fine for SVN and CVS, but broken for GIT, HG, etc because the SCM URL is 'static' for them. proposal --- Since we cannot put this information into the various scm plugins (because of a 'definition cycle' as explained here [1]) we could split the URL construction into scmUrlAppendChild=true/false and make it configurable. The configuration could be controlled via a Modello config, my suggestion would be to just add them to toolchains.mdo. I'd just add a String property which holds a regular expression which parses the SCM URL and decides upon this whether the appending should get activated, e.g. for all SCMs which contain 'scm:svn:' or 'scm:cvs:' or the java-svn (olamy, you know the plexus key for that?) If there is a better place to put that config or a better way to get the info, then please speak up now :) I think this change would be backward compatible and doesn't need any pom changes. It also could easily get back-ported to mvn2 if needed. Are there other URLS which also need a similar distinction while building the model? WDYT? txs and LieGrue, strub [1] http://markmail.org/message/npw3hp6aloa55ctf - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
On Thu, Jul 28, 2011 at 2:59 PM, John Casey jdca...@commonjava.org wrote: Would it be better to have a syntax to mark a URL as literal, not to be calculated or used as the basis of calculation? Yes. I tried to fix this behavior for urls back in ~2.0.6/7 ish and it broke lots of stuff that depended upon that behavior. That way, we don't have to worry about adjusting to new SCMs or other places where we want to use it...new SCMs could be added via build extension, IIRC, so this is particularly important there. WDYT? On 7/28/11 12:46 PM, Mark Struberg wrote: Hi! problem description --- SCM URLs currently automatically get extended for child modules. E.g. from svn://mycompany.com/myproject in the parent pom, a child module 'frontend' will result in getting a SCM URL svn://mycompany.com/myproject/frontend This is fine for SVN and CVS, but broken for GIT, HG, etc because the SCM URL is 'static' for them. proposal --- Since we cannot put this information into the various scm plugins (because of a 'definition cycle' as explained here [1]) we could split the URL construction into scmUrlAppendChild=true/false and make it configurable. The configuration could be controlled via a Modello config, my suggestion would be to just add them to toolchains.mdo. I'd just add a String property which holds a regular expression which parses the SCM URL and decides upon this whether the appending should get activated, e.g. for all SCMs which contain 'scm:svn:' or 'scm:cvs:' or the java-svn (olamy, you know the plexus key for that?) If there is a better place to put that config or a better way to get the info, then please speak up now :) I think this change would be backward compatible and doesn't need any pom changes. It also could easily get back-ported to mvn2 if needed. Are there other URLS which also need a similar distinction while building the model? WDYT? txs and LieGrue, strub [1] http://markmail.org/message/npw3hp6aloa55ctf - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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: [DISCUSS] SCM child-project URL composition
Hi John, Brian Just to make sure I did understand that correctly: you propose to use a special URL prefix to tell the maven DefaultProjectBuilder to treat those urls as static. An example: scm developerConnectionstaticscm:git:ssh://myserver:/../developerConnection resulting in replacing 'staticscm' with 'scm' and not adding the child modules to the URL. Did I get this correctly? Tried that with mvn-3.0.3 and mvn-2.2.1 and a standard build works just fine. Of course a release would only work with the newer maven versions! LieGrue, strub --- On Thu, 7/28/11, Brian Fox bri...@infinity.nu wrote: From: Brian Fox bri...@infinity.nu Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 7:23 PM On Thu, Jul 28, 2011 at 2:59 PM, John Casey jdca...@commonjava.org wrote: Would it be better to have a syntax to mark a URL as literal, not to be calculated or used as the basis of calculation? Yes. I tried to fix this behavior for urls back in ~2.0.6/7 ish and it broke lots of stuff that depended upon that behavior. That way, we don't have to worry about adjusting to new SCMs or other places where we want to use it...new SCMs could be added via build extension, IIRC, so this is particularly important there. WDYT? On 7/28/11 12:46 PM, Mark Struberg wrote: Hi! problem description --- SCM URLs currently automatically get extended for child modules. E.g. from svn://mycompany.com/myproject in the parent pom, a child module 'frontend' will result in getting a SCM URL svn://mycompany.com/myproject/frontend This is fine for SVN and CVS, but broken for GIT, HG, etc because the SCM URL is 'static' for them. proposal --- Since we cannot put this information into the various scm plugins (because of a 'definition cycle' as explained here [1]) we could split the URL construction into scmUrlAppendChild=true/false and make it configurable. The configuration could be controlled via a Modello config, my suggestion would be to just add them to toolchains.mdo. I'd just add a String property which holds a regular expression which parses the SCM URL and decides upon this whether the appending should get activated, e.g. for all SCMs which contain 'scm:svn:' or 'scm:cvs:' or the java-svn (olamy, you know the plexus key for that?) If there is a better place to put that config or a better way to get the info, then please speak up now :) I think this change would be backward compatible and doesn't need any pom changes. It also could easily get back-ported to mvn2 if needed. Are there other URLS which also need a similar distinction while building the model? WDYT? txs and LieGrue, strub [1] http://markmail.org/message/npw3hp6aloa55ctf - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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: [DISCUSS] SCM child-project URL composition
On 7/28/11 3:37 PM, Mark Struberg wrote: Hi John, Brian Just to make sure I did understand that correctly: you propose to use a special URL prefix to tell the maven DefaultProjectBuilder to treat those urls as static. An example: scm developerConnectionstaticscm:git:ssh://myserver:/../developerConnection resulting in replacing 'staticscm' with 'scm' and not adding the child modules to the URL. Did I get this correctly? Tried that with mvn-3.0.3 and mvn-2.2.1 and a standard build works just fine. Of course a release would only work with the newer maven versions! I think that's an acceptable compromise, personally. LieGrue, strub --- On Thu, 7/28/11, Brian Foxbri...@infinity.nu wrote: From: Brian Foxbri...@infinity.nu Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers Listdev@maven.apache.org Date: Thursday, July 28, 2011, 7:23 PM On Thu, Jul 28, 2011 at 2:59 PM, John Caseyjdca...@commonjava.org wrote: Would it be better to have a syntax to mark a URL as literal, not to be calculated or used as the basis of calculation? Yes. I tried to fix this behavior for urls back in ~2.0.6/7 ish and it broke lots of stuff that depended upon that behavior. That way, we don't have to worry about adjusting to new SCMs or other places where we want to use it...new SCMs could be added via build extension, IIRC, so this is particularly important there. WDYT? On 7/28/11 12:46 PM, Mark Struberg wrote: Hi! problem description --- SCM URLs currently automatically get extended for child modules. E.g. from svn://mycompany.com/myproject in the parent pom, a child module 'frontend' will result in getting a SCM URL svn://mycompany.com/myproject/frontend This is fine for SVN and CVS, but broken for GIT, HG, etc because the SCM URL is 'static' for them. proposal --- Since we cannot put this information into the various scm plugins (because of a 'definition cycle' as explained here [1]) we could split the URL construction into scmUrlAppendChild=true/false and make it configurable. The configuration could be controlled via a Modello config, my suggestion would be to just add them to toolchains.mdo. I'd just add a String property which holds a regular expression which parses the SCM URL and decides upon this whether the appending should get activated, e.g. for all SCMs which contain 'scm:svn:' or 'scm:cvs:' or the java-svn (olamy, you know the plexus key for that?) If there is a better place to put that config or a better way to get the info, then please speak up now :) I think this change would be backward compatible and doesn't need any pom changes. It also could easily get back-ported to mvn2 if needed. Are there other URLS which also need a similar distinction while building the model? WDYT? txs and LieGrue, strub [1] http://markmail.org/message/npw3hp6aloa55ctf - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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 -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Do we want to push a Maven Release Plugin 2.2.1 to include MRELEASE-697?
he he. vote already in progress ;-) - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jul 2011 18:41, Arnaud Héritier aherit...@gmail.com wrote: +1 Le 28 juil. 2011 à 16:49, Julien HENRY henr...@yahoo.fr a écrit : +1 for a 2.2.1 Thanks - Mail original - De : Stephen Connolly stephen.alan.conno...@gmail.com À : Maven Developers List dev@maven.apache.org Cc : Envoyé le : Jeudi 28 Juillet 2011 16h28 Objet : Re: Do we want to push a Maven Release Plugin 2.2.1 to include MRELEASE-697? well it was my typo in the first place, so yeah I'm willing to RM it... feck it... i'll do it On 28 July 2011 15:26, Mark Struberg strub...@yahoo.de wrote: If you are volunteering on the build, then +1 :) LieGrue, strub --- On Thu, 7/28/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: Do we want to push a Maven Release Plugin 2.2.1 to include MRELEASE-697? To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 2:21 PM Since it is a rather nasty bug due to a typo on my behalf, do we push a release (2.2.1) now to include the fix and push all the unfixed issues back to 2.3 (where they currently live) -Stephen - 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: [DISCUSS] SCM child-project URL composition
not crazy about the syntax, but generally yes i think that makes sense. I've long maintained that we need something similar for properties to balance between resolve at build time and resolve at fetch from repo type of issues. On Thu, Jul 28, 2011 at 3:37 PM, Mark Struberg strub...@yahoo.de wrote: Hi John, Brian Just to make sure I did understand that correctly: you propose to use a special URL prefix to tell the maven DefaultProjectBuilder to treat those urls as static. An example: scm developerConnectionstaticscm:git:ssh://myserver:/../developerConnection resulting in replacing 'staticscm' with 'scm' and not adding the child modules to the URL. Did I get this correctly? Tried that with mvn-3.0.3 and mvn-2.2.1 and a standard build works just fine. Of course a release would only work with the newer maven versions! LieGrue, strub --- On Thu, 7/28/11, Brian Fox bri...@infinity.nu wrote: From: Brian Fox bri...@infinity.nu Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 7:23 PM On Thu, Jul 28, 2011 at 2:59 PM, John Casey jdca...@commonjava.org wrote: Would it be better to have a syntax to mark a URL as literal, not to be calculated or used as the basis of calculation? Yes. I tried to fix this behavior for urls back in ~2.0.6/7 ish and it broke lots of stuff that depended upon that behavior. That way, we don't have to worry about adjusting to new SCMs or other places where we want to use it...new SCMs could be added via build extension, IIRC, so this is particularly important there. WDYT? On 7/28/11 12:46 PM, Mark Struberg wrote: Hi! problem description --- SCM URLs currently automatically get extended for child modules. E.g. from svn://mycompany.com/myproject in the parent pom, a child module 'frontend' will result in getting a SCM URL svn://mycompany.com/myproject/frontend This is fine for SVN and CVS, but broken for GIT, HG, etc because the SCM URL is 'static' for them. proposal --- Since we cannot put this information into the various scm plugins (because of a 'definition cycle' as explained here [1]) we could split the URL construction into scmUrlAppendChild=true/false and make it configurable. The configuration could be controlled via a Modello config, my suggestion would be to just add them to toolchains.mdo. I'd just add a String property which holds a regular expression which parses the SCM URL and decides upon this whether the appending should get activated, e.g. for all SCMs which contain 'scm:svn:' or 'scm:cvs:' or the java-svn (olamy, you know the plexus key for that?) If there is a better place to put that config or a better way to get the info, then please speak up now :) I think this change would be backward compatible and doesn't need any pom changes. It also could easily get back-ported to mvn2 if needed. Are there other URLS which also need a similar distinction while building the model? WDYT? txs and LieGrue, strub [1] http://markmail.org/message/npw3hp6aloa55ctf - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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: [DISCUSS] SCM child-project URL composition
I keep thinking that I read about a convention that used the presence or absence of a trailing '/' on the URL to control this. Does anyone else recall this? On Thu, Jul 28, 2011 at 5:32 PM, Brian Fox bri...@infinity.nu wrote: not crazy about the syntax, but generally yes i think that makes sense. I've long maintained that we need something similar for properties to balance between resolve at build time and resolve at fetch from repo type of issues. On Thu, Jul 28, 2011 at 3:37 PM, Mark Struberg strub...@yahoo.de wrote: Hi John, Brian Just to make sure I did understand that correctly: you propose to use a special URL prefix to tell the maven DefaultProjectBuilder to treat those urls as static. An example: scm developerConnectionstaticscm:git:ssh://myserver:/../developerConnection resulting in replacing 'staticscm' with 'scm' and not adding the child modules to the URL. Did I get this correctly? Tried that with mvn-3.0.3 and mvn-2.2.1 and a standard build works just fine. Of course a release would only work with the newer maven versions! LieGrue, strub --- On Thu, 7/28/11, Brian Fox bri...@infinity.nu wrote: From: Brian Fox bri...@infinity.nu Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 7:23 PM On Thu, Jul 28, 2011 at 2:59 PM, John Casey jdca...@commonjava.org wrote: Would it be better to have a syntax to mark a URL as literal, not to be calculated or used as the basis of calculation? Yes. I tried to fix this behavior for urls back in ~2.0.6/7 ish and it broke lots of stuff that depended upon that behavior. That way, we don't have to worry about adjusting to new SCMs or other places where we want to use it...new SCMs could be added via build extension, IIRC, so this is particularly important there. WDYT? On 7/28/11 12:46 PM, Mark Struberg wrote: Hi! problem description --- SCM URLs currently automatically get extended for child modules. E.g. from svn://mycompany.com/myproject in the parent pom, a child module 'frontend' will result in getting a SCM URL svn://mycompany.com/myproject/frontend This is fine for SVN and CVS, but broken for GIT, HG, etc because the SCM URL is 'static' for them. proposal --- Since we cannot put this information into the various scm plugins (because of a 'definition cycle' as explained here [1]) we could split the URL construction into scmUrlAppendChild=true/false and make it configurable. The configuration could be controlled via a Modello config, my suggestion would be to just add them to toolchains.mdo. I'd just add a String property which holds a regular expression which parses the SCM URL and decides upon this whether the appending should get activated, e.g. for all SCMs which contain 'scm:svn:' or 'scm:cvs:' or the java-svn (olamy, you know the plexus key for that?) If there is a better place to put that config or a better way to get the info, then please speak up now :) I think this change would be backward compatible and doesn't need any pom changes. It also could easily get back-ported to mvn2 if needed. Are there other URLS which also need a similar distinction while building the model? WDYT? txs and LieGrue, strub [1] http://markmail.org/message/npw3hp6aloa55ctf - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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: [DISCUSS] SCM child-project URL composition
Hi!
A small update:
Benjamin mentioned that this might also be useful for site URLs if a user like
to define the effective URLs of the sub-module site via
${project.version}/${project.artifactId} or similar.
So we just came up with static: as prefix.
More soon via Jira.
LieGrue,
strub
--- On Thu, 7/28/11, Brian Fox bri...@infinity.nu wrote:
From: Brian Fox bri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers List dev@maven.apache.org
Date: Thursday, July 28, 2011, 9:32 PM
not crazy about the syntax, but
generally yes i think that makes sense.
I've long maintained that we need something similar for
properties to
balance between resolve at build time and resolve at
fetch from
repo type of issues.
On Thu, Jul 28, 2011 at 3:37 PM, Mark Struberg strub...@yahoo.de
wrote:
Hi John, Brian
Just to make sure I did understand that correctly:
you propose to use a special URL prefix to tell the
maven DefaultProjectBuilder to treat those urls as static.
An example:
scm
developerConnectionstaticscm:git:ssh://myserver:/../developerConnection
resulting in replacing 'staticscm' with 'scm' and not
adding the child modules to the URL.
Did I get this correctly?
Tried that with mvn-3.0.3 and mvn-2.2.1 and a standard
build works just fine. Of course a release would only work
with the newer maven versions!
LieGrue,
strub
--- On Thu, 7/28/11, Brian Fox bri...@infinity.nu
wrote:
From: Brian Fox bri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project URL
composition
To: Maven Developers List dev@maven.apache.org
Date: Thursday, July 28, 2011, 7:23 PM
On Thu, Jul 28, 2011 at 2:59 PM, John
Casey jdca...@commonjava.org
wrote:
Would it be better to have a syntax to mark a
URL as
literal, not to be
calculated or used as the basis of
calculation?
Yes. I tried to fix this behavior for urls back in
~2.0.6/7
ish and it
broke lots of stuff that depended upon that
behavior.
That way, we don't have to worry about
adjusting to
new SCMs or other places
where we want to use it...new SCMs could be
added via
build extension, IIRC,
so this is particularly important there.
WDYT?
On 7/28/11 12:46 PM, Mark Struberg wrote:
Hi!
problem description
---
SCM URLs currently automatically get
extended for
child modules.
E.g. from
svn://mycompany.com/myproject
in the parent pom, a child module
'frontend' will
result in getting a SCM
URL
svn://mycompany.com/myproject/frontend
This is fine for SVN and CVS, but broken
for GIT,
HG, etc because the SCM
URL is 'static' for them.
proposal
---
Since we cannot put this information into
the
various scm plugins (because
of a 'definition cycle' as explained here
[1]) we
could split the URL
construction into
scmUrlAppendChild=true/false and
make it configurable. The
configuration could be controlled via a
Modello
config, my suggestion would
be to just add them to toolchains.mdo.
I'd just add a String property which
holds a
regular expression which
parses the SCM URL and decides upon this
whether
the appending should get
activated, e.g. for all SCMs which
contain
'scm:svn:' or 'scm:cvs:' or the
java-svn (olamy, you know the plexus key
for
that?)
If there is a better place to put that
config or a
better way to get the
info, then please speak up now :)
I think this change would be backward
compatible
and doesn't need any pom
changes. It also could easily get
back-ported to
mvn2 if needed.
Are there other URLS which also need a
similar
distinction while building
the model?
WDYT?
txs and LieGrue,
strub
[1] http://markmail.org/message/npw3hp6aloa55ctf
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
John Casey
Developer, PMC Chair - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
-
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:
Re: [DISCUSS] SCM child-project URL composition
Is static: really superior to scm2: and then more colons allowing
arbitrary keyword-value pairs?
On Thu, Jul 28, 2011 at 5:44 PM, Mark Struberg strub...@yahoo.de wrote:
Hi!
A small update:
Benjamin mentioned that this might also be useful for site URLs if a user
like to define the effective URLs of the sub-module site via
${project.version}/${project.artifactId} or similar.
So we just came up with static: as prefix.
More soon via Jira.
LieGrue,
strub
--- On Thu, 7/28/11, Brian Fox bri...@infinity.nu wrote:
From: Brian Fox bri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers List dev@maven.apache.org
Date: Thursday, July 28, 2011, 9:32 PM
not crazy about the syntax, but
generally yes i think that makes sense.
I've long maintained that we need something similar for
properties to
balance between resolve at build time and resolve at
fetch from
repo type of issues.
On Thu, Jul 28, 2011 at 3:37 PM, Mark Struberg strub...@yahoo.de
wrote:
Hi John, Brian
Just to make sure I did understand that correctly:
you propose to use a special URL prefix to tell the
maven DefaultProjectBuilder to treat those urls as static.
An example:
scm
developerConnectionstaticscm:git:ssh://myserver:/../developerConnection
resulting in replacing 'staticscm' with 'scm' and not
adding the child modules to the URL.
Did I get this correctly?
Tried that with mvn-3.0.3 and mvn-2.2.1 and a standard
build works just fine. Of course a release would only work
with the newer maven versions!
LieGrue,
strub
--- On Thu, 7/28/11, Brian Fox bri...@infinity.nu
wrote:
From: Brian Fox bri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project URL
composition
To: Maven Developers List dev@maven.apache.org
Date: Thursday, July 28, 2011, 7:23 PM
On Thu, Jul 28, 2011 at 2:59 PM, John
Casey jdca...@commonjava.org
wrote:
Would it be better to have a syntax to mark a
URL as
literal, not to be
calculated or used as the basis of
calculation?
Yes. I tried to fix this behavior for urls back in
~2.0.6/7
ish and it
broke lots of stuff that depended upon that
behavior.
That way, we don't have to worry about
adjusting to
new SCMs or other places
where we want to use it...new SCMs could be
added via
build extension, IIRC,
so this is particularly important there.
WDYT?
On 7/28/11 12:46 PM, Mark Struberg wrote:
Hi!
problem description
---
SCM URLs currently automatically get
extended for
child modules.
E.g. from
svn://mycompany.com/myproject
in the parent pom, a child module
'frontend' will
result in getting a SCM
URL
svn://mycompany.com/myproject/frontend
This is fine for SVN and CVS, but broken
for GIT,
HG, etc because the SCM
URL is 'static' for them.
proposal
---
Since we cannot put this information into
the
various scm plugins (because
of a 'definition cycle' as explained here
[1]) we
could split the URL
construction into
scmUrlAppendChild=true/false and
make it configurable. The
configuration could be controlled via a
Modello
config, my suggestion would
be to just add them to toolchains.mdo.
I'd just add a String property which
holds a
regular expression which
parses the SCM URL and decides upon this
whether
the appending should get
activated, e.g. for all SCMs which
contain
'scm:svn:' or 'scm:cvs:' or the
java-svn (olamy, you know the plexus key
for
that?)
If there is a better place to put that
config or a
better way to get the
info, then please speak up now :)
I think this change would be backward
compatible
and doesn't need any pom
changes. It also could easily get
back-ported to
mvn2 if needed.
Are there other URLS which also need a
similar
distinction while building
the model?
WDYT?
txs and LieGrue,
strub
[1] http://markmail.org/message/npw3hp6aloa55ctf
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
John Casey
Developer, PMC Chair - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
-
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: [VOTE] Release Maven Release plugin version 2.2.1
+1 Non Binding On 29/07/2011, at 2:56 AM, Stephen Connolly wrote: Hi, This is a patch release to fix a particularly nasty regression: http://jira.codehaus.org/browse/MRELEASE-697 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
On 7/28/11 5:43 PM, Benson Margulies wrote: I keep thinking that I read about a convention that used the presence or absence of a trailing '/' on the URL to control this. Does anyone else recall this? You mean overloading an explicit URL referencing a directory? Seems a tad confusing and maybe even a problem waiting to happen... On Thu, Jul 28, 2011 at 5:32 PM, Brian Foxbri...@infinity.nu wrote: not crazy about the syntax, but generally yes i think that makes sense. I've long maintained that we need something similar for properties to balance between resolve at build time and resolve at fetch from repo type of issues. On Thu, Jul 28, 2011 at 3:37 PM, Mark Strubergstrub...@yahoo.de wrote: Hi John, Brian Just to make sure I did understand that correctly: you propose to use a special URL prefix to tell the maven DefaultProjectBuilder to treat those urls as static. An example: scm developerConnectionstaticscm:git:ssh://myserver:/../developerConnection resulting in replacing 'staticscm' with 'scm' and not adding the child modules to the URL. Did I get this correctly? Tried that with mvn-3.0.3 and mvn-2.2.1 and a standard build works just fine. Of course a release would only work with the newer maven versions! LieGrue, strub --- On Thu, 7/28/11, Brian Foxbri...@infinity.nu wrote: From: Brian Foxbri...@infinity.nu Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers Listdev@maven.apache.org Date: Thursday, July 28, 2011, 7:23 PM On Thu, Jul 28, 2011 at 2:59 PM, John Caseyjdca...@commonjava.org wrote: Would it be better to have a syntax to mark a URL as literal, not to be calculated or used as the basis of calculation? Yes. I tried to fix this behavior for urls back in ~2.0.6/7 ish and it broke lots of stuff that depended upon that behavior. That way, we don't have to worry about adjusting to new SCMs or other places where we want to use it...new SCMs could be added via build extension, IIRC, so this is particularly important there. WDYT? On 7/28/11 12:46 PM, Mark Struberg wrote: Hi! problem description --- SCM URLs currently automatically get extended for child modules. E.g. from svn://mycompany.com/myproject in the parent pom, a child module 'frontend' will result in getting a SCM URL svn://mycompany.com/myproject/frontend This is fine for SVN and CVS, but broken for GIT, HG, etc because the SCM URL is 'static' for them. proposal --- Since we cannot put this information into the various scm plugins (because of a 'definition cycle' as explained here [1]) we could split the URL construction into scmUrlAppendChild=true/false and make it configurable. The configuration could be controlled via a Modello config, my suggestion would be to just add them to toolchains.mdo. I'd just add a String property which holds a regular expression which parses the SCM URL and decides upon this whether the appending should get activated, e.g. for all SCMs which contain 'scm:svn:' or 'scm:cvs:' or the java-svn (olamy, you know the plexus key for that?) If there is a better place to put that config or a better way to get the info, then please speak up now :) I think this change would be backward compatible and doesn't need any pom changes. It also could easily get back-ported to mvn2 if needed. Are there other URLS which also need a similar distinction while building the model? WDYT? txs and LieGrue, strub [1] http://markmail.org/message/npw3hp6aloa55ctf - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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 -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail:
Re: [DISCUSS] SCM child-project URL composition
yup something like
developerConnectionstatic:scm:git:https://...
And the trailing / is rather unhandy. Some scms just crash if you don't use the
correct trailing ;)
LieGrue,
strub
--- On Thu, 7/28/11, Benson Margulies bimargul...@gmail.com wrote:
From: Benson Margulies bimargul...@gmail.com
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers List dev@maven.apache.org
Date: Thursday, July 28, 2011, 9:45 PM
Is static: really superior to scm2:
and then more colons allowing
arbitrary keyword-value pairs?
On Thu, Jul 28, 2011 at 5:44 PM, Mark Struberg strub...@yahoo.de
wrote:
Hi!
A small update:
Benjamin mentioned that this might also be useful for
site URLs if a user like to define the effective URLs of the
sub-module site via ${project.version}/${project.artifactId}
or similar.
So we just came up with static: as prefix.
More soon via Jira.
LieGrue,
strub
--- On Thu, 7/28/11, Brian Fox bri...@infinity.nu
wrote:
From: Brian Fox bri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project URL
composition
To: Maven Developers List dev@maven.apache.org
Date: Thursday, July 28, 2011, 9:32 PM
not crazy about the syntax, but
generally yes i think that makes sense.
I've long maintained that we need something
similar for
properties to
balance between resolve at build time and
resolve at
fetch from
repo type of issues.
On Thu, Jul 28, 2011 at 3:37 PM, Mark Struberg
strub...@yahoo.de
wrote:
Hi John, Brian
Just to make sure I did understand that
correctly:
you propose to use a special URL prefix to
tell the
maven DefaultProjectBuilder to treat those urls as
static.
An example:
scm
developerConnectionstaticscm:git:ssh://myserver:/../developerConnection
resulting in replacing 'staticscm' with 'scm'
and not
adding the child modules to the URL.
Did I get this correctly?
Tried that with mvn-3.0.3 and mvn-2.2.1 and a
standard
build works just fine. Of course a release would
only work
with the newer maven versions!
LieGrue,
strub
--- On Thu, 7/28/11, Brian Fox bri...@infinity.nu
wrote:
From: Brian Fox bri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project
URL
composition
To: Maven Developers List dev@maven.apache.org
Date: Thursday, July 28, 2011, 7:23 PM
On Thu, Jul 28, 2011 at 2:59 PM, John
Casey jdca...@commonjava.org
wrote:
Would it be better to have a syntax
to mark a
URL as
literal, not to be
calculated or used as the basis of
calculation?
Yes. I tried to fix this behavior for
urls back in
~2.0.6/7
ish and it
broke lots of stuff that depended upon
that
behavior.
That way, we don't have to worry
about
adjusting to
new SCMs or other places
where we want to use it...new SCMs
could be
added via
build extension, IIRC,
so this is particularly important
there.
WDYT?
On 7/28/11 12:46 PM, Mark Struberg
wrote:
Hi!
problem description
---
SCM URLs currently automatically
get
extended for
child modules.
E.g. from
svn://mycompany.com/myproject
in the parent pom, a child
module
'frontend' will
result in getting a SCM
URL
svn://mycompany.com/myproject/frontend
This is fine for SVN and CVS,
but broken
for GIT,
HG, etc because the SCM
URL is 'static' for them.
proposal
---
Since we cannot put this
information into
the
various scm plugins (because
of a 'definition cycle' as
explained here
[1]) we
could split the URL
construction into
scmUrlAppendChild=true/false and
make it configurable. The
configuration could be
controlled via a
Modello
config, my suggestion would
be to just add them to
toolchains.mdo.
I'd just add a String property
which
holds a
regular expression which
parses the SCM URL and decides
upon this
whether
the appending should get
activated, e.g. for all SCMs
which
contain
'scm:svn:' or 'scm:cvs:' or the
java-svn (olamy, you know the
plexus key
for
that?)
If there is a better place to
put that
config or a
better way to get the
info, then please speak up now
:)
I think this change would be
backward
compatible
and doesn't need any pom
changes. It also could easily
get
back-ported to
mvn2 if needed.
Are there other URLS which also
need a
similar
distinction while building
the model?
WDYT?
txs and LieGrue,
strub
[1] http://markmail.org/message/npw3hp6aloa55ctf
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail:
dev-h...@maven.apache.org
--
John Casey
Developer, PMC Chair - Apache Maven
Re: [DISCUSS] SCM child-project URL composition
using scm2: you're not able to apply the solution to website urls, etc.
which have a similar inheritance/calculation problem...
On 7/28/11 5:45 PM, Benson Margulies wrote:
Is static: really superior to scm2: and then more colons allowing
arbitrary keyword-value pairs?
On Thu, Jul 28, 2011 at 5:44 PM, Mark Strubergstrub...@yahoo.de wrote:
Hi!
A small update:
Benjamin mentioned that this might also be useful for site URLs if a user like
to define the effective URLs of the sub-module site via
${project.version}/${project.artifactId} or similar.
So we just came up with static: as prefix.
More soon via Jira.
LieGrue,
strub
--- On Thu, 7/28/11, Brian Foxbri...@infinity.nu wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011, 9:32 PM
not crazy about the syntax, but
generally yes i think that makes sense.
I've long maintained that we need something similar for
properties to
balance between resolve at build time and resolve at
fetch from
repo type of issues.
On Thu, Jul 28, 2011 at 3:37 PM, Mark Strubergstrub...@yahoo.de
wrote:
Hi John, Brian
Just to make sure I did understand that correctly:
you propose to use a special URL prefix to tell the
maven DefaultProjectBuilder to treat those urls as static.
An example:
scm
developerConnectionstaticscm:git:ssh://myserver:/../developerConnection
resulting in replacing 'staticscm' with 'scm' and not
adding the child modules to the URL.
Did I get this correctly?
Tried that with mvn-3.0.3 and mvn-2.2.1 and a standard
build works just fine. Of course a release would only work
with the newer maven versions!
LieGrue,
strub
--- On Thu, 7/28/11, Brian Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project URL
composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011, 7:23 PM
On Thu, Jul 28, 2011 at 2:59 PM, John
Caseyjdca...@commonjava.org
wrote:
Would it be better to have a syntax to mark a
URL as
literal, not to be
calculated or used as the basis of
calculation?
Yes. I tried to fix this behavior for urls back in
~2.0.6/7
ish and it
broke lots of stuff that depended upon that
behavior.
That way, we don't have to worry about
adjusting to
new SCMs or other places
where we want to use it...new SCMs could be
added via
build extension, IIRC,
so this is particularly important there.
WDYT?
On 7/28/11 12:46 PM, Mark Struberg wrote:
Hi!
problem description
---
SCM URLs currently automatically get
extended for
child modules.
E.g. from
svn://mycompany.com/myproject
in the parent pom, a child module
'frontend' will
result in getting a SCM
URL
svn://mycompany.com/myproject/frontend
This is fine for SVN and CVS, but broken
for GIT,
HG, etc because the SCM
URL is 'static' for them.
proposal
---
Since we cannot put this information into
the
various scm plugins (because
of a 'definition cycle' as explained here
[1]) we
could split the URL
construction into
scmUrlAppendChild=true/false and
make it configurable. The
configuration could be controlled via a
Modello
config, my suggestion would
be to just add them to toolchains.mdo.
I'd just add a String property which
holds a
regular expression which
parses the SCM URL and decides upon this
whether
the appending should get
activated, e.g. for all SCMs which
contain
'scm:svn:' or 'scm:cvs:' or the
java-svn (olamy, you know the plexus key
for
that?)
If there is a better place to put that
config or a
better way to get the
info, then please speak up now :)
I think this change would be backward
compatible
and doesn't need any pom
changes. It also could easily get
back-ported to
mvn2 if needed.
Are there other URLS which also need a
similar
distinction while building
the model?
WDYT?
txs and LieGrue,
strub
[1] http://markmail.org/message/npw3hp6aloa55ctf
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
John Casey
Developer, PMC Chair - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
-
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:
Re: POM design principles: what qualifies for the model?
Something what was denounced in the past was the mix of delivery informations (identity, dependencies, ...) and project informations (build configuration, build environment, team, ) delivery informations are immutable whereas for project informations it depends. Build configuration used to create the delivery should be inmutable (I need to be able to reproduce the binaries creation). But some others part may change over the time. The most frequent is the scm, the project mailing list ... Even if when the delivery was done with its sources in SCM X (svn for example) and its support was done on the project mailing list Y (hosted by sourceforge), when I will want to use the delivery I will want to know were sources are now (perhaps git) and how to contact its team (perhaps google groups). Thus all of that to say that we cannot/shouldn't deny the fact that a project lives. For some information it is important to have them immutable while for some others we should provide a mechanism to be able to keep them up-to-date with the project life. Note : Yes it doesn't help on the how to do :-) Arnaud On Thu, Jul 28, 2011 at 7:16 PM, Benson Margulies bimargul...@gmail.comwrote: I am now going to go to the wiki page and add some more thinking about the use of extensible (e.g. property-set) XML for things like scm. what about existing xml tools for this: namespaces, URNs, etc.? Let me do some thinking and writing on the wiki. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
As well I know from MSITE-600. However, now I'm confused: you
couldn't use the static business with
/project/distributionManagement/site/url, since those are naked urls.
The proposal above is not scm:static:, it's static:scm:. are you
suggesting putting static:http: in
/project/distributionManagement/site/url? That looks like a problem
for anything that parses the pom and doesn't use the model code, and I
thought we felt precluded from busting things like this.
Yet Another Alternative:
url static='true'what-we-have-today/url
would work for scm and also for websites. In my opinion, the
'disconnected parent' issue has to be fully taken on board, and that
really calls for
url inherit='false'what-we-have-today/url
which would be a good thing for the overall ASF pom.
On Thu, Jul 28, 2011 at 5:50 PM, John Casey jdca...@commonjava.org wrote:
using scm2: you're not able to apply the solution to website urls, etc.
which have a similar inheritance/calculation problem...
On 7/28/11 5:45 PM, Benson Margulies wrote:
Is static: really superior to scm2: and then more colons allowing
arbitrary keyword-value pairs?
On Thu, Jul 28, 2011 at 5:44 PM, Mark Strubergstrub...@yahoo.de wrote:
Hi!
A small update:
Benjamin mentioned that this might also be useful for site URLs if a user
like to define the effective URLs of the sub-module site via
${project.version}/${project.artifactId} or similar.
So we just came up with static: as prefix.
More soon via Jira.
LieGrue,
strub
--- On Thu, 7/28/11, Brian Foxbri...@infinity.nu wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011, 9:32 PM
not crazy about the syntax, but
generally yes i think that makes sense.
I've long maintained that we need something similar for
properties to
balance between resolve at build time and resolve at
fetch from
repo type of issues.
On Thu, Jul 28, 2011 at 3:37 PM, Mark Strubergstrub...@yahoo.de
wrote:
Hi John, Brian
Just to make sure I did understand that correctly:
you propose to use a special URL prefix to tell the
maven DefaultProjectBuilder to treat those urls as static.
An example:
scm
developerConnectionstaticscm:git:ssh://myserver:/../developerConnection
resulting in replacing 'staticscm' with 'scm' and not
adding the child modules to the URL.
Did I get this correctly?
Tried that with mvn-3.0.3 and mvn-2.2.1 and a standard
build works just fine. Of course a release would only work
with the newer maven versions!
LieGrue,
strub
--- On Thu, 7/28/11, Brian Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project URL
composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011, 7:23 PM
On Thu, Jul 28, 2011 at 2:59 PM, John
Caseyjdca...@commonjava.org
wrote:
Would it be better to have a syntax to mark a
URL as
literal, not to be
calculated or used as the basis of
calculation?
Yes. I tried to fix this behavior for urls back in
~2.0.6/7
ish and it
broke lots of stuff that depended upon that
behavior.
That way, we don't have to worry about
adjusting to
new SCMs or other places
where we want to use it...new SCMs could be
added via
build extension, IIRC,
so this is particularly important there.
WDYT?
On 7/28/11 12:46 PM, Mark Struberg wrote:
Hi!
problem description
---
SCM URLs currently automatically get
extended for
child modules.
E.g. from
svn://mycompany.com/myproject
in the parent pom, a child module
'frontend' will
result in getting a SCM
URL
svn://mycompany.com/myproject/frontend
This is fine for SVN and CVS, but broken
for GIT,
HG, etc because the SCM
URL is 'static' for them.
proposal
---
Since we cannot put this information into
the
various scm plugins (because
of a 'definition cycle' as explained here
[1]) we
could split the URL
construction into
scmUrlAppendChild=true/false and
make it configurable. The
configuration could be controlled via a
Modello
config, my suggestion would
be to just add them to toolchains.mdo.
I'd just add a String property which
holds a
regular expression which
parses the SCM URL and decides upon this
whether
the appending should get
activated, e.g. for all SCMs which
contain
'scm:svn:' or 'scm:cvs:' or the
java-svn (olamy, you know the plexus key
for
that?)
If there is a better place to put that
config or a
better way to get the
info, then please speak up now :)
I think this change would be backward
compatible
and doesn't need any pom
changes. It also could easily get
back-ported to
mvn2 if needed.
Are there other URLS which also need a
similar
distinction while building
the model?
WDYT?
txs and LieGrue,
strub
[1] http://markmail.org/message/npw3hp6aloa55ctf
Re: [DISCUSS] SCM child-project URL composition
Hi and txs 4 looking through the proposal!
url static=true is a neat idea but sadly requires us to change the pom-4.0
schema. So I fear this is a no-go atm.
I'm not sure if there is lots of code which parses the content of the urls
manually. It's not guaranteed what it contains, and we already apply _lots_ of
magic to those URLs (property expansion, etc). So anyone which does not use our
stuff is on his own anyway. Actually the content is still a valid URL in the
sense of RFC-1738. But it's our own protocol now ;)
Just my $0.02
LieGrue,
strub
PS: I really like the 'absolute:' protocol name Robert proposed (instead of
'static:'.
--- On Thu, 7/28/11, Benson Margulies bimargul...@gmail.com wrote:
From: Benson Margulies bimargul...@gmail.com
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers List dev@maven.apache.org
Date: Thursday, July 28, 2011, 10:01 PM
As well I know from MSITE-600.
However, now I'm confused: you
couldn't use the static business with
/project/distributionManagement/site/url, since those are
naked urls.
The proposal above is not scm:static:, it's static:scm:.
are you
suggesting putting static:http: in
/project/distributionManagement/site/url? That looks
like a problem
for anything that parses the pom and doesn't use the model
code, and I
thought we felt precluded from busting things like this.
Yet Another Alternative:
url static='true'what-we-have-today/url
would work for scm and also for websites. In my opinion,
the
'disconnected parent' issue has to be fully taken on board,
and that
really calls for
url
inherit='false'what-we-have-today/url
which would be a good thing for the overall ASF pom.
On Thu, Jul 28, 2011 at 5:50 PM, John Casey jdca...@commonjava.org
wrote:
using scm2: you're not able to apply the solution to
website urls, etc.
which have a similar inheritance/calculation
problem...
On 7/28/11 5:45 PM, Benson Margulies wrote:
Is static: really superior to scm2: and then more
colons allowing
arbitrary keyword-value pairs?
On Thu, Jul 28, 2011 at 5:44 PM, Mark
Strubergstrub...@yahoo.de
wrote:
Hi!
A small update:
Benjamin mentioned that this might also be
useful for site URLs if a user
like to define the effective URLs of the
sub-module site via
${project.version}/${project.artifactId} or
similar.
So we just came up with static: as prefix.
More soon via Jira.
LieGrue,
strub
--- On Thu, 7/28/11, Brian Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project
URL composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011, 9:32 PM
not crazy about the syntax, but
generally yes i think that makes sense.
I've long maintained that we need
something similar for
properties to
balance between resolve at build time
and resolve at
fetch from
repo type of issues.
On Thu, Jul 28, 2011 at 3:37 PM, Mark
Strubergstrub...@yahoo.de
wrote:
Hi John, Brian
Just to make sure I did understand
that correctly:
you propose to use a special URL
prefix to tell the
maven DefaultProjectBuilder to treat those
urls as static.
An example:
scm
developerConnectionstaticscm:git:ssh://myserver:/../developerConnection
resulting in replacing 'staticscm'
with 'scm' and not
adding the child modules to the URL.
Did I get this correctly?
Tried that with mvn-3.0.3 and
mvn-2.2.1 and a standard
build works just fine. Of course a release
would only work
with the newer maven versions!
LieGrue,
strub
--- On Thu, 7/28/11, Brian Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM
child-project URL
composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011,
7:23 PM
On Thu, Jul 28, 2011 at 2:59 PM,
John
Caseyjdca...@commonjava.org
wrote:
Would it be better to have a
syntax to mark a
URL as
literal, not to be
calculated or used as the
basis of
calculation?
Yes. I tried to fix this behavior
for urls back in
~2.0.6/7
ish and it
broke lots of stuff that depended
upon that
behavior.
That way, we don't have to
worry about
adjusting to
new SCMs or other places
where we want to use it...new
SCMs could be
added via
build extension, IIRC,
so this is particularly
important there.
WDYT?
On 7/28/11 12:46 PM, Mark
Struberg wrote:
Hi!
problem description
---
SCM URLs currently
automatically get
extended for
child modules.
E.g. from
svn://mycompany.com/myproject
in the parent pom, a child
module
'frontend' will
result in getting a SCM
URL
svn://mycompany.com/myproject/frontend
This is fine for SVN and
CVS, but broken
for GIT,
HG, etc because the SCM
URL is 'static' for them.
Re: [DISCUSS] SCM child-project URL composition
On 7/28/11 6:12 PM, Mark Struberg wrote:
Hi and txs 4 looking through the proposal!
url static=true is a neat idea but sadly requires us to change the pom-4.0
schema. So I fear this is a no-go atm.
I'm not sure if there is lots of code which parses the content of the urls
manually. It's not guaranteed what it contains, and we already apply _lots_ of
magic to those URLs (property expansion, etc). So anyone which does not use our
stuff is on his own anyway. Actually the content is still a valid URL in the
sense of RFC-1738. But it's our own protocol now ;)
Just my $0.02
LieGrue,
strub
PS: I really like the 'absolute:' protocol name Robert proposed (instead of
'static:'.
+1
--- On Thu, 7/28/11, Benson Marguliesbimargul...@gmail.com wrote:
From: Benson Marguliesbimargul...@gmail.com
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011, 10:01 PM
As well I know from MSITE-600.
However, now I'm confused: you
couldn't use the static business with
/project/distributionManagement/site/url, since those are
naked urls.
The proposal above is not scm:static:, it's static:scm:.
are you
suggesting putting static:http: in
/project/distributionManagement/site/url? That looks
like a problem
for anything that parses the pom and doesn't use the model
code, and I
thought we felt precluded from busting things like this.
Yet Another Alternative:
url static='true'what-we-have-today/url
would work for scm and also for websites. In my opinion,
the
'disconnected parent' issue has to be fully taken on board,
and that
really calls for
url
inherit='false'what-we-have-today/url
which would be a good thing for the overall ASF pom.
On Thu, Jul 28, 2011 at 5:50 PM, John Caseyjdca...@commonjava.org
wrote:
using scm2: you're not able to apply the solution to
website urls, etc.
which have a similar inheritance/calculation
problem...
On 7/28/11 5:45 PM, Benson Margulies wrote:
Is static: really superior to scm2: and then more
colons allowing
arbitrary keyword-value pairs?
On Thu, Jul 28, 2011 at 5:44 PM, Mark
Strubergstrub...@yahoo.de
wrote:
Hi!
A small update:
Benjamin mentioned that this might also be
useful for site URLs if a user
like to define the effective URLs of the
sub-module site via
${project.version}/${project.artifactId} or
similar.
So we just came up with static: as prefix.
More soon via Jira.
LieGrue,
strub
--- On Thu, 7/28/11, Brian Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project
URL composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011, 9:32 PM
not crazy about the syntax, but
generally yes i think that makes sense.
I've long maintained that we need
something similar for
properties to
balance between resolve at build time
and resolve at
fetch from
repo type of issues.
On Thu, Jul 28, 2011 at 3:37 PM, Mark
Strubergstrub...@yahoo.de
wrote:
Hi John, Brian
Just to make sure I did understand
that correctly:
you propose to use a special URL
prefix to tell the
maven DefaultProjectBuilder to treat those
urls as static.
An example:
scm
developerConnectionstaticscm:git:ssh://myserver:/../developerConnection
resulting in replacing 'staticscm'
with 'scm' and not
adding the child modules to the URL.
Did I get this correctly?
Tried that with mvn-3.0.3 and
mvn-2.2.1 and a standard
build works just fine. Of course a release
would only work
with the newer maven versions!
LieGrue,
strub
--- On Thu, 7/28/11, Brian Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM
child-project URL
composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011,
7:23 PM
On Thu, Jul 28, 2011 at 2:59 PM,
John
Caseyjdca...@commonjava.org
wrote:
Would it be better to have a
syntax to mark a
URL as
literal, not to be
calculated or used as the
basis of
calculation?
Yes. I tried to fix this behavior
for urls back in
~2.0.6/7
ish and it
broke lots of stuff that depended
upon that
behavior.
That way, we don't have to
worry about
adjusting to
new SCMs or other places
where we want to use it...new
SCMs could be
added via
build extension, IIRC,
so this is particularly
important there.
WDYT?
On 7/28/11 12:46 PM, Mark
Struberg wrote:
Hi!
problem description
---
SCM URLs currently
automatically get
extended for
child modules.
E.g. from
svn://mycompany.com/myproject
in the parent pom, a child
module
'frontend' will
result in getting a SCM
URL
svn://mycompany.com/myproject/frontend
This is fine for SVN and
CVS, but broken
for GIT,
HG, etc because the SCM
URL is 'static' for them.
proposal
---
Since we cannot put this
information into
the
various scm plugins (because
of a 'definition cycle' as
explained here
[1]) we
Re: [DISCUSS] SCM child-project URL composition
attributes are special in XML schema. I plan to check and see if pom
4.0 really precludes unqualified attributes.
On Jul 28, 2011, at 6:26 PM, John Casey jdca...@commonjava.org wrote:
On 7/28/11 6:12 PM, Mark Struberg wrote:
Hi and txs 4 looking through the proposal!
url static=true is a neat idea but sadly requires us to change the
pom-4.0 schema. So I fear this is a no-go atm.
I'm not sure if there is lots of code which parses the content of the urls
manually. It's not guaranteed what it contains, and we already apply _lots_
of magic to those URLs (property expansion, etc). So anyone which does not
use our stuff is on his own anyway. Actually the content is still a valid
URL in the sense of RFC-1738. But it's our own protocol now ;)
Just my $0.02
LieGrue,
strub
PS: I really like the 'absolute:' protocol name Robert proposed (instead of
'static:'.
+1
--- On Thu, 7/28/11, Benson Marguliesbimargul...@gmail.com wrote:
From: Benson Marguliesbimargul...@gmail.com
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011, 10:01 PM
As well I know from MSITE-600.
However, now I'm confused: you
couldn't use the static business with
/project/distributionManagement/site/url, since those are
naked urls.
The proposal above is not scm:static:, it's static:scm:.
are you
suggesting putting static:http: in
/project/distributionManagement/site/url? That looks
like a problem
for anything that parses the pom and doesn't use the model
code, and I
thought we felt precluded from busting things like this.
Yet Another Alternative:
url static='true'what-we-have-today/url
would work for scm and also for websites. In my opinion,
the
'disconnected parent' issue has to be fully taken on board,
and that
really calls for
url
inherit='false'what-we-have-today/url
which would be a good thing for the overall ASF pom.
On Thu, Jul 28, 2011 at 5:50 PM, John Caseyjdca...@commonjava.org
wrote:
using scm2: you're not able to apply the solution to
website urls, etc.
which have a similar inheritance/calculation
problem...
On 7/28/11 5:45 PM, Benson Margulies wrote:
Is static: really superior to scm2: and then more
colons allowing
arbitrary keyword-value pairs?
On Thu, Jul 28, 2011 at 5:44 PM, Mark
Strubergstrub...@yahoo.de
wrote:
Hi!
A small update:
Benjamin mentioned that this might also be
useful for site URLs if a user
like to define the effective URLs of the
sub-module site via
${project.version}/${project.artifactId} or
similar.
So we just came up with static: as prefix.
More soon via Jira.
LieGrue,
strub
--- On Thu, 7/28/11, Brian Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project
URL composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011, 9:32 PM
not crazy about the syntax, but
generally yes i think that makes sense.
I've long maintained that we need
something similar for
properties to
balance between resolve at build time
and resolve at
fetch from
repo type of issues.
On Thu, Jul 28, 2011 at 3:37 PM, Mark
Strubergstrub...@yahoo.de
wrote:
Hi John, Brian
Just to make sure I did understand
that correctly:
you propose to use a special URL
prefix to tell the
maven DefaultProjectBuilder to treat those
urls as static.
An example:
scm
developerConnectionstaticscm:git:ssh://myserver:/../developerConnection
resulting in replacing 'staticscm'
with 'scm' and not
adding the child modules to the URL.
Did I get this correctly?
Tried that with mvn-3.0.3 and
mvn-2.2.1 and a standard
build works just fine. Of course a release
would only work
with the newer maven versions!
LieGrue,
strub
--- On Thu, 7/28/11, Brian Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM
child-project URL
composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011,
7:23 PM
On Thu, Jul 28, 2011 at 2:59 PM,
John
Caseyjdca...@commonjava.org
wrote:
Would it be better to have a
syntax to mark a
URL as
literal, not to be
calculated or used as the
basis of
calculation?
Yes. I tried to fix this behavior
for urls back in
~2.0.6/7
ish and it
broke lots of stuff that depended
upon that
behavior.
That way, we don't have to
worry about
adjusting to
new SCMs or other places
where we want to use it...new
SCMs could be
added via
build extension, IIRC,
so this is particularly
important there.
WDYT?
On 7/28/11 12:46 PM, Mark
Struberg wrote:
Hi!
problem description
---
SCM URLs currently
automatically get
extended for
child modules.
E.g. from
svn://mycompany.com/myproject
in the parent pom, a child
module
'frontend' will
result in getting a SCM
URL
svn://mycompany.com/myproject/frontend
This is fine for SVN and
Re: [DISCUSS] SCM child-project URL composition
i think modelleo allows any random attributes (as other pays them no heed...
not sure of ivy, and the others... but they are likely only looking at
dependencies... a garden problem alright)
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 28 Jul 2011 23:38, Benson Margulies bimargul...@gmail.com wrote:
attributes are special in XML schema. I plan to check and see if pom
4.0 really precludes unqualified attributes.
On Jul 28, 2011, at 6:26 PM, John Casey jdca...@commonjava.org wrote:
On 7/28/11 6:12 PM, Mark Struberg wrote:
Hi and txs 4 looking through the proposal!
url static=true is a neat idea but sadly requires us to change the
pom-4.0 schema. So I fear this is a no-go atm.
I'm not sure if there is lots of code which parses the content of the
urls manually. It's not guaranteed what it contains, and we already apply
_lots_ of magic to those URLs (property expansion, etc). So anyone which
does not use our stuff is on his own anyway. Actually the content is still a
valid URL in the sense of RFC-1738. But it's our own protocol now ;)
Just my $0.02
LieGrue,
strub
PS: I really like the 'absolute:' protocol name Robert proposed (instead
of 'static:'.
+1
--- On Thu, 7/28/11, Benson Marguliesbimargul...@gmail.com wrote:
From: Benson Marguliesbimargul...@gmail.com
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011, 10:01 PM
As well I know from MSITE-600.
However, now I'm confused: you
couldn't use the static business with
/project/distributionManagement/site/url, since those are
naked urls.
The proposal above is not scm:static:, it's static:scm:.
are you
suggesting putting static:http: in
/project/distributionManagement/site/url? That looks
like a problem
for anything that parses the pom and doesn't use the model
code, and I
thought we felt precluded from busting things like this.
Yet Another Alternative:
url static='true'what-we-have-today/url
would work for scm and also for websites. In my opinion,
the
'disconnected parent' issue has to be fully taken on board,
and that
really calls for
url
inherit='false'what-we-have-today/url
which would be a good thing for the overall ASF pom.
On Thu, Jul 28, 2011 at 5:50 PM, John Caseyjdca...@commonjava.org
wrote:
using scm2: you're not able to apply the solution to
website urls, etc.
which have a similar inheritance/calculation
problem...
On 7/28/11 5:45 PM, Benson Margulies wrote:
Is static: really superior to scm2: and then more
colons allowing
arbitrary keyword-value pairs?
On Thu, Jul 28, 2011 at 5:44 PM, Mark
Strubergstrub...@yahoo.de
wrote:
Hi!
A small update:
Benjamin mentioned that this might also be
useful for site URLs if a user
like to define the effective URLs of the
sub-module site via
${project.version}/${project.artifactId} or
similar.
So we just came up with static: as prefix.
More soon via Jira.
LieGrue,
strub
--- On Thu, 7/28/11, Brian Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project
URL composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011, 9:32 PM
not crazy about the syntax, but
generally yes i think that makes sense.
I've long maintained that we need
something similar for
properties to
balance between resolve at build time
and resolve at
fetch from
repo type of issues.
On Thu, Jul 28, 2011 at 3:37 PM, Mark
Strubergstrub...@yahoo.de
wrote:
Hi John, Brian
Just to make sure I did understand
that correctly:
you propose to use a special URL
prefix to tell the
maven DefaultProjectBuilder to treat those
urls as static.
An example:
scm
developerConnectionstaticscm:git:ssh://myserver:/../developerConnection
resulting in replacing 'staticscm'
with 'scm' and not
adding the child modules to the URL.
Did I get this correctly?
Tried that with mvn-3.0.3 and
mvn-2.2.1 and a standard
build works just fine. Of course a release
would only work
with the newer maven versions!
LieGrue,
strub
--- On Thu, 7/28/11, Brian Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM
child-project URL
composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011,
7:23 PM
On Thu, Jul 28, 2011 at 2:59 PM,
John
Caseyjdca...@commonjava.org
wrote:
Would it be better to have a
syntax to mark a
URL as
literal, not to be
calculated or used as the
basis of
calculation?
Yes. I tried to fix this behavior
for urls back in
~2.0.6/7
ish and it
broke lots of stuff that depended
upon that
behavior.
That way, we don't have to
worry about
adjusting to
new SCMs or other places
where we want to use it...new
SCMs could be
added via
build extension,
Re: [DISCUSS] SCM child-project URL composition
will try that too
yup, just fine too with mvn-3.0.3 and mvn-2.2.1.
So we now have either
A.)
url absolute=truescm:git:https://...
or
B.)
urlabsolute:scm:git:https://...
Please decide folks ;)
LieGrue,
strub
--- On Thu, 7/28/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote:
From: Stephen Connolly stephen.alan.conno...@gmail.com
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers List dev@maven.apache.org
Date: Thursday, July 28, 2011, 10:47 PM
i think modelleo allows any random
attributes (as other pays them no heed...
not sure of ivy, and the others... but they are likely only
looking at
dependencies... a garden problem alright)
- Stephen
---
Sent from my Android phone, so random spelling mistakes,
random nonsense
words and other nonsense are a direct result of using swype
to type on the
screen
On 28 Jul 2011 23:38, Benson Margulies bimargul...@gmail.com
wrote:
attributes are special in XML schema. I plan to check
and see if pom
4.0 really precludes unqualified attributes.
On Jul 28, 2011, at 6:26 PM, John Casey jdca...@commonjava.org
wrote:
On 7/28/11 6:12 PM, Mark Struberg wrote:
Hi and txs 4 looking through the proposal!
url static=true is a neat idea but
sadly requires us to change the
pom-4.0 schema. So I fear this is a no-go atm.
I'm not sure if there is lots of code which
parses the content of the
urls manually. It's not guaranteed what it contains, and we
already apply
_lots_ of magic to those URLs (property expansion, etc). So
anyone which
does not use our stuff is on his own anyway. Actually the
content is still a
valid URL in the sense of RFC-1738. But it's our own
protocol now ;)
Just my $0.02
LieGrue,
strub
PS: I really like the 'absolute:' protocol
name Robert proposed (instead
of 'static:'.
+1
--- On Thu, 7/28/11, Benson Marguliesbimargul...@gmail.com
wrote:
From: Benson Marguliesbimargul...@gmail.com
Subject: Re: [DISCUSS] SCM child-project
URL composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011, 10:01 PM
As well I know from MSITE-600.
However, now I'm confused: you
couldn't use the static business with
/project/distributionManagement/site/url,
since those are
naked urls.
The proposal above is not scm:static:,
it's static:scm:.
are you
suggesting putting static:http: in
/project/distributionManagement/site/url?
That looks
like a problem
for anything that parses the pom and
doesn't use the model
code, and I
thought we felt precluded from busting
things like this.
Yet Another Alternative:
url
static='true'what-we-have-today/url
would work for scm and also for websites.
In my opinion,
the
'disconnected parent' issue has to be
fully taken on board,
and that
really calls for
url
inherit='false'what-we-have-today/url
which would be a good thing for the
overall ASF pom.
On Thu, Jul 28, 2011 at 5:50 PM, John
Caseyjdca...@commonjava.org
wrote:
using scm2: you're not able to apply
the solution to
website urls, etc.
which have a similar
inheritance/calculation
problem...
On 7/28/11 5:45 PM, Benson Margulies
wrote:
Is static: really superior to
scm2: and then more
colons allowing
arbitrary keyword-value pairs?
On Thu, Jul 28, 2011 at 5:44 PM,
Mark
Strubergstrub...@yahoo.de
wrote:
Hi!
A small update:
Benjamin mentioned that this
might also be
useful for site URLs if a user
like to define the effective
URLs of the
sub-module site via
${project.version}/${project.artifactId} or
similar.
So we just came up with
static: as prefix.
More soon via Jira.
LieGrue,
strub
--- On Thu, 7/28/11, Brian
Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM
child-project
URL composition
To: Maven Developers
Listdev@maven.apache.org
Date: Thursday, July 28,
2011, 9:32 PM
not crazy about the
syntax, but
generally yes i think that
makes sense.
I've long maintained that
we need
something similar for
properties to
balance between resolve
at build time
and resolve at
fetch from
repo type of issues.
On Thu, Jul 28, 2011 at
3:37 PM, Mark
Strubergstrub...@yahoo.de
wrote:
Hi John, Brian
Just to make sure I
did understand
that correctly:
you propose to use a
special URL
prefix to tell the
maven
DefaultProjectBuilder to treat those
urls as static.
An example:
scm
developerConnectionstaticscm:git:ssh://myserver:/../developerConnection
resulting in replacing
'staticscm'
with 'scm' and not
adding the child modules
to the URL.
Did I get this
correctly?
Tried that with
mvn-3.0.3 and
mvn-2.2.1 and a standard
build works just fine. Of
course a release
would only work
with the newer maven
versions!
LieGrue,
strub
--- On Thu, 7/28/11,
Brian
Re: [DISCUSS] SCM child-project URL composition
Since the attributes work, let's go with that. It's cleaner than a
mangled URL, IMO. That's my vote, anyway.
-john
On 7/28/11 6:59 PM, Mark Struberg wrote:
will try that too
yup, just fine too with mvn-3.0.3 and mvn-2.2.1.
So we now have either
A.)
url absolute=truescm:git:https://...
or
B.)
urlabsolute:scm:git:https://...
Please decide folks ;)
LieGrue,
strub
--- On Thu, 7/28/11, Stephen Connollystephen.alan.conno...@gmail.com wrote:
From: Stephen Connollystephen.alan.conno...@gmail.com
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011, 10:47 PM
i think modelleo allows any random
attributes (as other pays them no heed...
not sure of ivy, and the others... but they are likely only
looking at
dependencies... a garden problem alright)
- Stephen
---
Sent from my Android phone, so random spelling mistakes,
random nonsense
words and other nonsense are a direct result of using swype
to type on the
screen
On 28 Jul 2011 23:38, Benson Marguliesbimargul...@gmail.com
wrote:
attributes are special in XML schema. I plan to check
and see if pom
4.0 really precludes unqualified attributes.
On Jul 28, 2011, at 6:26 PM, John Caseyjdca...@commonjava.org
wrote:
On 7/28/11 6:12 PM, Mark Struberg wrote:
Hi and txs 4 looking through the proposal!
url static=true is a neat idea but
sadly requires us to change the
pom-4.0 schema. So I fear this is a no-go atm.
I'm not sure if there is lots of code which
parses the content of the
urls manually. It's not guaranteed what it contains, and we
already apply
_lots_ of magic to those URLs (property expansion, etc). So
anyone which
does not use our stuff is on his own anyway. Actually the
content is still a
valid URL in the sense of RFC-1738. But it's our own
protocol now ;)
Just my $0.02
LieGrue,
strub
PS: I really like the 'absolute:' protocol
name Robert proposed (instead
of 'static:'.
+1
--- On Thu, 7/28/11, Benson Marguliesbimargul...@gmail.com
wrote:
From: Benson Marguliesbimargul...@gmail.com
Subject: Re: [DISCUSS] SCM child-project
URL composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011, 10:01 PM
As well I know from MSITE-600.
However, now I'm confused: you
couldn't use the static business with
/project/distributionManagement/site/url,
since those are
naked urls.
The proposal above is not scm:static:,
it's static:scm:.
are you
suggesting putting static:http: in
/project/distributionManagement/site/url?
That looks
like a problem
for anything that parses the pom and
doesn't use the model
code, and I
thought we felt precluded from busting
things like this.
Yet Another Alternative:
url
static='true'what-we-have-today/url
would work for scm and also for websites.
In my opinion,
the
'disconnected parent' issue has to be
fully taken on board,
and that
really calls for
url
inherit='false'what-we-have-today/url
which would be a good thing for the
overall ASF pom.
On Thu, Jul 28, 2011 at 5:50 PM, John
Caseyjdca...@commonjava.org
wrote:
using scm2: you're not able to apply
the solution to
website urls, etc.
which have a similar
inheritance/calculation
problem...
On 7/28/11 5:45 PM, Benson Margulies
wrote:
Is static: really superior to
scm2: and then more
colons allowing
arbitrary keyword-value pairs?
On Thu, Jul 28, 2011 at 5:44 PM,
Mark
Strubergstrub...@yahoo.de
wrote:
Hi!
A small update:
Benjamin mentioned that this
might also be
useful for site URLs if a user
like to define the effective
URLs of the
sub-module site via
${project.version}/${project.artifactId} or
similar.
So we just came up with
static: as prefix.
More soon via Jira.
LieGrue,
strub
--- On Thu, 7/28/11, Brian
Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM
child-project
URL composition
To: Maven Developers
Listdev@maven.apache.org
Date: Thursday, July 28,
2011, 9:32 PM
not crazy about the
syntax, but
generally yes i think that
makes sense.
I've long maintained that
we need
something similar for
properties to
balance between resolve
at build time
and resolve at
fetch from
repo type of issues.
On Thu, Jul 28, 2011 at
3:37 PM, Mark
Strubergstrub...@yahoo.de
wrote:
Hi John, Brian
Just to make sure I
did understand
that correctly:
you propose to use a
special URL
prefix to tell the
maven
DefaultProjectBuilder to treat those
urls as static.
An example:
scm
developerConnectionstaticscm:git:ssh://myserver:/../developerConnection
resulting in replacing
'staticscm'
with 'scm' and not
adding the child modules
to the URL.
Did I get this
correctly?
Tried that with
mvn-3.0.3 and
mvn-2.2.1 and a standard
build works just fine. Of
course a release
would only work
with the newer maven
versions!
LieGrue,
strub
--- On Thu, 7/28/11,
Brian Foxbri...@infinity.nu
wrote:
From: Brian
Upgrading maven-checkstyle-plugin checkstyle version support
Hi all, I'm looking to use the maven-checkstyle-plugin with checkstyle 5.3, but it only supports 5.0 as of the 2.6 release of the plugin. Looking at trunk it seems to already have been upgraded to 5.3 but there haven't been commits for a couple of months. I'm using a few rules which are not available on 5.0 so can't currently make use of this plug-in. I have a few queries: 1. What are the plans for releasing v2.7 of the plugin? Is there any more work outstanding for checkstyle 5.3/5.4 support? I'd be happy to help with any remaining tasks to get this pushed out the door as it would be a useful upgrade for me. 2. I've done a quick diff of the 1.6 tag against trunk and looking at the changes, the only change related to the checkstyle 5.3 upgrade seems to be bumping the version number of the dependency in the plugin's pom file. Is this all that's needed to make the new plugins from checkstyle 5.3 executable via the plugin? 3. Given that new checkstyle releases pop up every now and again and are likely to include new plug-ins but not necessarily break the API used by maven-checkstyle-plugin, is there another mechanism that could be used to make the upgrade easier? I'm thinking something like a plugin configuration setting checkstyle.version which could be used to specify the checkstyle dependency used by the plug-in. That way it would be possible to use the plugin with future minor releases of checkstyle without having to do a new release of the plug-in itself? I might be oversimplifying things, I'm not sure if additional configuration or glue code is needed to make the new checkstyle rules available through the plug-in when upgrading to 5.3 and beyond. Obviously this would break if checkstyle changed their API but the benefits could well be worth it and the value could easily be defaulted. I'd be happy to work on this and submit a patch if someone can give me an initial pointer to let me know if they think it would be possible. Cheers, Chris
Re: [DISCUSS] SCM child-project URL composition
well the questions we need to ask then are:
does modelleo now support attributes so we can read it out
does this make a precident
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 29 Jul 2011 00:06, John Casey jdca...@commonjava.org wrote:
Since the attributes work, let's go with that. It's cleaner than a
mangled URL, IMO. That's my vote, anyway.
-john
On 7/28/11 6:59 PM, Mark Struberg wrote:
will try that too
yup, just fine too with mvn-3.0.3 and mvn-2.2.1.
So we now have either
A.)
url absolute=truescm:git:https://...
or
B.)
urlabsolute:scm:git:https://...
Please decide folks ;)
LieGrue,
strub
--- On Thu, 7/28/11, Stephen Connollystephen.alan.conno...@gmail.com
wrote:
From: Stephen Connollystephen.alan.conno...@gmail.com
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011, 10:47 PM
i think modelleo allows any random
attributes (as other pays them no heed...
not sure of ivy, and the others... but they are likely only
looking at
dependencies... a garden problem alright)
- Stephen
---
Sent from my Android phone, so random spelling mistakes,
random nonsense
words and other nonsense are a direct result of using swype
to type on the
screen
On 28 Jul 2011 23:38, Benson Marguliesbimargul...@gmail.com
wrote:
attributes are special in XML schema. I plan to check
and see if pom
4.0 really precludes unqualified attributes.
On Jul 28, 2011, at 6:26 PM, John Caseyjdca...@commonjava.org
wrote:
On 7/28/11 6:12 PM, Mark Struberg wrote:
Hi and txs 4 looking through the proposal!
url static=true is a neat idea but
sadly requires us to change the
pom-4.0 schema. So I fear this is a no-go atm.
I'm not sure if there is lots of code which
parses the content of the
urls manually. It's not guaranteed what it contains, and we
already apply
_lots_ of magic to those URLs (property expansion, etc). So
anyone which
does not use our stuff is on his own anyway. Actually the
content is still a
valid URL in the sense of RFC-1738. But it's our own
protocol now ;)
Just my $0.02
LieGrue,
strub
PS: I really like the 'absolute:' protocol
name Robert proposed (instead
of 'static:'.
+1
--- On Thu, 7/28/11, Benson Marguliesbimargul...@gmail.com
wrote:
From: Benson Marguliesbimargul...@gmail.com
Subject: Re: [DISCUSS] SCM child-project
URL composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011, 10:01 PM
As well I know from MSITE-600.
However, now I'm confused: you
couldn't use the static business with
/project/distributionManagement/site/url,
since those are
naked urls.
The proposal above is not scm:static:,
it's static:scm:.
are you
suggesting putting static:http: in
/project/distributionManagement/site/url?
That looks
like a problem
for anything that parses the pom and
doesn't use the model
code, and I
thought we felt precluded from busting
things like this.
Yet Another Alternative:
url
static='true'what-we-have-today/url
would work for scm and also for websites.
In my opinion,
the
'disconnected parent' issue has to be
fully taken on board,
and that
really calls for
url
inherit='false'what-we-have-today/url
which would be a good thing for the
overall ASF pom.
On Thu, Jul 28, 2011 at 5:50 PM, John
Caseyjdca...@commonjava.org
wrote:
using scm2: you're not able to apply
the solution to
website urls, etc.
which have a similar
inheritance/calculation
problem...
On 7/28/11 5:45 PM, Benson Margulies
wrote:
Is static: really superior to
scm2: and then more
colons allowing
arbitrary keyword-value pairs?
On Thu, Jul 28, 2011 at 5:44 PM,
Mark
Strubergstrub...@yahoo.de
wrote:
Hi!
A small update:
Benjamin mentioned that this
might also be
useful for site URLs if a user
like to define the effective
URLs of the
sub-module site via
${project.version}/${project.artifactId} or
similar.
So we just came up with
static: as prefix.
More soon via Jira.
LieGrue,
strub
--- On Thu, 7/28/11, Brian
Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM
child-project
URL composition
To: Maven Developers
Listdev@maven.apache.org
Date: Thursday, July 28,
2011, 9:32 PM
not crazy about the
syntax, but
generally yes i think that
makes sense.
I've long maintained that
we need
something similar for
properties to
balance between resolve
at build time
and resolve at
fetch from
repo type of issues.
On Thu, Jul 28, 2011 at
3:37 PM, Mark
Strubergstrub...@yahoo.de
wrote:
Hi John, Brian
Just to make sure I
did understand
that correctly:
you propose to use a
special URL
prefix to tell the
maven
DefaultProjectBuilder to treat those
urls as static.
An example:
scm
Re: [DISCUSS] SCM child-project URL composition
we already have the plugin config inheritance attributes in modello.
On Jul 28, 2011, at 7:27 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
well the questions we need to ask then are:
does modelleo now support attributes so we can read it out
does this make a precident
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 29 Jul 2011 00:06, John Casey jdca...@commonjava.org wrote:
Since the attributes work, let's go with that. It's cleaner than a
mangled URL, IMO. That's my vote, anyway.
-john
On 7/28/11 6:59 PM, Mark Struberg wrote:
will try that too
yup, just fine too with mvn-3.0.3 and mvn-2.2.1.
So we now have either
A.)
url absolute=truescm:git:https://...
or
B.)
urlabsolute:scm:git:https://...
Please decide folks ;)
LieGrue,
strub
--- On Thu, 7/28/11, Stephen Connollystephen.alan.conno...@gmail.com
wrote:
From: Stephen Connollystephen.alan.conno...@gmail.com
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011, 10:47 PM
i think modelleo allows any random
attributes (as other pays them no heed...
not sure of ivy, and the others... but they are likely only
looking at
dependencies... a garden problem alright)
- Stephen
---
Sent from my Android phone, so random spelling mistakes,
random nonsense
words and other nonsense are a direct result of using swype
to type on the
screen
On 28 Jul 2011 23:38, Benson Marguliesbimargul...@gmail.com
wrote:
attributes are special in XML schema. I plan to check
and see if pom
4.0 really precludes unqualified attributes.
On Jul 28, 2011, at 6:26 PM, John Caseyjdca...@commonjava.org
wrote:
On 7/28/11 6:12 PM, Mark Struberg wrote:
Hi and txs 4 looking through the proposal!
url static=true is a neat idea but
sadly requires us to change the
pom-4.0 schema. So I fear this is a no-go atm.
I'm not sure if there is lots of code which
parses the content of the
urls manually. It's not guaranteed what it contains, and we
already apply
_lots_ of magic to those URLs (property expansion, etc). So
anyone which
does not use our stuff is on his own anyway. Actually the
content is still a
valid URL in the sense of RFC-1738. But it's our own
protocol now ;)
Just my $0.02
LieGrue,
strub
PS: I really like the 'absolute:' protocol
name Robert proposed (instead
of 'static:'.
+1
--- On Thu, 7/28/11, Benson Marguliesbimargul...@gmail.com
wrote:
From: Benson Marguliesbimargul...@gmail.com
Subject: Re: [DISCUSS] SCM child-project
URL composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011, 10:01 PM
As well I know from MSITE-600.
However, now I'm confused: you
couldn't use the static business with
/project/distributionManagement/site/url,
since those are
naked urls.
The proposal above is not scm:static:,
it's static:scm:.
are you
suggesting putting static:http: in
/project/distributionManagement/site/url?
That looks
like a problem
for anything that parses the pom and
doesn't use the model
code, and I
thought we felt precluded from busting
things like this.
Yet Another Alternative:
url
static='true'what-we-have-today/url
would work for scm and also for websites.
In my opinion,
the
'disconnected parent' issue has to be
fully taken on board,
and that
really calls for
url
inherit='false'what-we-have-today/url
which would be a good thing for the
overall ASF pom.
On Thu, Jul 28, 2011 at 5:50 PM, John
Caseyjdca...@commonjava.org
wrote:
using scm2: you're not able to apply
the solution to
website urls, etc.
which have a similar
inheritance/calculation
problem...
On 7/28/11 5:45 PM, Benson Margulies
wrote:
Is static: really superior to
scm2: and then more
colons allowing
arbitrary keyword-value pairs?
On Thu, Jul 28, 2011 at 5:44 PM,
Mark
Strubergstrub...@yahoo.de
wrote:
Hi!
A small update:
Benjamin mentioned that this
might also be
useful for site URLs if a user
like to define the effective
URLs of the
sub-module site via
${project.version}/${project.artifactId} or
similar.
So we just came up with
static: as prefix.
More soon via Jira.
LieGrue,
strub
--- On Thu, 7/28/11, Brian
Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM
child-project
URL composition
To: Maven Developers
Listdev@maven.apache.org
Date: Thursday, July 28,
2011, 9:32 PM
not crazy about the
syntax, but
generally yes i think that
makes sense.
I've long maintained that
we need
something similar for
properties to
balance between resolve
at build time
and resolve at
fetch from
repo type of issues.
On Thu, Jul 28, 2011 at
3:37 PM, Mark
Strubergstrub...@yahoo.de
wrote:
Hi John, Brian
Just to make sure I
did understand
that correctly:
Re: [DISCUSS] SCM child-project URL composition
I would also propose
C) A small bit of Java code in the form of a component for each SCM type and
inject those into the inheritance assembler to deal with the URLs. Then no need
is required in the POM, and we can also look at the version of Maven if we want
to mimic historic behavior. We could also try to simply the form we currently
have to simply allow native expressions like:
g...@github.com:sonatype/sonatype-aether.git
And deal with those in the component if it's determined it's possible. I think
this method has the advantage of requiring zero change to the POM, no trickery
with Modello, can be made flexible with relation to different versions of Maven
and will allow a progression toward using native expressions. It would be a bit
more code but are we sure we can handle weirder cases like with Perforce or
Clearcase with just absolute and relative?. If someone can hack out a little
bit a Java code I think that's ultimately simpler than trying to play with
regular expressions, and modello.
On Jul 28, 2011, at 6:59 PM, Mark Struberg wrote:
will try that too
yup, just fine too with mvn-3.0.3 and mvn-2.2.1.
So we now have either
A.)
url absolute=truescm:git:https://...
or
B.)
urlabsolute:scm:git:https://...
Please decide folks ;)
LieGrue,
strub
--- On Thu, 7/28/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote:
From: Stephen Connolly stephen.alan.conno...@gmail.com
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers List dev@maven.apache.org
Date: Thursday, July 28, 2011, 10:47 PM
i think modelleo allows any random
attributes (as other pays them no heed...
not sure of ivy, and the others... but they are likely only
looking at
dependencies... a garden problem alright)
- Stephen
---
Sent from my Android phone, so random spelling mistakes,
random nonsense
words and other nonsense are a direct result of using swype
to type on the
screen
On 28 Jul 2011 23:38, Benson Margulies bimargul...@gmail.com
wrote:
attributes are special in XML schema. I plan to check
and see if pom
4.0 really precludes unqualified attributes.
On Jul 28, 2011, at 6:26 PM, John Casey jdca...@commonjava.org
wrote:
On 7/28/11 6:12 PM, Mark Struberg wrote:
Hi and txs 4 looking through the proposal!
url static=true is a neat idea but
sadly requires us to change the
pom-4.0 schema. So I fear this is a no-go atm.
I'm not sure if there is lots of code which
parses the content of the
urls manually. It's not guaranteed what it contains, and we
already apply
_lots_ of magic to those URLs (property expansion, etc). So
anyone which
does not use our stuff is on his own anyway. Actually the
content is still a
valid URL in the sense of RFC-1738. But it's our own
protocol now ;)
Just my $0.02
LieGrue,
strub
PS: I really like the 'absolute:' protocol
name Robert proposed (instead
of 'static:'.
+1
--- On Thu, 7/28/11, Benson Marguliesbimargul...@gmail.com
wrote:
From: Benson Marguliesbimargul...@gmail.com
Subject: Re: [DISCUSS] SCM child-project
URL composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011, 10:01 PM
As well I know from MSITE-600.
However, now I'm confused: you
couldn't use the static business with
/project/distributionManagement/site/url,
since those are
naked urls.
The proposal above is not scm:static:,
it's static:scm:.
are you
suggesting putting static:http: in
/project/distributionManagement/site/url?
That looks
like a problem
for anything that parses the pom and
doesn't use the model
code, and I
thought we felt precluded from busting
things like this.
Yet Another Alternative:
url
static='true'what-we-have-today/url
would work for scm and also for websites.
In my opinion,
the
'disconnected parent' issue has to be
fully taken on board,
and that
really calls for
url
inherit='false'what-we-have-today/url
which would be a good thing for the
overall ASF pom.
On Thu, Jul 28, 2011 at 5:50 PM, John
Caseyjdca...@commonjava.org
wrote:
using scm2: you're not able to apply
the solution to
website urls, etc.
which have a similar
inheritance/calculation
problem...
On 7/28/11 5:45 PM, Benson Margulies
wrote:
Is static: really superior to
scm2: and then more
colons allowing
arbitrary keyword-value pairs?
On Thu, Jul 28, 2011 at 5:44 PM,
Mark
Strubergstrub...@yahoo.de
wrote:
Hi!
A small update:
Benjamin mentioned that this
might also be
useful for site URLs if a user
like to define the effective
URLs of the
sub-module site via
${project.version}/${project.artifactId} or
similar.
So we just came up with
static: as prefix.
More soon via Jira.
LieGrue,
strub
--- On Thu, 7/28/11, Brian
Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM
child-project
URL composition
To: Maven Developers
Listdev@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Of course, not having to touch the POMs is a good thing. But I don't get the 'historic behaviour' part. Even if you would have components in the scm-providers (which all need to be changed), this solution would not work with older maven version because they will simply not get injected somewhere. Plus, you would need to split that code from the scm-providers, as explained before. But maintaining them separately, I wonder how this should scale. It must be part of maven-core, because it must clearly be available _before_ dependencies and even extensions are available. So basically it comes down to 1.) having a list of SCMs which must not get the module-name appended. It imo doesn't make much difference if you do this via a regexp or via a Java class. I think the regexp in toolchains.mdo even would have the benefit that a user would be able to overwrite/extend the default config if he needs to. 2.) marking the url tag somehow. Either inside the URL string with a prefix like 'absolute:' or via an xml attribute. The explicit marking of URLs allows this solution to get applied for site stuff too. The regexp/Java stuff would not work for the site URL problematic, because there is no information about the intention of the user in the pom atm. LieGrue, strub --- On Fri, 7/29/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 12:08 AM I would also propose C) A small bit of Java code in the form of a component for each SCM type and inject those into the inheritance assembler to deal with the URLs. Then no need is required in the POM, and we can also look at the version of Maven if we want to mimic historic behavior. We could also try to simply the form we currently have to simply allow native expressions like: g...@github.com:sonatype/sonatype-aether.git And deal with those in the component if it's determined it's possible. I think this method has the advantage of requiring zero change to the POM, no trickery with Modello, can be made flexible with relation to different versions of Maven and will allow a progression toward using native expressions. It would be a bit more code but are we sure we can handle weirder cases like with Perforce or Clearcase with just absolute and relative?. If someone can hack out a little bit a Java code I think that's ultimately simpler than trying to play with regular expressions, and modello. On Jul 28, 2011, at 6:59 PM, Mark Struberg wrote: will try that too yup, just fine too with mvn-3.0.3 and mvn-2.2.1. So we now have either A.) url absolute=truescm:git:https://... or B.) urlabsolute:scm:git:https://... Please decide folks ;) LieGrue, strub --- On Thu, 7/28/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 10:47 PM i think modelleo allows any random attributes (as other pays them no heed... not sure of ivy, and the others... but they are likely only looking at dependencies... a garden problem alright) - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jul 2011 23:38, Benson Margulies bimargul...@gmail.com wrote: attributes are special in XML schema. I plan to check and see if pom 4.0 really precludes unqualified attributes. On Jul 28, 2011, at 6:26 PM, John Casey jdca...@commonjava.org wrote: On 7/28/11 6:12 PM, Mark Struberg wrote: Hi and txs 4 looking through the proposal! url static=true is a neat idea but sadly requires us to change the pom-4.0 schema. So I fear this is a no-go atm. I'm not sure if there is lots of code which parses the content of the urls manually. It's not guaranteed what it contains, and we already apply _lots_ of magic to those URLs (property expansion, etc). So anyone which does not use our stuff is on his own anyway. Actually the content is still a valid URL in the sense of RFC-1738. But it's our own protocol now ;) Just my $0.02 LieGrue, strub PS: I really like the 'absolute:' protocol name Robert proposed (instead of 'static:'. +1 --- On Thu, 7/28/11, Benson Marguliesbimargul...@gmail.com wrote: From: Benson Marguliesbimargul...@gmail.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers Listdev@maven.apache.org Date: Thursday, July 28, 2011, 10:01 PM As well I know from MSITE-600. However, now I'm confused: you couldn't use the static business with
Re: [DISCUSS] SCM child-project URL composition
On Jul 28, 2011, at 8:31 PM, Mark Struberg wrote: Of course, not having to touch the POMs is a good thing. But I don't get the 'historic behaviour' part. Even if you would have components in the scm-providers (which all need to be changed), this solution would not work with older maven version because they will simply not get injected somewhere. Dealing with what people use today versus native expressions in the future. The components are simple, they could be external and use in Maven 2.x and 3.x. Plus, you would need to split that code from the scm-providers, as explained before. But maintaining them separately, I wonder how this should scale. It must be part of maven-core, because it must clearly be available _before_ dependencies and even extensions are available. We're going to end up with a few lines of code for each SCM. For the short term I doubt this is going to be a problem because there are probably less than 10 to deal with and changes could be made quickly and then they are unlikely to change. It's not a lot of code to deal with, it can be in Maven as it is more for POM construction than anything to do with any particular SCM. So basically it comes down to 1.) having a list of SCMs which must not get the module-name appended. It imo doesn't make much difference if you do this via a regexp or via a Java class. I think the regexp in toolchains.mdo even would have the benefit that a user would be able to overwrite/extend the default config if he needs to. Is it as simple as that for all SCMs? 2.) marking the url tag somehow. Either inside the URL string with a prefix like 'absolute:' or via an xml attribute. The explicit marking of URLs allows this solution to get applied for site stuff too. The regexp/Java stuff would not work for the site URL problematic, because there is no information about the intention of the user in the pom atm. It would be useful to see the forms SCM URL construction for: CVS SVN Git Hg Perforce Clearcase And anything else that people might want. I think if it's going to be something that must work for all cases, and cases we cannot foresee then a simple implementation in a component where the default implementation is component that uses regexes that's fine, but if we're thinking of making this pluggable then I think allowing someone to plug in whatever logic they want would be useful. LieGrue, strub --- On Fri, 7/29/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 12:08 AM I would also propose C) A small bit of Java code in the form of a component for each SCM type and inject those into the inheritance assembler to deal with the URLs. Then no need is required in the POM, and we can also look at the version of Maven if we want to mimic historic behavior. We could also try to simply the form we currently have to simply allow native expressions like: g...@github.com:sonatype/sonatype-aether.git And deal with those in the component if it's determined it's possible. I think this method has the advantage of requiring zero change to the POM, no trickery with Modello, can be made flexible with relation to different versions of Maven and will allow a progression toward using native expressions. It would be a bit more code but are we sure we can handle weirder cases like with Perforce or Clearcase with just absolute and relative?. If someone can hack out a little bit a Java code I think that's ultimately simpler than trying to play with regular expressions, and modello. On Jul 28, 2011, at 6:59 PM, Mark Struberg wrote: will try that too yup, just fine too with mvn-3.0.3 and mvn-2.2.1. So we now have either A.) url absolute=truescm:git:https://... or B.) urlabsolute:scm:git:https://... Please decide folks ;) LieGrue, strub --- On Thu, 7/28/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 10:47 PM i think modelleo allows any random attributes (as other pays them no heed... not sure of ivy, and the others... but they are likely only looking at dependencies... a garden problem alright) - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jul 2011 23:38, Benson Margulies bimargul...@gmail.com wrote: attributes are special in XML schema. I plan to check and see if pom 4.0 really precludes unqualified attributes. On Jul 28, 2011, at 6:26 PM, John Casey jdca...@commonjava.org wrote: On 7/28/11 6:12 PM, Mark Struberg
Re: [DISCUSS] SCM child-project URL composition
Is it as simple as that for all SCMs? Yes it is. Remember the old days: this is only a fix for a 'fix'. Originally the SCM URLs haven't been changed for child modules. This 'feature' only got introduce later to make life easier for SVN and CVS users (the vast majority of projects back then). What we now do is to disable this 'feature' (which now got a known and expected default behaviour) in some certain cases. Not more not less. I honestly fear of doing some magic with the SCM Urls because those are NOT native urls but get interpreted by the SCM providers. Thus the 'url adaptors' would need to 100% match the specific scm providers. So you either ship it in the same build or you are soon doomed I fear. But as you need to ship that classes as part of a maven release, there is just no upgrade scenario and you would need to support sins for a long time... The 2nd nice benefit: I'm currently digging into the attribute stuff in Modello. If this works out, we can use this approach for other long awaited features (like the mixins) in a pom-4.0.0 compatible way! LieGrue, strub --- On Fri, 7/29/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 12:47 AM On Jul 28, 2011, at 8:31 PM, Mark Struberg wrote: Of course, not having to touch the POMs is a good thing. But I don't get the 'historic behaviour' part. Even if you would have components in the scm-providers (which all need to be changed), this solution would not work with older maven version because they will simply not get injected somewhere. Dealing with what people use today versus native expressions in the future. The components are simple, they could be external and use in Maven 2.x and 3.x. Plus, you would need to split that code from the scm-providers, as explained before. But maintaining them separately, I wonder how this should scale. It must be part of maven-core, because it must clearly be available _before_ dependencies and even extensions are available. We're going to end up with a few lines of code for each SCM. For the short term I doubt this is going to be a problem because there are probably less than 10 to deal with and changes could be made quickly and then they are unlikely to change. It's not a lot of code to deal with, it can be in Maven as it is more for POM construction than anything to do with any particular SCM. So basically it comes down to 1.) having a list of SCMs which must not get the module-name appended. It imo doesn't make much difference if you do this via a regexp or via a Java class. I think the regexp in toolchains.mdo even would have the benefit that a user would be able to overwrite/extend the default config if he needs to. Is it as simple as that for all SCMs? 2.) marking the url tag somehow. Either inside the URL string with a prefix like 'absolute:' or via an xml attribute. The explicit marking of URLs allows this solution to get applied for site stuff too. The regexp/Java stuff would not work for the site URL problematic, because there is no information about the intention of the user in the pom atm. It would be useful to see the forms SCM URL construction for: CVS SVN Git Hg Perforce Clearcase And anything else that people might want. I think if it's going to be something that must work for all cases, and cases we cannot foresee then a simple implementation in a component where the default implementation is component that uses regexes that's fine, but if we're thinking of making this pluggable then I think allowing someone to plug in whatever logic they want would be useful. LieGrue, strub --- On Fri, 7/29/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 12:08 AM I would also propose C) A small bit of Java code in the form of a component for each SCM type and inject those into the inheritance assembler to deal with the URLs. Then no need is required in the POM, and we can also look at the version of Maven if we want to mimic historic behavior. We could also try to simply the form we currently have to simply allow native expressions like: g...@github.com:sonatype/sonatype-aether.git And deal with those in the component if it's determined it's possible. I think this method has the advantage of requiring zero change to the POM, no trickery with Modello, can be made flexible with relation to different versions of Maven and will allow a progression toward using native expressions. It would be a bit more code but are we sure we can handle weirder cases like with Perforce or Clearcase
Re: [DISCUSS] SCM child-project URL composition
I have some perhaps minor bad news about attributes. Attributes on the url/ element won't validate against the current schema. I had hoped to discover otherwise, but no such luck. The combine.children trick passes because it is inside of the 'any' inside the plugin configuration. I claim that the following is tolerable from a compatibility standpoint: 1) create a 4.0.1 XSD file that adds the necessary xs:anyAttribute (or specific attributes, if you prefer) to the url/ element. 2) Change default archetypes and the release plugin and friends to add this schema instead of the 4.0.0 schema. In other words, Mark's experiments show that, in *practical* terms, adding the attributes works. That leave the question of programs that actually pay attention to the schema itself. The only bad case would be some program out there which for some reason always validates against the 4.0.0 schema even if the schema declared at the top is 4.0.1. I don't believe in this. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
This was exactly the fix I applied back in 2.0.6 ish times and broke too much stuff. Because the currently impl doesn't care about the trailing /, too many poms have it set incorrectly. On Thu, Jul 28, 2011 at 5:49 PM, John Casey jdca...@commonjava.org wrote: On 7/28/11 5:43 PM, Benson Margulies wrote: I keep thinking that I read about a convention that used the presence or absence of a trailing '/' on the URL to control this. Does anyone else recall this? You mean overloading an explicit URL referencing a directory? Seems a tad confusing and maybe even a problem waiting to happen... On Thu, Jul 28, 2011 at 5:32 PM, Brian Foxbri...@infinity.nu wrote: not crazy about the syntax, but generally yes i think that makes sense. I've long maintained that we need something similar for properties to balance between resolve at build time and resolve at fetch from repo type of issues. On Thu, Jul 28, 2011 at 3:37 PM, Mark Strubergstrub...@yahoo.de wrote: Hi John, Brian Just to make sure I did understand that correctly: you propose to use a special URL prefix to tell the maven DefaultProjectBuilder to treat those urls as static. An example: scm developerConnectionstaticscm:git:ssh://myserver:/../developerConnection resulting in replacing 'staticscm' with 'scm' and not adding the child modules to the URL. Did I get this correctly? Tried that with mvn-3.0.3 and mvn-2.2.1 and a standard build works just fine. Of course a release would only work with the newer maven versions! LieGrue, strub --- On Thu, 7/28/11, Brian Foxbri...@infinity.nu wrote: From: Brian Foxbri...@infinity.nu Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers Listdev@maven.apache.org Date: Thursday, July 28, 2011, 7:23 PM On Thu, Jul 28, 2011 at 2:59 PM, John Caseyjdca...@commonjava.org wrote: Would it be better to have a syntax to mark a URL as literal, not to be calculated or used as the basis of calculation? Yes. I tried to fix this behavior for urls back in ~2.0.6/7 ish and it broke lots of stuff that depended upon that behavior. That way, we don't have to worry about adjusting to new SCMs or other places where we want to use it...new SCMs could be added via build extension, IIRC, so this is particularly important there. WDYT? On 7/28/11 12:46 PM, Mark Struberg wrote: Hi! problem description --- SCM URLs currently automatically get extended for child modules. E.g. from svn://mycompany.com/myproject in the parent pom, a child module 'frontend' will result in getting a SCM URL svn://mycompany.com/myproject/frontend This is fine for SVN and CVS, but broken for GIT, HG, etc because the SCM URL is 'static' for them. proposal --- Since we cannot put this information into the various scm plugins (because of a 'definition cycle' as explained here [1]) we could split the URL construction into scmUrlAppendChild=true/false and make it configurable. The configuration could be controlled via a Modello config, my suggestion would be to just add them to toolchains.mdo. I'd just add a String property which holds a regular expression which parses the SCM URL and decides upon this whether the appending should get activated, e.g. for all SCMs which contain 'scm:svn:' or 'scm:cvs:' or the java-svn (olamy, you know the plexus key for that?) If there is a better place to put that config or a better way to get the info, then please speak up now :) I think this change would be backward compatible and doesn't need any pom changes. It also could easily get back-ported to mvn2 if needed. Are there other URLS which also need a similar distinction while building the model? WDYT? txs and LieGrue, strub [1] http://markmail.org/message/npw3hp6aloa55ctf - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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
[jira] Subscription: Design Best Practices
Issue Subscription
Filter: Design Best Practices (24 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
https://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
https://jira.codehaus.org/browse/MNG-612
MNG-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to jsp tags or jsf composites
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
MNG-1569Make build process info read-only to mojos, and provide mechanism
for explicit out-params for mojos to declare
https://jira.codehaus.org/browse/MNG-1569
MNG-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for properties and other tags
https://jira.codehaus.org/browse/MNG-868
MNG-1425best practices: the location of configuration files vs resources
https://jira.codehaus.org/browse/MNG-1425
MNG-1463best practices: plugin inheritance for a multi project build
https://jira.codehaus.org/browse/MNG-1463
MNG-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
MNG-1867deprecate system scope, analyse other use cases
https://jira.codehaus.org/browse/MNG-1867
MNG-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
