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]
