[jira] [Comment Edited] (GROOVY-8666) groovy-all pom approach breaks OSGi due to split-packages

["Josef Härtl (JIRA)" <ji...@apache.org>]

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

Josef Härtl edited comment on GROOVY-8666 at 6/29/18 11:41 AM:
---------------------------------------------------------------

Another finding: I analysed our project for further split-packages and found that Eclipse RCP does in fact use split-packages successfully. It does so by defining OSGi Fragments instead of full bundles. The technique is for example described in here: [https://www.ibm.com/support/knowledgecenter/SSRTLW_8.5.5/com.ibm.osgi.common.doc/topics/cbundlefragment.html] and [https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module.fragmenthost]. This way the fragment (in our case groovy-xml) could live inside the groovy bundle and add it's own classes.


was (Author: josef härtl):
Another finding: I analysed our project for further split-packages and found that Eclipse RCP does in fact use split-packages successfully. It does so by defining OSGi Fragments instead of full bundles. The technique is for example described in here: [https://www.ibm.com/support/knowledgecenter/SSRTLW_8.5.5/com.ibm.osgi.common.doc/topics/cbundlefragment.html] . This way the fragment (in our case groovy-xml) could live inside the groovy bundle and add it's own classes.

> 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
>            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 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)