You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2006/07/23 02:26:47 UTC
CayenneModeler plugin environment
I am back to the plugin engine topic again. Now it is out of the
hypothetical realm, as 3.0 development has already started.
First I wanted to address earlier suggestion by Ahmed [1] to use JPF
[2]. Cayenne *as a package* is released under Apache license. ASF has
an explicit policy that prohibits bundling (L)GPL software. We can't
even use Launch4j for the Windows distro as it has a binary component
that is distributed with Cayenne. The only "workaround" for the LGPL
"incompatibility" is to release the Modeler entirely outside of
Apache, which is certainly NOT what we want.
*****
Another candidate is Platonos [3]. Which is an excellent one, but as
Ahmed and myself pointed out, the project is dormant, as its
developers can't for personal reasons dedicate much time to it.
I contacted Platonos developers to get a better feeling of the
situation (I am cc'ing to Kevin and Evert who are the main force
behind the project). To be entirely accurate the project is not
dormant - Evert is developing a new version [4], which I still need
to explore, and looking into JSR 198 (A Standard Extension API for
IDE, which itself seems dormant :-)). And Kevin is consistently
providing support on the user mailing list. Essentially the situation
is slightly better than I had with JStaple some time ago (really
passionate about the project, but not realistic to do 100 things at
once).
Kevin suggested donating Platonos code to Apache. In the ideal world
this would be a great idea. This is a very nice component that would
fit either in Jakarta commons or Cayenne (believe it or not, such
commonly useful thing as a plugin engine is nowhere to be found).
Still with no support from the original developers for the time-
consuming incubation process, I don't see this as an option at this
time. Essentially this would place the Platonos incubation burden on
Cayenne committers. Don't know about others, but for me this is out
of the question at the moment. While I'd be glad to mentor such
project at the Incubator, anything beyond that is unrealistic until
Cayenne's own incubation is finished. Maybe we can scout for
volunteers on the Incubator list??
Anyways, IMO the best option would be to start with current Platonos
code, working out any issues with Kevin and Evert. Kevin also
suggested giving commit access to interested Cayenne committers.
While I am not psyched about taking over the project without any
sense of direction on my end (this is a bit un-Apache as well), it
will be sort of a guarantee for the ongoing support of CayenneModeler
requirements. The first one of those being Maven builds from repo
that we could use in Cayenne.
Thoughts? Comments?
(Kevin, Evert, please feel free to chime in as well)
Andrus
[1] http://objectstyle.org/cayenne/lists/cayenne-devel/2006/07/0032.html
[2] http://jpf.sourceforge.net/
[3] http://platonos.sourceforge.net
[4] http://platonos.cvs.sourceforge.net/platonos/ppe2/
Re: CayenneModeler plugin environment
Posted by Bill Dudney <bd...@apache.org>.
Hi Ahmed,
No OSGi is about dynamically assembling applications from a group of
plugins.
http://www.osgi.org/
talks a lot about mobile applications because the consortium is
focused on the mobile market but the framework has had wide
acceptance outside the mobile market. There are even some talking
about adopting OSGi as a backend assembly mechanism for servers.
OSGi is the backend of eclipse, it is how all the plugins that are
loaded find each other and work together.
HTH,
Bill Dudney
MyFaces - http://myfaces.apache.org
Cayenne - http://incubator.apache.org/projects/cayenne.html
On Jul 25, 2006, at 2:00 AM, Ahmed Mohombe wrote:
>> Sorry for being late to the party I was busy with mavenization :-)
>> Felix is an OSGi impl currently incubating.
>> http://incubator.apache.org/felix/index.html
>> OSGi has been very successful as the Eclipse runtime plugin
>> management framework.
>> Thoughts?
> Sorry, but AFAIK Felix is about Service Injection et co., so it's
> more something like
> HiveMind, Spring, etc. IMHO this is NOT what Cayenne Modeler is
> missing (not even
> the Cayenne Framework itself, as it works fantastic even without
> injection).
>
> Ahmed.
>
Re: CayenneModeler plugin environment
Posted by Ahmed Mohombe <am...@yahoo.com>.
> Sorry for being late to the party I was busy with mavenization :-)
>
> Felix is an OSGi impl currently incubating.
>
> http://incubator.apache.org/felix/index.html
>
> OSGi has been very successful as the Eclipse runtime plugin management
> framework.
>
> Thoughts?
Sorry, but AFAIK Felix is about Service Injection et co., so it's more something like
HiveMind, Spring, etc. IMHO this is NOT what Cayenne Modeler is missing (not even
the Cayenne Framework itself, as it works fantastic even without injection).
Ahmed.
Re: CayenneModeler plugin environment
Posted by Bill Dudney <bd...@apache.org>.
Sorry for being late to the party I was busy with mavenization :-)
Felix is an OSGi impl currently incubating.
http://incubator.apache.org/felix/index.html
OSGi has been very successful as the Eclipse runtime plugin
management framework.
Thoughts?
-bd-
On Jul 22, 2006, at 6:26 PM, Andrus Adamchik wrote:
> I am back to the plugin engine topic again. Now it is out of the
> hypothetical realm, as 3.0 development has already started.
>
> First I wanted to address earlier suggestion by Ahmed [1] to use
> JPF [2]. Cayenne *as a package* is released under Apache license.
> ASF has an explicit policy that prohibits bundling (L)GPL software.
> We can't even use Launch4j for the Windows distro as it has a
> binary component that is distributed with Cayenne. The only
> "workaround" for the LGPL "incompatibility" is to release the
> Modeler entirely outside of Apache, which is certainly NOT what we
> want.
>
> *****
>
> Another candidate is Platonos [3]. Which is an excellent one, but
> as Ahmed and myself pointed out, the project is dormant, as its
> developers can't for personal reasons dedicate much time to it.
>
> I contacted Platonos developers to get a better feeling of the
> situation (I am cc'ing to Kevin and Evert who are the main force
> behind the project). To be entirely accurate the project is not
> dormant - Evert is developing a new version [4], which I still need
> to explore, and looking into JSR 198 (A Standard Extension API for
> IDE, which itself seems dormant :-)). And Kevin is consistently
> providing support on the user mailing list. Essentially the
> situation is slightly better than I had with JStaple some time ago
> (really passionate about the project, but not realistic to do 100
> things at once).
>
> Kevin suggested donating Platonos code to Apache. In the ideal
> world this would be a great idea. This is a very nice component
> that would fit either in Jakarta commons or Cayenne (believe it or
> not, such commonly useful thing as a plugin engine is nowhere to be
> found). Still with no support from the original developers for the
> time-consuming incubation process, I don't see this as an option at
> this time. Essentially this would place the Platonos incubation
> burden on Cayenne committers. Don't know about others, but for me
> this is out of the question at the moment. While I'd be glad to
> mentor such project at the Incubator, anything beyond that is
> unrealistic until Cayenne's own incubation is finished. Maybe we
> can scout for volunteers on the Incubator list??
>
> Anyways, IMO the best option would be to start with current
> Platonos code, working out any issues with Kevin and Evert. Kevin
> also suggested giving commit access to interested Cayenne
> committers. While I am not psyched about taking over the project
> without any sense of direction on my end (this is a bit un-Apache
> as well), it will be sort of a guarantee for the ongoing support of
> CayenneModeler requirements. The first one of those being Maven
> builds from repo that we could use in Cayenne.
>
> Thoughts? Comments?
>
> (Kevin, Evert, please feel free to chime in as well)
>
> Andrus
>
> [1] http://objectstyle.org/cayenne/lists/cayenne-devel/
> 2006/07/0032.html
> [2] http://jpf.sourceforge.net/
> [3] http://platonos.sourceforge.net
> [4] http://platonos.cvs.sourceforge.net/platonos/ppe2/
Re: CayenneModeler plugin environment
Posted by Andrus Adamchik <an...@objectstyle.org>.
There is nothing to be sorry about. I am getting much better in
dealing with online attitudes during the past few years. Besides this
is a valid discussion and I want to follow up on it once Dmitry (the
main developer) gets back from vacation. And I was indeed having fun
reading about Apache License taking away rights from users coming
from the GPL supporters :-)
Hopefully we'll be able to use this time to evaluate Platonos 2.0 vs.
JPF on the technical merits.
Andrus
On Jul 24, 2006, at 4:49 AM, Ahmed Mohombe wrote:
>> Now you can read some fun (L)GPL vs. Apache license discussion on
>> this forum ... and the project owner is on vacation for a month,
>> so this is all just hot air. Have fun :-)
> I'm very sorry :(. When proposing this project I evaluated the
> technical aspect
> of the framework, the rich documentation and the support form the
> author, but
> not the attitude of some users that "hang around", and try to "slow
> it down" :(.
>
> Ahmed.
>
>
Re: CayenneModeler plugin environment
Posted by Ahmed Mohombe <am...@yahoo.com>.
> Now you can read some fun (L)GPL vs. Apache license discussion on this
> forum ... and the project owner is on vacation for a month, so this is
> all just hot air. Have fun :-)
I'm very sorry :(. When proposing this project I evaluated the technical aspect
of the framework, the rich documentation and the support form the author, but
not the attitude of some users that "hang around", and try to "slow it down" :(.
Ahmed.
Re: CayenneModeler plugin environment
Posted by Andrus Adamchik <an...@objectstyle.org>.
Now you can read some fun (L)GPL vs. Apache license discussion on
this forum ... and the project owner is on vacation for a month, so
this is all just hot air. Have fun :-)
Andrus
On Jul 23, 2006, at 2:32 PM, Andrus Adamchik wrote:
>
> On Jul 23, 2006, at 4:42 AM, Ahmed Mohombe wrote:
>
>> The JPF developer asked if he should change the license to ASF or
>> something else,but no one gave good reason to do it - so it was
>> not done at that time:
>> http://tinyurl.com/gwbag
>
> Thanks for posting this link - I posted a request to change the
> license on the JPF forum.
>
> Andrus
>
>
Re: CayenneModeler plugin environment
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jul 23, 2006, at 4:42 AM, Ahmed Mohombe wrote:
> The JPF developer asked if he should change the license to ASF or
> something else,but no one gave good reason to do it - so it was not
> done at that time:
> http://tinyurl.com/gwbag
Thanks for posting this link - I posted a request to change the
license on the JPF forum.
Andrus
Re: CayenneModeler plugin environment
Posted by Ahmed Mohombe <am...@yahoo.com>.
> I am back to the plugin engine topic again. Now it is out of the
> hypothetical realm, as 3.0 development has already started.
>
>
> Thoughts? Comments?
Compared to JPF, Platonos looks poor and undocumented (about abandonware not to mention) - even if
it's donated.
The JPF developer asked if he should change the license to ASF or something else,but no one gave
good reason to do it - so it was not done at that time:
http://tinyurl.com/gwbag
IMHO the technical advantage is much more important, so for the legal part can always be found a
solution.
Ahmed.
Re: CayenneModeler plugin environment
Posted by Evert Tigchelaar jr <ev...@cnerds.com>.
Andrus Adamchik wrote:
> I am back to the plugin engine topic again. Now it is out of the
> hypothetical realm, as 3.0 development has already started.
>
> First I wanted to address earlier suggestion by Ahmed [1] to use JPF
> [2]. Cayenne *as a package* is released under Apache license. ASF has an
> explicit policy that prohibits bundling (L)GPL software. We can't even
> use Launch4j for the Windows distro as it has a binary component that is
> distributed with Cayenne. The only "workaround" for the LGPL
> "incompatibility" is to release the Modeler entirely outside of Apache,
> which is certainly NOT what we want.
>
> *****
>
> Another candidate is Platonos [3]. Which is an excellent one, but as
> Ahmed and myself pointed out, the project is dormant, as its developers
> can't for personal reasons dedicate much time to it.
>
> I contacted Platonos developers to get a better feeling of the situation
> (I am cc'ing to Kevin and Evert who are the main force behind the
> project). To be entirely accurate the project is not dormant - Evert is
> developing a new version [4], which I still need to explore, and looking
> into JSR 198 (A Standard Extension API for IDE, which itself seems
> dormant :-)). And Kevin is consistently providing support on the user
> mailing list. Essentially the situation is slightly better than I had
> with JStaple some time ago (really passionate about the project, but not
> realistic to do 100 things at once).
Yes, I (Evert) am working on the new version for time to time, just got
my bachelor degree and now I am a bit busy with job interviews. JSR 198
is designed for IDE's but a lot of things could also be applied to many
other kinds of applications so thats the reason I look a bit into it, to
see what could be useful for our pluginengine.
> Kevin suggested donating Platonos code to Apache. In the ideal world
> this would be a great idea. This is a very nice component that would fit
> either in Jakarta commons or Cayenne (believe it or not, such commonly
> useful thing as a plugin engine is nowhere to be found). Still with no
> support from the original developers for the time-consuming incubation
> process, I don't see this as an option at this time. Essentially this
> would place the Platonos incubation burden on Cayenne committers. Don't
> know about others, but for me this is out of the question at the moment.
> While I'd be glad to mentor such project at the Incubator, anything
> beyond that is unrealistic until Cayenne's own incubation is finished.
> Maybe we can scout for volunteers on the Incubator list??
>
> Anyways, IMO the best option would be to start with current Platonos
> code, working out any issues with Kevin and Evert. Kevin also suggested
> giving commit access to interested Cayenne committers. While I am not
> psyched about taking over the project without any sense of direction on
> my end (this is a bit un-Apache as well), it will be sort of a guarantee
> for the ongoing support of CayenneModeler requirements. The first one of
> those being Maven builds from repo that we could use in Cayenne.
>
> Thoughts? Comments?
>
> (Kevin, Evert, please feel free to chime in as well)
>
> Andrus
Yes, I think what Andrus suggest is good idea, because of the
time-consuming incubation process as he told.
Looking forward to comments on our pluginengine and see where our
pluginengine can be useful for your modeling tool.
> [1] http://objectstyle.org/cayenne/lists/cayenne-devel/2006/07/0032.html
> [2] http://jpf.sourceforge.net/
> [3] http://platonos.sourceforge.net
> [4] http://platonos.cvs.sourceforge.net/platonos/ppe2/
>
Re: CayenneModeler plugin environment
Posted by Evert Tigchelaar jr <ev...@cnerds.com>.
Andrus Adamchik wrote:
>
> On Jul 22, 2006, at 11:52 PM, Kevin Duffey wrote:
>> I have not joined the cayenne-dev list, so I may not see some replies.
>> I am on about 17 mailing lists right now and while I do not mean any
>> offense, I don't have the time to start developing on a new project.
>
> Certainly no offense, but see related comments below.
>
>> A few thoughts since Andrus has emailed Evert and I. First, I would
>> like to explore Evert's "2.0" codebase a bit, possibly with Evert and
>> Andrus on IM if there is any possibility we can all three meet. I know
>> I am in California, PST and Evert is Netherlands. I am on Yahoo IM as
>> is Evert if Andrus, you could maybe join up (if you dont have Yahoo
>> account) and meet with us, or we can log in to any IRC server (usually
>> EFNET works well) and chat in a private channel. Does this work for
>> you Andrus... if so, yahoo/irc? Anyone else on the cayenne project is
>> welcome to join as well.
>
> We are (almost) an Apache project, so we do things via mailing lists. I
> would suggest to do the same here, and avoid the timezone mismatch
> problems at the same time :-) To save you from the flood of unrelated
> traffic on cayenne-dev, I just subscribed to platonos-plugeng-dev. Let's
> communicate via that list, so there will be a track record for anybody
> who would want to jump on it later. This is important.
>
>> The 2.0 codebase is a rewrite of the engine from scratch. It shares
>> many of the same ideas, especially at the classloader level, but we
>> ran into some snags with plugin dependencies (primarily circular
>> references where plugin A depends on B, B on C and C on A.. not a good
>> thing to do).
>
> I still need to check out 2.0. Hopefully I'll have time tomorrow.
>
>> As well, Evert, who did most of the unload coding of plugins, learned
>> that there is quite a problem in trying to unload plugins once one
>> plugin grabs a ref to any class in another plugin. I used to
>> contribute to the Eclipse Equniox project, and learned from them that
>> they basically unload the entire plugin stack to do a runtime reload
>> of just a single plugin, depending on the dependency complexities.
>> Anyway, don't want to delve into that now, just a heads up of why the
>> 2.0 codebase may be the way to go, especially if a few of you on the
>> cayenne project will help contributes to it (both code and ideas).
Yes, the unloading of plugins can be difficult. A classLoader loads
classes and while there are still references to one or more of the
classes that were loaded by a classloader they will not be garbage
collected. So for example, if plugin B implements an interface from
plugin A, then plugin A can not be unloaded until plugin B has been
unloaded.
Btw, we have two kinds of plugins, directory plugins and plugin archive
plugins.
Directory plugins are plugins that have the classes and other resources
in a directory.
Archive plugins are plugins that are stored in an zip based archive,
default file extensions are .par and .jar but other file extensions
could be configured (by code) to if desired. The only extra feature a
plugin archive has is that it can also contain embeded zip basesd
archives, so you can bundle your class libraries in the plugin archive.
No code changes are needed in plugins to be used as archive plugins,
this is handles by our classloader. Archive plugins may be a bit slower
than directory plugins but I try to improve that where I can.
> Just like you don't want to delve into Cayenne, we'll probably just be
> the "active observers" :-)
>
> Andrus
>
Re: CayenneModeler plugin environment
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jul 22, 2006, at 11:52 PM, Kevin Duffey wrote:
> I have not joined the cayenne-dev list, so I may not see some
> replies. I am on about 17 mailing lists right now and while I do
> not mean any offense, I don't have the time to start developing on
> a new project.
Certainly no offense, but see related comments below.
> A few thoughts since Andrus has emailed Evert and I. First, I would
> like to explore Evert's "2.0" codebase a bit, possibly with Evert
> and Andrus on IM if there is any possibility we can all three meet.
> I know I am in California, PST and Evert is Netherlands. I am on
> Yahoo IM as is Evert if Andrus, you could maybe join up (if you
> dont have Yahoo account) and meet with us, or we can log in to any
> IRC server (usually EFNET works well) and chat in a private
> channel. Does this work for you Andrus... if so, yahoo/irc? Anyone
> else on the cayenne project is welcome to join as well.
We are (almost) an Apache project, so we do things via mailing lists.
I would suggest to do the same here, and avoid the timezone mismatch
problems at the same time :-) To save you from the flood of unrelated
traffic on cayenne-dev, I just subscribed to platonos-plugeng-dev.
Let's communicate via that list, so there will be a track record for
anybody who would want to jump on it later. This is important.
> The 2.0 codebase is a rewrite of the engine from scratch. It shares
> many of the same ideas, especially at the classloader level, but we
> ran into some snags with plugin dependencies (primarily circular
> references where plugin A depends on B, B on C and C on A.. not a
> good thing to do).
I still need to check out 2.0. Hopefully I'll have time tomorrow.
> As well, Evert, who did most of the unload coding of plugins,
> learned that there is quite a problem in trying to unload plugins
> once one plugin grabs a ref to any class in another plugin. I used
> to contribute to the Eclipse Equniox project, and learned from them
> that they basically unload the entire plugin stack to do a runtime
> reload of just a single plugin, depending on the dependency
> complexities. Anyway, don't want to delve into that now, just a
> heads up of why the 2.0 codebase may be the way to go, especially
> if a few of you on the cayenne project will help contributes to it
> (both code and ideas).
Just like you don't want to delve into Cayenne, we'll probably just
be the "active observers" :-)
Andrus
Re: CayenneModeler plugin environment
Posted by Kevin Duffey <ke...@yahoo.com>.
Hi all,
I have not joined the cayenne-dev list, so I may not see some replies. I am on about 17 mailing lists right now and while I do not mean any offense, I don't have the time to start developing on a new project.
A few thoughts since Andrus has emailed Evert and I. First, I would like to explore Evert's "2.0" codebase a bit, possibly with Evert and Andrus on IM if there is any possibility we can all three meet. I know I am in California, PST and Evert is Netherlands. I am on Yahoo IM as is Evert if Andrus, you could maybe join up (if you dont have Yahoo account) and meet with us, or we can log in to any IRC server (usually EFNET works well) and chat in a private channel. Does this work for you Andrus... if so, yahoo/irc? Anyone else on the cayenne project is welcome to join as well.
The 2.0 codebase is a rewrite of the engine from scratch. It shares many of the same ideas, especially at the classloader level, but we ran into some snags with plugin dependencies (primarily circular references where plugin A depends on B, B on C and C on A.. not a good thing to do). As well, Evert, who did most of the unload coding of plugins, learned that there is quite a problem in trying to unload plugins once one plugin grabs a ref to any class in another plugin. I used to contribute to the Eclipse Equniox project, and learned from them that they basically unload the entire plugin stack to do a runtime reload of just a single plugin, depending on the dependency complexities. Anyway, don't want to delve into that now, just a heads up of why the 2.0 codebase may be the way to go, especially if a few of you on the cayenne project will help contributes to it (both code and ideas).
As Andrus mentioned, I am tied up with my present job, but always check emails, and would like to start contributing a bit more to the new codebase.
Look forward to working with you guys.
Andrus Adamchik <an...@objectstyle.org> wrote: I am back to the plugin engine topic again. Now it is out of the
hypothetical realm, as 3.0 development has already started.
First I wanted to address earlier suggestion by Ahmed [1] to use JPF
[2]. Cayenne *as a package* is released under Apache license. ASF has
an explicit policy that prohibits bundling (L)GPL software. We can't
even use Launch4j for the Windows distro as it has a binary component
that is distributed with Cayenne. The only "workaround" for the LGPL
"incompatibility" is to release the Modeler entirely outside of
Apache, which is certainly NOT what we want.
*****
Another candidate is Platonos [3]. Which is an excellent one, but as
Ahmed and myself pointed out, the project is dormant, as its
developers can't for personal reasons dedicate much time to it.
I contacted Platonos developers to get a better feeling of the
situation (I am cc'ing to Kevin and Evert who are the main force
behind the project). To be entirely accurate the project is not
dormant - Evert is developing a new version [4], which I still need
to explore, and looking into JSR 198 (A Standard Extension API for
IDE, which itself seems dormant :-)). And Kevin is consistently
providing support on the user mailing list. Essentially the situation
is slightly better than I had with JStaple some time ago (really
passionate about the project, but not realistic to do 100 things at
once).
Kevin suggested donating Platonos code to Apache. In the ideal world
this would be a great idea. This is a very nice component that would
fit either in Jakarta commons or Cayenne (believe it or not, such
commonly useful thing as a plugin engine is nowhere to be found).
Still with no support from the original developers for the time-
consuming incubation process, I don't see this as an option at this
time. Essentially this would place the Platonos incubation burden on
Cayenne committers. Don't know about others, but for me this is out
of the question at the moment. While I'd be glad to mentor such
project at the Incubator, anything beyond that is unrealistic until
Cayenne's own incubation is finished. Maybe we can scout for
volunteers on the Incubator list??
Anyways, IMO the best option would be to start with current Platonos
code, working out any issues with Kevin and Evert. Kevin also
suggested giving commit access to interested Cayenne committers.
While I am not psyched about taking over the project without any
sense of direction on my end (this is a bit un-Apache as well), it
will be sort of a guarantee for the ongoing support of CayenneModeler
requirements. The first one of those being Maven builds from repo
that we could use in Cayenne.
Thoughts? Comments?
(Kevin, Evert, please feel free to chime in as well)
Andrus
[1] http://objectstyle.org/cayenne/lists/cayenne-devel/2006/07/0032.html
[2] http://jpf.sourceforge.net/
[3] http://platonos.sourceforge.net
[4] http://platonos.cvs.sourceforge.net/platonos/ppe2/
---------------------------------
Do you Yahoo!?
Get on board. You're invited to try the new Yahoo! Mail Beta.