On Monday 26 February 2018 12:51:14 Konrad Windszus wrote: > @Carsten: > Which dependency exactly to you want to declare now? The aggregate one for > annotations or the individual ones per annotation definition? > > But I rather tend to agree with Oli here. We should really force every > project to declare all(!) its dependencies. Having a dirty classpath for > non-OSGi modules just because you derive from parent does not seem right to > me. This should be a one time effort (given that OSGi does not rename the > artifacts again in the future).
And here is the example for dirty classpath: https://github.com/apache/sling-org-apache-sling-jcr-contentloader/blob/master/pom.xml#L113 This is *NOT* a problem of Pax Exam. Regards, O. > Konrad > > > On 26. Feb 2018, at 12:44, Carsten Ziegeler <cziege...@apache.org> 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. > > > > Upgrading to the new parent pom is now really a pain. > > > > 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