Re: Multi-project releases
Cool, thanks :) -Deng On Wed, Mar 13, 2013 at 3:38 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > I thought I had included the link... But it does not seem there now... > Strange > > https://github.com/stephenc/mpr-maven-plugin > > On Wednesday, 13 March 2013, Deng Ching-Mallete wrote: > > > Hi Stephen, > > > > Where can I get/checkout the plugin? We have a project with the same > > structure so I'd like to try it out. > > > > Thanks, > > Deng > > > > On Mon, Mar 11, 2013 at 7:50 PM, Stephen Connolly < > > stephen.alan.conno...@gmail.com > wrote: > > > > > Hey one and all, > > > > > > So we all know how multiple projects with multiple release roots are a > > > pain... > > > > > > Here's some experiments I've been playing with... > > > > > > Not yet brave enough to have it fire up release:prepare release:perform > > on > > > each release root, nor fire up versions:set on the downstream projects > > with > > > explicit dependencies, nor lather rinse repeat until there is nothing > > > needing a release... > > > > > > But even the simple report should be useful, and if anyone has > > suggestions > > > to help improve its recommendations towards getting confidence that the > > > automated stuff could work... please give me pull requests. > > > > > > If this proves useful, I will probably roll it into the release > plugin... > > > but for now I'll keep it in a holding pattern on github (where it is > not > > in > > > a default plugin groupId and hence relocation is less of an issue if I > do > > > happen to make any releases into central) > > > > > > $ mvn com.github.stephenc.maven:mpr-maven-plugin:list-roots > > > > > > from an aggregator pom should identify all the release roots and > whether > > > they might need a release > > > > > > -Stephen > > > > > > > > > > > -- > > Maria Odea "Deng" Ching-Mallete | och...@apache.org | > > http://www.linkedin.com/in/oching > > > > > -- > Sent from my phone > -- Maria Odea "Deng" Ching-Mallete | och...@apache.org | http://www.linkedin.com/in/oching
[ANN] Maven Dependency Plugin 2.7 Released
The Apache Maven team is pleased to announce the release of the Maven Dependency Plugin, version 2.7 The dependency plugin provides the capability to manipulate artifacts. It can copy and/or unpack artifacts from local or remote repositories to a specified location. http://maven.apache.org/plugins/maven-dependency-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-dependency-plugin 2.7 Release Notes - Maven 2.x Dependency Plugin - Version 2.7 ** Bug * [MDEP-391] - Unpack fails on linux with large archives * [MDEP-399] - Multi-module dependencies incorrectly marked as unused * [MDEP-401] - Support include/exclude of artifactId/groupId in resolve-plugins * [MDEP-402] - Allow resolve-plugins to exclude plugins in the current reactor ** Improvement * [MDEP-301] - Allow build-classpath to output to property * [MDEP-396] - Add support to use the baseVersion of an artifact instead of version for the destFileName * [MDEP-403] - add a "skip" configuration option to the dependency plugin Enjoy, -The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: git commit: Use Eclipse/Sisu 0.0.0.M2 milestone
master branch really ? 2013/3/13 : > Updated Branches: > refs/heads/master 41a292d9a -> 2c2bf6e6e > > > Use Eclipse/Sisu 0.0.0.M2 milestone > > Signed-off-by: Jason van Zyl > > > Project: http://git-wip-us.apache.org/repos/asf/maven/repo > Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/2c2bf6e6 > Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/2c2bf6e6 > Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/2c2bf6e6 > > Branch: refs/heads/master > Commit: 2c2bf6e6e5b06c35a935ca69c5dcb54b381baf46 > Parents: 41a292d > Author: Stuart McCulloch > Authored: Wed Mar 13 01:11:34 2013 + > Committer: Jason van Zyl > Committed: Wed Mar 13 08:49:00 2013 -0400 > > -- > apache-maven/pom.xml |4 +- > maven-aether-provider/pom.xml |4 +- > maven-compat/pom.xml |4 +- > maven-core/pom.xml |4 +- > .../apache/maven/DefaultArtifactFilterManager.java |1 + > .../maven/classrealm/DefaultClassRealmManager.java |5 +- > maven-embedder/pom.xml |4 +- > maven-model-builder/pom.xml|4 +- > maven-plugin-api/pom.xml |4 +- > pom.xml| 34 +++ > 10 files changed, 42 insertions(+), 26 deletions(-) > -- > > > http://git-wip-us.apache.org/repos/asf/maven/blob/2c2bf6e6/apache-maven/pom.xml > -- > diff --git a/apache-maven/pom.xml b/apache-maven/pom.xml > index ce547e7..9794928 100644 > --- a/apache-maven/pom.xml > +++ b/apache-maven/pom.xml > @@ -48,8 +48,8 @@ >maven-compat > > > - org.sonatype.sisu > - sisu-inject-plexus > + org.eclipse.sisu > + org.eclipse.sisu.plexus > > > > > http://git-wip-us.apache.org/repos/asf/maven/blob/2c2bf6e6/maven-aether-provider/pom.xml > -- > diff --git a/maven-aether-provider/pom.xml b/maven-aether-provider/pom.xml > index 6c61177..f6985d9 100644 > --- a/maven-aether-provider/pom.xml > +++ b/maven-aether-provider/pom.xml > @@ -76,8 +76,8 @@ under the License. >test > > > - org.sonatype.sisu > - sisu-inject-plexus > + org.eclipse.sisu > + org.eclipse.sisu.plexus > > >org.codehaus.plexus > > http://git-wip-us.apache.org/repos/asf/maven/blob/2c2bf6e6/maven-compat/pom.xml > -- > diff --git a/maven-compat/pom.xml b/maven-compat/pom.xml > index 3bdb1aa..e098fad 100644 > --- a/maven-compat/pom.xml > +++ b/maven-compat/pom.xml > @@ -54,8 +54,8 @@ >plexus-interpolation > > > - org.sonatype.sisu > - sisu-inject-plexus > + org.eclipse.sisu > + org.eclipse.sisu.plexus > > >org.codehaus.plexus > > http://git-wip-us.apache.org/repos/asf/maven/blob/2c2bf6e6/maven-core/pom.xml > -- > diff --git a/maven-core/pom.xml b/maven-core/pom.xml > index dcc2699..7dbde4a 100644 > --- a/maven-core/pom.xml > +++ b/maven-core/pom.xml > @@ -72,8 +72,8 @@ > > > > - org.sonatype.sisu > - sisu-inject-plexus > + org.eclipse.sisu > + org.eclipse.sisu.plexus > > >org.codehaus.plexus > > http://git-wip-us.apache.org/repos/asf/maven/blob/2c2bf6e6/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java > -- > diff --git > a/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java > b/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java > index 9d772f7..7676834 100644 > --- > a/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java > +++ > b/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java > @@ -58,6 +58,7 @@ public class DefaultArtifactFilterManager > artifacts.add( "plexus:plexus-container-default" ); > artifacts.add( "org.sonatype.spice:spice-inject-plexus" ); > artifacts.add( "org.sonatype.sisu:sisu-inject-plexus" ); > +artifacts.add( "org.eclipse.sisu:org.eclipse.sisu.plexus" ); > artifacts.add( "org.apache.maven:maven-artifact" ); > artifacts.add( "org.apache.maven:maven-aether-provider" ); > artifacts.add( "org.apache.maven:maven-artifact-manager" ); > > http://git-wip-us.apache.org/repos/asf/maven/blob/2c2bf6e6/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java >
[ANN] Maven Dependency Analyzer 1.4 Released
The Apache Maven team is pleased to announce the release of the Maven Dependency Analyzer, version 1.4 As the name implies, the Maven dependency analyzer analyzes the dependencies of a project for undeclared or unused artifacts. http://maven.apache.org/shared/maven-dependency-analyzer/ Release Notes - Maven Shared Components - Version maven-dependency-analyzer-1.4 ** Bug * [MSHARED-276] - analyzer ignores project directories in a multi-module build Enjoy, -The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
maven pull request: Use Eclipse/Sisu 0.0.0.M2 milestone
Github user mcculls closed the pull request at: https://github.com/apache/maven/pull/2 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven Shared Incremental 1.1 and Apache Maven Compiler Plugin 3.1
+1 (non-binding). Just built our main-project without any issue. Cheers 2013/3/6 Olivier Lamy > Hi, > > Apache Maven Shared Incremental 1.1 > We fixed 1 issue: > > http://jira.codehaus.org/secure/ReleaseNote.jspa?version=19002&styleName=Text&projectId=11761&Create=Create > > Staging repository: > https://repository.apache.org/content/repositories/maven-334/ > > Staging site: > http://maven.apache.org/shared-archives/maven-shared-incremental-1.1/ > > Apache Maven Compiler Plugin 3.1 > We fixed 8 issues: > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11130&version=18973 > > Staging repository: > https://repository.apache.org/content/repositories/maven-334/ > > Staging site: > http://maven.apache.org/plugins-archives/maven-compiler-plugin-3.1/ > > Vote open for 72H > > [+1] > [0] > [-1] > > Thanks! > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- > Baptiste MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! nbsp;!
Re: The next major release of Maven: 4.0.0
I apologize for muddling svnpubsub and the cmd On Mar 13, 2013, at 12:19 PM, Jason van Zyl wrote: > > On Mar 13, 2013, at 12:09 PM, Daniel Kulp wrote: > >> >> On Mar 13, 2013, at 9:18 AM, Jason van Zyl wrote: >> >>> Sadly it was forced upon us it seems. And I don't believe it's a rant to >>> comment on a tool that is hard to use and detracts from productivity >>> especially given how much other work there is to do. It's hard to use tools >>> like this home grown CMS, given the prevalence of great tools like Github >>> pages where you don't even have to think about it. It's amazing that to >>> this day at Apache projects are given little choice over the tools they use. >>> >>> The model at Eclipse is more reasonable where there is infrastructure >>> provided and if you want to leverage that you are free to do so. But you >>> have webspace and want to use something different then you can because >>> ultimately it is the project that is responsible for their website. I think >>> it's great that base services are offered but I don't think it's great to >>> force people to use a tool that no one else in the world uses. I believe it >>> adds zero value to the project, it's only made creating documentation more >>> painful, we've really had tons of problems with syncing and 4/5th of the >>> commit logs are now related to the website. It's unfortunate, much like the >>> situation where we had to wait years to use Git. The infrastructure here is >>> dictated in many cases which is not an optimal model IMO. >> >> Umm…. No one in Apache is forcing the CMS on anyone. > > Just quoting Benson about the choice issue. I don't ever remember any > discussion it just seemed to start happening and I remember mention of a CMS. > >> The only requirement is that your website must be stored in subversion >> someplace. It can be in your projects main svn tree someplace or infra has >> setup a separate repo that can be used. This really is no "different" than >> a directory someplace other than it's backed by an SCM.How the project >> populates that SVN space is completely up to the project.The CMS is just >> one way of accomplishing that.Confluence + the exporter tool + buildbot >> is one.Directly editing .html files with emacs is another. A maven >> build from buildbot is another.That's completely up to the project to >> decide. > > Do you like the Confluence setup? That seems the easiest of solutions where > you edit a page and the site is updated eventually. > >> >> Dan >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder & CTO, Sonatype > 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: The next major release of Maven: 4.0.0
On Mar 13, 2013, at 12:09 PM, Daniel Kulp wrote: > > On Mar 13, 2013, at 9:18 AM, Jason van Zyl wrote: > >> Sadly it was forced upon us it seems. And I don't believe it's a rant to >> comment on a tool that is hard to use and detracts from productivity >> especially given how much other work there is to do. It's hard to use tools >> like this home grown CMS, given the prevalence of great tools like Github >> pages where you don't even have to think about it. It's amazing that to this >> day at Apache projects are given little choice over the tools they use. >> >> The model at Eclipse is more reasonable where there is infrastructure >> provided and if you want to leverage that you are free to do so. But you >> have webspace and want to use something different then you can because >> ultimately it is the project that is responsible for their website. I think >> it's great that base services are offered but I don't think it's great to >> force people to use a tool that no one else in the world uses. I believe it >> adds zero value to the project, it's only made creating documentation more >> painful, we've really had tons of problems with syncing and 4/5th of the >> commit logs are now related to the website. It's unfortunate, much like the >> situation where we had to wait years to use Git. The infrastructure here is >> dictated in many cases which is not an optimal model IMO. > > Umm…. No one in Apache is forcing the CMS on anyone. Just quoting Benson about the choice issue. I don't ever remember any discussion it just seemed to start happening and I remember mention of a CMS. > The only requirement is that your website must be stored in subversion > someplace. It can be in your projects main svn tree someplace or infra has > setup a separate repo that can be used. This really is no "different" than a > directory someplace other than it's backed by an SCM.How the project > populates that SVN space is completely up to the project.The CMS is just > one way of accomplishing that.Confluence + the exporter tool + buildbot > is one.Directly editing .html files with emacs is another. A maven > build from buildbot is another.That's completely up to the project to > decide. Do you like the Confluence setup? That seems the easiest of solutions where you edit a page and the site is updated eventually. > > Dan > Thanks, Jason -- Jason van Zyl Founder & CTO, Sonatype 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: The next major release of Maven: 4.0.0
On Mar 13, 2013, at 9:18 AM, Jason van Zyl wrote: > Sadly it was forced upon us it seems. And I don't believe it's a rant to > comment on a tool that is hard to use and detracts from productivity > especially given how much other work there is to do. It's hard to use tools > like this home grown CMS, given the prevalence of great tools like Github > pages where you don't even have to think about it. It's amazing that to this > day at Apache projects are given little choice over the tools they use. > > The model at Eclipse is more reasonable where there is infrastructure > provided and if you want to leverage that you are free to do so. But you have > webspace and want to use something different then you can because ultimately > it is the project that is responsible for their website. I think it's great > that base services are offered but I don't think it's great to force people > to use a tool that no one else in the world uses. I believe it adds zero > value to the project, it's only made creating documentation more painful, > we've really had tons of problems with syncing and 4/5th of the commit logs > are now related to the website. It's unfortunate, much like the situation > where we had to wait years to use Git. The infrastructure here is dictated in > many cases which is not an optimal model IMO. Umm…. No one in Apache is forcing the CMS on anyone. The only requirement is that your website must be stored in subversion someplace. It can be in your projects main svn tree someplace or infra has setup a separate repo that can be used. This really is no "different" than a directory someplace other than it's backed by an SCM.How the project populates that SVN space is completely up to the project.The CMS is just one way of accomplishing that.Confluence + the exporter tool + buildbot is one.Directly editing .html files with emacs is another. A maven build from buildbot is another.That's completely up to the project to decide. Dan > It would be like me forcing everyone at Apache to build with Maven because > that's what I understand. Isn't building your software just as, or more, > important than publishing your website? Yet we don't force everyone to build > with Maven, we let each project decide based on their preferences and needs. > It should be the same for any tool a project decides to use. > > On Mar 13, 2013, at 8:50 AM, Benson Margulies wrote: > >> On Wed, Mar 13, 2013 at 8:47 AM, Ansgar Konermann < >> ansgar.konerm...@googlemail.com> wrote: >> >>> Am 13.03.2013 08:38 schrieb "herve.bout...@free.fr" >>> : If you write documentation in Maven core (the components), not in Maven >>> site (the global project), you'll be happy with git like you do with >>> sources I can then take care of svnpubsub publication, or anybody else since I >>> already prepared it (notice ranting against svnpubsub is just a waste of time and karma) >>> >>> What is the value of svnpubsub? Why is it so valuable compared to >>> alternatives? Which alternatives are could you (all) imagine? >>> >> >> >> We don't have an alternative at Apache, so it's not worth chewing over, and >> this is not the list to re-produce infra@'s reasons >> >> >>> >>> I'm clueless. >>> >>> Best >>> >>> Ansgar Envoyé depuis mon mobile - Reply message - De : "Jason van Zyl" Pour : "Maven Developers List" Objet : The next major release of Maven: 4.0.0 Date : mar., mars 12, 2013 16:29 I would like if someone would volunteer to do the documentation part of >>> the release. This will probably be the 3rd time I've merged Eclipse Aether >>> into Maven and there are a lot of moving parts that need to be tested and >>> frankly it's starting to burn me out. I don't have time or interest in >>> using the Subversion-based documentation system so I'd like someone else to >>> do that. Do we really have no choice in how we publish our site? Checking >>> stuff into SVN for documentation seems arcane and ridiculous. I don't mind >>> doing the technical work, I would like someone else to pickup the >>> documentation work for the release. Can someone help with that? On Mar 11, 2013, at 10:33 AM, Jason van Zyl wrote: > Any other comments? > > Unless I hear otherwise this week I'll start merging Eclipse Aether >>> into master and start a discussion about what that means. > > On Mar 10, 2013, at 1:20 AM, Anders Hammar wrote: > >> Personally I would like us to stick with the initial discussion of >>> shipping >> 3.1 with the slf4j usage (and slf4j-simple). That's what we've >>> discussed >> and talked about for some time so it would be great to get that out of >>> the >> door. The we could discuss the next step. Basically, and generally, >>> I'd >> like us to stick to the plans we discuss. >> >> At the same time I fully appreciate t
Re: The next major release of Maven: 4.0.0
On Mar 13, 2013, at 9:40 AM, Jason van Zyl wrote: > So what do you normally use for documentation? Or what would you prefer? > > Of anything I've seen here the Confluence --> static website looked the most > promising. As soon as you saved a page it attempted to make the update to the > static website. I don't know if that's still in use but was being used by > some projects at some point. Several projects still use Confluence -> static website, but it's a bit more complicated now with svnpubsub in there. We have buildbot builds that run once an hour to "export" the confluence space to static HTML and check it into SVN where svnpubsub then takes over. CXF, Camel, ActiveMQ, Geronimo, etc… are using it. See: http://www.dankulp.com/blog/2012/03/svnpubsub-for-confluence-sites/ Dan > > On Mar 13, 2013, at 9:37 AM, Kristian Rosenvold > wrote: > >> As long as one definitely and 100% stays away from the EU mirror it >> would seem to work. Running through the mirror is route to disaster >> and *lots* of wasted time. >> >> It would appear that the equivalent git-based solution for site >> publication is not ready yet. So for this moment someone will have to >> do the pom changes to make core use svnsubpub. >> >> There is little to like about svnsubpub. There was little to like >> about the previous solutions used for maven sites either. Nor do I >> like github pages. It all makes me feel a little depressed. >> >> Kristian >> >> - >> 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 & CTO, Sonatype > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > I never make the mistake of arguing with people for whose opinions I have no > respect. > > -- Edward Gibbon > > > > > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[Result] [Vote #2] maven-dependency-plugin 2.7 AND maven-dependency-analyzer 1.4
This vote passed with the following: +1 (binding): Brian Fox, John Casey, Paul Gier +1 (non-binding): Henning Schmiedehausen I'll promote the artifacts and website, send the announcement, and tidy up the rest. Thanks, -john On 3/7/13 1:48 PM, John Casey wrote: Hi, This vote is for the Maven dependency plugin version 2.7, which also requires the release of Maven shared dependency analyzer version 1.4. The first vote failed due to MDEP-391. Since I had previously staged both of these together, I had to redeploy the same tag for the maven-dependency-analyzer to a new staging repo, then deploy the new code for the maven-dependency-plugin to another staging repo. The new repos are listed below. maven-dependency-plugin 2.7: We solved 7 issues: http://s.apache.org/cmZc The new issue from the first vote is MDEP-391. There are still issues left in JIRA: http://s.apache.org/N6u maven-dependency-analyzer 1.4: -- We solved 1 issue: http://s.apache.org/48k There is still 1 issue left in JIRA: http://s.apache.org/ZCc --- Staging repos: https://repository.apache.org/content/repositories/maven-339/ https://repository.apache.org/content/repositories/maven-340/ * maven-dependency-analyzer is under maven-339 * maven-dependency-plugin is under maven-340 Source releases: http://s.apache.org/mda-1.4-src.zip (maven-dependency-analyzer 1.4) http://s.apache.org/mdep-2.7-src.zip (maven-dependency-plugin 2.7) Staging site: http://maven.apache.org/shared-archives/maven-dependency-analyzer-1.4/ http://maven.apache.org/plugins-archives/maven-dependency-plugin-2.7/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Here's my +1. -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) GitHub - http://github.com/jdcasey - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Vote #2] maven-dependency-plugin 2.7 AND maven-dependency-analyzer 1.4
+1 On Mon, Mar 11, 2013 at 1:04 PM, Henning Schmiedehausen < henn...@schmiedehausen.org> wrote: > +1 to release. > > Thanks, > Henning > > > > > On Mon, Mar 11, 2013 at 9:44 AM, John Casey > wrote: > > > Bump... > > > > Has this vote failed, then, or are we saying that all the +1's from the > > previous round of voting should be counted here? There is new code in > this > > vote, so I'm not 100% sure that's a good idea. > > > > I can complete the release of the dependency analyzer, I guess, as that > > code has not changed. > > > > On 3/7/13 1:48 PM, John Casey wrote: > > > >> Hi, > >> > >> This vote is for the Maven dependency plugin version 2.7, which also > >> requires the release of Maven shared dependency analyzer version 1.4. > >> > >> The first vote failed due to MDEP-391. Since I had previously staged > >> both of these together, I had to redeploy the same tag for the > >> maven-dependency-analyzer to a new staging repo, then deploy the new > >> code for the maven-dependency-plugin to another staging repo. The new > >> repos are listed below. > >> > >> maven-dependency-plugin 2.7: > >> > >> > >> We solved 7 issues: http://s.apache.org/cmZc > >> > >> The new issue from the first vote is MDEP-391. > >> > >> There are still issues left in JIRA: http://s.apache.org/N6u > >> > >> > >> maven-dependency-analyzer 1.4: > >> -- > >> > >> We solved 1 issue: http://s.apache.org/48k > >> > >> There is still 1 issue left in JIRA: http://s.apache.org/ZCc > >> > >> --- > >> > >> Staging repos: > >> > >> https://repository.apache.org/**content/repositories/maven-**339/< > https://repository.apache.org/content/repositories/maven-339/> > >> https://repository.apache.org/**content/repositories/maven-**340/< > https://repository.apache.org/content/repositories/maven-340/> > >> > >> * maven-dependency-analyzer is under maven-339 > >> * maven-dependency-plugin is under maven-340 > >> > >> > >> Source releases: > >> > >> http://s.apache.org/mda-1.4-**src.zip< > http://s.apache.org/mda-1.4-src.zip> (maven-dependency-analyzer 1.4) > >> http://s.apache.org/mdep-2.7-**src.zip< > http://s.apache.org/mdep-2.7-src.zip>(maven-dependency-plugin 2.7) > >> > >> > >> Staging site: > >> > >> http://maven.apache.org/**shared-archives/maven-** > >> dependency-analyzer-1.4/< > http://maven.apache.org/shared-archives/maven-dependency-analyzer-1.4/> > >> > http://maven.apache.org/**plugins-archives/maven-**dependency-plugin-2.7/< > http://maven.apache.org/plugins-archives/maven-dependency-plugin-2.7/> > >> > >> Guide to testing staged releases: > >> > >> http://maven.apache.org/**guides/development/guide-** > >> testing-releases.html< > http://maven.apache.org/guides/development/guide-testing-releases.html> > >> > >> Vote open for 72 hours. > >> > >> [ ] +1 > >> [ ] +0 > >> [ ] -1 > >> > >> > >> Here's my +1. > >> > >> -john > >> > >> > > > > -- > > John Casey > > Developer, PMC Member - Apache Maven (http://maven.apache.org) > > GitHub - http://github.com/jdcasey > > > > --**--**- > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org< > dev-unsubscr...@maven.apache.org> > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
Re: [Vote #2] maven-dependency-plugin 2.7 AND maven-dependency-analyzer 1.4
+1 it looks ok to me. On 03/11/2013 11:44 AM, John Casey wrote: > Bump... > > Has this vote failed, then, or are we saying that all the +1's from the > previous round of voting should be counted here? There is new code in > this vote, so I'm not 100% sure that's a good idea. > > I can complete the release of the dependency analyzer, I guess, as that > code has not changed. > > On 3/7/13 1:48 PM, John Casey wrote: >> Hi, >> >> This vote is for the Maven dependency plugin version 2.7, which also >> requires the release of Maven shared dependency analyzer version 1.4. >> >> The first vote failed due to MDEP-391. Since I had previously staged >> both of these together, I had to redeploy the same tag for the >> maven-dependency-analyzer to a new staging repo, then deploy the new >> code for the maven-dependency-plugin to another staging repo. The new >> repos are listed below. >> >> maven-dependency-plugin 2.7: >> >> >> We solved 7 issues: http://s.apache.org/cmZc >> >> The new issue from the first vote is MDEP-391. >> >> There are still issues left in JIRA: http://s.apache.org/N6u >> >> >> maven-dependency-analyzer 1.4: >> -- >> >> We solved 1 issue: http://s.apache.org/48k >> >> There is still 1 issue left in JIRA: http://s.apache.org/ZCc >> >> --- >> >> Staging repos: >> >> https://repository.apache.org/content/repositories/maven-339/ >> https://repository.apache.org/content/repositories/maven-340/ >> >> * maven-dependency-analyzer is under maven-339 >> * maven-dependency-plugin is under maven-340 >> >> >> Source releases: >> >> http://s.apache.org/mda-1.4-src.zip (maven-dependency-analyzer 1.4) >> http://s.apache.org/mdep-2.7-src.zip (maven-dependency-plugin 2.7) >> >> >> Staging site: >> >> http://maven.apache.org/shared-archives/maven-dependency-analyzer-1.4/ >> http://maven.apache.org/plugins-archives/maven-dependency-plugin-2.7/ >> >> Guide to testing staged releases: >> >> http://maven.apache.org/guides/development/guide-testing-releases.html >> >> Vote open for 72 hours. >> >> [ ] +1 >> [ ] +0 >> [ ] -1 >> >> >> Here's my +1. >> >> -john >> > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: core-integration-testing-maven-3-jdk-1.7 - Build # 598 - Failure
FYI, the two failing ITs can be fixed by https://github.com/apache/maven-integration-testing/pull/3 with more details available in https://jira.codehaus.org/browse/MNG-5446 On 13 Mar 2013, at 14:39, Apache Jenkins Server wrote: > The Apache Jenkins build system has built > core-integration-testing-maven-3-jdk-1.7 (build #598) > > Status: Failure > > Check console output at > https://builds.apache.org/job/core-integration-testing-maven-3-jdk-1.7/598/ > to view the results. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The next major release of Maven: 4.0.0
So what do you normally use for documentation? Or what would you prefer? Of anything I've seen here the Confluence --> static website looked the most promising. As soon as you saved a page it attempted to make the update to the static website. I don't know if that's still in use but was being used by some projects at some point. On Mar 13, 2013, at 9:37 AM, Kristian Rosenvold wrote: > As long as one definitely and 100% stays away from the EU mirror it > would seem to work. Running through the mirror is route to disaster > and *lots* of wasted time. > > It would appear that the equivalent git-based solution for site > publication is not ready yet. So for this moment someone will have to > do the pom changes to make core use svnsubpub. > > There is little to like about svnsubpub. There was little to like > about the previous solutions used for maven sites either. Nor do I > like github pages. It all makes me feel a little depressed. > > Kristian > > - > 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 & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - I never make the mistake of arguing with people for whose opinions I have no respect. -- Edward Gibbon
Re: The next major release of Maven: 4.0.0
As long as one definitely and 100% stays away from the EU mirror it would seem to work. Running through the mirror is route to disaster and *lots* of wasted time. It would appear that the equivalent git-based solution for site publication is not ready yet. So for this moment someone will have to do the pom changes to make core use svnsubpub. There is little to like about svnsubpub. There was little to like about the previous solutions used for maven sites either. Nor do I like github pages. It all makes me feel a little depressed. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The next major release of Maven: 4.0.0
Ansgar, Sadly it was forced upon us it seems. And I don't believe it's a rant to comment on a tool that is hard to use and detracts from productivity especially given how much other work there is to do. It's hard to use tools like this home grown CMS, given the prevalence of great tools like Github pages where you don't even have to think about it. It's amazing that to this day at Apache projects are given little choice over the tools they use. The model at Eclipse is more reasonable where there is infrastructure provided and if you want to leverage that you are free to do so. But you have webspace and want to use something different then you can because ultimately it is the project that is responsible for their website. I think it's great that base services are offered but I don't think it's great to force people to use a tool that no one else in the world uses. I believe it adds zero value to the project, it's only made creating documentation more painful, we've really had tons of problems with syncing and 4/5th of the commit logs are now related to the website. It's unfortunate, much like the situation where we had to wait years to use Git. The infrastructure here is dictated in many cases which is not an optimal model IMO. It would be like me forcing everyone at Apache to build with Maven because that's what I understand. Isn't building your software just as, or more, important than publishing your website? Yet we don't force everyone to build with Maven, we let each project decide based on their preferences and needs. It should be the same for any tool a project decides to use. On Mar 13, 2013, at 8:50 AM, Benson Margulies wrote: > On Wed, Mar 13, 2013 at 8:47 AM, Ansgar Konermann < > ansgar.konerm...@googlemail.com> wrote: > >> Am 13.03.2013 08:38 schrieb "herve.bout...@free.fr" >> : >>> >>> If you write documentation in Maven core (the components), not in Maven >> site (the global project), you'll be happy with git like you do with >> sources >>> >>> I can then take care of svnpubsub publication, or anybody else since I >> already prepared it >>> (notice ranting against svnpubsub is just a waste of time and karma) >> >> What is the value of svnpubsub? Why is it so valuable compared to >> alternatives? Which alternatives are could you (all) imagine? >> > > > We don't have an alternative at Apache, so it's not worth chewing over, and > this is not the list to re-produce infra@'s reasons > > >> >> I'm clueless. >> >> Best >> >> Ansgar >>> >>> Envoyé depuis mon mobile >>> >>> - Reply message - >>> De : "Jason van Zyl" >>> Pour : "Maven Developers List" >>> Objet : The next major release of Maven: 4.0.0 >>> Date : mar., mars 12, 2013 16:29 >>> >>> >>> I would like if someone would volunteer to do the documentation part of >> the release. This will probably be the 3rd time I've merged Eclipse Aether >> into Maven and there are a lot of moving parts that need to be tested and >> frankly it's starting to burn me out. I don't have time or interest in >> using the Subversion-based documentation system so I'd like someone else to >> do that. Do we really have no choice in how we publish our site? Checking >> stuff into SVN for documentation seems arcane and ridiculous. I don't mind >> doing the technical work, I would like someone else to pickup the >> documentation work for the release. Can someone help with that? >>> >>> On Mar 11, 2013, at 10:33 AM, Jason van Zyl wrote: >>> Any other comments? Unless I hear otherwise this week I'll start merging Eclipse Aether >> into master and start a discussion about what that means. On Mar 10, 2013, at 1:20 AM, Anders Hammar wrote: > Personally I would like us to stick with the initial discussion of >> shipping > 3.1 with the slf4j usage (and slf4j-simple). That's what we've >> discussed > and talked about for some time so it would be great to get that out of >> the > door. The we could discuss the next step. Basically, and generally, >> I'd > like us to stick to the plans we discuss. > > At the same time I fully appreciate that I'm not doing the work. > > > On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen > wrote: > >> Well at least with Maven 4.0 I would not get the question anymore, >> why the >> pom's model version is at 4 while we use Maven 3 ;-). >> >> Regards Mirko >> -- >> Sent from my mobile >> On Mar 9, 2013 12:15 AM, "Brian Fox" wrote: >> >>> I don't think we should move to 4.0 because of this. The primary >> consumer >>> of our systems are the end users and this change doesn't represent >> "api" >>> breakage to them. If we make what appears to be such a large version >>> change, that could scare off or confuse people who are just now >> warming >> up >>> to 3.x. I think this does need to be resolved, but lets just call it >> 3.1 >>> and notify the plugins
Re: Re : The next major release of Maven: 4.0.0
On Wed, Mar 13, 2013 at 8:47 AM, Ansgar Konermann < ansgar.konerm...@googlemail.com> wrote: > Am 13.03.2013 08:38 schrieb "herve.bout...@free.fr" >: > > > > If you write documentation in Maven core (the components), not in Maven > site (the global project), you'll be happy with git like you do with > sources > > > > I can then take care of svnpubsub publication, or anybody else since I > already prepared it > > (notice ranting against svnpubsub is just a waste of time and karma) > > What is the value of svnpubsub? Why is it so valuable compared to > alternatives? Which alternatives are could you (all) imagine? > We don't have an alternative at Apache, so it's not worth chewing over, and this is not the list to re-produce infra@'s reasons > > I'm clueless. > > Best > > Ansgar > > > > Envoyé depuis mon mobile > > > > - Reply message - > > De : "Jason van Zyl" > > Pour : "Maven Developers List" > > Objet : The next major release of Maven: 4.0.0 > > Date : mar., mars 12, 2013 16:29 > > > > > > I would like if someone would volunteer to do the documentation part of > the release. This will probably be the 3rd time I've merged Eclipse Aether > into Maven and there are a lot of moving parts that need to be tested and > frankly it's starting to burn me out. I don't have time or interest in > using the Subversion-based documentation system so I'd like someone else to > do that. Do we really have no choice in how we publish our site? Checking > stuff into SVN for documentation seems arcane and ridiculous. I don't mind > doing the technical work, I would like someone else to pickup the > documentation work for the release. Can someone help with that? > > > > On Mar 11, 2013, at 10:33 AM, Jason van Zyl wrote: > > > > > Any other comments? > > > > > > Unless I hear otherwise this week I'll start merging Eclipse Aether > into master and start a discussion about what that means. > > > > > > On Mar 10, 2013, at 1:20 AM, Anders Hammar wrote: > > > > > >> Personally I would like us to stick with the initial discussion of > shipping > > >> 3.1 with the slf4j usage (and slf4j-simple). That's what we've > discussed > > >> and talked about for some time so it would be great to get that out of > the > > >> door. The we could discuss the next step. Basically, and generally, > I'd > > >> like us to stick to the plans we discuss. > > >> > > >> At the same time I fully appreciate that I'm not doing the work. > > >> > > >> > > >> On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen > > >> wrote: > > >> > > >>> Well at least with Maven 4.0 I would not get the question anymore, > why the > > >>> pom's model version is at 4 while we use Maven 3 ;-). > > >>> > > >>> Regards Mirko > > >>> -- > > >>> Sent from my mobile > > >>> On Mar 9, 2013 12:15 AM, "Brian Fox" wrote: > > >>> > > I don't think we should move to 4.0 because of this. The primary > consumer > > of our systems are the end users and this change doesn't represent > "api" > > breakage to them. If we make what appears to be such a large version > > change, that could scare off or confuse people who are just now > warming > > >>> up > > to 3.x. I think this does need to be resolved, but lets just call it > 3.1 > > and notify the plugins that need to know directly. > > > > > > On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl > wrote: > > > > > > > > On Mar 6, 2013, at 6:09 PM, Olivier Lamy wrote: > > > > > >> 2013/3/4 Hervé BOUTEMY : > > >>> some more personal thoughts and questions to make myself an > opinion > > >>> > > >>> - about determining whether Aether API is biased or not: there > was > > >>> an > > > argument > > >>> for not developing Aether in Maven that was "Aether API will be > more > > > generic > > >>> to cover other dependency resolution mecanisms and repository > > >>> formats, > > > like > > >>> P2". Is there something done on this area (be it P2 or anyhting > else > > > outside > > >>> Maven use)? > > >>> > > >>> - about maintaining a 3.1.0 bugfix branch like the actual one in > > > parallel with > > >>> the master incorporating Eclipse Aether: isn't it the area where > the > > > git move > > >>> was expected to help? The 3.1.0 is just a bugfix branch, without > > >>> much > > > commits > > >>> expected since the work will happen on master (and on every > > > components/plugins > > >>> having an impact from Eclipse Aether integration), or do I miss > > > something? > > >>> I suppose these outside component will require some time to adapt > > >>> and > > > propose > > >>> a solution for users. > > >> > > >> In such case why not using the opportunity of 4.0.0 to back to a > > >> org.apache.maven namespace (with a wrapper on top of the real > > >> implementation). > > > > > > Go for it. As I wrote previously if anyone wants to make a shim or > > > compatibi
Re: Re : The next major release of Maven: 4.0.0
Am 13.03.2013 08:38 schrieb "herve.bout...@free.fr" : > > If you write documentation in Maven core (the components), not in Maven site (the global project), you'll be happy with git like you do with sources > > I can then take care of svnpubsub publication, or anybody else since I already prepared it > (notice ranting against svnpubsub is just a waste of time and karma) What is the value of svnpubsub? Why is it so valuable compared to alternatives? Which alternatives are could you (all) imagine? I'm clueless. Best Ansgar > > Envoyé depuis mon mobile > > - Reply message - > De : "Jason van Zyl" > Pour : "Maven Developers List" > Objet : The next major release of Maven: 4.0.0 > Date : mar., mars 12, 2013 16:29 > > > I would like if someone would volunteer to do the documentation part of the release. This will probably be the 3rd time I've merged Eclipse Aether into Maven and there are a lot of moving parts that need to be tested and frankly it's starting to burn me out. I don't have time or interest in using the Subversion-based documentation system so I'd like someone else to do that. Do we really have no choice in how we publish our site? Checking stuff into SVN for documentation seems arcane and ridiculous. I don't mind doing the technical work, I would like someone else to pickup the documentation work for the release. Can someone help with that? > > On Mar 11, 2013, at 10:33 AM, Jason van Zyl wrote: > > > Any other comments? > > > > Unless I hear otherwise this week I'll start merging Eclipse Aether into master and start a discussion about what that means. > > > > On Mar 10, 2013, at 1:20 AM, Anders Hammar wrote: > > > >> Personally I would like us to stick with the initial discussion of shipping > >> 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed > >> and talked about for some time so it would be great to get that out of the > >> door. The we could discuss the next step. Basically, and generally, I'd > >> like us to stick to the plans we discuss. > >> > >> At the same time I fully appreciate that I'm not doing the work. > >> > >> > >> On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen > >> wrote: > >> > >>> Well at least with Maven 4.0 I would not get the question anymore, why the > >>> pom's model version is at 4 while we use Maven 3 ;-). > >>> > >>> Regards Mirko > >>> -- > >>> Sent from my mobile > >>> On Mar 9, 2013 12:15 AM, "Brian Fox" wrote: > >>> > I don't think we should move to 4.0 because of this. The primary consumer > of our systems are the end users and this change doesn't represent "api" > breakage to them. If we make what appears to be such a large version > change, that could scare off or confuse people who are just now warming > >>> up > to 3.x. I think this does need to be resolved, but lets just call it 3.1 > and notify the plugins that need to know directly. > > > On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl wrote: > > > > > On Mar 6, 2013, at 6:09 PM, Olivier Lamy wrote: > > > >> 2013/3/4 Hervé BOUTEMY : > >>> some more personal thoughts and questions to make myself an opinion > >>> > >>> - about determining whether Aether API is biased or not: there was > >>> an > > argument > >>> for not developing Aether in Maven that was "Aether API will be more > > generic > >>> to cover other dependency resolution mecanisms and repository > >>> formats, > > like > >>> P2". Is there something done on this area (be it P2 or anyhting else > > outside > >>> Maven use)? > >>> > >>> - about maintaining a 3.1.0 bugfix branch like the actual one in > > parallel with > >>> the master incorporating Eclipse Aether: isn't it the area where the > > git move > >>> was expected to help? The 3.1.0 is just a bugfix branch, without > >>> much > > commits > >>> expected since the work will happen on master (and on every > > components/plugins > >>> having an impact from Eclipse Aether integration), or do I miss > > something? > >>> I suppose these outside component will require some time to adapt > >>> and > > propose > >>> a solution for users. > >> > >> In such case why not using the opportunity of 4.0.0 to back to a > >> org.apache.maven namespace (with a wrapper on top of the real > >> implementation). > > > > Go for it. As I wrote previously if anyone wants to make a shim or > > compatibility layer over Eclipse Aether they are welcome too. I'm not > doing > > for all the reasons I cited previously, but feel free to take the > > opportunity. > > > >> At least that will be a more stable namespace. (If did as it since > >>> the > >> beginning we could think about something else now !) > >> > >>> > >>> > >>> Regards, > >>> > >>> Hervé > >>> > >>> Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit : > Step
Re: The next major release of Maven: 4.0.0
On Mar 13, 2013, at 3:30 AM, herve.bout...@free.fr wrote: > I'm on vacation, with weak mobile connexion... > I'll try m-dependency-tree when back home > Id You updates m-dependency-p to latest -tree, the hope was it would work > without more efforts > It may be something small, but it appears to be an issue at the moment. > Envoyé depuis mon mobile > > - Reply message - > De : "Jason van Zyl" > Pour : "Maven Developers List" > Objet : The next major release of Maven: 4.0.0 > Date : mer., mars 13, 2013 08:00 > > > I will push the Eclipse Aether work to a branch as there are several ITs that > fail that are related to using real plugins in the ITs which are affected by > the changes. The dependency plugins and site plugin are the ones that are > visible right now. The shade plugin also doesn't work. > > The ITs should probably not be using real plugins, but we can decide what to > do once the branch is in. > > Hervé, just a note that I quickly tried the dependency tree with the > dependency plugin with Eclipse Aether wired in and it still seems to be > breaking. I have a build if you want to try it to see the error messages. I > assume what's on master is intended to work with both versions of Aether? > > On Mar 12, 2013, at 11:29 AM, Jason van Zyl wrote: > >> I would like if someone would volunteer to do the documentation part of the >> release. This will probably be the 3rd time I've merged Eclipse Aether into >> Maven and there are a lot of moving parts that need to be tested and frankly >> it's starting to burn me out. I don't have time or interest in using the >> Subversion-based documentation system so I'd like someone else to do that. >> Do we really have no choice in how we publish our site? Checking stuff into >> SVN for documentation seems arcane and ridiculous. I don't mind doing the >> technical work, I would like someone else to pickup the documentation work >> for the release. Can someone help with that? >> >> On Mar 11, 2013, at 10:33 AM, Jason van Zyl wrote: >> >>> Any other comments? >>> >>> Unless I hear otherwise this week I'll start merging Eclipse Aether into >>> master and start a discussion about what that means. >>> >>> On Mar 10, 2013, at 1:20 AM, Anders Hammar wrote: >>> Personally I would like us to stick with the initial discussion of shipping 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed and talked about for some time so it would be great to get that out of the door. The we could discuss the next step. Basically, and generally, I'd like us to stick to the plans we discuss. At the same time I fully appreciate that I'm not doing the work. On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen wrote: > Well at least with Maven 4.0 I would not get the question anymore, why the > pom's model version is at 4 while we use Maven 3 ;-). > > Regards Mirko > -- > Sent from my mobile > On Mar 9, 2013 12:15 AM, "Brian Fox" wrote: > >> I don't think we should move to 4.0 because of this. The primary consumer >> of our systems are the end users and this change doesn't represent "api" >> breakage to them. If we make what appears to be such a large version >> change, that could scare off or confuse people who are just now warming > up >> to 3.x. I think this does need to be resolved, but lets just call it 3.1 >> and notify the plugins that need to know directly. >> >> >> On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl wrote: >> >>> >>> On Mar 6, 2013, at 6:09 PM, Olivier Lamy wrote: >>> 2013/3/4 Hervé BOUTEMY : > some more personal thoughts and questions to make myself an opinion > > - about determining whether Aether API is biased or not: there was > an >>> argument > for not developing Aether in Maven that was "Aether API will be more >>> generic > to cover other dependency resolution mecanisms and repository > formats, >>> like > P2". Is there something done on this area (be it P2 or anyhting else >>> outside > Maven use)? > > - about maintaining a 3.1.0 bugfix branch like the actual one in >>> parallel with > the master incorporating Eclipse Aether: isn't it the area where the >>> git move > was expected to help? The 3.1.0 is just a bugfix branch, without > much >>> commits > expected since the work will happen on master (and on every >>> components/plugins > having an impact from Eclipse Aether integration), or do I miss >>> something? > I suppose these outside component will require some time to adapt > and >>> propose > a solution for users. In such case why not using the opportunity of 4.0.0 to back to a org.apache.maven namespace (with a wrapper on to
Re: Multi-project releases
I thought I had included the link... But it does not seem there now... Strange https://github.com/stephenc/mpr-maven-plugin On Wednesday, 13 March 2013, Deng Ching-Mallete wrote: > Hi Stephen, > > Where can I get/checkout the plugin? We have a project with the same > structure so I'd like to try it out. > > Thanks, > Deng > > On Mon, Mar 11, 2013 at 7:50 PM, Stephen Connolly < > stephen.alan.conno...@gmail.com > wrote: > > > Hey one and all, > > > > So we all know how multiple projects with multiple release roots are a > > pain... > > > > Here's some experiments I've been playing with... > > > > Not yet brave enough to have it fire up release:prepare release:perform > on > > each release root, nor fire up versions:set on the downstream projects > with > > explicit dependencies, nor lather rinse repeat until there is nothing > > needing a release... > > > > But even the simple report should be useful, and if anyone has > suggestions > > to help improve its recommendations towards getting confidence that the > > automated stuff could work... please give me pull requests. > > > > If this proves useful, I will probably roll it into the release plugin... > > but for now I'll keep it in a holding pattern on github (where it is not > in > > a default plugin groupId and hence relocation is less of an issue if I do > > happen to make any releases into central) > > > > $ mvn com.github.stephenc.maven:mpr-maven-plugin:list-roots > > > > from an aggregator pom should identify all the release roots and whether > > they might need a release > > > > -Stephen > > > > > > -- > Maria Odea "Deng" Ching-Mallete | och...@apache.org | > http://www.linkedin.com/in/oching > -- Sent from my phone
Re : The next major release of Maven: 4.0.0
If you write documentation in Maven core (the components), not in Maven site (the global project), you'll be happy with git like you do with sources I can then take care of svnpubsub publication, or anybody else since I already prepared it (notice ranting against svnpubsub is just a waste of time and karma) Envoyé depuis mon mobile - Reply message - De : "Jason van Zyl" Pour : "Maven Developers List" Objet : The next major release of Maven: 4.0.0 Date : mar., mars 12, 2013 16:29 I would like if someone would volunteer to do the documentation part of the release. This will probably be the 3rd time I've merged Eclipse Aether into Maven and there are a lot of moving parts that need to be tested and frankly it's starting to burn me out. I don't have time or interest in using the Subversion-based documentation system so I'd like someone else to do that. Do we really have no choice in how we publish our site? Checking stuff into SVN for documentation seems arcane and ridiculous. I don't mind doing the technical work, I would like someone else to pickup the documentation work for the release. Can someone help with that? On Mar 11, 2013, at 10:33 AM, Jason van Zyl wrote: > Any other comments? > > Unless I hear otherwise this week I'll start merging Eclipse Aether into > master and start a discussion about what that means. > > On Mar 10, 2013, at 1:20 AM, Anders Hammar wrote: > >> Personally I would like us to stick with the initial discussion of shipping >> 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed >> and talked about for some time so it would be great to get that out of the >> door. The we could discuss the next step. Basically, and generally, I'd >> like us to stick to the plans we discuss. >> >> At the same time I fully appreciate that I'm not doing the work. >> >> >> On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen >> wrote: >> >>> Well at least with Maven 4.0 I would not get the question anymore, why the >>> pom's model version is at 4 while we use Maven 3 ;-). >>> >>> Regards Mirko >>> -- >>> Sent from my mobile >>> On Mar 9, 2013 12:15 AM, "Brian Fox" wrote: >>> I don't think we should move to 4.0 because of this. The primary consumer of our systems are the end users and this change doesn't represent "api" breakage to them. If we make what appears to be such a large version change, that could scare off or confuse people who are just now warming >>> up to 3.x. I think this does need to be resolved, but lets just call it 3.1 and notify the plugins that need to know directly. On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl wrote: > > On Mar 6, 2013, at 6:09 PM, Olivier Lamy wrote: > >> 2013/3/4 Hervé BOUTEMY : >>> some more personal thoughts and questions to make myself an opinion >>> >>> - about determining whether Aether API is biased or not: there was >>> an > argument >>> for not developing Aether in Maven that was "Aether API will be more > generic >>> to cover other dependency resolution mecanisms and repository >>> formats, > like >>> P2". Is there something done on this area (be it P2 or anyhting else > outside >>> Maven use)? >>> >>> - about maintaining a 3.1.0 bugfix branch like the actual one in > parallel with >>> the master incorporating Eclipse Aether: isn't it the area where the > git move >>> was expected to help? The 3.1.0 is just a bugfix branch, without >>> much > commits >>> expected since the work will happen on master (and on every > components/plugins >>> having an impact from Eclipse Aether integration), or do I miss > something? >>> I suppose these outside component will require some time to adapt >>> and > propose >>> a solution for users. >> >> In such case why not using the opportunity of 4.0.0 to back to a >> org.apache.maven namespace (with a wrapper on top of the real >> implementation). > > Go for it. As I wrote previously if anyone wants to make a shim or > compatibility layer over Eclipse Aether they are welcome too. I'm not doing > for all the reasons I cited previously, but feel free to take the > opportunity. > >> At least that will be a more stable namespace. (If did as it since >>> the >> beginning we could think about something else now !) >> >>> >>> >>> Regards, >>> >>> Hervé >>> >>> Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit : Stephen, It doesn't matter where the code is. It's complicated, takes a lot >>> of > effort to understand and I don't really care, or see it as a problem that > Benjamin is the one who works on it most. No one else worked on here, no one > else is working on it there. It's not where it is, it's that it's a non-trivial body
Re : The next major release of Maven: 4.0.0
I'm on vacation, with weak mobile connexion... I'll try m-dependency-tree when back home Id You updates m-dependency-p to latest -tree, the hope was it would work without more efforts Envoyé depuis mon mobile - Reply message - De : "Jason van Zyl" Pour : "Maven Developers List" Objet : The next major release of Maven: 4.0.0 Date : mer., mars 13, 2013 08:00 I will push the Eclipse Aether work to a branch as there are several ITs that fail that are related to using real plugins in the ITs which are affected by the changes. The dependency plugins and site plugin are the ones that are visible right now. The shade plugin also doesn't work. The ITs should probably not be using real plugins, but we can decide what to do once the branch is in. Hervé, just a note that I quickly tried the dependency tree with the dependency plugin with Eclipse Aether wired in and it still seems to be breaking. I have a build if you want to try it to see the error messages. I assume what's on master is intended to work with both versions of Aether? On Mar 12, 2013, at 11:29 AM, Jason van Zyl wrote: > I would like if someone would volunteer to do the documentation part of the > release. This will probably be the 3rd time I've merged Eclipse Aether into > Maven and there are a lot of moving parts that need to be tested and frankly > it's starting to burn me out. I don't have time or interest in using the > Subversion-based documentation system so I'd like someone else to do that. Do > we really have no choice in how we publish our site? Checking stuff into SVN > for documentation seems arcane and ridiculous. I don't mind doing the > technical work, I would like someone else to pickup the documentation work > for the release. Can someone help with that? > > On Mar 11, 2013, at 10:33 AM, Jason van Zyl wrote: > >> Any other comments? >> >> Unless I hear otherwise this week I'll start merging Eclipse Aether into >> master and start a discussion about what that means. >> >> On Mar 10, 2013, at 1:20 AM, Anders Hammar wrote: >> >>> Personally I would like us to stick with the initial discussion of shipping >>> 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed >>> and talked about for some time so it would be great to get that out of the >>> door. The we could discuss the next step. Basically, and generally, I'd >>> like us to stick to the plans we discuss. >>> >>> At the same time I fully appreciate that I'm not doing the work. >>> >>> >>> On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen >>> wrote: >>> Well at least with Maven 4.0 I would not get the question anymore, why the pom's model version is at 4 while we use Maven 3 ;-). Regards Mirko -- Sent from my mobile On Mar 9, 2013 12:15 AM, "Brian Fox" wrote: > I don't think we should move to 4.0 because of this. The primary consumer > of our systems are the end users and this change doesn't represent "api" > breakage to them. If we make what appears to be such a large version > change, that could scare off or confuse people who are just now warming up > to 3.x. I think this does need to be resolved, but lets just call it 3.1 > and notify the plugins that need to know directly. > > > On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl wrote: > >> >> On Mar 6, 2013, at 6:09 PM, Olivier Lamy wrote: >> >>> 2013/3/4 Hervé BOUTEMY : some more personal thoughts and questions to make myself an opinion - about determining whether Aether API is biased or not: there was an >> argument for not developing Aether in Maven that was "Aether API will be more >> generic to cover other dependency resolution mecanisms and repository formats, >> like P2". Is there something done on this area (be it P2 or anyhting else >> outside Maven use)? - about maintaining a 3.1.0 bugfix branch like the actual one in >> parallel with the master incorporating Eclipse Aether: isn't it the area where the >> git move was expected to help? The 3.1.0 is just a bugfix branch, without much >> commits expected since the work will happen on master (and on every >> components/plugins having an impact from Eclipse Aether integration), or do I miss >> something? I suppose these outside component will require some time to adapt and >> propose a solution for users. >>> >>> In such case why not using the opportunity of 4.0.0 to back to a >>> org.apache.maven namespace (with a wrapper on top of the real >>> implementation). >> >> Go for it. As I wrote previously if anyone wants to make a shim or >> compatibility layer over Eclipse Aether they are welcome too. I'm not > doing >> for all the reasons I cited previously, but feel free to take
Re: The next major release of Maven: 4.0.0
I will push the Eclipse Aether work to a branch as there are several ITs that fail that are related to using real plugins in the ITs which are affected by the changes. The dependency plugins and site plugin are the ones that are visible right now. The shade plugin also doesn't work. The ITs should probably not be using real plugins, but we can decide what to do once the branch is in. Hervé, just a note that I quickly tried the dependency tree with the dependency plugin with Eclipse Aether wired in and it still seems to be breaking. I have a build if you want to try it to see the error messages. I assume what's on master is intended to work with both versions of Aether? On Mar 12, 2013, at 11:29 AM, Jason van Zyl wrote: > I would like if someone would volunteer to do the documentation part of the > release. This will probably be the 3rd time I've merged Eclipse Aether into > Maven and there are a lot of moving parts that need to be tested and frankly > it's starting to burn me out. I don't have time or interest in using the > Subversion-based documentation system so I'd like someone else to do that. Do > we really have no choice in how we publish our site? Checking stuff into SVN > for documentation seems arcane and ridiculous. I don't mind doing the > technical work, I would like someone else to pickup the documentation work > for the release. Can someone help with that? > > On Mar 11, 2013, at 10:33 AM, Jason van Zyl wrote: > >> Any other comments? >> >> Unless I hear otherwise this week I'll start merging Eclipse Aether into >> master and start a discussion about what that means. >> >> On Mar 10, 2013, at 1:20 AM, Anders Hammar wrote: >> >>> Personally I would like us to stick with the initial discussion of shipping >>> 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed >>> and talked about for some time so it would be great to get that out of the >>> door. The we could discuss the next step. Basically, and generally, I'd >>> like us to stick to the plans we discuss. >>> >>> At the same time I fully appreciate that I'm not doing the work. >>> >>> >>> On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen >>> wrote: >>> Well at least with Maven 4.0 I would not get the question anymore, why the pom's model version is at 4 while we use Maven 3 ;-). Regards Mirko -- Sent from my mobile On Mar 9, 2013 12:15 AM, "Brian Fox" wrote: > I don't think we should move to 4.0 because of this. The primary consumer > of our systems are the end users and this change doesn't represent "api" > breakage to them. If we make what appears to be such a large version > change, that could scare off or confuse people who are just now warming up > to 3.x. I think this does need to be resolved, but lets just call it 3.1 > and notify the plugins that need to know directly. > > > On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl wrote: > >> >> On Mar 6, 2013, at 6:09 PM, Olivier Lamy wrote: >> >>> 2013/3/4 Hervé BOUTEMY : some more personal thoughts and questions to make myself an opinion - about determining whether Aether API is biased or not: there was an >> argument for not developing Aether in Maven that was "Aether API will be more >> generic to cover other dependency resolution mecanisms and repository formats, >> like P2". Is there something done on this area (be it P2 or anyhting else >> outside Maven use)? - about maintaining a 3.1.0 bugfix branch like the actual one in >> parallel with the master incorporating Eclipse Aether: isn't it the area where the >> git move was expected to help? The 3.1.0 is just a bugfix branch, without much >> commits expected since the work will happen on master (and on every >> components/plugins having an impact from Eclipse Aether integration), or do I miss >> something? I suppose these outside component will require some time to adapt and >> propose a solution for users. >>> >>> In such case why not using the opportunity of 4.0.0 to back to a >>> org.apache.maven namespace (with a wrapper on top of the real >>> implementation). >> >> Go for it. As I wrote previously if anyone wants to make a shim or >> compatibility layer over Eclipse Aether they are welcome too. I'm not > doing >> for all the reasons I cited previously, but feel free to take the >> opportunity. >> >>> At least that will be a more stable namespace. (If did as it since the >>> beginning we could think about something else now !) >>> Regards, Hervé Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit : > Stephen, > > It doesn
