Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[technology-pmc] RE: EclipseLink: Dependent non-oss libraries
Sorry for the resend but I realized I sent this before completing the registration to the mailing list and was unsure if it got through.
 

Doug Clarke
Principal Product Manager, Oracle TopLink
Oracle Corporation

-----Original Message-----
From: Doug Clarke [mailto:douglas.clarke@xxxxxxxxxx]
Sent: Tuesday, April 10, 2007 3:01 PM
To: Eclipse-Technology-PMC (E-mail)
Subject: 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

Back to the top