The last 2 weeks I've been working with the contribution processing code
and am bumping into the following issues:
- ContributionImpl is tied to a ClassLoader
- ModelResolver as well, and it seems to be used to resolve classes in
some cases.
- We're now using a special ContributionClassLoader implementation.
- The ContributionService depends on it and assumes that it should be
used on all contributions.
- ContributionClassLoader contains code to navigate the imports/exports,
assumes that all contributions are using such a ContributionClassLoader,
calls implementation methods on it to match imports and exports and
resolve classes, going around the regular model resolver based scheme
used for everything else.
- contribution-impl depends on contribution-java, this is going
backwards IMO and breaks modularity and pluggability, as a core module
should not have dependencies on extensions.
- I don't fully understand what JavaImportExportListener does but it
looks like an attempt to implement a fancy domain update scheme,
bringing another way to match Java imports/exports. Unfortunately it's
only half implemented.
All this complexity related to classloading makes my head spin, prevents
me from using the contribution service outside of a running runtime
(where I don't have a classloader at all) and should not be in the core
contribution code in the first place, as processing of Java classes
should be handled in a Java specific extension and not in the core.
For now I have to make a copy of the contribution code without this
stuff to make progress. Could the people who worked on this classloading
code please help clean it up and move it out of the core contribution
modules?
Thanks.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
