Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[equinox-dev] Updates on registry resolution


Hi,

I'm moving this thread to the public knowledge.

        PaScaL

----- Forwarded by Pascal Rapicault/Ottawa/IBM on 05/28/2003 09:12 AM -----
Keith Kimball@IRIS

05/27/2003 04:46 PM


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


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

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

I'm really looking forward to seeing your code.

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

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

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

    I believe disable has similar issues.

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

    Thanks for the update and great work!!
    Keith



    Rafael Chaves/Ottawa/IBM@IBMCA

    05/26/2003 01:54 PM

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




    Hi Keith,

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

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


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

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

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

    Regards,

            Rafael


Back to the top