Re: code documentation was: For anyone trying to fix configuration bugs in 2.1 (and some notes on how Maven 2.1 works)
Sound goods for me. Also, we could use the overview javadoc parameter to specify doc or samples. Cheers, Vincent 2007/9/9, Brian E. Fox <[EMAIL PROTECTED]>: > I would prefer the javadocs so it's self contained. Anyone looking at > this detailed level would really want javadocs and not an APT anyway. > The narrative description can go in the class javadoc to describe > how/what/why etc. > > > -Original Message- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: Sunday, September 09, 2007 10:50 PM > To: Maven Developers List > Subject: Re: code documentation was: For anyone trying to fix > configuration bugs in 2.1 (and some notes on how Maven 2.1 works) > > Cool. > > This mail has some good content that I'd like to retain in the code > documentation. What process should we have for documenting code in > Maven core? > > I kind of like: > - as much as possible in the class javadoc that describes just that > class (I think the current javadoc for MERP does this, and the rest > of the mail could go into the MavenExecutionRequest javadoc) > - package javadoc for things a whole package does > - a couple of APTs for things the whole module does, tying the > javadocs together with a more wholistic overview. > > WDYT? > > Cheers > Brett > > On 10/09/2007, at 9:34 AM, Jason van Zyl wrote: > > > Hi, > > > > I have made a great attempt to push all configuration of anything > > possible to configure in Maven to this class: > > > > http://svn.apache.org/repos/asf/maven/components/trunk/maven- > > embedder/src/main/java/org/apache/maven/embedder/execution/ > > DefaultMavenExecutionRequestPopulator.java > > > > For anyone not familiar with the core in 2.1, we populate a > > MavenExecutionRequest and that is used in the MavenEmbedder.execute > > ( request ) method to carry out what you know Maven to do. The > > Maven CLI for 2.1.x uses the MavenEmbedder along with the IDE > > integration. The class above takes care of populating any defaults > > in the request before it is passed to the embedder. So if anyone is > > interested in trying to track down bugs with: > > > > - settings > > - profiles > > - update policies > > - checksum policies > > - wagon configurations: servers, proxies > > > > Then you can look in the request class and you will also want to > > look in the CLI class to see how the request is populated from > > command line options: > > > > http://svn.apache.org/repos/asf/maven/components/trunk/maven- > > embedder/src/main/java/org/apache/maven/cli/MavenCli.java > > > > Between these two (at least for command line use) you should be > > able track down some of the easier configuration problems or bugs. > > There's still all sorts operations going on in the core like the > > merging of profiles, plugin configurations and what not, but the > > initial configuration is now all located in one place if anyone > > wants to take a shot of fixing anything here: > > > > http://jira.codehaus.org/secure/IssueNavigator.jspa? > > mode=hide&requestId=12412 > > > > Thanks, > > > > Jason > > > > -- > > Jason van Zyl > > Founder and PMC Chair, Apache Maven > > jason at sonatype dot com > > -- > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > -- > Brett Porter - [EMAIL PROTECTED] > Blog: http://www.devzuz.org/blogs/bporter/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > 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-one-plugin 1.2
+1 Vincent 2007/9/10, Brett Porter <[EMAIL PROTECTED]>: > +1 > > On 10/09/2007, at 6:26 AM, Dennis Lundberg wrote: > > > Hi, > > > > I'd like to release maven-one-plugin 1.2. > > > > Release Notes: > > http://jira.codehaus.org/secure/ReleaseNote.jspa? > > projectId=11241&styleName=Html&version=13531 > > > > Tag: > > https://svn.apache.org/repos/asf/maven/plugins/tags/maven-one- > > plugin-1.2/ > > > > Staged at: > > http://people.apache.org/~dennisl/staging-repository-one-plugin/ > > > > The vote will be open for 72 hours. > > > > > > Here is my +1 > > > > -- > > Dennis Lundberg > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > -- > Brett Porter - [EMAIL PROTECTED] > Blog: http://www.devzuz.org/blogs/bporter/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using alternate pom files
Ok, since other people seem against me on using multiple poms, I will spend some more time trying to get everything working with profiles ;) Then I will blame all of the maven community if there are bugs with my builds later on :p Andrew Williams wrote: I would have thought that a combination of classifiers and profiles with a decent DependencyManagement should do it. Make activating a profile at any level will change mydep-1.0 to mydep-1.0-jdk1.4 thoughout the tree. Of course you would need to be sure that the depManagement covered every single artifact that needs this treatment... Andy On 10 Sep 2007, at 18:51, Paul Gier wrote: Basically the problem with using profiles is that it really complicates how the transitive dependencies work. I have to make sure that the correct profiles are activated throughout the dependency tree. I added a comment about this to the jira issue: http://jira.codehaus.org/browse/MNG-3150 Since there is an existing feature to use an alternate pom file, it seems to make sense to me that a multi-module project should also be able to use this feature. Jason van Zyl wrote: On 7 Sep 07, at 9:31 AM 7 Sep 07, Paul Gier wrote: I submitted a small patch for this issue: http://jira.codehaus.org/browse/MNG-3150 The basic idea of it is to be able to use alternate pom.xml files in a multi-module project. Can someone with commit access take a look at this? It would really help with some of our projects if this can be added to a future release. Not sure this is a great idea. Why aren't you using profiles? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: How to upload artefacts and parent poms
ok, I'll create my upload request with my bundles and ASAP I'll update our forge to be able to rsync it with the central repo. thx. Arnaud On 11/09/2007, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > > On 9/11/07, Arnaud HERITIER <[EMAIL PROTECTED]> wrote: > > The bundle is just a jar with this pom ? > > yes > > > I'll certainly setup a synced repo on our future forge. > > The actual one is on widows. What a hassle! > > the upload bundle is a pita for anything more complex than a simple jar > > > > > Arnaud > > > > On 10/09/2007, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > > > > > > create another bundle with just the pom, but if you are gonna do it > > > from time to time you can setup a synced repo somwhere > > > > > > On 9/10/07, Arnaud HERITIER <[EMAIL PROTECTED]> wrote: > > > > Hi guys, > > > > > > > > I would to upload a maven plugin on the central repository. This > one > > > need > > > > also a parent pom. > > > > I can create a bundle for the plugin. But what should I do for the > > > parent > > > > pom ? > > > > > > > > thx > > > > .. > > > > Arnaud HERITIER > > > > .. > > > > OCTO Technology - aheritier AT octo DOT com > > > > www.octo.com | blog.octo.com > > > > .. > > > > ASF - aheritier AT apache DOT org > > > > www.apache.org | maven.apache.org > > > > ... > > > > > > > > > > > > > -- > > > I could give you my word as a Spaniard. > > > No good. I've known too many Spaniards. > > > -- The Princess Bride > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > .. > > Arnaud HERITIER > > .. > > OCTO Technology - aheritier AT octo DOT com > > www.octo.com | blog.octo.com > > .. > > ASF - aheritier AT apache DOT org > > www.apache.org | maven.apache.org > > ... > > > > > -- > I could give you my word as a Spaniard. > No good. I've known too many Spaniards. > -- The Princess Bride > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...
Re: Using alternate pom files
I would have thought that a combination of classifiers and profiles with a decent DependencyManagement should do it. Make activating a profile at any level will change mydep-1.0 to mydep-1.0-jdk1.4 thoughout the tree. Of course you would need to be sure that the depManagement covered every single artifact that needs this treatment... Andy On 10 Sep 2007, at 18:51, Paul Gier wrote: Basically the problem with using profiles is that it really complicates how the transitive dependencies work. I have to make sure that the correct profiles are activated throughout the dependency tree. I added a comment about this to the jira issue: http://jira.codehaus.org/browse/MNG-3150 Since there is an existing feature to use an alternate pom file, it seems to make sense to me that a multi-module project should also be able to use this feature. Jason van Zyl wrote: On 7 Sep 07, at 9:31 AM 7 Sep 07, Paul Gier wrote: I submitted a small patch for this issue: http://jira.codehaus.org/browse/MNG-3150 The basic idea of it is to be able to use alternate pom.xml files in a multi-module project. Can someone with commit access take a look at this? It would really help with some of our projects if this can be added to a future release. Not sure this is a great idea. Why aren't you using profiles? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Maven Artifact in 2.0.x
On 9/11/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > On 11 Sep 07, at 9:25 AM 11 Sep 07, Carlos Sanchez wrote: > > > i'd like to see 2.0.8 released with the old artifact code and then > > 2.0.9 with the new one so we have a clear checkpoint to easily know if > > there are problems with the new approach > > > > How is 2.0.7 not a clear point? I just would like to reduce the changes between releases. We release what is now as 2.0.8 and then prepare artifact 3.0 for 2.0.9 if something breaks between 2.0.8 and 2.0.9 we know clearly it was the artifact changes and it's just a matter of downgrading to 2.0.8. I think it'd make our life easier > > And if a few of us are planning to do the work what is the objection? no objection, just my 2 cents > > If there are technical problems or things don't work then I don't > want to do it at all, but it's looking like it will work with the > minimal amount of testing that has happened. > > > On 9/10/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > >> Hi, > >> > >> How do people feel about trying to use maven-artifact in 2.0.x? > >> > >> The code has not changed, and backward compatibility will be > >> maintained, and from Mark's trials it appears to work. Is this > >> correct Mark? The ITs run using the decoupled version? > >> > >> The question is what are the criteria to decide if this is viable? > >> > >> 1) All plugins using the old artifacts must work (we need those smoke > >> test projects in plugins) > >> 2) Code must be binary compatible (easy to check with clirr) > >> > >> The only thing I can see as a problem right now is if people directly > >> depend on maven-artifact-manager (would you guess that's the api?) > >> then without a modification for the request of that would cause a > >> problem. This needs to be fixed in 2.1 as well and I was just going > >> to flip any requests for > >> > >> org.apache.maven:maven-artifact > >> org.apache.maven:maven-artifact-manager > >> org.apache.maven:maven-repository-metadata > >> > >> into a request for > >> > >> org.apache.maven.artifact:maven-artifact > >> > >> which containers everything required. > >> > >> A little artifact filter would do the trick. > >> > >> We are going to have to maintain backward compat in maven-artifact > >> for a long time anyway because of plugins using it directly. We are > >> going to have to support 2.0.x for a long time and having to maintain > >> divergent copies of maven-artifact will very much suck ass. Maven > >> 2.0.x is going to be used for a long time, and that's fine, but the > >> easier to maintain the better. > >> > >> 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] > >> > >> > > > > > > -- > > I could give you my word as a Spaniard. > > No good. I've known too many Spaniards. > > -- The Princess Bride > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > 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] > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Doing alpha releases faster
Frequent, fast releases sure would help - but I am not sure they are always a good idea, say (as many do) that an API break is needed in the alpha code - I'm not sure that should pass by on the fast track, it could cause problems with those in the wrong time zone not being able to comment. Andy On 10 Sep 2007, at 17:59, Jason van Zyl wrote: Hi, For 2.1 I have been trying to lock down all the versions so that the dependencies are stable. When I need to fix something in classworlds, plexus, or modello, I just make the fix, install, test and if everything works deploy it and lock down the versions in the build and continue. I would like to do the same with maven-artifact and get a little more agile, and not force people to use a snapshot. For alphas I think it would be acceptable to get 3 +1s from PMC members and then push it out. For anything in beta or beyond it's the standard procedure, but pushing out an alpha or incremental release just takes too long and it is in those times of flux that the bugs in the snapshot mechanism bite you. I think this will also force us to start changing things to what they are. Doxia for example should probably be a beta, not an alpha. I want to be able to fix things in maven-artifact as using SNAPSHOTs is not good for external dependencies, but I don't want to be grounded for 3 days while I wait to release maven-artifact in order to pick up a stable set of changes. We can use timestamps too I suppose, but then what's the difference really. I just want to get the 2.1 release out faster. Maven artifact is simply no where near being usable for 2.1 and it's going to change as it will be one of the first proposals I will put on the table after the first series of alphas to fix the bugs, regressions, and usability. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Maven Artifact in 2.0.x
On 11 Sep 07, at 9:25 AM 11 Sep 07, Carlos Sanchez wrote: i'd like to see 2.0.8 released with the old artifact code and then 2.0.9 with the new one so we have a clear checkpoint to easily know if there are problems with the new approach How is 2.0.7 not a clear point? And if a few of us are planning to do the work what is the objection? If there are technical problems or things don't work then I don't want to do it at all, but it's looking like it will work with the minimal amount of testing that has happened. On 9/10/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: Hi, How do people feel about trying to use maven-artifact in 2.0.x? The code has not changed, and backward compatibility will be maintained, and from Mark's trials it appears to work. Is this correct Mark? The ITs run using the decoupled version? The question is what are the criteria to decide if this is viable? 1) All plugins using the old artifacts must work (we need those smoke test projects in plugins) 2) Code must be binary compatible (easy to check with clirr) The only thing I can see as a problem right now is if people directly depend on maven-artifact-manager (would you guess that's the api?) then without a modification for the request of that would cause a problem. This needs to be fixed in 2.1 as well and I was just going to flip any requests for org.apache.maven:maven-artifact org.apache.maven:maven-artifact-manager org.apache.maven:maven-repository-metadata into a request for org.apache.maven.artifact:maven-artifact which containers everything required. A little artifact filter would do the trick. We are going to have to maintain backward compat in maven-artifact for a long time anyway because of plugins using it directly. We are going to have to support 2.0.x for a long time and having to maintain divergent copies of maven-artifact will very much suck ass. Maven 2.0.x is going to be used for a long time, and that's fine, but the easier to maintain the better. 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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Maven Artifact in 2.0.x
Yes, I would think it is a good plan to see as much shared between 2.0.x and 2.1 as possible, except the core codebase of course ;) Andy On 11 Sep 2007, at 03:40, Jason van Zyl wrote: Hi, How do people feel about trying to use maven-artifact in 2.0.x? The code has not changed, and backward compatibility will be maintained, and from Mark's trials it appears to work. Is this correct Mark? The ITs run using the decoupled version? The question is what are the criteria to decide if this is viable? 1) All plugins using the old artifacts must work (we need those smoke test projects in plugins) 2) Code must be binary compatible (easy to check with clirr) The only thing I can see as a problem right now is if people directly depend on maven-artifact-manager (would you guess that's the api?) then without a modification for the request of that would cause a problem. This needs to be fixed in 2.1 as well and I was just going to flip any requests for org.apache.maven:maven-artifact org.apache.maven:maven-artifact-manager org.apache.maven:maven-repository-metadata into a request for org.apache.maven.artifact:maven-artifact which containers everything required. A little artifact filter would do the trick. We are going to have to maintain backward compat in maven-artifact for a long time anyway because of plugins using it directly. We are going to have to support 2.0.x for a long time and having to maintain divergent copies of maven-artifact will very much suck ass. Maven 2.0.x is going to be used for a long time, and that's fine, but the easier to maintain the better. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to upload artefacts and parent poms
On 9/11/07, Arnaud HERITIER <[EMAIL PROTECTED]> wrote: > The bundle is just a jar with this pom ? yes > I'll certainly setup a synced repo on our future forge. > The actual one is on widows. What a hassle! the upload bundle is a pita for anything more complex than a simple jar > > Arnaud > > On 10/09/2007, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > > > > create another bundle with just the pom, but if you are gonna do it > > from time to time you can setup a synced repo somwhere > > > > On 9/10/07, Arnaud HERITIER <[EMAIL PROTECTED]> wrote: > > > Hi guys, > > > > > > I would to upload a maven plugin on the central repository. This one > > need > > > also a parent pom. > > > I can create a bundle for the plugin. But what should I do for the > > parent > > > pom ? > > > > > > thx > > > .. > > > Arnaud HERITIER > > > .. > > > OCTO Technology - aheritier AT octo DOT com > > > www.octo.com | blog.octo.com > > > .. > > > ASF - aheritier AT apache DOT org > > > www.apache.org | maven.apache.org > > > ... > > > > > > > > > -- > > I could give you my word as a Spaniard. > > No good. I've known too many Spaniards. > > -- The Princess Bride > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > .. > Arnaud HERITIER > .. > OCTO Technology - aheritier AT octo DOT com > www.octo.com | blog.octo.com > .. > ASF - aheritier AT apache DOT org > www.apache.org | maven.apache.org > ... > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Maven Artifact in 2.0.x
i'd like to see 2.0.8 released with the old artifact code and then 2.0.9 with the new one so we have a clear checkpoint to easily know if there are problems with the new approach On 9/10/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > Hi, > > How do people feel about trying to use maven-artifact in 2.0.x? > > The code has not changed, and backward compatibility will be > maintained, and from Mark's trials it appears to work. Is this > correct Mark? The ITs run using the decoupled version? > > The question is what are the criteria to decide if this is viable? > > 1) All plugins using the old artifacts must work (we need those smoke > test projects in plugins) > 2) Code must be binary compatible (easy to check with clirr) > > The only thing I can see as a problem right now is if people directly > depend on maven-artifact-manager (would you guess that's the api?) > then without a modification for the request of that would cause a > problem. This needs to be fixed in 2.1 as well and I was just going > to flip any requests for > > org.apache.maven:maven-artifact > org.apache.maven:maven-artifact-manager > org.apache.maven:maven-repository-metadata > > into a request for > > org.apache.maven.artifact:maven-artifact > > which containers everything required. > > A little artifact filter would do the trick. > > We are going to have to maintain backward compat in maven-artifact > for a long time anyway because of plugins using it directly. We are > going to have to support 2.0.x for a long time and having to maintain > divergent copies of maven-artifact will very much suck ass. Maven > 2.0.x is going to be used for a long time, and that's fine, but the > easier to maintain the better. > > 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] > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lining up maven-artifact for a release
On 11 Sep 07, at 6:58 AM 11 Sep 07, Mark Hobson wrote: On 10/09/2007, Jason van Zyl <[EMAIL PROTECTED]> wrote: I tried out your changes in 2.1 and it seems to work just fine. Sweet! Now if this works in 2.0.x and we decide we can go that path that will be even sweeter. Have you tried the maven-artifact trunk in 2.0.x? I haven't tried it yet. Good stuff. I did try maven-artifact 3.0-SNAPSHOT in 2.0.x and it appeared to work after lots of dependency tweaking - see my previous comments in this thread. I can commit the required changes to a branch if you want. Sure that would be good, I really just want to test plugins that used the old stuff and make sure it doesn't tank there. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Maven Artifact in 2.0.x
On 11/09/2007, Jason van Zyl <[EMAIL PROTECTED]> wrote: > How do people feel about trying to use maven-artifact in 2.0.x? > > The code has not changed, and backward compatibility will be > maintained, and from Mark's trials it appears to work. Is this > correct Mark? The ITs run using the decoupled version? I'm certainly in favour of giving this a go. I got the ITs running locally with ma3 in 2.0.x after fixing the plugin dependency problems that you described above. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using Maven Artifact in 2.0.x
I think it's a good idea. The risk is it delays 2.0.8 a little longer, but the benefit of getting there sooner and being compatible with the changes in 2.1 shouldn't be underestimated. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, September 10, 2007 10:41 PM To: Maven Developers List Subject: Using Maven Artifact in 2.0.x Hi, How do people feel about trying to use maven-artifact in 2.0.x? The code has not changed, and backward compatibility will be maintained, and from Mark's trials it appears to work. Is this correct Mark? The ITs run using the decoupled version? The question is what are the criteria to decide if this is viable? 1) All plugins using the old artifacts must work (we need those smoke test projects in plugins) 2) Code must be binary compatible (easy to check with clirr) The only thing I can see as a problem right now is if people directly depend on maven-artifact-manager (would you guess that's the api?) then without a modification for the request of that would cause a problem. This needs to be fixed in 2.1 as well and I was just going to flip any requests for org.apache.maven:maven-artifact org.apache.maven:maven-artifact-manager org.apache.maven:maven-repository-metadata into a request for org.apache.maven.artifact:maven-artifact which containers everything required. A little artifact filter would do the trick. We are going to have to maintain backward compat in maven-artifact for a long time anyway because of plugins using it directly. We are going to have to support 2.0.x for a long time and having to maintain divergent copies of maven-artifact will very much suck ass. Maven 2.0.x is going to be used for a long time, and that's fine, but the easier to maintain the better. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lining up maven-artifact for a release
On 10/09/2007, Jason van Zyl <[EMAIL PROTECTED]> wrote: > I tried out your changes in 2.1 and it seems to work just fine. Sweet! > > Now if this works in 2.0.x and we decide we can go that path that > will be even sweeter. > > Have you tried the maven-artifact trunk in 2.0.x? > > I haven't tried it yet. Good stuff. I did try maven-artifact 3.0-SNAPSHOT in 2.0.x and it appeared to work after lots of dependency tweaking - see my previous comments in this thread. I can commit the required changes to a branch if you want. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UI for Group Actions
LAMY Olivier a écrit :
Hi,
In fact, I think "Choose a Build Definition" is not very clear.
The best should be something like : "You can choose a Build Definition but if you don't the default one will be used".
But it's a little bit huge for a list box ;-) .
I will look at the tooltip feature in webwork to add help/explanation on how
does it work.
If someone has better idea for the UI ?
"Default Build Definition" will be clear
And fix CONTINUUM-1439 too (sorry I haven't tested with shell script).
I will work on this today at evening time.
--
Olivier
-Message d'origine-
De : Wendy Smoak [mailto:[EMAIL PROTECTED]
Envoyé : lundi 10 septembre 2007 03:27
À : [EMAIL PROTECTED]
Objet : UI for Group Actions
I'm looking at the UI for the new things in Group Actions, and there's some
inconsistency.
The drop down needs a space, "Choose a Build Definition" (not BuildDefinition).
Everything else is capitalized, so the next one should be "Build All Projects".
We have "Edit", "Delete Group", and "Release". Either they all need to have
'Group' or none of them should. (It's in a section called Group Actions, so leaving off Group is my
preference. Shorter, too.)
So far it seems clear that the drop downs "go with" the button just to the
right, but I reserve the right to complain later if something else gets added. :)
I'll eventually open issues for these if no one beats me to fixing them. It's
going to be a busy week so I wanted to toss it out to see if anyone else has
time.
--
Wendy
This e-mail, any attachments and the information contained therein ("this
message") are confidential and intended solely for the use of the addressee(s). If
you have received this message in error please send it back to the sender and delete it.
Unauthorized publication, use, dissemination or disclosure of this message, either in
whole or in part is strictly prohibited.
--
Ce message électronique et tous les fichiers joints ainsi que les informations contenues
dans ce message ( ci après "le message" ), sont confidentiels et destinés
exclusivement à l'usage de la personne à laquelle ils sont adressés. Si vous avez reçu
ce message par erreur, merci de le renvoyer à son émetteur et de le détruire. Toutes
diffusion, publication, totale ou partielle ou divulgation sous quelque forme que se soit
non expressément autorisées de ce message, sont interdites.
-
Re: How to upload artefacts and parent poms
The bundle is just a jar with this pom ? I'll certainly setup a synced repo on our future forge. The actual one is on widows. What a hassle! Arnaud On 10/09/2007, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > > create another bundle with just the pom, but if you are gonna do it > from time to time you can setup a synced repo somwhere > > On 9/10/07, Arnaud HERITIER <[EMAIL PROTECTED]> wrote: > > Hi guys, > > > > I would to upload a maven plugin on the central repository. This one > need > > also a parent pom. > > I can create a bundle for the plugin. But what should I do for the > parent > > pom ? > > > > thx > > .. > > Arnaud HERITIER > > .. > > OCTO Technology - aheritier AT octo DOT com > > www.octo.com | blog.octo.com > > .. > > ASF - aheritier AT apache DOT org > > www.apache.org | maven.apache.org > > ... > > > > > -- > I could give you my word as a Spaniard. > No good. I've known too many Spaniards. > -- The Princess Bride > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...
Re: turning off continuum_ci.sh?
yes, we can turn off it, but it would be good to deploy the assemblies somewhere (in a snapshot repo?) so users/testers will can use them. About the nightly build, I think we should run it until the the beta-3 update so we'll can run a fresh build every nights. Emmanuel Brett Porter a écrit : Now that Continuum is self-hosting, shall we turn off the hourly build to save some cpu cycles? - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
Re: Maven 2.0.7 is coming this week, let's prepare for 2.0.8
Ok thanks. I'll try to see if I can find some hours to help on it. Arnaud On 11/09/2007, Brett Porter <[EMAIL PROTECTED]> wrote: > > On 11/09/2007, at 5:57 AM, Arnaud HERITIER wrote: > > > Hi team, > > > > Will we release the 2.0.8 ? > > It was scheduled for mid-august ( > > http://docs.codehaus.org/display/MAVEN/Home) and there's always some > > annoying blocking bugs in 2.0.7 (return codes, settings not read when > > there's no pom, ...). > > I know that a lot of us are working to release a first alpha of > > 2.1. Is > > there some of you who will work on 2.0.x ? > > Yep, I've been putting bugs back into the 2.0.x bucket that can be > fixed before 2.1, since these will still go on in parallel for a bit. > I started with WAGON-82 which was unfortunately more time consuming > than I thought, but I can work on that and other 2.0.x stuff again > later this week. > > Cheers, > Brett > > -- > Brett Porter - [EMAIL PROTECTED] > Blog: http://www.devzuz.org/blogs/bporter/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...
New feature wanted
Hi All , I wonder if add a new feature something like " mvn eclipseme:eclipseme " , to make a J2ME project. Any one want involve this work ? I just comit this requirement..
