groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josef Härtl (JIRA) <>
Subject [jira] [Commented] (GROOVY-8666) groovy-all pom approach breaks OSGi due to split-packages
Date Mon, 02 Jul 2018 05:53:00 GMT


Josef Härtl commented on GROOVY-8666:

OK thanks.

I'll do some tests with the Snapshots in our application(s).

I agree to the presumption to include this only to 2.X, not to 3.X. Resolving the split in
the package structure for java modules should also mend it for osgi.

On automatically testing it in a test suite: As unsatisfactory as it is: I'm unsure of how
or even whether this can be done realistically.

The ones who initially designed our application once designed it w/o tests regarding osgi
itself, they just did junit tests that considered the osgi bundles as plain java and mocked
osgi apart. As one can see with this ticket, this won't always suffice. 

Some time ago we implemented some kind of verification-feature inside our application itself
that can be used by our users, but also by ourselves to verify the application as a whole
is behaving like it should and to verify it still behaves like in previous releases. That
way it's tested in the most realistic way possible. Many tests in there are using groovy.
However, the shadowed package area was smally enough to leap through our tests / did not interfere
with them. Complex as they were, they did not use xml parsing of groovy.

I'm also increasing our tests for shadowing/split-packages in general. But this is also done
without junit or the like. Instead, i'm analysing the structure of all our osgi bundles used
by a custom script producing a list of potential overlaps to be examined by some of us. Only
this way i can see all potential overlaps without relying on sheer luck testing the right
thing at the right time. This way i also found the fragment-approach as eclipse itself makes
much use of it.

Other than that, it's going to be difficult i'm afraid. Already testing out the bug of this
ticket proved that: While our client (based on Eclipse RCP that's based on equinox) showed
random behaviour whether XPathUtil would be present or not (depending on the loading order
of the bundles), our server (equinox-jetty) more or less resorted to a state of constant denial.
In the end shadowing/split-package-problems like this totally depend on the loading order.
From then on, it can be random, never found or always occur. From a quick search: There seem
to be some libraries for testing osgi inside an osgi environment. But in the end the results
will heavily depend on their loading mechanism and configuration. As some kind of osgi-tester
would have to include something like that, it would bias the result straight away.

So i'm a bit out of luck on that. Should some osgi expert come by, i would appreciate any
input on automatically testing something like this myself.

> 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
>            Assignee: Paul King
>            Priority: Critical
>             Fix For: 2.5.1
> 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