Again, I totally agree for *normal* dependencies and again, I'm not talking about those. I'm talking about the annotations only - which are separate artifacts anyway.
Carsten Oliver Lietz wrote > 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 <[email protected]> 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 > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
