Derby provides a nice "out of the box" experience, so I vote to keep it with our set of required runtime libraries.
On 4/18/07, Michael Dick <[EMAIL PROTECTED]> wrote:
In general I agree with Patrick. I'm +0 regarding including Derby, it's nice for the examples, but it just doesn't seem right to include a "preferred database" . No logical reason, just personal preference. On 4/18/07, Patrick Linskey <[EMAIL PROTECTED]> wrote: > > > - commons-logging-1.0.4.jar (used only in > > CommonsLogFactory when logging is configured to use commons) > > I think that we should leave this out altogether. Anyone who wants to > use commons logging will presumably have commons logging. > > > - commons-pool-1.3.jar (used only in > > TCPRemoteCommitProvider for distributed data caching) > > We should keep this, since it is required for one of our built-in > options, although it's unfortunate to have the extra dependency for just > one bit of code. > > > - geronimo-jms_1.1_spec-1.0.1.jar (used only in > > JMSRemoteCommitProvider for distributed data caching) > > We should leave this out, since anyone who uses the JMS RCP will need to > have a JMS server, and will therefore presumably have JMS jars. > > > - derby-10.2.2.0.jar (provided only as a convenience for > > getting started with the examples quickly) > > I think that we should keep this. > > > My question: should we differentiate between the required > > libraries and the optional ones (perhaps by putting them in > > an /optional/ directory or something)? Does anyone have > > experience with how this is done with other Apache projects? > > I think that we should make the changes I outlined above, and we should > not create an /optional/ for other things. > > -Patrick > > -- > Patrick Linskey > BEA Systems, Inc. > _______________________________________________________________________ > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual > or entity named in this message. If you are not the intended recipient, > and have received this message in error, please immediately return this > by email and then delete it. > > > -----Original Message----- > > From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On > > Behalf Of Marc Prud'hommeaux > > Sent: Wednesday, April 18, 2007 11:31 AM > > To: open-jpa-dev@incubator.apache.org > > Subject: [DISCUSS] required vs. optional dependencies > > > > > > Currently with OpenJPA, we ship with the following jars in the lib/ > > directory: > > > > * commons-lang-2.1.jar > > * commons-collections-3.2.jar > > * geronimo-jta_1.0.1B_spec-1.0.1.jar > > * geronimo-jpa_3.0_spec-1.0.jar > > * geronimo-j2ee-connector_1.5_spec-1.0.1.jar > > * serp-1.11.0.jar > > - commons-logging-1.0.4.jar (used only in > > CommonsLogFactory when logging is configured to use commons) > > - commons-pool-1.3.jar (used only in > > TCPRemoteCommitProvider for distributed data caching) > > - geronimo-jms_1.1_spec-1.0.1.jar (used only in > > JMSRemoteCommitProvider for distributed data caching) > > - derby-10.2.2.0.jar (provided only as a convenience for > > getting started with the examples quickly) > > > > The jars marked with stars (*) are the only ones that are > > actually required for OpenJPA to function in the common cases > > (the examples included in the distribution all run if you > > have just the starred libraries + derby). > > > > My question: should we differentiate between the required > > libraries and the optional ones (perhaps by putting them in > > an /optional/ directory or something)? Does anyone have > > experience with how this is done with other Apache projects? > > > > > > > > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual or > entity named in this message. If you are not the intended recipient, and > have received this message in error, please immediately return this by email > and then delete it. > -- -Michael Dick
