[jira] [Updated] (GROOVY-8666) New partial groovy 2.5 causes split-packages itself
[ https://issues.apache.org/jira/browse/GROOVY-8666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-8666: -- Priority: Major (was: Minor) > New partial groovy 2.5 causes split-packages itself > --- > > 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: Major > > 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)
[jira] [Updated] (GROOVY-8666) New partial groovy 2.5 causes split-packages itself
[ https://issues.apache.org/jira/browse/GROOVY-8666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-8666: -- Priority: Minor (was: Blocker) > New partial groovy 2.5 causes split-packages itself > --- > > Key: GROOVY-8666 > URL: https://issues.apache.org/jira/browse/GROOVY-8666 > Project: Groovy > Issue Type: Bug > Components: release, XML Processing >Affects Versions: 2.5.0 >Reporter: Josef Härtl >Priority: Minor > > 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)
[jira] [Updated] (GROOVY-8666) New partial groovy 2.5 causes split-packages itself
[ https://issues.apache.org/jira/browse/GROOVY-8666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-8666: -- Component/s: (was: XML Processing) > New partial groovy 2.5 causes split-packages itself > --- > > 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: Minor > > 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)
[jira] [Updated] (GROOVY-8666) New partial groovy 2.5 causes split-packages itself
[ https://issues.apache.org/jira/browse/GROOVY-8666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josef Härtl updated GROOVY-8666: Description: 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. was: 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. 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. > New partial groovy 2.5 causes split-packages itself > --- > > Key: GROOVY-8666 > URL: https://issues.apache.org/jira/browse/GROOVY-8666 > Project: Groovy > Issue Type: Bug > Components: release, XML Processing >Affects Versions: 2.5.0 >Reporter: Josef Härtl >Priority: Blocker > > 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)
[jira] [Updated] (GROOVY-8666) New partial groovy 2.5 causes split-packages itself
[ https://issues.apache.org/jira/browse/GROOVY-8666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josef Härtl updated GROOVY-8666: Description: 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. 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. was: 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 as very serious problems can arise from that. 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. > New partial groovy 2.5 causes split-packages itself > --- > > Key: GROOVY-8666 > URL: https://issues.apache.org/jira/browse/GROOVY-8666 > Project: Groovy > Issue Type: Bug > Components: release, XML Processing >Affects Versions: 2.5.0 >Reporter: Josef Härtl >Priority: Blocker > > 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. > 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)
[jira] [Updated] (GROOVY-8666) New partial groovy 2.5 causes split-packages itself
[ https://issues.apache.org/jira/browse/GROOVY-8666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josef Härtl updated GROOVY-8666: Description: 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 as very serious problems can arise from that. 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. was: 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 as very serious problems can arise from that. Therefore, the splitting of groovy 2.5 into smaller pieces introduced split-packages to itself. > New partial groovy 2.5 causes split-packages itself > --- > > Key: GROOVY-8666 > URL: https://issues.apache.org/jira/browse/GROOVY-8666 > Project: Groovy > Issue Type: Bug > Components: release, XML Processing >Affects Versions: 2.5.0 >Reporter: Josef Härtl >Priority: Blocker > > 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 as very serious problems can arise from that. > 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)
[jira] [Updated] (GROOVY-8666) New partial groovy 2.5 causes split-packages itself
[ https://issues.apache.org/jira/browse/GROOVY-8666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josef Härtl updated GROOVY-8666: Description: 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 as very serious problems can arise from that. Therefore, the splitting of groovy 2.5 into smaller pieces introduced split-packages to itself. was: 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. Therefore, the splitting of groovy 2.5 into smaller pieces introduced split-packages to itself. > New partial groovy 2.5 causes split-packages itself > --- > > Key: GROOVY-8666 > URL: https://issues.apache.org/jira/browse/GROOVY-8666 > Project: Groovy > Issue Type: Bug > Components: release, XML Processing >Affects Versions: 2.5.0 >Reporter: Josef Härtl >Priority: Blocker > > 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 as very serious problems can arise from that. > Therefore, the splitting of groovy 2.5 into smaller pieces introduced > split-packages to itself. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GROOVY-8666) New partial groovy 2.5 causes split-packages itself
[ https://issues.apache.org/jira/browse/GROOVY-8666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josef Härtl updated GROOVY-8666: Description: 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. Therefore, the splitting of groovy 2.5 into smaller pieces introduced split-packages to itself. was: 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) 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. Therefore, the splitting of groovy 2.5 into smaller pieces introduced split-packages to itself. > New partial groovy 2.5 causes split-packages itself > --- > > Key: GROOVY-8666 > URL: https://issues.apache.org/jira/browse/GROOVY-8666 > Project: Groovy > Issue Type: Bug > Components: release, XML Processing >Affects Versions: 2.5.0 >Reporter: Josef Härtl >Priority: Blocker > > 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. > Therefore, the splitting of groovy 2.5 into smaller pieces introduced > split-packages to itself. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
