On Feb 14, 2006, at 1:31 PM, Frank Budinsky wrote:
Part of the Eclipse (EMF) project build is the plugin (jar)
"commonj-sdo",
which contains nothing more then the implementation-independent SDO
v1.0
interfaces distributed with the SDO spec. The fact that it's part
of EMF
version 2.1.0 or any other version, is just an Eclipse build
statement ...
the interfaces are the same in any EMF version - it only ever
implemented
SDO 1.0.
In the Tuscany spec/sdo project we have essentially the same thing
- a jar
that contains the (implementation neutral) SDO interfaces from the SDO
spec - but this time SDO v2.0. SDO 2, however, introduces "hellper
interfaces" which include an INSTANCE field for locating the
implementation. The way that the "supplied" SDO interfaces locate the
helper instances (implementations) was trivial and in fact (as Jeremy
pointed out) made it impossible to support multiple implementations
of the
interfaces, so we (Jeremy) replaced the class that manges this with
our
own. So now our impl-neutral jar is even more neutral.
We had a similar problem with SCA originally (use of a static field
on an interface). We decided to remove the use of .INSTANCE and use a
factory locator. Is the SDO spec considering moving away from .INSTANCE?
Hope this helps clarify things.
Yes, thanks.
Frank.
Jim Marino <[EMAIL PROTECTED]> wrote on 02/14/2006 12:49:05 PM:
O.K. I assumed 2.1.0 referred to the SDO version (2.1.0 eclipse impl
~ SDO 1.0). It seems like the issue of an impl-neutral jar should be
raised with the spec group since this is bound to crop up elsewhere.
Jim
On Feb 14, 2006, at 9:34 AM, Jeremy Boynes wrote:
Jim Marino wrote:
In our POMs, we have the following dependency:
<dependency>
<groupId>org.eclipse.emf</groupId>
<artifactId>commonj-sdo</artifactId>
<version>2.1.0</version>
</dependency>
So does 2.1.0 refer to the eclipse version, not the "spec" jar?
Yes. This is the SDO1 API.
Is there an "independent" (i.e. impl neutral) SDO jar?
Due to issues with the SDO spec, no. However, I made some changes
to our
version of the SDO2 spec jar (the one in spec/sdo) to allow multiple
implementations to share it. It's a "vendor" extension that allows
other
vendors to use our implementation :-)
I am in the process of converting the SCA code over to using our
SDO2
implementation rather then the SDO1 one from Eclipse. Until this is
done
we need to continue using the SDO1 APIs to match the SDO1
implementation.
If someone would like to chip in, any assistance would be
appreciated.
--
Jeremy
