groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul King (JIRA)" <>
Subject [jira] [Commented] (GROOVY-8666) groovy-all pom approach breaks OSGi due to split-packages
Date Fri, 29 Jun 2018 12:58:00 GMT


Paul King commented on GROOVY-8666:

Nice find. I'll try that tomorrow in my experiments.


I went down this path:

I can create an empty jar with the appropriate Require-Bundle information in the MANIFEST
and have it produced as a groovy-all jar with an osgi classifier but I haven't managed to
publish it locally yet via our normal build process perhaps since we specify packaging as
pom. Then again, I am unsure of the downsides of Require-Bundle. It isn't ideal but seems
like a potential way forward.


But I'll give your approach a go first. See if bnd likes that header.

> groovy-all pom approach breaks OSGi due to split-packages
> ---------------------------------------------------------
>                 Key: GROOVY-8666
>                 URL:
>             Project: Groovy
>          Issue Type: Bug
>          Components: release
>    Affects Versions: 2.5.0
>            Reporter: Josef Härtl
>            Priority: Critical
> The splitting of groovy into smaller causes another, very major, problem:
> First, consider the "main" groovy jar: It contains the package groovy.util with numerous
> Secondly, consider the groovy-xml jar. It contains the package groovy.util and therein
the classes XMLParser etc.
> Regardless whether you use OSGi (like in our case) or Java 9 (what we are migrating to):
This presents a split-package itself: As we already reproduced in our build: Whatever jar
of these is loaded first wins the groovy.util package and "overrides" the other.
> As a result, it's become random whether our users can use XMLParser or not. Sometimes
it is found, sometimes it's not. I consider this a very major problem and a blocker as it
makes execution unreliable and randomish. I did not check but somewhat guess that this is
not the only collision of this sort.
> Therefore, the splitting of groovy 2.5 into smaller pieces introduced split-packages
to itself. If one wants to split groovy, the split will have to follow package borders.

This message was sent by Atlassian JIRA

View raw message