[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cross-project-issues-dev] Two versions of ASM 9.3.0
|
Using the analysis tool that I occasionally have time to develop
further, I can see the following details about the older version
of ASM. ECF contains two older asm versions, though it's not
necessarily the only one, it's just the the one to which I assign
IUs early. You can see here all the capabilities provided by this
IU (brown right arrow decorated). Below each capability are the
requirements (blue left arrow decorated) that can be resolved to
that capability:

The breadcrumb---which I wish was AP because it's incredibly
useful and easy to use, but is internal to JDT---shows the tree
path of the current selection; from this we can see easily that
this IU comes from ECF's contribution.
Having expanded all the capabilities above, we can see at a
glance what requires this IU and how it requires this IU. We can
also see the range of each such requirement and from this we can
see that only ATL's feature inclusion of the asm bundle strictly
requires this older version.
Looking at the newer asm version (also available in ECF), I've
selected all the requirements that would preclude a 9.3 version
when it comes into the picture:

I opened this bug for the cause of the 9.1 version being present:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=579737
But clearly it's going to be work to get rid of 9.2 as well and
that effort will be made more complex by multiple
"versions/sources" of 9.3, perhaps all signed by different project
PGP signatures/keys, none carrying the original Maven
signature/key of the artifact.
Regards,
Ed
On 20.04.2022 18:03, Jonah Graham
wrote:
I think there are two
cases:
1) ASM is only included transitively (e.g. there is no
feature
referencing it) and everyone uses a proper version range.
2) It is referenced directly with a fixed version
In the first case i think we don't have a problem as it
either is not
part of the updatesite or p2 will chose only one version
In the second most probably two version will installed and
it now
depends how good the bundle is shaped (e.g. does it use
proper
use-clauses) if OSGi will sort that out at runtime.
ASM does not have any uses clauses in its manifest (maybe
it doesn't need them) - and p2 does not use "uses" when
choosing which bundles to install.
Manifest-Version: 1.0
Bundle-DocURL: http://asm.ow2.org
Bundle-License: BSD-3-Clause;link=https://asm.ow2.io/LICENSE.txt
Bundle-ManifestVersion: 2
Bundle-Name: org.objectweb.asm
Bundle-RequiredExecutionEnvironment: J2SE-1.5
Bundle-SymbolicName: org.objectweb.asm
Bundle-Version: 9.3.0
Export-Package:
org.objectweb.asm;version="9.3",org.objectweb.asm.sign
ature;version="9.3"
Implementation-Title: ASM, a very small and fast Java
bytecode manipul
ation framework
Implementation-Version: 9.3
Jonah
To make the second case more lax, I have opened a bug [1] at
Tycho to
support version range inclusion of features so one do not
need to stick
to a strict version. Then it would even be possible to
resolve this on
p2 level and p2 will simply choose the highest matching
version to install.
[1] https://github.com/eclipse/tycho/issues/898
Am 20.04.22 um 00:26 schrieb Jonah Graham:
>
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
<http://www.kichwacoders.com>
>
>
> On Tue, 19 Apr 2022 at 16:28, Aleksandar Kurtakov <akurtako@xxxxxxxxxx
> <mailto:akurtako@xxxxxxxxxx>>
wrote:
>
>
>
> On Tue, Apr 19, 2022 at 11:12 PM Jonah Graham
> <jonah@xxxxxxxxxxxxxxxx
<mailto:jonah@xxxxxxxxxxxxxxxx>>
wrote:
>
>
>
> On Tue., Apr. 19, 2022, 15:49 Aleksandar
Kurtakov,
> <akurtako@xxxxxxxxxx
<mailto:akurtako@xxxxxxxxxx>>
wrote:
>
>
>
> On Tue, Apr 19, 2022 at 10:39 PM Nitin
Dahyabhai
> <thatnitind@xxxxxxxxx
<mailto:thatnitind@xxxxxxxxx>>
wrote:
>
> Unless and until there is a pressing
need for a newer
> version than what's in Orbit--which has
a recipe that
> can be updated should that need
arise--couldn't the
> Platform stop simply stop packaging its
own?
>
>
> That's kind of what happened - [1] and [2].
At the time
> Platform (PDE actually) had the need and
work was initiated
> there was nothing in Orbit - [3].
>
>
> So now that it is orbit would a PR to consume
that one when M2
> orbit is ready be welcome?
>
>
>
> What happens next time PDE/JDT needs new ASM? Same
dance? This
> doesn't sound like a good long term plan to me.
>
> My personal opinion is that it's better to stop
putting things in
> Orbit when upstream provides OSGi bundles in Maven
central but use
> directly.
>
>
> OK - in that case we have some specific SimRel testing
to do:
>
> 1- Which bundles ends up SimRel - or do both end up
there. I assume that
> it will be the Orbit one because it is more recent as
far as p2 is
> concerned (not sure, just best guess).
> 2- Starting from the SDK, does installing features from
SimRel cause
> both to be installed, and if so, are both resolved.
>
> I have added the above test to my M2 checks I will do -
> https://git.eclipse.org/r/c/epp/org.eclipse.epp.packages/+/192830
> <https://git.eclipse.org/r/c/epp/org.eclipse.epp.packages/+/192830>
-
> and I will report back then.
>
> Jonah
>
>
>
> Thanks,
> Jonah
>
>
> [1]
> https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/commit/8f79635e7217ecb24dbc209b964711e66a8f322d
> <https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/commit/8f79635e7217ecb24dbc209b964711e66a8f322d>
> [2]
> https://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=16b27f6531af3cf41bc73bdfb27a581565f9dc33
> <https://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=16b27f6531af3cf41bc73bdfb27a581565f9dc33>
> [3] https://github.com/eclipse-pde/eclipse.pde.ui/issues/11
> <https://github.com/eclipse-pde/eclipse.pde.ui/issues/11>
>
>
_______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> <https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
>
_______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> <https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
<https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> <https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev