+1
Carsten
On 21.01.2020 14:25, David Bosschaert wrote:
I've added the JIRA as requested by Konrad:
https://issues.apache.org/jira/browse/SLING-9018
+1 from me.
David
On Tue, 21 Jan 2020 at 13:09, Carsten Ziegeler <cziege...@apache.org> wrote:
@David:
Maven correctly constructs the plugin classpath, you will not end up
with two versions of the same dependency in a classpath for a plugin.
But of course each plugin can use a different version as it has its own
dependency chain - I assume that caused the problems you were seeing
@Konrad: Its getting OT here, but embedding complete bundles is probably
causing problems over time. Its better to not embed.
Regards
Carsten
On 21.01.2020 13:30, dav...@apache.org wrote:
Hi Konrad,
Yes, I know that Maven tries to manage this but I have seen cases where
it
didn't work. Since the Feature IO component has so many downstream deps I
thought it would be safer to release it so that we're sure that the right
version is picked up.
I'll create a JIRA for it.
Best regards,
David
On Tue, 21 Jan 2020 at 12:23, Konrad Windszus <konra...@gmx.de> wrote:
IMHO Maven manages version conflicts, so you will never(!) end up with
the
same artifact in two versions in your classpath (but either the old one
or
the new one, depending on which is closer in the dependency tree or
which
version is managed)
Also Sling Feature Model IO is now embedded in the OSGi Installer Core,
so
in fact it is used outside the Maven Plugins and I was wondering
whether an
update is necessary here...
Therefore I would still appreciate a JIRA with a short reasoning for
Models IO.
Konrad
On 21. Jan 2020, at 12:55, dav...@apache.org wrote:
Hi Konrad,
Yes all that you say is true for OSGi bundles, but these are
dependencies
of 2 maven plugins: the slingfeature-maven-plugin and the
slingstart-maven-plugin (which are also included in the release). With
Maven the don't have the clean classpath separation that you get with
OSGi
bundles.
There are new APIs in the feature model that are used downstream through
those maven plugins.
Basically those plugins have a direct (or indirect) dependency on the
Feature IO component. By traversing through the pom.xmls Maven builds up
its dependency tree. If I didn't release the Feature IO component it
would
still point at the old Feature Model pom and we'll end up with 2
versions
of the Feature Model component on the Maven plugin classpath, the new
one
(1.1.2) and an older one.
Because Maven doesn't have the classpath separation that OSGi has, this
can cause linkage errors.
So in short - because this component is used as a Maven Plugin
dependency
we unfortunately have to release it whenever a higher dependency is
changed.
Well, this is my understanding. And I've seen problems with this in the
past when we sometimes forgot to update all the intermediaries with
Maven
Plugins.
Best regards,
David
On Tue, 21 Jan 2020 at 11:44, Konrad Windszus <konra...@gmx.de> wrote:
Well, I think consensus is that bundles always should aim for
backwards-compatibility. IMHO they should reference the oldest
dependency
version still supported (in case they don't embed the dependency)
In this particular case I fail to see why you have to upgrade to a
newer
API?
Is that newer API being used by Feature Model IO?
Otherwise I would prefer sticking to the old dependency version.
Or is it not forward-compatible with the new Feature Model API? In that
case that definitely deserves a JIRA,
Konrad
On 21. Jan 2020, at 12:37, dav...@apache.org wrote:
Hi Konrad,
The Feature IO component didn't get any changes other than that its
dependency on the feature model was moved to the latest version.
I thought about creating a 'dummy' JIRA, but I think it's probably
clearer to not have any in cases where there actually weren't any
changes
(other than the update of dependencies). There is a release version in
Jira
so you can see this clearly IMHO...
But if general consensus is that we need a JIRA for this, I can add
one.
Not sure what would be in it though...
Best regards,
David
On Tue, 21 Jan 2020 at 11:32, Konrad Windszus <konra...@gmx.de> wrote:
Can we have at least one JIRA issue per new release?
This is currently empty:
https://issues.apache.org/jira/projects/SLING/versions/12346774
On 21. Jan 2020, at 12:29, dav...@apache.org wrote:
Hi all,
I would like to call the release on the following Sling Apache
components:
Feature Model 1.1.2
https://issues.apache.org/jira/projects/SLING/versions/12346060
Feature Model IO 1.2.2
https://issues.apache.org/jira/projects/SLING/versions/12346774
Feature Model Analyser 1.2.4
https://issues.apache.org/jira/projects/SLING/versions/12346646
Feature Model Converter 1.0.12
https://issues.apache.org/jira/projects/SLING/versions/12346753
Feature Model Launcher 1.1.2
https://issues.apache.org/jira/projects/SLING/versions/12346049
Feature Model API Regions Runtime Fragment 1.0.6
https://issues.apache.org/jira/projects/SLING/versions/12346743
Feature Model API Regions Extension 1.1.2
https://issues.apache.org/jira/projects/SLING/versions/12346471
Feature Model Content Extension 1.0.6
https://issues.apache.org/jira/projects/SLING/versions/12345655
Feature Diff 0.0.6
https://issues.apache.org/jira/projects/SLING/versions/12345846
slingfeature-maven-plugin 1.1.14
https://issues.apache.org/jira/projects/SLING/versions/12346857
Slingstart Maven Plugin 1.9.8
https://issues.apache.org/jira/projects/SLING/versions/12346754
Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-2185
You can use this UNIX script to download the release and verify the
signatures:
https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD
Usage:
sh check_staged_release.sh 2185 /tmp/sling-staging
Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't release, because ...
This majority vote is open for at least 72 hours.
Best regards,
David
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
