You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2018/02/26 11:15:16 UTC
[Maven] Updating to parent pom 33 breaks all projects
Hi
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?
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <cz...@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
>> cziegeler@apache.org
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Konrad Windszus <ko...@gmx.de>.
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 <cz...@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
> cziegeler@apache.org
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Oliver Lietz <ap...@oliverlietz.de>.
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
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Carsten Ziegeler <cz...@apache.org>.
Yepp and following your argumentation then every project which starts to
use R7 annotations can do so in its own pom.
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
cziegeler@apache.org
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Oliver Lietz <ap...@oliverlietz.de>.
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
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Carsten Ziegeler <cz...@apache.org>.
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...
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
cziegeler@apache.org
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Oliver Lietz <ap...@oliverlietz.de>.
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
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Monday 26 February 2018 13:52:56 Carsten Ziegeler wrote:
> 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.
I see your point.
O.
> 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/ma
> > ster/pom.xml#L113
> >
> > This is *NOT* a problem of Pax Exam.
> >
> > Regards,
> > O.
> >
> >> Konrad
> >>
> >>> On 26. Feb 2018, at 12:44, Carsten Ziegeler <cz...@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
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <cz...@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
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Oliver Lietz <ap...@oliverlietz.de>.
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 <cz...@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
RE: [Maven] Updating to parent pom 33 breaks all projects
Posted by Stefan Seifert <ss...@pro-vision.de>.
>Not even this is an option, see Konrad's response. So maybe we should
>consider multiple parent poms.
yes, i think multiple parents are the cleanest solution.
the only drawback i see is that a new release of the main parent also requires a new release of the osgi-parent - but this can be combined in one vote.
additional bonus of two parents: it would be possible to support different major versions or artifacts of osgi-parents, e.g. one for OSGi R6 and one for OSGi R7.
stefan
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Robert Munteanu <ro...@apache.org>.
On Tue, 2018-02-27 at 17:38 +0100, Oliver Lietz wrote:
> On Tuesday 27 February 2018 18:28:05 Robert Munteanu wrote:
> > On Tue, 2018-02-27 at 17:09 +0100, Oliver Lietz wrote:
> > > > Well, let's try and avoid that :-)
> > > >
> > > > Could we either:
> > > >
> > > > 1) Create a profile in the parent pom, activated for bundle
> > > > projects,
> > > > which adds the OSGi dependencies?
> > > >
> > > > 2) Create a 'non-OSGi' parent POM (A) and an 'OSGi' parent POM
> > > > (B),
> > > > where A is the parent of B. This way we could use the parent
> > > > POM in
> > > > different projects without getting any clashes.
> > >
> > > We could use the bundle profile but that "requires" switching to
> > > bnd
> > > Maven
> > > Plugin (or at least placing a file bnd.bnd in the module).
> >
> > Well, I assume that using the bnd.bnd file is another manual
> > transition
> > that we must do, right? If that is the case we should discuss it on
> > the
> > dev list before committing to another migration.
>
> Putting bnd instructions into a file is the preferred way (instead of
> POM, see
> discussion in SLING-7417). Once Maven JAR Plugin is fixed those
> profile from
> parent can be removed. You don't have to switch to bnd Maven Plugin,
> Maven
> Bundle Plugin is still supported.
Right, but AFAICT a marker file is the only way to detect a bundle, and
I'd like to not tie up the migration to the bnd-maven-plugin and the
migration to a newer parent pom.
>
> > Maybe we can have a compromise and require a property in the pom,
> > e.g.
> >
> > <properties>
> > <sling.bundle>true</sling.bundle>
> > </properties>
> >
> > That property will activate the OSGi-related profile from the
> > parent
> > pom.
> >
> > Not ideal but still better than copy/pasting considerably more
> > dependency versions.
>
> Ugly... no other way to activate profile?
Not even this is an option, see Konrad's response. So maybe we should
consider multiple parent poms.
Robert
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Tuesday 27 February 2018 18:28:05 Robert Munteanu wrote:
> On Tue, 2018-02-27 at 17:09 +0100, Oliver Lietz wrote:
> > > Well, let's try and avoid that :-)
> > >
> > > Could we either:
> > >
> > > 1) Create a profile in the parent pom, activated for bundle
> > > projects,
> > > which adds the OSGi dependencies?
> > >
> > > 2) Create a 'non-OSGi' parent POM (A) and an 'OSGi' parent POM (B),
> > > where A is the parent of B. This way we could use the parent POM in
> > > different projects without getting any clashes.
> >
> > We could use the bundle profile but that "requires" switching to bnd
> > Maven
> > Plugin (or at least placing a file bnd.bnd in the module).
>
> Well, I assume that using the bnd.bnd file is another manual transition
> that we must do, right? If that is the case we should discuss it on the
> dev list before committing to another migration.
Putting bnd instructions into a file is the preferred way (instead of POM, see
discussion in SLING-7417). Once Maven JAR Plugin is fixed those profile from
parent can be removed. You don't have to switch to bnd Maven Plugin, Maven
Bundle Plugin is still supported.
> Maybe we can have a compromise and require a property in the pom, e.g.
>
> <properties>
> <sling.bundle>true</sling.bundle>
> </properties>
>
> That property will activate the OSGi-related profile from the parent
> pom.
>
> Not ideal but still better than copy/pasting considerably more
> dependency versions.
Ugly... no other way to activate profile?
O.
> Robert
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Konrad Windszus <ko...@gmx.de>.
>
> Maybe we can have a compromise and require a property in the pom, e.g.
>
> <properties>
> <sling.bundle>true</sling.bundle>
> </properties>
>
> That property will activate the OSGi-related profile from the parent
> pom.
>
> Not ideal but still better than copy/pasting considerably more
> dependency versions.
>
This is not supported by Maven. Only properties given via command line can be used for profile activation (see https://issues.apache.org/jira/browse/MNG-5127 and a lot of related tickets). Therefore we would rather need to rely on existence of a dedicated marker file.
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Robert Munteanu <ro...@apache.org>.
On Tue, 2018-02-27 at 17:09 +0100, Oliver Lietz wrote:
> > Well, let's try and avoid that :-)
> >
> > Could we either:
> >
> > 1) Create a profile in the parent pom, activated for bundle
> > projects,
> > which adds the OSGi dependencies?
> >
> > 2) Create a 'non-OSGi' parent POM (A) and an 'OSGi' parent POM (B),
> > where A is the parent of B. This way we could use the parent POM in
> > different projects without getting any clashes.
>
> We could use the bundle profile but that "requires" switching to bnd
> Maven
> Plugin (or at least placing a file bnd.bnd in the module).
Well, I assume that using the bnd.bnd file is another manual transition
that we must do, right? If that is the case we should discuss it on the
dev list before committing to another migration.
Maybe we can have a compromise and require a property in the pom, e.g.
<properties>
<sling.bundle>true</sling.bundle>
</properties>
That property will activate the OSGi-related profile from the parent
pom.
Not ideal but still better than copy/pasting considerably more
dependency versions.
Robert
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Tuesday 27 February 2018 17:58:50 Robert Munteanu wrote:
> On Mon, 2018-02-26 at 12:54 +0100, Carsten Ziegeler wrote:
> > I'm talking about:
> > <!-- https://osgi.org/javadoc/r6/annotation/ -->
> > <dependency>
> >
> > <groupId>org.osgi</groupId>
> > <artifactId>org.osgi.annotation.versioning</artifactI
> >
> > d>
> >
> > <version>1.0.0</version>
> > <scope>provided</scope>
> >
> > </dependency>
> > <!--
> >
> > https://osgi.org/javadoc/r6/cmpn/org/osgi/service/component/annotatio
> > ns/package-summary.html
> > -->
> >
> > <dependency>
> >
> > <groupId>org.osgi</groupId>
> >
> > <artifactId>org.osgi.service.component.annotations</artifactId>
> >
> > <version>1.3.0</version>
> > <scope>provided</scope>
> >
> > </dependency>
> > <!--
> >
> > https://osgi.org/javadoc/r6/cmpn/org/osgi/service/metatype/annotation
> > s/package-summary.html
> > -->
> >
> > <dependency>
> >
> > <groupId>org.osgi</groupId>
> >
> > <artifactId>org.osgi.service.metatype.annotations</artifactId>
> >
> > <version>1.3.0</version>
> > <scope>provided</scope>
> >
> > </dependency>
> >
> > Sure, it's a one time effort, but for 100++ modules
>
> Well, let's try and avoid that :-)
>
> Could we either:
>
> 1) Create a profile in the parent pom, activated for bundle projects,
> which adds the OSGi dependencies?
>
> 2) Create a 'non-OSGi' parent POM (A) and an 'OSGi' parent POM (B),
> where A is the parent of B. This way we could use the parent POM in
> different projects without getting any clashes.
We could use the bundle profile but that "requires" switching to bnd Maven
Plugin (or at least placing a file bnd.bnd in the module).
Regards,
O.
> Robert
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Jason E Bailey <ja...@24601.org>.
+1 on this, my mental model of a parent POM is to handle the commonality, if there are a hundred projects that require the same settings in a POM that should be moved up to a parent, much like I would do if I were developing.
--
Jason
On Tue, Feb 27, 2018, at 10:58 AM, Robert Munteanu wrote:
>
> Well, let's try and avoid that :-)
>
> Could we either:
>
> 1) Create a profile in the parent pom, activated for bundle projects,
> which adds the OSGi dependencies?
>
> 2) Create a 'non-OSGi' parent POM (A) and an 'OSGi' parent POM (B),
> where A is the parent of B. This way we could use the parent POM in
> different projects without getting any clashes.
>
> Robert
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Robert Munteanu <ro...@apache.org>.
On Mon, 2018-02-26 at 12:54 +0100, Carsten Ziegeler wrote:
> I'm talking about:
>
> <!-- https://osgi.org/javadoc/r6/annotation/ -->
> <dependency>
> <groupId>org.osgi</groupId>
> <artifactId>org.osgi.annotation.versioning</artifactI
> d>
> <version>1.0.0</version>
> <scope>provided</scope>
> </dependency>
> <!--
> https://osgi.org/javadoc/r6/cmpn/org/osgi/service/component/annotatio
> ns/package-summary.html
> -->
> <dependency>
> <groupId>org.osgi</groupId>
>
> <artifactId>org.osgi.service.component.annotations</artifactId>
> <version>1.3.0</version>
> <scope>provided</scope>
> </dependency>
> <!--
> https://osgi.org/javadoc/r6/cmpn/org/osgi/service/metatype/annotation
> s/package-summary.html
> -->
> <dependency>
> <groupId>org.osgi</groupId>
>
> <artifactId>org.osgi.service.metatype.annotations</artifactId>
> <version>1.3.0</version>
> <scope>provided</scope>
> </dependency>
>
> Sure, it's a one time effort, but for 100++ modules
Well, let's try and avoid that :-)
Could we either:
1) Create a profile in the parent pom, activated for bundle projects,
which adds the OSGi dependencies?
2) Create a 'non-OSGi' parent POM (A) and an 'OSGi' parent POM (B),
where A is the parent of B. This way we could use the parent POM in
different projects without getting any clashes.
Robert
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Carsten Ziegeler <cz...@apache.org>.
I'm talking about:
<!-- https://osgi.org/javadoc/r6/annotation/ -->
<dependency>
<groupId>org.osgi</groupId>
<artifactId>org.osgi.annotation.versioning</artifactId>
<version>1.0.0</version>
<scope>provided</scope>
</dependency>
<!--
https://osgi.org/javadoc/r6/cmpn/org/osgi/service/component/annotations/package-summary.html
-->
<dependency>
<groupId>org.osgi</groupId>
<artifactId>org.osgi.service.component.annotations</artifactId>
<version>1.3.0</version>
<scope>provided</scope>
</dependency>
<!--
https://osgi.org/javadoc/r6/cmpn/org/osgi/service/metatype/annotations/package-summary.html
-->
<dependency>
<groupId>org.osgi</groupId>
<artifactId>org.osgi.service.metatype.annotations</artifactId>
<version>1.3.0</version>
<scope>provided</scope>
</dependency>
Sure, it's a one time effort, but for 100++ modules
Carsten
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).
>
> Konrad
>
>> On 26. Feb 2018, at 12:44, Carsten Ziegeler <cz...@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
>>>
>>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Konrad Windszus <ko...@gmx.de>.
@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).
Konrad
> On 26. Feb 2018, at 12:44, Carsten Ziegeler <cz...@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
>>
>>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Oliver Lietz <ap...@oliverlietz.de>.
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
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Carsten Ziegeler <cz...@apache.org>.
The individual artifacts are fine and they where already part of parent
pom 32 for the annotations. Not having the annotations in the parent pom
requires to repeat this in each and every project now, making the move
from anything below 33 to 33 a pain.
Regards
Carsten
Konrad Windszus wrote
> Actually Oli switched to individual spec chapter artifacts and there was also some discussion triggered by me in the comments (e.g. https://issues.apache.org/jira/browse/SLING-7384?focusedCommentId=16327408&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16327408).
>
> It was you Carsten, who answered and said
> "But again, in general its better to use the above mentioned single purpose artifacts".
>
> Therefore you have to include the individual annotation artifacts (which are all managed in parent) in your project!
> Please clarify if there was some misunderstanding there.
> Konrad
>
>> On 26. Feb 2018, at 12:15, Carsten Ziegeler <cz...@apache.org> wrote:
>>
>> Hi
>>
>> 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?
>>
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [Maven] Updating to parent pom 33 breaks all projects
Posted by Konrad Windszus <ko...@gmx.de>.
Actually Oli switched to individual spec chapter artifacts and there was also some discussion triggered by me in the comments (e.g. https://issues.apache.org/jira/browse/SLING-7384?focusedCommentId=16327408&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16327408).
It was you Carsten, who answered and said
"But again, in general its better to use the above mentioned single purpose artifacts".
Therefore you have to include the individual annotation artifacts (which are all managed in parent) in your project!
Please clarify if there was some misunderstanding there.
Konrad
> On 26. Feb 2018, at 12:15, Carsten Ziegeler <cz...@apache.org> wrote:
>
> Hi
>
> 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?
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org