Re: [DISCUSS] required vs. optional dependencies

2007-04-24 Thread Eddie O'Neil

 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_spe

Re: [DISCUSS] required vs. optional dependencies

2007-04-23 Thread Craig L Russell
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!



smime.p7s
Description: S/MIME cryptographic signature


Re: [DISCUSS] required vs. optional dependencies

2007-04-23 Thread Kevin Sutter

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



Re: [DISCUSS] required vs. optional dependencies

2007-04-18 Thread Michael Dick

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


RE: [DISCUSS] required vs. optional dependencies

2007-04-18 Thread Patrick Linskey
>- 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.


[DISCUSS] required vs. optional dependencies

2007-04-18 Thread Marc Prud'hommeaux


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?