It's still a bit of a question mark, I thought, as to whether you
needed an OS X server license to deploy with or not. Apple contacted
me about the plugin, though, so I'll email them and ask specifically.
One particularly funky thing about SQL generation is that the
EOModeler plugin runs in Eclipse's classpath, but the db plugins and
JDBC drivers are in the PROJECT classpath. So we are going to have
to do some crazy classpath manipulation to be able to run the SQL gen
code in the project's classpath ... It should be totally doable,
though, using JarClassLoader to setup a dynamic classpath to run within.
Index creation would be AWESOME. That drives me CRAZY that EOM
doesn't do it. As god is my witness, we will never go without
indexes again :) I can add a new flag on attribute that lets you
specify that it's indexed and write it into a custom entry in the plist.
Oh by the way, re: plists being associated with eomodeler ... So I
have a custom decorator that only sets the icon when a plist is
inside of an eomodeld. However, to have double-clicking plists open
EOModeler plugin, I had to add it to the extension list for the
editor, which override my decorator. So it SHOULD be the case that a
plist inside of an eomodeld folder has the entity icon, but maybe a
plist somewhere else has the eomodel icon (which is the icon
associated with EOModelEditor?).
ms
On Jul 13, 2006, at 11:45 AM, Pierre Frisch wrote:
> But there are no licensing issue anymore. We can redistribute a WO
> developed product freely since WO 5.3 and WOLips is no exception.
>
> If we decide to use WO I could probably do my share. I am on
> "holiday" for 10 days so I can have a look at it. The table
> creation is part of EOF public API and is supported by all Databse
> plug-ins. I also have a library for index creation that is one of
> the bug missing feature of EOModeler.
>
> Pierre
>
> On 13-Jul-06, at 8:20 AM, Mike Schrag wrote:
>
>> We can't include WO libraries in the WOLips distribution because
>> of licensing, so it would require having users copy WO jar files
>> into plugins after installing. I think it would suck from a
>> workflow standpoint. But yeah, SQL generation is one of the
>> nastiest things so far ... I'm also not quite sure if the table
>> creation code is in the WO libs or in EOModeler's private
>> frameworks. I've never actually done that from within WO itself.
>>
>> ms
>>
>> On Jul 13, 2006, at 10:29 AM, Pierre Frisch wrote:
>>
>>> Just one question? Why not use WO for sql generation? It works
>>> very well and I have lots of experience with it. All my projects
>>> create their own DB structure if it does not pre-exist. It would
>>> have the benefit of consistency.
>>>
>>> Pierre
>>>
>>> On 13-Jul-06, at 4:16 AM, Mike Schrag wrote:
>>>
>>>> For the curious, here's my tentative plan for EOModeler:
>>>>
>>>> Pretty Much Done
>>>> * data model (reading, writing, loading dependent models,
>>>> prototype support, etc) including notifications (for syncing UI
>>>> components as it changes)
>>>> * model browser (== 'tree view in EOModeler)
>>>> * entity browser (== entity list table in EOModeler)
>>>> * attribute browser (== attribute list table in EOModeler)
>>>> * relationship browser (== relationship list table in EOModeler)
>>>> * relationship editor (== relationship inspector in EOModeler)
>>>> * user info editor (shared among several object types in
>>>> inspectors)
>>>> * java generation (wolips integrates with EOGenerator for java
>>>> generation)
>>>> * entity editor (excluding stored procs)
>>>>
>>>> Phase 1.0 To-Do's (sure things for WWDC)
>>>> * adaptor info editor
>>>> * attribute editor
>>>>
>>>> Phase 1.1 To-Do's (pretty must essential, but might be annoying)
>>>> * SQL generation (this is the big one -- I'm hoping to be able
>>>> to use Cayenne's code for this) -- It's the trickiest because it
>>>> requires the eclipse plugin to talk to a JDBC driver that isn't
>>>> in its own classpath (it's in the project's classpath). This is
>>>> the one I'm least looking forward to :)
>>>>
>>>> Phase 1.2 To-Do's (really nice to have, but not technically
>>>> ESSENTIAL)
>>>> * fetch spec editor
>>>> * flattened relationship editor
>>>>
>>>> Phase 2 To-Do's (probably post WWDC)
>>>> * stored procedure browser/editor/etc
>>>> * diagram view (Eclipse has the Graph Editing Framework (GEF)
>>>> that should provide most of this, but I'm pushing it off for now)
>>>> * sql data browser (though if i can do generation, this might
>>>> not be a big deal)
>>>> * schema syncing
>>>>
>>>> ms
>>>
>>
>
This archive was generated by hypermail 2.0.0 : Thu Jul 13 2006 - 11:58:00 EDT