Re: Getting a 2.1 release happening
On 3 Sep 07, at 4:32 AM 3 Sep 07, Jason Dillon wrote: On Aug 31, 2007, at 8:58 AM, Brett Porter wrote: and the optional are: * java 5 annotations This would be swell :-) When is Maven slated for using Java 5 as the base JVM? Is that still for 2.2? Yoav has already agreed so we just need to look at the code, possibly grab a grant, and push it in. I tried it out and it works very well, already tested and used for quite awhile by Yoav. Yoav, you have anything to add? --jason - 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: Getting a 2.1 release happening
On Aug 31, 2007, at 8:58 AM, Brett Porter wrote: and the optional are: * java 5 annotations This would be swell :-) When is Maven slated for using Java 5 as the base JVM? Is that still for 2.2? --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting a 2.1 release happening
Brett Porter wrote: Hi, I'm looking to do a few things towards getting a 2.1 alpha out, and wanted to look towards getting 2.1 itself a bit nearer. It seems like we have too many things scheduled at the moment for 2.1, so here are a few bits I've been looking at and was going to start running through. Would be great to hear others thoughts. 1) 2.1-alpha-1 issues I would like to cut this back to just the following and start working on them: * current known regressions * integration test failures and move the rest to 2.1.x as the 2.1 sorting bucket Any objections? 2) 2.1 JIRA This has about 270 issues + a large number currently unreviewed again for us all to go through. I think it needs to be cut down dramatically - I'd say ~100 issues should be the target here. I would map it out as 2.1-alpha-2 thru alpha-4: the highest priority / most addressable / related issues from 2.1.x and the current 2.1-alpha-1, + the new features from the wiki. I think this should be all we plan for 2.1 at this point, and move on to feature-complete betas then. We'll also include stuff that gets addressed through 2.0.x of course, and anything else that someone gets an itch to fix or a patch lands for. Any objections? If others think this is the right approach, I'm happy to go through and produce a list of what I think should remain. I'd be happy to help out with this.. :) 3) New features I believe we should categorise these as: required for 2.1, optional for 2.1, and the rest as beyond 2.1. I think we should be particularly conservative to make sure a 2.1 release happens sooner. IMO, the required are: * decoupling maven-artifact (under way) * IT problems * shared build context (mostly done) * profile activators (mostly done) * repository mirroring (generally better ability to define repositories, even without the artifact resolution changes) * POM loading and building * Toolchains * Embedder * Plugin packs (depends on POM loading as currently defined) and the optional are: * java 5 annotations * conflict resolvers * artifact handling / artifact resolution spec * repository security * local repo separation * use StAX I'm also going over the rest of the wiki stuff to help finish up the things that still needed putting into the current layout and have a couple of other comments. I'll get back to that over the weekend. In my mind, I'd really like to see a realistic chance of 2.1 getting out this year, and planning to have 2 or 3 point releases next year, each spending time addressing the key issues people experience and those that get the most bang for our buck with the open JIRAs. Thoughts? Any volunteers? :) Cheers, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ Thanks, Deng - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Getting a 2.1 release happening
>As I noted before, if the ITs are reasonably under control with a way >for people to make them and submit them then I will cut alphas everyday. >Brian is pretty much done. Is that true Brian on the Archetype front? The archetypeNG plugin needs to be released before this is truly usable by our target audience. The instructions on the page [1] work with the current plugin code, but I wouldn't call that user friendly because of the snapshot repo requirement. However, the page [1] also shows how to get the existing sample project and make those changes. The end result of checking out and renaming this project and running the archetype plugin to create the IT project are the same. Therefor, I would say that with those instructions, it is easy to do and entirely reasonable to expect Its to be created. 1: http://docs.codehaus.org/display/MAVEN/Creating+a+Maven+Integration+Test --Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting a 2.1 release happening
Comments inlined 2007/8/31, Jason van Zyl <[EMAIL PROTECTED]>: > > > On 31 Aug 07, at 9:58 AM 31 Aug 07, Raphaël Piéroni wrote: > > > Hi guys, > > > > Could it be some work done on integrating archetypes for maven 2.1 ? > > > > Archetype should stand completely on its own. Should have nothing to > do with 2.1. Agree > What i am thinking about is to enhance the settings model to permit > > plugins to access some configuration when used without a project. > > > > Sure, that's fine but it should all be the same to the underlying > Archetype components. How the parameters get to Archetype is arbitrary. > > > Like the repositories defined in active profiles. > > Like plugin configuration like in project.build.plugins but only > > when called > > without a project. > > Like the list of archetype groups like for the plugins. > > > > So you're just asking for changes in Maven to make getting better > information to Archetype easier? Exactly > Is that premature (for maven 2.2+), or offtopic in this thread ? > > > > Some inlined comments follow. > > > > Regards > > > > Raphaël > > > > > > 2007/8/31, Jason van Zyl <[EMAIL PROTECTED]>: > >> > >> As I noted before, if the ITs are reasonably under control with a way > >> for people to make them and submit them then I will cut alphas > >> everyday. > >> > >> Brian is pretty much done. Is that true Brian on the Archetype front? > > > > > > The archetypeng code has moved to apache/maven/sandbox > > > > And you were supposed to figure out the JIRA workflow and I am > >> supposed to do the patch submission policy. > >> > >> After this we just warn people and we can cut releases on a weekly > >> basis. > >> > >> I don't think you can reasonably say what can be released when until > >> people actually start doing some work. Until then we pump out alphas, > >> my only two requirements were above to have some form of sanity for > >> people to makes tests for us. > >> > >> On 31 Aug 07, at 8:58 AM 31 Aug 07, Brett Porter wrote: > >> > >>> Hi, > >>> > >>> I'm looking to do a few things towards getting a 2.1 alpha out, and > >>> wanted to look towards getting 2.1 itself a bit nearer. It seems > >>> like we have too many things scheduled at the moment for 2.1, so > >>> here are a few bits I've been looking at and was going to start > >>> running through. Would be great to hear others thoughts. > >>> > >>> 1) 2.1-alpha-1 issues > >>> > >>> I would like to cut this back to just the following and start > >>> working on them: > >>> * current known regressions > >>> * integration test failures > >>> and move the rest to 2.1.x as the 2.1 sorting bucket > >>> > >>> Any objections? > >>> > >>> 2) 2.1 JIRA > >>> > >>> This has about 270 issues + a large number currently unreviewed > >>> again for us all to go through. I think it needs to be cut down > >>> dramatically - I'd say ~100 issues should be the target here. > >>> > >>> I would map it out as 2.1-alpha-2 thru alpha-4: the highest > >>> priority / most addressable / related issues from 2.1.x and the > >>> current 2.1-alpha-1, + the new features from the wiki. I think this > >>> should be all we plan for 2.1 at this point, and move on to feature- > >>> complete betas then. We'll also include stuff that gets addressed > >>> through 2.0.x of course, and anything else that someone gets an > >>> itch to fix or a patch lands for. > >>> > >>> Any objections? If others think this is the right approach, I'm > >>> happy to go through and produce a list of what I think should > >>> remain. > >>> > >>> 3) New features > >>> > >>> I believe we should categorise these as: required for 2.1, optional > >>> for 2.1, and the rest as beyond 2.1. I think we should be > >>> particularly conservative to make sure a 2.1 release happens sooner. > >>> > >>> IMO, the required are: > >>> * decoupling maven-artifact (under way) > >>> * IT problems > >>> * shared build context (mostly done) > >>> * profile activators (mostly done) > >>> * repository mirroring (generally better ability to define > >>> repositories, even without the artifact resolution changes) > >>> * POM loading and building > >>> * Toolchains > >>> * Embedder > >>> * Plugin packs (depends on POM loading as currently defined) > >>> > >>> and the optional are: > >>> * java 5 annotations > >>> * conflict resolvers > >>> * artifact handling / artifact resolution spec > >>> * repository security > >>> * local repo separation > >>> * use StAX > >>> > >>> I'm also going over the rest of the wiki stuff to help finish up > >>> the things that still needed putting into the current layout and > >>> have a couple of other comments. I'll get back to that over the > >>> weekend. > >>> > >>> In my mind, I'd really like to see a realistic chance of 2.1 > >>> getting out this year, and planning to have 2 or 3 point releases > >>> next year, each spending time addressing the key issues people > >>> experience and those that get the most bang for our buck with the > >>> open JIRAs. > >>> > >>> Thoughts? Any
Re: Getting a 2.1 release happening
On 31 Aug 07, at 9:58 AM 31 Aug 07, Raphaël Piéroni wrote: Hi guys, Could it be some work done on integrating archetypes for maven 2.1 ? Archetype should stand completely on its own. Should have nothing to do with 2.1. What i am thinking about is to enhance the settings model to permit plugins to access some configuration when used without a project. Sure, that's fine but it should all be the same to the underlying Archetype components. How the parameters get to Archetype is arbitrary. Like the repositories defined in active profiles. Like plugin configuration like in project.build.plugins but only when called without a project. Like the list of archetype groups like for the plugins. So you're just asking for changes in Maven to make getting better information to Archetype easier? Is that premature (for maven 2.2+), or offtopic in this thread ? Some inlined comments follow. Regards Raphaël 2007/8/31, Jason van Zyl <[EMAIL PROTECTED]>: As I noted before, if the ITs are reasonably under control with a way for people to make them and submit them then I will cut alphas everyday. Brian is pretty much done. Is that true Brian on the Archetype front? The archetypeng code has moved to apache/maven/sandbox And you were supposed to figure out the JIRA workflow and I am supposed to do the patch submission policy. After this we just warn people and we can cut releases on a weekly basis. I don't think you can reasonably say what can be released when until people actually start doing some work. Until then we pump out alphas, my only two requirements were above to have some form of sanity for people to makes tests for us. On 31 Aug 07, at 8:58 AM 31 Aug 07, Brett Porter wrote: Hi, I'm looking to do a few things towards getting a 2.1 alpha out, and wanted to look towards getting 2.1 itself a bit nearer. It seems like we have too many things scheduled at the moment for 2.1, so here are a few bits I've been looking at and was going to start running through. Would be great to hear others thoughts. 1) 2.1-alpha-1 issues I would like to cut this back to just the following and start working on them: * current known regressions * integration test failures and move the rest to 2.1.x as the 2.1 sorting bucket Any objections? 2) 2.1 JIRA This has about 270 issues + a large number currently unreviewed again for us all to go through. I think it needs to be cut down dramatically - I'd say ~100 issues should be the target here. I would map it out as 2.1-alpha-2 thru alpha-4: the highest priority / most addressable / related issues from 2.1.x and the current 2.1-alpha-1, + the new features from the wiki. I think this should be all we plan for 2.1 at this point, and move on to feature- complete betas then. We'll also include stuff that gets addressed through 2.0.x of course, and anything else that someone gets an itch to fix or a patch lands for. Any objections? If others think this is the right approach, I'm happy to go through and produce a list of what I think should remain. 3) New features I believe we should categorise these as: required for 2.1, optional for 2.1, and the rest as beyond 2.1. I think we should be particularly conservative to make sure a 2.1 release happens sooner. IMO, the required are: * decoupling maven-artifact (under way) * IT problems * shared build context (mostly done) * profile activators (mostly done) * repository mirroring (generally better ability to define repositories, even without the artifact resolution changes) * POM loading and building * Toolchains * Embedder * Plugin packs (depends on POM loading as currently defined) and the optional are: * java 5 annotations * conflict resolvers * artifact handling / artifact resolution spec * repository security * local repo separation * use StAX I'm also going over the rest of the wiki stuff to help finish up the things that still needed putting into the current layout and have a couple of other comments. I'll get back to that over the weekend. In my mind, I'd really like to see a realistic chance of 2.1 getting out this year, and planning to have 2 or 3 point releases next year, each spending time addressing the key issues people experience and those that get the most bang for our buck with the open JIRAs. Thoughts? Any volunteers? :) Cheers, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ 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 --
Re: Getting a 2.1 release happening
On 31 Aug 07, at 9:48 AM 31 Aug 07, Brett Porter wrote: On 01/09/2007, at 2:27 AM, Jason van Zyl wrote: As I noted before, if the ITs are reasonably under control with a way for people to make them and submit them then I will cut alphas everyday. There's some known failures I'd like to fix, that's all. They are all in JIRA. Brian is pretty much done. Is that true Brian on the Archetype front? And you were supposed to figure out the JIRA workflow already done and I am supposed to do the patch submission policy. that's great, but I don't think it's required to cut an alpha-1 (which I thought you agreed to last time I asked in June, which is why I assumed it wasn't a blocker). Just the page saying how we take patches, a few paragraphs talking about the IT archetype. If we're happy with the state of ITs that's not hard to whip off. I don't think you can reasonably say what can be released when until people actually start doing some work. I think there's enough work in there already to start turning them out right now. As long as people are warned that's fine. I'm using it in production in a few places and it's pretty stable and has been for a while. I also think it's appropriate to reduce the scope of 2.1 now to make working on it more approachable, to make maintaining JIRA easier and to get a final release out sooner. We need a small, incremental update - not Maven 3.0. If we've got those couple things above I'll start cutting releases. I have no problem with that. - 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: Getting a 2.1 release happening
Hi guys, Could it be some work done on integrating archetypes for maven 2.1 ? What i am thinking about is to enhance the settings model to permit plugins to access some configuration when used without a project. Like the repositories defined in active profiles. Like plugin configuration like in project.build.plugins but only when called without a project. Like the list of archetype groups like for the plugins. Is that premature (for maven 2.2+), or offtopic in this thread ? Some inlined comments follow. Regards Raphaël 2007/8/31, Jason van Zyl <[EMAIL PROTECTED]>: > > As I noted before, if the ITs are reasonably under control with a way > for people to make them and submit them then I will cut alphas everyday. > > Brian is pretty much done. Is that true Brian on the Archetype front? The archetypeng code has moved to apache/maven/sandbox And you were supposed to figure out the JIRA workflow and I am > supposed to do the patch submission policy. > > After this we just warn people and we can cut releases on a weekly > basis. > > I don't think you can reasonably say what can be released when until > people actually start doing some work. Until then we pump out alphas, > my only two requirements were above to have some form of sanity for > people to makes tests for us. > > On 31 Aug 07, at 8:58 AM 31 Aug 07, Brett Porter wrote: > > > Hi, > > > > I'm looking to do a few things towards getting a 2.1 alpha out, and > > wanted to look towards getting 2.1 itself a bit nearer. It seems > > like we have too many things scheduled at the moment for 2.1, so > > here are a few bits I've been looking at and was going to start > > running through. Would be great to hear others thoughts. > > > > 1) 2.1-alpha-1 issues > > > > I would like to cut this back to just the following and start > > working on them: > > * current known regressions > > * integration test failures > > and move the rest to 2.1.x as the 2.1 sorting bucket > > > > Any objections? > > > > 2) 2.1 JIRA > > > > This has about 270 issues + a large number currently unreviewed > > again for us all to go through. I think it needs to be cut down > > dramatically - I'd say ~100 issues should be the target here. > > > > I would map it out as 2.1-alpha-2 thru alpha-4: the highest > > priority / most addressable / related issues from 2.1.x and the > > current 2.1-alpha-1, + the new features from the wiki. I think this > > should be all we plan for 2.1 at this point, and move on to feature- > > complete betas then. We'll also include stuff that gets addressed > > through 2.0.x of course, and anything else that someone gets an > > itch to fix or a patch lands for. > > > > Any objections? If others think this is the right approach, I'm > > happy to go through and produce a list of what I think should remain. > > > > 3) New features > > > > I believe we should categorise these as: required for 2.1, optional > > for 2.1, and the rest as beyond 2.1. I think we should be > > particularly conservative to make sure a 2.1 release happens sooner. > > > > IMO, the required are: > > * decoupling maven-artifact (under way) > > * IT problems > > * shared build context (mostly done) > > * profile activators (mostly done) > > * repository mirroring (generally better ability to define > > repositories, even without the artifact resolution changes) > > * POM loading and building > > * Toolchains > > * Embedder > > * Plugin packs (depends on POM loading as currently defined) > > > > and the optional are: > > * java 5 annotations > > * conflict resolvers > > * artifact handling / artifact resolution spec > > * repository security > > * local repo separation > > * use StAX > > > > I'm also going over the rest of the wiki stuff to help finish up > > the things that still needed putting into the current layout and > > have a couple of other comments. I'll get back to that over the > > weekend. > > > > In my mind, I'd really like to see a realistic chance of 2.1 > > getting out this year, and planning to have 2 or 3 point releases > > next year, each spending time addressing the key issues people > > experience and those that get the most bang for our buck with the > > open JIRAs. > > > > Thoughts? Any volunteers? :) > > > > Cheers, > > Brett > > > > -- > > Brett Porter - [EMAIL PROTECTED] > > Blog: http://www.devzuz.org/blogs/bporter/ > > > > 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: Getting a 2.1 release happening
On 01/09/2007, at 2:27 AM, Jason van Zyl wrote: As I noted before, if the ITs are reasonably under control with a way for people to make them and submit them then I will cut alphas everyday. There's some known failures I'd like to fix, that's all. They are all in JIRA. Brian is pretty much done. Is that true Brian on the Archetype front? And you were supposed to figure out the JIRA workflow already done and I am supposed to do the patch submission policy. that's great, but I don't think it's required to cut an alpha-1 (which I thought you agreed to last time I asked in June, which is why I assumed it wasn't a blocker). I don't think you can reasonably say what can be released when until people actually start doing some work. I think there's enough work in there already to start turning them out right now. I also think it's appropriate to reduce the scope of 2.1 now to make working on it more approachable, to make maintaining JIRA easier and to get a final release out sooner. We need a small, incremental update - not Maven 3.0. - 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: Getting a 2.1 release happening
As I noted before, if the ITs are reasonably under control with a way for people to make them and submit them then I will cut alphas everyday. Brian is pretty much done. Is that true Brian on the Archetype front? And you were supposed to figure out the JIRA workflow and I am supposed to do the patch submission policy. After this we just warn people and we can cut releases on a weekly basis. I don't think you can reasonably say what can be released when until people actually start doing some work. Until then we pump out alphas, my only two requirements were above to have some form of sanity for people to makes tests for us. On 31 Aug 07, at 8:58 AM 31 Aug 07, Brett Porter wrote: Hi, I'm looking to do a few things towards getting a 2.1 alpha out, and wanted to look towards getting 2.1 itself a bit nearer. It seems like we have too many things scheduled at the moment for 2.1, so here are a few bits I've been looking at and was going to start running through. Would be great to hear others thoughts. 1) 2.1-alpha-1 issues I would like to cut this back to just the following and start working on them: * current known regressions * integration test failures and move the rest to 2.1.x as the 2.1 sorting bucket Any objections? 2) 2.1 JIRA This has about 270 issues + a large number currently unreviewed again for us all to go through. I think it needs to be cut down dramatically - I'd say ~100 issues should be the target here. I would map it out as 2.1-alpha-2 thru alpha-4: the highest priority / most addressable / related issues from 2.1.x and the current 2.1-alpha-1, + the new features from the wiki. I think this should be all we plan for 2.1 at this point, and move on to feature- complete betas then. We'll also include stuff that gets addressed through 2.0.x of course, and anything else that someone gets an itch to fix or a patch lands for. Any objections? If others think this is the right approach, I'm happy to go through and produce a list of what I think should remain. 3) New features I believe we should categorise these as: required for 2.1, optional for 2.1, and the rest as beyond 2.1. I think we should be particularly conservative to make sure a 2.1 release happens sooner. IMO, the required are: * decoupling maven-artifact (under way) * IT problems * shared build context (mostly done) * profile activators (mostly done) * repository mirroring (generally better ability to define repositories, even without the artifact resolution changes) * POM loading and building * Toolchains * Embedder * Plugin packs (depends on POM loading as currently defined) and the optional are: * java 5 annotations * conflict resolvers * artifact handling / artifact resolution spec * repository security * local repo separation * use StAX I'm also going over the rest of the wiki stuff to help finish up the things that still needed putting into the current layout and have a couple of other comments. I'll get back to that over the weekend. In my mind, I'd really like to see a realistic chance of 2.1 getting out this year, and planning to have 2 or 3 point releases next year, each spending time addressing the key issues people experience and those that get the most bang for our buck with the open JIRAs. Thoughts? Any volunteers? :) Cheers, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ 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]
