groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul King (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GROOVY-8666) groovy-all pom approach breaks OSGi due to split-packages
Date Sun, 01 Jul 2018 09:41:00 GMT

    [ https://issues.apache.org/jira/browse/GROOVY-8666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16529028#comment-16529028
] 

Paul King commented on GROOVY-8666:
-----------------------------------

This has been applied just on the GROOVY_2_5_X branch (for 2.5.1+) but not on master (for
Groovy 3). The presumption is that we will have removed the split packages by then and this
change won't be needed. But we'll need to do some testing when the time comes. We don't have
any tests involving an OSGi container in our test suite at present. I'd appreciate any advice
on best ways to do that.

> groovy-all pom approach breaks OSGi due to split-packages
> ---------------------------------------------------------
>
>                 Key: GROOVY-8666
>                 URL: https://issues.apache.org/jira/browse/GROOVY-8666
>             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
classes.
> 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
(v7.6.3#76005)

Mime
View raw message