Re: choosing EclipseLink over TopLink/TopLink Essentials
Giovanni Azua wrote:
"Lew" <noone@lewscanon.com> wrote in message
news:gu79tj$4jp$1@news.albasani.net...
Giovanni Azua wrote:
Maybe my bad, researching latest TopLink's source code I could not find
the TopLink API accepting JPQL statements ...
http://www.oracle.com/technology/software/products/ias/htdocs/1111topsoft.html
Did you find it in the EclipseLink source?
yep :)
Wha...?
Consider a set of features: { JPA, JDBC, HELPER, PUBLICAPI }.
[snip]
What is your definition of "subset"?
That's it. If you open the download toplink_111101_en.zip and extract
"toplink-src.zip" you will find e.g. [sic]
{ HELPER, PUBLICAPI, XXX }
That's one subset of TopLink.
If you extract "eclipselink-src.zip" you will find e.g.
{JPA, YYY}
That's a distinct subset of TopLink.
is {JPA, YYY} subset of { HELPER, PUBLICAPI, XXX } ??? ehhhh no! :)
No, but both are proper subsets of TopLink, {JPA, YYY, HELPER, PUBLICAPI, XXX,
ZZZ }. Ehhhh, yes.
Your argument is specious. You show that each subset is distinct, and not
redundant with the other. Both are subsets of the overall product, which is
the point. Each subset is resonsible for a different, non-overlapping part of
the overall functionality. That's just how the product is organized. It
proves my point.
You kept referring to the "full" TopLink. I note that both of the ZIPs you
mentioned are included in toplink_111101.zip, a fact you conveniently omit
from your discourse, and that there are other subsets of TopLink not included
in either of those sub-ZIPs: xml.jar, glassfish.jaxb_2.1.6.jar,
coherence-eclipselink-src.zip, and more.
Showing that a proper subset of the full product doesn't include everything in
the full product, as you did, is a rather trivial point.
--
Lew