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

I just did the same posting it to the newsgroups, Pascal...    :(

 In my post I replied to Keith's comments/questions, so maybe we should continue it there...



Pascal Rapicault/Ottawa/IBM@IBMCA
Sent by: equinox-dev-admin@xxxxxxxxxxx

28/05/2003 09:13 AM

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


I'm moving this thread to the public knowledge.


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

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

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).