This is true for every other managed dependency in parent as well. We do maintain a certain baseline with parent and I think this is good.
Projects deliberately supporting older versions of the baseline cannot upgrade to the most recent parent then! > On 26. Feb 2018, at 14:01, Carsten Ziegeler <[email protected]> wrote: > > Sure works, but I guess it's better (yes arguing against myself now...) > if each project references it's own version of those annotations :) > Using a new version of the annotations and rebuilding your project will > most likely bind your project to the latest DS version although you > might not be using any feature of it. bnd uses the annotations package > version to create the namespace for the XML (as far as I know). > > Updating a parent pom should not bring such surprises, so therefore not > having these things in the pom at all is probably the best option. > > Carsten > > > Oliver Lietz wrote >> On Monday 26 February 2018 13:28:27 Carsten Ziegeler wrote: >>> Yepp and following your argumentation then every project which starts to >>> use R7 annotations can do so in its own pom. >> >> I guess we release a new parent with new version for annotations and >> upgrading >> to that parent should be enough – or do you expect new Maven coordinates >> (again)? >> >> Regards, >> O. >> >>> Let's leave it the way it is. It would just have been nice to hear about >>> these breaking changes in some way. But I guess I could have seen this >>> coming by watching the commits. So all fine >>> >>> Carsten >>> >>> >>> Oliver Lietz wrote >>> >>>> On Monday 26 February 2018 13:05:46 Carsten Ziegeler wrote: >>>>> Well, it seems I'm the only one complaining anyway... >>>>> >>>>> TBH, I don't see a real advantage in having these things in the >>>>> dependency management at all then. But I guess, it will just be me >>>>> again... >>>> >>>> I expect to see an update at least for versioning annotations with R7, no? >>>> >>>> O. >>>> >>>>> Carsten >>>>> >>>>> >>>>> Oliver Lietz wrote >>>>> >>>>>> On Monday 26 February 2018 12:44:53 Carsten Ziegeler wrote: >>>>>>> Well, how many non OSGi modules do we have? I totally agree that it's >>>>>>> better to not declare dependencies in the parent pom. But every rule >>>>>>> has >>>>>>> an exception, and I think the annotations (not the api) are an >>>>>>> exception. >>>>>> >>>>>> The Maven and bnd plugins, Maven archetypes, the IDE modules and several >>>>>> testing modules are non-OSGi – but I don't have any numbers. >>>>>> >>>>>>> Upgrading to the new parent pom is now really a pain. >>>>>> >>>>>> I don't think adding one or two dependencies is a big deal (correctness >>>>>> vs >>>>>> convenience) and we have already updated several modules to Parent 33. >>>>>> If others disagree we can add back those annotations with Parent 34. >>>>>> >>>>>> Regards, >>>>>> O. >>>>>> >>>>>>> Regards >>>>>>> Carsten >>>>>>> >>>>>>> Oliver Lietz wrote >>>>>>> >>>>>>>> On Monday 26 February 2018 12:15:16 Carsten Ziegeler wrote: >>>>>>>>> Hi >>>>>>>> >>>>>>>> Hi Carsten, >>>>>>>> >>>>>>>>> it seems that updating to parent pom 33 is way harder than it should >>>>>>>>> be. >>>>>>>>> For an unknown reason the OSGi annotations are no longer declared as >>>>>>>>> dependencies, requiring now each and every project to define >>>>>>>>> them...which I think is really annoying. >>>>>>>>> >>>>>>>>> The change in question is referencing SLING-7384, but I can't find a >>>>>>>>> discussion nor reason in there. So why has this been done? >>>>>>>> >>>>>>>> in my opinion dependencies should only be managed in parent and not >>>>>>>> declared. We have several modules which are "not OSGi" and they >>>>>>>> inherit >>>>>>>> those dependencies although not used at all. >>>>>>>> >>>>>>>> Regards, >>>>>>>> O. >>>>>>>> >>>>>>>>> Regards >>>>>>>>> Carsten >> > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected]
