[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[technology-pmc] EclipseLink: Dependent non-oss libraries
|
Technology
PMC,
As we prepare for
the proposed contribution of Oracle TopLink to the Eclipse Java Persistence
Platform Project we are working hard to clearly define/describe all dependencies
and identify any that can/should be removed.
The TopLink product
includes a significant set of build/test dependencies with a much smaller set of
runtime dependencies which are required only based on the functionality
used.
Object-Relational Example:
TopLink's ORM
capabilities does include many vendor specific capabilities (OracleDB, DB2,
Sybase, MySQL, ...). Most of these extensions are done through custom SQL
generation and have no hard dependencies on specific vendor JDBC drivers. In
the case of Oracle's database however there are many extensions for advanced
data types where hard dependencies on an Oracle JDBC driver are required. This
means that to build and test the full product you must have the Oracle JDBC
driver present. Customers using the resulting toplink.jar do not however
require the Oracle JDBC driver for standard object-relational functionality.
The product is written so these dependencies are only required when actually
accessing the specific extended capabilities.
We also have
a similar issue in our EIS mappings using JCA resource adapters. These include
IBM MQ, Oracle AQ, and Attunity adapters.
My question
for the PMC is with respect to how a new project should address these
dependencies. Since the dependent JARs are not open source themselves it poses
an interesting challenge. The build machine and any machine performing full
product testing will require these libraries.
1. How is
this typically addressed in Eclipse projects?
2. Is there
a project structure (i.e. sub-components) that address compartmentalizing of
these dependencies that we should follow?
3. How are
these dependencies addressed in the IP review process?
Doug
