Hi, I agree somehow and disagree at the same time :) So far, we have different options but none of them is optimal, this has a direct impact on the user. With the suggested workaround we have the optimal solution for the user and its our task to keep it running with newer maven versions - if this is ever going to change in maven. I'll contact the maven list once more to find out what they think about it.
Carsten 2011/11/6 Justin Edelson <[email protected]>: > Hi Carsten, > > On Sat, Nov 5, 2011 at 9:20 PM, Carsten Ziegeler <[email protected]> wrote: >> 2011/11/5 Jukka Zitting <[email protected]>: >>> Hi, >>> >>> On Sun, Nov 6, 2011 at 12:11 AM, Carsten Ziegeler <[email protected]> >>> 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 >> [email protected] >> > -- Carsten Ziegeler [email protected]
