[cross-project-issues-dev] Orbit Bundles To Be Removed From 2018-09 M3

Possible impacts:

org.eclipse.recommenders.injection 2.5.3.v20180609-1554 requires
com.google.guava 15.0. Unsure if a newer version exists which works w/
Guava 21..

Not sure about the com.ibm.icu stuff -- is 62 compatible with 58?

The rest - the apache felix and ant stuff - should hopefully be fine.

As to Lucene removals:

* org.eclipse.recommenders.models 2.5.3 requires lucene.core 3.5

* o.e.epp.logging.aeri.feature requires lucene.analysis 6.1

* org.eclipse.datatools.sqltools.result (DTP) and
org.eclipse.m2e.wtp.jpa.feature (WTP) both
require org.apache.lucene.queryparser 6.1.0.v20161115-1612, which doesn't
exist in 7.1 (Lucene loves to add and drop bundles will-nilly, don't they?)

So... either those bundles / features need updating to use lucene 7.1+ or
else they'll have to build against old Orbit... and Simrel will end up
having multiple versions of these IUs peppered in the mix.

What version of HttpComponents are you thinking would be included/dropped?
Currently I'm using httpcore 4.4.6 and httpclient 4.5.2, but I think I saw
a thread about Platform moving to newer versions? cc: @Aleksandar Kurtakov
<***@redhat.com>

Nick

Post by Roland Grunberg
Hey all,
I just wanted to give a heads-up that the following bundles (and
corresponding source bundles) are expected to be removed from the Orbit
build towards 2018-09, for M3 [1].
com.ibm.icu 56.1.0, 58.2.0 (use 62.0.0)
com.ibm.icu.base 56.1.0, 58.2.0 (use com.ibm.icu 62.0.0)
org.apache.felix.gogo.runtime 1.0.6 (use 1.1.0)
org.apache.felix.gogo.shell 1.0.0 (use 1.1.0)
org.apache.felix.scr 2.0.8, 2.0.10, 2.0.12 (use 2.0.14)
com.google.guava 15.0.0, 18.0.0 (use 21.0.0)
org.apache.ant 1.9.6, 1.10.3 (use 1.10.5, will be in soon)
There may be some additional bundles but they would be announced later
on (possibly older Lucene, tukaani.xz, ASM, HttpComponents).
If any projects are unable to update for some reason, or there's a good
reason not to remove one of these that I've missed, It would be good to
know ahead of time, though there is always the option to reference an
older build (eg. Photon) that would still contain them as well.
Thank-you,
Roland Grunberg
[1]
https://wiki.eclipse.org/SimRel/2018-09/Simultaneous_Release_Plan#Schedule
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
Nick Boldt

Principal Software Engineer, RHCSA

Productization Lead :: JBoss Tools & Dev Studio

IM: @nickboldt / @nboldt / http://nick.divbyzero.com
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
@ @redhatnews <https://twitter.com/redhatnews> Red Hat
<https://www.facebook.com/RedHatInc>
<https://www.facebook.com/RedHatInc>

âThe Only Thing That Is Constant Is Changeâ - Heraclitus

Roland Grunberg

2018-08-01 20:36:27 UTC

Post by Nick Boldt
* org.eclipse.recommenders.models 2.5.3 requires lucene.core 3.5
* o.e.epp.logging.aeri.feature requires lucene.analysis 6.1
* org.eclipse.datatools.sqltools.result (DTP) and org.eclipse.m2e.wtp.jpa.feature (WTP) both require org.apache.lucene.queryparser 6.1.0.v20161115-1612, which doesn't exist in 7.1 (Lucene loves to add and drop bundles will-nilly, don't they?)
So... either those bundles / features need updating to use lucene 7.1+ or else they'll have to build against old Orbit... and Simrel will end up having multiple versions of these IUs peppered in the mix.

You've highlighted another issue, which is that sometimes, when a newer
version of a set of bundles gets pushed in, the initial contributor
will handle the ones that are of interest to their project. lucene-
queryparser does exist for > 6.1.0, but likely some class(es) within it
were moved elsewhere and there was no need to include it.
Yes, I believe they'd move to httpcore 4.4.9 / httpclient 4.5.5 . I'm
fine with not removing certain sets of bundles (eg. lucene,
httpcomponents) but I did want to clean up some known cases where it's
used/updated by a single project that always migrates to the newer
version.

Cheers,

--
Roland Grunberg

Nick Boldt

2018-08-01 20:53:04 UTC

So can you push lucene-queryparser 7.1 into Orbit for 201809M3?

JBoss Tools & RH devstudio will use it too, as devstudio depends on JBT,
which depends on WTP, which depends on DTP.

Post by Nick Boldt

Post by Nick Boldt
* org.eclipse.recommenders.models 2.5.3 requires lucene.core 3.5
* o.e.epp.logging.aeri.feature requires lucene.analysis 6.1
* org.eclipse.datatools.sqltools.result (DTP) and

org.eclipse.m2e.wtp.jpa.feature (WTP) both require
org.apache.lucene.queryparser 6.1.0.v20161115-1612, which doesn't exist in
7.1 (Lucene loves to add and drop bundles will-nilly, don't they?)

Post by Nick Boldt
So... either those bundles / features need updating to use lucene 7.1+

or else they'll have to build against old Orbit... and Simrel will end up
having multiple versions of these IUs peppered in the mix.
You've highlighted another issue, which is that sometimes, when a newer
version of a set of bundles gets pushed in, the initial contributor
will handle the ones that are of interest to their project. lucene-
queryparser does exist for > 6.1.0, but likely some class(es) within it
were moved elsewhere and there was no need to include it.

Post by Nick Boldt
What version of HttpComponents are you thinking would be

included/dropped? Currently I'm using httpcore 4.4.6 and httpclient 4.5.2,
@Aleksandar Kurtakov
Yes, I believe they'd move to httpcore 4.4.9 / httpclient 4.5.5 . I'm
fine with not removing certain sets of bundles (eg. lucene,
httpcomponents) but I did want to clean up some known cases where it's
used/updated by a single project that always migrates to the newer
version.
Cheers,
--
Roland Grunberg
_______________________________________________
orbit-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/orbit-dev

Roland Grunberg

2018-08-02 18:44:17 UTC

Post by Nick Boldt
So can you push lucene-queryparser 7.1 into Orbit for 201809M3?

It should be possible. It looks like it depends on lucene-
{queries,sandbox,codec} but they may have been optional looking at how
6.1.0 was done.

You would need to figure out exactly which bundles are needed, and file
CQs for them.

Cheers,

--
Roland Grunberg

Andreas Sewe

2018-08-02 06:58:21 UTC

Post by Nick Boldt
* org.eclipse.recommenders.models 2.5.3 requires lucene.core 3.5

Again, we can't switch because we need to parse an Lucene 3.x index
downloaded from the model repository, which newer Lucene versions can't
parse anymore. Migration strategy would be to deploy both 3.x and 7.x
indexes to download.eclipse.org, but we don't have the resources to do
this for 2018-09.

Post by Nick Boldt
* o.e.epp.logging.aeri.feature requires lucene.analysis 6.1

Similar scenario than Code Recommenders (built by the same guys...).
Here, however, we may get rid of the index downloads, as we have (since
Oxygen.2) a REST API in place that does the queries on demand; under
normal circumstances, they won't be answered from the index anymore.

I'll see what I can do here.

Best wishes,

Andreas
--
Codetrails GmbH
The best code possible

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940

Andreas Sewe

2018-08-06 18:22:25 UTC

Post by Nick Boldt
* o.e.epp.logging.aeri.feature requires lucene.analysis 6.1

Nick, are you sure? I just checked and all I can see are Import-Packages
on Lucene [7.1.0,8.0.0). Also, the update site [1] offers only Lucene 7.

Can you please clarify?

Best wishes,

Andreas

[1] <http://download.eclipse.org/technology/epp/logging/head/>
--
Codetrails GmbH
The best code possible

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940

Nick Boldt

2018-08-08 20:37:35 UTC

I'm still using org.eclipse.epp.logging.aeri.feature.feature.group
2.0.7.v20170906-1327
in my target platform.

Perhaps you updated it to depend on Lucene 7.1.0+ recently ? I see
that 2.0.7.v20180504-0806 does have a dep on [7.1.0,8.0.0).

Aside: Aeri 2.0.7 was released in Photon. Surely it's time to upversion to
2.0.8? Even if the timestamp is newer, it's good practice to have a new
x.y.z version for a new train, even if it's just z+1.

Post by Nick Boldt
* o.e.epp.logging.aeri.feature requires lucene.analysis 6.1

Nick, are you sure? I just checked and all I can see are Import-Packages
on Lucene [7.1.0,8.0.0). Also, the update site [1] offers only Lucene 7.
Can you please clarify?
Best wishes,
Andreas
[1] <http://download.eclipse.org/technology/epp/logging/head/>
--
Codetrails GmbH
The best code possible
Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791
http://www.codetrails.com/
Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940

Donát Csikós

2018-08-09 07:50:10 UTC

Martin, you are correct, we scheduled the Guava 15 -> 21 update for
Buildship 3.0 which we plan to contribute to Eclipse 2018-12. Would that be
a reasonable deadline for the code recommenders project too?

I'm still using org.eclipse.epp.logging.aeri.feature.feature.group 2.0.7.v20170906-1327
in my target platform.
Perhaps you updated it to depend on Lucene 7.1.0+ recently ? I see
that 2.0.7.v20180504-0806 does have a dep on [7.1.0,8.0.0).
Aside: Aeri 2.0.7 was released in Photon. Surely it's time to upversion to
2.0.8? Even if the timestamp is newer, it's good practice to have a new
x.y.z version for a new train, even if it's just z+1.

Post by Nick Boldt
* o.e.epp.logging.aeri.feature requires lucene.analysis 6.1

Nick, are you sure? I just checked and all I can see are Import-Packages
on Lucene [7.1.0,8.0.0). Also, the update site [1] offers only Lucene 7.
Can you please clarify?
Best wishes,
Andreas
[1] <http://download.eclipse.org/technology/epp/logging/head/>
--
Codetrails GmbH
The best code possible
Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791
http://www.codetrails.com/
Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940

--
Nick Boldt
Principal Software Engineer, RHCSA
Productization Lead :: JBoss Tools & Dev Studio
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
@ @redhatnews <https://twitter.com/redhatnews> Red Hat
<https://www.facebook.com/RedHatInc>
<https://www.facebook.com/RedHatInc>
âThe Only Thing That Is Constant Is Changeâ - Heraclitus
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Roland Grunberg

2018-08-09 13:27:00 UTC

This seems fine. I can always go ahead and remove only the bundles for
which no removal issues have been mentioned.

Post by DonÃ¡t CsikÃ³s
Martin, you are correct, we scheduled the Guava 15 -> 21 update for
Buildship 3.0 which we plan to contribute to Eclipse 2018-12. Would that be
a reasonable deadline for the code recommenders project too?

I'm still using org.eclipse.epp.logging.aeri.feature.feature.group 2.0.7.v20170906-1327
in my target platform.
Perhaps you updated it to depend on Lucene 7.1.0+ recently ? I see
that 2.0.7.v20180504-0806 does have a dep on [7.1.0,8.0.0).
Aside: Aeri 2.0.7 was released in Photon. Surely it's time to upversion
to 2.0.8? Even if the timestamp is newer, it's good practice to have a new
x.y.z version for a new train, even if it's just z+1.

Post by Nick Boldt
* o.e.epp.logging.aeri.feature requires lucene.analysis 6.1

Nick, are you sure? I just checked and all I can see are Import-Packages
on Lucene [7.1.0,8.0.0). Also, the update site [1] offers only Lucene 7.
Can you please clarify?
Best wishes,
Andreas
[1] <http://download.eclipse.org/technology/epp/logging/head/>
--
Codetrails GmbH
The best code possible
Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791
http://www.codetrails.com/
Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940

Tom Schindl

2018-10-03 13:44:02 UTC

Hi,

I'm late to this but while trying to bring our products up to 2018-09 I
found the removal of "com.ibm.icu.base" disturbing.

The Mail from "Roland" says one should substitute "com.ibm.icu.base"
with "com.ibm.icu" which I think is a bad idea.

The sole reason for "com.ibm.icu.base" was/is that you don't ship a 12MB
jar if you don't need any of the extra functionality "com.ibm.icu" provides.

Tom

Post by Nick Boldt
org.eclipse.recommenders.injection 2.5.3.v20180609-1554 requires
com.google.guava 15.0. Unsure if a newer version exists which works w/
Guava 21..
Not sure about the com.ibm.icu stuff -- is 62 compatible with 58?
The rest - the apache felix and ant stuff - should hopefully be fine.
* org.eclipse.recommenders.models 2.5.3 requires lucene.core 3.5
* o.e.epp.logging.aeri.feature requires lucene.analysis 6.1
* org.eclipse.datatools.sqltools.result (DTP) and
org.eclipse.m2e.wtp.jpa.feature (WTP) both
require org.apache.lucene.queryparser 6.1.0.v20161115-1612, which
doesn't exist in 7.1 (Lucene loves to add and drop bundles will-nilly,
don't they?)
So... either those bundles / features need updating to use lucene 7.1+
or else they'll have to build against old Orbit... and Simrel will end
up having multiple versions of these IUs peppered in the mix.
What version of HttpComponents are you thinking would be
included/dropped? Currently I'm using httpcore 4.4.6 and httpclient
4.5.2, but I think I saw a thread about Platform moving to newer
Nick
Hey all,
I just wanted to give a heads-up that the following bundles (and
corresponding source bundles) are expected to be removed from the Orbit
build towards 2018-09, for M3 [1].
com.ibm.icu 56.1.0, 58.2.0 (use 62.0.0)
com.ibm.icu.base 56.1.0, 58.2.0 (use com.ibm.icu 62.0.0)
org.apache.felix.gogo.runtime 1.0.6 (use 1.1.0)
org.apache.felix.gogo.shell 1.0.0 (use 1.1.0)
org.apache.felix.scr 2.0.8, 2.0.10, 2.0.12 (use 2.0.14)
com.google.guava 15.0.0, 18.0.0 (use 21.0.0)
org.apache.ant 1.9.6, 1.10.3 (use 1.10.5, will be in soon)
There may be some additional bundles but they would be announced later
on (possibly older Lucene, tukaani.xz, ASM, HttpComponents).
If any projects are unable to update for some reason, or there's a good
reason not to remove one of these that I've missed, It would be good to
know ahead of time, though there is always the option to reference an
older build (eg. Photon) that would still contain them as well.
Thank-you,
Roland Grunberg
[1]
https://wiki.eclipse.org/SimRel/2018-09/Simultaneous_Release_Plan#Schedule
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Nick Boldt
Principal Software Engineer, RHCSA
Productization Lead :: JBoss Tools & Dev Studio
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
@ @redhatnews <https://twitter.com/redhatnews> Red Hat
<https://www.facebook.com/RedHatInc>
<https://www.facebook.com/RedHatInc>
“The Only Thing That Is Constant Is Change” - Heraclitus
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

Aleksandar Kurtakov

2018-10-03 15:09:35 UTC

Post by Tom Schindl
Hi,
I'm late to this but while trying to bring our products up to 2018-09 I
found the removal of "com.ibm.icu.base" disturbing.
The Mail from "Roland" says one should substitute "com.ibm.icu.base"
with "com.ibm.icu" which I think is a bad idea.
The sole reason for "com.ibm.icu.base" was/is that you don't ship a 12MB
jar if you don't need any of the extra functionality "com.ibm.icu" provides.

So far Platform has been doing the work to include both com.ibm.icu and
com.ibm.icu.base even though the later was not used by Platform in the last
5+ years. The way icu.base has been produced was a weird build coming from
IBM guys working on icu4j which was a really slow and controversial way to
do it with orbit recipes. So we stopped doing this time consuming task and
moved to plain recipe for com.ibm.icu. There is no com.ibm.icu.base I'm
aware of available either at maven central or icu4j projects downloads.
With all that said I don't see an issue having com.ibm.icu.base if whoever
is interested steps in and do the necessary CQ and orbit work to introduce
it at the version of the main com.ibm.icu bundle, for older versions one
can always use older Orbit repo.

Post by Tom Schindl
Tom

Orbit

Post by Nick Boldt
build towards 2018-09, for M3 [1].
com.ibm.icu 56.1.0, 58.2.0 (use 62.0.0)
com.ibm.icu.base 56.1.0, 58.2.0 (use com.ibm.icu 62.0.0)
org.apache.felix.gogo.runtime 1.0.6 (use 1.1.0)
org.apache.felix.gogo.shell 1.0.0 (use 1.1.0)
org.apache.felix.scr 2.0.8, 2.0.10, 2.0.12 (use 2.0.14)
com.google.guava 15.0.0, 18.0.0 (use 21.0.0)
org.apache.ant 1.9.6, 1.10.3 (use 1.10.5, will be in soon)
There may be some additional bundles but they would be announced

later

Post by Nick Boldt
on (possibly older Lucene, tukaani.xz, ASM, HttpComponents).
If any projects are unable to update for some reason, or there's a

good

Post by Nick Boldt
reason not to remove one of these that I've missed, It would be good

Post by Nick Boldt
know ahead of time, though there is always the option to reference an
older build (eg. Photon) that would still contain them as well.
Thank-you,
Roland Grunberg
[1]

https://wiki.eclipse.org/SimRel/2018-09/Simultaneous_Release_Plan#Schedule

Post by Nick Boldt
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Nick Boldt
Principal Software Engineer, RHCSA
Productization Lead :: JBoss Tools & Dev Studio
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
@ @redhatnews <https://twitter.com/redhatnews> Red Hat
<https://www.facebook.com/RedHatInc>
<https://www.facebook.com/RedHatInc>
âThe Only Thing That Is Constant Is Changeâ - Heraclitus
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe

from this list, visit

Post by Nick Boldt
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
Alexander Kurtakov
Red Hat Eclipse Team

Roland Grunberg

2018-10-03 15:25:31 UTC

Post by Tom Schindl
I'm late to this but while trying to bring our products up to 2018-09 I
found the removal of "com.ibm.icu.base" disturbing.
The Mail from "Roland" says one should substitute "com.ibm.icu.base"
with "com.ibm.icu" which I think is a bad idea.
The sole reason for "com.ibm.icu.base" was/is that you don't ship a 12MB
jar if you don't need any of the extra functionality "com.ibm.icu" provides.

Hey Tom,

If people would like to have corresponding com.ibm.icu.base for any
version of com.ibm.icu, that's fine. It would just be a matter of
ensuring the "base" version is available for the latest one in use as
I'd rather not accumulate many older versions. This is a similar
situation to things like Batik or Lucene, where platform handles the
set of bundles it cares about, but anyone wanting more has to do the
extra work.

The discussion for Platform to move to plain icu4j (from maven) was in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=536411 (comments 11-17)
so it made sense to have everyone using the same thing, but maybe other
projects outside SimRel may still want a smaller version so I'm not
opposing this. For those projects, there is also the Photon Orbit repo
which has the older versions (containing icu.base) as well.

Cheers,

--
Roland Grunberg

Tom Schindl

2018-10-03 18:03:44 UTC

Hi,

In the bug you reference I don't see that the platform has lifted any of
its version range so one can happily run the complete codebase on the
old icu.base version.

In the end the right thing for the future is to get rid of ibm.icu from
the core platform (anything defining an e4 application) is the right way
forward.

I understand that for a IDE it does not make a big difference if your
download is 12MB larger but for a small RCP application it can be.

Anyways I'm packaging it into our target now so e(fx)clipse users are
not affected because they anyways point to our self-contained p2 repository.

Tom

Post by Roland Grunberg

Hey Tom,
If people would like to have corresponding com.ibm.icu.base for any
version of com.ibm.icu, that's fine. It would just be a matter of
ensuring the "base" version is available for the latest one in use as
I'd rather not accumulate many older versions. This is a similar
situation to things like Batik or Lucene, where platform handles the
set of bundles it cares about, but anyone wanting more has to do the
extra work.
The discussion for Platform to move to plain icu4j (from maven) was in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=536411 (comments 11-17)
so it made sense to have everyone using the same thing, but maybe other
projects outside SimRel may still want a smaller version so I'm not
opposing this. For those projects, there is also the Photon Orbit repo
which has the older versions (containing icu.base) as well.
Cheers,

--
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

Fred Bricon

2018-10-03 19:59:22 UTC

FYI, jdt.ls uses com.ibm.icu.base because the full package represented
about 25% of the jdt.ls distro.
So keeping it is kind of a big deal for us.

Post by Tom Schindl
Hi,
In the bug you reference I don't see that the platform has lifted any of
its version range so one can happily run the complete codebase on the
old icu.base version.
In the end the right thing for the future is to get rid of ibm.icu from
the core platform (anything defining an e4 application) is the right way
forward.
I understand that for a IDE it does not make a big difference if your
download is 12MB larger but for a small RCP application it can be.
Anyways I'm packaging it into our target now so e(fx)clipse users are
not affected because they anyways point to our self-contained p2 repository.
Tom

Post by Roland Grunberg

provides.

Post by Roland Grunberg
Hey Tom,
If people would like to have corresponding com.ibm.icu.base for any
version of com.ibm.icu, that's fine. It would just be a matter of
ensuring the "base" version is available for the latest one in use as
I'd rather not accumulate many older versions. This is a similar
situation to things like Batik or Lucene, where platform handles the
set of bundles it cares about, but anyone wanting more has to do the
extra work.
The discussion for Platform to move to plain icu4j (from maven) was in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=536411 (comments 11-17)
so it made sense to have everyone using the same thing, but maybe other
projects outside SimRel may still want a smaller version so I'm not
opposing this. For those projects, there is also the Photon Orbit repo
which has the older versions (containing icu.base) as well.
Cheers,

--
"Have you tried turning it off and on again" - The IT Crowd
And if that fails, then http://goo.gl/tnBgH5

Marc-Andre Laperle

2018-10-04 03:04:28 UTC

I was planning to use com.ibm.icu.base as well for CDTâs stand-alone debugger. It will help shrink the size quite a bit.

Marc-AndrÃ©

FYI, jdt.ls <http://jdt.ls/> uses com.ibm.icu.base because the full package represented about 25% of the jdt.ls <http://jdt.ls/> distro.
So keeping it is kind of a big deal for us.
Hi,
In the bug you reference I don't see that the platform has lifted any of
its version range so one can happily run the complete codebase on the
old icu.base version.
In the end the right thing for the future is to get rid of ibm.icu from
the core platform (anything defining an e4 application) is the right way
forward.
I understand that for a IDE it does not make a big difference if your
download is 12MB larger but for a small RCP application it can be.
Anyways I'm packaging it into our target now so e(fx)clipse users are
not affected because they anyways point to our self-contained p2 repository.
Tom

Post by Roland Grunberg

Hey Tom,
If people would like to have corresponding com.ibm.icu.base for any
version of com.ibm.icu, that's fine. It would just be a matter of
ensuring the "base" version is available for the latest one in use as
I'd rather not accumulate many older versions. This is a similar
situation to things like Batik or Lucene, where platform handles the
set of bundles it cares about, but anyone wanting more has to do the
extra work.
The discussion for Platform to move to plain icu4j (from maven) was in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=536411 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=536411> (comments 11-17)
so it made sense to have everyone using the same thing, but maybe other
projects outside SimRel may still want a smaller version so I'm not
opposing this. For those projects, there is also the Photon Orbit repo
which has the older versions (containing icu.base) as well.
Cheers,

--
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
--
"Have you tried turning it off and on again" - The IT Crowd
And if that fails, then http://goo.gl/tnBgH5 <http://goo.gl/tnBgH5>_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Roland Grunberg

2018-10-04 16:26:14 UTC

Ok, so it's settled. This should be provided given that there's enough
demand for it.

Now we just need com.ibm.icu.base 62.1 binary and source jar, which in
the past was provided by IBM [1] or instructions on how to reproduce
the base bundle.

Without that, my best guess is just compare 58.2 base/full bundles to
see what should be included.

--
Roland Grunberg

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=510163#c3

Tom Schindl

2018-10-04 16:28:01 UTC

Frankly I think you can just push what was there in 58.2 - as I outlined
there's no need to provide 62.1 as this is not required by any of the
projects we are talking about here.

Tom

Post by Roland Grunberg
Ok, so it's settled. This should be provided given that there's enough
demand for it.
Now we just need com.ibm.icu.base 62.1 binary and source jar, which in
the past was provided by IBM [1] or instructions on how to reproduce
the base bundle.
Without that, my best guess is just compare 58.2 base/full bundles to
see what should be included.

--
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

Andreas Sewe

2018-08-02 06:53:19 UTC

Hi Roland,

Post by Roland Grunberg
I just wanted to give a heads-up that the following bundles (and
corresponding source bundles) are expected to be removed from the Orbit
build towards 2018-09, for M3 [1].
com.google.guava 15.0.0, 18.0.0 (use 21.0.0)

Ed Willink

2018-08-02 08:34:45 UTC

Hi

IMHO this means that Code Recommenders must withdraw from SimRel.

a) all SimRel contributions should use the latest Orbit version

b) mismatch of Guava has been a long-running nightmare with Guava
classes in APIs a known no-no causing projects that integrate diverse
Guava contributions to fail with bad classes.

Chasing evoluion is a pain but the whole point of SimRel is a suite of
contributions that work together. Now that we release four times more
often, this pain must be endured four times more often.

Â Â Â Regards

Â Â Â Â Â Â Ed Willink

Post by Andreas Sewe
Hi Roland,

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Andreas Sewe

2018-08-02 10:48:14 UTC

Hi Ed,

Post by Ed Willink
IMHO this means that Code Recommenders must withdraw from SimRel.
a) all SimRel contributions should use the latest Orbit version

yes, but the emphasis is on *should*.

Post by Ed Willink
b) mismatch of Guava has been a long-running nightmare with Guava
classes in APIs a known no-no causing projects that integrate diverse
Guava contributions to fail with bad classes.

As I said last year on this list, the problems show up only if you
expose Guava in your external API and do not have uses constraints in
place. Once you do the latter, you won't see LinkageErrors or similar
problems. It does mean, however, that if your clients use Guava, then
they must use the same version as you. That's the price you have to pay
for using Guava (directly or indirectly) in your external API.

At any rate, the mere presence of another bundle (unless it does some
arcane reflection/class-loading hackery, which AFAICT Guava does not)
should never break your bundle unless your metadata (version ranges and
uses constraints) is not in order. That's the whole point of OSGi:
Different bundles can use different versions of the same library in the
same runtime.

Best wishes,

Andreas
--
Codetrails GmbH
The best code possible

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940

Mat Booth

2018-08-02 15:53:53 UTC

Post by Andreas Sewe
Hi Roland,

Here I might be able to help. That recommenders uses old guava has caused
me a bit of headache in my downstream builds and I've been carrying some
patches against recommenders for a while -- let me clean up the patches
that we are carrying downstream and I will file a bug where we can discuss
it further -- how does that sound?

Mat Booth

2018-08-02 16:19:25 UTC

Post by Andreas Sewe
Hi Roland,

Sorry for replying to myself. I filed two bugs to talk about it:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=537624
https://bugs.eclipse.org/bugs/show_bug.cgi?id=537625

Aleksandar Kurtakov

2018-08-09 08:01:23 UTC

Post by Andreas Sewe
Hi Roland,

https://bugs.eclipse.org/bugs/show_bug.cgi?id=537624
https://bugs.eclipse.org/bugs/show_bug.cgi?id=537625

It would be nice if someone from recommenders checks up what's up with it's
gerrit verifications jobs.

Post by Mat Booth
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
Alexander Kurtakov
Red Hat Eclipse Team

Mat Booth

2018-08-20 15:51:39 UTC

Post by Andreas Sewe
Hi Roland,

https://bugs.eclipse.org/bugs/show_bug.cgi?id=537624
https://bugs.eclipse.org/bugs/show_bug.cgi?id=537625

Martin Lippert

2018-08-20 18:10:38 UTC

Hey Mat,

as far as I remember Buildship will update to Guava 21 (from 15) for the 2018-12 release. Sounds like we canât remove that old Guava Version from Orbit for the 2018-09 release.

Just wanted to point that out, in case that piece of the puzzle got lost somewhere... :-)

Cheers,
Martin

Post by Andreas Sewe
Hi Roland,

Here I might be able to help. That recommenders uses old guava has caused me a bit of headache in my downstream builds and I've been carrying some patches against recommenders for a while -- let me clean up the patches that we are carrying downstream and I will file a bug where we can discuss it further -- how does that sound?

https://bugs.eclipse.org/bugs/show_bug.cgi?id=537624
https://bugs.eclipse.org/bugs/show_bug.cgi?id=537625

Hi all,
I submitted patches for these bugs (for aligning guava versions with the rest of the train) but received no feedback yet from the recommenders project. I'm also still not sure what is wrong with their jenkins instance -- I lack sufficient privileges to investigate, but I tried to re-create the build on my own personal jenkins instance and I couldn't reproduce the problem. Please see the above bugs for details, and please comment if anyone has any recommendation on how best to proceed.
Thanks,
Mat
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Donát Csikós

2018-08-21 08:49:38 UTC

The Buildship update sites contain the required dependencies too, so from
our POV Guava 15 can be safely removed from Orbit.

Post by Martin Lippert
Hey Mat,
as far as I remember Buildship will update to Guava 21 (from 15) for the
2018-12 release. Sounds like we canât remove that old Guava Version from
Orbit for the 2018-09 release.
Just wanted to point that out, in case that piece of the puzzle got lost somewhere... :-)
Cheers,
Martin

Post by Andreas Sewe
Hi Roland,

Post by Roland Grunberg
I just wanted to give a heads-up that the following bundles (and
corresponding source bundles) are expected to be removed from the

Orbit

Post by Roland Grunberg
build towards 2018-09, for M3 [1].
com.google.guava 15.0.0, 18.0.0 (use 21.0.0)

Here I might be able to help. That recommenders uses old guava has
caused me a bit of headache in my downstream builds and I've been carrying
some patches against recommenders for a while -- let me clean up the
patches that we are carrying downstream and I will file a bug where we can
discuss it further -- how does that sound?

https://bugs.eclipse.org/bugs/show_bug.cgi?id=537624
https://bugs.eclipse.org/bugs/show_bug.cgi?id=537625

Hi all,
I submitted patches for these bugs (for aligning guava versions with the
rest of the train) but received no feedback yet from the recommenders
project. I'm also still not sure what is wrong with their jenkins instance
-- I lack sufficient privileges to investigate, but I tried to re-create
the build on my own personal jenkins instance and I couldn't reproduce the
problem. Please see the above bugs for details, and please comment if
anyone has any recommendation on how best to proceed.
Thanks,
Mat
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Martin Lippert

2018-08-21 08:59:12 UTC

Hey!

But as long as Buildship requires Guava 15, it will end up in the simrel repo.
And I thought that Orbit should be the only source of third-party dependencies… ;-)

Cheers,
-Martin

The Buildship update sites contain the required dependencies too, so from our POV Guava 15 can be safely removed from Orbit.
Hey Mat,
as far as I remember Buildship will update to Guava 21 (from 15) for the 2018-12 release. Sounds like we can’t remove that old Guava Version from Orbit for the 2018-09 release.
Just wanted to point that out, in case that piece of the puzzle got lost somewhere... :-)
Cheers,
Martin

Post by Andreas Sewe
Hi Roland,

Code Recommenders still uses Guava 15 and can't switch without doing a
major release, as Guava classes like ImmutableList and Optional are
unfortunately part of our public API. Switching to a new major version
of Guava would hence mean forcing all our clients to also switch, which
may not be possible.
A major release, possibly moving from Guava Optional to Java 8 Optional
in our public APIs, would eliminate this problem for good, but we don't
have the resources to do that for 2018-09.
Best wishes,
Andreas
Here I might be able to help. That recommenders uses old guava has caused me a bit of headache in my downstream builds and I've been carrying some patches against recommenders for a while -- let me clean up the patches that we are carrying downstream and I will file a bug where we can discuss it further -- how does that sound?
https://bugs.eclipse.org/bugs/show_bug.cgi?id=537624
https://bugs.eclipse.org/bugs/show_bug.cgi?id=537625
Hi all,
I submitted patches for these bugs (for aligning guava versions with the rest of the train) but received no feedback yet from the recommenders project. I'm also still not sure what is wrong with their jenkins instance -- I lack sufficient privileges to investigate, but I tried to re-create the build on my own personal jenkins instance and I couldn't reproduce the problem. Please see the above bugs for details, and please comment if anyone has any recommendation on how best to proceed.
Thanks,
Mat
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Donát Csikós

2018-08-21 09:39:34 UTC

That's correct, I just wanted to state the current state of affairs.
Regarding Orbit containing all dependencies: I remember in the past that
some plugins were "leaked" into the EPPs accidentally and it was quite hard
to track down the source. The conclusion is that the transitive
dependencies are not enforced to be loaded from Orbit. I don't know how
hard would this be to implement but it's maybe something to consider for
2018.12.

Post by Martin Lippert
Hey!
But as long as Buildship requires Guava 15, it will end up in the simrel repo.
And I thought that Orbit should be the only source of third-party
dependenciesâŠ ;-)
Cheers,
-Martin

Post by DonÃ¡t CsikÃ³s
The Buildship update sites contain the required dependencies too, so

from our POV Guava 15 can be safely removed from Orbit.

Post by DonÃ¡t CsikÃ³s
Hey Mat,
as far as I remember Buildship will update to Guava 21 (from 15) for the

2018-12 release. Sounds like we canât remove that old Guava Version from
Orbit for the 2018-09 release.

Post by DonÃ¡t CsikÃ³s
Just wanted to point that out, in case that piece of the puzzle got lost

somewhere... :-)

Post by DonÃ¡t CsikÃ³s
Cheers,
Martin

Post by Andreas Sewe
Hi Roland,

Post by Roland Grunberg
I just wanted to give a heads-up that the following bundles (and
corresponding source bundles) are expected to be removed from the

Orbit

Post by Roland Grunberg
build towards 2018-09, for M3 [1].
com.google.guava 15.0.0, 18.0.0 (use 21.0.0)

caused me a bit of headache in my downstream builds and I've been carrying
some patches against recommenders for a while -- let me clean up the
patches that we are carrying downstream and I will file a bug where we can
discuss it further -- how does that sound?

Post by Andreas Sewe
https://bugs.eclipse.org/bugs/show_bug.cgi?id=537624
https://bugs.eclipse.org/bugs/show_bug.cgi?id=537625
Hi all,
I submitted patches for these bugs (for aligning guava versions with

the rest of the train) but received no feedback yet from the recommenders
project. I'm also still not sure what is wrong with their jenkins instance
-- I lack sufficient privileges to investigate, but I tried to re-create
the build on my own personal jenkins instance and I couldn't reproduce the
problem. Please see the above bugs for details, and please comment if
anyone has any recommendation on how best to proceed.

Post by Andreas Sewe
Thanks,
Mat
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe

from this list, visit

Post by Andreas Sewe
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe

from this list, visit

Post by DonÃ¡t CsikÃ³s
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe

from this list, visit

Post by DonÃ¡t CsikÃ³s
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Martin Lippert

2018-08-02 07:29:18 UTC