I understand the need to avoid possible version conflicts, but it
surprises me that code with direct references to SDO classes would not
include an explicit SDO dependency. Applying this principle in all cases
would require intimate knowledge of the full dependency chains for
everything that my code is pullng in, so I that I can exclude direct
dependencies for anything I am using that happens to get pulled in by a
dependency chain. Even so, I could still get into trouble if I'm pulling
in code from direct dependencies A and B, and they both pull in dependency C
but at different levels. If I'm using code from C as well, will I get the
A version of C or the B version of C?
Simon
Raymond Feng wrote:
Hi,
This is the transitive dependency support by maven. IMO, duplicating the
SDO dependency might lead to inconsistent versions for SDO and DAS
unless we need to use a different version of SDO other than the one used
by a given DAS version.
Thanks,
Raymond
----- Original Message ----- From: "Simon Nash" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Friday, July 13, 2007 7:29 AM
Subject: SDO dependencies in implementation-das and implementation-data
I was looking through the Java SCA trunk for dependencies on SDO.
Both implementation-das and implementation-data use commonj.sdo APIs,
but they don't declare an SDO dependency in their poms. This happens
to work out because the tuscany-das-rdb dependency pulls in the SDO
dependency. Should the SDO dependency be declared directly rather
than pulled in indirectly in this way?
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
