Re: Good JarDiff/Clirr Setup
On 08/09/2007, at 10:52 AM, Jason van Zyl wrote: I want to take the aggregate uber jar in 2.0.x and start comparing it with with the uber jar for 2.1.x. Anyone have a preference for JarDiff or Clirr and have a good setup for it? I've been happy with clirr when I've used it, and the check and report are pretty easy to set up. I've used it in maven-core before using this: http://mojo.codehaus.org/clirr-maven-plugin/examples/ specific-version.html It might need an enhancement to be able to deal with the uber jar since, IIRC, that's an attached artifact instead of the primary one. I would like to set this up to catch anything. +1 Cheers, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using HTTP repositories for consumption only
On 7 Sep 07, at 5:43 PM 7 Sep 07, Brett Porter wrote: On 08/09/2007, at 10:37 AM, Jason van Zyl wrote: On 7 Sep 07, at 5:16 PM 7 Sep 07, Brett Porter wrote: file:// ? I also know of some wagon-scm + SVN uses (though they could download over HTTP). Right, deployment is a different story. I use the wagon-scm stuff for audit trail and deploy there. I'm talking strictly about pulling. But if anyone is using something other than svn for the scm backend they might not have the same option. I'd be hesitant to remove this without doing some decent polling of users (and probably a deprecation cycle). Yah, this is just based on comments from Greg and people I've asked since that discussion. I have seen questions on the user list regarding pulling from things other then non-http but I can barely remember any of them. And anyone I've asked doesn't even know we support anything else other then http/https. Sorry, could you point me at that discussion? I'm drawing a blank. Need to buy more RAM for my brain :) http://www.nabble.com/http:--jira.codehaus.org-browse-MNG-3151- t4306084s177.html - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Good JarDiff/Clirr Setup
I want to take the aggregate uber jar in 2.0.x and start comparing it with with the uber jar for 2.1.x. Anyone have a preference for JarDiff or Clirr and have a good setup for it? I would like to set this up to catch anything. I can be rather radical in refactoring but I think that's fine provided test, ITs, and binary compatibility are maintained. Anyone should be able to make improvements (which is all I'm doing at this point) without fear. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using HTTP repositories for consumption only
On 7 Sep 07, at 5:20 PM 7 Sep 07, Brian E. Fox wrote: I don't currently, but have in the past used file:// for remote. For deploying or actually pulling? Deploying is a totally different story. I know tons of people who use file, dav, scp, and ftp. Strictly for pulling I'm saying. And I'm not saying it will satisfy our users, just throwing out the idea. But HTTP is pretty much ubiquitous, handles all security concerns, easily distributed ... The use case was that we had to mirror our internal repo to another corp network. We essentially zipped up the repo and transferred it to their machine (regularly and automatically via scm), which set a mirror entry pointing to the local fs. This had to be done this way because a proxied connection to our internal repo was not allowed, they needed full copies of the entire build in scm. I think these tools could could probably be special tools using Wagon, or something else like an rsync tool would be ideal. I agree though that file:// is pretty useful. Just looking to make the mechanism as streamlined, simple, and consistent as possible. Does Ivy or OSGi repositories support anything other then HTTP? -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, September 07, 2007 6:55 PM To: Maven Developers List Subject: Using HTTP repositories for consumption only After thinking about Greg's comments I think it would be interesting to ask people who actually uses anything but HTTP repositories for consumption? Deployment is a totally different story, but to radically simplify the core what if we only allowed HTTP repositories for consumption in 2.1? Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using HTTP repositories for consumption only
On 08/09/2007, at 10:37 AM, Jason van Zyl wrote: On 7 Sep 07, at 5:16 PM 7 Sep 07, Brett Porter wrote: file:// ? I also know of some wagon-scm + SVN uses (though they could download over HTTP). Right, deployment is a different story. I use the wagon-scm stuff for audit trail and deploy there. I'm talking strictly about pulling. But if anyone is using something other than svn for the scm backend they might not have the same option. I'd be hesitant to remove this without doing some decent polling of users (and probably a deprecation cycle). Yah, this is just based on comments from Greg and people I've asked since that discussion. I have seen questions on the user list regarding pulling from things other then non-http but I can barely remember any of them. And anyone I've asked doesn't even know we support anything else other then http/https. Sorry, could you point me at that discussion? I'm drawing a blank. Need to buy more RAM for my brain :) - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using HTTP repositories for consumption only
On 7 Sep 07, at 5:16 PM 7 Sep 07, Brett Porter wrote: file:// ? I also know of some wagon-scm + SVN uses (though they could download over HTTP). Right, deployment is a different story. I use the wagon-scm stuff for audit trail and deploy there. I'm talking strictly about pulling. I'd be hesitant to remove this without doing some decent polling of users (and probably a deprecation cycle). Yah, this is just based on comments from Greg and people I've asked since that discussion. I have seen questions on the user list regarding pulling from things other then non-http but I can barely remember any of them. And anyone I've asked doesn't even know we support anything else other then http/https. - Brett On 08/09/2007, at 8:55 AM, Jason van Zyl wrote: After thinking about Greg's comments I think it would be interesting to ask people who actually uses anything but HTTP repositories for consumption? Deployment is a totally different story, but to radically simplify the core what if we only allowed HTTP repositories for consumption in 2.1? Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1 refactoring and plugins
On 7 Sep 07, at 5:03 PM 7 Sep 07, Brett Porter wrote: On 08/09/2007, at 12:24 AM, Jason van Zyl wrote: On 7 Sep 07, at 2:19 AM 7 Sep 07, Brett Porter wrote: Just curious - will there be any issues with these APIs changing for plugins that may have come to rely on it, or are these all purely internal? (I haven't had a chance to dig through the changes yet). We must absolutely guarantee that all 2.0.x plugins work out of the box without change. I've made no plugin api changes and we won't until the proposals are vetted. If I understand your comment correctly, I think what I was referring to was more along the lines of this: http:// svn.apache.org/viewvc?view=rev&revision=573718 "put the profile manager back into place as the project build is exposed in a ton of plugin. arrrg." I think there are quite a few plugins using maven-settings, maven- project, etc directly. I will absolutely guarantee that the plugins that have been written will run. They have to. Cheers, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using HTTP repositories for consumption only
I think it's also a reasonable goal to allow people to use projects that refer to embedded remote repositories to build...that way, the build is totally self-contained. This is one of the things that the assembly plugin tries to do with its section (though it doesn't work very well so far...but that's just a matter of time). IMO, file:// is a nice thing to have, unless we have some way of allowing the above to work without the file wagon being in core (maybe I'm not thinking about it the right way). -john On Sep 7, 2007, at 8:20 PM, Brian E. Fox wrote: I don't currently, but have in the past used file:// for remote. The use case was that we had to mirror our internal repo to another corp network. We essentially zipped up the repo and transferred it to their machine (regularly and automatically via scm), which set a mirror entry pointing to the local fs. This had to be done this way because a proxied connection to our internal repo was not allowed, they needed full copies of the entire build in scm. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, September 07, 2007 6:55 PM To: Maven Developers List Subject: Using HTTP repositories for consumption only After thinking about Greg's comments I think it would be interesting to ask people who actually uses anything but HTTP repositories for consumption? Deployment is a totally different story, but to radically simplify the core what if we only allowed HTTP repositories for consumption in 2.1? Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john
RE: Using HTTP repositories for consumption only
I don't currently, but have in the past used file:// for remote. The use case was that we had to mirror our internal repo to another corp network. We essentially zipped up the repo and transferred it to their machine (regularly and automatically via scm), which set a mirror entry pointing to the local fs. This had to be done this way because a proxied connection to our internal repo was not allowed, they needed full copies of the entire build in scm. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, September 07, 2007 6:55 PM To: Maven Developers List Subject: Using HTTP repositories for consumption only After thinking about Greg's comments I think it would be interesting to ask people who actually uses anything but HTTP repositories for consumption? Deployment is a totally different story, but to radically simplify the core what if we only allowed HTTP repositories for consumption in 2.1? Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using HTTP repositories for consumption only
file:// ? I also know of some wagon-scm + SVN uses (though they could download over HTTP). I'd be hesitant to remove this without doing some decent polling of users (and probably a deprecation cycle). - Brett On 08/09/2007, at 8:55 AM, Jason van Zyl wrote: After thinking about Greg's comments I think it would be interesting to ask people who actually uses anything but HTTP repositories for consumption? Deployment is a totally different story, but to radically simplify the core what if we only allowed HTTP repositories for consumption in 2.1? Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why not more releases of maven plugins ?
Also, I'm not prepared to release 2.3.1 until the things that have regressed since previous releases are fixed. I keep working on it when I have spare time - others are welcome and we just got a new volunteer last week... On 08/09/2007, at 2:06 AM, Carlos Sanchez wrote: the changelog is easy to see in jira ie http://jira.codehaus.org/browse/SUREFIRE? report=com.atlassian.jira.plugin.system.project:roadmap-panel it's not a problem of tracking the changes but to say out loud "hey, release the plugin!" On 9/7/07, nicolas de loof <[EMAIL PROTECTED]> wrote: If you have ideas on how we can do this better, we're all ears. I've noticed from the hudson way (but maybe this is the wrong way) that they put a release when 2 or 3 bugs have been fixed. As maven provides SNAPSHOT support this seems not required to release a plugin to allow users to get the fix. But this as the side effect that project that want to release must have all dependencies and plugins also released.. And many user prefer to have a reproductible build. IMHO, commiters do great work fixing issues and testing patches, but they should go a little more deeper with suggesting releases. A simple rule like "when more than N issues have been fixes OR there has been no release from X latest weeks, prepare a new release after fixing an issue". Surefire for example has 96 issues in Jira, so I understand this makes huge work for commiters. But there is allready 2 issues marked as CLOSED, one from april 07, latest from july. I can't think nobody worked on surefire during 5 month ! IMHO a 2.4 (maybe 2.3.1 ?) release should be a good way to make many users happy : the ones that reported this issue, and the ones that will fall into same situation and may duplicate the ticket. Why not use the project wiki to create a dashboard for fixed issues, so that a new release requirement could be more visible ? I didn't found a simple way to get Jira report a list of "closed issue since latest release". Just my 2 cents... -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependencies in maven-jar-plugin
If it works with 2.0.7, I think that's ok. On 07/09/2007, at 8:59 PM, Johan Kindgren wrote: Hi I've fixed the mjar-30 and possibly the mjar-80 (by accident), and while I was at it I created a couple of integrationtests using the maven-embedder. I could not get the embedder to run without upgrading the some dependencies (like maven-core and the maven-artifact), do you have any general policy for witch versions to use? Snapshot? Currently I'm using 2.0.7. I found out that the patch I submitted has some faults (wrong formatting in some files, complete file-paths, missing licence-header). I'll try to fix this during the weekend. /Johan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1 refactoring and plugins
urg, sorry. I see you already started a separate thread on this. Please ignore me. On 08/09/2007, at 10:03 AM, Brett Porter wrote: On 08/09/2007, at 12:24 AM, Jason van Zyl wrote: On 7 Sep 07, at 2:19 AM 7 Sep 07, Brett Porter wrote: Just curious - will there be any issues with these APIs changing for plugins that may have come to rely on it, or are these all purely internal? (I haven't had a chance to dig through the changes yet). We must absolutely guarantee that all 2.0.x plugins work out of the box without change. I've made no plugin api changes and we won't until the proposals are vetted. If I understand your comment correctly, I think what I was referring to was more along the lines of this: http:// svn.apache.org/viewvc?view=rev&revision=573718 "put the profile manager back into place as the project build is exposed in a ton of plugin. arrrg." I think there are quite a few plugins using maven-settings, maven- project, etc directly. Cheers, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1 refactoring and plugins
On 08/09/2007, at 12:24 AM, Jason van Zyl wrote: On 7 Sep 07, at 2:19 AM 7 Sep 07, Brett Porter wrote: Just curious - will there be any issues with these APIs changing for plugins that may have come to rely on it, or are these all purely internal? (I haven't had a chance to dig through the changes yet). We must absolutely guarantee that all 2.0.x plugins work out of the box without change. I've made no plugin api changes and we won't until the proposals are vetted. If I understand your comment correctly, I think what I was referring to was more along the lines of this: http://svn.apache.org/viewvc? view=rev&revision=573718 "put the profile manager back into place as the project build is exposed in a ton of plugin. arrrg." I think there are quite a few plugins using maven-settings, maven- project, etc directly. Cheers, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [continuum] BUILD FAILURE: Maven Embedder
On 08/09/2007, at 12:25 AM, Jason van Zyl wrote: On 7 Sep 07, at 2:19 AM 7 Sep 07, Brett Porter wrote: I guess you're out for the night now... anyway, until we get the direct nag happening I'll just pass it on :) I just checked again, no changes for me locally, bootstrapped again and ran the ITs and it's all fine so we have a discrepancy. Continuum, my machine, and John all had the same problem. You fixed it in: http://svn.apache.org/viewvc/maven/components/trunk/ maven-embedder/src/main/java/org/apache/maven/embedder/execution/ DefaultMavenExecutionRequestPopulator.java? r1=573494&r2=573718&pathrev=573718&diff_format=h Bootstraps again here now. You might need to check what's going on in your environment, and why your Hudson install also didn't notice (I guess if that's installed on your machine it might be using the same repository). Thanks, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Working on 2.1 over the weekend
If anyone else is going to be working on 2.1 over the weekend then I will work on a branch, otherwise I will continue tracking down the release plugin problem, starting the error reporting based on feedback of what can go wrong, and documenting the front-end populating of the execution request. I am also building up a set of tests so that a version of Maven can be run against a known set of plugins so that we can deliver on the promise to have 2.0.x plugins work in 2.1. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] Mauro Talevi committer access
Results: +12 Brian, Stephane, Emmanuel, Vincent, Fabrice, Maria, Raphael, Lukas, Olivier, Jason vZ, Arnaud, Brett This vote has passed. Jason, since Mauro is already an Apache committer, I believe only granting of Karma is required. Please join me in welcoming Mauro! --Brian -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 04, 2007 9:35 PM To: Maven Developers List Subject: [vote] Mauro Talevi committer access Mauro is an existing Apache Committer on the Excalibur project (http://excalibur.apache.org/team-list.html) as well as the mojo project at Codehaus. He has recently been working on the shade plugin currently up for vote to be moved to Apache. As he has demonstrated ability and we can use the help maintaining shade and Maven in general, I'd like to call a vote to add Mauro as a Maven Committer. Vote will be open for 72 hrs. Adopted Project Conventions for new Committer votes: "The vote duration should be specified in the mail, but must be a minimum of 72 hours (it may be made longer if there is a weekend or holiday in the middle). Votes on committers should be accepted from all committers on the project. There is no minimum number of votes needed for a vote to pass. The vote is decided by the majority (simply add all the +1's and -1's). Candidates can not be vetoed. Votes can be changed any time while the vote is still open and will supercede the previous vote by an individual. The vote should then be tallied, and if it has passed, the process for adding a new committer is followed." +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] bring shade-maven-plugin to apache
Results:
+7 (Binding) Brian, Jason, Brett, Stephane, Lukas, Dennis, Arnaud
+2 (Non Binding) Rafale, Andy,
This vote has passed. I will wrap up the move most likely over the
weekend. It will first go to the sandbox where we will perform the
refactoring of packages and to include apache headers.
Since I'm also a mojo committer, I'll call a vote over there to decide
what happens with the source in mojo.
-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 02, 2007 10:37 PM
To: Maven Developers List
Subject: [vote] bring shade-maven-plugin to apache
The shade-maven-plugin is currently in the codehaus mojo sandbox. This
plugin is used by maven core to package the uberjar for distribution and
should be moved to the maven project.
Please vote {+1,0,-1], vote is open for 72 hrs.
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1 execution of plugins
On 7 Sep 07, at 3:46 PM 7 Sep 07, John Casey wrote: Hell, I'd settle for being able to bootstrap at all. It's really not cool to respond that CI is broken and not respond at all to someone saying the build breaks on their machine I have 4 machines going, I'm not trying to intentionally break the build the for people. The last one was a problem. I did a normal build, not a bootstrap, and some old binaries got pulled down and made a distribution with things that worked previously. And I honestly walked away while stuff was running on the other machines. I am not trying to waste people's time, I'm trying to make comprehensible and explainable which is the goal of my current work and haven't even attempted to add any new features. All I'm doing is grunt work. ...without even taking more time trying to replicate their results. This has put a HUGE crimp in my own plans for today, I can tell you. -john On Sep 7, 2007, at 4:33 PM, Jason van Zyl wrote: I started testing many of our standard plugins and we have more then a few problems. So don't be alarmed if you bootstrap and try to run things like the release plugin, or the site plugin because they won't work. I'm making a compatibility layer and tracking down problems this weekend to stabilize in an attempt for a release soon. Not looking like next week is going to be feasible given these problems and doxia and m-a are not released yet. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The importance of working in branches
I thought we'd all agreed to use branches as a measure for preserving stability in the trunk as much as was reasonable. This was awhile back, but I'm sure I can find that thread if I need to. FWIW, major refactorings are no different from new features in my book, and if the tables had been turned, I'm sure you'd agree. -j On Sep 7, 2007, at 7:21 PM, Jason van Zyl wrote: On 7 Sep 07, at 3:52 PM 7 Sep 07, John Casey wrote: I thought we'd agreed awhile back to do this, but apparently that's not the case. For big features sure. I wasn't adding any new features. I'm getting rid of the ton of crap lying around to prepare for more people being able to understand 2.1. When I updated from Subversion today, I got a nasty surprise. Lo and behold, it would not bootstrap! I didn't find much discussion on the dev list about a massive reorganization (none, in fact), The issues for refactoring the major components has been in JIRA for a long time. Yes, I am additionally cleaning things up, no one else has touched the trunk in any significant way in the last couple months so I see myself as pretty much alone (unfortunately at this point). and the number of commits makes it pretty difficult to parse out exactly where things went wrong. Suffice it to say that I'm doing all of my build/plugin work today based on 2.1-SNAPSHOT artifacts, not on a trunk build. Can we please, please, PLEASE start using feature friggin branches?? I'm fixing bugs, trying to get plugins to work and improving error reporting and generally push all configuration to the front-end so that it can be explained. It's not so difficult to merge them in when you're done, and I'm willing to help anyone who has trouble. If I attempt any large features I will definitely use a branch. All the features I have implemented I have not pushed into trunk. -john --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john
Re: The importance of working in branches
On 7 Sep 07, at 3:52 PM 7 Sep 07, John Casey wrote: I thought we'd agreed awhile back to do this, but apparently that's not the case. For big features sure. I wasn't adding any new features. I'm getting rid of the ton of crap lying around to prepare for more people being able to understand 2.1. When I updated from Subversion today, I got a nasty surprise. Lo and behold, it would not bootstrap! I didn't find much discussion on the dev list about a massive reorganization (none, in fact), The issues for refactoring the major components has been in JIRA for a long time. Yes, I am additionally cleaning things up, no one else has touched the trunk in any significant way in the last couple months so I see myself as pretty much alone (unfortunately at this point). and the number of commits makes it pretty difficult to parse out exactly where things went wrong. Suffice it to say that I'm doing all of my build/plugin work today based on 2.1-SNAPSHOT artifacts, not on a trunk build. Can we please, please, PLEASE start using feature friggin branches?? I'm fixing bugs, trying to get plugins to work and improving error reporting and generally push all configuration to the front-end so that it can be explained. It's not so difficult to merge them in when you're done, and I'm willing to help anyone who has trouble. If I attempt any large features I will definitely use a branch. All the features I have implemented I have not pushed into trunk. -john --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Duplicate artifactId name
On 7 Sep 07, at 3:48 PM 7 Sep 07, Vincent Siveton wrote: Hi, I noticed that we have two artifactId with the same name, ie doxia- site: * doxia/doxia-sitetools/trunk/pom.xml [1] * doxia/site/pom.xml [2] I proposed to rename the first one in doxia-sitetools. WDYT? +1 Cheers, Vincent [1] http://svn.apache.org/repos/asf/maven/doxia/doxia-sitetools/ trunk/pom.xml [2] http://svn.apache.org/repos/asf/maven/doxia/site/pom.xml Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com --
Using HTTP repositories for consumption only
After thinking about Greg's comments I think it would be interesting to ask people who actually uses anything but HTTP repositories for consumption? Deployment is a totally different story, but to radically simplify the core what if we only allowed HTTP repositories for consumption in 2.1? Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
The importance of working in branches
I thought we'd agreed awhile back to do this, but apparently that's not the case. When I updated from Subversion today, I got a nasty surprise. Lo and behold, it would not bootstrap! I didn't find much discussion on the dev list about a massive reorganization (none, in fact), and the number of commits makes it pretty difficult to parse out exactly where things went wrong. Suffice it to say that I'm doing all of my build/plugin work today based on 2.1-SNAPSHOT artifacts, not on a trunk build. Can we please, please, PLEASE start using feature friggin branches?? It's not so difficult to merge them in when you're done, and I'm willing to help anyone who has trouble. -john --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john
Duplicate artifactId name
Hi, I noticed that we have two artifactId with the same name, ie doxia-site: * doxia/doxia-sitetools/trunk/pom.xml [1] * doxia/site/pom.xml [2] I proposed to rename the first one in doxia-sitetools. WDYT? Cheers, Vincent [1] http://svn.apache.org/repos/asf/maven/doxia/doxia-sitetools/trunk/pom.xml [2] http://svn.apache.org/repos/asf/maven/doxia/site/pom.xml
Re: 2.1 execution of plugins
Hell, I'd settle for being able to bootstrap at all. It's really not cool to respond that CI is broken and not respond at all to someone saying the build breaks on their machine...without even taking more time trying to replicate their results. This has put a HUGE crimp in my own plans for today, I can tell you. -john On Sep 7, 2007, at 4:33 PM, Jason van Zyl wrote: I started testing many of our standard plugins and we have more then a few problems. So don't be alarmed if you bootstrap and try to run things like the release plugin, or the site plugin because they won't work. I'm making a compatibility layer and tracking down problems this weekend to stabilize in an attempt for a release soon. Not looking like next week is going to be feasible given these problems and doxia and m-a are not released yet. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john
Re: Classpath ordering of dependencies
On 7 Sep 07, at 2:20 PM 7 Sep 07, Paul Gier wrote: Jason van Zyl wrote: On 7 Sep 07, at 9:43 AM 7 Sep 07, Paul Gier wrote: Hi Everyone, I noticed that transitive dependencies seem to precede direct dependencies on the test classpath. I created this issue related to this: http://jira.codehaus.org/browse/MNG-3197 Is this behaviour by design? No. This is not good as it provides no control over ordering when you need it. I've already run into serious issues with migrations where you have very little control when you need it. In the current maven, this means that if there is an older version of one of your direct dependencies in the transitive dep tree of another dependency, the older version will be used by the test code. This can be confusing when a test fails because the test is using an old version of one of the dependencies listed in the pom. It seems like it would make more sense if the direct dependencies take priority over transitive dependencies, but maybe there is some reason for this. If not, I will start working on a patch to reverse the classpath ordering. No, what you list should be first, that only makes sense and artifacts should not be duplicated. You are finding you're getting two copies of foo-XXX.jar? I did a little more research, and it looks like the artifact was renamed, so maven didn't know they were the same artifact. For an example, if you create a project with a direct dependency on antlr:antlr:3.0b5 and have a transitive dependency on antlr:antlr: 2.7.1, you will get the 2.7.1 version in the classpath first because 3.0b5 has been renamed to groupId "org.antlr" When the groupId and artifactId are the same, then maven does the right thing and removed the transitive dependency. So does it still make sense to reverse the generated classpath ordering so that direct dependencies come first? Absolutely. It's not right that the user has no control. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classpath ordering of dependencies
Jason van Zyl wrote: On 7 Sep 07, at 9:43 AM 7 Sep 07, Paul Gier wrote: Hi Everyone, I noticed that transitive dependencies seem to precede direct dependencies on the test classpath. I created this issue related to this: http://jira.codehaus.org/browse/MNG-3197 Is this behaviour by design? No. This is not good as it provides no control over ordering when you need it. I've already run into serious issues with migrations where you have very little control when you need it. In the current maven, this means that if there is an older version of one of your direct dependencies in the transitive dep tree of another dependency, the older version will be used by the test code. This can be confusing when a test fails because the test is using an old version of one of the dependencies listed in the pom. It seems like it would make more sense if the direct dependencies take priority over transitive dependencies, but maybe there is some reason for this. If not, I will start working on a patch to reverse the classpath ordering. No, what you list should be first, that only makes sense and artifacts should not be duplicated. You are finding you're getting two copies of foo-XXX.jar? I did a little more research, and it looks like the artifact was renamed, so maven didn't know they were the same artifact. For an example, if you create a project with a direct dependency on antlr:antlr:3.0b5 and have a transitive dependency on antlr:antlr:2.7.1, you will get the 2.7.1 version in the classpath first because 3.0b5 has been renamed to groupId "org.antlr" When the groupId and artifactId are the same, then maven does the right thing and removed the transitive dependency. So does it still make sense to reverse the generated classpath ordering so that direct dependencies come first? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r573699 - in /maven/core-integration-testing/trunk: ./ core-integration-testing-plugins/ core-integration-testing-plugins/maven-it-plugin-context-passing/ core-integration-testing-plug
On 7 Sep 07, at 1:58 PM 7 Sep 07, [EMAIL PROTECTED] wrote: Author: jdcasey Date: Fri Sep 7 13:58:21 2007 New Revision: 573699 URL: http://svn.apache.org/viewvc?rev=573699&view=rev Log: Fixing core-it-plugins so they won't bomb on surefire:test with NPE if there is nothing under src/test/java. Huh? I do mvn install all the time and have never seen this? Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
2.1 execution of plugins
I started testing many of our standard plugins and we have more then a few problems. So don't be alarmed if you bootstrap and try to run things like the release plugin, or the site plugin because they won't work. I'm making a compatibility layer and tracking down problems this weekend to stabilize in an attempt for a release soon. Not looking like next week is going to be feasible given these problems and doxia and m-a are not released yet. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lining up maven-artifact for a release
Mark, can you merge your changes into the trunk of maven-artifact? I'm willing to try them out with 2.1.x. If we can work in tandem there to validate and test that would be great. Thanks for taking the time to test 2.0.x. I really, really hope we can get this to work as it means that people using the library independently, 2.1.x and 2.0.x will be using the same code that that would be fantastic. On 7 Sep 07, at 3:36 AM 7 Sep 07, Mark Hobson wrote: On 04/09/2007, Jason van Zyl <[EMAIL PROTECTED]> wrote: On 4 Sep 07, at 8:37 AM 4 Sep 07, Mark Hobson wrote: I haven't had time to test it out in 2.1.x, although that FIXME needs fixing first as detailed in the issue. When are you thinking of releasing maven-artifact? Could be worth trying to get 2.0.x to use it first in case it requires any changes. Yes, we should try it to see if it's even feasible. I have a little Hudson grid I can flip it into to try it. I started trying to get 2.0.x to use maven-artifact 3.0-SNAPSHOT. It doesn't seem too bad - no compilation problems - currently just a linking issue to resolve before the IT tests should hopefully pass. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classpath ordering of dependencies
On 7 Sep 07, at 9:43 AM 7 Sep 07, Paul Gier wrote: Hi Everyone, I noticed that transitive dependencies seem to precede direct dependencies on the test classpath. I created this issue related to this: http://jira.codehaus.org/browse/MNG-3197 Is this behaviour by design? No. This is not good as it provides no control over ordering when you need it. I've already run into serious issues with migrations where you have very little control when you need it. In the current maven, this means that if there is an older version of one of your direct dependencies in the transitive dep tree of another dependency, the older version will be used by the test code. This can be confusing when a test fails because the test is using an old version of one of the dependencies listed in the pom. It seems like it would make more sense if the direct dependencies take priority over transitive dependencies, but maybe there is some reason for this. If not, I will start working on a patch to reverse the classpath ordering. No, what you list should be first, that only makes sense and artifacts should not be duplicated. You are finding you're getting two copies of foo-XXX.jar? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using alternate pom files
On 7 Sep 07, at 9:31 AM 7 Sep 07, Paul Gier wrote: I submitted a small patch for this issue: http://jira.codehaus.org/browse/MNG-3150 The basic idea of it is to be able to use alternate pom.xml files in a multi-module project. Can someone with commit access take a look at this? It would really help with some of our projects if this can be added to a future release. Not sure this is a great idea. Why aren't you using profiles? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Using alternate pom files
I submitted a small patch for this issue: http://jira.codehaus.org/browse/MNG-3150 The basic idea of it is to be able to use alternate pom.xml files in a multi-module project. Can someone with commit access take a look at this? It would really help with some of our projects if this can be added to a future release. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Classpath ordering of dependencies
Hi Everyone, I noticed that transitive dependencies seem to precede direct dependencies on the test classpath. I created this issue related to this: http://jira.codehaus.org/browse/MNG-3197 Is this behaviour by design? In the current maven, this means that if there is an older version of one of your direct dependencies in the transitive dep tree of another dependency, the older version will be used by the test code. This can be confusing when a test fails because the test is using an old version of one of the dependencies listed in the pom. It seems like it would make more sense if the direct dependencies take priority over transitive dependencies, but maybe there is some reason for this. If not, I will start working on a patch to reverse the classpath ordering. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why not more releases of maven plugins ?
the changelog is easy to see in jira ie http://jira.codehaus.org/browse/SUREFIRE?report=com.atlassian.jira.plugin.system.project:roadmap-panel it's not a problem of tracking the changes but to say out loud "hey, release the plugin!" On 9/7/07, nicolas de loof <[EMAIL PROTECTED]> wrote: > > If you have ideas on how we can do this better, we're all ears. > > > I've noticed from the hudson way (but maybe this is the wrong way) that they > put a release when 2 or 3 bugs have been fixed. > > As maven provides SNAPSHOT support this seems not required to release a > plugin to allow users to get the fix. But this as the side effect that > project that want to release must have all dependencies and plugins also > released.. And many user prefer to have a reproductible build. > > IMHO, commiters do great work fixing issues and testing patches, but they > should go a little more deeper with suggesting releases. A simple rule like > "when more than N issues have been fixes OR there has been no release from X > latest weeks, prepare a new release after fixing an issue". > > Surefire for example has 96 issues in Jira, so I understand this makes huge > work for commiters. But there is allready 2 issues marked as CLOSED, one > from april 07, latest from july. I can't think nobody worked on surefire > during 5 month ! > > IMHO a 2.4 (maybe 2.3.1 ?) release should be a good way to make many users > happy : the ones that reported this issue, and the ones that will fall into > same situation and may duplicate the ticket. > > Why not use the project wiki to create a dashboard for fixed issues, so that > a new release requirement could be more visible ? I didn't found a simple > way to get Jira report a list of "closed issue since latest release". > > Just my 2 cents... > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why not more releases of maven plugins ?
> If you have ideas on how we can do this better, we're all ears. I've noticed from the hudson way (but maybe this is the wrong way) that they put a release when 2 or 3 bugs have been fixed. As maven provides SNAPSHOT support this seems not required to release a plugin to allow users to get the fix. But this as the side effect that project that want to release must have all dependencies and plugins also released.. And many user prefer to have a reproductible build. IMHO, commiters do great work fixing issues and testing patches, but they should go a little more deeper with suggesting releases. A simple rule like "when more than N issues have been fixes OR there has been no release from X latest weeks, prepare a new release after fixing an issue". Surefire for example has 96 issues in Jira, so I understand this makes huge work for commiters. But there is allready 2 issues marked as CLOSED, one from april 07, latest from july. I can't think nobody worked on surefire during 5 month ! IMHO a 2.4 (maybe 2.3.1 ?) release should be a good way to make many users happy : the ones that reported this issue, and the ones that will fall into same situation and may duplicate the ticket. Why not use the project wiki to create a dashboard for fixed issues, so that a new release requirement could be more visible ? I didn't found a simple way to get Jira report a list of "closed issue since latest release". Just my 2 cents...
Re: [vote] release maven-verifier 1.1
Ok, I'll prepare to release this on Monday and then we will have all release goodies in the set of goods required for ITs. But I'll go check and see if anything else needs to be released. On 6 Sep 07, at 11:17 PM 6 Sep 07, Jason van Zyl wrote: Hi, I would like to release the maven-verifier as it's used as part of Maven's integration tests and would like to stop using the snapshot in order to prepare for the 2.1-alpha-1. The staging area is here: http://people.apache.org/~jvanzyl/maven-verifier-1.1-staging- repository/ There are no JIRA issues in the shared component, it just needs to be released. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] release maven-verifier 1.1
+1 -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, September 07, 2007 2:17 AM To: Maven Developers List Subject: [vote] release maven-verifier 1.1 Hi, I would like to release the maven-verifier as it's used as part of Maven's integration tests and would like to stop using the snapshot in order to prepare for the 2.1-alpha-1. The staging area is here: http://people.apache.org/~jvanzyl/maven-verifier-1.1-staging-repository/ There are no JIRA issues in the shared component, it just needs to be released. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [continuum] BUILD FAILURE: Maven Embedder
On 7 Sep 07, at 2:19 AM 7 Sep 07, Brett Porter wrote: I guess you're out for the night now... anyway, until we get the direct nag happening I'll just pass it on :) I just checked again, no changes for me locally, bootstrapped again and ran the ITs and it's all fine so we have a discrepancy. (yes, same problem in my checkout as on continuum - it's doing it's job just fine) Just curious - will there be any issues with these APIs changing for plugins that may have come to rely on it, or are these all purely internal? (I haven't had a chance to dig through the changes yet). Cheers, Brett On 07/09/2007, at 6:22 PM, [EMAIL PROTECTED] wrote: Online report : http://maven.zones.apache.org/continuum/ buildResult.action?buildId=20448&projectId=486 Build statistics: State: Failed Previous State: Ok Started at: Fri 7 Sep 2007 08:21:43 + Finished at: Fri 7 Sep 2007 08:22:00 + Total time: 16s Build Trigger: Schedule Build Number: 4 Exit code: 1 Building machine hostname: maven.zones.apache.org Operating system : SunOS(unknown) Java Home version : java version "1.5.0_12" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Server VM (build 1.5.0_12-b04, mixed mode) Builder version : Maven version: 2.0.7 Java version: 1.5.0_12 OS name: "sunos" version: "5.10" arch: "x86" * *** SCM Changes: * *** Changed: jvanzyl @ Fri 7 Sep 2007 07:54:11 + Comment: o scrub of the settings building, was able to reduce to the need of the build context and use the execution request directly. eventually i will get it to be the session, along with the profile tools, then all the tools can also share a common interpolator, which can then be shared by other components instead of having 5 interpolators lying around causing a great deal of inconsistency. Files changed: /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ execution/DefaultMavenExecutionRequest.java ( 573494 ) /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ execution/MavenExecutionRequest.java ( 573494 ) /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ settings/DefaultMavenSettingsBuilder.java ( 573494 ) /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ settings/MavenSettingsBuilder.java ( 573494 ) /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ settings/RuntimeInfo.java ( 573494 ) /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ settings/SettingsUtils.java ( 573494 ) /maven/components/trunk/maven-core/src/main/mdo/settings.mdo ( 573494 ) /maven/components/trunk/maven-core/src/test/java/org/apache/maven/ settings/SettingsUtilsTest.java ( 573494 ) /maven/components/trunk/maven-embedder/src/main/java/org/apache/ maven/embedder/MavenEmbedder.java ( 573494 ) /maven/components/trunk/maven-embedder/src/main/java/org/apache/ maven/embedder/execution/ DefaultMavenExecutionRequestPopulator.java ( 573494 ) /maven/components/trunk/maven-embedder/src/main/java/org/apache/ maven/embedder/execution/MavenExecutionRequestPopulator.java ( 573494 ) /maven/components/trunk/maven-embedder/src/main/resources/META- INF/plexus/components.xml ( 573494 ) /maven/components/trunk/maven-embedder/src/test/java/org/apache/ maven/embedder/MavenEmbedderExampleTest.java ( 573494 ) * *** Dependencies Changes: * *** org.apache.maven:maven-core:2.1-SNAPSHOT org.apache.maven:maven:2.1-SNAPSHOT * *** Test Summary: * *** Tests: 1 Failures: 0 Total time: 29 * *** Output: * *** [INFO] Scanning for projects... [INFO] - --- [INFO] Building Maven Embedder [INFO]task-segment: [clean, install] [INFO] - --- [INFO] [clean:clean] [INFO] Deleting directory /export/home/build/data/continuum/ checkouts/486/target [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] Copying 2 resources [INFO] [compiler:compile] [INFO] Compiling 24 source files to /export/home/build/data/ continuum/checkouts/486/target/classes [INFO] - --- [ERROR] BUILD FAILURE [INFO] -
Re: [vote] release maven-verifier 1.1
+1 On 7 Sep 2007, at 07:17, Jason van Zyl wrote: Hi, I would like to release the maven-verifier as it's used as part of Maven's integration tests and would like to stop using the snapshot in order to prepare for the 2.1-alpha-1. The staging area is here: http://people.apache.org/~jvanzyl/maven-verifier-1.1-staging- repository/ There are no JIRA issues in the shared component, it just needs to be released. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-verifier 1.1
+1 -john On Sep 7, 2007, at 2:17 AM, Jason van Zyl wrote: Hi, I would like to release the maven-verifier as it's used as part of Maven's integration tests and would like to stop using the snapshot in order to prepare for the 2.1-alpha-1. The staging area is here: http://people.apache.org/~jvanzyl/maven-verifier-1.1-staging- repository/ There are no JIRA issues in the shared component, it just needs to be released. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john
Re: [continuum] BUILD FAILURE: Maven Embedder
On 7 Sep 07, at 2:19 AM 7 Sep 07, Brett Porter wrote: Just curious - will there be any issues with these APIs changing for plugins that may have come to rely on it, or are these all purely internal? (I haven't had a chance to dig through the changes yet). We must absolutely guarantee that all 2.0.x plugins work out of the box without change. I've made no plugin api changes and we won't until the proposals are vetted. Cheers, Brett On 07/09/2007, at 6:22 PM, [EMAIL PROTECTED] wrote: Online report : http://maven.zones.apache.org/continuum/ buildResult.action?buildId=20448&projectId=486 Build statistics: State: Failed Previous State: Ok Started at: Fri 7 Sep 2007 08:21:43 + Finished at: Fri 7 Sep 2007 08:22:00 + Total time: 16s Build Trigger: Schedule Build Number: 4 Exit code: 1 Building machine hostname: maven.zones.apache.org Operating system : SunOS(unknown) Java Home version : java version "1.5.0_12" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Server VM (build 1.5.0_12-b04, mixed mode) Builder version : Maven version: 2.0.7 Java version: 1.5.0_12 OS name: "sunos" version: "5.10" arch: "x86" * *** SCM Changes: * *** Changed: jvanzyl @ Fri 7 Sep 2007 07:54:11 + Comment: o scrub of the settings building, was able to reduce to the need of the build context and use the execution request directly. eventually i will get it to be the session, along with the profile tools, then all the tools can also share a common interpolator, which can then be shared by other components instead of having 5 interpolators lying around causing a great deal of inconsistency. Files changed: /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ execution/DefaultMavenExecutionRequest.java ( 573494 ) /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ execution/MavenExecutionRequest.java ( 573494 ) /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ settings/DefaultMavenSettingsBuilder.java ( 573494 ) /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ settings/MavenSettingsBuilder.java ( 573494 ) /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ settings/RuntimeInfo.java ( 573494 ) /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ settings/SettingsUtils.java ( 573494 ) /maven/components/trunk/maven-core/src/main/mdo/settings.mdo ( 573494 ) /maven/components/trunk/maven-core/src/test/java/org/apache/maven/ settings/SettingsUtilsTest.java ( 573494 ) /maven/components/trunk/maven-embedder/src/main/java/org/apache/ maven/embedder/MavenEmbedder.java ( 573494 ) /maven/components/trunk/maven-embedder/src/main/java/org/apache/ maven/embedder/execution/ DefaultMavenExecutionRequestPopulator.java ( 573494 ) /maven/components/trunk/maven-embedder/src/main/java/org/apache/ maven/embedder/execution/MavenExecutionRequestPopulator.java ( 573494 ) /maven/components/trunk/maven-embedder/src/main/resources/META- INF/plexus/components.xml ( 573494 ) /maven/components/trunk/maven-embedder/src/test/java/org/apache/ maven/embedder/MavenEmbedderExampleTest.java ( 573494 ) * *** Dependencies Changes: * *** org.apache.maven:maven-core:2.1-SNAPSHOT org.apache.maven:maven:2.1-SNAPSHOT * *** Test Summary: * *** Tests: 1 Failures: 0 Total time: 29 * *** Output: * *** [INFO] Scanning for projects... [INFO] - --- [INFO] Building Maven Embedder [INFO]task-segment: [clean, install] [INFO] - --- [INFO] [clean:clean] [INFO] Deleting directory /export/home/build/data/continuum/ checkouts/486/target [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] Copying 2 resources [INFO] [compiler:compile] [INFO] Compiling 24 source files to /export/home/build/data/ continuum/checkouts/486/target/classes [INFO] - --- [ERROR] BUILD FAILURE [INFO] - --- [INFO] Compilation failure /export/home/build/data/continuum/checkouts/486/src/main/java/org/ apache/maven/embedder/
Re: [continuum] BUILD FAILURE: Maven Embedder
I will setup Hudson on a Contegix machine and we'll have two automated opinions. On 7 Sep 07, at 2:19 AM 7 Sep 07, Brett Porter wrote: I guess you're out for the night now... anyway, until we get the direct nag happening I'll just pass it on :) (yes, same problem in my checkout as on continuum - it's doing it's job just fine) I always bootstrap as it still resolves incorrectly sometimes and pulls in the wrong things otherwise. Just curious - will there be any issues with these APIs changing for plugins that may have come to rely on it, or are these all purely internal? (I haven't had a chance to dig through the changes yet). Cheers, Brett On 07/09/2007, at 6:22 PM, [EMAIL PROTECTED] wrote: Online report : http://maven.zones.apache.org/continuum/ buildResult.action?buildId=20448&projectId=486 Build statistics: State: Failed Previous State: Ok Started at: Fri 7 Sep 2007 08:21:43 + Finished at: Fri 7 Sep 2007 08:22:00 + Total time: 16s Build Trigger: Schedule Build Number: 4 Exit code: 1 Building machine hostname: maven.zones.apache.org Operating system : SunOS(unknown) Java Home version : java version "1.5.0_12" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Server VM (build 1.5.0_12-b04, mixed mode) Builder version : Maven version: 2.0.7 Java version: 1.5.0_12 OS name: "sunos" version: "5.10" arch: "x86" * *** SCM Changes: * *** Changed: jvanzyl @ Fri 7 Sep 2007 07:54:11 + Comment: o scrub of the settings building, was able to reduce to the need of the build context and use the execution request directly. eventually i will get it to be the session, along with the profile tools, then all the tools can also share a common interpolator, which can then be shared by other components instead of having 5 interpolators lying around causing a great deal of inconsistency. Files changed: /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ execution/DefaultMavenExecutionRequest.java ( 573494 ) /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ execution/MavenExecutionRequest.java ( 573494 ) /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ settings/DefaultMavenSettingsBuilder.java ( 573494 ) /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ settings/MavenSettingsBuilder.java ( 573494 ) /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ settings/RuntimeInfo.java ( 573494 ) /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ settings/SettingsUtils.java ( 573494 ) /maven/components/trunk/maven-core/src/main/mdo/settings.mdo ( 573494 ) /maven/components/trunk/maven-core/src/test/java/org/apache/maven/ settings/SettingsUtilsTest.java ( 573494 ) /maven/components/trunk/maven-embedder/src/main/java/org/apache/ maven/embedder/MavenEmbedder.java ( 573494 ) /maven/components/trunk/maven-embedder/src/main/java/org/apache/ maven/embedder/execution/ DefaultMavenExecutionRequestPopulator.java ( 573494 ) /maven/components/trunk/maven-embedder/src/main/java/org/apache/ maven/embedder/execution/MavenExecutionRequestPopulator.java ( 573494 ) /maven/components/trunk/maven-embedder/src/main/resources/META- INF/plexus/components.xml ( 573494 ) /maven/components/trunk/maven-embedder/src/test/java/org/apache/ maven/embedder/MavenEmbedderExampleTest.java ( 573494 ) * *** Dependencies Changes: * *** org.apache.maven:maven-core:2.1-SNAPSHOT org.apache.maven:maven:2.1-SNAPSHOT * *** Test Summary: * *** Tests: 1 Failures: 0 Total time: 29 * *** Output: * *** [INFO] Scanning for projects... [INFO] - --- [INFO] Building Maven Embedder [INFO]task-segment: [clean, install] [INFO] - --- [INFO] [clean:clean] [INFO] Deleting directory /export/home/build/data/continuum/ checkouts/486/target [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] Copying 2 resources [INFO] [compiler:compile] [INFO] Compiling 24 source files to /export/home/build/data/ continuum/checkouts/486/target/classes [INFO] - --- [ERROR
Re: svn propchange: r573485 - svn:log
On 7 Sep 07, at 12:02 AM 7 Sep 07, [EMAIL PROTECTED] wrote: Author: brett Revision: 573485 Modified property: svn:log Modified: svn:log at Fri Sep 7 00:02:24 2007 -- --- svn:log (original) +++ svn:log Fri Sep 7 00:02:24 2007 @@ -1 +1,8 @@ move the wagon with the manager out to a branch + +As of this revision, the differences with the 1.x branch are: +- API changes in the Wagon interface +- resulting changes to events to add the repository parameters +- inclusion of the wagon manager + +Ideally, the wagon manager would be ported to the Wagon 1.x trunk without the breaking API changes This is not ideally what should happen. I propose tossing the trunk as the WagonManager should not be part of Wagon, here's my proposal which I will post as part of next week. Wagon is far too complicated and its concerns being mixed. It is sole for transport, not management of the sources. h3. Context Wagon is starting to take on too much functionality, becoming too complicated, and veering away from its intended goal of being a simple transport provider. These things should be in Wagon proper * Mirrors * Proxies (general proxies) * WagonManager * Authentication and Authorization should be abstract and should really be the job of another system that is tied in * Copying anything other then single files is not really the job of Wagon. As we have found you need quite a bit of logic to actually make directory copying * Anything like stats should be taken from information provided by events and should not be baked into Wagon These things just make Wagon unmanageable and not what Wagon was intended to be. These secondary concerns are not Wagon's concern and should be dealt with in client code like Maven. Or even add-ons to Wagon but not part of the core. The core is only concerned with transport. We should be focusing of things like: * Session support for publishing and retrieval * Pooling connections * Betting event monitoring * Integrity of transmission * Proxy information should be localized to the provider. Knowledge of SOCKs proxies for example is an HTTP thing primarily * RepositoryPermissions is specific to file system based repositories and is not applicable generally h3. Solution - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lining up maven-artifact for a release
On 7 Sep 07, at 6:39 AM 7 Sep 07, Mark Hobson wrote: On 07/09/2007, Mark Hobson <[EMAIL PROTECTED]> wrote: I started trying to get 2.0.x to use maven-artifact 3.0-SNAPSHOT. It doesn't seem too bad - no compilation problems - currently just a linking issue to resolve before the IT tests should hopefully pass. The linking issue was due to maven-plugin-plugin using the old maven-artifact - updating its dependencies fixed the ITs. Only it0095 and it0118 fail for me now, but then they fail with the current 2.0.x branch too. That's awesome news. How do we want to take this forward? I'll take a try and run it as well and then we have to decide if we trust our tests. We might want to be a little more rigourous and try to run some of the other major plugins like the archetype and the site plugin which make use of the resolver. If those make it I would think that it's pretty safe. We also have to deal with tools that require 3 modules instead of one. Old plugins might have used maven-repository-metadata, maven- artifact, and maven-artifact-manager so we have to make sure that works somehow. But as discussed in a mail a few days ago I am fine with having releases require at least betas and maven-artifact is not going to be for a while. So if it works that's great, we need to assess some other plugins, our tests and decide whether we can use it or not. The code is not really an alpha, it's just the decoupled code with a bumped version. With some rigourous testing and we find it works I would much prefer to use the same decoupled codebase. I can commit these changes and delete the old maven-artifact & maven-artifact-manager, although I'm guessing several plugins will need updating to use the new maven-artifact. A branch may be better if people want to review it first. Yah, we would definitely need to figure out how to use the new code with old plugins. There probably are not that many but we still need to make sure it works. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] toolchains
On 7 Sep 07, at 2:36 AM 7 Sep 07, Milos Kleint wrote: can I assume this proposal is ok with everyone and start some initial work on it? The plan was that we collect all the proposals, and give people until next friday. Then we decide what will be done and in what release. If you want to start features then do it on a branch because the first couple releases should focus on making sure that regressions are eliminated (alpha-1), and then alpha-2 should focus on usability i.e. making every last possible thing that can go wrong reaches a user in a way that is understandable. Honestly your changes of adding a feature like toolchains being done prior to some key components being refactored and the plugin api sort I think will be hard. I am focusing solely on cleaning up code to prepare for people like you being able to add features but if you want to start now and prepare then please do it in a branch and just pull in the changes I'm making from trunk. We have to focus on compatibility and usability and test that for the first couple releases. The alpha-1 can be cut when the prereqs are done (doxia and maven-artifact) and the regressions are gone. The second release should be the improvements users most need and that's understanding anything problem that occurs. There really also needs to be some refactoring in the core before you could do a serious stab at toolchains. Milos On 9/2/07, Milos Kleint <[EMAIL PROTECTED]> wrote: Hello, See: http://docs.codehaus.org/display/MAVEN/Toolchains Text included below for inline comments (which I'll feed back into the document as needed). Milos Goal Have a way for plugins to discover what JDK (or other tools) are to be used, without configuring the plugins. The current Maven way of achieving this is to run Maven itself with the required JDK. After toolchains, the JDK that Maven is running within, shall be irrelevant to the project in question. Motivation Current way or enforcing project's JDK version (via the enforcer or otherwise) by forcing the user to run Maven itself with the given JDK version breaks embedded use. Additionally toolchains will allow a type of user interaction that IDE users are used to. Just set the JDK to the project and go. Design Note: I'll be focusing on JDK toolchain. I don't have enough background information for other types of toolchains. The associated issue is: MNG-468 3 basic points of view: 1. Plugin denotes what toolchain type it requires for it's operation. So compilation, surefire, jnlp, ... need a JDK toolchain instance for example. The actual instance of the toolchain is passed into the plugin by the infrastructure (using Build context?). If no toolchain of given type is available to the infrastructure, the build fails. The JDK toolchain shall have a fallback default value of the JDK maven runs with. Others might not have such a default value. Q1: how shall the plugin tell what toolchains it needs? parameter? parameter's or mojo's @toolchain annotation? 2. User defines the toolchain instances that are available in his current setup. Shall be project independent, stored in $HOME/.m2/toolchains.xml file? Could look like this: jdk jdk15 /home/mkleint/javatools/jdk1.5.0_07directory> 3. Project shall be allowed to state which instance of the given toolchain type it requires for the build. Therefore making sure that all plugins use jdk15 for example. if such toolchain instance is not found in user's local setup, the build shall fail early. Q2: how to mark that in the pom? Shall also be profile-able, eg. have different configurations run with different instances of toolchains.. a new pom element? eg. jdk jdk15 or rather some backward compatible solution? Possibly something along the lines of the enforcer plugin? A toolchain-plugin would be responsible for picking the correct instances and make it available for other plugins to use (in the build content). maven-toolchain-plugin jdk15 toolkit22 Backward compatibility Can we achieve backward compatibility with 2.0.x or do we have to go with 2.1 only? It would be nice if at least plugins that start using toolchains would not require 2.1. The only roadblock for backward compatibility is the build-context that is needed for inter-plugin communication. Build-context seems to be relatively independent of the rest of maven, just requires plexus container that is newer than the one used in 2.0.x. Can we upgrade? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com --
Re: What can possibly go wrong with Maven
On 05/09/2007, Jörg Schaible <[EMAIL PROTECTED]> wrote: > You mean something like this? > > [EMAIL PROTECTED] ~/src/Codehaus/pico/java-2.x/nano/container-bsh $ mvn > info:deps-runtime > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'info'. > WAGON_VERSION: 1.0-beta-2 > [INFO] > > [INFO] Building NanoContainer bsh > [INFO]task-segment: [info:deps-runtime] > [INFO] > > [INFO] [info:deps-runtime] > [INFO] org.nanocontainer:nanocontainer-bsh:jar:2.0-SNAPSHOT > [INFO] org.nanocontainer:nanocontainer:jar:2.0-SNAPSHOT > [INFO] : org.picocontainer:picocontainer:jar:2.0-SNAPSHOT > [INFO] : com.thoughtworks.paranamer:paranamer-asm:jar:1.0.1 > [INFO] : com.thoughtworks.paranamer:paranamer:jar:1.0.1 > [INFO] : asm:asm:jar:3.0 > [INFO] org.beanshell:bsh:jar:2.0b4 > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 5 seconds > [INFO] Finished at: Wed Sep 05 13:03:28 CEST 2007 > [INFO] Final Memory: 3M/6M > [INFO] > Also see dependency:tree under MDEP-100. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lining up maven-artifact for a release
On 07/09/2007, Mark Hobson <[EMAIL PROTECTED]> wrote: > I started trying to get 2.0.x to use maven-artifact 3.0-SNAPSHOT. It > doesn't seem too bad - no compilation problems - currently just a > linking issue to resolve before the IT tests should hopefully pass. The linking issue was due to maven-plugin-plugin using the old maven-artifact - updating its dependencies fixed the ITs. Only it0095 and it0118 fail for me now, but then they fail with the current 2.0.x branch too. How do we want to take this forward? I can commit these changes and delete the old maven-artifact & maven-artifact-manager, although I'm guessing several plugins will need updating to use the new maven-artifact. A branch may be better if people want to review it first. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.0-alpha-9 release checklist
Vincent Siveton wrote: Hi, Mainly for Dennis who kindly suggests to do the release, here are some doc issues: * publish the site decoration descriptor XSD and the associated doc. Actually, it is decoration-1.0.0.xsd but I would prefer to name it decoration-1.0.0-alpha-9.xsd. WDYT? Moreover, where to publish it? in http://maven.apache.org/xsd/ ? or http://maven.apache.org/doxia/xsd/ ? IMHO, the second one seems to be the right place. I just had a look at this, the generated xsd suffers from the same modello bugs that I mentioned at DOXIA-136 (attributes are written as elements). Since it's practically unusable, I wouldn't bother publishing it, even as an alpha... * since fml descriptor is buggy (DOXIA-136), we shouldn't publish it. * we need (short) reference pages for FML and xdoc [1]. * We need to publish also the dev sites of doxia and doxia-sitetools. I suggest to put them at http://maven.apache.org/doxia/ref/ like on the maven site. WDYT? There are several sub-project sites that have been deployed once already in a preliminary state [1], I think we can remove those pages and just put the top-level sites of doxia/ and doxia-sitetools/, which contain the links to all sub-modules. And put some links there from the main doxia site (Developer docs, or so). -Lukas [1] http://maven.apache.org/doxia/doxia-core/ http://maven.apache.org/doxia/doxia-modules/ http://maven.apache.org/doxia/doxia-sink-api/ http://maven.apache.org/doxia/doxia-book/ http://maven.apache.org/doxia/doxia-decoration-model/ http://maven.apache.org/doxia/doxia-doc-renderer/ http://maven.apache.org/doxia/doxia-editor/ http://maven.apache.org/doxia/doxia-maven-plugin/ http://maven.apache.org/doxia/doxia-sandbox/ http://maven.apache.org/doxia/doxia-site-renderer/ Cheers, Vincent [1] http://maven.apache.org/doxia/references/index.html 2007/9/4, Dennis Lundberg <[EMAIL PROTECTED]>: Hi all Just trying to sum up all remaining issues for the release. This is what I have left on my checklist: - Await [vote] to include doxia-book and doxia-maven-plugin. The vote ends on friday the 7th. If someone has something else please speak up now. Vincent, if the vote passes, when will you have time to promote the them from the sandbox? I can prepare the proposed release bits over the weekend if we are done by then. -- Dennis Lundberg
RE: [proposal] "Make like" reactor build mode
Heh, when I first read it, I thought you took the proposal and made a jira until I saw the date ;-) Freaky. -Original Message- From: Kenney Westerhof [mailto:[EMAIL PROTECTED] Sent: Friday, September 07, 2007 12:12 AM To: Maven Developers List Subject: Re: [proposal] "Make like" reactor build mode Hi, FYI I reported this as a Jira issue almost a year ago: http://jira.codehaus.org/browse/MNG-2576 oh. I just saw your comment on the issue referring to this. Yes, this is exactly the same issue ;) -- Kenney Brian E. Fox wrote: > http://docs.codehaus.org/display/MAVEN/Make+Like+Reactor+Mode > > > > "Make" like build behavior mode > > Maven currently has a top down build approach where you start at the top > of a reactor and build all children. One of the most common requests I > get from my developers is an easy way to build certain artifacts from > the bottom up. Often times a build, especially large ones, will contain > many modules needed for a "full" build, but are actually made up of > pockets of interdependencies. It's not always possible to logically > group these all together with a common parent to enable easily building > a subtree. > > For example, you may have a project comprised of services, ui's and > packages: > > > +---packages > > | +---a-package > > | +---b-package > > | \---c-package > > +---services > > | +---a-service > > | +---b-service > > | \---c-service > > \---ui > > +---a-ui > > +---b-ui > > \---c-ui > > The packages inherit from the package parent, etc. Assume that > "A-package" depends on "a-service" "b-service" and "a-ui" > > In Maven, there is currently no easy way to make a change to "a-service" > and build it and the package at once. This can be controlled to some > extent with modules in profiles, but this quickly becomes unwieldy and > doesn't support the granularity needed. > > Out of Scope > > It is out of scope for this proposal to determine if a project actually > needs to be rebuilt based on the contents. (ie checking if anything has > actually changed) This is simply intended to be an extension to the > reactor behavior in choosing which projects should be included in the > reactor. > > Proposed Solution > > The ideal use case for this issue is: > > 1. Developer makes change to code in "a-service" > > 2. Developer goes to "a-package" and executes "mvn -A install" (-A for > all) > > 3. Maven walks up the parent tree to see how far up the source goes. > Then any dependencies in the graph that are found in the contained > source on disk are ordered and built. Everything else is ignored in the > build. > > Alternate Use Case: > > 2. Instead of going to "a-package" and executing mvn, the developer > goes to the top level parent and executes "mvn -Aa-package" (in this > case defining the module that should be considered for dependency > graphing) > > 3. Maven builds the graph and builds what is needed. > > This use case isn't ideal but is probably easier to implement since the > top level parent doesn't need to be located and everything to be built > is included in the subtree. > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Dependencies in maven-jar-plugin
Hi I've fixed the mjar-30 and possibly the mjar-80 (by accident), and while I was at it I created a couple of integrationtests using the maven-embedder. I could not get the embedder to run without upgrading the some dependencies (like maven-core and the maven-artifact), do you have any general policy for witch versions to use? Snapshot? Currently I'm using 2.0.7. I found out that the patch I submitted has some faults (wrong formatting in some files, complete file-paths, missing licence-header). I'll try to fix this during the weekend. /Johan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lining up maven-artifact for a release
On 04/09/2007, Jason van Zyl <[EMAIL PROTECTED]> wrote: > On 4 Sep 07, at 8:37 AM 4 Sep 07, Mark Hobson wrote: > > I haven't had time to test it out in 2.1.x, although that FIXME needs > > fixing first as detailed in the issue. When are you thinking of > > releasing maven-artifact? Could be worth trying to get 2.0.x to use > > it first in case it requires any changes. > > Yes, we should try it to see if it's even feasible. I have a little > Hudson grid I can flip it into to try it. I started trying to get 2.0.x to use maven-artifact 3.0-SNAPSHOT. It doesn't seem too bad - no compilation problems - currently just a linking issue to resolve before the IT tests should hopefully pass. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] toolchains
Yeah, go for it - lazy consensus :) I actually started to flip through this the other day - I'll take another look. I also started marking JIRA issues that might be related with [toolchain]. - Brett On 07/09/2007, at 7:36 PM, Milos Kleint wrote: can I assume this proposal is ok with everyone and start some initial work on it? Milos On 9/2/07, Milos Kleint <[EMAIL PROTECTED]> wrote: Hello, See: http://docs.codehaus.org/display/MAVEN/Toolchains Text included below for inline comments (which I'll feed back into the document as needed). Milos Goal Have a way for plugins to discover what JDK (or other tools) are to be used, without configuring the plugins. The current Maven way of achieving this is to run Maven itself with the required JDK. After toolchains, the JDK that Maven is running within, shall be irrelevant to the project in question. Motivation Current way or enforcing project's JDK version (via the enforcer or otherwise) by forcing the user to run Maven itself with the given JDK version breaks embedded use. Additionally toolchains will allow a type of user interaction that IDE users are used to. Just set the JDK to the project and go. Design Note: I'll be focusing on JDK toolchain. I don't have enough background information for other types of toolchains. The associated issue is: MNG-468 3 basic points of view: 1. Plugin denotes what toolchain type it requires for it's operation. So compilation, surefire, jnlp, ... need a JDK toolchain instance for example. The actual instance of the toolchain is passed into the plugin by the infrastructure (using Build context?). If no toolchain of given type is available to the infrastructure, the build fails. The JDK toolchain shall have a fallback default value of the JDK maven runs with. Others might not have such a default value. Q1: how shall the plugin tell what toolchains it needs? parameter? parameter's or mojo's @toolchain annotation? 2. User defines the toolchain instances that are available in his current setup. Shall be project independent, stored in $HOME/.m2/toolchains.xml file? Could look like this: jdk jdk15 /home/mkleint/javatools/jdk1.5.0_07directory> 3. Project shall be allowed to state which instance of the given toolchain type it requires for the build. Therefore making sure that all plugins use jdk15 for example. if such toolchain instance is not found in user's local setup, the build shall fail early. Q2: how to mark that in the pom? Shall also be profile-able, eg. have different configurations run with different instances of toolchains.. a new pom element? eg. jdk jdk15 or rather some backward compatible solution? Possibly something along the lines of the enforcer plugin? A toolchain-plugin would be responsible for picking the correct instances and make it available for other plugins to use (in the build content). maven-toolchain-plugin jdk15 toolkit22 Backward compatibility Can we achieve backward compatibility with 2.0.x or do we have to go with 2.1 only? It would be nice if at least plugins that start using toolchains would not require 2.1. The only roadblock for backward compatibility is the build-context that is needed for inter-plugin communication. Build-context seems to be relatively independent of the rest of maven, just requires plexus container that is newer than the one used in 2.0.x. Can we upgrade? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] toolchains
can I assume this proposal is ok with everyone and start some initial work on it? Milos On 9/2/07, Milos Kleint <[EMAIL PROTECTED]> wrote: > Hello, > > See: http://docs.codehaus.org/display/MAVEN/Toolchains > > Text included below for inline comments (which I'll feed back into > the document as needed). > > Milos > > > Goal > > Have a way for plugins to discover what JDK (or other tools) are to > be used, without configuring the plugins. The current Maven way of > achieving this is to run Maven itself with the required JDK. After > toolchains, the JDK that Maven is running within, shall be irrelevant > to the project in question. > Motivation > > Current way or enforcing project's JDK version (via the enforcer or > otherwise) by forcing the user to run Maven itself with the given JDK > version breaks embedded use. > Additionally toolchains will allow a type of user interaction that IDE > users are used to. Just set the JDK to the project and go. > > Design > > Note: I'll be focusing on JDK toolchain. I don't have enough > background information for other types of toolchains. > The associated issue is: MNG-468 > > 3 basic points of view: > > 1. Plugin denotes what toolchain type it requires for it's > operation. So compilation, surefire, jnlp, ... need a JDK toolchain > instance for example. The actual instance of the toolchain is passed > into the plugin by the infrastructure (using Build context?). If no > toolchain of given type is available to the infrastructure, the build > fails. The JDK toolchain shall have a fallback default value of the > JDK maven runs with. Others might not have such a default value. > > Q1: how shall the plugin tell what toolchains it needs? parameter? > parameter's or mojo's @toolchain annotation? > > 2. User defines the toolchain instances that are available in his > current setup. Shall be project independent, stored in > $HOME/.m2/toolchains.xml file? > Could look like this: > > > > jdk > jdk15 > > /home/mkleint/javatools/jdk1.5.0_07 > > > > > 3. Project shall be allowed to state which instance of the given > toolchain type it requires for the build. Therefore making sure that > all plugins use jdk15 for example. > if such toolchain instance is not found in user's local setup, the > build shall fail early. > > Q2: how to mark that in the pom? Shall also be profile-able, eg. have > different configurations run with different instances of toolchains.. > > a new pom element? > eg. > > > > jdk > jdk15 > > > > or rather some backward compatible solution? Possibly something along > the lines of the enforcer plugin? > A toolchain-plugin would be responsible for picking the correct > instances and make it available for other plugins to use (in the build > content). > > > > maven-toolchain-plugin > > > jdk15 > toolkit22 > > > > > > Backward compatibility > > Can we achieve backward compatibility with 2.0.x or do we have to go > with 2.1 only? It would be nice if at least plugins that start using > toolchains would not require 2.1. > The only roadblock for backward compatibility is the build-context > that is needed for inter-plugin communication. Build-context seems to > be relatively independent of the rest of maven, just requires plexus > container that is newer than the one used in 2.0.x. Can we upgrade? > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [continuum] BUILD FAILURE: Maven Embedder
I guess you're out for the night now... anyway, until we get the direct nag happening I'll just pass it on :) (yes, same problem in my checkout as on continuum - it's doing it's job just fine) Just curious - will there be any issues with these APIs changing for plugins that may have come to rely on it, or are these all purely internal? (I haven't had a chance to dig through the changes yet). Cheers, Brett On 07/09/2007, at 6:22 PM, [EMAIL PROTECTED] wrote: Online report : http://maven.zones.apache.org/continuum/ buildResult.action?buildId=20448&projectId=486 Build statistics: State: Failed Previous State: Ok Started at: Fri 7 Sep 2007 08:21:43 + Finished at: Fri 7 Sep 2007 08:22:00 + Total time: 16s Build Trigger: Schedule Build Number: 4 Exit code: 1 Building machine hostname: maven.zones.apache.org Operating system : SunOS(unknown) Java Home version : java version "1.5.0_12" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Server VM (build 1.5.0_12-b04, mixed mode) Builder version : Maven version: 2.0.7 Java version: 1.5.0_12 OS name: "sunos" version: "5.10" arch: "x86" ** ** SCM Changes: ** ** Changed: jvanzyl @ Fri 7 Sep 2007 07:54:11 + Comment: o scrub of the settings building, was able to reduce to the need of the build context and use the execution request directly. eventually i will get it to be the session, along with the profile tools, then all the tools can also share a common interpolator, which can then be shared by other components instead of having 5 interpolators lying around causing a great deal of inconsistency. Files changed: /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ execution/DefaultMavenExecutionRequest.java ( 573494 ) /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ execution/MavenExecutionRequest.java ( 573494 ) /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ settings/DefaultMavenSettingsBuilder.java ( 573494 ) /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ settings/MavenSettingsBuilder.java ( 573494 ) /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ settings/RuntimeInfo.java ( 573494 ) /maven/components/trunk/maven-core/src/main/java/org/apache/maven/ settings/SettingsUtils.java ( 573494 ) /maven/components/trunk/maven-core/src/main/mdo/settings.mdo ( 573494 ) /maven/components/trunk/maven-core/src/test/java/org/apache/maven/ settings/SettingsUtilsTest.java ( 573494 ) /maven/components/trunk/maven-embedder/src/main/java/org/apache/ maven/embedder/MavenEmbedder.java ( 573494 ) /maven/components/trunk/maven-embedder/src/main/java/org/apache/ maven/embedder/execution/DefaultMavenExecutionRequestPopulator.java ( 573494 ) /maven/components/trunk/maven-embedder/src/main/java/org/apache/ maven/embedder/execution/MavenExecutionRequestPopulator.java ( 573494 ) /maven/components/trunk/maven-embedder/src/main/resources/META-INF/ plexus/components.xml ( 573494 ) /maven/components/trunk/maven-embedder/src/test/java/org/apache/ maven/embedder/MavenEmbedderExampleTest.java ( 573494 ) ** ** Dependencies Changes: ** ** org.apache.maven:maven-core:2.1-SNAPSHOT org.apache.maven:maven:2.1-SNAPSHOT ** ** Test Summary: ** ** Tests: 1 Failures: 0 Total time: 29 ** ** Output: ** ** [INFO] Scanning for projects... [INFO] -- -- [INFO] Building Maven Embedder [INFO]task-segment: [clean, install] [INFO] -- -- [INFO] [clean:clean] [INFO] Deleting directory /export/home/build/data/continuum/ checkouts/486/target [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] Copying 2 resources [INFO] [compiler:compile] [INFO] Compiling 24 source files to /export/home/build/data/ continuum/checkouts/486/target/classes [INFO] -- -- [ERROR] BUILD FAILURE [INFO] -- -- [INFO] Compilation failure /export/home/build/data/continuum/checkouts/486/src/main/java/org/ apache/maven/embedder/execution/ DefaultMavenExecution
Re: [vote] release maven-verifier 1.1
Jason van Zyl <[EMAIL PROTECTED]> writes: > On 6 Sep 07, at 11:46 PM 6 Sep 07, Insitu wrote: > >> Jason van Zyl <[EMAIL PROTECTED]> writes: >> >>> Hi, >>> >>> I would like to release the maven-verifier as it's used as part of >>> Maven's integration tests and would like to stop using the snapshot >>> in order to prepare for the 2.1-alpha-1. >>> >>> The staging area is here: >>> >>> http://people.apache.org/~jvanzyl/maven-verifier-1.1-staging->> repository/ >>> >>> There are no JIRA issues in the shared component, it just needs to be >>> released. >>> >> >> Hello, >> Maybe I did it the wrong way, or maybe these issues are unimportant, >> but I filed recently two issues MNG-3135 and MNG-3143 that are, >> AFAICT, still open. >> > > I didn't see them there under the "integration test" component. > > I took a look and the patches have huge formatting changes so I'll > pick out the salient parts and put them in for the next round. > That's strange (the formatting changes). I am using eclipse and did the formatting with the eclipse configuration from maven's site. BTW, sorry for the misplacement of the patches. Regards -- OQube < software engineering \ génie logiciel > Arnaud Bailly, Dr. \web> http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-verifier 1.1
+1 Stéphane On 9/7/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > Hi, > > I would like to release the maven-verifier as it's used as part of > Maven's integration tests and would like to stop using the snapshot > in order to prepare for the 2.1-alpha-1. > > The staging area is here: > > http://people.apache.org/~jvanzyl/maven-verifier-1.1-staging-repository/ > > There are no JIRA issues in the shared component, it just needs to be > released. > > Thanks, > > Jason > > -- > Jason van Zyl > Founder and PMC Chair, Apache Maven > jason at sonatype dot com > -- > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck" -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: head element in site.xml?
Yes :) Though it's probably a bit dodgy as is. It really is XHTML specific - you probably want some more general way to include in there. The JavaScript is for Google Analytics (which btw, seems to have broken with a recent site deploy... traffic halved suddenly 2 weeks ago) - Brett On 07/09/2007, at 5:25 PM, Lukas Theussl wrote: Hi, I just noticed that the site descriptors for the doxia (and maven) site contain a element, apparently to include a javascript snippet in all created site pages. I was not aware that this was possible, it's not mentioned anywhere in the docs and google didn't help me either. Problem is: 1st, it causes a bug that makes all maven generated pages invalid XHTML [1], and 2nd I have already told a user that it's illegal [also 1]. So question: should it be supported officially? If yes, whoever knows more, please document! :) -Lukas [1] http://jira.codehaus.org/browse/MSITE-230 -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
Re: [vote] release maven-verifier 1.1
On 6 Sep 07, at 11:46 PM 6 Sep 07, Insitu wrote: Jason van Zyl <[EMAIL PROTECTED]> writes: Hi, I would like to release the maven-verifier as it's used as part of Maven's integration tests and would like to stop using the snapshot in order to prepare for the 2.1-alpha-1. The staging area is here: http://people.apache.org/~jvanzyl/maven-verifier-1.1-staging- repository/ There are no JIRA issues in the shared component, it just needs to be released. Hello, Maybe I did it the wrong way, or maybe these issues are unimportant, but I filed recently two issues MNG-3135 and MNG-3143 that are, AFAICT, still open. I didn't see them there under the "integration test" component. I took a look and the patches have huge formatting changes so I'll pick out the salient parts and put them in for the next round. FWIW... Best regards, -- OQube < software engineering \ génie logiciel > Arnaud Bailly, Dr. \web> http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-verifier 1.1
Jason van Zyl <[EMAIL PROTECTED]> writes: > Hi, > > I would like to release the maven-verifier as it's used as part of > Maven's integration tests and would like to stop using the snapshot > in order to prepare for the 2.1-alpha-1. > > The staging area is here: > > http://people.apache.org/~jvanzyl/maven-verifier-1.1-staging-repository/ > > There are no JIRA issues in the shared component, it just needs to be > released. > Hello, Maybe I did it the wrong way, or maybe these issues are unimportant, but I filed recently two issues MNG-3135 and MNG-3143 that are, AFAICT, still open. FWIW... Best regards, -- OQube < software engineering \ génie logiciel > Arnaud Bailly, Dr. \web> http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
