Sure -- One less thing I have to think about. I don't have
permission to grant commit rights, so you can just email me a patch
if you get something you're happy with.
ms
On Jul 13, 2006, at 12:20 PM, Pierre Frisch wrote:
> With WO licensing I don't understand why Apple cannot make their
> intention clear -:). It is all there but you have to learn some
> bizarre legal language top understand it. I am sorry I did not
> step in before.
>
> Saving before SQL generation is a valid strategy. Would you like me
> to have a look into this? I have 12 hours of flight in from of me -:)
>
> On a practical note how do I commit? or do you want it all to go
> through you?
>
> Pierre
>
> Pierre
>
> On 13-Jul-06, at 9:03 AM, Mike Schrag wrote:
>
>> So based on the email you sent, it sounds like licensing isn't
>> really an issue ... Interesting. Well, I needed to clean room the
>> EOModel files to do notifications properly, so I don't feel TOO
>> bad that I ended up rewriting all that. I suspect it would have
>> been really tricky to try and wire up the current models to make
>> the active update the UI. However, now we have two model sets
>> that we need to go between. It may be that we require the user to
>> save their model before SQL generation, and just reload the model
>> again using EOF proper?
>>
>> 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 - 12:39:37 EDT