>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
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
>
> Maybe we can have a compromise and require a property in the pom, e.g.
>
>
>true
>
>
> 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
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
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
+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:
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:
> >
> >
> >
> > org.osgi
> > org.osgi.annotation.versioning >
> > d>
> >
> >
On Mon, 2018-02-26 at 12:54 +0100, Carsten Ziegeler wrote:
> I'm talking about:
>
>
>
> org.osgi
> org.osgi.annotation.versioning d>
> 1.0.0
> provided
>
>
>
>
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
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
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
>
>
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
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 –
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
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
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
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
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,
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
I'm talking about:
org.osgi
org.osgi.annotation.versioning
1.0.0
provided
org.osgi
org.osgi.service.component.annotations
1.3.0
@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
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
>
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
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
>
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=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16327408).
It
25 matches
Mail list logo
