Linus said: > It says already in the deprecation statement of > PluggableImport that the Import class has no registration > method so it should come as no surprise.
Oops, missed that part! > The details on the Import interface and registration are not > decided. If it were, the registration method would most > likely be there. Who owns this decision about what these details are? I'm not sure I understand how the old interface can be deprecated if there's nothing to replace it. From the documentation it appears that this "new" architecture is 2 years old. What action are module implementers expected to take? As I understand it, the general thrust is to: a) distribute the plugin mechanism among the various subsystems rather than having it be centralized and b) invert the registration responsibility so that modules explicitly register themselves rather than being implicitly registered based on the interfaces that they implement. Is there an example which demonstrates how this general theory works in practice? Perhaps not for Import, but maybe for one of the other pluggable module types? As a general principle, I think we should make the plugin API only as wide as is necessary. The more surface area it has, the less flexibility we have in changing things in the future. Speaking of the future, if this is completely undefined territory, is there any reason not to just adopt a complete working specification and/or implementation from somewhere else? Perhaps the Eclipse, OSGi, NetBeans, or some other API? That would save us from having to design and implement another proprietary framework API. I'd really like to see us get out of the business of doing non-core infrastructure work. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
