Maybe I'm really wondering how much the IU taxonomy will change from 
product to product.

We've already discussed that the presentation to the user of what a 
repository is may differ from product to product.  Or at least that most 
end users (of the Eclipse SDK, RCP products) are unaware of metadata and 
artifact repositories as separate entities.  I would expect that many 
products would want to keep the concept of a "site" (maybe plug in their 
own terminology or icons), so we must have API to find the artifact repo 
from a metadata repo or colocate them.   (See discussion in 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=200259). 

Same is true for profiles.  A user of most RCP products, and even many 
Eclipse SDK users, would likely not want to know that the provisioning 
infrastructure supports multiple profiles.  Their view is likely of the 
"product install location" or something like that, and the fact that there 
exists a profile that drove this configuration, the fact that bundles 
might be shared, etc...would be hidden. 

So now I'm wondering if the same is true for IU's, at least those that the 
user knows about.  We have the notion of IU's that are groups (which is 
how we filter the IU views in M1).  And Pascal is thinking about an "entry 
point" concept that would define what the "product view" of a bunch of 
installable units would be. 

Should we assume a particular taxonomy for most/all RCP apps and build a 
UI that can be reused in this way? 
Pascal, do you think the entry point concept is the way that we would 
expect many/most products to show the user what they have?

I used to think that I could build a fairly reusable update UI that could 
be plugged into different products.   Products could define their 
terminology for things like IU's (feature, add-on, plug-in), and 
repositories (sites, repositories, etc.).  Then I realized that we need to 
do some mapping from the user view (site) to the reality (metadata + 
artifact repo), and that we might have a default strategy (such as 
colocation of repos), but ultimately we can't assume how repos are 
presented to the user. 

Do we think that, for IU's, we can also come up with a default strategy 
(such as entry points) for deciding how to present IU's?  ie, how to 
filter the list of IU's the user sees, and more interesting, what would 
show up on the property page for those kinds of IU's. 

I hope this makes sense....

susan
_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Reply via email to