Hi,
On Wed, Nov 16, 2011 at 9:28 AM, Carsten Ziegeler <[email protected]> wrote:
> I really think we should just provide one way for defining a bundle
> list - as the current way with the xml file has no downsides anymore,
>From my perspective as a user of the plugin there are still big
problems with the separate XML file:
1) You have to learn a new dependency and configuration mechanism.
I've witnessed a handful people interact with the partial bundle list
mechanism for the first time, and they all come out confused trying to
figure out where they should put a new dependency.
2) You lose a lot of built-in Maven mechanisms. It's only recently
when support for basic stuff like ${properties} was added, and I have
no idea if or how things like transitive dependencies, inheritance,
dependencyManagement, profiles, etc. work with the bundle list
mechanism. They even might, but where do I find the documentation of
how that stuff is supposed to work with the bundle list?
3) Having a custom dependency mechanism confuses tools like Jenkins
that could otherwise automatically trigger CI builds based on changes
in upstream dependencies. Or Eclipse that when opening a project gives
the option for automatically opening also all upstream dependencies.
> There has always been the argument that having the configuration
> inside the plugin configuration in the pom allows to use tools like
> m2e etc. but that's only true to some degree. If we want support for
> our plugin, we need to write a m2e plugin (if that's the right term).
A plugin is not needed since m2e automatically introspects Maven
plugins to find which configuration options are available. My Eclipse
instance happily provides inline validation, code completion and
context-sensitive help for all Maven plugins, including the launchpad
one.
Of course we'd get similar level of IDE support also for the bundle
list XML file by adding an explicit XML schema or DTD reference, but
the effort spent implementing something like that is just reinventing
stuff that we'd already get for free by following standard Maven
conventions.
BR,
Jukka Zitting
