Re: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
I did some further investigation. While there may be a memory leak, it could well be a case of it always having been there so that is worth separate investigation. I did hook yourkit up to it and didn't see anything in particular that might be a culprit. However, the reason I'm seeing the problem is this: http:// jira.codehaus.org/browse/MASSEMBLY-194 It's actually a functionality regression when you include unpacked dependencies in your assembly. A test project is attached that demonstrates it. It takes about 13s on 2.1, and 1m 30s on 2.2-beta-1 (and is triple the size on output). So, it looks like the 155 fix can go back in, but I think this regression needs fixing before release. Thanks! Cheers, Brett On 31/03/2007, at 11:40 AM, Brett Porter wrote: No dice :( I made sure to delete the copy from my local repo so it was downloaded again. I checked the build order, and you were right - the CCE blew it up before it got to the problem spot. I'll try and come up with a test case for you. - Brett On 31/03/2007, at 2:32 AM, John Casey wrote: Unfortunately, it wasn't that simple. I had actually combined two merges in a single commit to the beta-1 tag...a no-no, I know, but it's fixed now. I've put the newest deployment that excludes MASSEMBLY-155 out on my people.a.o acct, for your perusal. Let me know what you find out, and thanks for checking this so thoroughly. -john On 3/30/07, Brett Porter <[EMAIL PROTECTED]> wrote: On 31/03/2007, at 12:43 AM, John Casey wrote: > I'll try rolling out the MASSEMBLY-155 fix, just to see if that > makes a > difference. I can't imagine the ClassCastException fix or the file- > mode > processing chewing up much, though. > > Brett: Is it possible that you weren't running out of memory > previously > *because* of the CCE? I'd need to check the build order, but that's entirely possible - good point :) I'll try it again tomorrow - if you want to point me at a rev# to rollback I'm happy to do so to avoid you having to muck around with deployments. Thanks for your patience... Cheers, Brett - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
No dice :( I made sure to delete the copy from my local repo so it was downloaded again. I checked the build order, and you were right - the CCE blew it up before it got to the problem spot. I'll try and come up with a test case for you. - Brett On 31/03/2007, at 2:32 AM, John Casey wrote: Unfortunately, it wasn't that simple. I had actually combined two merges in a single commit to the beta-1 tag...a no-no, I know, but it's fixed now. I've put the newest deployment that excludes MASSEMBLY-155 out on my people.a.o acct, for your perusal. Let me know what you find out, and thanks for checking this so thoroughly. -john On 3/30/07, Brett Porter <[EMAIL PROTECTED]> wrote: On 31/03/2007, at 12:43 AM, John Casey wrote: > I'll try rolling out the MASSEMBLY-155 fix, just to see if that > makes a > difference. I can't imagine the ClassCastException fix or the file- > mode > processing chewing up much, though. > > Brett: Is it possible that you weren't running out of memory > previously > *because* of the CCE? I'd need to check the build order, but that's entirely possible - good point :) I'll try it again tomorrow - if you want to point me at a rev# to rollback I'm happy to do so to avoid you having to muck around with deployments. Thanks for your patience... Cheers, Brett - 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: confluence (was: We're near the release of 1.0 final)
On Mar 29, 2007, at 6:19 PM, Jeff Jensen wrote: Just not understanding yet the Maven plans for wiki/site usage. My fear, obviously, is continued "separate" works, as some people I helped with Maven have a "not happy-out-of- the-box experience", which includes scattered docs - I always have to give them multiple URLs for info and/or they keep Googling for answers. If you plan to integrate Maven site and the wiki so well like the examples you provided, then the user sees them as one source. Very nice. Just a note on this aspect too. I have a confluence client library which could be used in a plugin that automatically exports some or all of the confluence content for inclusion in other works -- releases, etc. Might be some other fun things you with the ability to easily read/write data from confluence. Some javadoc here: http://swizzle.codehaus.org/swizzle-confluence/ -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preparing for continuum-1.1-alpha-1
I'm ok for a timestamped version, but we can release the release manager too, without the plugin because it isn't ready and I want the new Maven-SCM in it. The pb is that release-manager use maven-scm 1.0-SNAPSHOT, we can use 1.0-beta-4 because the release manager doesn't use new code of maven-scm but we won't have maven-scm fixes. Or we can use a timestamped version of Maven-SCM too. If we choose the timestamped version of Maven-SCM, Continuum need to use it. Emmanuel Jesse McConnell a écrit : with maven-app-configuration released I thought we were well on our way to getting a release of continuum cut, but Emmanuel pointed out that I had missing the latest SNAPSHOT of the maven release stuff. Does anyone have an issues with my resolving the maven-release version to the latest timestamped snapshot version and cutting the release with that? jesse On 3/21/07, Jesse McConnell <[EMAIL PROTECTED]> wrote: All outstanding jira tickets that were under 1.1-alpha-1 have been resolved... I am going to put together the dependencies that need to be released and get those on track for release now and then we can stage and call a vote on the first alpha of continuum 1.1 jesse On 3/20/07, Brett Porter <[EMAIL PROTECTED]> wrote: > > On 20/03/2007, at 6:45 AM, Jesse McConnell wrote: > > > ok, I am changing my tune on the remaining 11 issues, I want this > > thing released asap so we have something concrete to get moving on. > > The 11 issues are functionally no real different then a lot of the > > ones in the -2 jira so I am thinking we just push that forward and get > > going on this. > > Sounds good to me. > > > > > so, I haven't actually pulled a release on something like this at > > apache, from what I understand we can put this someplace for > > downloading that doesn't have to get mirrored all over the place. > > more information please brett... > > We have, in the past, deployed alphas to the regular deployment > location. > > > > > Should we vote on this? I think we have an implict consent based on > > just this thread from committers but should this alpha cycle take a > > vote each push, or can we vote on a biweekly release schedule for > > alphas for the next month or two? > > Yes, if it's a release we should vote on it. > > > > > if we get this decided I'll arrange the dependencies and get this > > thing alpha release dealio running asap. > > Cool > > - Brett > -- jesse mcconnell [EMAIL PROTECTED]
Re: Preparing for continuum-1.1-alpha-1
with maven-app-configuration released I thought we were well on our way to getting a release of continuum cut, but Emmanuel pointed out that I had missing the latest SNAPSHOT of the maven release stuff. Does anyone have an issues with my resolving the maven-release version to the latest timestamped snapshot version and cutting the release with that? jesse On 3/21/07, Jesse McConnell <[EMAIL PROTECTED]> wrote: All outstanding jira tickets that were under 1.1-alpha-1 have been resolved... I am going to put together the dependencies that need to be released and get those on track for release now and then we can stage and call a vote on the first alpha of continuum 1.1 jesse On 3/20/07, Brett Porter <[EMAIL PROTECTED]> wrote: > > On 20/03/2007, at 6:45 AM, Jesse McConnell wrote: > > > ok, I am changing my tune on the remaining 11 issues, I want this > > thing released asap so we have something concrete to get moving on. > > The 11 issues are functionally no real different then a lot of the > > ones in the -2 jira so I am thinking we just push that forward and get > > going on this. > > Sounds good to me. > > > > > so, I haven't actually pulled a release on something like this at > > apache, from what I understand we can put this someplace for > > downloading that doesn't have to get mirrored all over the place. > > more information please brett... > > We have, in the past, deployed alphas to the regular deployment > location. > > > > > Should we vote on this? I think we have an implict consent based on > > just this thread from committers but should this alpha cycle take a > > vote each push, or can we vote on a biweekly release schedule for > > alphas for the next month or two? > > Yes, if it's a release we should vote on it. > > > > > if we get this decided I'll arrange the dependencies and get this > > thing alpha release dealio running asap. > > Cool > > - Brett > -- jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: [vote] maven-app-configuration and maven-shared-component parent release
passed with 6 binding (jmcconnell, bporter, oching, evenisse, jdcasey, and jerdfelt) I'll copy these out and get the continuum alpha 1 release prepared for a vote jesse On 3/28/07, Jesse McConnell <[EMAIL PROTECTED]> wrote: ok, I redid the release using the parent version of 7 so if its ok with folks I would like to just keep this vote ongoing...the only difference is the 8->7 in the parent version I republished the artifacts to the same directory and smoked the old ones, thanks for noticing that dennis jesse On 3/28/07, Jesse McConnell <[EMAIL PROTECTED]> wrote: > oh oh, I see, that was the old artifact name...nevermind on the parent > part then, I'll fix that up and point it to 7 then > > jesse > > On 3/28/07, Jesse McConnell <[EMAIL PROTECTED]> wrote: > > has that been pushed out anywhere? > > > > http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/shared/shared-components-parent/ > > > > I only see up to 2 there... > > > > On 3/28/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > > > Jesse McConnell wrote: > > > > As part of the prepwork for getting an actual continuum alpha release > > > > out I need to get a few more dependencies released, one of them is the > > > > maven-app-configuration. And since the currently released parent > > > > version is out of date with regards to the new release setup I have to > > > > release that as well. > > > > > > Jesse, > > > > > > Before I released maven-plugin-tools I released > > > maven-shared-components-7, on March 9. I can't see what is missing from > > > that version. Do you really need a version 8? > > > > > > > Tags: > > > > https://svn.apache.org/repos/asf/maven/shared/tags/maven-app-configuration-1.0 > > > > > > > > > > > > Staged at: > > > > http://people.apache.org/~jmcconnell/org/apache/maven/shared/ > > > > > > > > This would be an initial release of these fairly simple components, > > > > they are primarily to bring some unity in configuration elements > > > > between archiva and continuum right now. > > > > > > > > Vote is open for 72 hours. > > > > > > > > +1 > > > > > > > > > > > > > -- > > > Dennis Lundberg > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > jesse mcconnell > > [EMAIL PROTECTED] > > > > > -- > jesse mcconnell > [EMAIL PROTECTED] > -- jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: confluence
There are some issues with autoexport, you guys might want to take a peek at the HokeyPokey's exportspace command: http://svn.apache.org/repos/asf/geronimo/sandbox/hokeypokey/trunk/ Its still a work in progress, but it basically exports a space via xmlrpc and applies a velocity template and then does some massaging of urls. Currently the massaging is hardcoded... the rules need to be externalized. And the multi-space exporter needs to be hooked up too. But, the idea is to have a regular cron job execute the exporter using templates and resources that are checked into svn, which makes it easier to manage and allows for better oversight of template changes. And by using this method pages with dynamic tags (like include or jiraissues, etc) will also get refreshed. Anyways... its a work in progress, but worth a look if you are just getting started. --jason On Mar 30, 2007, at 12:19 PM, Jason van Zyl wrote: On 30 Mar 07, at 3:06 PM 30 Mar 07, Emmanuel Venisse wrote: Jason van Zyl a écrit : On 30 Mar 07, at 10:49 AM 30 Mar 07, Brett Porter wrote: While you make plenty of valid points about Contegix, it's completely unrelated to what I'm arguing for. How is starting to move things away from Contegix, which is you suggestion, not related? The subsequent argument would then be made that we already started this process so why not move the rest. Of course it's related. If you are successful in bringing them in to the ASF infrastructure as you've proposed, it should be a no-brainer to move a cwiki space to that infrastructure. So that's a non-issue as far as this discussion is concerned. We're better off on cwiki than where we are now. We have no admin privileges (I'm currently locked out of editing the CONTINUUM space) Did you ask? I asked Ben for JIRA privs and that took 5 minutes. , and the setup is not conducive to deploying into the Apache site. cwiki is already running the stuff we need. People I trust recommend it. The stuff is a plugin which can be installed in any Confluence instance. So that's not an onerous task. We've wanted to do this for months, and this is an avenue that actually makes it easier for us - I continue to suggest we take it. I'm simply not in favour of moving anything away from Contegix. Taking the output from the export plugin and scp'ing it to people is not hard either. If Ben is ok to install the plugin and if we can manage the scp to people, it's ok for me. But I don't know how we'll can manage it, we don't have shell access to codehaus. The plugin will be installed and the PMC will have access: http://jira.codehaus.org/browse/HAUS-1489 Jason. Emmanuel Jason. - Brett On 31/03/2007, at 12:23 AM, Jason van Zyl wrote: On 28 Mar 07, at 5:22 PM 28 Mar 07, Brett Porter wrote: (moving to main dev list as scope has increased) On 29/03/2007, at 12:28 AM, Jason van Zyl wrote: Similar to what Emmanuel suggested, how about we move *all* the current spaces to cwiki, avoiding any further fragmentation, and in fact removing the current fragmentation between the apache site and the codehaus confluence, as well as getting all of the above benefits? Before biting the bullet we can do a trial with this single SCM page. What do folks think? I think it's a bad idea to move from a stable setup we have with great support from people who have helped us at every turn. I would like to suggest we stay with Contegix wherever possible and this discussion is still ongoing with infra and they have yet to get back with SLA policies. I believe it is in the best interest of users and the community to provide the best infrastructure as possible and there is no doubt in my mind that is Contegix. For anything we have ever done for JIRA, Confluence or the Central Repository they have been there for us. We gain nothing by moving any of this to Apache. Contegix has run JIRA and Confluence for us when these services were not available at Apache and they have been more than accommodating when we needed a new repository infrastructure. I have been trying to incorporate Contegix officially into the infrastructure at Apache so that we can keep everyone happy. I am not willing, nor do I support any move to Apache without infra deciding their policies, nor am I overly excited about the possibility of any of our infrastructure being moved to a place where no one is really accountable. Contegix is responsible, accountable, a pleasure to work with and they have bent over backward to help us. We are relying on Jeff Turner who is already overworked in trying to manage our setup whereas at Contegix we have a team who are very knowledgeable about Atlassian products because they resell them. We also have people here who's first response is a derisive comment about the tools we use. My vote is for Contegix to continue the great job they have done and seeing as infra h
Re: confluence
On 30 Mar 07, at 3:06 PM 30 Mar 07, Emmanuel Venisse wrote: Jason van Zyl a écrit : On 30 Mar 07, at 10:49 AM 30 Mar 07, Brett Porter wrote: While you make plenty of valid points about Contegix, it's completely unrelated to what I'm arguing for. How is starting to move things away from Contegix, which is you suggestion, not related? The subsequent argument would then be made that we already started this process so why not move the rest. Of course it's related. If you are successful in bringing them in to the ASF infrastructure as you've proposed, it should be a no-brainer to move a cwiki space to that infrastructure. So that's a non-issue as far as this discussion is concerned. We're better off on cwiki than where we are now. We have no admin privileges (I'm currently locked out of editing the CONTINUUM space) Did you ask? I asked Ben for JIRA privs and that took 5 minutes. , and the setup is not conducive to deploying into the Apache site. cwiki is already running the stuff we need. People I trust recommend it. The stuff is a plugin which can be installed in any Confluence instance. So that's not an onerous task. We've wanted to do this for months, and this is an avenue that actually makes it easier for us - I continue to suggest we take it. I'm simply not in favour of moving anything away from Contegix. Taking the output from the export plugin and scp'ing it to people is not hard either. If Ben is ok to install the plugin and if we can manage the scp to people, it's ok for me. But I don't know how we'll can manage it, we don't have shell access to codehaus. The plugin will be installed and the PMC will have access: http://jira.codehaus.org/browse/HAUS-1489 Jason. Emmanuel Jason. - Brett On 31/03/2007, at 12:23 AM, Jason van Zyl wrote: On 28 Mar 07, at 5:22 PM 28 Mar 07, Brett Porter wrote: (moving to main dev list as scope has increased) On 29/03/2007, at 12:28 AM, Jason van Zyl wrote: Similar to what Emmanuel suggested, how about we move *all* the current spaces to cwiki, avoiding any further fragmentation, and in fact removing the current fragmentation between the apache site and the codehaus confluence, as well as getting all of the above benefits? Before biting the bullet we can do a trial with this single SCM page. What do folks think? I think it's a bad idea to move from a stable setup we have with great support from people who have helped us at every turn. I would like to suggest we stay with Contegix wherever possible and this discussion is still ongoing with infra and they have yet to get back with SLA policies. I believe it is in the best interest of users and the community to provide the best infrastructure as possible and there is no doubt in my mind that is Contegix. For anything we have ever done for JIRA, Confluence or the Central Repository they have been there for us. We gain nothing by moving any of this to Apache. Contegix has run JIRA and Confluence for us when these services were not available at Apache and they have been more than accommodating when we needed a new repository infrastructure. I have been trying to incorporate Contegix officially into the infrastructure at Apache so that we can keep everyone happy. I am not willing, nor do I support any move to Apache without infra deciding their policies, nor am I overly excited about the possibility of any of our infrastructure being moved to a place where no one is really accountable. Contegix is responsible, accountable, a pleasure to work with and they have bent over backward to help us. We are relying on Jeff Turner who is already overworked in trying to manage our setup whereas at Contegix we have a team who are very knowledgeable about Atlassian products because they resell them. We also have people here who's first response is a derisive comment about the tools we use. My vote is for Contegix to continue the great job they have done and seeing as infra has not decided anything or contacted me after I attended the last board meeting, I am going to go ahead with an official proposal starting with our PMC to let each PMC decide on their infrastructure needs and use whomever they like working on the integration strategies and policies that will make everyone comfortable. Until that time I don't think it's prudent because you will potentially jeopardize the infrastructure used by everyone using Maven. Jason. Cheers, Brett -- --- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For addit
Re: confluence
Jason van Zyl a écrit : On 30 Mar 07, at 10:49 AM 30 Mar 07, Brett Porter wrote: While you make plenty of valid points about Contegix, it's completely unrelated to what I'm arguing for. How is starting to move things away from Contegix, which is you suggestion, not related? The subsequent argument would then be made that we already started this process so why not move the rest. Of course it's related. If you are successful in bringing them in to the ASF infrastructure as you've proposed, it should be a no-brainer to move a cwiki space to that infrastructure. So that's a non-issue as far as this discussion is concerned. We're better off on cwiki than where we are now. We have no admin privileges (I'm currently locked out of editing the CONTINUUM space) Did you ask? I asked Ben for JIRA privs and that took 5 minutes. , and the setup is not conducive to deploying into the Apache site. cwiki is already running the stuff we need. People I trust recommend it. The stuff is a plugin which can be installed in any Confluence instance. So that's not an onerous task. We've wanted to do this for months, and this is an avenue that actually makes it easier for us - I continue to suggest we take it. I'm simply not in favour of moving anything away from Contegix. Taking the output from the export plugin and scp'ing it to people is not hard either. If Ben is ok to install the plugin and if we can manage the scp to people, it's ok for me. But I don't know how we'll can manage it, we don't have shell access to codehaus. Emmanuel Jason. - Brett On 31/03/2007, at 12:23 AM, Jason van Zyl wrote: On 28 Mar 07, at 5:22 PM 28 Mar 07, Brett Porter wrote: (moving to main dev list as scope has increased) On 29/03/2007, at 12:28 AM, Jason van Zyl wrote: Similar to what Emmanuel suggested, how about we move *all* the current spaces to cwiki, avoiding any further fragmentation, and in fact removing the current fragmentation between the apache site and the codehaus confluence, as well as getting all of the above benefits? Before biting the bullet we can do a trial with this single SCM page. What do folks think? I think it's a bad idea to move from a stable setup we have with great support from people who have helped us at every turn. I would like to suggest we stay with Contegix wherever possible and this discussion is still ongoing with infra and they have yet to get back with SLA policies. I believe it is in the best interest of users and the community to provide the best infrastructure as possible and there is no doubt in my mind that is Contegix. For anything we have ever done for JIRA, Confluence or the Central Repository they have been there for us. We gain nothing by moving any of this to Apache. Contegix has run JIRA and Confluence for us when these services were not available at Apache and they have been more than accommodating when we needed a new repository infrastructure. I have been trying to incorporate Contegix officially into the infrastructure at Apache so that we can keep everyone happy. I am not willing, nor do I support any move to Apache without infra deciding their policies, nor am I overly excited about the possibility of any of our infrastructure being moved to a place where no one is really accountable. Contegix is responsible, accountable, a pleasure to work with and they have bent over backward to help us. We are relying on Jeff Turner who is already overworked in trying to manage our setup whereas at Contegix we have a team who are very knowledgeable about Atlassian products because they resell them. We also have people here who's first response is a derisive comment about the tools we use. My vote is for Contegix to continue the great job they have done and seeing as infra has not decided anything or contacted me after I attended the last board meeting, I am going to go ahead with an official proposal starting with our PMC to let each PMC decide on their infrastructure needs and use whomever they like working on the integration strategies and policies that will make everyone comfortable. Until that time I don't think it's prudent because you will potentially jeopardize the infrastructure used by everyone using Maven. Jason. Cheers, Brett - 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] - 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: War plugin and Overlays handling
On 21 Mar 2007, at 07:04, Stephane Nicoll wrote: Hi, On 3/21/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: Will the use of this new overlay cause the transitive dependencies of the overlayed wars to be resolved and included? I currently construct wars that I intend to be used as overlays by excluding all the jars. I do this to avoid conflicts but also to reduce the size in the repository. Unfortunately because I'm using a very old version of mwar, I have to manually keep my war project dependencies synchronized. If these transitive dependencies from the wars are automatically pulled in, then I think it's safe to also exclude WEB-INF/lib by default from the overlays. I think we'll have an excellent solution at that point. The proposition sticks to a simple overlay which does not resolve the transitive dependencies, that's a very good point. We could even put a default exclude on WEB-INF/* for overlays that are not the current build (?). This will also solves the issues of people having multiple time the same dep with a different minor versions in the resulting war. Erm, does that not mean that all classes from other wars will be omitted? Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven-enforcer-plugin
I thought that the Maven version parsing takes the -xx as a build number? I'm internally reformatting the jdk version into something that Maven understands. -Original Message- From: Jerome Lacoste [mailto:[EMAIL PROTECTED] Sent: Friday, March 30, 2007 1:11 PM To: Maven Developers List Subject: Re: maven-enforcer-plugin On 3/30/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: > I know what changed, but not why it's broken yet. I changed the Java > rule a little to support the build number of java instead of just 3 > digits like before. The parsing is correct according to the unit > tests, but perhaps the version ranging isn't doing what I think. note that there's a difference between 1.5.0-07 and 1.5.0_07, maybe that's where your issue is ? J - 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: maven-enforcer-plugin
On 3/30/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: I know what changed, but not why it's broken yet. I changed the Java rule a little to support the build number of java instead of just 3 digits like before. The parsing is correct according to the unit tests, but perhaps the version ranging isn't doing what I think. note that there's a difference between 1.5.0-07 and 1.5.0_07, maybe that's where your issue is ? J - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
Unfortunately, it wasn't that simple. I had actually combined two merges in a single commit to the beta-1 tag...a no-no, I know, but it's fixed now. I've put the newest deployment that excludes MASSEMBLY-155 out on my people.a.o acct, for your perusal. Let me know what you find out, and thanks for checking this so thoroughly. -john On 3/30/07, Brett Porter <[EMAIL PROTECTED]> wrote: On 31/03/2007, at 12:43 AM, John Casey wrote: > I'll try rolling out the MASSEMBLY-155 fix, just to see if that > makes a > difference. I can't imagine the ClassCastException fix or the file- > mode > processing chewing up much, though. > > Brett: Is it possible that you weren't running out of memory > previously > *because* of the CCE? I'd need to check the build order, but that's entirely possible - good point :) I'll try it again tomorrow - if you want to point me at a rev# to rollback I'm happy to do so to avoid you having to muck around with deployments. Thanks for your patience... Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.6
On 30 Mar 07, at 12:16 PM 30 Mar 07, Emmanuel Venisse wrote:
Jason van Zyl a écrit :
On 30 Mar 07, at 10:33 AM 30 Mar 07, Brett Porter wrote:
Two problems have been found:
- the maven root POM contains '2.0.6-SNAPSHOT' as the
maven.version, which will probably filter in incorrectly and hose
any transitive dependencies. That'll need to be fixed.
That's fixed, I didn't notice because the release plugin must not
be using the resolved model. I thought it did both in order to
catch properties which are used in depMan.
What was the pb? which property?
The release plugin isn't smart enough to know that a property is
being used a version. You can't use ${project.version} as that
doesn't work because of a order of operations in the project builder.
So you have to 1) make sure you use the fully resolved project and
walk through dependencies and dependencyManagement to make sure there
are no SNAPSHOTs. That would have caught the problem I had, and 2)
You can to cycle through the properties to make sure there are no
snapshots there. Looking for SNAPSHOTs there would probably work
there. We have people working around things to have a single place to
define versions, but you have to look for now and have a work around
because I just released something with the plugin that's no
reproducible.
Jason.
I'll try to work on release plugin in few days and want to fix
problems on properties.
- as pointed out on IRC earlier, the plexus container used in
this release was not properly released - there are no source
jars, nor SVN tag, which is a worry for reproducibility.
There we go:
https://dav.codehaus.org/repository/plexus/org/codehaus/plexus/
plexus-container-default/1.0-alpha-9-stable-1/
These are only deployment issues - can we get them corrected
before sending it wild?
- Brett
On 27/03/2007, at 12:55 PM, Jason van Zyl wrote:
Hi,
The roadmap is here:
http://jira.codehaus.org/secure/IssueNavigator.jspa?
reset=true&pid=10500&fixfor=13010
The tag is here:
http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.6/
Staging repository:
http://people.apache.org/~jvanzyl/staging-repository/maven-2.0.6/
And the distros you are interested in are here:
http://people.apache.org/~jvanzyl/staging-repository/maven-2.0.6/
org/apache/maven/maven-core/2.0.6/
Thanks,
Jason.
---
--
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]
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: confluence (was: We're near the release of 1.0 final)
On 30 Mar 07, at 10:49 AM 30 Mar 07, Brett Porter wrote: While you make plenty of valid points about Contegix, it's completely unrelated to what I'm arguing for. How is starting to move things away from Contegix, which is you suggestion, not related? The subsequent argument would then be made that we already started this process so why not move the rest. Of course it's related. If you are successful in bringing them in to the ASF infrastructure as you've proposed, it should be a no-brainer to move a cwiki space to that infrastructure. So that's a non-issue as far as this discussion is concerned. We're better off on cwiki than where we are now. We have no admin privileges (I'm currently locked out of editing the CONTINUUM space) Did you ask? I asked Ben for JIRA privs and that took 5 minutes. , and the setup is not conducive to deploying into the Apache site. cwiki is already running the stuff we need. People I trust recommend it. The stuff is a plugin which can be installed in any Confluence instance. So that's not an onerous task. We've wanted to do this for months, and this is an avenue that actually makes it easier for us - I continue to suggest we take it. I'm simply not in favour of moving anything away from Contegix. Taking the output from the export plugin and scp'ing it to people is not hard either. Jason. - Brett On 31/03/2007, at 12:23 AM, Jason van Zyl wrote: On 28 Mar 07, at 5:22 PM 28 Mar 07, Brett Porter wrote: (moving to main dev list as scope has increased) On 29/03/2007, at 12:28 AM, Jason van Zyl wrote: Similar to what Emmanuel suggested, how about we move *all* the current spaces to cwiki, avoiding any further fragmentation, and in fact removing the current fragmentation between the apache site and the codehaus confluence, as well as getting all of the above benefits? Before biting the bullet we can do a trial with this single SCM page. What do folks think? I think it's a bad idea to move from a stable setup we have with great support from people who have helped us at every turn. I would like to suggest we stay with Contegix wherever possible and this discussion is still ongoing with infra and they have yet to get back with SLA policies. I believe it is in the best interest of users and the community to provide the best infrastructure as possible and there is no doubt in my mind that is Contegix. For anything we have ever done for JIRA, Confluence or the Central Repository they have been there for us. We gain nothing by moving any of this to Apache. Contegix has run JIRA and Confluence for us when these services were not available at Apache and they have been more than accommodating when we needed a new repository infrastructure. I have been trying to incorporate Contegix officially into the infrastructure at Apache so that we can keep everyone happy. I am not willing, nor do I support any move to Apache without infra deciding their policies, nor am I overly excited about the possibility of any of our infrastructure being moved to a place where no one is really accountable. Contegix is responsible, accountable, a pleasure to work with and they have bent over backward to help us. We are relying on Jeff Turner who is already overworked in trying to manage our setup whereas at Contegix we have a team who are very knowledgeable about Atlassian products because they resell them. We also have people here who's first response is a derisive comment about the tools we use. My vote is for Contegix to continue the great job they have done and seeing as infra has not decided anything or contacted me after I attended the last board meeting, I am going to go ahead with an official proposal starting with our PMC to let each PMC decide on their infrastructure needs and use whomever they like working on the integration strategies and policies that will make everyone comfortable. Until that time I don't think it's prudent because you will potentially jeopardize the infrastructure used by everyone using Maven. Jason. Cheers, Brett - 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] - 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 2.0.6
Jason van Zyl a écrit : On 30 Mar 07, at 10:33 AM 30 Mar 07, Brett Porter wrote: Two problems have been found: - the maven root POM contains '2.0.6-SNAPSHOT' as the maven.version, which will probably filter in incorrectly and hose any transitive dependencies. That'll need to be fixed. That's fixed, I didn't notice because the release plugin must not be using the resolved model. I thought it did both in order to catch properties which are used in depMan. What was the pb? which property? I'll try to work on release plugin in few days and want to fix problems on properties. - as pointed out on IRC earlier, the plexus container used in this release was not properly released - there are no source jars, nor SVN tag, which is a worry for reproducibility. There we go: https://dav.codehaus.org/repository/plexus/org/codehaus/plexus/plexus-container-default/1.0-alpha-9-stable-1/ These are only deployment issues - can we get them corrected before sending it wild? - Brett On 27/03/2007, at 12:55 PM, Jason van Zyl wrote: Hi, The roadmap is here: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&fixfor=13010 The tag is here: http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.6/ Staging repository: http://people.apache.org/~jvanzyl/staging-repository/maven-2.0.6/ And the distros you are interested in are here: http://people.apache.org/~jvanzyl/staging-repository/maven-2.0.6/org/apache/maven/maven-core/2.0.6/ Thanks, Jason. - 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] - 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 2.0.6
On 30 Mar 07, at 10:33 AM 30 Mar 07, Brett Porter wrote: Two problems have been found: - the maven root POM contains '2.0.6-SNAPSHOT' as the maven.version, which will probably filter in incorrectly and hose any transitive dependencies. That'll need to be fixed. That's fixed, I didn't notice because the release plugin must not be using the resolved model. I thought it did both in order to catch properties which are used in depMan. - as pointed out on IRC earlier, the plexus container used in this release was not properly released - there are no source jars, nor SVN tag, which is a worry for reproducibility. There we go: https://dav.codehaus.org/repository/plexus/org/codehaus/plexus/plexus- container-default/1.0-alpha-9-stable-1/ These are only deployment issues - can we get them corrected before sending it wild? - Brett On 27/03/2007, at 12:55 PM, Jason van Zyl wrote: Hi, The roadmap is here: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=true&pid=10500&fixfor=13010 The tag is here: http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.6/ Staging repository: http://people.apache.org/~jvanzyl/staging-repository/maven-2.0.6/ And the distros you are interested in are here: http://people.apache.org/~jvanzyl/staging-repository/maven-2.0.6/ org/apache/maven/maven-core/2.0.6/ Thanks, Jason. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Maven PMC welcomes Brian Fox
Woo Hoo! Another binding voter!:-) Congrats! Dan On Thursday 29 March 2007 21:21, Brett Porter wrote: > Hi all, > > The Maven PMC has voted to add Brian Fox to the PMC. Please > join me in welcoming him! > > Cheers, > Brett > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Splitting the stable and unstable repositories
On 30 Mar 07, at 10:41 AM 30 Mar 07, Brett Porter wrote: On 31/03/2007, at 12:09 AM, Jason van Zyl wrote: This would not be a concept change in Maven (at least, yet - it could be something to consider in the versioning in future): it's simply two types of release repositories. The stable one would be included in Maven by default, the unstable/pre-release one would not. You'd have to add the repository to your project. -1 Ok - having reflected on this, I still believe in the concept but agree that it won't be practical without first making it easier to declare your repositories without all the extra work that is required now. It's already complicated enough and I think we should, in fact, go the other way and put a default SNAPSHOT repository in the process by default so that thousands of people don't have diddle POMs all the time. No real objections here. So in summary, more default repositories definitions not more types of repositories. I'm not sure that's a fair summary. Specifying your repositories globally needs to be simpler, trying to shove everything (especially snapshots) through central is impractical. In a separate repository that's pulled in by all the syncing partners? Why is that impractical? It would make it an order of magnitude easier for users. Again the onus is on us. But syncing the snapshot repos is no harder then syncing the production repositories and the new central repo machine has very large disks. Put a default snapshot repository on central, find some reasonable eviction policy and make day-to-day use easier. Also make the specification of the plugin version to bring that into common pattern that is the same for dependencies. +1 on both easier day to day use and locking down versions. - Brett - 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: [discuss] Splitting the stable and unstable repositories
Not entirely sure I agree with this point. Another level of complexity to get round this issue? surely if folk have any problems they can use dependencyManagement and pluginManagement to solve the same issue? I know plenty of folk who barely know why to separate snapshot from release repositories, I think adding another split will just raise the bar of easy adoption... Andy On 29 Mar 2007, at 00:46, Brett Porter wrote: Hi, I didn't want to pin the assembly plugin vote to this, but it seemed like a good opportunity to bring this up. I'd like to propose we split the stable repository from the unstable repository (which would be where alphas, betas and rcs get deployed), and make this a documented best practice. This would not be a concept change in Maven (at least, yet - it could be something to consider in the versioning in future): it's simply two types of release repositories. The stable one would be included in Maven by default, the unstable/pre-release one would not. You'd have to add the repository to your project. I would suggest this for future additions to central, but leave anything currently there in place for backwards compat. I think this is a good all round concept, but there is a particular practical problem that we should do this for: unpinned plugin versions. In the specific example of the assembly plugin - if you don't request a version (ie, use latest release), or you said [2.1,), then you'll get the 2.2-beta-1 release which is presumably less stable than 2.1. The same rationalisation would apply to ranges used in any dependency, but thats the biggest use case I can think of that affects people today. It would allow us to do more regular test releases of the plugins. Thoughts? - Brett - 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] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
On 31/03/2007, at 12:43 AM, John Casey wrote: I'll try rolling out the MASSEMBLY-155 fix, just to see if that makes a difference. I can't imagine the ClassCastException fix or the file- mode processing chewing up much, though. Brett: Is it possible that you weren't running out of memory previously *because* of the CCE? I'd need to check the build order, but that's entirely possible - good point :) I'll try it again tomorrow - if you want to point me at a rev# to rollback I'm happy to do so to avoid you having to muck around with deployments. Thanks for your patience... Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: confluence (was: We're near the release of 1.0 final)
While you make plenty of valid points about Contegix, it's completely unrelated to what I'm arguing for. If you are successful in bringing them in to the ASF infrastructure as you've proposed, it should be a no-brainer to move a cwiki space to that infrastructure. So that's a non-issue as far as this discussion is concerned. We're better off on cwiki than where we are now. We have no admin privileges (I'm currently locked out of editing the CONTINUUM space), and the setup is not conducive to deploying into the Apache site. cwiki is already running the stuff we need. People I trust recommend it. We've wanted to do this for months, and this is an avenue that actually makes it easier for us - I continue to suggest we take it. - Brett On 31/03/2007, at 12:23 AM, Jason van Zyl wrote: On 28 Mar 07, at 5:22 PM 28 Mar 07, Brett Porter wrote: (moving to main dev list as scope has increased) On 29/03/2007, at 12:28 AM, Jason van Zyl wrote: Similar to what Emmanuel suggested, how about we move *all* the current spaces to cwiki, avoiding any further fragmentation, and in fact removing the current fragmentation between the apache site and the codehaus confluence, as well as getting all of the above benefits? Before biting the bullet we can do a trial with this single SCM page. What do folks think? I think it's a bad idea to move from a stable setup we have with great support from people who have helped us at every turn. I would like to suggest we stay with Contegix wherever possible and this discussion is still ongoing with infra and they have yet to get back with SLA policies. I believe it is in the best interest of users and the community to provide the best infrastructure as possible and there is no doubt in my mind that is Contegix. For anything we have ever done for JIRA, Confluence or the Central Repository they have been there for us. We gain nothing by moving any of this to Apache. Contegix has run JIRA and Confluence for us when these services were not available at Apache and they have been more than accommodating when we needed a new repository infrastructure. I have been trying to incorporate Contegix officially into the infrastructure at Apache so that we can keep everyone happy. I am not willing, nor do I support any move to Apache without infra deciding their policies, nor am I overly excited about the possibility of any of our infrastructure being moved to a place where no one is really accountable. Contegix is responsible, accountable, a pleasure to work with and they have bent over backward to help us. We are relying on Jeff Turner who is already overworked in trying to manage our setup whereas at Contegix we have a team who are very knowledgeable about Atlassian products because they resell them. We also have people here who's first response is a derisive comment about the tools we use. My vote is for Contegix to continue the great job they have done and seeing as infra has not decided anything or contacted me after I attended the last board meeting, I am going to go ahead with an official proposal starting with our PMC to let each PMC decide on their infrastructure needs and use whomever they like working on the integration strategies and policies that will make everyone comfortable. Until that time I don't think it's prudent because you will potentially jeopardize the infrastructure used by everyone using Maven. Jason. Cheers, Brett - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
I'll try rolling out the MASSEMBLY-155 fix, just to see if that makes a difference. I can't imagine the ClassCastException fix or the file-mode processing chewing up much, though. Brett: Is it possible that you weren't running out of memory previously *because* of the CCE? -john On 3/30/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: I imagine the fix for MASSEMBLY-155 might cause the archiver to use a little more memory. I would imagine though that if the excludes weren't used, the fix wouldn't have an impact. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Friday, March 30, 2007 1:36 AM To: Maven Developers List Subject: Re: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin John, I'm building a >100mb assembly and the build is blowing up with an OOME. I upped the limit to 128m and instead of that problem it completely hangs down the track (kill -9). I'm trying again with 256m now. If I build with 2.1 again, there are no problems. I am able to switch back and forth and get consistent results: dead with 2.2, fine with 2.1. Oddly, though, I had no such problems with 2.2 yesterday. Did anything change overnight that might leak memory? - Brett On 30/03/2007, at 3:50 AM, John Casey wrote: > This is the second attempt, after fixing: > > * http://jira.codehaus.org/browse/MASSEMBLY-155 > * http://jira.codehaus.org/browse/MASSEMBLY-192 > * [file and directory mode parsing] > > WRT mode parsing, everything is now parsed using Integer.parseInt > ( mode, 8 > ). If this results in a NumberFormatException, that is wrapped in an > AssemblyFormattingException that indicates that it was a file/dir > mode that > failed to parse. If the parse succeeds, the resulting mode int is > checked > for sanity. That is, cases where group|world have perms that the user > doesn't, or cases where world has perms that the group doesn't (as in, > user:rx, group:rwx, world: rx). This could still break builds where > a mode > is specified in decimal, but at least there should be some > indication of > what went wrong...and now they'll know that we're trying to do the > right > thing. Also, all of the mode parsing has been consolidated into > TypeConversionUtils, with a TypeConversionUtilsTest to check my work. > Finally, for MASSEMBLY-155, there is a new integration test that > verifies > its behavior. > > > So, let's try this again: > > I wanted to call a vote to release a beta version of the new assembly > plugin. There are still some outstanding issues (though not as many > as jira > would have you believe; they just need tests), but I think we're at > around > 95-99% backward compatibility and the new features seem to be > working well. > It's been just sitting in SVN for quite awhile now, and many people > are > using it directly from there. I'd like to provide better support > for those > people, and start getting more feedback on exactly what's still > broken. > > The change list is pretty large, but is mainly concerned with > refactoring > the plugin away from the old monolithic approach to one that uses > phases to > handle the different descriptor sections, along with common task > classes to > handle behavior shared between phases. > > Road Map: > > http://jira.codehaus.org/secure/ReleaseNote.jspa? > projectId=11126&styleName=Html&version=12617 > > > Tag: > > http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly- > plugin-2.2-beta-1 > > Staging repository: > > http://people.apache.org/~jdcasey/stage/repo people.apache.org/%7Ejdcasey/stage/repo> > > So, let's try 72h +1/+0/-1. Please cast your votes! > > Here's my +1. > > -john - 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: [discuss] Splitting the stable and unstable repositories
On 31/03/2007, at 12:09 AM, Jason van Zyl wrote: This would not be a concept change in Maven (at least, yet - it could be something to consider in the versioning in future): it's simply two types of release repositories. The stable one would be included in Maven by default, the unstable/pre-release one would not. You'd have to add the repository to your project. -1 Ok - having reflected on this, I still believe in the concept but agree that it won't be practical without first making it easier to declare your repositories without all the extra work that is required now. It's already complicated enough and I think we should, in fact, go the other way and put a default SNAPSHOT repository in the process by default so that thousands of people don't have diddle POMs all the time. No real objections here. So in summary, more default repositories definitions not more types of repositories. I'm not sure that's a fair summary. Specifying your repositories globally needs to be simpler, trying to shove everything (especially snapshots) through central is impractical. Put a default snapshot repository on central, find some reasonable eviction policy and make day-to-day use easier. Also make the specification of the plugin version to bring that into common pattern that is the same for dependencies. +1 on both easier day to day use and locking down versions. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.6
Two problems have been found: - the maven root POM contains '2.0.6-SNAPSHOT' as the maven.version, which will probably filter in incorrectly and hose any transitive dependencies. That'll need to be fixed. - as pointed out on IRC earlier, the plexus container used in this release was not properly released - there are no source jars, nor SVN tag, which is a worry for reproducibility. These are only deployment issues - can we get them corrected before sending it wild? - Brett On 27/03/2007, at 12:55 PM, Jason van Zyl wrote: Hi, The roadmap is here: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=true&pid=10500&fixfor=13010 The tag is here: http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.6/ Staging repository: http://people.apache.org/~jvanzyl/staging-repository/maven-2.0.6/ And the distros you are interested in are here: http://people.apache.org/~jvanzyl/staging-repository/maven-2.0.6/ org/apache/maven/maven-core/2.0.6/ Thanks, Jason. - 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: confluence (was: We're near the release of 1.0 final)
On 28 Mar 07, at 5:22 PM 28 Mar 07, Brett Porter wrote: (moving to main dev list as scope has increased) On 29/03/2007, at 12:28 AM, Jason van Zyl wrote: Similar to what Emmanuel suggested, how about we move *all* the current spaces to cwiki, avoiding any further fragmentation, and in fact removing the current fragmentation between the apache site and the codehaus confluence, as well as getting all of the above benefits? Before biting the bullet we can do a trial with this single SCM page. What do folks think? I think it's a bad idea to move from a stable setup we have with great support from people who have helped us at every turn. I would like to suggest we stay with Contegix wherever possible and this discussion is still ongoing with infra and they have yet to get back with SLA policies. I believe it is in the best interest of users and the community to provide the best infrastructure as possible and there is no doubt in my mind that is Contegix. For anything we have ever done for JIRA, Confluence or the Central Repository they have been there for us. We gain nothing by moving any of this to Apache. Contegix has run JIRA and Confluence for us when these services were not available at Apache and they have been more than accommodating when we needed a new repository infrastructure. I have been trying to incorporate Contegix officially into the infrastructure at Apache so that we can keep everyone happy. I am not willing, nor do I support any move to Apache without infra deciding their policies, nor am I overly excited about the possibility of any of our infrastructure being moved to a place where no one is really accountable. Contegix is responsible, accountable, a pleasure to work with and they have bent over backward to help us. We are relying on Jeff Turner who is already overworked in trying to manage our setup whereas at Contegix we have a team who are very knowledgeable about Atlassian products because they resell them. We also have people here who's first response is a derisive comment about the tools we use. My vote is for Contegix to continue the great job they have done and seeing as infra has not decided anything or contacted me after I attended the last board meeting, I am going to go ahead with an official proposal starting with our PMC to let each PMC decide on their infrastructure needs and use whomever they like working on the integration strategies and policies that will make everyone comfortable. Until that time I don't think it's prudent because you will potentially jeopardize the infrastructure used by everyone using Maven. Jason. Cheers, Brett - 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: [discuss] Splitting the stable and unstable repositories
Jason said: I'm far more in favor of hosting a default snapshot repository on central and forcing plugin versions in 2.1. This creates far more stability and puts the onus on us to make finding that version for first time use easy. Not specifying a version for a plugin is not predictable as clearly shown with the last release of the surefire. If I had to specify surefire 2.2 then trunk would not have broken, or the 2.0.x branch. I think we should be striving for ease of use and stability. --- I agree 100%. Anyone concerned about reproducibility would never allow the plugins to be unversioned in their builds. For my corp builds, it's as if this feature never existed...everything is in pluginMgt. I think if we are to encourage best practices, requiring a version somewhere, either in the plugin definition or pluginManagement is the right thing to do. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Splitting the stable and unstable repositories
On 28 Mar 07, at 7:46 PM 28 Mar 07, Brett Porter wrote: Hi, I didn't want to pin the assembly plugin vote to this, but it seemed like a good opportunity to bring this up. I'd like to propose we split the stable repository from the unstable repository (which would be where alphas, betas and rcs get deployed), and make this a documented best practice. I don't see the value in this at all. A release is already from distinguished, and to add another layer of meaning to this adds more complexity and will be a source of great confusion. This would not be a concept change in Maven (at least, yet - it could be something to consider in the versioning in future): it's simply two types of release repositories. The stable one would be included in Maven by default, the unstable/pre-release one would not. You'd have to add the repository to your project. -1 It's already complicated enough and I think we should, in fact, go the other way and put a default SNAPSHOT repository in the process by default so that thousands of people don't have diddle POMs all the time. The anti pattern we have now when switching to a snapshot is having to add the snapshot repository definition. When you move to a release if you wanted to be accurate you would remove the snapshot repository entry. If you're lazy, like most people, then you just leave the definition in there anyway. So some of the time the list of repositories is accurate, sometimes not. We should just put the snapshot repository in by default and find better ways of distinguishing the use of snapshots or various levels of quality with metadata. We're already making this harder for users and adding another layer to this would be crazy. People would have to go look in different repositories and have to define yet another repository entry, that's just so inconvenient. I would suggest this for future additions to central, but leave anything currently there in place for backwards compat. Having separate repositories is fine for manageability but having to diddle POMs all the time is very annoying especially for day-to-day use. I think anyone experiencing the pain of this would not want this. Case in point is building trunk and building and deploying a snapshot locally and deploying it and then a build not working because I didn't put in a snapshot repository. It's an asymmetry that really makes no sense and is a great source of irritation and often leads to builds that don't work out of the box because of this asymmetry. I think this is a good all round concept, but there is a particular practical problem that we should do this for: unpinned plugin versions. In the specific example of the assembly plugin - if you don't request a version (ie, use latest release), or you said [2.1,), then you'll get the 2.2-beta-1 release which is presumably less stable than 2.1. The same rationalisation would apply to ranges used in any dependency, but thats the biggest use case I can think of that affects people today. It would allow us to do more regular test releases of the plugins. Thoughts? I think this is a not a good idea. We should make this easier for users not harder. And for plugins in 2.1 we should make people specify versions and again restore symmetry in the use pluginManagement like dependencyManagement as well as turning off any automatic updates. Many things were not working as a result of magically finding the last release, the plugin registry being the biggest culprit but users can specify versions for plugins as they very accustom to this and the same management techniques can be used. Anyone who wants a reliable build is doing this already. I'm far more in favor of hosting a default snapshot repository on central and forcing plugin versions in 2.1. This creates far more stability and puts the onus on us to make finding that version for first time use easy. Not specifying a version for a plugin is not predictable as clearly shown with the last release of the surefire. If I had to specify surefire 2.2 then trunk would not have broken, or the 2.0.x branch. I think we should be striving for ease of use and stability. So in summary, more default repositories definitions not more types of repositories. Put a default snapshot repository on central, find some reasonable eviction policy and make day-to-day use easier. Also make the specification of the plugin version to bring that into common pattern that is the same for dependencies. Jason. - Brett - 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] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
I imagine the fix for MASSEMBLY-155 might cause the archiver to use a little more memory. I would imagine though that if the excludes weren't used, the fix wouldn't have an impact. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Friday, March 30, 2007 1:36 AM To: Maven Developers List Subject: Re: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin John, I'm building a >100mb assembly and the build is blowing up with an OOME. I upped the limit to 128m and instead of that problem it completely hangs down the track (kill -9). I'm trying again with 256m now. If I build with 2.1 again, there are no problems. I am able to switch back and forth and get consistent results: dead with 2.2, fine with 2.1. Oddly, though, I had no such problems with 2.2 yesterday. Did anything change overnight that might leak memory? - Brett On 30/03/2007, at 3:50 AM, John Casey wrote: > This is the second attempt, after fixing: > > * http://jira.codehaus.org/browse/MASSEMBLY-155 > * http://jira.codehaus.org/browse/MASSEMBLY-192 > * [file and directory mode parsing] > > WRT mode parsing, everything is now parsed using Integer.parseInt > ( mode, 8 > ). If this results in a NumberFormatException, that is wrapped in an > AssemblyFormattingException that indicates that it was a file/dir > mode that > failed to parse. If the parse succeeds, the resulting mode int is > checked > for sanity. That is, cases where group|world have perms that the user > doesn't, or cases where world has perms that the group doesn't (as in, > user:rx, group:rwx, world: rx). This could still break builds where > a mode > is specified in decimal, but at least there should be some > indication of > what went wrong...and now they'll know that we're trying to do the > right > thing. Also, all of the mode parsing has been consolidated into > TypeConversionUtils, with a TypeConversionUtilsTest to check my work. > Finally, for MASSEMBLY-155, there is a new integration test that > verifies > its behavior. > > > So, let's try this again: > > I wanted to call a vote to release a beta version of the new assembly > plugin. There are still some outstanding issues (though not as many > as jira > would have you believe; they just need tests), but I think we're at > around > 95-99% backward compatibility and the new features seem to be > working well. > It's been just sitting in SVN for quite awhile now, and many people > are > using it directly from there. I'd like to provide better support > for those > people, and start getting more feedback on exactly what's still > broken. > > The change list is pretty large, but is mainly concerned with > refactoring > the plugin away from the old monolithic approach to one that uses > phases to > handle the different descriptor sections, along with common task > classes to > handle behavior shared between phases. > > Road Map: > > http://jira.codehaus.org/secure/ReleaseNote.jspa? > projectId=11126&styleName=Html&version=12617 > > > Tag: > > http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly- > plugin-2.2-beta-1 > > Staging repository: > > http://people.apache.org/~jdcasey/stage/repo people.apache.org/%7Ejdcasey/stage/repo> > > So, let's try 72h +1/+0/-1. Please cast your votes! > > Here's my +1. > > -john - 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: maven-enforcer-plugin
I know what changed, but not why it's broken yet. I changed the Java rule a little to support the build number of java instead of just 3 digits like before. The parsing is correct according to the unit tests, but perhaps the version ranging isn't doing what I think. -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon Sent: Friday, March 30, 2007 3:43 AM To: Maven Developers List Subject: Re: maven-enforcer-plugin I've no idea what is wrong... though I didn't look to hard. I rolled back Geronimo to use 1.0-alpha-1-20070328.035547-9 which is happy. Hopefully you can figure out whats hosed and publish a new snapshot so I can remove my hack. --jason On Mar 30, 2007, at 12:27 AM, Jason Dillon wrote: > Something is busted in the latest snapshot... > > I'm seeing: > > > [INFO] Detected Maven Version: 2.0.5 is allowed in the range [2.0.5,). > [WARNING] Rule 0: RequireJavaVersion failed with message: Detected > JDK Version: 1.5.0-07 is not in the allowed range [1.5,1.6). > > > java -version says: > > > java version "1.5.0_07" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164) > Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing) > > > Why is "1.5.0-07" not in this range "[1.5,1.6)"? > > The exact same configuration was working about 30 minutes ago > (before Mvn decided to refresh snapshots). > > * * * > > I'll look into it if I have time... but something is broken :-( > > --jason > > > On Mar 29, 2007, at 8:58 PM, Brian E. Fox wrote: > >> I reimplemented the enforcer plugin along the lines of Jason D's >> idea[1] >> and I think this is a much more extensible solution. The rules now >> implement a common interface in shared/maven-enforcer-rule-api and >> users >> will be able to inject their own custom rules. By defining the >> interface >> external to the plugin, the Lint idea that JVZ put out[2] should >> be able >> to invoke these rules, as will IDEs. >> >> Please take a look at the site to see how the plugin works and >> provide >> any suggestions. I still need to document how to create your own >> rules >> and inject them, but I believe everything else is covered. A >> snapshot of >> 1.0-alpha-1 has also been deployed for testing. (I believe >> Geronimo is >> already using it) >> >> http://maven.apache.org/plugins/maven-enforcer-plugin (just >> deployed, >> may take a while to refresh) >> >> [1] >> http://www.nabble.com/maven-enforcer-plugin- >> tf3431452s177.html#a9565974 >> [2] http://www.nabble.com/Maven-Lint-tf3462956s177.html#a9661545 >> >> -Original Message- >> From: Brian E. Fox [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, March 20, 2007 12:05 AM >> To: Maven Developers List >> Subject: maven-enforcer-plugin >> >> There is a new plugin that I'd like to get some feedback on, >> particularly on non-windows os's and the unit tests. >> >> >> >> The maven-enforcer-plugin picks up where leaves >> off and >> allows control over the maven, jdk and os versions of a build. >> >> >> >> This plugin was initially conceived here: >> >> http://www.nabble.com/Control-of-maven-using-prerequisites- >> tf3231437s177 >> .html#a8979318 >> >> And here: >> >> http://www.nabble.com/Why-is-prerequisites-not-inherited-- >> tf3236197s177. >> html#a9016296 >> >> >> >> 1.0-alpha-1-SNAPSHOT is deployed and the site is here: >> http://maven.apache.org/plugins/maven-enforcer-plugin/ (just >> deployed so >> give it a little bit to completely update) >> >> >> >> If all goes well and no major issues are uncovered, then I think it's >> ready for staging and a vote. >> >> >> >> Thanks, >> >> Brian >> >> >> >> >> >> >> >> >> >> >> - >> 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
