RE: [technology-pmc] EclipseLink: Dependent non-oss libraries

["Wayne Beaton" <wayne@xxxxxxxxxxx>]

Hi Doug. I haven't had the time to provide the answer you are due. But I did
come across this comment that Mike posted on the Higgins dev list.

--
I should also point out that the Eclipse Board is in the process of drafting
a policy which explicitly states that prereq'ing code with non-compatible
licenses and/or known IP problems will be a no-no. For exactly those reasons
described by Tony. Although doing this will sometimes make things "easier"
for a project, if no one can build a product or distribute the combination,
there is not a lot of value in doing it in the first place.
--

The the simple answer is "no". As for how other projects address this issue,
I'll have to work a little harder to come up with a reasonable answer.

Wayne
--
Wayne Beaton
The Eclipse Foundation
wayne.beaton@xxxxxxxxxxx
Skype, YIM: waynebeaton
http://www.eclipse.org
http://wbeaton.blogspot.com/
http://www.planeteclipse.org/planet/
 

> -----Original Message-----
> From: technology-pmc-bounces@xxxxxxxxxxx 
> [mailto:technology-pmc-bounces@xxxxxxxxxxx] On Behalf Of Doug Clarke
> Sent: April 10, 2007 3:01 PM
> To: Eclipse-Technology-PMC (E-mail)
> Subject: [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
>