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

Reply via email to