:
Changed: sebb @ Thu 30 Jan 2014 17:05:41 +
Comment: Add a failure message
Files changed:
/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp2/cpdsadapter/TestDriverAdapterCPDS.java
( 1562895 )
Changed: sebb @ Thu 30 Jan 2014 17:11:06 +
Comment: Latest JUnit version
Files
Add direct test to ensure Utils class loads OK
Files changed:
/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp2/Utils.java (
1562912 )
/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp2/TestUtils.java (
1562912
At present DBCP uses a non-standard Maven layout.
For example src/java should really be src/main/java
Generally the poms are easier to configure if the standard layout [1] is used.
Commons Parent generally assumes the standard layout as does the Apache pom.
OK if I fix this?
[Obviously the Ant
+1
Gary
On Thu, Jan 30, 2014 at 1:56 PM, sebb seb...@gmail.com wrote:
At present DBCP uses a non-standard Maven layout.
For example src/java should really be src/main/java
Generally the poms are easier to configure if the standard layout [1] is
used.
Commons Parent generally assumes
Go for it!
2014/1/30 sebb seb...@gmail.com
At present DBCP uses a non-standard Maven layout.
For example src/java should really be src/main/java
Generally the poms are easier to configure if the standard layout [1] is
used.
Commons Parent generally assumes the standard layout as does
...@apache.org wrote:
Go for it!
2014/1/30 sebb seb...@gmail.com
At present DBCP uses a non-standard Maven layout.
For example src/java should really be src/main/java
Generally the poms are easier to configure if the standard layout [1] is
used.
Commons Parent generally assumes the standard
done on trunk.
Local build works OK as does Continuum.
Mark
Thanks!
On 30 January 2014 19:57, Benedikt Ritter brit...@apache.org wrote:
Go for it!
2014/1/30 sebb seb...@gmail.com
At present DBCP uses a non-standard Maven layout.
For example src/java should really be src/main/java
!
On 30 January 2014 19:57, Benedikt Ritter brit...@apache.org wrote:
Go for it!
2014/1/30 sebb seb...@gmail.com
At present DBCP uses a non-standard Maven layout.
For example src/java should really be src/main/java
Generally the poms are easier to configure if the standard layout [1
standard Maven layout
Files changed:
/commons/proper/dbcp/branches/DBCP_1_5_x_BRANCH/pom-1.3.xml ( 1562989 )
/commons/proper/dbcp/branches/DBCP_1_5_x_BRANCH/pom-1.4.xml ( 1562989 )
/commons/proper/dbcp/branches/DBCP_1_5_x_BRANCH/pom.xml ( 1562989 )
/commons/proper/dbcp/branches
version: 3.2.0-53-generic arch: amd64 Family:
unix
SCM Changes:
Changed: markt @ Thu 30 Jan 2014 21:39:51 +
Comment: Fix DBCP-369
Fix
On 30 January 2014 21:54, ma...@apache.org wrote:
Author: markt
Date: Thu Jan 30 21:54:56 2014
New Revision: 1562992
URL: http://svn.apache.org/r1562992
Log:
Fix DBCP-369
Fix threading issue when using multiple instances of the SharedPoolDataSource
concurrently.
I can't reproduce
On 12/01/2014 23:10, sebb wrote:
Removing the 1.4.x build should help too.
If only.
It's marginally better now, as the branch temporarily shows up as
Apache Commons DBCP 1.5-SNAPSHOT in the Group summary, but click on
the project and it all reverts to 1.4 and the old branch. I've tried
On 13 January 2014 11:08, Mark Thomas ma...@apache.org wrote:
On 12/01/2014 23:10, sebb wrote:
Removing the 1.4.x build should help too.
If only.
It's marginally better now, as the branch temporarily shows up as
Apache Commons DBCP 1.5-SNAPSHOT in the Group summary, but click
On 12/01/2014 03:06, sebb wrote:
I've been trying to add a Continuum build for the 1_5 branch, but it won't
take.
Assuming 1.4.x and 1.3.x will be auto-generated from 1.5.x you should
probably be replacing 1.4.x with 1.5.x
This may perhaps be due to the fact that the 1_4 branch also uses the
I am curious why we have a 1.5 branch. Are there new features (not
just bug fixes) relative to 1.3/1.4 in there?
Also, do you guys think it might be time to officially drop 1.3?
Getting the the combined 1.3/1.4 release scripts to work in the new
regime is not something that I personally look
On 12/01/2014 17:33, Phil Steitz wrote:
I am curious why we have a 1.5 branch. Are there new features (not
just bug fixes) relative to 1.3/1.4 in there?
JDBC 4.1 support.
Also, do you guys think it might be time to officially drop 1.3?
No objection from me.
Getting the the combined
Hi,
while looking through the commit mails, I saw that dbcp does not follow
maven conventions. Instead the code is packaged like this:
src/java/org.apache.dbcp2
src/test/org.apache.dbcp2
From what I know, you plan to roll out a new major release soon. Maybe this
is a good opportunity to change
On 1/12/14, 9:46 AM, Mark Thomas wrote:
On 12/01/2014 17:33, Phil Steitz wrote:
I am curious why we have a 1.5 branch. Are there new features (not
just bug fixes) relative to 1.3/1.4 in there?
JDBC 4.1 support.
Also, do you guys think it might be time to officially drop 1.3?
No objection
Go for it!
G
Original message
From: Benedikt Ritter brit...@apache.org
Date:01/12/2014 14:15 (GMT-05:00)
To: Commons Developers List dev@commons.apache.org
Subject: [dbcp] Adopt maven conventions?
Hi,
while looking through the commit mails, I saw that dbcp does
Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=27775projectId=295
Build statistics:
State: Failed
Previous Build: No previous build.
Started at: Sun 12 Jan 2014 22:54:24 +
Finished at: Sun 12 Jan 2014 22:54:39 +
Total time: 14s
Build
Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=27776projectId=296
Build statistics:
State: Failed
Previous Build: No previous build.
Started at: Sun 12 Jan 2014 23:00:04 +
Finished at: Sun 12 Jan 2014 23:00:21 +
Total time: 17s
Build
DBCP 1.5-SNAPSHOT in the Group summary, but click on
the project and it all reverts to 1.4 and the old branch. I've tried
deleting the old project several times; it disappears but clearly is
still around in the background messing things up.
Mark
Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=2projectId=296
Build statistics:
State: Failed
Previous Build: No previous build.
Started at: Sun 12 Jan 2014 23:20:57 +
Finished at: Sun 12 Jan 2014 23:21:12 +
Total time: 15s
Build
that maxActive was originally meaningless
because the pool was configured to grow when exhausted.
Files changed:
/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp2/cpdsadapter/DriverAdapterCPDS.java
( 1557437
Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=27762projectId=293
Build statistics:
State: Failed
Previous Build: No previous build.
Started at: Sun 12 Jan 2014 02:51:43 +
Finished at: Sun 12 Jan 2014 02:51:55 +
Total time: 11s
Build
Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=27763projectId=294
Build statistics:
State: Failed
Previous Build: No previous build.
Started at: Sun 12 Jan 2014 03:00:02 +
Finished at: Sun 12 Jan 2014 03:00:21 +
Total time: 18s
Build
I've been trying to add a Continuum build for the 1_5 branch, but it won't take.
This may perhaps be due to the fact that the 1_4 branch also uses the
same version, i.e.
1.4.1-SNAPSHOT
Is this intended, or should the 1_5 branch be using a different version?
If the version could (should) be
Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=27764projectId=294
Build statistics:
State: Failed
Previous Build: No previous build.
Started at: Sun 12 Jan 2014 03:20:47 +
Finished at: Sun 12 Jan 2014 03:21:00 +
Total time: 12s
Build
Online report :
http://localhost:8080/continuum/buildResult.action?buildId=27664projectId=73
Build statistics:
State: Failed
Previous State: Failed
Started at: Tue 7 Jan 2014 14:19:47 +
Finished at: Tue 7 Jan 2014 14:19:53 +
Total time: 5s
Build Trigger: Forced
Build
Online report :
http://localhost:8080/continuum/buildResult.action?buildId=27631projectId=73
Build statistics:
State: Failed
Previous State: Failed
Started at: Tue 7 Jan 2014 13:19:35 +
Finished at: Tue 7 Jan 2014 13:20:28 +
Total time: 53s
Build Trigger: Forced
Build
Online report :
http://localhost:8080/continuum/buildResult.action?buildId=27620projectId=283
Build statistics:
State: Failed
Previous State: Ok
Started at: Tue 7 Jan 2014 13:07:47 +
Finished at: Tue 7 Jan 2014 13:07:56 +
Total time: 9s
Build Trigger: Forced
Build Number:
that fixed a
handful of type safety warnings.
Mark
Modified:
commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp2/BasicDataSource.java
Modified:
commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp2/BasicDataSource.java
URL:
http://svn.apache.org/viewvc/commons/proper
why the annotatiions are needed and why
they are OK to use (i.e. in this case the CCE is expected and
handled).
Mark
Modified:
commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp2/BasicDataSource.java
Modified:
commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp2
the annotatiions are needed and why
they are OK to use (i.e. in this case the CCE is expected and
handled).
Mark
Modified:
commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp2/BasicDataSource.java
Modified:
commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp2
to document why the annotatiions are needed and why
they are OK to use (i.e. in this case the CCE is expected and
handled).
Mark
Modified:
commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp2/BasicDataSource.java
Modified:
commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp2
method.
Modified:
commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp2/BasicDataSource.java
Modified:
commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp2/BasicDataSource.java
URL:
http://svn.apache.org/viewvc/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp2
Project Maven 2 Build Definition (Java 1.7)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Continuum-Build-Host: vmbuild
X-Continuum-Project-Id: 73
X-Continuum-Project-Name: Commons DBCP
Online report :
http://vmbuild.apache.org/continuum
On 27/07/2013 00:24, James Carman wrote:
Perhaps an event listener for all dbcp events? Then folks can log it
themselves. I would be concerned about performance unless of course the
events are delivered asynchronously.
My initial reaction was - neat idea lets do it.
However, on further
I like it!
Le 27 juil. 2013 04:24, James Carman ja...@carmanconsulting.com a
écrit :
On Fri, Jul 26, 2013 at 10:01 PM, Gary Gregory garydgreg...@gmail.com
wrote:
On Jul 26, 2013, at 19:24, James Carman ja...@carmanconsulting.com
wrote:
Perhaps an event listener for all dbcp events
.
This should be documented in the source as well please.
Partly so our release contains the information, and partly for future
maintainers (they could easily miss the hint in the log message).
Modified:
commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp2/DelegatingResultSet.java
Perhaps an event listener for all dbcp events? Then folks can log it
themselves. I would be concerned about performance unless of course the
events are delivered asynchronously.
On Wednesday, July 24, 2013, Phil Steitz wrote:
On 7/24/13 12:56 AM, Mark Thomas wrote:
I'm working my way
On 27 July 2013 00:24, James Carman ja...@carmanconsulting.com wrote:
Perhaps an event listener for all dbcp events? Then folks can log it
themselves. I would be concerned about performance unless of course the
events are delivered asynchronously.
So long as the docs make very clear
On Jul 26, 2013, at 8:22 PM, sebb seb...@gmail.com wrote:
So long as the docs make very clear that the listener must complete
quickly, I don't see why DBCP should have to take additional
precautions.
Indeed it might be useful for debugging if the listener were synchronous.
I'm cool
On Jul 26, 2013, at 19:24, James Carman ja...@carmanconsulting.com wrote:
Perhaps an event listener for all dbcp events? Then folks can log it
themselves.
I would then expect dbcp to deliver a logging implementation, probably
not hooked up by default.
Gary
I would be concerned about
On Fri, Jul 26, 2013 at 10:01 PM, Gary Gregory garydgreg...@gmail.com wrote:
On Jul 26, 2013, at 19:24, James Carman ja...@carmanconsulting.com wrote:
Perhaps an event listener for all dbcp events? Then folks can log it
themselves.
I would then expect dbcp to deliver a logging
implementations really a problem dbcp should be
concerned with?
*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*
http://rmannibucau.wordpress.com/
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https
it correctly
from the apps (on this point slf4j is better supported)
Is this lack in container implementations really a problem dbcp should be
concerned with?
*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*
http
On 25 July 2013 14:07, ma...@apache.org wrote:
Author: markt
Date: Thu Jul 25 13:07:03 2013
New Revision: 1506952
URL: http://svn.apache.org/r1506952
Log:
Name change
Please could you specify the old and new names?
Modified:
commons/proper/dbcp/trunk/src/java/org/apache/commons
I'm working my way through the open DBCP bugs with a view to getting the
DBCP code (and the POOL code as some changes may be required there) into
a state where it is ready for the first v2 release.
I've quickly reached DBCP-154 that requests that logging is added. This
is not a new request
: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/7/24 Mark Thomas ma...@apache.org
I'm working my way through the open DBCP
On 24/07/2013 09:36, Romain Manni-Bucau wrote:
Hi,
in a bunch of JavaEE projects (openejb/tomee, OWB, CXF) we have a facade
in front of the logging to be able to select the framework to use. I know
CL is already a facade but it has the drawback to force a dependency. Maybe
it could be a
you forget providing CL in container will break app usage...which justify
the 100 lines of code IMHO
*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/
*LinkedIn:
case I'd argue that the container has a bug that needs
to be fixed.
If a container wants to provide DBCP then it is going to have to do
something to protect against conflicts when applications use (a
potentially different) version of DBCP. Whatever mechanism the container
opts for can be used
argue that the container has a bug that needs
to be fixed.
If a container wants to provide DBCP then it is going to have to do
something to protect against conflicts when applications use (a
potentially different) version of DBCP. Whatever mechanism the container
opts for can be used for Commons
there is simply no
need. Writing another facade would make switching logging frameworks
harder, not easier.
There is a choice with respect to which facade DBCP uses. I'm of the
view that we should be eating our own dog food here and if using Commons
Logging for DBCP identifies some issues with Commons
)
I think i have 2 points for JUL:
1) logging is mainly for exceptions so no need to bring something for a
case which shouldn't be that common
2) DBCP is highly linked to JDBC and JDBC uses JUL in its recent API (java
7 IIRC) so maybe we should just align on it
*Romain Manni-Bucau*
*Twitter
On 24/07/2013 11:44, Romain Manni-Bucau wrote:
well what i don't get is you (understand as tomcat guy) are the first to
relocate classes to avoid clashes with apps and here you don't want.
Relocating classes here won't help. If a container and an app both try
to use a version of DBCP that uses
both try
to use a version of DBCP that uses a relocated Commons Logging both DBCP
and the relocated Commons Logging will clash.
If relocation the preferred use case then the container has to relocate
DBCP and Logging. Relocating things in the library doesn't help.
we worked on tomee to limit
On 7/24/13 12:56 AM, Mark Thomas wrote:
I'm working my way through the open DBCP bugs with a view to getting the
DBCP code (and the POOL code as some changes may be required there) into
a state where it is ready for the first v2 release.
I've quickly reached DBCP-154 that requests
While still in Beta, there is also Log4j 2, which let's you optionally use
SLF4J as the back-end.
Gary
On Wed, Jul 24, 2013 at 12:15 PM, Phil Steitz phil.ste...@gmail.com wrote:
On 7/24/13 12:56 AM, Mark Thomas wrote:
I'm working my way through the open DBCP bugs with a view to getting
as the back-end.
Gary
On Wed, Jul 24, 2013 at 12:15 PM, Phil Steitz phil.ste...@gmail.com
wrote:
On 7/24/13 12:56 AM, Mark Thomas wrote:
I'm working my way through the open DBCP bugs with a view to getting
the
DBCP code (and the POOL code as some changes may be required
the issues are in practice (vis-à-vis dog-fooding). And one of the original
authors of JCL proposes that it SHOULD be used in just this situation (DBCP):
http://radio-weblogs.com/0122027/2003/08/15.html
quote
If however, like the Jakarta Commons project, you're building a tiny little
component
is better supported? The
containers isolate it better? Also, for the containers that do not
isolate it correctly, what is the marginal impact of adding it as a
dependency to DBCP? Do these containers bundle DBCP as well and not
isolate it? What I am trying to understand is what practical impact
working my way through the open DBCP bugs with a view to
getting
the
DBCP code (and the POOL code as some changes may be required there)
into
a state where it is ready for the first v2 release.
I've quickly reached DBCP-154 that requests that logging is added
On 24/07/2013 17:15, Phil Steitz wrote:
1) Do we absolutely need logging itself or is there some other way
we could satisfy the needs here? IIRC, there are basically two
things that require logging in DBCP: a) abandoned connections b)
exceptions / warnings. In a), we want users to be able
things that require logging in DBCP: a) abandoned connections b)
exceptions / warnings. In a), we want users to be able to log the
stack trace of the code that opened the connection. Case b) splits
into all kinds of different stuff. This may be a little smelly, but
I wonder if we could not shove
Thomas ma...@apache.org wrote:
On 24/07/2013 17:15, Phil Steitz wrote:
1) Do we absolutely need logging itself or is there some other way
we could satisfy the needs here? IIRC, there are basically two
things that require logging in DBCP: a) abandoned connections b)
exceptions / warnings
Le 24/07/2013 18:53, Romain Manni-Bucau a écrit :
about slf4j is better supported: since it is more widely used (i don't
judge)
http://qa.debian.org/popcon.php?package=libcommons-logging-java
http://qa.debian.org/popcon.php?package=libslf4j-java
You said? :)
Emmanuel Bourg
signature.asc
Hmm, libxxx is a particular usage. When i said more used i qpoke about apps
and was speaking about feedbacks i got from TomEE and work.
Le 24 juil. 2013 23:24, Emmanuel Bourg ebo...@apache.org a écrit :
Le 24/07/2013 18:53, Romain Manni-Bucau a écrit :
about slf4j is better supported: since
/r1490906
Log:
Updated copyright date range.
Modified:
commons/proper/dbcp/branches/DBCP_1_5_x_BRANCH/build.xml
Modified: commons/proper/dbcp/branches/DBCP_1_5_x_BRANCH/build.xml
URL:
http://svn.apache.org/viewvc/commons/proper/dbcp/branches/DBCP_1_5_x_BRANCH/build.xml?rev=1490906r1
wrote:
Author: psteitz
Date: Sat Jun 8 02:38:38 2013
New Revision: 1490906
URL: http://svn.apache.org/r1490906
Log:
Updated copyright date range.
Modified:
commons/proper/dbcp/branches/DBCP_1_5_x_BRANCH/build.xml
Modified: commons/proper/dbcp/branches/DBCP_1_5_x_BRANCH/build.xml
URL
On Tue, Jun 4, 2013 at 11:29 AM, sebb seb...@gmail.com wrote:
DBCP is complicated to release, because the source has to be
pre-processed in order to build additional versions of the code.
(unlike the rest of Java, JDBC is not generally upwards compatible).
Alternative proposal (worked for me
Hi Jochen,
Jochen Wiedmann wrote:
On Tue, Jun 4, 2013 at 11:29 AM, sebb seb...@gmail.com wrote:
DBCP is complicated to release, because the source has to be
pre-processed in order to build additional versions of the code.
(unlike the rest of Java, JDBC is not generally upwards compatible
Hi, Jörg,
On Wed, Jun 5, 2013 at 1:42 PM, Jörg Schaible
joerg.schai...@scalaris.comwrote:
This is here not possible, since we provide *implementations* that
implement
the affected interfaces. E.g. Statement interface has more methods which
have arguments of types that are not even present
DBCP is complicated to release, because the source has to be
pre-processed in order to build additional versions of the code.
(unlike the rest of Java, JDBC is not generally upwards compatible).
The source code in SVN is for the latest JDBC version we support, and
can be built and deployed using
sebb wrote:
DBCP is complicated to release, because the source has to be
pre-processed in order to build additional versions of the code.
(unlike the rest of Java, JDBC is not generally upwards compatible).
The source code in SVN is for the latest JDBC version we support, and
can be built
On 4 June 2013 11:16, Jörg Schaible joerg.schai...@scalaris.com wrote:
sebb wrote:
DBCP is complicated to release, because the source has to be
pre-processed in order to build additional versions of the code.
(unlike the rest of Java, JDBC is not generally upwards compatible).
The source
joerg.schai...@scalaris.com wrote:
sebb wrote:
DBCP is complicated to release, because the source has to be
pre-processed in order to build additional versions of the code.
(unlike the rest of Java, JDBC is not generally upwards compatible).
The source code in SVN is for the latest JDBC
, Jörg Schaible joerg.schai...@scalaris.com wrote:
sebb wrote:
DBCP is complicated to release, because the source has to be
pre-processed in order to build additional versions of the code.
(unlike the rest of Java, JDBC is not generally upwards compatible).
The source code in SVN
The current DBCP versioning scheme is a bit odd.
1.3.x is for JDBC 3
1.4.x is for JDBC 4
They have the same original code base, so 1.4 is not later than 1.3
It might make more sense to use Maven classifiers to distinguish the
different builds.
Then there would be a single release version
Le 04/06/2013 13:03, sebb a écrit :
Are you sure?
Sounds like a lot more work than what we have currently.
I like the idea. It's more work but the scope could be wider than DBCP.
I guess any project implementing JDBC classes could be interested by a
tool filtering JDBC methods and producing
Hi Sebb,
sebb wrote:
On 4 June 2013 11:16, Jörg Schaible joerg.schai...@scalaris.com wrote:
sebb wrote:
DBCP is complicated to release, because the source has to be
pre-processed in order to build additional versions of the code.
(unlike the rest of Java, JDBC is not generally upwards
On 6/4/13 4:10 AM, Emmanuel Bourg wrote:
Le 04/06/2013 13:03, sebb a écrit :
Are you sure?
Sounds like a lot more work than what we have currently.
I like the idea. It's more work but the scope could be wider than DBCP.
I guess any project implementing JDBC classes could be interested
On 6/4/13 2:29 AM, sebb wrote:
DBCP is complicated to release, because the source has to be
pre-processed in order to build additional versions of the code.
(unlike the rest of Java, JDBC is not generally upwards compatible).
The source code in SVN is for the latest JDBC version we support
On 6/4/13 3:16 AM, Jörg Schaible wrote:
sebb wrote:
DBCP is complicated to release, because the source has to be
pre-processed in order to build additional versions of the code.
(unlike the rest of Java, JDBC is not generally upwards compatible).
The source code in SVN is for the latest
Le 04/06/2013 15:45, Phil Steitz a écrit :
Such a tool would be useful if it could automatically generate
taggable sources. This is what the comment markers and ant filter
tasks in the current setup do.
I don't think a tool based on bytecode manipulation could produce the
corresponding
Hi Phil,
Phil Steitz wrote:
[snip]
For the release you can now activate the appropriate JDK profile, provide
the versions with the command line and possibly we can additionally add
an enforcer rule to avoid errors.
If maven can do the filtering to help create the source branches /
tags,
Le 04/06/2013 16:01, Phil Steitz a écrit :
Are you guys OK with me plowing forward with the setup I described
yesterday
+1
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands,
Emmanuel Bourg wrote:
Le 04/06/2013 15:45, Phil Steitz a écrit :
Such a tool would be useful if it could automatically generate
taggable sources. This is what the comment markers and ant filter
tasks in the current setup do.
I don't think a tool based on bytecode manipulation could
Le 04/06/2013 16:23, Jörg Schaible a écrit :
IMHO it is. If you do not have a matching -sources.jar, it will be
cumbersome to debug a problem for any client. Note, that the -sources.jar
would contain the filtered stuff, while the source distribution (-src.zip)
would contain the originals.
change, we are going to have to support the 1.x code
suitably hacked forward indefinitely. This is not a happy prospect;
but given how widely used DBCP is, we should do it. Given this, I
agree with your original proposal that we build in another layer of
filtering to the 1.x code base
will have to patch every
packaged software that depends on DBCP 1.x to use the new API until the
change is applied upstream (if ever it's applied). If the behavior of
the API changed they'll also have to endorse the responsibility for
testing their changes. That's worse than patching DBCP 1.x
with Java 7, the Debian/Fedora maintainers will have to patch every
packaged software that depends on DBCP 1.x to use the new API until the
change is applied upstream (if ever it's applied). If the behavior of
the API changed they'll also have to endorse the responsibility for
testing
code
suitably hacked forward indefinitely. This is not a happy prospect;
but given how widely used DBCP is, we should do it. Given this, I
agree with your original proposal that we build in another layer of
filtering to the 1.x code base, with the no-op patch merged in. I
will play
to compile DBCP 1.x with Java 7 because they can't support
Java 6 any longer.
Only because we have not yet released 2.0. If we focus on doing
that, their problem is solved. That was basically my point above.
Rather than hacking more compile filters so that 1.x can work for 3
different
On 27/05/2013 15:49, Phil Steitz wrote:
We need to make a decision on whether or not to change the contract
for PoolableConnection (or DelegatingConnection or PoolGuardWrapper)
isClosed. There are two changes suggested in DBCP-398:
1) Currently, isClosed returns true if the connection
Le 11/01/2013 08:36, Mark Thomas a écrit :
We could also add the JDBC 4.1 methods to DBCP1 but I'm not sure I like the
idea of three builds for that version.
I think we should do that. Debian and Fedora maintain a patch to be able
to build DBCP from source (see DBCP-385), but we should assume
a patch to be able
to build DBCP from source (see DBCP-385), but we should assume this burden.
I see 3 options, either:
1. Release DBCP 1.4.1 with no-op methods throwing a
SQLFeatureNotSupportedException or an UnsupportedOperationException.
This is what Fedora/Debian do.
That's fine with me
On 5/28/13 1:58 AM, Mark Thomas wrote:
On 27/05/2013 15:49, Phil Steitz wrote:
We need to make a decision on whether or not to change the contract
for PoolableConnection (or DelegatingConnection or PoolGuardWrapper)
isClosed. There are two changes suggested in DBCP-398:
1) Currently
On 5/28/13 3:58 AM, Emmanuel Bourg wrote:
Le 11/01/2013 08:36, Mark Thomas a écrit :
We could also add the JDBC 4.1 methods to DBCP1 but I'm not sure I like the
idea of three builds for that version.
I think we should do that. Debian and Fedora maintain a patch to be able
to build DBCP from
701 - 800 of 1661 matches
Mail list logo
