[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-update-dev] Filters for eUpdate
|
Yeah, well, Java is but platforms are
not all the same. There are a number of places where we have plugins
that use function specific to a platform, others that have natives, others
that require particulra JRE levels, ... So the build and deploy story
is more complicated than you would think.
As for James Miles' points, yes features
have these settings but they are not sufficient. for example, they
imply that all combinations of the values constitute valid platforms. Clearly
this is not true. This mechanism is a hold over from days before
we had conditional plugin lists (see the os, ws, arch attributes on the
plugin and import elements). That is by far the preferred mechanism
now. Between that and the actual plugin dependencies, you should
be able to determine a feature's applicability. We have considered
expanding the set of matching attributes to be arbitrary. Perhaps
this would address the issues?
Jeff
"James D Carroll"
<jamesdcarroll@xxxxxxxxxxx>
Sent by: platform-update-dev-bounces@xxxxxxxxxxx
11/19/2005 01:46 AM
|
Please respond to
"Eclipse Platform Update component developers list." |
|
|
To
| "Eclipse Platform Update
component developers list." <platform-update-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| Re: [platform-update-dev]
Filters for eUpdate |
|
I'm sorry but I thought Java was
"cross platform". You know: "Write once, run anywhere".
That whole thing.
----- Original Message -----
From: James
D Miles
To: platform-update-dev@xxxxxxxxxxx
Sent: Tuesday, November 08, 2005 6:25 PM
Subject: [platform-update-dev] Filters for eUpdate
It is not clear to me that we have adequate filters for
features.
We have
os = {win32, linux, aix, solaris, hpux, qnx, macosx, unknown}
arch = {x86, PA_RISC, ppc, sparc, x86-64, ARCH_X86_64, ia64, ia64-32}
ws = {win32, motif, gtk, photon, carbon, unknown}
What would be the preferred way to prevent eUpdate from attempting to load
a feature that expects a full blown platform. Chances are good that the
required features or plugins would not be satisfied but that will give
an error. Shouldn't we have a filter to handle this?
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-update-dev_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-update-dev
