I agree with having a good OOTB experience as well -- such an experience helps users get started with OpenJPA and is more likely to have them learning the APIs and using the distro.
Even better, it's all in the ASF family. :) Eddie On 4/23/07, Craig L Russell <[EMAIL PROTECTED]> wrote:
I agree that it's nice to have an out-of-the-box database shipped with our distribution. Once Java SE 6 is universal, we can revisit the decision, since Java SE 6 distributes Java DB (a renamed Derby distribution). Craig On Apr 23, 2007, at 3:03 PM, Kevin Sutter wrote: > 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 >> Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
