cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Razumovsky <>
Subject Re: Eclipse vs. Swing (Re: [jira] Commented: (CAY-762) ERDiagram for Object Entities in Cayenne Modeler)
Date Mon, 02 Nov 2009 10:17:09 GMT

In ideal world, it is surely better to rewrite modeler with SWT. But CM is
too big application to do it in a couple of weekends. My main question is:
who will be doing the work? Personally I am weak with SWT and most likely
will not participate.
Moreover, it is obvious that such plugin will be buggy at the start. So
we'll need to support both CM and SWT-CM at the same time.

I agree that such unusability as refreshing the model is user-unfriendly.
But, until we find Cayenne&SWT guru with a lot of free time, improving
modeler usability seems to be the only realistic goal for us. E.g. add
ability to generate classes automatically etc..

Once again, I'm all for Cayenne-Eclipse plugin, but I'm sceptical about its
future in current state of Cayenne community

2009/11/2 Aristedes Maniatis <>

> On 2/11/09 8:19 PM, Andrus Adamchik wrote:
>> That would've been ideal, but likely won't work. IIRC Mike from WOLips
>> commented on that at one point, saying it is not possible to have a
>> single tool for both Cayenne and EOF. I think he looked at the Modeler
>> initially (or maybe even used some of the code?) but couldn't keep it as
>> a common library due to lots of "small" differences. Still probably
>> worth pinging WOLips community to get some feedback on the idea.
> There are four options:
> 1. Keep Cayenne Modeler as a Swing app as it is today.
> 2. Write a whole new Eclipse plugin from scratch
> 3. Fork the WOLips code as a starting point for writing a Cayenne Eclipse
> plugin
> 4. Work together with WOLips to have one multi-purpose modeler
> It sounds like (4) may be difficult: I am sure it would be since there are
> competing goals and needs. And (3) might benefit us, but give nothing back
> to WoLips, so there will be no incentive for them to work together on new
> improvements. But still (3) might be easier than starting from nothing:
> surely easier than (2).
> Ari
> --
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message