Hello Tom! >From my optimistic point of view... Module implementers are expected to ask the subsystem responsible persons for an API that fits their needs. >From the constructive discussion that follows a robust, well-designed and appropriate API is developed.
As you have noticed, very little has happened... As an example, have a look at how ArgoPrint connects to the GenericArgoMenuBar. I assume that once we start reworking the ProjectBrowser that is no longer the access point of the GenericArgoMenuBar. And perhaps the fact that a Plugin allocates a JMenuItem of its own will also have to change but that is just moving the API. http://argoprint.tigris.org/source/browse/argoprint/trunk/src/org/argoum l/ui/argoprint/ArgoPrintMenuPlugin.java?annotate=247 lines 96-112 We could use some existing working specification. Please suggest a specific one and point out the benefits! /Linus > -----Original Message----- > From: Tom Morris [mailto:[EMAIL PROTECTED] > Sent: den 28 september 2006 20:15 > To: [email protected] > Subject: RE: [argouml-dev] What replaces PluggableImport and Generator2? > (and other language module questions) > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
