Re: [VOTE] Release Maven JXR version 2.3
+1 tested in Maven 3.0.4-SNAPSHOT [1] (sync pending) notice that there are some glitches with documentation: - plugin-info.html isn't there nor goals documentation (?) - aggregating example should be modified like javadoc to show new goals and mark aggregate parameter as obsolete nothing that prevents plugin release, but these should be fixed when the site is published Regards, Hervé Le vendredi 15 juillet 2011, Benson Margulies a écrit : Hi, We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?atl_token=ACIO-CAVI-QX7G-9 IAS|939d07db80126b429369a4acdb3a1c32519711ef|linversion=16520styleName=Te xtprojectId=11085Create=Create There are still a gaggle of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=pro ject+%3D+JXR+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-028/ Staging sites: maven.apache.org/plugins/maven-jxr-plugin/staging maven.apache.org/jxr/staging Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for at leasr 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven JXR version 2.3
Hervé, How can I make these site repairs when publishing against the label? Is the idea to go ahead and make fixes to a checkout of the tag, publish the site, and then patch them into trunk? --benson On Sat, Jul 16, 2011 at 5:06 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: +1 tested in Maven 3.0.4-SNAPSHOT [1] (sync pending) notice that there are some glitches with documentation: - plugin-info.html isn't there nor goals documentation (?) - aggregating example should be modified like javadoc to show new goals and mark aggregate parameter as obsolete nothing that prevents plugin release, but these should be fixed when the site is published Regards, Hervé Le vendredi 15 juillet 2011, Benson Margulies a écrit : Hi, We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?atl_token=ACIO-CAVI-QX7G-9 IAS|939d07db80126b429369a4acdb3a1c32519711ef|linversion=16520styleName=Te xtprojectId=11085Create=Create There are still a gaggle of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=pro ject+%3D+JXR+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-028/ Staging sites: maven.apache.org/plugins/maven-jxr-plugin/staging maven.apache.org/jxr/staging Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for at leasr 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Coordinating with Aether
Folks, I've submitted one tiny fix to Aether, and I have a feature proposal I'm discussing with the proprietor: making the *-pattern in mirrors a bit richer. Eventually, this would be 'as simple' as a change to the aether provider to take a newer aether. However, I wonder if the PMC has established any organized process of coordinating. --benson - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven JXR version 2.3
qhat I usually do is patch the trunk and when publishing the final version, I copy modified files from site to my local checkout yes, that means that the site published on maven.apache.org isn't reproducible But having a non-reproducible site isn't really an issue AFAIK modifying the svn tag would be cumbersome and more risky IMHO don't hesitate to tell me if you want help to fix issues: for the moment, I'm not working on them to avoid checkin conflicts Regards, Hervé Le samedi 16 juillet 2011, Benson Margulies a écrit : Hervé, How can I make these site repairs when publishing against the label? Is the idea to go ahead and make fixes to a checkout of the tag, publish the site, and then patch them into trunk? --benson On Sat, Jul 16, 2011 at 5:06 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: +1 tested in Maven 3.0.4-SNAPSHOT [1] (sync pending) notice that there are some glitches with documentation: - plugin-info.html isn't there nor goals documentation (?) - aggregating example should be modified like javadoc to show new goals and mark aggregate parameter as obsolete nothing that prevents plugin release, but these should be fixed when the site is published Regards, Hervé Le vendredi 15 juillet 2011, Benson Margulies a écrit : Hi, We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?atl_token=ACIO-CAVI-QX7 G-9 IAS|939d07db80126b429369a4acdb3a1c32519711ef|linversion=16520styleNam e=Te xtprojectId=11085Create=Create There are still a gaggle of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= pro ject+%3D+JXR+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-028/ Staging sites: maven.apache.org/plugins/maven-jxr-plugin/staging maven.apache.org/jxr/staging Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for at leasr 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - 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 JXR version 2.3
By the way, is anyone still active who did the previous release of JXR? It's not obvious how I could have caused these issues. On Sat, Jul 16, 2011 at 3:36 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: qhat I usually do is patch the trunk and when publishing the final version, I copy modified files from site to my local checkout yes, that means that the site published on maven.apache.org isn't reproducible But having a non-reproducible site isn't really an issue AFAIK modifying the svn tag would be cumbersome and more risky IMHO don't hesitate to tell me if you want help to fix issues: for the moment, I'm not working on them to avoid checkin conflicts Regards, Hervé Le samedi 16 juillet 2011, Benson Margulies a écrit : Hervé, How can I make these site repairs when publishing against the label? Is the idea to go ahead and make fixes to a checkout of the tag, publish the site, and then patch them into trunk? --benson On Sat, Jul 16, 2011 at 5:06 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: +1 tested in Maven 3.0.4-SNAPSHOT [1] (sync pending) notice that there are some glitches with documentation: - plugin-info.html isn't there nor goals documentation (?) - aggregating example should be modified like javadoc to show new goals and mark aggregate parameter as obsolete nothing that prevents plugin release, but these should be fixed when the site is published Regards, Hervé Le vendredi 15 juillet 2011, Benson Margulies a écrit : Hi, We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?atl_token=ACIO-CAVI-QX7 G-9 IAS|939d07db80126b429369a4acdb3a1c32519711ef|linversion=16520styleNam e=Te xtprojectId=11085Create=Create There are still a gaggle of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= pro ject+%3D+JXR+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-028/ Staging sites: maven.apache.org/plugins/maven-jxr-plugin/staging maven.apache.org/jxr/staging Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for at leasr 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - 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 JXR version 2.3
for the old aggregation parameter, it's easy for the goals documentation, yes, I don't understand how it can disappear. It seems to be using m-site-p 2.2: upgrade to 2.3? Or maybe you changed the parent? We're a few working on site improvements to avoid regressions with future releases: site ITs have improved a lot recently, but we probably still need more experience That's exaclty for this one that I proposed you to help: I'm on IRC, dont hesitate to connect Regards, Hervé Le samedi 16 juillet 2011, Benson Margulies a écrit : By the way, is anyone still active who did the previous release of JXR? It's not obvious how I could have caused these issues. On Sat, Jul 16, 2011 at 3:36 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: qhat I usually do is patch the trunk and when publishing the final version, I copy modified files from site to my local checkout yes, that means that the site published on maven.apache.org isn't reproducible But having a non-reproducible site isn't really an issue AFAIK modifying the svn tag would be cumbersome and more risky IMHO don't hesitate to tell me if you want help to fix issues: for the moment, I'm not working on them to avoid checkin conflicts Regards, Hervé Le samedi 16 juillet 2011, Benson Margulies a écrit : Hervé, How can I make these site repairs when publishing against the label? Is the idea to go ahead and make fixes to a checkout of the tag, publish the site, and then patch them into trunk? --benson On Sat, Jul 16, 2011 at 5:06 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: +1 tested in Maven 3.0.4-SNAPSHOT [1] (sync pending) notice that there are some glitches with documentation: - plugin-info.html isn't there nor goals documentation (?) - aggregating example should be modified like javadoc to show new goals and mark aggregate parameter as obsolete nothing that prevents plugin release, but these should be fixed when the site is published Regards, Hervé Le vendredi 15 juillet 2011, Benson Margulies a écrit : Hi, We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?atl_token=ACIO-CAVI- QX7 G-9 IAS|939d07db80126b429369a4acdb3a1c32519711ef|linversion=16520styleN am e=Te xtprojectId=11085Create=Create There are still a gaggle of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQue ry= pro ject+%3D+JXR+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-028/ Staging sites: maven.apache.org/plugins/maven-jxr-plugin/staging maven.apache.org/jxr/staging Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.htm l Vote open for at leasr 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - 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: [VOTE] Release Maven JXR version 2.3
I'll come looking for assistance once the vote passes. On Sat, Jul 16, 2011 at 4:09 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: for the old aggregation parameter, it's easy for the goals documentation, yes, I don't understand how it can disappear. It seems to be using m-site-p 2.2: upgrade to 2.3? Or maybe you changed the parent? We're a few working on site improvements to avoid regressions with future releases: site ITs have improved a lot recently, but we probably still need more experience That's exaclty for this one that I proposed you to help: I'm on IRC, dont hesitate to connect Regards, Hervé Le samedi 16 juillet 2011, Benson Margulies a écrit : By the way, is anyone still active who did the previous release of JXR? It's not obvious how I could have caused these issues. On Sat, Jul 16, 2011 at 3:36 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: qhat I usually do is patch the trunk and when publishing the final version, I copy modified files from site to my local checkout yes, that means that the site published on maven.apache.org isn't reproducible But having a non-reproducible site isn't really an issue AFAIK modifying the svn tag would be cumbersome and more risky IMHO don't hesitate to tell me if you want help to fix issues: for the moment, I'm not working on them to avoid checkin conflicts Regards, Hervé Le samedi 16 juillet 2011, Benson Margulies a écrit : Hervé, How can I make these site repairs when publishing against the label? Is the idea to go ahead and make fixes to a checkout of the tag, publish the site, and then patch them into trunk? --benson On Sat, Jul 16, 2011 at 5:06 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: +1 tested in Maven 3.0.4-SNAPSHOT [1] (sync pending) notice that there are some glitches with documentation: - plugin-info.html isn't there nor goals documentation (?) - aggregating example should be modified like javadoc to show new goals and mark aggregate parameter as obsolete nothing that prevents plugin release, but these should be fixed when the site is published Regards, Hervé Le vendredi 15 juillet 2011, Benson Margulies a écrit : Hi, We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?atl_token=ACIO-CAVI- QX7 G-9 IAS|939d07db80126b429369a4acdb3a1c32519711ef|linversion=16520styleN am e=Te xtprojectId=11085Create=Create There are still a gaggle of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQue ry= pro ject+%3D+JXR+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-028/ Staging sites: maven.apache.org/plugins/maven-jxr-plugin/staging maven.apache.org/jxr/staging Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.htm l Vote open for at leasr 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - 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: Coordinating with Aether
Good question :) Current Maven versions (3.0.3 and 3.0.4-SNAPSHOT) use Aether 1.11, which has a dual EPL/ASLv2 license [1]. As far new versions of Aether stay under ASLv2 license, there is no question for Maven when upgrading dependency. Now, Aether 1.12 was released under EPL license only, and actual 1.13-SNAPSHOT sources are EPL only too. Upgrading Maven dependency will imply a license change, that must be voted upon. Regards, Hervé [1] http://maven.apache.org/ref/3.0.4-SNAPSHOT/apache-maven/dependencies.html Le samedi 16 juillet 2011, Benson Margulies a écrit : Folks, I've submitted one tiny fix to Aether, and I have a feature proposal I'm discussing with the proprietor: making the *-pattern in mirrors a bit richer. Eventually, this would be 'as simple' as a change to the aether provider to take a newer aether. However, I wonder if the PMC has established any organized process of coordinating. --benson - 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: Coordinating with Aether
Well, I'm not a PMC member, so I'll just follow instructions. Someone might wonder if, given the progressive calm that has settled over the trademark business, perhaps Sonatype might go back to dual-licensing if asked? On Sat, Jul 16, 2011 at 5:36 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Good question :) Current Maven versions (3.0.3 and 3.0.4-SNAPSHOT) use Aether 1.11, which has a dual EPL/ASLv2 license [1]. As far new versions of Aether stay under ASLv2 license, there is no question for Maven when upgrading dependency. Now, Aether 1.12 was released under EPL license only, and actual 1.13-SNAPSHOT sources are EPL only too. Upgrading Maven dependency will imply a license change, that must be voted upon. Regards, Hervé [1] http://maven.apache.org/ref/3.0.4-SNAPSHOT/apache-maven/dependencies.html Le samedi 16 juillet 2011, Benson Margulies a écrit : Folks, I've submitted one tiny fix to Aether, and I have a feature proposal I'm discussing with the proprietor: making the *-pattern in mirrors a bit richer. Eventually, this would be 'as simple' as a change to the aether provider to take a newer aether. However, I wonder if the PMC has established any organized process of coordinating. --benson - 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 JXR version 2.3
For the next release, how would you feel about moving the plugin in with the other plugins, and eliminating the extra level of parent? On Sat, Jul 16, 2011 at 4:09 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: for the old aggregation parameter, it's easy for the goals documentation, yes, I don't understand how it can disappear. It seems to be using m-site-p 2.2: upgrade to 2.3? Or maybe you changed the parent? We're a few working on site improvements to avoid regressions with future releases: site ITs have improved a lot recently, but we probably still need more experience That's exaclty for this one that I proposed you to help: I'm on IRC, dont hesitate to connect Regards, Hervé Le samedi 16 juillet 2011, Benson Margulies a écrit : By the way, is anyone still active who did the previous release of JXR? It's not obvious how I could have caused these issues. On Sat, Jul 16, 2011 at 3:36 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: qhat I usually do is patch the trunk and when publishing the final version, I copy modified files from site to my local checkout yes, that means that the site published on maven.apache.org isn't reproducible But having a non-reproducible site isn't really an issue AFAIK modifying the svn tag would be cumbersome and more risky IMHO don't hesitate to tell me if you want help to fix issues: for the moment, I'm not working on them to avoid checkin conflicts Regards, Hervé Le samedi 16 juillet 2011, Benson Margulies a écrit : Hervé, How can I make these site repairs when publishing against the label? Is the idea to go ahead and make fixes to a checkout of the tag, publish the site, and then patch them into trunk? --benson On Sat, Jul 16, 2011 at 5:06 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: +1 tested in Maven 3.0.4-SNAPSHOT [1] (sync pending) notice that there are some glitches with documentation: - plugin-info.html isn't there nor goals documentation (?) - aggregating example should be modified like javadoc to show new goals and mark aggregate parameter as obsolete nothing that prevents plugin release, but these should be fixed when the site is published Regards, Hervé Le vendredi 15 juillet 2011, Benson Margulies a écrit : Hi, We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?atl_token=ACIO-CAVI- QX7 G-9 IAS|939d07db80126b429369a4acdb3a1c32519711ef|linversion=16520styleN am e=Te xtprojectId=11085Create=Create There are still a gaggle of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQue ry= pro ject+%3D+JXR+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-028/ Staging sites: maven.apache.org/plugins/maven-jxr-plugin/staging maven.apache.org/jxr/staging Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.htm l Vote open for at leasr 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - 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: [VOTE] Release Maven JXR version 2.3
Vincent S did a lot of work on JXR, and has a branch in sandbox He's actually on holiday and should reply when he's back to make the good choice Regards, Hervé Le dimanche 17 juillet 2011, Benson Margulies a écrit : For the next release, how would you feel about moving the plugin in with the other plugins, and eliminating the extra level of parent? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Coordinating with Aether
yes, that would be a good option and seems reasonable from my perspective Le dimanche 17 juillet 2011, Benson Margulies a écrit : Well, I'm not a PMC member, so I'll just follow instructions. Someone might wonder if, given the progressive calm that has settled over the trademark business, perhaps Sonatype might go back to dual-licensing if asked? On Sat, Jul 16, 2011 at 5:36 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Good question :) Current Maven versions (3.0.3 and 3.0.4-SNAPSHOT) use Aether 1.11, which has a dual EPL/ASLv2 license [1]. As far new versions of Aether stay under ASLv2 license, there is no question for Maven when upgrading dependency. Now, Aether 1.12 was released under EPL license only, and actual 1.13-SNAPSHOT sources are EPL only too. Upgrading Maven dependency will imply a license change, that must be voted upon. Regards, Hervé [1] http://maven.apache.org/ref/3.0.4-SNAPSHOT/apache-maven/dependencies.htm l Le samedi 16 juillet 2011, Benson Margulies a écrit : Folks, I've submitted one tiny fix to Aether, and I have a feature proposal I'm discussing with the proprietor: making the *-pattern in mirrors a bit richer. Eventually, this would be 'as simple' as a change to the aether provider to take a newer aether. However, I wonder if the PMC has established any organized process of coordinating. --benson - 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: SCM info and modules
Hi folks!
Just back from vacation so I try to slowly catch up speed ...
There are a few things to take care off:
a.) We must not introduce a circle: model - scm - model. In other words: we
cannot ask the scm provider to give us additional information to build the
model before the model has been built. This is a chicken-egg problem...
b.) Yes, an URL is a coordinate to access the repository. Since GIT (and other
DSCMs) allow different protocols for push and pull, we needed optionally add 2
path information to the URL.
We could now either opt for a clean solution, but this would most likely not
work with POM model-4.0.
Or we could just add another step of indirection (the classical computer
science pattern): We introduce a SCM-URL-behaviour mapping.
* BehaviourA ('relative') is the one used by e.g. SVN and CVS: automatically
adding the submodule file path to the SCM URL while building the MavenModel.
* BehaviourB ('static') means to let the SCM URL untouched when constructing
the MavenModel.
There must be a mapping somewhere between scm url regexp - SCM-URL-Strategy,
e.g. scm:svn-relative, scm:git-static, scm:jgit-static,...
This could be maintained in settings.xml and we deliver a default one in the
global settings.xml. That way it would be predefined but maintainable by the
user.
LieGrue,
strub
--- On Fri, 7/15/11, Benson Margulies bimargul...@gmail.com wrote:
From: Benson Margulies bimargul...@gmail.com
Subject: Re: SCM info and modules
To: Maven Developers List dev@maven.apache.org
Date: Friday, July 15, 2011, 8:47 PM
Let me suggest a generalization of
Hervé's thought process.
I submit that there are four issues here we might be trying
to
address. (1) users want to put an scm spec in an
aggregating project
and not have to repeat it (with slight mods) in all the
modules. (2)
users want to be able to toss a set of
aggregation-unrelated projects
into a single git repo, or some other SCM where there is a
very sharp
distinction between the coordinates of the repo and the
coordinates of
something in the repo (unlike svn), and (3), SCMs like P4
(with the
problem of managing views) where there are complex aspects
of the
situation that don't fit nicely into a URI. (4)
representing the
distinction between 'here's how to obtain *this very
module* versus
*here's now to obtain the smallest unit that you can expect
to type
'mvn at'.
If we are looking to 3.1, I think that all of these would
be addressed
best by making the scm element of the POM more
complex, by treating
it as a bag of properties, consisting of:
1: An SCM plugin identifier.
2: whatever the SCM would like to know to identify the
sensible unit
of checkin / checkout (we need a term for this. In Git it's
a repo,
for svn it's just a path).
3: A path within this unit for this project.
4: other, per-scm, parameters.
Before 3.1, we can, of course, cram all this into one URI.
The issue
is how to separate stuff that is viable for the scm itself
from our
other information. Using a # inside 'the url' is unsafe, I
submit,
since some scm or another could really use a fragment for
something.
How about:
scm2:new-maven-params:provider-tag:current-provider-params
No one is forced to switch to scm2. If they want the
features it
enables, they have to eschew tools that don't support it.
One thing still seems insufficient about this to me.
Whether a project
requires an aggregation environment to build is not,
really, just an
scm question. Right now, nothing inside a project states
whether it is
really independent (published parent) or not. In the case
of complex
parent structures, there is no simple scheme that does the
job. Item 3
above sort of solves the problem. but does not distinguish
between
'this is an independent project at relative path x within a
lump of
stuff you get from the scm' and 'this is only buildable as
a module of
some other aggregating project.'
Do we really need to solve that? If so, we could add one
more fact:
the g:a of the parent from which a build makes sense. Maven
could then
chase up the parent tree to it.
On Fri, Jul 15, 2011 at 4:13 PM, Hervé BOUTEMY herve.bout...@free.fr
wrote:
Le vendredi 15 juillet 2011, John Casey a écrit :
On 7/14/11 6:41 PM, Hervé BOUTEMY wrote:
we call it a URL, but it's a String in the
POM [2]
Nothing prevents another way of interpreting
this String: say properties
format?
If we want to transform this String to a DOM
object in the POM, with
specific XML definition for each SCM, I only
see the backward
compatibility as a strong problem
Whatever the format is, maven-scm-api should
provide an API to derivate a
module definition form its parent: AFAIK,
this API doesn't exist, so
there should be a Jira issue for this in
SCM.
Then Maven Core should use it when merging
parent, instead of simply
appending module name [3]: another Jira issue
is needed
Re: SCM info and modules
Mark,
I only see a cycle if the scm modules have to call back into the model
to get the facts they need to answer the question the model is asking.
If the model can load all of the scm facts for the current project and
its parents into some data structure and pass it into the scm to ask
it to fill in what's missing for the current project, then there's no
cycle.
--benson
On Sat, Jul 16, 2011 at 6:36 PM, Mark Struberg strub...@yahoo.de wrote:
Hi folks!
Just back from vacation so I try to slowly catch up speed ...
There are a few things to take care off:
a.) We must not introduce a circle: model - scm - model. In other words: we
cannot ask the scm provider to give us additional information to build the
model before the model has been built. This is a chicken-egg problem...
b.) Yes, an URL is a coordinate to access the repository. Since GIT (and
other DSCMs) allow different protocols for push and pull, we needed
optionally add 2 path information to the URL.
We could now either opt for a clean solution, but this would most likely not
work with POM model-4.0.
Or we could just add another step of indirection (the classical computer
science pattern): We introduce a SCM-URL-behaviour mapping.
* BehaviourA ('relative') is the one used by e.g. SVN and CVS: automatically
adding the submodule file path to the SCM URL while building the MavenModel.
* BehaviourB ('static') means to let the SCM URL untouched when constructing
the MavenModel.
There must be a mapping somewhere between scm url regexp - SCM-URL-Strategy,
e.g. scm:svn-relative, scm:git-static, scm:jgit-static,...
This could be maintained in settings.xml and we deliver a default one in the
global settings.xml. That way it would be predefined but maintainable by the
user.
LieGrue,
strub
--- On Fri, 7/15/11, Benson Margulies bimargul...@gmail.com wrote:
From: Benson Margulies bimargul...@gmail.com
Subject: Re: SCM info and modules
To: Maven Developers List dev@maven.apache.org
Date: Friday, July 15, 2011, 8:47 PM
Let me suggest a generalization of
Hervé's thought process.
I submit that there are four issues here we might be trying
to
address. (1) users want to put an scm spec in an
aggregating project
and not have to repeat it (with slight mods) in all the
modules. (2)
users want to be able to toss a set of
aggregation-unrelated projects
into a single git repo, or some other SCM where there is a
very sharp
distinction between the coordinates of the repo and the
coordinates of
something in the repo (unlike svn), and (3), SCMs like P4
(with the
problem of managing views) where there are complex aspects
of the
situation that don't fit nicely into a URI. (4)
representing the
distinction between 'here's how to obtain *this very
module* versus
*here's now to obtain the smallest unit that you can expect
to type
'mvn at'.
If we are looking to 3.1, I think that all of these would
be addressed
best by making the scm element of the POM more
complex, by treating
it as a bag of properties, consisting of:
1: An SCM plugin identifier.
2: whatever the SCM would like to know to identify the
sensible unit
of checkin / checkout (we need a term for this. In Git it's
a repo,
for svn it's just a path).
3: A path within this unit for this project.
4: other, per-scm, parameters.
Before 3.1, we can, of course, cram all this into one URI.
The issue
is how to separate stuff that is viable for the scm itself
from our
other information. Using a # inside 'the url' is unsafe, I
submit,
since some scm or another could really use a fragment for
something.
How about:
scm2:new-maven-params:provider-tag:current-provider-params
No one is forced to switch to scm2. If they want the
features it
enables, they have to eschew tools that don't support it.
One thing still seems insufficient about this to me.
Whether a project
requires an aggregation environment to build is not,
really, just an
scm question. Right now, nothing inside a project states
whether it is
really independent (published parent) or not. In the case
of complex
parent structures, there is no simple scheme that does the
job. Item 3
above sort of solves the problem. but does not distinguish
between
'this is an independent project at relative path x within a
lump of
stuff you get from the scm' and 'this is only buildable as
a module of
some other aggregating project.'
Do we really need to solve that? If so, we could add one
more fact:
the g:a of the parent from which a build makes sense. Maven
could then
chase up the parent tree to it.
On Fri, Jul 15, 2011 at 4:13 PM, Hervé BOUTEMY herve.bout...@free.fr
wrote:
Le vendredi 15 juillet 2011, John Casey a écrit :
On 7/14/11 6:41 PM, Hervé BOUTEMY wrote:
we call it a URL, but it's a String in the
POM [2]
Nothing prevents another way of interpreting
this String: say properties
format?
If we want to transform this String to a DOM
Re: SCM info and modules
The Model gets constructed and only if that step is finished, all the
information to determine the correct scm provider GAV is available!
But at this point in time it's too late to modify the SCM url because afaik the
Model cannot get amended, right?
At least that's what I remember from grabbing into this very problem 2 years
ago. That was maven-2 back then, so not sure if things have changed in mvn-3...
LieGrue,
strub
--- On Sat, 7/16/11, Benson Margulies bimargul...@gmail.com wrote:
From: Benson Margulies bimargul...@gmail.com
Subject: Re: SCM info and modules
To: Maven Developers List dev@maven.apache.org
Date: Saturday, July 16, 2011, 11:08 PM
Mark,
I only see a cycle if the scm modules have to call back
into the model
to get the facts they need to answer the question the model
is asking.
If the model can load all of the scm facts for the current
project and
its parents into some data structure and pass it into the
scm to ask
it to fill in what's missing for the current project, then
there's no
cycle.
--benson
On Sat, Jul 16, 2011 at 6:36 PM, Mark Struberg strub...@yahoo.de
wrote:
Hi folks!
Just back from vacation so I try to slowly catch up
speed ...
There are a few things to take care off:
a.) We must not introduce a circle: model - scm
- model. In other words: we cannot ask the scm provider
to give us additional information to build the model before
the model has been built. This is a chicken-egg problem...
b.) Yes, an URL is a coordinate to access the
repository. Since GIT (and other DSCMs) allow different
protocols for push and pull, we needed optionally add 2 path
information to the URL.
We could now either opt for a clean solution, but this
would most likely not work with POM model-4.0.
Or we could just add another step of indirection (the
classical computer science pattern): We introduce a
SCM-URL-behaviour mapping.
* BehaviourA ('relative') is the one used by e.g.
SVN and CVS: automatically adding the submodule file path to
the SCM URL while building the MavenModel.
* BehaviourB ('static') means to let the SCM URL
untouched when constructing the MavenModel.
There must be a mapping somewhere between scm url
regexp - SCM-URL-Strategy, e.g. scm:svn-relative,
scm:git-static, scm:jgit-static,...
This could be maintained in settings.xml and we
deliver a default one in the global settings.xml. That way
it would be predefined but maintainable by the user.
LieGrue,
strub
--- On Fri, 7/15/11, Benson Margulies bimargul...@gmail.com
wrote:
From: Benson Margulies bimargul...@gmail.com
Subject: Re: SCM info and modules
To: Maven Developers List dev@maven.apache.org
Date: Friday, July 15, 2011, 8:47 PM
Let me suggest a generalization of
Hervé's thought process.
I submit that there are four issues here we might
be trying
to
address. (1) users want to put an scm spec in an
aggregating project
and not have to repeat it (with slight mods) in
all the
modules. (2)
users want to be able to toss a set of
aggregation-unrelated projects
into a single git repo, or some other SCM where
there is a
very sharp
distinction between the coordinates of the repo
and the
coordinates of
something in the repo (unlike svn), and (3), SCMs
like P4
(with the
problem of managing views) where there are complex
aspects
of the
situation that don't fit nicely into a URI. (4)
representing the
distinction between 'here's how to obtain *this
very
module* versus
*here's now to obtain the smallest unit that you
can expect
to type
'mvn at'.
If we are looking to 3.1, I think that all of
these would
be addressed
best by making the scm element of the POM
more
complex, by treating
it as a bag of properties, consisting of:
1: An SCM plugin identifier.
2: whatever the SCM would like to know to identify
the
sensible unit
of checkin / checkout (we need a term for this. In
Git it's
a repo,
for svn it's just a path).
3: A path within this unit for this project.
4: other, per-scm, parameters.
Before 3.1, we can, of course, cram all this into
one URI.
The issue
is how to separate stuff that is viable for the
scm itself
from our
other information. Using a # inside 'the url' is
unsafe, I
submit,
since some scm or another could really use a
fragment for
something.
How about:
scm2:new-maven-params:provider-tag:current-provider-params
No one is forced to switch to scm2. If they want
the
features it
enables, they have to eschew tools that don't
support it.
One thing still seems insufficient about this to
me.
Whether a project
requires an aggregation environment to build is
not,
really, just an
scm question. Right now, nothing inside a project
states
whether it is
really independent (published parent) or not. In
the case
of complex
parent structures, there is no simple scheme that
does the
Re: SCM info and modules
Mark,
Oh, drat, I see, to pick a provider, we have to have finished
processing extensions and all that other good model-building stuff.
OK, another thought.
As per a previous comment in this thread, death to inheritance in scm.
Let children have sparse scm, and make it the job of the scm provider,
at runtime, to assemble all the information (including correct 'url')
by working up the models of the parents.
--benson
On Sat, Jul 16, 2011 at 7:25 PM, Mark Struberg strub...@yahoo.de wrote:
The Model gets constructed and only if that step is finished, all the
information to determine the correct scm provider GAV is available!
But at this point in time it's too late to modify the SCM url because afaik
the Model cannot get amended, right?
At least that's what I remember from grabbing into this very problem 2 years
ago. That was maven-2 back then, so not sure if things have changed in
mvn-3...
LieGrue,
strub
--- On Sat, 7/16/11, Benson Margulies bimargul...@gmail.com wrote:
From: Benson Margulies bimargul...@gmail.com
Subject: Re: SCM info and modules
To: Maven Developers List dev@maven.apache.org
Date: Saturday, July 16, 2011, 11:08 PM
Mark,
I only see a cycle if the scm modules have to call back
into the model
to get the facts they need to answer the question the model
is asking.
If the model can load all of the scm facts for the current
project and
its parents into some data structure and pass it into the
scm to ask
it to fill in what's missing for the current project, then
there's no
cycle.
--benson
On Sat, Jul 16, 2011 at 6:36 PM, Mark Struberg strub...@yahoo.de
wrote:
Hi folks!
Just back from vacation so I try to slowly catch up
speed ...
There are a few things to take care off:
a.) We must not introduce a circle: model - scm
- model. In other words: we cannot ask the scm provider
to give us additional information to build the model before
the model has been built. This is a chicken-egg problem...
b.) Yes, an URL is a coordinate to access the
repository. Since GIT (and other DSCMs) allow different
protocols for push and pull, we needed optionally add 2 path
information to the URL.
We could now either opt for a clean solution, but this
would most likely not work with POM model-4.0.
Or we could just add another step of indirection (the
classical computer science pattern): We introduce a
SCM-URL-behaviour mapping.
* BehaviourA ('relative') is the one used by e.g.
SVN and CVS: automatically adding the submodule file path to
the SCM URL while building the MavenModel.
* BehaviourB ('static') means to let the SCM URL
untouched when constructing the MavenModel.
There must be a mapping somewhere between scm url
regexp - SCM-URL-Strategy, e.g. scm:svn-relative,
scm:git-static, scm:jgit-static,...
This could be maintained in settings.xml and we
deliver a default one in the global settings.xml. That way
it would be predefined but maintainable by the user.
LieGrue,
strub
--- On Fri, 7/15/11, Benson Margulies bimargul...@gmail.com
wrote:
From: Benson Margulies bimargul...@gmail.com
Subject: Re: SCM info and modules
To: Maven Developers List dev@maven.apache.org
Date: Friday, July 15, 2011, 8:47 PM
Let me suggest a generalization of
Hervé's thought process.
I submit that there are four issues here we might
be trying
to
address. (1) users want to put an scm spec in an
aggregating project
and not have to repeat it (with slight mods) in
all the
modules. (2)
users want to be able to toss a set of
aggregation-unrelated projects
into a single git repo, or some other SCM where
there is a
very sharp
distinction between the coordinates of the repo
and the
coordinates of
something in the repo (unlike svn), and (3), SCMs
like P4
(with the
problem of managing views) where there are complex
aspects
of the
situation that don't fit nicely into a URI. (4)
representing the
distinction between 'here's how to obtain *this
very
module* versus
*here's now to obtain the smallest unit that you
can expect
to type
'mvn at'.
If we are looking to 3.1, I think that all of
these would
be addressed
best by making the scm element of the POM
more
complex, by treating
it as a bag of properties, consisting of:
1: An SCM plugin identifier.
2: whatever the SCM would like to know to identify
the
sensible unit
of checkin / checkout (we need a term for this. In
Git it's
a repo,
for svn it's just a path).
3: A path within this unit for this project.
4: other, per-scm, parameters.
Before 3.1, we can, of course, cram all this into
one URI.
The issue
is how to separate stuff that is viable for the
scm itself
from our
other information. Using a # inside 'the url' is
unsafe, I
submit,
since some scm or another could really use a
fragment for
something.
How about:
Re: SCM info and modules
Let children have sparse scm, and make it the job of the
scm provider, at runtime ...
Thought about that too. That would work for maven-scm, but there are lots of
other plugins and extensions which access the URL information too. For example
the site-reporting plugin uses it to report the SCM information.
maven-changelog-plugin, etc.
I think it could be possible, but would need some work...
Anyone got a show-stopper for this approach?
Too late for me to think about it over here, will ping back tomorrow morning.
LieGrue,
strub
--- On Sat, 7/16/11, Benson Margulies bimargul...@gmail.com wrote:
From: Benson Margulies bimargul...@gmail.com
Subject: Re: SCM info and modules
To: Maven Developers List dev@maven.apache.org
Date: Saturday, July 16, 2011, 11:31 PM
Mark,
Oh, drat, I see, to pick a provider, we have to have
finished
processing extensions and all that other good
model-building stuff.
OK, another thought.
As per a previous comment in this thread, death to
inheritance in scm.
Let children have sparse scm, and make it the job of the
scm provider,
at runtime, to assemble all the information (including
correct 'url')
by working up the models of the parents.
--benson
On Sat, Jul 16, 2011 at 7:25 PM, Mark Struberg strub...@yahoo.de
wrote:
The Model gets constructed and only if that step is
finished, all the information to determine the correct scm
provider GAV is available!
But at this point in time it's too late to modify the
SCM url because afaik the Model cannot get amended, right?
At least that's what I remember from grabbing into
this very problem 2 years ago. That was maven-2 back then,
so not sure if things have changed in mvn-3...
LieGrue,
strub
--- On Sat, 7/16/11, Benson Margulies bimargul...@gmail.com
wrote:
From: Benson Margulies bimargul...@gmail.com
Subject: Re: SCM info and modules
To: Maven Developers List dev@maven.apache.org
Date: Saturday, July 16, 2011, 11:08 PM
Mark,
I only see a cycle if the scm modules have to call
back
into the model
to get the facts they need to answer the question
the model
is asking.
If the model can load all of the scm facts for the
current
project and
its parents into some data structure and pass it
into the
scm to ask
it to fill in what's missing for the current
project, then
there's no
cycle.
--benson
On Sat, Jul 16, 2011 at 6:36 PM, Mark Struberg
strub...@yahoo.de
wrote:
Hi folks!
Just back from vacation so I try to slowly
catch up
speed ...
There are a few things to take care off:
a.) We must not introduce a circle: model
- scm
- model. In other words: we cannot ask the scm
provider
to give us additional information to build the
model before
the model has been built. This is a chicken-egg
problem...
b.) Yes, an URL is a coordinate to access
the
repository. Since GIT (and other DSCMs) allow
different
protocols for push and pull, we needed optionally
add 2 path
information to the URL.
We could now either opt for a clean solution,
but this
would most likely not work with POM model-4.0.
Or we could just add another step of
indirection (the
classical computer science pattern): We introduce
a
SCM-URL-behaviour mapping.
* BehaviourA ('relative') is the one used
by e.g.
SVN and CVS: automatically adding the submodule
file path to
the SCM URL while building the MavenModel.
* BehaviourB ('static') means to let the
SCM URL
untouched when constructing the MavenModel.
There must be a mapping somewhere between scm
url
regexp - SCM-URL-Strategy, e.g.
scm:svn-relative,
scm:git-static, scm:jgit-static,...
This could be maintained in settings.xml and
we
deliver a default one in the global settings.xml.
That way
it would be predefined but maintainable by the
user.
LieGrue,
strub
--- On Fri, 7/15/11, Benson Margulies bimargul...@gmail.com
wrote:
From: Benson Margulies bimargul...@gmail.com
Subject: Re: SCM info and modules
To: Maven Developers List dev@maven.apache.org
Date: Friday, July 15, 2011, 8:47 PM
Let me suggest a generalization of
Hervé's thought process.
I submit that there are four issues here
we might
be trying
to
address. (1) users want to put an scm
spec in an
aggregating project
and not have to repeat it (with slight
mods) in
all the
modules. (2)
users want to be able to toss a set of
aggregation-unrelated projects
into a single git repo, or some other SCM
where
there is a
very sharp
distinction between the coordinates of
the repo
and the
coordinates of
something in the repo (unlike svn), and
(3), SCMs
like P4
(with the
problem of managing views) where there
are complex
aspects
of the
situation that don't fit nicely into a
URI. (4)
representing the
distinction between 'here's how to obtain
*this
very
