I am all for Platonos, just don't have any spare bandwidth now ...
sigh :-/
Andrus
On Sep 29, 2006, at 5:49 PM, Evert Tigchelaar jr wrote:
> 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:55:19 EDT