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

[James D Miles <jdmiles@xxxxxxxxxx>]

It seems to me that older RCP clients not being able to access an eRCP update site would be less of a problem than eRCP clients accessing RCP sites. I think I should go ahead and implement this way. I will open an enhancement request for the PDE editor to add the site attribute.

I looked again at the 2 default siteTypes available org.eclipse.update.core.file and org.eclipse.update.core.http. It seems to me that we should have one extension org.eclipse.update.core.default or something. Then if the URL starts with http we would use SiteURLFactory and if the URL starts with file we would use the SiteFileFactory. The problem is once we start adding <site type= to the site.xml we are not portable. For instance if I have an update site on a http server the type would be wrong if I put it on the local file system. Did I miss something?

Also as best I can tell a site with <site type=org.eclipse.update.core.file is broken.

Dorian Birsan <birsan@xxxxxxxxxx>

Dorian Birsan <birsan@xxxxxxxxxx>
Sent by: platform-update-dev-bounces@xxxxxxxxxxx

11/09/2005 11:08 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 think the problem may be older RCP clients accessing an update site that uses the new siteTypes. 
Those clients would not be able to use anything from the new update site (that may be a good thing :-) 

-Dorian

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

11/09/2005 11:59 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

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
_______________________________________________
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