One of the plugin engine that where discussed was the Platonos Plugin
Engine, I am one of the two developers thats working on it.
We currently have a stable version 1.5 and on 2.0 I am working on but
this one should be allready quit stable, its not a drop in replacements
for the 1.5 but it shouldn't be to hard to move, after you fix the
imports for the plugin engine it should work the same as with 1.5 of the
plugin engine.
I didn't seen the code of the moduler tool but it should be to hard to
turn it into a plugin, create a lifecycle class and a configuration file
and off you go. Then its one big plugin and from there you could the
moduler tool and divide it into multipul plugins.
But like you write the developers of the cayenne project are quit busy
with lots of things so it may be better to focus on those things and
move the addition of a plugin engine up to a later time.
And as far as I know there wasn't made a decision about which plugin
engine to choice so that must be finished off before you can add a
plugin engine.
Evert
Mike Kienenberger wrote:
> I remember those discussions, but I don't see real plugin engine
> availability as something that's going to happen in the near term.
> There's far too many other "important" things going on like JPA, outer
> joins, audit logging, and other fun things.
>
> So I'm looking for a short-term maintainable solution. If we're
> going to have real plugin support down the road, I think what I've
> proposed is probably good enough for the time being, and has minimal
> impact.
>
> On 9/29/06, Andrus Adamchik <andru..bjectstyle.org> wrote:
>> Mike,
>>
>> we have this entire big thing in the queue for 3.0 - switching
>> CayenneModeler to a plugin engine. If you search the mailing list,
>> you'll find long heated discussions about it throughout the summer.
>>
>> So I suggest to avoid checking in any ad hoc plugin functionality
>> until the engine is in place. Or even better - let's get the plugin
>> engine going for real.
>>
>> Andrus
>>
>>
>> On Sep 29, 2006, at 3:34 PM, Mike Kienenberger wrote:
>>
>> > I needed to add a new feature to Cayenne Modeler yesterday. The
>> > primary impact was the addition of a new menu item which called my own
>> > code.
>> >
>> > Today, I went through and tried to figure out a reasonable way of
>> > making such an extension built-in to Cayenne, so I don't have to
>> > maintain it with patches.
>> >
>> > I'm not completely happy with what I have come up with, primarily
>> > because it only supports one extension set, but this is what I've done
>> > so far. I read a cayenneActionPluginFactory class from a system
>> > property (yes, the property needs to be fully-qualified) as a method
>> > on Application. Application seemed easily accessible and no worse
>> > than anything else, but maybe a separate
>> > CayenneActionPluginFactoryManager would make more sense.
>> >
>> > If a plugin is found, I create a new Extensions top-level menu and
>> > stick the actions into it in CayenneModelerFrame. In ActionManager's
>> > constructor, I register the actions, and add any to the DOMAIN_ACTIONS
>> > list that are domain actions (also should provide ways to do the same
>> > for project, datamap, objEntity, dbEntity, Special, etc.)
>> >
>> > That's the majority of the changes to support this. What I'd ideally
>> > like to have happen is to figure out a way to support any number of
>> > CayenneActionPluginFactory objects, and have the registration
>> > automatic (maybe check each jar for a CayenneActionPluginFactory
>> > config file?), but I don't know if the second option is realistic. I
>> > suppose the first option could be handled by making the system
>> > property a list of comma-separated classes rather than a single class.
>> >
>> >
>> >
>> > public interface CayenneActionPlugin {
>> > public String getActionName();
>> > public CayenneAction createCayenneAction(Application application);
>> > public boolean isDomainAction();
>> > }
>> >
>> > public interface CayenneActionPluginFactory {
>> > public List getCayenneActionPluginList();
>> > }
>> >
>> > static CayenneActionPluginFactory cayenneActionPluginFactory =
>> > null;
>> > public CayenneActionPluginFactory getCayenneActionPluginFactory()
>> > {
>> > // TODO: retrieve somehow and allow multiple factories.
>> > if (null == cayenneActionPluginFactory)
>> > {
>> > String pluginName =
>> > System.getProperty("cayenneActionPluginFactory");
>> > if (null != pluginName)
>> > {
>> > try {
>> > cayenneActionPluginFactory =
>> > (CayenneActionPluginFactory)Class.forName(pluginName).newInstance();
>> > }
>> > catch (InstantiationException e) {
>> > logObj.error("InstantiationException error
>> > instantiating cayenneActionPluginFactory", e);
>> > }
>> > catch (IllegalAccessException e) {
>> > logObj.error("IllegalAccessException error
>> > instantiating cayenneActionPluginFactory", e);
>> > }
>> > catch (ClassNotFoundException e) {
>> > logObj.error("ClassNotFoundException error
>> > instantiating cayenneActionPluginFactory", e);
>> > }
>> > }
>> > }
>> > return cayenneActionPluginFactory;
>> > }
>> >
>>
>>
>
This archive was generated by hypermail 2.0.0 : Fri Sep 29 2006 - 17:49:50 EDT