Hi Carsten, On Sat, Nov 5, 2011 at 9:20 PM, Carsten Ziegeler <cziege...@apache.org> wrote: > 2011/11/5 Jukka Zitting <jukka.zitt...@gmail.com>: >> Hi, >> >> On Sun, Nov 6, 2011 at 12:11 AM, Carsten Ziegeler <cziege...@apache.org> >> wrote: >>> Yes, but the tooling point only applies partially - there is no >>> tooling for the various plugin configurations including the new >>> configuration for this plugin. So there is no tooling support for that >>> regardless which way we go. >> >> At least Eclipse with m2e will automatically introspect plugins to >> find out what configuration options they support. With that >> information I have automatic validation, code completion and >> context-sensitive documentation for plugin configuration. That's >> obviously not a killer feature, but still nice to have. As a user of >> the plugin I'd rather live with a bit more verbose and less coherent >> POM file than lose this and other features like inheritance or >> profiles. > > Sure, so far I haven't seen a use case for inheritance and profiles > when it comes to bundle lists - which of course doesn't mean that they > don't exist. > > But what I've seen is typos and all kind of maintenance problems if > the information has to be maintained at more than one place. Before > the bundle list we used an internal way which is pretty similar to > this new one and all types of user errors occured. :)
While I appreciate your concern about this, I don't think it is actually true of the latest SLING-2194/SLING-2265 changes. If you use both mechanisms, then *all* of your dependencies are placed into the bundle list at some default level and you only need to call out the artifactIds for the cases where you want a non-default bundle level. This means less maintenance and errors along the way, at least I hope that's the case. I do agree with you that the ultimate solution is to have dependency-level metadata in the pom. But I'd rather see that problem solved in Maven itself (or see us move away from Maven) instead of having some potentially non-forward compatible solution. Justin > > Regards > Carsten > >> BR, >> >> Jukka Zitting >> > > > > -- > Carsten Ziegeler > cziege...@apache.org >
