Hi Mike,
I would like to question a few assumption. Why do we need to ship WO
jars with WOLips? WO is a prerequisite of WOLips and is therefore
installed on very machine we run on. Why not use it where it is. I
know that it requires a bit of fancy work for loading the jar
dynamically but we will have to do that for the SQL generation anyway.
The other thing we all need to remember is that EOModeler and Java
EOF modeling support are two very different things. EOModeler uses
EOF 4.5 in ObjC. In no case do I suggest to use the old ObjC
libraries. I think we should not infer the EOModeler bugs into the
Java version. I have had quite a bit of experience with the Java
version so I must confess that I feel a lot more at ease with the
Java EOF than with Cayenne that I have never used and will probably
never use.
Pierre
On 19-Jul-06, at 12:39 PM, Mike Schrag wrote:
> I'm sending this to the woproject list because I would like to get
> opinions from the other developers/users on this, too. It's kind
> of a fundamental point that we need to come to an agreement on.
>
> On Jul 19, 2006, at 5:51 AM, Pierre Frisch wrote:
>> Hi Mike,
>>
>> I really like your implementation of the new modeler but I have a
>> real problem with using Cayenne. The purpose is to create WO code
>> and I think we should use WO tools. Cayenne may be an excellent
>> product but I find really not worth my time to learn it when I
>> have EOF. The only justification for it was the license but that
>> excuse does not exist any more.
>>
>> I much prefer to work with EOF bugs that I know inside out than
>> learning another tool that is not where I am going to deploy
>> anyway. The other objection I have is that we are creating a
>> dependency on cayenne that we do not need. WO is a prerequisite of
>> WOLips anyway.
>>
>> Thanks
>>
>> Pierre
>
> I assume your email is in response to my commit last night where I
> removed my reimplementation of EOQualifiers and replaced it with
> Cayenne Expressions. First, some background on the change: I need
> to make a Fetch Spec editor panel, and at the moment I don't want
> to make a graphical qualifier builder, because it's a huge pain.
> The obvious alternative is to provide just a text area where you
> can type a qualifier in text form. Not wanting to write the parser
> for that, I switched over to Cayenne expressions, which already has
> a parser/formatter and data model for building what it is
> effectively an EOQualifier, for Entity Modeler's (shoutout Chuck)
> in-memory representation, and I wrote a converter that can turn
> Expressions into EOQualifier eomodel format and from eomodel format
> into Expressions (with the exception at the moment of doesContain:,
> which I'm not sure if you can even put in a fetch spec). Note that
> we already use Cayenne (and have for some time) for other things in
> WOLips -- specifically PropertyListSerialization/Deserialization.
>
> We get to the next part, which is sort of the crux of the issue,
> though. The reason I have done this is that we don't currently
> have any internal dependencies on actual WO libraries.
> Historically this has been a legal issue -- we were not legally
> allowed to ship WO jars as part of WOLips. The recent changes to
> licensing may allow us to ship jars, though. I know you had spoken
> with Daryl about shipping WO jars as part of an app you have, but
> when I emailed her specifically about WOLips and bundling WO jars
> inside of it, it wasn't an immediate "yes" response. She's talking
> with Apple Legal to see if this is something we're allowed to do.
> So my first concern is whether this actually is legal or not. If
> it's not, then I'm all for using what is convenient -- if that's
> Cayenne, so be it. However, it may turn out that it's perfectly
> legal in which case we have another issue to discuss.
>
> Does WOLips have a philosophical issue with including WO jars?
> Real EOModeler sucks because we don't have source and we can't fix
> their crap. If we start depending on WO libraries, is this going
> to put us right back in the same situation? Case in point -- a
> post on webobjects-dev just yesterday about EOModeler not updating
> the list of client class properties when you change the name of an
> attribute. If we were using the com.webobjects.eo* code for our
> EOModel stack, we might very well inherit this same behavior and
> not be able to do anything about it. The reimplementation of
> EOModel/Attribute/etc that Entity Modeler is using has support for
> event notification throughout, making it substantially easier to
> hook up to the new modeler UI, and we can actually fix problems
> with it. Obviously we can't fix things that would fail at runtime,
> and we need to be consistent with EOF's runtime behavior, so
> there's a case to be made that maybe we SHOULD inherit its bugs (I
> think that case is lame though :) ).
>
> So what do people think? If we officially find out that we can
> ship WO jars in WOLips, should we? If we do, should EOModeler
> plugin be using the EO model stack instead of its own (if you
> answer is yes, have fun because I'm not rewriting it :) ).
>
> ms
>
This archive was generated by hypermail 2.0.0 : Wed Jul 19 2006 - 07:11:23 EDT