Re: [eclipse.org-planning-council] Question about how to handle ICU...

[brian.fitzpatrick@xxxxxxxxxx]

Thanks David! 

We changed it to "5.0" from
"4.0" and that seemed to get around the issue for now. I'm definitely
of the opinion that "if it ain't broke..." at the moment, why
mess with it again? But there was a question about it and I'm following
up to do due diligence. 

I'll pass this info along to the DTP
PMC today.

--Fitz

Brian Fitzpatrick
Eclipse Data Tools Platform PMC Chair
Eclipse Data Tools Platform Connectivity Team Lead
Staff Software Engineer, Sybase, Inc.

David M Williams <david_williams@xxxxxxxxxx>
Sent by: eclipse.org-planning-council-bounces@xxxxxxxxxxx

02/03/2009 10:09 AM

Please respond to
"eclipse.org-planning-council"        <eclipse.org-planning-council@xxxxxxxxxxx>

To	"eclipse.org-planning-council" <eclipse.org-planning-council@xxxxxxxxxxx>
cc
Subject	Re: [eclipse.org-planning-council] Question about how to handle ICU...

Brian, here was my advice to WTP team (in short, use
import-package with lower bound only). 
And, to clarify, I'd say only half the team followed my advice ... the
rest found it easier to mass search and replace tweaking the 
upper bound, to 4.1 or 5.0 ... which works for now. If you've already changed,
I'm not sure it'd be worth
changing just for "future correctness" ... but, if you are going
to change, I'd recommend the same advice, below. 


= = = = = =
What to do about ICU? 

Thanks to you that have already made adjustments, but there's still 40
more. 

Here's what I recommend, 

Search for 
com.ibm.icu;bundle-version=
in all your manifest.mf files. 
remove it. 
Red Xs appear. 
Take a moment to see if you really need ICU where those red-Xs are. 
I've seen a few cases where it was not required. Once in a test plugin.
Not required. (If you do, you have some pretty sophisticated tests!). Once
I saw in some code that was using StringTokenizer from ICU to parse a doctype
element, to get the public and system IDs. The normal Java StringTokenizer
would do in this case, Doctypes can not have supplementary characters ...
the only thing that StringTokenizer handles over the Java one. 

To fix the red Xs, use the following in your manifest.mf files. 
Import-Package: com.ibm.icu.util;
version="3.8",
com.ibm.icu.text; version="3.8"

You may need only one of those packages. 
Maybe others ... those were the only two I saw 
in half a dozen cases. 

Bonus Question: why no upper bound?

answer
answer 
a. icu doesn't follow the rules we do so hard to know where an appropriate
bound would be, and 
b. For %99.9 of what we use from ICU we are just using the ICU version
of a Java API. It will be very very ... no, extremely very ... unlikely
that API would ever be broken, even in ICU version 54. 

This is all my advice anyway ... I'm sure there are valid alternatives.

= = = = =

brian.fitzpatrick---02/03/2009
10:12:05 AM---Hey all... So there were a bunch of e-mails flying around
with how to best handle the

From:	brian.fitzpatrick@xxxxxxxxxx
To:	"eclipse.org-planning-council" <eclipse.org-planning-council@xxxxxxxxxxx>
Date:	02/03/2009 10:12 AM
Subject:	[eclipse.org-planning-council] Question about how to handle ICU...
Sent by:	eclipse.org-planning-council-bounces@xxxxxxxxxxx

---

Hey all... 

So there were a bunch of e-mails flying around with how to best handle
the ICU dependency issue for Galileo, whether by using import package or
bundles in the plugin metadata. We adjusted the DTP plug-ins to change
the upper bound of the bundle version constraint to 5.0 (from 4.0), but
it came up yesterday that perhaps we should just remove all version constraints
or go with the import package method... 

I'm wondering what the general consensus is for this... Are we being asked
to import the ICU packages into each plug-in where ICU is being used? Or
are we simply removing the version bounds? What is the suggested course
of action? 

Thanks in advance. Sorry if I'm clueless on this, but I thought I'd bring
it up to the council at large so I can get the right information to take
back to my PMC and team leads. If it's easiest just to point me somewhere,
I'll be happy to skulk quietly back into the corner. :)

--Fitz 

Brian Fitzpatrick
Eclipse Data Tools Platform PMC Chair
Eclipse Data Tools Platform Connectivity Team Lead
Staff Software Engineer, Sybase, Inc.

Richard Gronback <richard.gronback@xxxxxxxxxxx>
Sent by: eclipse.org-planning-council-bounces@xxxxxxxxxxx

01/27/2009 09:14 AM

Please respond to
"eclipse.org-planning-council" <eclipse.org-planning-council@xxxxxxxxxxx>

To	"eclipse.org-planning-council" <eclipse.org-planning-council@xxxxxxxxxxx>
cc
Subject	Re: [eclipse.org-planning-council] Agenda item for Feb 4 Call

Thanks, I created a page and added this topic:
http://wiki.eclipse.org/Planning_Council/Feb_04_2009

- Rich


On 1/27/09 5:07 AM, "Oisin Hurley" <ohurley@xxxxxxxxxxxx>
wrote:

> Antoine, the project lead of the BPMN Modeler Project,
> would like the Planning Council to consider the following
> proposal for the Galileo release train projects.
> 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=261766

_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to
the Eclipse Foundation.  To be permanently removed from this list,
you must contact emo@xxxxxxxxxxx to request removal.

_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to
the Eclipse Foundation.  To be permanently removed from this list,
you must contact emo@xxxxxxxxxxx to request removal.
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to
the Eclipse Foundation.  To be permanently removed from this list,
you must contact emo@xxxxxxxxxxx to request removal.