True, that's why we intentionally keep the list short. Things like the servlet api or the logging api or JCR rarely need a change at all.
For the OSGi dependencies we have this with every major release, so every 2 to 3 years, not a big deal either. Similar is true for Java version the project is using. We have the default in the parent pom. I guess we can continue to argue in one way or the other for some time. But I think there are no big wins with going one way or the other. Every approach has advantages and consequences. So let's stick with what we have now and only adjust if there is a real problem. My problem of updating to parent 33 is at least fixed now, after manually adding the missing dependencies to 10 projects. Thanks Carsten Konrad Windszus wrote > 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 <cziege...@apache.org> 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 >> cziege...@apache.org > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
