|
| Re: Headless-feature installs com.ibm.icu.base causing strange errors [message #551312 is a reply to message #551228] |
Thu, 05 August 2010 21:35   |
|
Hi Thorsten,
The reason we ship the com.ibm.icu.base is that the com.ibm.icu is huge and Buckminster does not really need it. Not
sure why that should be a problem. Why are you installing the org.eclipse.jdt.ui into a headless Buckminster? Do you use
the Buckminster runtime as your target platform?
- thomas
On 08/05/2010 06:46 PM, Thorsten Meinl wrote:
> Hi all,
>
> I spent quite some tome to figure out a strange problem whilst building
> a workspace in headless buckminster. To make it short, the error
> messages were that the bundles org.eclipse.jdt.ui or
> org.eclipse.wst.sse.core could not be started because some classes from
> com.ibm.icu.util could not be found (e.g.
> com.ibm.icu.util.StringTokenizer). The reason is that the bundles do not
> require the com.ibm.icu-bundle but rather import the needed packages.
> However, Buckminster's headless feature comes with com.ibm.icu.base
> which contains some ICU classes but not all, e.g. the StringTokenizer.
> Even though the full com.ibm.icu is lateron installed via the
> org.eclipse.jdt-feature it does not get used lateron for resolving the
> StringTokenizer class (due to the OSGi specification, see e.g.
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=145988).
> So my question is, if I did something wrong to stumble upon that problem
> or if others have run into the same. And if so, maybe the headless
> feature should ship the full com.ibm.icu instead of the lightweight
> base-version?
>
> Cheers,
>
> Thorsten
|
|
|
|
| Re: Headless-feature installs com.ibm.icu.base causing strange errors [message #551420 is a reply to message #551409] |
Fri, 06 August 2010 11:14 |
|
On 08/06/2010 12:05 PM, Thorsten Meinl wrote:
> Am 05.08.2010 23:35, schrieb Thomas Hallgren:
>> The reason we ship the com.ibm.icu.base is that the com.ibm.icu is huge
>> and Buckminster does not really need it. Not sure why that should be a
>> problem. Why are you installing the org.eclipse.jdt.ui into a headless
>> Buckminster? Do you use the Buckminster runtime as your target platform?
> Ah, so I don't need to install org.eclipse.jdt into the headless
> Buckminster. Good point. However, there are some other bundles (which I
> installed) that rely on the full com.ibm.icu. That brings me to a more
> general question: what is the preferred way of physically managing
> target platform definitions? I have a defintion that includes the
> installation and some software site. In order to prevent fetching
> required features from the remote sites over and over again, I installed
> most of them into the headless Buckminster. But that seems to cause some
> problems?
>
Yes, using the actual runtime as the target platform (TP) is often problematic and not recommended.
My preferred way is to always create a TP from scratch as part of the normal resolve/materialize process. The steps are
as follows:
1. See to that your RMAP appoints the needed repositories using providers with "p2" readers and that the proper locators
are in place for this. The providers must have the attribute source=false.
2. Before you issue the import of your cquery/mspec, do a setpref targetPlatformPath=<some folder of choice>
3. Run the import.
The default behavior will now ensure that all components that are resolved from binary repositories (source=false in the
provider) end up in your TP and that all other components end up in your workspace.
An alternative is to define a TP using PDE and export it to your workspace. You will then get a .target file. This file
can be imported by Buckminster using the importtargetdefinition -A <the .target file> (the -A is to set the TP active).
In general, Buckminster will always import binary content into your active TP unless otherwise specified. The default TP
however, will include the Buckminster runtime. Hence the setpref or importtargetdefinition call.
HTH,
- thomas
|
|
|
Powered by
FUDForum. Page generated in 0.02784 seconds
] 
Search
Help
Register
Login
Home
