Re: [platform-update-dev] Filters for eUpdate

[James D Miles <jdmiles@xxxxxxxxxx>]

We have existing features which may not have any filters specified. They were expected to run on anything. We add eRCP and that is not necessarily true.

Do we expect to be able to intermix eRCP features and RCP features on the same update site?
The current siteType extension points are org.eclipse.update.core.http and org.eclipse.update.core.file. If we create new siteTypes for eRCP it would seem to satisfy the problem of isolating the existing features from eRCP. If RCP platform could also process the new siteTypes then RCP would have a shot at using eRCP features.


Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>

Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
Sent by: platform-update-dev-bounces@xxxxxxxxxxx

11/08/2005 10:56 PM

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

Note that the <feature> filters for os, ws and arch are not recommended.  The problem is that they do not list triplets but just lists.  For example linux, win32, carbon is not a valid configuration but could be construed as one from the current syntax.  In most cases people have features that supply some function generically and then as an implementation detail have some platform-specific plugins.  In that case you are better off using the <plugin> markup for os, ws and arch (see the RCP feature for an exampel). 

Jeff

James D Miles <jdmiles@xxxxxxxxxx>
Sent by: platform-update-dev-bounces@xxxxxxxxxxx

11/08/2005 06:25 PM

Please respond to
"Eclipse Platform Update component developers list."

To	platform-update-dev@xxxxxxxxxxx
cc
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