Re: Re[2]: [equinox-dev] Updates on registry resolution

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

yes!  This is something that seems to come up in many scenarios and from different people.

Related to this, I would propose that the actual policy used for version resolution in the framework be pluggable.  One motivation is the constrast between local and global version optimization.  Local optimization says "pick the highest version that satisfies my constraint".  Global says "pick the highest version that satisfies the most constraints".  Local gives you independence but at the cost of more classes loaded and more chance for ClassCastExceptions.  Global may introduce artificial interdependencies but reduces both the loaded class count and the chance of exceptions.

Note, this may not have to be in the framework spec (i.e., it may just be an implementation choice) but the spec should leave room for it to happen.

Jeff

Peter Kriens <Peter.Kriens@xxxxxxxx> Sent by: equinox-dev-admin@xxxxxxxxxxx 05/29/2003 06:10 AM Please respond to pkriens

To:        Pascal Rapicault/Ottawa/IBM@IBMCA         cc:        equinox-dev@xxxxxxxxxxx         Subject:        Re[2]: [equinox-dev] Updates on registry resolution

I like the 2 phase method. Just like to add that we probably need an
administrative facility that allows the user to override some of the
attributes of the packages. I.e. the author may have indicated a
compatibility with later versions, but in reality this is not true.
The user should have the possibility to override these settings,
especially the matching rules, imho.

Kind regards,

     Peter Kriens

PR> Keith, 

PR> I understand your motivation when you said that "no currently resolved 
PR> plugins go unresolved" but I think this behaviour may not be desired by 
PR> everybody. I think the algorithm must not try to be clever, because it 
PR> will never satisfy all the cases.

PR> In order to avoid the "resolved / unresolved" by surprise, we are thinking 
PR> of providing a way to do a "two phase install" : 
PR>         1) you will install, uninstall etc... plugins and you will be able 
PR> to query the system to know what are the results of these operations
PR>         2) once you are happy with the results you simply "commit" the 
PR> operations you've done so they really take effect.

PR> Note that the first phase does not affect the running system.

PR>         PaScaL






PR> Pascal Rapicault/Ottawa/IBM@IBMCA
PR> Sent by: equinox-dev-admin@xxxxxxxxxxx
PR> 05/28/2003 09:13 AM

 
PR>         To:     equinox-dev@xxxxxxxxxxx
PR>         cc: 
PR>         Subject:        [equinox-dev] Updates on registry resolution




PR> Hi, 

PR> I'm moving this thread to the public knowledge. 

PR>         PaScaL 

PR> ----- Forwarded by Pascal Rapicault/Ottawa/IBM on 05/28/2003 09:12 AM 
PR> ----- 

PR> Keith Kimball@IRIS 
PR> 05/27/2003 04:46 PM 

PR>         To:        Rafael Chaves/Ottawa/IBM@IBMCA@IBMUS 
PR>         cc:        Jeff McAffer/Ottawa/IBM@IBMCA, Pascal 
PR> Rapicault/Ottawa/IBM@IBMCA 
PR>         Subject:        Re: more updates on registry resolutionLink 


PR> I'm impressed that you're making such good progress!!! 

PR> I didn't understand your comment regarding changing back to original 
PR> intent - do library plug-ins currently not get resolved if they have their 
PR> prerequisites satisfied? Does this only happen when the library is not 
PR> required by other plugins? 

PR> I'm really looking forward to seeing your code. 

PR> What have you do with the extension/extension point resolver? 

PR> What are your thoughts regarding permitting/disallowing the 
PR> enablement/disablement of plugins? We should discuss this with Jeff et al 
PR> but my thoughts are that we should we refactor the resolver so that we can 
PR> run it w/o effecting a running register (this is not too hard with the 
PR> current resolver). 

PR> Consider enable(plugin-list). My thoughts are that this should only be 
PR> allowed if 
PR> No currently resolved plugins go unresolved. 
PR> Corresponding extension points of extensions implemented by this plugin 
PR> must be able to handle dynamic plugins. For example, if the plugin 
PR> provides a menu, the menu needs to get displayed. 
PR> I'm not sure if there's an issue the other way - if a previously 
PR> unresolved plugin provides an extension point, is it ok if there were 
PR> dangling extensions? 
PR> My thoughts are you run the resolver, see if a desirable end state if 
PR> reached, and then carefully add the new plugins to the registry while 
PR> keeping it consistent. This would take some refactoring but I believe it 
PR> could be done.

PR> I believe disable has similar issues. 

PR> I'm not sure this is inline with what Jeff and Pascal are thinking? Do you 
PR> think we should talk later this week. 

PR> Thanks for the update and great work!! 
PR> Keith 



PR> Rafael Chaves/Ottawa/IBM@IBMCA 
PR> 05/26/2003 01:54 PM 


PR> To 
PR> Keith Kimball/Westford/IBM@Iris@IBMUS 
PR> cc 
PR> Jeff McAffer/Ottawa/IBM@IBMCA, Pascal Rapicault/Ottawa/IBM@IBMCA 
PR> Subject 
PR> more updates on registry resolution







PR> Hi Keith, 

PR> Again, just to keep you updated with what is going on here... 

PR> Here, we have made good progress. I have made the registry resolver to 
PR> call the new dependency resolution algorithm instead of doing it itself, 
PR> and so far I've been able to run the Eclipse registry resolution test 
PR> cases with a low failure rate (8 in 189), due to known limitations in the 
PR> new algorithm regarding conflict resolution and cycle detection. The good 
PR> news is that some tests known to fail with the current implementation pass 
PR> in the new one. The performance for running Eclipse is now equivalent to 
PR> slightly better than the current implementation, and it has shown to scale 
PR> well for huge registries. Also, for the incremental cases (addition, 
PR> removal),  the resolution time is proportional to the number of affected 
PR> plug-ins, being really fast for small changes. 


PR> I believe I am almost ready to help you in the whole registry resolution 
PR> thing. I still need to implement handling cycles/conflicts in the way the 
PR> current implementation does, and improving the delta generation. After 
PR> that, it is just a matter of cleaning up the code and tidying up the 
PR> object interfaces so it will be ready for going public. 

PR> And what about you, are things going well? Please let me know if is there 
PR> anything you need that I can help. 

PR> P.S.: Jeff and Pascal may be asking how the number of test failures 
PR> dropped from 57 to just 8... for now, I decided to change the version 
PR> selection algorithm to be compatible with the current implementation (for 
PR> library plug-ins, pick only the versions which are required by other 
PR> plug-ins, or pick the highest version if none is required). So, now the 8 
PR> failure cases are really problems that the previous implementation handled 
PR> ok. Later, we may change it back to our original intent (resolve all 
PR> library plug-ins that can have their pre-requisites satisfied). 

PR> Regards, 

PR>         Rafael 




-- 
Peter Kriens                              Tel. +46 30039800
Finnasandsvägen 22                        Fax. +46 30039805
SE-43933 Onsala                           Mob. +46705950899

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/equinox-dev