Another possible approach is to have a single root IU, whose prerequisites have filters based on different classes of users. Since the filters on required capabilities are evaluated at install time based on properties in the profile, the result would be that the same root installed into different kinds of profiles would yield different install trees. This allows per-user customization without having to build too much smarts into the repository itself. Of course, this does require that the profile be seeded initially with the correct properties.
Pascal Rapicault/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 08/17/2007 08:42 AM Please respond to Equinox development mailing list <[email protected]> To Equinox development mailing list <[email protected]> cc Equinox development mailing list <[email protected]>, [EMAIL PROTECTED] Subject [ProbableSpam]Re: [equinox-dev] [prov] Thoughts on the engine I'm sorry but I don't understand what you are trying to achieve, nor what the problem is. The SDK IU is an artificial root that we create at metadata generation time to provide one entity to install and get the sdk. The presence of this IU does not prevent you to define "James SDK" IU. You should be able to compose and/or install directly from the other IUs since they are completely independent. For example if you were to install the "org.eclipse.core.runtime" IU you would get it and all its prereq, thing that we were not able to do before. PaScaL James D Miles <[EMAIL PROTECTED] om> To Sent by: Equinox development mailing list equinox-dev-bounc <[email protected]> [EMAIL PROTECTED] cc Subject 08/16/2007 05:16 Re: [equinox-dev] [prov] Thoughts PM on the engine Please respond to Equinox development mailing list <[EMAIL PROTECTED] pse.org> Do you mean that some operations must be done with the actual user being identified? Yes, if you are sharing an install (multiuser), each user must be configured separately. And to your point in <tangent 2> each user may be managed differently. <cotangent 2> My thoughts were along these lines. Currently we have an IU with id "sdk" in the sample. This sample provides no capabilities but only list requirements to be installed. While it should remain an IU it should be categorized by subclassing or creating an interface for all of these: IU fragment, IU, etc. That would allow another abstraction that manages a description ("sdk") of what can be installed. These could me managed on a per user basis if that is what is wanted. </cotangent> (Embedded image moved to file: pic08335.gif)Inactive hide details for "Tim Webb" <[EMAIL PROTECTED]>"Tim Webb" <[EMAIL PROTECTED]> "Tim Webb" <[EMAIL PROTECTED] om> Sent by: (Embedded image moved to file: equinox-dev-b pic03420.gif) [EMAIL PROTECTED] To e.org (Embedded image moved to file: pic31381.gif) "Equinox development 08/16/2007 mailing list" 03:40 PM <[EMAIL PROTECTED] g> (Embedded image moved to file: Please respond to pic15965.gif) Equinox development mailing list cc <[email protected]> (Embedded image moved to file: pic13816.gif) (Embedded image moved to file: pic31066.gif) Subject (Embedded image moved to file: pic15739.gif) Re: [equinox-dev] [prov] Thoughts on the engine (Embedded image moved to file: pic26985.gif) (Embedded image moved to file: pic08985.gif) <tangent> That said I must admit that I'm not super happy with this solution since to make such a "fetch only" operation usable, either the director would have to expose a "fetch" operation (but it would also have to expose a "install" operation to solve the other pb mentioned by James), or one would have to either author its own director (or at least extend the current one) which is something we want to avoid. In the light of recent discussions with Tim and others, I wonder if the director should not become just a planner that returns a bunch on operations that needs to be performed. The results of this planner would then be passed on to the engine and a "target" phase could be specified. For example: EngineOperation[] op = director.install(ius, profile1) engine(op, "fetch"); //This means do the operations but stop at fetch. </tangent> This actually makes a lot of sense to me. It addresses multiple concerns including being able to present to the user an accurate statement of how much work needs to be performed, as well as allowing for much easier re-use in server-side scenarios. Do you mean that some operations must be done with the actual user being identified? <tangent id="2"> While probably not where you were going with this one, mentioning per-user operations reminded me of another flow we were planning to support in Maya where some software would only be available to certain users. If we were using user-aware repositories as part of the resolution process, would we do the filtering inside the repository? If so, how would we handle this in a multi-user scenario especially when a director/planner is being used server-side? Ideally I'd like the flexibility of filtering which software is available to which user, but currently the implementation / APIs do not allow passing of any handle or request-identifier to the repositories to aide in determining which software is available. Thoughts? </tangent>_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev (See attached file: pic00393.gif) _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<attachment: pic08335.gif>>
<<attachment: pic03420.gif>>
<<attachment: pic31381.gif>>
<<attachment: pic15965.gif>>
<<attachment: pic13816.gif>>
<<attachment: pic31066.gif>>
<<attachment: pic15739.gif>>
<<attachment: pic26985.gif>>
<<attachment: pic08985.gif>>
<<attachment: pic00393.gif>>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
