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
