Re: [poll] Need for plugin packs / mixins for plugins
I'd basically like to use snippets, or whatever you call them. However, if you restrict them to a plugin pack, then I'd consider them as half baken. There are lots of other places where one could use them. For example, a user on [EMAIL PROTECTED] has recently proposed to use snippets within configuration. My recommendation would be use an XML preprocessor. Like this: plugins include ... attributes to configure the include here ... /plugins The XML preprocessor would replace the include element with an XML snippet. Advantages: - Easy to implement: It is sufficient to modify the code that reads pom.xml, settings.xml, and/or profile.xml. (At least I would hope, that there is the code for each of these ... :-) - Powerful: Could be enhanced to do filtering or stuff like that. -- View this message in context: http://www.nabble.com/-poll--Need-for-plugin-packs---mixins-for-plugins-tf4366509s177.html#a12594066 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
Jochen Wiedmann pisze: I'd basically like to use snippets, or whatever you call them. However, if you restrict them to a plugin pack, then I'd consider them as half baken. There are lots of other places where one could use them. For example, a user on [EMAIL PROTECTED] has recently proposed to use snippets within configuration. My recommendation would be use an XML preprocessor. Like this: plugins include ... attributes to configure the include here ... /plugins The XML preprocessor would replace the include element with an XML snippet. Advantages: - Easy to implement: It is sufficient to modify the code that reads pom.xml, settings.xml, and/or profile.xml. (At least I would hope, that there is the code for each of these ... :-) - Powerful: Could be enhanced to do filtering or stuff like that. Why not use existing solutions, then? I mean, XInclude standard that is supported by XML parsers and would not clutter Maven's code. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
On 9/10/07, Grzegorz Kossakowski [EMAIL PROTECTED] wrote: Why not use existing solutions, then? I mean, XInclude standard that is supported by XML parsers and would not clutter Maven's code. Because of this: - Powerful: Could be enhanced to do filtering or stuff like that. -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
Jochen Wiedmann pisze: Because of this: - Powerful: Could be enhanced to do filtering or stuff like that. Your requirement is rather vague for me. Do you mean filtering of included XML? If so, XInclude already supports it in very powerful way - by using XPointer for this. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
On 9/10/07, Grzegorz Kossakowski [EMAIL PROTECTED] wrote: Your requirement is rather vague for me. Let's start with the most simple Filter: Extrapolation. And let's not forget, that Filtering is very underdeveloped, compared to Ants Filtering. -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
Jochen Wiedmann pisze: On 9/10/07, Grzegorz Kossakowski [EMAIL PROTECTED] wrote: Your requirement is rather vague for me. Let's start with the most simple Filter: Extrapolation. And let's not forget, that Filtering is very underdeveloped, compared to Ants Filtering. I'm not sure if we are talking about the same thing. I have in mind selecting some portion of included XML snippet by applying XPointer/XPath query on it. What do you mean by filtering here? -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
On 10 Sep 07, at 8:51 AM 10 Sep 07, Grzegorz Kossakowski wrote: Jochen Wiedmann pisze: On 9/10/07, Grzegorz Kossakowski [EMAIL PROTECTED] wrote: Your requirement is rather vague for me. Let's start with the most simple Filter: Extrapolation. And let's not forget, that Filtering is very underdeveloped, compared to Ants Filtering. I'm not sure if we are talking about the same thing. I have in mind selecting some portion of included XML snippet by applying XPointer/XPath query on it. What do you mean by filtering here? We definitely want to control how snippets are pulled in and used. I wouldn't turn on general XML includes as we'll end up with the mess we had in Maven 1.x. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
On 9/10/07, Grzegorz Kossakowski [EMAIL PROTECTED] wrote: I'm not sure if we are talking about the same thing. I have in mind selecting some portion of included XML snippet by applying XPointer/XPath query on it. What do you mean by filtering here? That we would want to change the included XML, depending on the POM which includes it. -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
Jason van Zyl pisze: On 10 Sep 07, at 8:51 AM 10 Sep 07, Grzegorz Kossakowski wrote: Jochen Wiedmann pisze: On 9/10/07, Grzegorz Kossakowski [EMAIL PROTECTED] wrote: Your requirement is rather vague for me. Let's start with the most simple Filter: Extrapolation. And let's not forget, that Filtering is very underdeveloped, compared to Ants Filtering. I'm not sure if we are talking about the same thing. I have in mind selecting some portion of included XML snippet by applying XPointer/XPath query on it. What do you mean by filtering here? We definitely want to control how snippets are pulled in and used. I wouldn't turn on general XML includes as we'll end up with the mess we had in Maven 1.x. Ok, if you have special requirements that XML includes do not satisfy it makes sense to invent something new. I only hope it's not going to be our own way of doing everything that Maven users will be forced to grasp. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
On 9/10/07, Jason van Zyl [EMAIL PROTECTED] wrote: We definitely want to control how snippets are pulled in and used. I wouldn't turn on general XML includes as we'll end up with the mess we had in Maven 1.x. I must admit, that I can't follow you here. What to you mean by the mess we had in Maven 1.x? Note, that the situation is quite different here, because the inclusions result would still produce a POM with exactly the same structure than we have now. Do you believe, that implementing a different inclusion mechanism (for example plugin pack) for every suitable situation, including more complex semantics, is better? Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
On 10 Sep 07, at 9:11 AM 10 Sep 07, Jochen Wiedmann wrote: On 9/10/07, Jason van Zyl [EMAIL PROTECTED] wrote: We definitely want to control how snippets are pulled in and used. I wouldn't turn on general XML includes as we'll end up with the mess we had in Maven 1.x. I must admit, that I can't follow you here. What to you mean by the mess we had in Maven 1.x? Note, that the situation is quite different here, because the inclusions result would still produce a POM with exactly the same structure than we have now. Do you believe, that implementing a different inclusion mechanism (for example plugin pack) for every suitable situation, I don't believe a plugin pack is useful at all, I'm all for using standard POM elements and a simple import , but we might want to limit where imports can be used for example. including more complex semantics, is better? I didn't say, or imply that at all. Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [poll] Need for plugin packs / mixins for plugins
Wendy Smoak wrote on Monday, September 03, 2007 7:41 PM: On 9/1/07, Brett Porter [EMAIL PROTECTED] wrote: Like the other poll, I'd like to hear from as many people as possible their opinion this topic (even if you just want to say '0' so we know where you stand). [ ] (A) Having a way to include a set of plugins in one small POM fragment would be a useful feature to have (if you have a use case other than the already stated standard plugins, please specify) [ ] (B) Pasting a snippet in from the web site is sufficient [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) B -- we're maintaining pluginManagement in a corporate parent pom and it's not that difficult. +1 I'd like to have more rules or help instead, like - enforce that no plugin is used, that is not declared in a pluginManagement section before - list all known plugins and their current versions - list all avalibale versions of a plugin - ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
Andrew Williams pisze: E) Specifying a a list of plugin versions in a pom snippet (better than plugin packs) is (as I see it) adding maintenance overhead that could become intrusive in some organisations. Why can we not just have a plugin (that maven suggests running if it seems missing version numbers) that updates your pom to specify the latest version of any plugins that are not currently stipulated. Running this on a parent pom in any organisation should eliminate the need for mixins or packs. +1 -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
On Sep 1, 2007, at 10:53 PM, Brett Porter wrote: [ X] (A) Having a way to include a set of plugins in one small POM fragment would be a useful feature to have (if you have a use case other than the already stated standard plugins, please specify) [ ] (B) Pasting a snippet in from the web site is sufficient [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) It seems to me that standardizing and releasing these snippets will be absolutely required in the very largest of environments, where development is highly distributed geographically, etc. etc. Also, in cases where it doesn't quite work to have only one plugin version specified one time in a single org pom for all projects everywhere for all time. IMO, we should pursue standardization of any boilerplate code, including standard additions to the POM...it doesn't preclude using snippets, for one thing. Also, it provides a lot more flexibility to do things like publish your own standardized (and maintained) suite of plugins as yet another open source offering for others to use. This will only serve to further stabilize Maven users' lives. -john --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john
Re: [poll] Need for plugin packs / mixins for plugins
Don't forget that successive versions of some plugins may break backward compatibility and other such bad practices. Locking everyone in a large organization down to one version of such a plugin could be very limiting, since these things have to be phased in. Also, I don't think we can pretend that we have all of the requirements or use cases. I've heard some pretty convoluted approaches to managing this sort of data, and I don't have the understanding of the environment to make a judgement about whether they are doing things in an unnecessarily complex way, or even whether their approach can be changed (political environment can have a big impact here). I do think that mixins like this would be beneficial, and I'm really not at all convinced that it's a good idea to expand the scope of such mixins outside of the build element...so, basically plugin packs. To me, the term 'plugin pack' still needs some definition, so I'm willing to say that it's a good idea to provide this type of flexibility, and then help shape the concrete details a little bit to get at something reasonable. As far as many of the complexities involved in your questions at the beginning of your reply, we can use tooling to help with that sort of visibility too. Also, supporting plugin packs for the wider world doesn't preclude having internal policies against their use in organizations...maybe we'd do better to help people set rules about how Maven is allowed to be used? -john On Sep 2, 2007, at 11:30 AM, Jason van Zyl wrote: What are the real requirements? They are: 1) An easy way to get a set of stable plugins that work together 2) To easily see what versions are contained in this set 3) To easily change or augment what is in this set The current mechanism + toolings works. I know what's going to happen with plugin packs. Someone is going to want to change a version of a plugin they are using and How do I find out what versions of plugins am I using, How do I override what version of a plugin I'm using if it's specified in a plugin pack?, Does plugin management win if it's in a plugin pack?. I found a bug in the way plugin packs are processed and I can't get a plugin version I need, is there a work around?. How do I configure plugins that have been defined in the plugin pack. So people are going to have to end up redeclaring bits to get configuration and execution information locked down and then you end up with a terrible configuration management problem. A fully, and clear, literal way to define this is what is most practical. The questions below are also framed to bias the answers. For A, plugin packs are not the only solution. In very practical terms the total number of plugins is not that high. What people want to know is the stable set. The core processing required for the notion of a plugin pack will not be straight forward and it's not necessary and adds almost no value and I'm certain it will lead to greater complexity. Users want 1), 2), and 3). The current mechanism plus minimal tooling, or no tooling if people cut and paste (big deal) covers those requirements. Plugin packs cover 1) and then it becomes another nightmare to maintain. I am not in favor of plugin packs. On 1 Sep 07, at 7:53 PM 1 Sep 07, Brett Porter wrote: Like the other poll, I'd like to hear from as many people as possible their opinion this topic (even if you just want to say '0' so we know where you stand). [ ] (A) Having a way to include a set of plugins in one small POM fragment would be a useful feature to have (if you have a use case other than the already stated standard plugins, please specify) [ ] (B) Pasting a snippet in from the web site is sufficient [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) Thanks, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john
Re: [poll] Need for plugin packs / mixins for plugins
E) Specifying a a list of plugin versions in a pom snippet (better than plugin packs) is (as I see it) adding maintenance overhead that could become intrusive in some organisations. Why can we not just have a plugin (that maven suggests running if it seems missing version numbers) that updates your pom to specify the latest version of any plugins that are not currently stipulated. Running this on a parent pom in any organisation should eliminate the need for mixins or packs. On 2 Sep 2007, at 03:53, Brett Porter wrote: Like the other poll, I'd like to hear from as many people as possible their opinion this topic (even if you just want to say '0' so we know where you stand). [ ] (A) Having a way to include a set of plugins in one small POM fragment would be a useful feature to have (if you have a use case other than the already stated standard plugins, please specify) [ ] (B) Pasting a snippet in from the web site is sufficient [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) Thanks, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
On Sep 2, 2007, at 8:30 AM, Jason van Zyl wrote: What are the real requirements? They are: 1) An easy way to get a set of stable plugins that work together 2) To easily see what versions are contained in this set 3) To easily change or augment what is in this set The current mechanism + toolings works. I know what's going to happen with plugin packs. Someone is going to want to change a version of a plugin they are using and How do I find out what versions of plugins am I using, How do I override what version of a plugin I'm using if it's specified in a plugin pack?, Does plugin management win if it's in a plugin pack?. I found a bug in the way plugin packs are processed and I can't get a plugin version I need, is there a work around?. How do I configure plugins that have been defined in the plugin pack. So people are going to have to end up redeclaring bits to get configuration and execution information locked down and then you end up with a terrible configuration management problem. Hehe... I think no matter what is implemented you are gonna find that users are going to ask all of these questions and more I'm sure. ;-) But of course, with a well defined contract and documentation its easy enough to give 'em a URL and tell 'em to RTFM :-P IMO, the goal of grouping stable plugins that work together into a reusable chunk of pom.xml can be achieved by a generic pom import/ merge facility. With a few different rules on how to merge, documented of course, then it should be possible to setup a plugin- pack pom or a common-profile pom. From what I gather the only tricky part is how the merge actually happens, what takes precedence and so on... though I think that can be simplified into a few modes of merging quite easily. LIke for example, one mode could always prefer the local configuration over anything in the included pom. Another could warn (or error) if local pom and parent pom contain conflicting configuration. Maybe there are some uber-wrinkles that I'm missing, but this seems rather simple... and can probably be easily inserted into (or close to) the place where the parent pom is resolved and merged. * * * Anyways, I'd *REALY* like to see this feature added, and then some general use-case/best-practices implemented and documented around the feature to show uses how to create a plugin-pack or common-profile. --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
2007/9/2, Brett Porter [EMAIL PROTECTED]: Like the other poll, I'd like to hear from as many people as possible their opinion this topic (even if you just want to say '0' so we know where you stand). [ ] (A) Having a way to include a set of plugins in one small POM fragment would be a useful feature to have (if you have a use case other than the already stated standard plugins, please specify) [ ] (B) Pasting a snippet in from the web site is sufficient [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) Thanks, Brett As a manager of multiple large teams with diverse multiple projects, I agree 100% with all of Jason's comments on this topic. -- Aaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
On 9/1/07, Brett Porter [EMAIL PROTECTED] wrote: Like the other poll, I'd like to hear from as many people as possible their opinion this topic (even if you just want to say '0' so we know where you stand). [ ] (A) Having a way to include a set of plugins in one small POM fragment would be a useful feature to have (if you have a use case other than the already stated standard plugins, please specify) [ ] (B) Pasting a snippet in from the web site is sufficient [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) B -- we're maintaining pluginManagement in a corporate parent pom and it's not that difficult. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
A - rnaud On 03/09/07, Hervé BOUTEMY [EMAIL PROTECTED] wrote: B need to be able to override version of a plugin that is in a plugin pack, then solve conflicts between different plugin packs I think that what seems to be really cool in the first place will be more difficult to maintain that it seems Hervé Le dimanche 2 septembre 2007, Brett Porter a écrit : Like the other poll, I'd like to hear from as many people as possible their opinion this topic (even if you just want to say '0' so we know where you stand). [ ] (A) Having a way to include a set of plugins in one small POM fragment would be a useful feature to have (if you have a use case other than the already stated standard plugins, please specify) [ ] (B) Pasting a snippet in from the web site is sufficient [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) Thanks, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
(C) -Lukas Brett Porter wrote: Like the other poll, I'd like to hear from as many people as possible their opinion this topic (even if you just want to say '0' so we know where you stand). [ ] (A) Having a way to include a set of plugins in one small POM fragment would be a useful feature to have (if you have a use case other than the already stated standard plugins, please specify) [ ] (B) Pasting a snippet in from the web site is sufficient [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) Thanks, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [poll] Need for plugin packs / mixins for plugins
A -- Olivier -Message d'origine- De : Brett Porter [mailto:[EMAIL PROTECTED] Envoyé : dimanche 2 septembre 2007 04:54 À : Maven Developers List Objet : [poll] Need for plugin packs / mixins for plugins Like the other poll, I'd like to hear from as many people as possible their opinion this topic (even if you just want to say '0' so we know where you stand). [ ] (A) Having a way to include a set of plugins in one small POM fragment would be a useful feature to have (if you have a use case other than the already stated standard plugins, please specify) [ ] (B) Pasting a snippet in from the web site is sufficient [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) Thanks, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, any attachments and the information contained therein (this message) are confidential and intended solely for the use of the addressee(s). If you have received this message in error please send it back to the sender and delete it. Unauthorized publication, use, dissemination or disclosure of this message, either in whole or in part is strictly prohibited. ** Ce message électronique et tous les fichiers joints ainsi que les informations contenues dans ce message ( ci après le message ), sont confidentiels et destinés exclusivement à l'usage de la personne à laquelle ils sont adressés. Si vous avez reçu ce message par erreur, merci de le renvoyer à son émetteur et de le détruire. Toutes diffusion, publication, totale ou partielle ou divulgation sous quelque forme que se soit non expressément autorisées de ce message, sont interdites. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
On 04/09/2007, at 1:30 AM, Aaron Metzger wrote: 2007/9/2, Brett Porter [EMAIL PROTECTED]: Like the other poll, I'd like to hear from as many people as possible their opinion this topic (even if you just want to say '0' so we know where you stand). [ ] (A) Having a way to include a set of plugins in one small POM fragment would be a useful feature to have (if you have a use case other than the already stated standard plugins, please specify) [ ] (B) Pasting a snippet in from the web site is sufficient [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) Thanks, Brett As a manager of multiple large teams with diverse multiple projects, I agree 100% with all of Jason's comments on this topic. Ummm... which option is that? :) There are two Jason's, and they are at other ends of the discussion :) - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
A Brett Porter wrote: Like the other poll, I'd like to hear from as many people as possible their opinion this topic (even if you just want to say '0' so we know where you stand). [ ] (A) Having a way to include a set of plugins in one small POM fragment would be a useful feature to have (if you have a use case other than the already stated standard plugins, please specify) [ ] (B) Pasting a snippet in from the web site is sufficient [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) Thanks, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
A Raphaël 2007/9/2, Brett Porter [EMAIL PROTECTED]: Like the other poll, I'd like to hear from as many people as possible their opinion this topic (even if you just want to say '0' so we know where you stand). [ ] (A) Having a way to include a set of plugins in one small POM fragment would be a useful feature to have (if you have a use case other than the already stated standard plugins, please specify) [ ] (B) Pasting a snippet in from the web site is sufficient [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) Thanks, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
What are the real requirements? They are: 1) An easy way to get a set of stable plugins that work together 2) To easily see what versions are contained in this set 3) To easily change or augment what is in this set The current mechanism + toolings works. I know what's going to happen with plugin packs. Someone is going to want to change a version of a plugin they are using and How do I find out what versions of plugins am I using, How do I override what version of a plugin I'm using if it's specified in a plugin pack?, Does plugin management win if it's in a plugin pack?. I found a bug in the way plugin packs are processed and I can't get a plugin version I need, is there a work around?. How do I configure plugins that have been defined in the plugin pack. So people are going to have to end up redeclaring bits to get configuration and execution information locked down and then you end up with a terrible configuration management problem. A fully, and clear, literal way to define this is what is most practical. The questions below are also framed to bias the answers. For A, plugin packs are not the only solution. In very practical terms the total number of plugins is not that high. What people want to know is the stable set. The core processing required for the notion of a plugin pack will not be straight forward and it's not necessary and adds almost no value and I'm certain it will lead to greater complexity. Users want 1), 2), and 3). The current mechanism plus minimal tooling, or no tooling if people cut and paste (big deal) covers those requirements. Plugin packs cover 1) and then it becomes another nightmare to maintain. I am not in favor of plugin packs. On 1 Sep 07, at 7:53 PM 1 Sep 07, Brett Porter wrote: Like the other poll, I'd like to hear from as many people as possible their opinion this topic (even if you just want to say '0' so we know where you stand). [ ] (A) Having a way to include a set of plugins in one small POM fragment would be a useful feature to have (if you have a use case other than the already stated standard plugins, please specify) [ ] (B) Pasting a snippet in from the web site is sufficient [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) Thanks, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
[ ] (A) Having a way to include a set of plugins in one small POM [ ] (B) Pasting a snippet in from the web site is sufficient [X] (D) Undecided I personally don't mind pasting a snippet and I think this is a good idea no matter what happens -- perhaps it could be included in the release notes for each version. I can also see the use of mixins. Especially if the Maven team is the one providing the mixin, and each mixin is linked to a specific Maven release version as a set of working, integration-tested plugin versions for this release which a lot of people expect from the tool. I am concerned though that providing mixins will send us further down the path of moving more and more pieces out of the pom which is not the right move IMO. If we add plugin+version in mixin v1, then people will want plugin+version+configuration in mixin v2, and in a short period of time we'll have re-invented parent and pluginManagement in non-pom files which really makes no sense at all. Instead of all this mixin stuff (and perhaps this isn't really related), I think we need to fix the way we develop and release plugins, and perhaps this means changing the way versions are resolved etc (which we've discussed before -- should [1.1, ) include alphas and betas etc -- I say no). I don't think we should have *any* plugin at an alpha phase for more than 30 days. Same goes for beta. Instead we should create pools of unit and integration tests, verify that things aren't broken when we add new functionality, and *release* new versions of plugins. I'd be super happy if a SINGLE rfe or bug fix in a plugin results in a new version (1.1.2 to 1.1.3). Instead we have months and even years in between plugin releases, and people are using alphas and betas and even adding snapshot repos to their poms etc, resulting in less stable builds than we can and should be delivering. Stability != no new releases. Wayne On 9/2/07, Jason van Zyl [EMAIL PROTECTED] wrote: What are the real requirements? They are: 1) An easy way to get a set of stable plugins that work together 2) To easily see what versions are contained in this set 3) To easily change or augment what is in this set The current mechanism + toolings works. I know what's going to happen with plugin packs. Someone is going to want to change a version of a plugin they are using and How do I find out what versions of plugins am I using, How do I override what version of a plugin I'm using if it's specified in a plugin pack?, Does plugin management win if it's in a plugin pack?. I found a bug in the way plugin packs are processed and I can't get a plugin version I need, is there a work around?. How do I configure plugins that have been defined in the plugin pack. So people are going to have to end up redeclaring bits to get configuration and execution information locked down and then you end up with a terrible configuration management problem. A fully, and clear, literal way to define this is what is most practical. The questions below are also framed to bias the answers. For A, plugin packs are not the only solution. In very practical terms the total number of plugins is not that high. What people want to know is the stable set. The core processing required for the notion of a plugin pack will not be straight forward and it's not necessary and adds almost no value and I'm certain it will lead to greater complexity. Users want 1), 2), and 3). The current mechanism plus minimal tooling, or no tooling if people cut and paste (big deal) covers those requirements. Plugin packs cover 1) and then it becomes another nightmare to maintain. I am not in favor of plugin packs. On 1 Sep 07, at 7:53 PM 1 Sep 07, Brett Porter wrote: Like the other poll, I'd like to hear from as many people as possible their opinion this topic (even if you just want to say '0' so we know where you stand). [ ] (A) Having a way to include a set of plugins in one small POM fragment would be a useful feature to have (if you have a use case other than the already stated standard plugins, please specify) [ ] (B) Pasting a snippet in from the web site is sufficient [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) Thanks, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To
