> [ ] (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 unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
