2011/11/16 Jukka Zitting <[email protected]>:
> 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.
Hmm, first time users have to read the docs anyway - so they need to
know whether and how they have to configure it in the configuration of
the plugin. The same goes for the external file - so there is no
difference.
>
> 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?
The answer is easy: these things don't work and are by intention this
way. The number one rule is: no surprises and therefore you have to
configure the full dependency list including versions. We explicitly
came up with the partial bundle list. If you want to assemble an
application you really want to specify what you want to have in there,
so transitive deps etc. should not be used at all here.
>
> 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.
We're using Maven api to get this done, so I expect that other tools
leveraging maven work as well. If not, well....
And just by having dependencies inside the plugin configuration. this
doesn't work either. Try specifying a dependency inside the dependency
plugin without in addition mentioning it in the dependencies section
of your pom! And I don't want to declare deps twice.
>
>> 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.
Ah, ok, we asked the maven gurus last week and they told us the
opposite. I haven't validated it yet. If that's the case then I'm fine
if we use the exact same format as we use for the external file inside
the plugin configuration.
I really like the external XML file - it's imho the best way to
specify an application assembly. The average developer rarely touches
these things and if, it's a well documented place with an easily
understandable format (well maybe we're missing docs atm, but we'll
fix that anyway).
Carsten
>
> 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
>
--
Carsten Ziegeler
[email protected]
