Re: Deprecate eclipse:eclipse plugin
On Tue, Nov 2, 2010 at 1:51 PM, Paul Benedict wrote: > +1 on keeping the eclipse plugin. I like m2Eclipse but at times is > buggy so I fall back to using this often. As someone who irregularly maintains m-e-p I have the same issues as above. I've got m2eclipse working at home but I've never been able to get it to work in my corporate environment yet. (I've never looked at Eclipse/STS) m-e-p mostly works. A lot of the problems are around the edge cases. And there are a lot of missing integration tests for the IBM specific tools. Maybe giving it a new home would help, I haven't thought about it enough. I've not looked at git usage at all, and from the little I understand someone still needs to maintain it so that it can be released and synced (via forge to central, or however). I dont think a move will help the maintenance question, but it may remove the (mis)percpetion that it is more actively maintained. I'd be interested to see other peoples opinions - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Deprecate eclipse:eclipse plugin
+1 on keeping the eclipse plugin. I like m2Eclipse but at times is buggy so I fall back to using this often. Paul 2010/11/1 Daniel Kulp : > > I personally think deprecating/retiring the eclipse plugin is a bit premature. > Looking at the svn log, there have been a buunch of commits and a release this > year, so there definitely are people that are "supporting" it. > > Maybe if m2eclipse was actually usable for any of the projects I work on I > might think differently, but it isn't. > > It's used a lot, it's at least somewhat supported here, and no viable > alternative exists. Doesn't sound like deprecation material to me. > > Dan > > > On Monday 01 November 2010 10:04:14 am Arnaud Héritier wrote: >> For the eclipse plugin, I think that just moving it to retired isn't a good >> think because even if we are agree that this one is now really difficult >> to maintain, this is always the preferred integration way with eclipse in >> many corporate environments. Thus we cannot just say to our community that >> we just stop to maintain it. We have to propose something else. >> m2eclipse or Q4E are the best choices for now but they don't cover all what >> eclipse:eclipse can do and they have always some performances/stabilities >> issues with large projects. Everybody can fork eclipse:eclipse plugin (and >> many teams already did it) but I think we should provide a solution for >> them to try to share their changes. >> >> How will we communicate around these changes ? >> >> On Nov 1, 2010, at 2:37 PM, Jason van Zyl wrote: >> > I started moving any of the ones discussed here: >> > >> > http://svn.apache.org/repos/asf/maven/retired/ >> > >> > If anyone disagrees we can move them back but I think the ones suggest so >> > far are good candidates. >> > >> > On Nov 1, 2010, at 1:37 PM, Jason van Zyl wrote: >> >> Following up from a discussion on the user list. I think it's time to be >> >> realistic about providing a healthy level of support for plugins here. >> >> I think it makes more sense to reduce the foot print of plugins we say >> >> we support and do those well as opposed to housing many plugin that >> >> just don't get much love. I would ask people to think about the plugins >> >> we're housing that we shouldn't. Probably a thread per plugin would be >> >> fine for discussion. >> >> >> >> To that end the plugins I'll send the first thread. >> >> >> >> Thanks, >> >> >> >> Jason >> >> >> >> -- >> >> Jason van Zyl >> >> Founder, Apache Maven >> >> http://twitter.com/jvanzyl >> >> - >> >> >> >> Our achievements speak for themselves. What we have to keep track >> >> of are our failures, discouragements and doubts. We tend to forget >> >> the past difficulties, the many false starts, and the painful >> >> groping. We see our past achievements as the end result of a >> >> clean forward thrust, and our present difficulties as >> >> signs of decline and decay. >> >> >> >> -- Eric Hoffer, Reflections on the Human Condition >> > >> > Thanks, >> > >> > Jason >> > >> > -- >> > Jason van Zyl >> > Founder, Apache Maven >> > http://twitter.com/jvanzyl >> > - >> > >> > In short, man creates for himself a new religion of a rational >> > and technical order to justify his work and to be justified in it. >> > >> > -- Jacques Ellul, The Technological Society >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org > > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Deprecate eclipse:eclipse plugin
I personally think deprecating/retiring the eclipse plugin is a bit premature. Looking at the svn log, there have been a buunch of commits and a release this year, so there definitely are people that are "supporting" it. Maybe if m2eclipse was actually usable for any of the projects I work on I might think differently, but it isn't. It's used a lot, it's at least somewhat supported here, and no viable alternative exists. Doesn't sound like deprecation material to me. Dan On Monday 01 November 2010 10:04:14 am Arnaud Héritier wrote: > For the eclipse plugin, I think that just moving it to retired isn't a good > think because even if we are agree that this one is now really difficult > to maintain, this is always the preferred integration way with eclipse in > many corporate environments. Thus we cannot just say to our community that > we just stop to maintain it. We have to propose something else. > m2eclipse or Q4E are the best choices for now but they don't cover all what > eclipse:eclipse can do and they have always some performances/stabilities > issues with large projects. Everybody can fork eclipse:eclipse plugin (and > many teams already did it) but I think we should provide a solution for > them to try to share their changes. > > How will we communicate around these changes ? > > On Nov 1, 2010, at 2:37 PM, Jason van Zyl wrote: > > I started moving any of the ones discussed here: > > > > http://svn.apache.org/repos/asf/maven/retired/ > > > > If anyone disagrees we can move them back but I think the ones suggest so > > far are good candidates. > > > > On Nov 1, 2010, at 1:37 PM, Jason van Zyl wrote: > >> Following up from a discussion on the user list. I think it's time to be > >> realistic about providing a healthy level of support for plugins here. > >> I think it makes more sense to reduce the foot print of plugins we say > >> we support and do those well as opposed to housing many plugin that > >> just don't get much love. I would ask people to think about the plugins > >> we're housing that we shouldn't. Probably a thread per plugin would be > >> fine for discussion. > >> > >> To that end the plugins I'll send the first thread. > >> > >> Thanks, > >> > >> Jason > >> > >> -- > >> Jason van Zyl > >> Founder, Apache Maven > >> http://twitter.com/jvanzyl > >> - > >> > >> Our achievements speak for themselves. What we have to keep track > >> of are our failures, discouragements and doubts. We tend to forget > >> the past difficulties, the many false starts, and the painful > >> groping. We see our past achievements as the end result of a > >> clean forward thrust, and our present difficulties as > >> signs of decline and decay. > >> > >> -- Eric Hoffer, Reflections on the Human Condition > > > > Thanks, > > > > Jason > > > > -- > > Jason van Zyl > > Founder, Apache Maven > > http://twitter.com/jvanzyl > > - > > > > In short, man creates for himself a new religion of a rational > > and technical order to justify his work and to be justified in it. > > > > -- Jacques Ellul, The Technological Society > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM interoperability
On Nov 1, 2010, at 7:36 PM, Jason van Zyl wrote: > > On Nov 2, 2010, at 3:29 AM, Ralph Goers wrote: > >> I'm not sure I understand. Is the proposal here to deploy non-XML project >> descriptors to the repository in addition to the standard pom? If so, what >> is the point? > > In the case of the Clojure dialect there will be two other implementations > using the same dialect. Lein, Cake, and Polyglot Maven. Lein and Cake want to > deal with the Clojure format. So it's not skin off my back if we deploy > another format, it's not going to harm anyone and help them. Polyglot Maven > could deal with either but there tools might not be able to. Should they use > the bits in Polyglot Maven. I'd like that but I can't make them. Yes, but... > >> Many projects aren't going to bother creating multiple dialects of poms and >> so the variations will still have to handle the traditional pom. Are you >> planning on adding something to Nexus to translate poms into the other >> language(s) to handle that so the tools don't have to? this is the part that concerns me. How are these projects planning on handling existing artifacts - I'm assuming as least some of the things they are working with can consume Java artifacts? Do you also want to support Gradle build files somehow? It would be unfortunate to have this get out of control and have the repo end up a mess. >> >> As for a new version of the model, this is something that has been on the >> table for quite a while and what should go in it should be discussed before >> code gets committed. > > Interoperability is step 1. Without figuring that out nothing gets > changed/added. I remember having this discussion a year ago in Oakland with Brian. It seemed pretty sensible then to leave the 4.0.0 pom alone and create a new file. A project using the new model would cause a 4.0.0 pom to be deployed in addition to the new model during a release. > >> However, I agree that a 4.0.0 pom should be generated from the new model. >> Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Culling the maven-stage-plugin
On Mon, Nov 1, 2010 at 5:59 PM, Jason van Zyl wrote: > > On Nov 2, 2010, at 1:40 AM, Dan Tran wrote: > >> On Mon, Nov 1, 2010 at 3:46 PM, Jason van Zyl wrote: >>> >>> On Nov 1, 2010, at 11:24 PM, Dan Tran wrote: >>> On Mon, Nov 1, 2010 at 2:15 PM, Jason van Zyl wrote: > > On Nov 1, 2010, at 10:12 PM, Dennis Lundberg wrote: > >> On 2010-11-01 18:54, Jason van Zyl wrote: >>> Doesn't change the fact it's a hack, generally not useful and is >>> generally not going to get used. >> >> It actually is being used. >> >>> Dennis, are you committed to supporting it? >> >> My plan is to close as many issues as I can and release a 1.0, to get >> rid of one of the last beta-version-plugins :) >> >> After that I'm done with it. >> >> I do think that this is a useful plugin for those that do not, for >> whatever reason, have a repository manager, despite its warts. Perhaps a >> plugin that could move to the Mojo project? >> There is no need to move stage plugin to MOJO since wagon-maven-plugin covers that feature. >>> >>> So you're saying Dennis applied your patch and you're using the >>> wagon-maven-plugin? >> >> My apology, should had withdrawn the request for this fix a long time ago. > > > No, no. I just didn't know they served the same purpose and just wanted to > know. If the maven-wagon-plugin is more flexible (I assume it handles all > supported transports, not just what I originally hard-coded for Apache stuff > a long time ago) then the maven-stage-plugin can probably be retired. Yes, wagon-maven-plugin supports staging and more flexible. So it is safe to retire stage-maven-plugin. > >>> > > That seems most sensible given the guy you applied the patch for could > have done it himself at Mojo. > >>> If so, that's fine, but it's a dead end plugin as far as I'm concerned. >>> Who's going to use it when all the repository managers have some form >>> of staging? >>> >>> On Nov 1, 2010, at 6:47 PM, Brett Porter wrote: >>> Dennis committed to it just yesterday, so I think calling it unsupported is premature. On 01/11/2010, at 8:39 AM, Jason van Zyl wrote: > This was a hack, and has now been replaced with Nexus staging here at > Apache (and most other forges). I believe this plugin can be > archived now. > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > You are never dedicated to something you have complete confidence in. > No one is fanatically shouting that the sun is going to rise tomorrow. > They know it is going to rise tomorrow. When people are fanatically > dedicated to political or religious faiths or any other kind of > dogmas or goals, it's always because these dogmas or > goals are in doubt. > > -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance > > > -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> Thanks, >>> >>> Jason >>> >>> -- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> - >>> >>> We all have problems. How we deal with them is a measure of our worth. >>> >>> -- Unknown >>> >>> >>> >>> >> >> >> -- >> Dennis Lundberg >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > Simplex sigillum veri. (Simplicity is the seal of truth.) > > > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> Thanks, >>> >>> Jason >>> >>> -- >>> Jason van
Re: POM interoperability
On Nov 2, 2010, at 3:29 AM, Ralph Goers wrote: > I'm not sure I understand. Is the proposal here to deploy non-XML project > descriptors to the repository in addition to the standard pom? If so, what > is the point? In the case of the Clojure dialect there will be two other implementations using the same dialect. Lein, Cake, and Polyglot Maven. Lein and Cake want to deal with the Clojure format. So it's not skin off my back if we deploy another format, it's not going to harm anyone and help them. Polyglot Maven could deal with either but there tools might not be able to. Should they use the bits in Polyglot Maven. I'd like that but I can't make them. > Many projects aren't going to bother creating multiple dialects of poms and > so the variations will still have to handle the traditional pom. Are you > planning on adding something to Nexus to translate poms into the other > language(s) to handle that so the tools don't have to? > > As for a new version of the model, this is something that has been on the > table for quite a while and what should go in it should be discussed before > code gets committed. Interoperability is step 1. Without figuring that out nothing gets changed/added. > However, I agree that a 4.0.0 pom should be generated from the new model. > > Ralph > > On Nov 1, 2010, at 3:37 PM, Jason van Zyl wrote: > >> I am working on a release of Polyglot Maven and the only tangible thing >> stopping me is having a plan for POM interoperability between: >> >> 1) Different representations of the model for the same version of the model. >> This is what I'd like for the first version of Polyglot Maven where I just >> want to translate the version 4.0.0 model between different representations. >> >> 2) Different versions of the model. This is something we will need for Maven >> 3.1. >> >> In talking with Benjamin and Brian for 1) I think it would be easiest to >> deploy both versions of the model. The complete model in the native dialect >> like Clojure, and the complete XML translation. Deploying both would be >> useful because in the case of Clojure they are trying to come up with a >> common model, like the POM, for Clojure-based build tools. So if someone >> built and deployed with Polyglot Maven using the Clojure dialect then they >> want people not using Polyglot Maven i.e. a native Clojure tool to read the >> Clojure. This assumes our models are compatible but we'll have to work that >> out. We need to start somewhere so I don't think abbreviating any of the >> information is good for a first pass. Leave it all there for now and we'll >> figure out if a build-only representation of the model will suffice for >> sending to the repository. >> >> For 2) Benjamin's recommendation was to transform elements in the newer >> model back to the 4.0.0 model. I'm not sure how long this will be possible >> but if we live with our baggage and say we'll only add elements to the model >> I think this will be a lot easier. Having to track removals across versions >> of the model will be a pain in the ass. We translate back for as long as we >> can and when we can't do that anymore maybe we do a build-only >> transformation. >> >> I'd like to field other thoughts before I write something up. I'm going to >> do all this work in Polyglot Maven because I'm sure I'm going to break >> things but the folks I'm working with will tolerate this for a while. I'm >> chatting with folks in the Clojure community on a Lein-like markup, Dhanji >> (a Googler working on Guice and Sitebricks) who is working on a format >> called Atom, and Kristian (fellow who makes all the Ruby/Maven tooling) who >> is working on a Ruby DSL. If things break here for a while it's not the end >> of the world and is a good testing ground. >> >> At any rate if anyone has ideas or documents I'll integrate it into the >> proposal I'm writing. I'm moving pretty fast and I plan to release a version >> of the Maven Shell next week, and then a couple weeks later a version with >> Polyglot capabilities. So if you have thoughts I'd appreciate them sooner >> rather then later. >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> Selfish deeds are the shortest path to self destruction. >> >> -- The Seven Samuari, Akira Kurosawa >> >> >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fan
Re: POM interoperability
I'm not sure I understand. Is the proposal here to deploy non-XML project descriptors to the repository in addition to the standard pom? If so, what is the point? Many projects aren't going to bother creating multiple dialects of poms and so the variations will still have to handle the traditional pom. Are you planning on adding something to Nexus to translate poms into the other language(s) to handle that so the tools don't have to? As for a new version of the model, this is something that has been on the table for quite a while and what should go in it should be discussed before code gets committed. However, I agree that a 4.0.0 pom should be generated from the new model. Ralph On Nov 1, 2010, at 3:37 PM, Jason van Zyl wrote: > I am working on a release of Polyglot Maven and the only tangible thing > stopping me is having a plan for POM interoperability between: > > 1) Different representations of the model for the same version of the model. > This is what I'd like for the first version of Polyglot Maven where I just > want to translate the version 4.0.0 model between different representations. > > 2) Different versions of the model. This is something we will need for Maven > 3.1. > > In talking with Benjamin and Brian for 1) I think it would be easiest to > deploy both versions of the model. The complete model in the native dialect > like Clojure, and the complete XML translation. Deploying both would be > useful because in the case of Clojure they are trying to come up with a > common model, like the POM, for Clojure-based build tools. So if someone > built and deployed with Polyglot Maven using the Clojure dialect then they > want people not using Polyglot Maven i.e. a native Clojure tool to read the > Clojure. This assumes our models are compatible but we'll have to work that > out. We need to start somewhere so I don't think abbreviating any of the > information is good for a first pass. Leave it all there for now and we'll > figure out if a build-only representation of the model will suffice for > sending to the repository. > > For 2) Benjamin's recommendation was to transform elements in the newer model > back to the 4.0.0 model. I'm not sure how long this will be possible but if > we live with our baggage and say we'll only add elements to the model I think > this will be a lot easier. Having to track removals across versions of the > model will be a pain in the ass. We translate back for as long as we can and > when we can't do that anymore maybe we do a build-only transformation. > > I'd like to field other thoughts before I write something up. I'm going to do > all this work in Polyglot Maven because I'm sure I'm going to break things > but the folks I'm working with will tolerate this for a while. I'm chatting > with folks in the Clojure community on a Lein-like markup, Dhanji (a Googler > working on Guice and Sitebricks) who is working on a format called Atom, and > Kristian (fellow who makes all the Ruby/Maven tooling) who is working on a > Ruby DSL. If things break here for a while it's not the end of the world and > is a good testing ground. > > At any rate if anyone has ideas or documents I'll integrate it into the > proposal I'm writing. I'm moving pretty fast and I plan to release a version > of the Maven Shell next week, and then a couple weeks later a version with > Polyglot capabilities. So if you have thoughts I'd appreciate them sooner > rather then later. > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > Selfish deeds are the shortest path to self destruction. > > -- The Seven Samuari, Akira Kurosawa > > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Culling dead/inactive plugins
>The barrier to collaboration is high here. That's all I'm saying. The tools make that partially true but it's not stopping other projects so it's clearly not the only issue. Maybe no one really cares about these plugins, and for the ones raised so far, that's probably the case. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Culling dead/inactive plugins
On Nov 2, 2010, at 2:31 AM, Brian Fox wrote: > 2010/11/1 Arnaud Héritier : >> I agree. >> Perhaps for some of them we could discuss to move them to mojo.codehaus.org >> to let the community take the lead on them if we find some volunteers (I'm >> thinking about the eclipse plugin for example). > > It probably needs to be said that if people want to step up and > maintain them, they should be considered for commit access. We wouldn't be having this discussion if that were the case, no? I'm not sure what you're saying. Leave them here in the hopes someone eventually comes along? > Just > because the current committer base doesn't want to maintain them > doesn't mean the plugins have to leave, perhaps we should try to > attract people to maintain them. > Obviously this doesn't apply for all > plugins like stage that was a hack and has a replacement, but if we > have so many dead plugins it's possibly a symptom of not growing the > committer base. > We don't support our own plugins but we're going to do outreach now? We have people contributing anymore because we hardly process any of the patches that are submitted. We don't process the patches because it's a complete pain in the ass compared to the methods available. If we put the plugins in a git repo, publicize that I think that's how we would get more contributors because it's much easier to clone, make an improvement and then submit a pull request. What you suggest has never happened in terms of outreach or people stepping up and I agree with you it's symptomatic of something. But this situation is not magically going to change. The barrier to collaboration is high here. I think it's easier to place the code in an environment where there are little to no barriers to collaborating and let the community do what the community is willing to do. Not let the code rot here and hope for the best. > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language
Meetup at ApacheCon in Atlanta
If you happen to find yourself in Atlanta on Wed, Nov 3rd at 8pm, and want to talk about Maven, come join the meetup. You can find details and the signup page here: http://na.apachecon.com/c/acna2010/schedule/meetups - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Culling dead/inactive plugins
2010/11/1 Arnaud Héritier : > I agree. > Perhaps for some of them we could discuss to move them to mojo.codehaus.org > to let the community take the lead on them if we find some volunteers (I'm > thinking about the eclipse plugin for example). It probably needs to be said that if people want to step up and maintain them, they should be considered for commit access. Just because the current committer base doesn't want to maintain them doesn't mean the plugins have to leave, perhaps we should try to attract people to maintain them. Obviously this doesn't apply for all plugins like stage that was a hack and has a replacement, but if we have so many dead plugins it's possibly a symptom of not growing the committer base. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Culling the maven-stage-plugin
On Nov 2, 2010, at 1:40 AM, Dan Tran wrote: > On Mon, Nov 1, 2010 at 3:46 PM, Jason van Zyl wrote: >> >> On Nov 1, 2010, at 11:24 PM, Dan Tran wrote: >> >>> On Mon, Nov 1, 2010 at 2:15 PM, Jason van Zyl wrote: On Nov 1, 2010, at 10:12 PM, Dennis Lundberg wrote: > On 2010-11-01 18:54, Jason van Zyl wrote: >> Doesn't change the fact it's a hack, generally not useful and is >> generally not going to get used. > > It actually is being used. > >> Dennis, are you committed to supporting it? > > My plan is to close as many issues as I can and release a 1.0, to get > rid of one of the last beta-version-plugins :) > > After that I'm done with it. > > I do think that this is a useful plugin for those that do not, for > whatever reason, have a repository manager, despite its warts. Perhaps a > plugin that could move to the Mojo project? > >>> >>> There is no need to move stage plugin to MOJO since wagon-maven-plugin >>> covers that feature. >>> >> >> So you're saying Dennis applied your patch and you're using the >> wagon-maven-plugin? > > My apology, should had withdrawn the request for this fix a long time ago. No, no. I just didn't know they served the same purpose and just wanted to know. If the maven-wagon-plugin is more flexible (I assume it handles all supported transports, not just what I originally hard-coded for Apache stuff a long time ago) then the maven-stage-plugin can probably be retired. >> >>> That seems most sensible given the guy you applied the patch for could have done it himself at Mojo. >> If so, that's fine, but it's a dead end plugin as far as I'm concerned. >> Who's going to use it when all the repository managers have some form of >> staging? >> >> On Nov 1, 2010, at 6:47 PM, Brett Porter wrote: >> >>> Dennis committed to it just yesterday, so I think calling it >>> unsupported is premature. >>> >>> On 01/11/2010, at 8:39 AM, Jason van Zyl wrote: >>> This was a hack, and has now been replaced with Nexus staging here at Apache (and most other forges). I believe this plugin can be archived now. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance >>> >>> -- >>> Brett Porter >>> br...@apache.org >>> http://brettporter.wordpress.com/ >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> We all have problems. How we deal with them is a measure of our worth. >> >> -- Unknown >> >> >> >> > > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Simplex sigillum veri. (Simplicity is the seal of truth.) >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> People develop abstractions by generalizing from concrete examples. >> Every attempt to determine the correct abstraction on pap
Re: Culling the maven-stage-plugin
On Mon, Nov 1, 2010 at 3:46 PM, Jason van Zyl wrote: > > On Nov 1, 2010, at 11:24 PM, Dan Tran wrote: > >> On Mon, Nov 1, 2010 at 2:15 PM, Jason van Zyl wrote: >>> >>> On Nov 1, 2010, at 10:12 PM, Dennis Lundberg wrote: >>> On 2010-11-01 18:54, Jason van Zyl wrote: > Doesn't change the fact it's a hack, generally not useful and is > generally not going to get used. It actually is being used. > Dennis, are you committed to supporting it? My plan is to close as many issues as I can and release a 1.0, to get rid of one of the last beta-version-plugins :) After that I'm done with it. I do think that this is a useful plugin for those that do not, for whatever reason, have a repository manager, despite its warts. Perhaps a plugin that could move to the Mojo project? >> >> There is no need to move stage plugin to MOJO since wagon-maven-plugin >> covers that feature. >> > > So you're saying Dennis applied your patch and you're using the > wagon-maven-plugin? My apology, should had withdrawn the request for this fix a long time ago. > >> >>> >>> That seems most sensible given the guy you applied the patch for could have >>> done it himself at Mojo. >>> > If so, that's fine, but it's a dead end plugin as far as I'm concerned. > Who's going to use it when all the repository managers have some form of > staging? > > On Nov 1, 2010, at 6:47 PM, Brett Porter wrote: > >> Dennis committed to it just yesterday, so I think calling it unsupported >> is premature. >> >> On 01/11/2010, at 8:39 AM, Jason van Zyl wrote: >> >>> This was a hack, and has now been replaced with Nexus staging here at >>> Apache (and most other forges). I believe this plugin can be archived >>> now. >>> >>> Thanks, >>> >>> Jason >>> >>> -- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> - >>> >>> You are never dedicated to something you have complete confidence in. >>> No one is fanatically shouting that the sun is going to rise tomorrow. >>> They know it is going to rise tomorrow. When people are fanatically >>> dedicated to political or religious faiths or any other kind of >>> dogmas or goals, it's always because these dogmas or >>> goals are in doubt. >>> >>> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance >>> >>> >>> >> >> -- >> Brett Porter >> br...@apache.org >> http://brettporter.wordpress.com/ >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > We all have problems. How we deal with them is a measure of our worth. > > -- Unknown > > > > -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> Thanks, >>> >>> Jason >>> >>> -- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> - >>> >>> Simplex sigillum veri. (Simplicity is the seal of truth.) >>> >>> >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > People develop abstractions by generalizing from concrete examples. > Every attempt to determine the correct abstraction on paper without > actually developing a running system is doomed to failure. No one > is that smart. A framework is a resuable design, so you develop it by > looking at the things it is supposed to be a design of. The more examples > you look at, the more general your framework will be. > > -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks > > > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [PROPOSAL] Create a retirement plan for plugins
Do you want a different process and proposal process for restructuring? Like I've proposed for the site plugin? On Nov 1, 2010, at 10:35 PM, Dennis Lundberg wrote: > Hi > > Given the discussions about retiring plugin I feel strongly that we need > to have a plan for doing so. There are bound to be differing opinions > about this, so see this as a starting point for discussions. When we get > to the point that we agree on the general process, I'll turn this > discussion into a document and put into our site. > > > 1. Propose a vote on the dev-list to retire a plugin. The vote should be > open for the standard 72 hours to allow people to voice their opinions. > Perhaps also send this to the users-list? > > > 2. Decide how to retire the plugin (don't know whether this should be a > vote or not, or perhaps incorporated into 1.). There are multiple > scenarios available. Two have been suggested in the other threads: > > 2.1 Move to retired area in svn > > 2.2 Move to mojo.codehaus.org > > please add more possible actions here > > > 3. Make one final release of the plugin before it goes away. This allows > us to make a clean break. The final release should have the site changed > so that SCM URLs are changed or removed to reflect the decision made > under 2. If the plugin is moved elsewhere a prominent notice should be > placed on the front page of the plugin's site. > > To respond to the inevitable "why bother" responses I hereby volunteer > to do all those releases, if no one else steps up. > > > 4. Announce the fact that the plugin has been retired/moved/whatever on > the annou...@m.a.o and us...@m.a.o mailing lists. Explain to people what > they should do if they would like to help with the continued development > of the plugin at some other place. > > > > Opinions, comments are welcome > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham
Re: [PROPOSAL] Create a retirement plan for plugins
And I capture what votes I've seen so far. https://cwiki.apache.org/confluence/display/MAVEN/Proposal+of+plugins+to+retire And we can just use that as a record. On Nov 1, 2010, at 10:57 PM, Dennis Lundberg wrote: > On 2010-11-01 22:38, Jason van Zyl wrote: >> Can you put this in Confluence. > > Sure, I'll just wait for some feedback first, then I'll summarize it in > Confluence. Once the wrinkles are ironed out I'll move it to the site. > >> I think we should include the addition of plugins as well ... as that's how >> we got here in the first place. New plugins, if we ever add anymore, should >> require the same rigor going in. > > Do you mean that we should describe how high the bar is for new plugins > to enter? > >> >> On Nov 1, 2010, at 10:35 PM, Dennis Lundberg wrote: >> >>> Hi >>> >>> Given the discussions about retiring plugin I feel strongly that we need >>> to have a plan for doing so. There are bound to be differing opinions >>> about this, so see this as a starting point for discussions. When we get >>> to the point that we agree on the general process, I'll turn this >>> discussion into a document and put into our site. >>> >>> >>> 1. Propose a vote on the dev-list to retire a plugin. The vote should be >>> open for the standard 72 hours to allow people to voice their opinions. >>> Perhaps also send this to the users-list? >>> >>> >>> 2. Decide how to retire the plugin (don't know whether this should be a >>> vote or not, or perhaps incorporated into 1.). There are multiple >>> scenarios available. Two have been suggested in the other threads: >>> >>> 2.1 Move to retired area in svn >>> >>> 2.2 Move to mojo.codehaus.org >>> >>> please add more possible actions here >>> >>> >>> 3. Make one final release of the plugin before it goes away. This allows >>> us to make a clean break. The final release should have the site changed >>> so that SCM URLs are changed or removed to reflect the decision made >>> under 2. If the plugin is moved elsewhere a prominent notice should be >>> placed on the front page of the plugin's site. >>> >>> To respond to the inevitable "why bother" responses I hereby volunteer >>> to do all those releases, if no one else steps up. >>> >>> >>> 4. Announce the fact that the plugin has been retired/moved/whatever on >>> the annou...@m.a.o and us...@m.a.o mailing lists. Explain to people what >>> they should do if they would like to help with the continued development >>> of the plugin at some other place. >>> >>> >>> >>> Opinions, comments are welcome >>> >>> -- >>> Dennis Lundberg >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> In short, man creates for himself a new religion of a rational >> and technical order to justify his work and to be justified in it. >> >> -- Jacques Ellul, The Technological Society >> >> >> >> > > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau
Re: [PROPOSAL] Create a retirement plan for plugins
I prefer to comment in Confluence where it can be captured: https://cwiki.apache.org/confluence/display/MAVEN/Proposal+--+A+creation+and+retirement+plan+for+plugins I added a bit about creation as well. On Nov 1, 2010, at 10:57 PM, Dennis Lundberg wrote: > On 2010-11-01 22:38, Jason van Zyl wrote: >> Can you put this in Confluence. > > Sure, I'll just wait for some feedback first, then I'll summarize it in > Confluence. Once the wrinkles are ironed out I'll move it to the site. > >> I think we should include the addition of plugins as well ... as that's how >> we got here in the first place. New plugins, if we ever add anymore, should >> require the same rigor going in. > > Do you mean that we should describe how high the bar is for new plugins > to enter? > >> >> On Nov 1, 2010, at 10:35 PM, Dennis Lundberg wrote: >> >>> Hi >>> >>> Given the discussions about retiring plugin I feel strongly that we need >>> to have a plan for doing so. There are bound to be differing opinions >>> about this, so see this as a starting point for discussions. When we get >>> to the point that we agree on the general process, I'll turn this >>> discussion into a document and put into our site. >>> >>> >>> 1. Propose a vote on the dev-list to retire a plugin. The vote should be >>> open for the standard 72 hours to allow people to voice their opinions. >>> Perhaps also send this to the users-list? >>> >>> >>> 2. Decide how to retire the plugin (don't know whether this should be a >>> vote or not, or perhaps incorporated into 1.). There are multiple >>> scenarios available. Two have been suggested in the other threads: >>> >>> 2.1 Move to retired area in svn >>> >>> 2.2 Move to mojo.codehaus.org >>> >>> please add more possible actions here >>> >>> >>> 3. Make one final release of the plugin before it goes away. This allows >>> us to make a clean break. The final release should have the site changed >>> so that SCM URLs are changed or removed to reflect the decision made >>> under 2. If the plugin is moved elsewhere a prominent notice should be >>> placed on the front page of the plugin's site. >>> >>> To respond to the inevitable "why bother" responses I hereby volunteer >>> to do all those releases, if no one else steps up. >>> >>> >>> 4. Announce the fact that the plugin has been retired/moved/whatever on >>> the annou...@m.a.o and us...@m.a.o mailing lists. Explain to people what >>> they should do if they would like to help with the continued development >>> of the plugin at some other place. >>> >>> >>> >>> Opinions, comments are welcome >>> >>> -- >>> Dennis Lundberg >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> In short, man creates for himself a new religion of a rational >> and technical order to justify his work and to be justified in it. >> >> -- Jacques Ellul, The Technological Society >> >> >> >> > > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition
Re: POM interoperability
On Nov 2, 2010, at 12:14 AM, Stephen Connolly wrote: > I wasn't saying my use cases were in scope for polyglot's requirements. > I'm talking generally for the model vN to model vN translation. Reduction is orthogonal to translation, it's a transformation. I'm thinking along the lines of making same canonical representation, not changing it. > I was saying my use cases were in scope for arguing that we deploy > multiple POM's to the repo. Interoperability involving selective reduction versus interoperability of the same canonical model is what we're talking about. I think the selective reduction to the model which is a superset of what I think should first be attempted. If you let users reduce what they liked you're likely to have no operability, that would certainly need to be bounded from our side I think. > > one POM must always be a 4.0.0 XML representation of the project Not following, because that's won't be the case for an altered model in 3.1. Say model 4.1. > , but > it may not be the same as the other versions, as long as an automated > process does the mapping ONTO the 4.0.0 XML representation > Right the lowest common denominator will be model version 4.0.0. > -Stephen > > On 1 November 2010 23:04, Jason van Zyl wrote: >> >> On Nov 1, 2010, at 11:59 PM, Stephen Connolly wrote: >> >>> I think we need to get use to the idea of deploying a different POM >>> (as XML) from the POM that is used to build. >>> >> >> Yes, my assumption for Polyglot is the front-end format could be anything, >> but an XML 4.0.0 POM must go to the repository. >> >>> Here are some use-cases I can see: >>> >>> 1. Corporate project which deploys an artifact to a public repo. Some >>> of the info (e.g. SCM details, developers, build, distMgmt, etc) is, >>> due to corporate policies / sensible reasons, information that should >>> not be deployed publically. >> >> This is out of scope. For interoperability, within the same model the >> selective reduction of the representation is a different problem. >> >>> >>> e.g. I may not want people contacting me directly just because I >>> worked for XYZ corp on that foobar-impl project >> >> Out of scope. >> >>> >>> e.g. May not want to publish how the artifact is built for external >>> persons. >>> >> >> Out of scope. >> >> I think any form of selective reduction is not an interoperability problem >> per se. I don't want to conflate model reduction with the translations of >> models of the same version. >> >>> 2. Shading >>> >> >> Not sure what this has to do with it. The shade plugin can already make a >> reduced dependency POM if you like. >> >>> 3. Backwards compat. >>> >> >> Sure, which is 2) when we start making changes to the POM. >> >>> 4. Properties behaving badly >>> >> >> You'll have to explain here. I honestly don't know what you mean here. >> >>> -Stephen >>> >>> On 1 November 2010 22:37, Jason van Zyl wrote: I am working on a release of Polyglot Maven and the only tangible thing stopping me is having a plan for POM interoperability between: 1) Different representations of the model for the same version of the model. This is what I'd like for the first version of Polyglot Maven where I just want to translate the version 4.0.0 model between different representations. 2) Different versions of the model. This is something we will need for Maven 3.1. In talking with Benjamin and Brian for 1) I think it would be easiest to deploy both versions of the model. The complete model in the native dialect like Clojure, and the complete XML translation. Deploying both would be useful because in the case of Clojure they are trying to come up with a common model, like the POM, for Clojure-based build tools. So if someone built and deployed with Polyglot Maven using the Clojure dialect then they want people not using Polyglot Maven i.e. a native Clojure tool to read the Clojure. This assumes our models are compatible but we'll have to work that out. We need to start somewhere so I don't think abbreviating any of the information is good for a first pass. Leave it all there for now and we'll figure out if a build-only representation of the model will suffice for sending to the repository. For 2) Benjamin's recommendation was to transform elements in the newer model back to the 4.0.0 model. I'm not sure how long this will be possible but if we live with our baggage and say we'll only add elements to the model I think this will be a lot easier. Having to track removals across versions of the model will be a pain in the ass. We translate back for as long as we can and when we can't do that anymore maybe we do a build-only transformation. I'd like to field other thoughts before I write something up. I'm going to do all this work in Polyglot Maven
Re: Moving all reporting to a site project
Le lundi 1 novembre 2010, Jason van Zyl a écrit : > I think they are primarily used as site plugin and as such they should move > with the site plugin. I agree there is a conflation of concerns. If > someone wants to decouple build logic from reporting logic that would be > great. AFAIK, code for simultaneous build+reporting logic has been factored out in AbstractMavenReport in maven-reporting-impl [1] even if few plugins have integrated this base class HTH Regards Hervé [1] http://maven.apache.org/shared/maven-reporting- impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM interoperability
I wasn't saying my use cases were in scope for polyglot's requirements. I was saying my use cases were in scope for arguing that we deploy multiple POM's to the repo. one POM must always be a 4.0.0 XML representation of the project, but it may not be the same as the other versions, as long as an automated process does the mapping ONTO the 4.0.0 XML representation -Stephen On 1 November 2010 23:04, Jason van Zyl wrote: > > On Nov 1, 2010, at 11:59 PM, Stephen Connolly wrote: > >> I think we need to get use to the idea of deploying a different POM >> (as XML) from the POM that is used to build. >> > > Yes, my assumption for Polyglot is the front-end format could be anything, > but an XML 4.0.0 POM must go to the repository. > >> Here are some use-cases I can see: >> >> 1. Corporate project which deploys an artifact to a public repo. Some >> of the info (e.g. SCM details, developers, build, distMgmt, etc) is, >> due to corporate policies / sensible reasons, information that should >> not be deployed publically. > > This is out of scope. For interoperability, within the same model the > selective reduction of the representation is a different problem. > >> >> e.g. I may not want people contacting me directly just because I >> worked for XYZ corp on that foobar-impl project > > Out of scope. > >> >> e.g. May not want to publish how the artifact is built for external persons. >> > > Out of scope. > > I think any form of selective reduction is not an interoperability problem > per se. I don't want to conflate model reduction with the translations of > models of the same version. > >> 2. Shading >> > > Not sure what this has to do with it. The shade plugin can already make a > reduced dependency POM if you like. > >> 3. Backwards compat. >> > > Sure, which is 2) when we start making changes to the POM. > >> 4. Properties behaving badly >> > > You'll have to explain here. I honestly don't know what you mean here. > >> -Stephen >> >> On 1 November 2010 22:37, Jason van Zyl wrote: >>> I am working on a release of Polyglot Maven and the only tangible thing >>> stopping me is having a plan for POM interoperability between: >>> >>> 1) Different representations of the model for the same version of the >>> model. This is what I'd like for the first version of Polyglot Maven where >>> I just want to translate the version 4.0.0 model between different >>> representations. >>> >>> 2) Different versions of the model. This is something we will need for >>> Maven 3.1. >>> >>> In talking with Benjamin and Brian for 1) I think it would be easiest to >>> deploy both versions of the model. The complete model in the native dialect >>> like Clojure, and the complete XML translation. Deploying both would be >>> useful because in the case of Clojure they are trying to come up with a >>> common model, like the POM, for Clojure-based build tools. So if someone >>> built and deployed with Polyglot Maven using the Clojure dialect then they >>> want people not using Polyglot Maven i.e. a native Clojure tool to read the >>> Clojure. This assumes our models are compatible but we'll have to work that >>> out. We need to start somewhere so I don't think abbreviating any of the >>> information is good for a first pass. Leave it all there for now and we'll >>> figure out if a build-only representation of the model will suffice for >>> sending to the repository. >>> >>> For 2) Benjamin's recommendation was to transform elements in the newer >>> model back to the 4.0.0 model. I'm not sure how long this will be possible >>> but if we live with our baggage and say we'll only add elements to the >>> model I think this will be a lot easier. Having to track removals across >>> versions of the model will be a pain in the ass. We translate back for as >>> long as we can and when we can't do that anymore maybe we do a build-only >>> transformation. >>> >>> I'd like to field other thoughts before I write something up. I'm going to >>> do all this work in Polyglot Maven because I'm sure I'm going to break >>> things but the folks I'm working with will tolerate this for a while. I'm >>> chatting with folks in the Clojure community on a Lein-like markup, Dhanji >>> (a Googler working on Guice and Sitebricks) who is working on a format >>> called Atom, and Kristian (fellow who makes all the Ruby/Maven tooling) who >>> is working on a Ruby DSL. If things break here for a while it's not the end >>> of the world and is a good testing ground. >>> >>> At any rate if anyone has ideas or documents I'll integrate it into the >>> proposal I'm writing. I'm moving pretty fast and I plan to release a >>> version of the Maven Shell next week, and then a couple weeks later a >>> version with Polyglot capabilities. So if you have thoughts I'd appreciate >>> them sooner rather then later. >>> >>> Thanks, >>> >>> Jason >>> >>> -- >>> Jason van Zyl >>> Founder, Apache Maven >
Re: [PROPOSAL] Create a retirement plan for plugins
On Nov 1, 2010, at 10:35 PM, Dennis Lundberg wrote: > Hi > > Given the discussions about retiring plugin I feel strongly that we need > to have a plan for doing so. There are bound to be differing opinions > about this, so see this as a starting point for discussions. When we get > to the point that we agree on the general process, I'll turn this > discussion into a document and put into our site. > > > 1. Propose a vote on the dev-list to retire a plugin. The vote should be > open for the standard 72 hours to allow people to voice their opinions. > Perhaps also send this to the users-list? > What kind of vote. 3 +1s, no -1s. Majority of the PMC? Like a technical vote that can be vetoed or a release vote that cannot. Please be more clear here. > > 2. Decide how to retire the plugin (don't know whether this should be a > vote or not, or perhaps incorporated into 1.). There are multiple > scenarios available. Two have been suggested in the other threads: > > 2.1 Move to retired area in svn > Just retire it and let people take the code as they like. Once it's retired it's open season. Let folks who might want to work on it organize themselves as they like. > 2.2 Move to mojo.codehaus.org > > please add more possible actions here > > > 3. Make one final release of the plugin before it goes away. This allows > us to make a clean break. The final release should have the site changed > so that SCM URLs are changed or removed to reflect the decision made > under 2. You're not going to know. I would just say it's retired. When and if someone takes up the torch we can point the site at that. In the interim saying it's retired I think is fine. > If the plugin is moved elsewhere a prominent notice should be > placed on the front page of the plugin's site. > > To respond to the inevitable "why bother" responses I hereby volunteer > to do all those releases, if no one else steps up. > I don't think you have to be a martyr. How about the person who proposes the retirement do the final release. If you want to do the cleanup work, you have to do all of it. > > 4. Announce the fact that the plugin has been retired/moved/whatever on > the annou...@m.a.o and us...@m.a.o mailing lists. Explain to people what > they should do if they would like to help with the continued development > of the plugin at some other place. > Make sense. > > > Opinions, comments are welcome > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C.
Re: Why are you so quick (Was: Culling dead/inactive plugins)
2010/11/1 Dennis Lundberg : > I've now reverted the changes in svn. Thank Dennis to have catch up the legendary Jason's speed. Vincent - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM interoperability
On Nov 1, 2010, at 11:59 PM, Stephen Connolly wrote: > I think we need to get use to the idea of deploying a different POM > (as XML) from the POM that is used to build. > Yes, my assumption for Polyglot is the front-end format could be anything, but an XML 4.0.0 POM must go to the repository. > Here are some use-cases I can see: > > 1. Corporate project which deploys an artifact to a public repo. Some > of the info (e.g. SCM details, developers, build, distMgmt, etc) is, > due to corporate policies / sensible reasons, information that should > not be deployed publically. This is out of scope. For interoperability, within the same model the selective reduction of the representation is a different problem. > > e.g. I may not want people contacting me directly just because I > worked for XYZ corp on that foobar-impl project Out of scope. > > e.g. May not want to publish how the artifact is built for external persons. > Out of scope. I think any form of selective reduction is not an interoperability problem per se. I don't want to conflate model reduction with the translations of models of the same version. > 2. Shading > Not sure what this has to do with it. The shade plugin can already make a reduced dependency POM if you like. > 3. Backwards compat. > Sure, which is 2) when we start making changes to the POM. > 4. Properties behaving badly > You'll have to explain here. I honestly don't know what you mean here. > -Stephen > > On 1 November 2010 22:37, Jason van Zyl wrote: >> I am working on a release of Polyglot Maven and the only tangible thing >> stopping me is having a plan for POM interoperability between: >> >> 1) Different representations of the model for the same version of the model. >> This is what I'd like for the first version of Polyglot Maven where I just >> want to translate the version 4.0.0 model between different representations. >> >> 2) Different versions of the model. This is something we will need for Maven >> 3.1. >> >> In talking with Benjamin and Brian for 1) I think it would be easiest to >> deploy both versions of the model. The complete model in the native dialect >> like Clojure, and the complete XML translation. Deploying both would be >> useful because in the case of Clojure they are trying to come up with a >> common model, like the POM, for Clojure-based build tools. So if someone >> built and deployed with Polyglot Maven using the Clojure dialect then they >> want people not using Polyglot Maven i.e. a native Clojure tool to read the >> Clojure. This assumes our models are compatible but we'll have to work that >> out. We need to start somewhere so I don't think abbreviating any of the >> information is good for a first pass. Leave it all there for now and we'll >> figure out if a build-only representation of the model will suffice for >> sending to the repository. >> >> For 2) Benjamin's recommendation was to transform elements in the newer >> model back to the 4.0.0 model. I'm not sure how long this will be possible >> but if we live with our baggage and say we'll only add elements to the model >> I think this will be a lot easier. Having to track removals across versions >> of the model will be a pain in the ass. We translate back for as long as we >> can and when we can't do that anymore maybe we do a build-only >> transformation. >> >> I'd like to field other thoughts before I write something up. I'm going to >> do all this work in Polyglot Maven because I'm sure I'm going to break >> things but the folks I'm working with will tolerate this for a while. I'm >> chatting with folks in the Clojure community on a Lein-like markup, Dhanji >> (a Googler working on Guice and Sitebricks) who is working on a format >> called Atom, and Kristian (fellow who makes all the Ruby/Maven tooling) who >> is working on a Ruby DSL. If things break here for a while it's not the end >> of the world and is a good testing ground. >> >> At any rate if anyone has ideas or documents I'll integrate it into the >> proposal I'm writing. I'm moving pretty fast and I plan to release a version >> of the Maven Shell next week, and then a couple weeks later a version with >> Polyglot capabilities. So if you have thoughts I'd appreciate them sooner >> rather then later. >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> Selfish deeds are the shortest path to self destruction. >> >> -- The Seven Samuari, Akira Kurosawa >> >> >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twi
Re: [vote] release maven parent 17
+1 - Olivier Le 1 nov. 2010 22:52, "Brian Fox" a écrit : I'm preparing the enforcer release and it needs the latest parent changes, so I've cut a release: Staged parent: https://repository.apache.org/service/local/repositories/maven-008/content/org/apache/maven/maven-parent/17/maven-parent-17.pom +1 Vote 72 hrs - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Why are you so quick (Was: Culling dead/inactive plugins)
On 2010-11-01 23:50, Stephen Connolly wrote: > On 1 November 2010 22:32, Dennis Lundberg wrote: >> That is something we need to add to the process. But until the process >> has been finalized I think we should revert the svn moves. >> > > +1 > > In the absense of a process, since retirement is essentially an SVN > operation, then our commit first forgiveness second process is the > default. > > Since Dennis started the debate on a process, Commit-first is no > longer viable, so revert the changes I've now reverted the changes in svn. > > -Stephen > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [vote] release maven parent 17
+1 Arnaud On Nov 1, 2010, at 10:51 PM, Brian Fox wrote: > I'm preparing the enforcer release and it needs the latest parent > changes, so I've cut a release: > > Staged parent: > https://repository.apache.org/service/local/repositories/maven-008/content/org/apache/maven/maven-parent/17/maven-parent-17.pom > > +1 > > Vote 72 hrs > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM interoperability
I think we need to get use to the idea of deploying a different POM (as XML) from the POM that is used to build. Here are some use-cases I can see: 1. Corporate project which deploys an artifact to a public repo. Some of the info (e.g. SCM details, developers, build, distMgmt, etc) is, due to corporate policies / sensible reasons, information that should not be deployed publically. e.g. I may not want people contacting me directly just because I worked for XYZ corp on that foobar-impl project e.g. May not want to publish how the artifact is built for external persons. 2. Shading 3. Backwards compat. 4. Properties behaving badly -Stephen On 1 November 2010 22:37, Jason van Zyl wrote: > I am working on a release of Polyglot Maven and the only tangible thing > stopping me is having a plan for POM interoperability between: > > 1) Different representations of the model for the same version of the model. > This is what I'd like for the first version of Polyglot Maven where I just > want to translate the version 4.0.0 model between different representations. > > 2) Different versions of the model. This is something we will need for Maven > 3.1. > > In talking with Benjamin and Brian for 1) I think it would be easiest to > deploy both versions of the model. The complete model in the native dialect > like Clojure, and the complete XML translation. Deploying both would be > useful because in the case of Clojure they are trying to come up with a > common model, like the POM, for Clojure-based build tools. So if someone > built and deployed with Polyglot Maven using the Clojure dialect then they > want people not using Polyglot Maven i.e. a native Clojure tool to read the > Clojure. This assumes our models are compatible but we'll have to work that > out. We need to start somewhere so I don't think abbreviating any of the > information is good for a first pass. Leave it all there for now and we'll > figure out if a build-only representation of the model will suffice for > sending to the repository. > > For 2) Benjamin's recommendation was to transform elements in the newer model > back to the 4.0.0 model. I'm not sure how long this will be possible but if > we live with our baggage and say we'll only add elements to the model I think > this will be a lot easier. Having to track removals across versions of the > model will be a pain in the ass. We translate back for as long as we can and > when we can't do that anymore maybe we do a build-only transformation. > > I'd like to field other thoughts before I write something up. I'm going to do > all this work in Polyglot Maven because I'm sure I'm going to break things > but the folks I'm working with will tolerate this for a while. I'm chatting > with folks in the Clojure community on a Lein-like markup, Dhanji (a Googler > working on Guice and Sitebricks) who is working on a format called Atom, and > Kristian (fellow who makes all the Ruby/Maven tooling) who is working on a > Ruby DSL. If things break here for a while it's not the end of the world and > is a good testing ground. > > At any rate if anyone has ideas or documents I'll integrate it into the > proposal I'm writing. I'm moving pretty fast and I plan to release a version > of the Maven Shell next week, and then a couple weeks later a version with > Polyglot capabilities. So if you have thoughts I'd appreciate them sooner > rather then later. > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > Selfish deeds are the shortest path to self destruction. > > -- The Seven Samuari, Akira Kurosawa > > > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Why are you so quick (Was: Culling dead/inactive plugins)
On Nov 1, 2010, at 11:32 PM, Dennis Lundberg wrote: > On 2010-11-01 23:19, Vincent Siveton wrote: >> 2010/11/1 Jason van Zyl : >>> >>> On Nov 1, 2010, at 10:59 PM, Vincent Siveton wrote: >>> Hi, I agree in the fact to move unmaintened plugins but god, why are you so quick one more time! You asked Dennis to create a wiki page but you already retired the plugins. >>> >>> Yes, because I wouldn't write a wiki page, but if he wants some process >>> then the process has to be documented. Now that I have time to work, I >>> start and that's how I started. If I started erasing the plugins that would >>> be different. >>> Ok I know we could revert your changes but why send us an email and move them 2 min after! We are a community Jason! >>> >>> And I'll happily abide by stuff we document. >>> >> >> Which are? Removing plugins without updating our website? Think about >> our final users! >> I know that documentation is not your strong but you (or someone else) >> should update our documentation (ie src/site/apt/plugins/index.apt >> similar to http://mojo.codehaus.org/plugins.html#Plugin_Graveyard) > > That is something we need to add to the process. But until the process > has been finalized I think we should revert the svn moves. > Do whatever you like Dennis. >> >> Vincent >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Three people can keep a secret provided two of them are dead. -- Unknown
Re: Why are you so quick (Was: Culling dead/inactive plugins)
On Nov 1, 2010, at 11:19 PM, Vincent Siveton wrote: > 2010/11/1 Jason van Zyl : >> >> On Nov 1, 2010, at 10:59 PM, Vincent Siveton wrote: >> >>> Hi, >>> >>> I agree in the fact to move unmaintened plugins but god, why are you >>> so quick one more time! >>> You asked Dennis to create a wiki page but you already retired the >>> plugins. >> >> Yes, because I wouldn't write a wiki page, but if he wants some process then >> the process has to be documented. Now that I have time to work, I start and >> that's how I started. If I started erasing the plugins that would be >> different. >> >>> Ok I know we could revert your changes but why send us an >>> email and move them 2 min after! We are a community Jason! >>> >> >> And I'll happily abide by stuff we document. >> > > Which are? Removing plugins without updating our website? Think about > our final users! That's all I ever think about. > I know that documentation is not your strong but you (or someone else) > should update our documentation (ie src/site/apt/plugins/index.apt > similar to http://mojo.codehaus.org/plugins.html#Plugin_Graveyard) > > Vincent > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
Re: Culling the maven-stage-plugin
On Nov 1, 2010, at 11:24 PM, Dan Tran wrote: > On Mon, Nov 1, 2010 at 2:15 PM, Jason van Zyl wrote: >> >> On Nov 1, 2010, at 10:12 PM, Dennis Lundberg wrote: >> >>> On 2010-11-01 18:54, Jason van Zyl wrote: Doesn't change the fact it's a hack, generally not useful and is generally not going to get used. >>> >>> It actually is being used. >>> Dennis, are you committed to supporting it? >>> >>> My plan is to close as many issues as I can and release a 1.0, to get >>> rid of one of the last beta-version-plugins :) >>> >>> After that I'm done with it. >>> >>> I do think that this is a useful plugin for those that do not, for >>> whatever reason, have a repository manager, despite its warts. Perhaps a >>> plugin that could move to the Mojo project? >>> > > There is no need to move stage plugin to MOJO since wagon-maven-plugin > covers that feature. > So you're saying Dennis applied your patch and you're using the wagon-maven-plugin? > >> >> That seems most sensible given the guy you applied the patch for could have >> done it himself at Mojo. >> If so, that's fine, but it's a dead end plugin as far as I'm concerned. Who's going to use it when all the repository managers have some form of staging? On Nov 1, 2010, at 6:47 PM, Brett Porter wrote: > Dennis committed to it just yesterday, so I think calling it unsupported > is premature. > > On 01/11/2010, at 8:39 AM, Jason van Zyl wrote: > >> This was a hack, and has now been replaced with Nexus staging here at >> Apache (and most other forges). I believe this plugin can be archived >> now. >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> You are never dedicated to something you have complete confidence in. >> No one is fanatically shouting that the sun is going to rise tomorrow. >> They know it is going to rise tomorrow. When people are fanatically >> dedicated to political or religious faiths or any other kind of >> dogmas or goals, it's always because these dogmas or >> goals are in doubt. >> >> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance >> >> >> > > -- > Brett Porter > br...@apache.org > http://brettporter.wordpress.com/ > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - We all have problems. How we deal with them is a measure of our worth. -- Unknown >>> >>> >>> -- >>> Dennis Lundberg >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> Simplex sigillum veri. (Simplicity is the seal of truth.) >> >> >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
Re: Why are you so quick (Was: Culling dead/inactive plugins)
On 1 November 2010 22:32, Dennis Lundberg wrote: > That is something we need to add to the process. But until the process > has been finalized I think we should revert the svn moves. > +1 In the absense of a process, since retirement is essentially an SVN operation, then our commit first forgiveness second process is the default. Since Dennis started the debate on a process, Commit-first is no longer viable, so revert the changes -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [PROPOSAL] Create a retirement plan for plugins
+1 On 1 November 2010 21:35, Dennis Lundberg wrote: > Hi > > Given the discussions about retiring plugin I feel strongly that we need > to have a plan for doing so. There are bound to be differing opinions > about this, so see this as a starting point for discussions. When we get > to the point that we agree on the general process, I'll turn this > discussion into a document and put into our site. > > > 1. Propose a vote on the dev-list to retire a plugin. The vote should be > open for the standard 72 hours to allow people to voice their opinions. > Perhaps also send this to the users-list? > > > 2. Decide how to retire the plugin (don't know whether this should be a > vote or not, or perhaps incorporated into 1.). There are multiple > scenarios available. Two have been suggested in the other threads: > > 2.1 Move to retired area in svn > > 2.2 Move to mojo.codehaus.org > > please add more possible actions here > > > 3. Make one final release of the plugin before it goes away. This allows > us to make a clean break. The final release should have the site changed > so that SCM URLs are changed or removed to reflect the decision made > under 2. If the plugin is moved elsewhere a prominent notice should be > placed on the front page of the plugin's site. > > To respond to the inevitable "why bother" responses I hereby volunteer > to do all those releases, if no one else steps up. > > > 4. Announce the fact that the plugin has been retired/moved/whatever on > the annou...@m.a.o and us...@m.a.o mailing lists. Explain to people what > they should do if they would like to help with the continued development > of the plugin at some other place. > > > > Opinions, comments are welcome > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Problems building Maven from 2.2.x branch with integration tests
Hi I'm looking into releasing Wagon and Brett suggested that I try the new version in a Maven build to make sure everything is building fine. So I checked out the 2.2.x branch tried to build it prior to maing any changes, by running: mvn install -Prun-its All is fine until it gets to "Building Integration Test Executor". I get ... Tests run: 663, Failures: 6, Errors: 370, Skipped: 0 [INFO] --- [ERROR] BUILD FAILURE [INFO] --- [INFO] There are test failures. ... I've tried this on Windows and Ubuntu using Java 1.5, with identical results. Is this to be expected? Am I doing something wrong? -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [vote] release maven parent 17
+1 On 1 November 2010 21:51, Brian Fox wrote: > I'm preparing the enforcer release and it needs the latest parent > changes, so I've cut a release: > > Staged parent: > https://repository.apache.org/service/local/repositories/maven-008/content/org/apache/maven/maven-parent/17/maven-parent-17.pom > > +1 > > Vote 72 hrs > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Culling dead/inactive plugins
On 1 November 2010 21:37, Dennis Lundberg wrote: > On 2010-11-01 22:10, Stephen Connolly wrote: >> Then -1 the commits. >> >> We have a commit first, ask forgiveness second policy in maven last time I >> checked > > So do you think that it's OK for someone to pull the rug from under your > feet, while you are working on something? > > (as in my work on the Stage Plugin) I think it's rude / bad form, but we all have the ability to svn merge . -c -1000563 svn ci -m "putting the rug back under my feet" or whatever revision number it was and ultimately, the Apache Maven policy is review after commit, this kind of thing can happen with review after commit... the only difference is the scale with respect to the refactoring... one could argue that the refactoring I made in surefire (to pool common code between failsafe and surefire) was worse than a simple folder copy/delete operation [because it rendered patches a lot harder to apply if they were pre-refactoring, whereas a folder relocation can be recovered from with either a svn sw to the new location and commit, or else by reverse merging from a clean checkout] > >> - Stephen >> >> On 1 Nov 2010 21:05, "Dennis Lundberg" wrote: >> >> Hi Jason >> >> Doing some house cleaning among our plugins is a good thing, and I'm in >> favor of retiring those that we feel that we cannot support. >> >> However it is not OK for you to go changing things in Subversion less >> than an hour after your proposal (which wasn't even labeled as one). >> That is not the way we do business here. For starters, people are on >> different time zones. Secondly I feel that retiring a plugin is >> something that should require a vote. Finally moving the stuff around in >> Subversion will break links from the plugin sites and a lot of other >> places. Please restore things in Subversion to how they were. >> >> >> On 2010-11-01 13:37, Jason van Zyl wrote: >>> Following up from a discussion on the user list. I thin... >> -- >> Dennis Lundberg >> >> >> - >> To unsubscribe, e-mail: dev-u... >> > > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
POM interoperability
I am working on a release of Polyglot Maven and the only tangible thing stopping me is having a plan for POM interoperability between: 1) Different representations of the model for the same version of the model. This is what I'd like for the first version of Polyglot Maven where I just want to translate the version 4.0.0 model between different representations. 2) Different versions of the model. This is something we will need for Maven 3.1. In talking with Benjamin and Brian for 1) I think it would be easiest to deploy both versions of the model. The complete model in the native dialect like Clojure, and the complete XML translation. Deploying both would be useful because in the case of Clojure they are trying to come up with a common model, like the POM, for Clojure-based build tools. So if someone built and deployed with Polyglot Maven using the Clojure dialect then they want people not using Polyglot Maven i.e. a native Clojure tool to read the Clojure. This assumes our models are compatible but we'll have to work that out. We need to start somewhere so I don't think abbreviating any of the information is good for a first pass. Leave it all there for now and we'll figure out if a build-only representation of the model will suffice for sending to the repository. For 2) Benjamin's recommendation was to transform elements in the newer model back to the 4.0.0 model. I'm not sure how long this will be possible but if we live with our baggage and say we'll only add elements to the model I think this will be a lot easier. Having to track removals across versions of the model will be a pain in the ass. We translate back for as long as we can and when we can't do that anymore maybe we do a build-only transformation. I'd like to field other thoughts before I write something up. I'm going to do all this work in Polyglot Maven because I'm sure I'm going to break things but the folks I'm working with will tolerate this for a while. I'm chatting with folks in the Clojure community on a Lein-like markup, Dhanji (a Googler working on Guice and Sitebricks) who is working on a format called Atom, and Kristian (fellow who makes all the Ruby/Maven tooling) who is working on a Ruby DSL. If things break here for a while it's not the end of the world and is a good testing ground. At any rate if anyone has ideas or documents I'll integrate it into the proposal I'm writing. I'm moving pretty fast and I plan to release a version of the Maven Shell next week, and then a couple weeks later a version with Polyglot capabilities. So if you have thoughts I'd appreciate them sooner rather then later. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa
Re: Moving all reporting to a site project
On 1 November 2010 22:26, Dennis Lundberg wrote: > The separation of concerns is a worthy goal. Like I wrote in another > mail I think some B+R plugins have their build and reporting code > intertwined. Splitting that up might be difficult and we could end up > with a bunch of new shared components, say for example a checkstyle-commons. > > Before we decide how to store the plugins in an SCM, we should work > through the "tainted" plugins one at a time, and try to split build from > reporting. The result of the split might look different than we first > expected it to. +1 on this. I would rather work on splitting the B+R concerns and then spin out the reporting, than push out the B+R plugins and have to pull back in stuff which we really should > > When it comes to the importance and future we have different opinions, > but then again that is nothing new :) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Why are you so quick (Was: Culling dead/inactive plugins)
On 2010-11-01 23:19, Vincent Siveton wrote: > 2010/11/1 Jason van Zyl : >> >> On Nov 1, 2010, at 10:59 PM, Vincent Siveton wrote: >> >>> Hi, >>> >>> I agree in the fact to move unmaintened plugins but god, why are you >>> so quick one more time! >>> You asked Dennis to create a wiki page but you already retired the >>> plugins. >> >> Yes, because I wouldn't write a wiki page, but if he wants some process then >> the process has to be documented. Now that I have time to work, I start and >> that's how I started. If I started erasing the plugins that would be >> different. >> >>> Ok I know we could revert your changes but why send us an >>> email and move them 2 min after! We are a community Jason! >>> >> >> And I'll happily abide by stuff we document. >> > > Which are? Removing plugins without updating our website? Think about > our final users! > I know that documentation is not your strong but you (or someone else) > should update our documentation (ie src/site/apt/plugins/index.apt > similar to http://mojo.codehaus.org/plugins.html#Plugin_Graveyard) That is something we need to add to the process. But until the process has been finalized I think we should revert the svn moves. > > Vincent > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Moving all reporting to a site project
On 2010-11-01 23:18, Jason van Zyl wrote: > > On Nov 1, 2010, at 11:01 PM, Dennis Lundberg wrote: > >> On 2010-11-01 22:48, Jason van Zyl wrote: >>> On Nov 1, 2010, at 10:41 PM, Dennis Lundberg wrote: >>> On 2010-11-01 13:41, Jason van Zyl wrote: > In much the same way we have a little sub-project for releasing I think > it's time to have one for the site generation. Take the maven-site-plugin > and any related plugins and move them into their own tree. What I'm > trying to do here is cull the set of plugins we have is to keep the ones > that are part of the core lifecycles and super popular plugins that get > maintained like the dependency plugin and enforcer plugin. I'm not sure I understand what we would gain by doing this, if we cull all the dead/inactive plugins. Can you elaborate some more? >>> >>> That we have a set of plugins that is actively maintained, released more on >>> a regular basis. Reduce the surface area of what we have to make great >>> because we honestly don't do a great job of releasing core plugins often >>> enough. We should focus on the plugins in the core lifecycles, and we >>> should be doing this well. Anything else we should really let a community >>> have better access to and push it out to Mojo or Github. Plugins that are >>> here people naturally, for whatever reason, assume we actively maintain >>> them and we don't. I would rather do fewer things well. >> >> I agree with you that we need to be able to support the stuff that we >> house. If we can't maintain it we need to let it go. >> >> But what has that got to do with site generation and reporting plugins? >> > > Additionally I think it would be stellar if we had core build lifecycle > plugins, heavily used but not lifecycle related, and the site stuff. Augment > the release tooling so that we could make consistent releases across a tree > for plugins that have changed on a known 6 week cycle. The release plugin > would have to be changed but this would make it easier to prepare for a > release cycle, and push out all related plugins together. Then users will > come to expect these regular release cycles which I think have been a great > benefit at Eclipse whose process I'm copying. Projects are not allowed to > survive very long missing release schedules in the real world. Even though > this is an open source project we can do the same. We simply reduce the > surface to the size we can honestly manage that process. It's more honest and > better for users. This is interesting stuff. Can you start a new thread about this, so it doesn't get buried here in this site/reporting thread. Perhaps a proposal in Confluence? > >>> > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > You are never dedicated to something you have complete confidence in. > No one is fanatically shouting that the sun is going to rise tomorrow. > They know it is going to rise tomorrow. When people are fanatically > dedicated to political or religious faiths or any other kind of > dogmas or goals, it's always because these dogmas or > goals are in doubt. > > -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance > > > > -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> Thanks, >>> >>> Jason >>> >>> -- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> - >>> >>> the course of true love never did run smooth ... >>> >>> -- Shakespeare >>> >>> >>> >>> >> >> >> -- >> Dennis Lundberg >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > First, the taking in of scattered particulars under one Idea, > so that everyone understands what is being talked about ... Second, > the separation of the Idea into parts, by dividing it at the joints, > as nature directs, not breaking any limb in half as a bad carver might. > > -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) > > > > -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr..
Re: Moving all reporting to a site project
On 2010-11-01 23:12, Jason van Zyl wrote: > On Nov 1, 2010, at 11:01 PM, Dennis Lundberg wrote: > >> On 2010-11-01 22:48, Jason van Zyl wrote: >>> On Nov 1, 2010, at 10:41 PM, Dennis Lundberg wrote: >>> On 2010-11-01 13:41, Jason van Zyl wrote: > In much the same way we have a little sub-project for releasing I think > it's time to have one for the site generation. Take the maven-site-plugin > and any related plugins and move them into their own tree. What I'm > trying to do here is cull the set of plugins we have is to keep the ones > that are part of the core lifecycles and super popular plugins that get > maintained like the dependency plugin and enforcer plugin. I'm not sure I understand what we would gain by doing this, if we cull all the dead/inactive plugins. Can you elaborate some more? >>> >>> That we have a set of plugins that is actively maintained, released more on >>> a regular basis. Reduce the surface area of what we have to make great >>> because we honestly don't do a great job of releasing core plugins often >>> enough. We should focus on the plugins in the core lifecycles, and we >>> should be doing this well. Anything else we should really let a community >>> have better access to and push it out to Mojo or Github. Plugins that are >>> here people naturally, for whatever reason, assume we actively maintain >>> them and we don't. I would rather do fewer things well. >> >> I agree with you that we need to be able to support the stuff that we >> house. If we can't maintain it we need to let it go. >> >> But what has that got to do with site generation and reporting plugins? >> > > First, to fully decouple build from site. That I'm not saying to nuke those > plugins but to separation. Look how easy the plugins themselves conflate > concerns and look how easily we polluted the core with site generating and > reporting. I think fully separation of the housing of the plugins and the > logic within plugins is a good separation of concerns. Additionally I think > we can all agree that the build related plugins are an absolute must to > maintain. I for one think the site plugin will see it's demise with static > documentation being sourced from wikis a la WikiModel and projects like > WikiText at Eclipse and trending information being produced by Sonar. That's > just my opinion, but the separation of concerns I believe is reason enough to > separate them. Is this not exactly what we did the release tooling? I think > it only follows what we've already started. The separation of concerns is a worthy goal. Like I wrote in another mail I think some B+R plugins have their build and reporting code intertwined. Splitting that up might be difficult and we could end up with a bunch of new shared components, say for example a checkstyle-commons. Before we decide how to store the plugins in an SCM, we should work through the "tainted" plugins one at a time, and try to split build from reporting. The result of the split might look different than we first expected it to. When it comes to the importance and future we have different opinions, but then again that is nothing new :) >>> > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > You are never dedicated to something you have complete confidence in. > No one is fanatically shouting that the sun is going to rise tomorrow. > They know it is going to rise tomorrow. When people are fanatically > dedicated to political or religious faiths or any other kind of > dogmas or goals, it's always because these dogmas or > goals are in doubt. > > -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance > > > > -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> Thanks, >>> >>> Jason >>> >>> -- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> - >>> >>> the course of true love never did run smooth ... >>> >>> -- Shakespeare >>> >>> >>> >>> >> >> >> -- >> Dennis Lundberg >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > Our achievem
Re: Culling the maven-stage-plugin
On Mon, Nov 1, 2010 at 2:15 PM, Jason van Zyl wrote: > > On Nov 1, 2010, at 10:12 PM, Dennis Lundberg wrote: > >> On 2010-11-01 18:54, Jason van Zyl wrote: >>> Doesn't change the fact it's a hack, generally not useful and is generally >>> not going to get used. >> >> It actually is being used. >> >>> Dennis, are you committed to supporting it? >> >> My plan is to close as many issues as I can and release a 1.0, to get >> rid of one of the last beta-version-plugins :) >> >> After that I'm done with it. >> >> I do think that this is a useful plugin for those that do not, for >> whatever reason, have a repository manager, despite its warts. Perhaps a >> plugin that could move to the Mojo project? >> There is no need to move stage plugin to MOJO since wagon-maven-plugin covers that feature. > > That seems most sensible given the guy you applied the patch for could have > done it himself at Mojo. > >>> If so, that's fine, but it's a dead end plugin as far as I'm concerned. >>> Who's going to use it when all the repository managers have some form of >>> staging? >>> >>> On Nov 1, 2010, at 6:47 PM, Brett Porter wrote: >>> Dennis committed to it just yesterday, so I think calling it unsupported is premature. On 01/11/2010, at 8:39 AM, Jason van Zyl wrote: > This was a hack, and has now been replaced with Nexus staging here at > Apache (and most other forges). I believe this plugin can be archived > now. > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > You are never dedicated to something you have complete confidence in. > No one is fanatically shouting that the sun is going to rise tomorrow. > They know it is going to rise tomorrow. When people are fanatically > dedicated to political or religious faiths or any other kind of > dogmas or goals, it's always because these dogmas or > goals are in doubt. > > -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance > > > -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> Thanks, >>> >>> Jason >>> >>> -- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> - >>> >>> We all have problems. How we deal with them is a measure of our worth. >>> >>> -- Unknown >>> >>> >>> >>> >> >> >> -- >> Dennis Lundberg >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > Simplex sigillum veri. (Simplicity is the seal of truth.) > > > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Why are you so quick (Was: Culling dead/inactive plugins)
2010/11/1 Jason van Zyl : > > On Nov 1, 2010, at 10:59 PM, Vincent Siveton wrote: > >> Hi, >> >> I agree in the fact to move unmaintened plugins but god, why are you >> so quick one more time! >> You asked Dennis to create a wiki page but you already retired the >> plugins. > > Yes, because I wouldn't write a wiki page, but if he wants some process then > the process has to be documented. Now that I have time to work, I start and > that's how I started. If I started erasing the plugins that would be > different. > >> Ok I know we could revert your changes but why send us an >> email and move them 2 min after! We are a community Jason! >> > > And I'll happily abide by stuff we document. > Which are? Removing plugins without updating our website? Think about our final users! I know that documentation is not your strong but you (or someone else) should update our documentation (ie src/site/apt/plugins/index.apt similar to http://mojo.codehaus.org/plugins.html#Plugin_Graveyard) Vincent - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Moving all reporting to a site project
On Nov 1, 2010, at 11:01 PM, Dennis Lundberg wrote: > On 2010-11-01 22:48, Jason van Zyl wrote: >> On Nov 1, 2010, at 10:41 PM, Dennis Lundberg wrote: >> >>> On 2010-11-01 13:41, Jason van Zyl wrote: In much the same way we have a little sub-project for releasing I think it's time to have one for the site generation. Take the maven-site-plugin and any related plugins and move them into their own tree. What I'm trying to do here is cull the set of plugins we have is to keep the ones that are part of the core lifecycles and super popular plugins that get maintained like the dependency plugin and enforcer plugin. >>> >>> I'm not sure I understand what we would gain by doing this, if we cull >>> all the dead/inactive plugins. Can you elaborate some more? >>> >> >> That we have a set of plugins that is actively maintained, released more on >> a regular basis. Reduce the surface area of what we have to make great >> because we honestly don't do a great job of releasing core plugins often >> enough. We should focus on the plugins in the core lifecycles, and we should >> be doing this well. Anything else we should really let a community have >> better access to and push it out to Mojo or Github. Plugins that are here >> people naturally, for whatever reason, assume we actively maintain them and >> we don't. I would rather do fewer things well. > > I agree with you that we need to be able to support the stuff that we > house. If we can't maintain it we need to let it go. > > But what has that got to do with site generation and reporting plugins? > Additionally I think it would be stellar if we had core build lifecycle plugins, heavily used but not lifecycle related, and the site stuff. Augment the release tooling so that we could make consistent releases across a tree for plugins that have changed on a known 6 week cycle. The release plugin would have to be changed but this would make it easier to prepare for a release cycle, and push out all related plugins together. Then users will come to expect these regular release cycles which I think have been a great benefit at Eclipse whose process I'm copying. Projects are not allowed to survive very long missing release schedules in the real world. Even though this is an open source project we can do the same. We simply reduce the surface to the size we can honestly manage that process. It's more honest and better for users. >> Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance >>> >>> >>> -- >>> Dennis Lundberg >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> the course of true love never did run smooth ... >> >> -- Shakespeare >> >> >> >> > > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
Re: Moving all reporting to a site project
On Nov 1, 2010, at 11:01 PM, Dennis Lundberg wrote: > On 2010-11-01 22:48, Jason van Zyl wrote: >> On Nov 1, 2010, at 10:41 PM, Dennis Lundberg wrote: >> >>> On 2010-11-01 13:41, Jason van Zyl wrote: In much the same way we have a little sub-project for releasing I think it's time to have one for the site generation. Take the maven-site-plugin and any related plugins and move them into their own tree. What I'm trying to do here is cull the set of plugins we have is to keep the ones that are part of the core lifecycles and super popular plugins that get maintained like the dependency plugin and enforcer plugin. >>> >>> I'm not sure I understand what we would gain by doing this, if we cull >>> all the dead/inactive plugins. Can you elaborate some more? >>> >> >> That we have a set of plugins that is actively maintained, released more on >> a regular basis. Reduce the surface area of what we have to make great >> because we honestly don't do a great job of releasing core plugins often >> enough. We should focus on the plugins in the core lifecycles, and we should >> be doing this well. Anything else we should really let a community have >> better access to and push it out to Mojo or Github. Plugins that are here >> people naturally, for whatever reason, assume we actively maintain them and >> we don't. I would rather do fewer things well. > > I agree with you that we need to be able to support the stuff that we > house. If we can't maintain it we need to let it go. > > But what has that got to do with site generation and reporting plugins? > First, to fully decouple build from site. That I'm not saying to nuke those plugins but to separation. Look how easy the plugins themselves conflate concerns and look how easily we polluted the core with site generating and reporting. I think fully separation of the housing of the plugins and the logic within plugins is a good separation of concerns. Additionally I think we can all agree that the build related plugins are an absolute must to maintain. I for one think the site plugin will see it's demise with static documentation being sourced from wikis a la WikiModel and projects like WikiText at Eclipse and trending information being produced by Sonar. That's just my opinion, but the separation of concerns I believe is reason enough to separate them. Is this not exactly what we did the release tooling? I think it only follows what we've already started. >> Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance >>> >>> >>> -- >>> Dennis Lundberg >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> the course of true love never did run smooth ... >> >> -- Shakespeare >> >> >> >> > > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition
Re: Why are you so quick (Was: Culling dead/inactive plugins)
On Nov 1, 2010, at 10:59 PM, Vincent Siveton wrote: > Hi, > > I agree in the fact to move unmaintened plugins but god, why are you > so quick one more time! > You asked Dennis to create a wiki page but you already retired the > plugins. Yes, because I wouldn't write a wiki page, but if he wants some process then the process has to be documented. Now that I have time to work, I start and that's how I started. If I started erasing the plugins that would be different. > Ok I know we could revert your changes but why send us an > email and move them 2 min after! We are a community Jason! > And I'll happily abide by stuff we document. > Cheers, > > Vincent > > -- Forwarded message -- > From: Jason van Zyl > Date: 2010/11/1 > Subject: Re: Culling dead/inactive plugins > To: Maven Developers List > > > I started moving any of the ones discussed here: > > http://svn.apache.org/repos/asf/maven/retired/ > > If anyone disagrees we can move them back but I think the ones suggest > so far are good candidates. > > On Nov 1, 2010, at 1:37 PM, Jason van Zyl wrote: > >> Following up from a discussion on the user list. I think it's time to be >> realistic about providing a healthy level of support for plugins here. I >> think it makes more sense to reduce the foot print of plugins we say we >> support and do those well as opposed to housing many plugin that just don't >> get much love. I would ask people to think about the plugins we're housing >> that we shouldn't. Probably a thread per plugin would be fine for discussion. >> >> To that end the plugins I'll send the first thread. >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> Our achievements speak for themselves. What we have to keep track >> of are our failures, discouragements and doubts. We tend to forget >> the past difficulties, the many false starts, and the painful >> groping. We see our past achievements as the end result of a >> clean forward thrust, and our present difficulties as >> signs of decline and decay. >> >> -- Eric Hoffer, Reflections on the Human Condition >> >> >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > In short, man creates for himself a new religion of a rational > and technical order to justify his work and to be justified in it. > > -- Jacques Ellul, The Technological Society > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt
Re: Moving all reporting to a site project
On 2010-11-01 22:48, Jason van Zyl wrote: > On Nov 1, 2010, at 10:41 PM, Dennis Lundberg wrote: > >> On 2010-11-01 13:41, Jason van Zyl wrote: >>> In much the same way we have a little sub-project for releasing I think >>> it's time to have one for the site generation. Take the maven-site-plugin >>> and any related plugins and move them into their own tree. What I'm trying >>> to do here is cull the set of plugins we have is to keep the ones that are >>> part of the core lifecycles and super popular plugins that get maintained >>> like the dependency plugin and enforcer plugin. >> >> I'm not sure I understand what we would gain by doing this, if we cull >> all the dead/inactive plugins. Can you elaborate some more? >> > > That we have a set of plugins that is actively maintained, released more on a > regular basis. Reduce the surface area of what we have to make great because > we honestly don't do a great job of releasing core plugins often enough. We > should focus on the plugins in the core lifecycles, and we should be doing > this well. Anything else we should really let a community have better access > to and push it out to Mojo or Github. Plugins that are here people naturally, > for whatever reason, assume we actively maintain them and we don't. I would > rather do fewer things well. I agree with you that we need to be able to support the stuff that we house. If we can't maintain it we need to let it go. But what has that got to do with site generation and reporting plugins? > >>> Thanks, >>> >>> Jason >>> >>> -- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> - >>> >>> You are never dedicated to something you have complete confidence in. >>> No one is fanatically shouting that the sun is going to rise tomorrow. >>> They know it is going to rise tomorrow. When people are fanatically >>> dedicated to political or religious faiths or any other kind of >>> dogmas or goals, it's always because these dogmas or >>> goals are in doubt. >>> >>> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance >>> >>> >>> >>> >> >> >> -- >> Dennis Lundberg >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > the course of true love never did run smooth ... > > -- Shakespeare > > > > -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [PROPOSAL] Create a retirement plan for plugins
On Nov 1, 2010, at 10:57 PM, Dennis Lundberg wrote: > On 2010-11-01 22:38, Jason van Zyl wrote: >> Can you put this in Confluence. > > Sure, I'll just wait for some feedback first, then I'll summarize it in > Confluence. Once the wrinkles are ironed out I'll move it to the site. > >> I think we should include the addition of plugins as well ... as that's how >> we got here in the first place. New plugins, if we ever add anymore, should >> require the same rigor going in. > > Do you mean that we should describe how high the bar is for new plugins > to enter? > Yes, that we should be loathe to add new ones given how we have supported what's here. >> >> On Nov 1, 2010, at 10:35 PM, Dennis Lundberg wrote: >> >>> Hi >>> >>> Given the discussions about retiring plugin I feel strongly that we need >>> to have a plan for doing so. There are bound to be differing opinions >>> about this, so see this as a starting point for discussions. When we get >>> to the point that we agree on the general process, I'll turn this >>> discussion into a document and put into our site. >>> >>> >>> 1. Propose a vote on the dev-list to retire a plugin. The vote should be >>> open for the standard 72 hours to allow people to voice their opinions. >>> Perhaps also send this to the users-list? >>> >>> >>> 2. Decide how to retire the plugin (don't know whether this should be a >>> vote or not, or perhaps incorporated into 1.). There are multiple >>> scenarios available. Two have been suggested in the other threads: >>> >>> 2.1 Move to retired area in svn >>> >>> 2.2 Move to mojo.codehaus.org >>> >>> please add more possible actions here >>> >>> >>> 3. Make one final release of the plugin before it goes away. This allows >>> us to make a clean break. The final release should have the site changed >>> so that SCM URLs are changed or removed to reflect the decision made >>> under 2. If the plugin is moved elsewhere a prominent notice should be >>> placed on the front page of the plugin's site. >>> >>> To respond to the inevitable "why bother" responses I hereby volunteer >>> to do all those releases, if no one else steps up. >>> >>> >>> 4. Announce the fact that the plugin has been retired/moved/whatever on >>> the annou...@m.a.o and us...@m.a.o mailing lists. Explain to people what >>> they should do if they would like to help with the continued development >>> of the plugin at some other place. >>> >>> >>> >>> Opinions, comments are welcome >>> >>> -- >>> Dennis Lundberg >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> In short, man creates for himself a new religion of a rational >> and technical order to justify his work and to be justified in it. >> >> -- Jacques Ellul, The Technological Society >> >> >> >> > > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -
Why are you so quick (Was: Culling dead/inactive plugins)
Hi, I agree in the fact to move unmaintened plugins but god, why are you so quick one more time! You asked Dennis to create a wiki page but you already retired the plugins. Ok I know we could revert your changes but why send us an email and move them 2 min after! We are a community Jason! Cheers, Vincent -- Forwarded message -- From: Jason van Zyl Date: 2010/11/1 Subject: Re: Culling dead/inactive plugins To: Maven Developers List I started moving any of the ones discussed here: http://svn.apache.org/repos/asf/maven/retired/ If anyone disagrees we can move them back but I think the ones suggest so far are good candidates. On Nov 1, 2010, at 1:37 PM, Jason van Zyl wrote: > Following up from a discussion on the user list. I think it's time to be > realistic about providing a healthy level of support for plugins here. I > think it makes more sense to reduce the foot print of plugins we say we > support and do those well as opposed to housing many plugin that just don't > get much love. I would ask people to think about the plugins we're housing > that we shouldn't. Probably a thread per plugin would be fine for discussion. > > To that end the plugins I'll send the first thread. > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > Our achievements speak for themselves. What we have to keep track > of are our failures, discouragements and doubts. We tend to forget > the past difficulties, the many false starts, and the painful > groping. We see our past achievements as the end result of a > clean forward thrust, and our present difficulties as > signs of decline and decay. > > -- Eric Hoffer, Reflections on the Human Condition > > > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [PROPOSAL] Create a retirement plan for plugins
On 2010-11-01 22:38, Jason van Zyl wrote: > Can you put this in Confluence. Sure, I'll just wait for some feedback first, then I'll summarize it in Confluence. Once the wrinkles are ironed out I'll move it to the site. > I think we should include the addition of plugins as well ... as that's how > we got here in the first place. New plugins, if we ever add anymore, should > require the same rigor going in. Do you mean that we should describe how high the bar is for new plugins to enter? > > On Nov 1, 2010, at 10:35 PM, Dennis Lundberg wrote: > >> Hi >> >> Given the discussions about retiring plugin I feel strongly that we need >> to have a plan for doing so. There are bound to be differing opinions >> about this, so see this as a starting point for discussions. When we get >> to the point that we agree on the general process, I'll turn this >> discussion into a document and put into our site. >> >> >> 1. Propose a vote on the dev-list to retire a plugin. The vote should be >> open for the standard 72 hours to allow people to voice their opinions. >> Perhaps also send this to the users-list? >> >> >> 2. Decide how to retire the plugin (don't know whether this should be a >> vote or not, or perhaps incorporated into 1.). There are multiple >> scenarios available. Two have been suggested in the other threads: >> >> 2.1 Move to retired area in svn >> >> 2.2 Move to mojo.codehaus.org >> >> please add more possible actions here >> >> >> 3. Make one final release of the plugin before it goes away. This allows >> us to make a clean break. The final release should have the site changed >> so that SCM URLs are changed or removed to reflect the decision made >> under 2. If the plugin is moved elsewhere a prominent notice should be >> placed on the front page of the plugin's site. >> >> To respond to the inevitable "why bother" responses I hereby volunteer >> to do all those releases, if no one else steps up. >> >> >> 4. Announce the fact that the plugin has been retired/moved/whatever on >> the annou...@m.a.o and us...@m.a.o mailing lists. Explain to people what >> they should do if they would like to help with the continued development >> of the plugin at some other place. >> >> >> >> Opinions, comments are welcome >> >> -- >> Dennis Lundberg >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > In short, man creates for himself a new religion of a rational > and technical order to justify his work and to be justified in it. > > -- Jacques Ellul, The Technological Society > > > > -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [vote] release maven parent 17
+1 On Nov 1, 2010, at 10:51 PM, Brian Fox wrote: > I'm preparing the enforcer release and it needs the latest parent > changes, so I've cut a release: > > Staged parent: > https://repository.apache.org/service/local/repositories/maven-008/content/org/apache/maven/maven-parent/17/maven-parent-17.pom > > +1 > > Vote 72 hrs > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
Re: Moving all reporting to a site project
On 2010-11-01 22:33, Jason van Zyl wrote: > On Nov 1, 2010, at 2:42 PM, Olivier Lamy wrote: > >> +1. >> I can be a volunteer for site stuff.. >> >> Question : what do we do with site plugin 2.x and 3.x branch ? >> >> Personnally : I'd like to move only 3.x branch in this new project. >> >> > > I would suggest these are the plugins that go as part of the site generation: To see which plugins are on the table go to http://maven.apache.org/plugins/index.html and check the "Type" column. If a plugin has an "R" in that column it is site related. Plugins that have "B+R" can be difficult to divide into two plugins in an easy way. Parts of the code is shared between the "build" part and the "reporting" part of the plugin. If the code is splitable, the reporting part could form a new plugin called "Old Name *Report* Plugin", like we have for Surefire. > maven-changelog-plugin > maven-changes-plugin No sure how to handle the announcement stuff in there. > maven-checkstyle-plugin Contains possible build-breaking hooks. > maven-doap-plugin > maven-javadoc-plugin For me this is part of the build as much as it is the site, since we attach the javadocs when deploying artifacts. > maven-linkcheck-plugin > maven-pdf-plugin > maven-pmd-plugin Contains possible build-breaking hooks. > maven-project-info-reports-plugin > maven-site-plugin > maven-source-plugin Has nothing to do with the site. > >> 2010/11/1 Jason van Zyl : >>> In much the same way we have a little sub-project for releasing I think >>> it's time to have one for the site generation. Take the maven-site-plugin >>> and any related plugins and move them into their own tree. What I'm trying >>> to do here is cull the set of plugins we have is to keep the ones that are >>> part of the core lifecycles and super popular plugins that get maintained >>> like the dependency plugin and enforcer plugin. >>> >>> Thanks, >>> >>> Jason >>> >>> -- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> - >>> >>> You are never dedicated to something you have complete confidence in. >>> No one is fanatically shouting that the sun is going to rise tomorrow. >>> They know it is going to rise tomorrow. When people are fanatically >>> dedicated to political or religious faiths or any other kind of >>> dogmas or goals, it's always because these dogmas or >>> goals are in doubt. >>> >>> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance >>> >>> >>> >>> >> >> >> >> -- >> Olivier Lamy >> http://twitter.com/olamy >> http://www.linkedin.com/in/olamy >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > > > > -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[vote] release maven parent 17
I'm preparing the enforcer release and it needs the latest parent changes, so I've cut a release: Staged parent: https://repository.apache.org/service/local/repositories/maven-008/content/org/apache/maven/maven-parent/17/maven-parent-17.pom +1 Vote 72 hrs - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Moving all reporting to a site project
Yup. Cut/paste error. On Nov 1, 2010, at 10:49 PM, Benjamin Bentmann wrote: > Jason van Zyl wrote: > >> I would suggest these are the plugins that go as part of the site generation: >> [...] >> maven-source-plugin > > I think the maven-source-plugin is misclassified here, it doesn't have any > reporting code. > > > Benjamin > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -
Re: Moving all reporting to a site project
Jason van Zyl wrote: I would suggest these are the plugins that go as part of the site generation: [...] maven-source-plugin I think the maven-source-plugin is misclassified here, it doesn't have any reporting code. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Moving all reporting to a site project
On Nov 1, 2010, at 10:41 PM, Dennis Lundberg wrote: > On 2010-11-01 13:41, Jason van Zyl wrote: >> In much the same way we have a little sub-project for releasing I think it's >> time to have one for the site generation. Take the maven-site-plugin and any >> related plugins and move them into their own tree. What I'm trying to do >> here is cull the set of plugins we have is to keep the ones that are part of >> the core lifecycles and super popular plugins that get maintained like the >> dependency plugin and enforcer plugin. > > I'm not sure I understand what we would gain by doing this, if we cull > all the dead/inactive plugins. Can you elaborate some more? > That we have a set of plugins that is actively maintained, released more on a regular basis. Reduce the surface area of what we have to make great because we honestly don't do a great job of releasing core plugins often enough. We should focus on the plugins in the core lifecycles, and we should be doing this well. Anything else we should really let a community have better access to and push it out to Mojo or Github. Plugins that are here people naturally, for whatever reason, assume we actively maintain them and we don't. I would rather do fewer things well. >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> You are never dedicated to something you have complete confidence in. >> No one is fanatically shouting that the sun is going to rise tomorrow. >> They know it is going to rise tomorrow. When people are fanatically >> dedicated to political or religious faiths or any other kind of >> dogmas or goals, it's always because these dogmas or >> goals are in doubt. >> >> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance >> >> >> >> > > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare
Re: Moving all reporting to a site project
On 2010-11-01 13:41, Jason van Zyl wrote: > In much the same way we have a little sub-project for releasing I think it's > time to have one for the site generation. Take the maven-site-plugin and any > related plugins and move them into their own tree. What I'm trying to do here > is cull the set of plugins we have is to keep the ones that are part of the > core lifecycles and super popular plugins that get maintained like the > dependency plugin and enforcer plugin. I'm not sure I understand what we would gain by doing this, if we cull all the dead/inactive plugins. Can you elaborate some more? > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > You are never dedicated to something you have complete confidence in. > No one is fanatically shouting that the sun is going to rise tomorrow. > They know it is going to rise tomorrow. When people are fanatically > dedicated to political or religious faiths or any other kind of > dogmas or goals, it's always because these dogmas or > goals are in doubt. > > -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance > > > > -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Culling dead/inactive plugins
On Nov 1, 2010, at 10:37 PM, Dennis Lundberg wrote: > On 2010-11-01 22:10, Stephen Connolly wrote: >> Then -1 the commits. >> >> We have a commit first, ask forgiveness second policy in maven last time I >> checked > > So do you think that it's OK for someone to pull the rug from under your > feet, while you are working on something? > Happens to me every so often, I know it's not intention as it wasn't in this case. > (as in my work on the Stage Plugin) > >> - Stephen >> >> On 1 Nov 2010 21:05, "Dennis Lundberg" wrote: >> >> Hi Jason >> >> Doing some house cleaning among our plugins is a good thing, and I'm in >> favor of retiring those that we feel that we cannot support. >> >> However it is not OK for you to go changing things in Subversion less >> than an hour after your proposal (which wasn't even labeled as one). >> That is not the way we do business here. For starters, people are on >> different time zones. Secondly I feel that retiring a plugin is >> something that should require a vote. Finally moving the stuff around in >> Subversion will break links from the plugin sites and a lot of other >> places. Please restore things in Subversion to how they were. >> >> >> On 2010-11-01 13:37, Jason van Zyl wrote: >>> Following up from a discussion on the user list. I thin... >> -- >> Dennis Lundberg >> >> >> - >> To unsubscribe, e-mail: dev-u... >> > > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language
Re: [PROPOSAL] Create a retirement plan for plugins
Can you put this in Confluence. I think we should include the addition of plugins as well ... as that's how we got here in the first place. New plugins, if we ever add anymore, should require the same rigor going in. On Nov 1, 2010, at 10:35 PM, Dennis Lundberg wrote: > Hi > > Given the discussions about retiring plugin I feel strongly that we need > to have a plan for doing so. There are bound to be differing opinions > about this, so see this as a starting point for discussions. When we get > to the point that we agree on the general process, I'll turn this > discussion into a document and put into our site. > > > 1. Propose a vote on the dev-list to retire a plugin. The vote should be > open for the standard 72 hours to allow people to voice their opinions. > Perhaps also send this to the users-list? > > > 2. Decide how to retire the plugin (don't know whether this should be a > vote or not, or perhaps incorporated into 1.). There are multiple > scenarios available. Two have been suggested in the other threads: > > 2.1 Move to retired area in svn > > 2.2 Move to mojo.codehaus.org > > please add more possible actions here > > > 3. Make one final release of the plugin before it goes away. This allows > us to make a clean break. The final release should have the site changed > so that SCM URLs are changed or removed to reflect the decision made > under 2. If the plugin is moved elsewhere a prominent notice should be > placed on the front page of the plugin's site. > > To respond to the inevitable "why bother" responses I hereby volunteer > to do all those releases, if no one else steps up. > > > 4. Announce the fact that the plugin has been retired/moved/whatever on > the annou...@m.a.o and us...@m.a.o mailing lists. Explain to people what > they should do if they would like to help with the continued development > of the plugin at some other place. > > > > Opinions, comments are welcome > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society
Re: Culling dead/inactive plugins
On 2010-11-01 22:10, Stephen Connolly wrote: > Then -1 the commits. > > We have a commit first, ask forgiveness second policy in maven last time I > checked So do you think that it's OK for someone to pull the rug from under your feet, while you are working on something? (as in my work on the Stage Plugin) > - Stephen > > On 1 Nov 2010 21:05, "Dennis Lundberg" wrote: > > Hi Jason > > Doing some house cleaning among our plugins is a good thing, and I'm in > favor of retiring those that we feel that we cannot support. > > However it is not OK for you to go changing things in Subversion less > than an hour after your proposal (which wasn't even labeled as one). > That is not the way we do business here. For starters, people are on > different time zones. Secondly I feel that retiring a plugin is > something that should require a vote. Finally moving the stuff around in > Subversion will break links from the plugin sites and a lot of other > places. Please restore things in Subversion to how they were. > > > On 2010-11-01 13:37, Jason van Zyl wrote: >> Following up from a discussion on the user list. I thin... > -- > Dennis Lundberg > > > - > To unsubscribe, e-mail: dev-u... > -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[PROPOSAL] Create a retirement plan for plugins
Hi Given the discussions about retiring plugin I feel strongly that we need to have a plan for doing so. There are bound to be differing opinions about this, so see this as a starting point for discussions. When we get to the point that we agree on the general process, I'll turn this discussion into a document and put into our site. 1. Propose a vote on the dev-list to retire a plugin. The vote should be open for the standard 72 hours to allow people to voice their opinions. Perhaps also send this to the users-list? 2. Decide how to retire the plugin (don't know whether this should be a vote or not, or perhaps incorporated into 1.). There are multiple scenarios available. Two have been suggested in the other threads: 2.1 Move to retired area in svn 2.2 Move to mojo.codehaus.org please add more possible actions here 3. Make one final release of the plugin before it goes away. This allows us to make a clean break. The final release should have the site changed so that SCM URLs are changed or removed to reflect the decision made under 2. If the plugin is moved elsewhere a prominent notice should be placed on the front page of the plugin's site. To respond to the inevitable "why bother" responses I hereby volunteer to do all those releases, if no one else steps up. 4. Announce the fact that the plugin has been retired/moved/whatever on the annou...@m.a.o and us...@m.a.o mailing lists. Explain to people what they should do if they would like to help with the continued development of the plugin at some other place. Opinions, comments are welcome -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Moving all reporting to a site project
On Nov 1, 2010, at 2:42 PM, Olivier Lamy wrote: > +1. > I can be a volunteer for site stuff.. > > Question : what do we do with site plugin 2.x and 3.x branch ? > > Personnally : I'd like to move only 3.x branch in this new project. > > I would suggest these are the plugins that go as part of the site generation: maven-changelog-plugin maven-changes-plugin maven-checkstyle-plugin maven-doap-plugin maven-javadoc-plugin maven-linkcheck-plugin maven-pdf-plugin maven-pmd-plugin maven-project-info-reports-plugin maven-site-plugin maven-source-plugin > 2010/11/1 Jason van Zyl : >> In much the same way we have a little sub-project for releasing I think it's >> time to have one for the site generation. Take the maven-site-plugin and any >> related plugins and move them into their own tree. What I'm trying to do >> here is cull the set of plugins we have is to keep the ones that are part of >> the core lifecycles and super popular plugins that get maintained like the >> dependency plugin and enforcer plugin. >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> You are never dedicated to something you have complete confidence in. >> No one is fanatically shouting that the sun is going to rise tomorrow. >> They know it is going to rise tomorrow. When people are fanatically >> dedicated to political or religious faiths or any other kind of >> dogmas or goals, it's always because these dogmas or >> goals are in doubt. >> >> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance >> >> >> >> > > > > -- > Olivier Lamy > http://twitter.com/olamy > http://www.linkedin.com/in/olamy > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -
Re: Moving all reporting to a site project
On Nov 1, 2010, at 6:37 PM, Brett Porter wrote: > +1 to consolidating the site stuff (under doxia?) > > -0 to moving plugins that have non-site-specific capabilities (pmd, > checkstyle, etc.). Though these could be in a separate plugins tree for "tool > support", if they aren't going to be held by the official projects. > I think they are primarily used as site plugin and as such they should move with the site plugin. I agree there is a conflation of concerns. If someone wants to decouple build logic from reporting logic that would be great. > On 01/11/2010, at 9:42 AM, Olivier Lamy wrote: > >> +1. >> I can be a volunteer for site stuff.. >> >> Question : what do we do with site plugin 2.x and 3.x branch ? >> >> Personnally : I'd like to move only 3.x branch in this new project. >> >> >> 2010/11/1 Jason van Zyl : >>> In much the same way we have a little sub-project for releasing I think >>> it's time to have one for the site generation. Take the maven-site-plugin >>> and any related plugins and move them into their own tree. What I'm trying >>> to do here is cull the set of plugins we have is to keep the ones that are >>> part of the core lifecycles and super popular plugins that get maintained >>> like the dependency plugin and enforcer plugin. >>> >>> Thanks, >>> >>> Jason >>> >>> -- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> - >>> >>> You are never dedicated to something you have complete confidence in. >>> No one is fanatically shouting that the sun is going to rise tomorrow. >>> They know it is going to rise tomorrow. When people are fanatically >>> dedicated to political or religious faiths or any other kind of >>> dogmas or goals, it's always because these dogmas or >>> goals are in doubt. >>> >>> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance >>> >>> >>> >>> >> >> >> >> -- >> Olivier Lamy >> http://twitter.com/olamy >> http://www.linkedin.com/in/olamy >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > -- > Brett Porter > br...@apache.org > http://brettporter.wordpress.com/ > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Simplex sigillum veri. (Simplicity is the seal of truth.)
Re: Process [was Re: Culling dead/inactive plugins]
On 2010-11-01 22:14, Jason van Zyl wrote: > > On Nov 1, 2010, at 10:04 PM, Dennis Lundberg wrote: > >> Hi Jason >> >> Doing some house cleaning among our plugins is a good thing, and I'm in >> favor of retiring those that we feel that we cannot support. >> >> However it is not OK for you to go changing things in Subversion less >> than an hour after your proposal (which wasn't even labeled as one). >> That is not the way we do business here. For starters, people are on >> different time zones. Secondly I feel that retiring a plugin is >> something that should require a vote. Finally moving the stuff around in >> Subversion will break links from the plugin sites and a lot of other >> places. Please restore things in Subversion to how they were. >> > > As almost everything here, nothing is documented. > > I don't believe starting to cleanup requires a vote. It is also not > irreversible. > > I happen to disagree with you. If you want to document something and we vote > on the process that's fine by me. I've already started writing a proposal... > >> On 2010-11-01 13:37, Jason van Zyl wrote: >>> Following up from a discussion on the user list. I think it's time to be >>> realistic about providing a healthy level of support for plugins here. I >>> think it makes more sense to reduce the foot print of plugins we say we >>> support and do those well as opposed to housing many plugin that just don't >>> get much love. I would ask people to think about the plugins we're housing >>> that we shouldn't. Probably a thread per plugin would be fine for >>> discussion. >>> >>> To that end the plugins I'll send the first thread. >>> >>> Thanks, >>> >>> Jason >>> >>> -- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> - >>> >>> Our achievements speak for themselves. What we have to keep track >>> of are our failures, discouragements and doubts. We tend to forget >>> the past difficulties, the many false starts, and the painful >>> groping. We see our past achievements as the end result of a >>> clean forward thrust, and our present difficulties as >>> signs of decline and decay. >>> >>> -- Eric Hoffer, Reflections on the Human Condition >>> >>> >>> >>> >> >> >> -- >> Dennis Lundberg >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > In short, man creates for himself a new religion of a rational > and technical order to justify his work and to be justified in it. > > -- Jacques Ellul, The Technological Society > > > > -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Culling the maven-stage-plugin
On Nov 1, 2010, at 10:12 PM, Dennis Lundberg wrote: > On 2010-11-01 18:54, Jason van Zyl wrote: >> Doesn't change the fact it's a hack, generally not useful and is generally >> not going to get used. > > It actually is being used. > >> Dennis, are you committed to supporting it? > > My plan is to close as many issues as I can and release a 1.0, to get > rid of one of the last beta-version-plugins :) > > After that I'm done with it. > > I do think that this is a useful plugin for those that do not, for > whatever reason, have a repository manager, despite its warts. Perhaps a > plugin that could move to the Mojo project? > That seems most sensible given the guy you applied the patch for could have done it himself at Mojo. >> If so, that's fine, but it's a dead end plugin as far as I'm concerned. >> Who's going to use it when all the repository managers have some form of >> staging? >> >> On Nov 1, 2010, at 6:47 PM, Brett Porter wrote: >> >>> Dennis committed to it just yesterday, so I think calling it unsupported is >>> premature. >>> >>> On 01/11/2010, at 8:39 AM, Jason van Zyl wrote: >>> This was a hack, and has now been replaced with Nexus staging here at Apache (and most other forges). I believe this plugin can be archived now. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance >>> >>> -- >>> Brett Porter >>> br...@apache.org >>> http://brettporter.wordpress.com/ >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> We all have problems. How we deal with them is a measure of our worth. >> >> -- Unknown >> >> >> >> > > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Simplex sigillum veri. (Simplicity is the seal of truth.)
Process [was Re: Culling dead/inactive plugins]
On Nov 1, 2010, at 10:04 PM, Dennis Lundberg wrote: > Hi Jason > > Doing some house cleaning among our plugins is a good thing, and I'm in > favor of retiring those that we feel that we cannot support. > > However it is not OK for you to go changing things in Subversion less > than an hour after your proposal (which wasn't even labeled as one). > That is not the way we do business here. For starters, people are on > different time zones. Secondly I feel that retiring a plugin is > something that should require a vote. Finally moving the stuff around in > Subversion will break links from the plugin sites and a lot of other > places. Please restore things in Subversion to how they were. > As almost everything here, nothing is documented. I don't believe starting to cleanup requires a vote. It is also not irreversible. I happen to disagree with you. If you want to document something and we vote on the process that's fine by me. > On 2010-11-01 13:37, Jason van Zyl wrote: >> Following up from a discussion on the user list. I think it's time to be >> realistic about providing a healthy level of support for plugins here. I >> think it makes more sense to reduce the foot print of plugins we say we >> support and do those well as opposed to housing many plugin that just don't >> get much love. I would ask people to think about the plugins we're housing >> that we shouldn't. Probably a thread per plugin would be fine for >> discussion. >> >> To that end the plugins I'll send the first thread. >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> Our achievements speak for themselves. What we have to keep track >> of are our failures, discouragements and doubts. We tend to forget >> the past difficulties, the many false starts, and the painful >> groping. We see our past achievements as the end result of a >> clean forward thrust, and our present difficulties as >> signs of decline and decay. >> >> -- Eric Hoffer, Reflections on the Human Condition >> >> >> >> > > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society
Re: Culling Maven Verifier Plugin
+1 to retire it. On 2010-11-01 14:44, Benjamin Bentmann wrote: > http://maven.apache.org/plugins/maven-verifier-plugin/ > > Is that plugin (not to be confused with the shared maven-verifier > component) actually used? > > > Benjamin > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Culling Maven One Plugin
+1 to retire it On 2010-11-01 14:00, Benjamin Bentmann wrote: > http://maven.apache.org/plugins/maven-one-plugin/ > > I think we're past its usefullness. > > > Benjamin > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Culling the maven-stage-plugin
On 2010-11-01 18:54, Jason van Zyl wrote: > Doesn't change the fact it's a hack, generally not useful and is generally > not going to get used. It actually is being used. > Dennis, are you committed to supporting it? My plan is to close as many issues as I can and release a 1.0, to get rid of one of the last beta-version-plugins :) After that I'm done with it. I do think that this is a useful plugin for those that do not, for whatever reason, have a repository manager, despite its warts. Perhaps a plugin that could move to the Mojo project? > If so, that's fine, but it's a dead end plugin as far as I'm concerned. Who's > going to use it when all the repository managers have some form of staging? > > On Nov 1, 2010, at 6:47 PM, Brett Porter wrote: > >> Dennis committed to it just yesterday, so I think calling it unsupported is >> premature. >> >> On 01/11/2010, at 8:39 AM, Jason van Zyl wrote: >> >>> This was a hack, and has now been replaced with Nexus staging here at >>> Apache (and most other forges). I believe this plugin can be archived now. >>> >>> Thanks, >>> >>> Jason >>> >>> -- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> - >>> >>> You are never dedicated to something you have complete confidence in. >>> No one is fanatically shouting that the sun is going to rise tomorrow. >>> They know it is going to rise tomorrow. When people are fanatically >>> dedicated to political or religious faiths or any other kind of >>> dogmas or goals, it's always because these dogmas or >>> goals are in doubt. >>> >>> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance >>> >>> >>> >> >> -- >> Brett Porter >> br...@apache.org >> http://brettporter.wordpress.com/ >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > We all have problems. How we deal with them is a measure of our worth. > > -- Unknown > > > > -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Culling dead/inactive plugins
On Nov 1, 2010, at 10:04 PM, Dennis Lundberg wrote: > Hi Jason > > Doing some house cleaning among our plugins is a good thing, and I'm in > favor of retiring those that we feel that we cannot support. > > However it is not OK for you to go changing things in Subversion less > than an hour after your proposal (which wasn't even labeled as one). > That is not the way we do business here. For starters, people are on > different time zones. Secondly I feel that retiring a plugin is > something that should require a vote. Finally moving the stuff around in > Subversion will break links from the plugin sites and a lot of other > places. Please restore things in Subversion to how they were. > If people disagree sure, I will. The only plugin that seems to be in question is the stage plugin, are you willing to maintain it? > On 2010-11-01 13:37, Jason van Zyl wrote: >> Following up from a discussion on the user list. I think it's time to be >> realistic about providing a healthy level of support for plugins here. I >> think it makes more sense to reduce the foot print of plugins we say we >> support and do those well as opposed to housing many plugin that just don't >> get much love. I would ask people to think about the plugins we're housing >> that we shouldn't. Probably a thread per plugin would be fine for >> discussion. >> >> To that end the plugins I'll send the first thread. >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> Our achievements speak for themselves. What we have to keep track >> of are our failures, discouragements and doubts. We tend to forget >> the past difficulties, the many false starts, and the painful >> groping. We see our past achievements as the end result of a >> clean forward thrust, and our present difficulties as >> signs of decline and decay. >> >> -- Eric Hoffer, Reflections on the Human Condition >> >> >> >> > > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha
Re: Culling dead/inactive plugins
Then -1 the commits. We have a commit first, ask forgiveness second policy in maven last time I checked - Stephen On 1 Nov 2010 21:05, "Dennis Lundberg" wrote: Hi Jason Doing some house cleaning among our plugins is a good thing, and I'm in favor of retiring those that we feel that we cannot support. However it is not OK for you to go changing things in Subversion less than an hour after your proposal (which wasn't even labeled as one). That is not the way we do business here. For starters, people are on different time zones. Secondly I feel that retiring a plugin is something that should require a vote. Finally moving the stuff around in Subversion will break links from the plugin sites and a lot of other places. Please restore things in Subversion to how they were. On 2010-11-01 13:37, Jason van Zyl wrote: > Following up from a discussion on the user list. I thin... -- Dennis Lundberg - To unsubscribe, e-mail: dev-u...
Re: Culling dead/inactive plugins
Hi Jason Doing some house cleaning among our plugins is a good thing, and I'm in favor of retiring those that we feel that we cannot support. However it is not OK for you to go changing things in Subversion less than an hour after your proposal (which wasn't even labeled as one). That is not the way we do business here. For starters, people are on different time zones. Secondly I feel that retiring a plugin is something that should require a vote. Finally moving the stuff around in Subversion will break links from the plugin sites and a lot of other places. Please restore things in Subversion to how they were. On 2010-11-01 13:37, Jason van Zyl wrote: > Following up from a discussion on the user list. I think it's time to be > realistic about providing a healthy level of support for plugins here. I > think it makes more sense to reduce the foot print of plugins we say we > support and do those well as opposed to housing many plugin that just don't > get much love. I would ask people to think about the plugins we're housing > that we shouldn't. Probably a thread per plugin would be fine for discussion. > > To that end the plugins I'll send the first thread. > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > Our achievements speak for themselves. What we have to keep track > of are our failures, discouragements and doubts. We tend to forget > the past difficulties, the many false starts, and the painful > groping. We see our past achievements as the end result of a > clean forward thrust, and our present difficulties as > signs of decline and decay. > > -- Eric Hoffer, Reflections on the Human Condition > > > > -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Culling the maven-stage-plugin
On Nov 1, 2010, at 7:02 PM, Brett Porter wrote: > > On 01/11/2010, at 1:54 PM, Jason van Zyl wrote: > >> Doesn't change the fact it's a hack, generally not useful and is generally >> not going to get used. > > I don't disagree, but given it was just yesterday, I think Dennis should get > to finish what he's doing. He was applying a patch by Dan Tran who actually has access to Mojo. >> >> Dennis, are you committed to supporting it? >> >> If so, that's fine, but it's a dead end plugin as far as I'm concerned. >> Who's going to use it when all the repository managers have some form of >> staging? > > The Artifactory and Nexus OSS users? :) Unlikely in both cases. If you're sophisticated enough to use/want that functionality you want it done properly. > > /me ducks > > - Brett > > -- > Brett Porter > br...@apache.org > http://brettporter.wordpress.com/ > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition
Re: Culling the maven-stage-plugin
> > On 01/11/2010, at 1:54 PM, Jason van Zyl wrote: > >> Doesn't change the fact it's a hack, generally not useful and is >> generally not going to get used. > > I don't disagree, but given it was just yesterday, I think Dennis should > get to finish what he's doing. >> >> Dennis, are you committed to supporting it? >> >> If so, that's fine, but it's a dead end plugin as far as I'm concerned. >> Who's going to use it when all the repository managers have some form of >> staging? > > The Artifactory and Nexus OSS users? :) > > /me ducks Haha... thanks for saying that Brett. You made me laugh ... I guess I gotta duck now too. Whoosh... by it went.. manfred - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Culling the maven-stage-plugin
On 01/11/2010, at 1:54 PM, Jason van Zyl wrote: > Doesn't change the fact it's a hack, generally not useful and is generally > not going to get used. I don't disagree, but given it was just yesterday, I think Dennis should get to finish what he's doing. > > Dennis, are you committed to supporting it? > > If so, that's fine, but it's a dead end plugin as far as I'm concerned. Who's > going to use it when all the repository managers have some form of staging? The Artifactory and Nexus OSS users? :) /me ducks - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Culling the maven-stage-plugin
Doesn't change the fact it's a hack, generally not useful and is generally not going to get used. Dennis, are you committed to supporting it? If so, that's fine, but it's a dead end plugin as far as I'm concerned. Who's going to use it when all the repository managers have some form of staging? On Nov 1, 2010, at 6:47 PM, Brett Porter wrote: > Dennis committed to it just yesterday, so I think calling it unsupported is > premature. > > On 01/11/2010, at 8:39 AM, Jason van Zyl wrote: > >> This was a hack, and has now been replaced with Nexus staging here at Apache >> (and most other forges). I believe this plugin can be archived now. >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> You are never dedicated to something you have complete confidence in. >> No one is fanatically shouting that the sun is going to rise tomorrow. >> They know it is going to rise tomorrow. When people are fanatically >> dedicated to political or religious faiths or any other kind of >> dogmas or goals, it's always because these dogmas or >> goals are in doubt. >> >> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance >> >> >> > > -- > Brett Porter > br...@apache.org > http://brettporter.wordpress.com/ > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - We all have problems. How we deal with them is a measure of our worth. -- Unknown
Re: Culling the maven-stage-plugin
Dennis committed to it just yesterday, so I think calling it unsupported is premature. On 01/11/2010, at 8:39 AM, Jason van Zyl wrote: > This was a hack, and has now been replaced with Nexus staging here at Apache > (and most other forges). I believe this plugin can be archived now. > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > You are never dedicated to something you have complete confidence in. > No one is fanatically shouting that the sun is going to rise tomorrow. > They know it is going to rise tomorrow. When people are fanatically > dedicated to political or religious faiths or any other kind of > dogmas or goals, it's always because these dogmas or > goals are in doubt. > > -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance > > > -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Culling Maven Verifier Plugin
On 01/11/2010, at 1:29 PM, Jörg Schaible wrote: > Benjamin Bentmann wrote: > >> http://maven.apache.org/plugins/maven-verifier-plugin/ >> >> Is that plugin (not to be confused with the shared maven-verifier >> component) actually used? > > Yes. It's handly for verifying templated run scripts or stuff like that. The old versions will still be around, it's just a question of maintenance. I don't think it's been changed in years or will be changed. I'm +1 to retire it. Perhaps someone would like to volunteer to fold some of the different capabilities together into one plugin... - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Culling maven-idea-plugin
+1 to retire it On 01/11/2010, at 8:54 AM, Kristian Rosenvold wrote: > The built-in support from jetbrains has been excellent since version 7, > not much point in keeping this one around. > > Kristian > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Culling Maven One Plugin
+1 to retire it On 01/11/2010, at 9:00 AM, Benjamin Bentmann wrote: > http://maven.apache.org/plugins/maven-one-plugin/ > > I think we're past its usefullness. > > > Benjamin > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Moving all reporting to a site project
+1 to consolidating the site stuff (under doxia?) -0 to moving plugins that have non-site-specific capabilities (pmd, checkstyle, etc.). Though these could be in a separate plugins tree for "tool support", if they aren't going to be held by the official projects. On 01/11/2010, at 9:42 AM, Olivier Lamy wrote: > +1. > I can be a volunteer for site stuff.. > > Question : what do we do with site plugin 2.x and 3.x branch ? > > Personnally : I'd like to move only 3.x branch in this new project. > > > 2010/11/1 Jason van Zyl : >> In much the same way we have a little sub-project for releasing I think it's >> time to have one for the site generation. Take the maven-site-plugin and any >> related plugins and move them into their own tree. What I'm trying to do >> here is cull the set of plugins we have is to keep the ones that are part of >> the core lifecycles and super popular plugins that get maintained like the >> dependency plugin and enforcer plugin. >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> You are never dedicated to something you have complete confidence in. >> No one is fanatically shouting that the sun is going to rise tomorrow. >> They know it is going to rise tomorrow. When people are fanatically >> dedicated to political or religious faiths or any other kind of >> dogmas or goals, it's always because these dogmas or >> goals are in doubt. >> >> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance >> >> >> >> > > > > -- > Olivier Lamy > http://twitter.com/olamy > http://www.linkedin.com/in/olamy > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Deprecate eclipse:eclipse plugin
Go for it. I'm going to help retire them, after that it's fair game. So if you, and the folks who might want to work on it, are cool with that then take it over there. My only concern is that we don't claim to support plugins that we have no real intention of supporting. Having them in our SCM is an implicit claim to support them. Just letting them sit there hoping people contribute patches I don't think is good enough. So if you want to give the maven-eclipse-plugin a happy life at Mojo then just take it there. On Nov 1, 2010, at 6:28 PM, Jörg Schaible wrote: > Jason van Zyl wrote: > >> >> On Nov 1, 2010, at 3:04 PM, Arnaud Héritier wrote: >> >>> For the eclipse plugin, I think that just moving it to retired isn't a >>> good think because even if we are agree that this one is now really >>> difficult to maintain, this is always the preferred integration way with >>> eclipse in many corporate environments. >> >> I think once it's retired anyone has the option to pick it up and maintain >> it. I think all we're saying putting it in the retired area is that we >> don't have the resources to support said plugin. Folks can do what they >> like after that. > > Why don't you move it then straight away over to mojo ? > > - Jörg > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare
Re: Culling Maven Verifier Plugin
Benjamin Bentmann wrote: > http://maven.apache.org/plugins/maven-verifier-plugin/ > > Is that plugin (not to be confused with the shared maven-verifier > component) actually used? Yes. It's handly for verifying templated run scripts or stuff like that. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Deprecate eclipse:eclipse plugin
Jason van Zyl wrote: > > On Nov 1, 2010, at 3:04 PM, Arnaud Héritier wrote: > >> For the eclipse plugin, I think that just moving it to retired isn't a >> good think because even if we are agree that this one is now really >> difficult to maintain, this is always the preferred integration way with >> eclipse in many corporate environments. > > I think once it's retired anyone has the option to pick it up and maintain > it. I think all we're saying putting it in the retired area is that we > don't have the resources to support said plugin. Folks can do what they > like after that. Why don't you move it then straight away over to mojo ? - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Culling maven-idea-plugin
+1 Sent from my iPhone On 01 Nov 2010, at 13:54, Kristian Rosenvold > wrote: The built-in support from jetbrains has been excellent since version 7, not much point in keeping this one around. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Deprecate eclipse:eclipse plugin
On Nov 1, 2010, at 3:04 PM, Arnaud Héritier wrote: > For the eclipse plugin, I think that just moving it to retired isn't a good > think because even if we are agree that this one is now really difficult to > maintain, this is always the preferred integration way with eclipse in many > corporate environments. I think once it's retired anyone has the option to pick it up and maintain it. I think all we're saying putting it in the retired area is that we don't have the resources to support said plugin. Folks can do what they like after that. > Thus we cannot just say to our community that we just stop to maintain it. > We have to propose something else. Go for it. > m2eclipse or Q4E are the best choices for now but they don't cover all what > eclipse:eclipse can do and they have always some performances/stabilities > issues with large projects. M2E specifically block project files created with mvn eclipse:eclipse. We're definitely not interested in maintaining it. > Everybody can fork eclipse:eclipse plugin (and many teams already did it) but > I think we should provide a solution for them to try to share their changes. > > How will we communicate around these changes ? > I think the easiest way for these people to work is to put the plugin in github and then they can more easily collaborate to fix it. I think we can announce these retirements on the user list and I can post a blog entry. > > On Nov 1, 2010, at 2:37 PM, Jason van Zyl wrote: > >> I started moving any of the ones discussed here: >> >> http://svn.apache.org/repos/asf/maven/retired/ >> >> If anyone disagrees we can move them back but I think the ones suggest so >> far are good candidates. >> >> On Nov 1, 2010, at 1:37 PM, Jason van Zyl wrote: >> >>> Following up from a discussion on the user list. I think it's time to be >>> realistic about providing a healthy level of support for plugins here. I >>> think it makes more sense to reduce the foot print of plugins we say we >>> support and do those well as opposed to housing many plugin that just don't >>> get much love. I would ask people to think about the plugins we're housing >>> that we shouldn't. Probably a thread per plugin would be fine for >>> discussion. >>> >>> To that end the plugins I'll send the first thread. >>> >>> Thanks, >>> >>> Jason >>> >>> -- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> - >>> >>> Our achievements speak for themselves. What we have to keep track >>> of are our failures, discouragements and doubts. We tend to forget >>> the past difficulties, the many false starts, and the painful >>> groping. We see our past achievements as the end result of a >>> clean forward thrust, and our present difficulties as >>> signs of decline and decay. >>> >>> -- Eric Hoffer, Reflections on the Human Condition >>> >>> >>> >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> In short, man creates for himself a new religion of a rational >> and technical order to justify his work and to be justified in it. >> >> -- Jacques Ellul, The Technological Society >> >> >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - We know what we are, but know not what we may be. -- Shakespeare
Re: Moving all reporting to a site project
+1 On Nov 1, 2010, at 1:41 PM, Jason van Zyl wrote: > In much the same way we have a little sub-project for releasing I think it's > time to have one for the site generation. Take the maven-site-plugin and any > related plugins and move them into their own tree. What I'm trying to do here > is cull the set of plugins we have is to keep the ones that are part of the > core lifecycles and super popular plugins that get maintained like the > dependency plugin and enforcer plugin. > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > You are never dedicated to something you have complete confidence in. > No one is fanatically shouting that the sun is going to rise tomorrow. > They know it is going to rise tomorrow. When people are fanatically > dedicated to political or religious faiths or any other kind of > dogmas or goals, it's always because these dogmas or > goals are in doubt. > > -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance > > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Deprecate eclipse:eclipse plugin
For the eclipse plugin, I think that just moving it to retired isn't a good think because even if we are agree that this one is now really difficult to maintain, this is always the preferred integration way with eclipse in many corporate environments. Thus we cannot just say to our community that we just stop to maintain it. We have to propose something else. m2eclipse or Q4E are the best choices for now but they don't cover all what eclipse:eclipse can do and they have always some performances/stabilities issues with large projects. Everybody can fork eclipse:eclipse plugin (and many teams already did it) but I think we should provide a solution for them to try to share their changes. How will we communicate around these changes ? On Nov 1, 2010, at 2:37 PM, Jason van Zyl wrote: > I started moving any of the ones discussed here: > > http://svn.apache.org/repos/asf/maven/retired/ > > If anyone disagrees we can move them back but I think the ones suggest so far > are good candidates. > > On Nov 1, 2010, at 1:37 PM, Jason van Zyl wrote: > >> Following up from a discussion on the user list. I think it's time to be >> realistic about providing a healthy level of support for plugins here. I >> think it makes more sense to reduce the foot print of plugins we say we >> support and do those well as opposed to housing many plugin that just don't >> get much love. I would ask people to think about the plugins we're housing >> that we shouldn't. Probably a thread per plugin would be fine for >> discussion. >> >> To that end the plugins I'll send the first thread. >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> Our achievements speak for themselves. What we have to keep track >> of are our failures, discouragements and doubts. We tend to forget >> the past difficulties, the many false starts, and the painful >> groping. We see our past achievements as the end result of a >> clean forward thrust, and our present difficulties as >> signs of decline and decay. >> >> -- Eric Hoffer, Reflections on the Human Condition >> >> >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > In short, man creates for himself a new religion of a rational > and technical order to justify his work and to be justified in it. > > -- Jacques Ellul, The Technological Society > > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Moving all reporting to a site project
Your call, you're doing the work. Not sure we have any precedent, but I imagine full support of the site plugin will require patches the 2.x version. On Nov 1, 2010, at 2:42 PM, Olivier Lamy wrote: > +1. > I can be a volunteer for site stuff.. > > Question : what do we do with site plugin 2.x and 3.x branch ? > > Personnally : I'd like to move only 3.x branch in this new project. > > > 2010/11/1 Jason van Zyl : >> In much the same way we have a little sub-project for releasing I think it's >> time to have one for the site generation. Take the maven-site-plugin and any >> related plugins and move them into their own tree. What I'm trying to do >> here is cull the set of plugins we have is to keep the ones that are part of >> the core lifecycles and super popular plugins that get maintained like the >> dependency plugin and enforcer plugin. >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> You are never dedicated to something you have complete confidence in. >> No one is fanatically shouting that the sun is going to rise tomorrow. >> They know it is going to rise tomorrow. When people are fanatically >> dedicated to political or religious faiths or any other kind of >> dogmas or goals, it's always because these dogmas or >> goals are in doubt. >> >> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance >> >> >> >> > > > > -- > Olivier Lamy > http://twitter.com/olamy > http://www.linkedin.com/in/olamy > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
Culling Maven Verifier Plugin
http://maven.apache.org/plugins/maven-verifier-plugin/ Is that plugin (not to be confused with the shared maven-verifier component) actually used? Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Moving all reporting to a site project
+1. I can be a volunteer for site stuff.. Question : what do we do with site plugin 2.x and 3.x branch ? Personnally : I'd like to move only 3.x branch in this new project. 2010/11/1 Jason van Zyl : > In much the same way we have a little sub-project for releasing I think it's > time to have one for the site generation. Take the maven-site-plugin and any > related plugins and move them into their own tree. What I'm trying to do here > is cull the set of plugins we have is to keep the ones that are part of the > core lifecycles and super popular plugins that get maintained like the > dependency plugin and enforcer plugin. > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > You are never dedicated to something you have complete confidence in. > No one is fanatically shouting that the sun is going to rise tomorrow. > They know it is going to rise tomorrow. When people are fanatically > dedicated to political or religious faiths or any other kind of > dogmas or goals, it's always because these dogmas or > goals are in doubt. > > -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance > > > > -- Olivier Lamy http://twitter.com/olamy http://www.linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Culling dead/inactive plugins
I started moving any of the ones discussed here: http://svn.apache.org/repos/asf/maven/retired/ If anyone disagrees we can move them back but I think the ones suggest so far are good candidates. On Nov 1, 2010, at 1:37 PM, Jason van Zyl wrote: > Following up from a discussion on the user list. I think it's time to be > realistic about providing a healthy level of support for plugins here. I > think it makes more sense to reduce the foot print of plugins we say we > support and do those well as opposed to housing many plugin that just don't > get much love. I would ask people to think about the plugins we're housing > that we shouldn't. Probably a thread per plugin would be fine for discussion. > > To that end the plugins I'll send the first thread. > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > Our achievements speak for themselves. What we have to keep track > of are our failures, discouragements and doubts. We tend to forget > the past difficulties, the many false starts, and the painful > groping. We see our past achievements as the end result of a > clean forward thrust, and our present difficulties as > signs of decline and decay. > > -- Eric Hoffer, Reflections on the Human Condition > > > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society
Re: Culling the maven-stage-plugin
+1 --mobile On Nov 1, 2010, at 8:40 AM, Jason van Zyl wrote: > This was a hack, and has now been replaced with Nexus staging here at Apache > (and most other forges). I believe this plugin can be archived now. > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > You are never dedicated to something you have complete confidence in. > No one is fanatically shouting that the sun is going to rise tomorrow. > They know it is going to rise tomorrow. When people are fanatically > dedicated to political or religious faiths or any other kind of > dogmas or goals, it's always because these dogmas or > goals are in doubt. > > -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance > > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Culling Maven One Plugin
http://maven.apache.org/plugins/maven-one-plugin/ I think we're past its usefullness. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Culling maven-idea-plugin
We can use http://svn.apache.org/repos/asf/maven/retired/ to start moving plugins. On Nov 1, 2010, at 1:54 PM, Kristian Rosenvold wrote: > The built-in support from jetbrains has been excellent since version 7, > not much point in keeping this one around. > > Kristian > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare
Re: Culling maven-idea-plugin
+1000 On 1 Nov 2010 12:54, "Kristian Rosenvold" wrote: The built-in support from jetbrains has been excellent since version 7, not much point in keeping this one around. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Culling maven-idea-plugin
On Nov 1, 2010, at 1:54 PM, Kristian Rosenvold wrote: > The built-in support from jetbrains has been excellent since version 7, > not much point in keeping this one around. > +1 > Kristian > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
Re: Culling dead/inactive plugins
On Nov 1, 2010, at 1:41 PM, Arnaud Héritier wrote: > I agree. > Perhaps for some of them we could discuss to move them to mojo.codehaus.org > to let the community take the lead on them if we find some volunteers (I'm > thinking about the eclipse plugin for example). > +1 to moving out the maven-eclipse-plugin This is what sparked the discussion. Then folks like Martin can work on the plugin more easily. > Arnaud > > On Nov 1, 2010, at 1:37 PM, Jason van Zyl wrote: > >> Following up from a discussion on the user list. I think it's time to be >> realistic about providing a healthy level of support for plugins here. I >> think it makes more sense to reduce the foot print of plugins we say we >> support and do those well as opposed to housing many plugin that just don't >> get much love. I would ask people to think about the plugins we're housing >> that we shouldn't. Probably a thread per plugin would be fine for >> discussion. >> >> To that end the plugins I'll send the first thread. >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> Our achievements speak for themselves. What we have to keep track >> of are our failures, discouragements and doubts. We tend to forget >> the past difficulties, the many false starts, and the painful >> groping. We see our past achievements as the end result of a >> clean forward thrust, and our present difficulties as >> signs of decline and decay. >> >> -- Eric Hoffer, Reflections on the Human Condition >> >> >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa
Culling maven-idea-plugin
The built-in support from jetbrains has been excellent since version 7, not much point in keeping this one around. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Culling dead/inactive plugins
I agree. Perhaps for some of them we could discuss to move them to mojo.codehaus.org to let the community take the lead on them if we find some volunteers (I'm thinking about the eclipse plugin for example). Arnaud On Nov 1, 2010, at 1:37 PM, Jason van Zyl wrote: > Following up from a discussion on the user list. I think it's time to be > realistic about providing a healthy level of support for plugins here. I > think it makes more sense to reduce the foot print of plugins we say we > support and do those well as opposed to housing many plugin that just don't > get much love. I would ask people to think about the plugins we're housing > that we shouldn't. Probably a thread per plugin would be fine for discussion. > > To that end the plugins I'll send the first thread. > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > Our achievements speak for themselves. What we have to keep track > of are our failures, discouragements and doubts. We tend to forget > the past difficulties, the many false starts, and the painful > groping. We see our past achievements as the end result of a > clean forward thrust, and our present difficulties as > signs of decline and decay. > > -- Eric Hoffer, Reflections on the Human Condition > > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Moving all reporting to a site project
In much the same way we have a little sub-project for releasing I think it's time to have one for the site generation. Take the maven-site-plugin and any related plugins and move them into their own tree. What I'm trying to do here is cull the set of plugins we have is to keep the ones that are part of the core lifecycles and super popular plugins that get maintained like the dependency plugin and enforcer plugin. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
Culling the maven-stage-plugin
This was a hack, and has now been replaced with Nexus staging here at Apache (and most other forges). I believe this plugin can be archived now. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
