[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [technology-pmc] EclipseLink: Dependent non-oss libraries
|
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
>