You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2009/11/25 01:23:33 UTC
[dbcp] 1.3 release packaging
The 1.3 release of dbcp will support JDK 1.4, 1.5 (JDBC 3) and 1.6
(JDBC 4). The Ant build in trunk will work with all three,
commenting out the JDBC 4 code when compiling under 1.4 or 1.5.
It does not appear to be possible to produce a single binary jar
which will work for both JDBC 3 and 4, so we are going to need to
package two different 1.3 release jars.
I would appreciate comments / better ideas on the following plan
1. Create a 1_3_JDBC3 branch copied from trunk
2. Remove the JDBC4 code from the 1_3_JDBC branch
3. Set the version identifier to 1.3-jdbc3 in the POM and Ant build
in the JDBC3 branch
4. Change the maven group id in the trunk POM to the maven standard
(org.apache.commons)
5. Create two full release distributions and tags (source, binary,
maven), one from trunk, using JDK 1.6 to build and package and one
from the JDBC3 branch.
6. Publish commons-pool-1.3-jdbc3.jar to
commons-dbcp/commons-dbcp/1.3-jdbc3
and commons-pool-1.3.jar to org/apache/commons/commons-dbcp/1.3
I would be OK adding jdbc4 to the JDBC 4 artifactId. The rationale
for leaving it as 1.3 and the sources in trunk is to signal that
this is the main development line. The rationale for separate
distros is that you end up with sources / tags / binaries all lined
up with simple reproducibility. Cutting a JDBC 3 branch leaves open
the possibility of future patch releases targeting JDBC 3.
The disadvantage of this approach is that given the large number of
changes and bugfixes in 1.3, there will almost certainly be patch
releases to follow and it will be a mild PITA to maintain fixes in
both branches.
I guess an alternative is to produce only one full distro, targeting
1.6 with 1.3 identifier and org.apache.commons groupID and then just
publish a "compatability jar" to commons-dbcp/commons-dbcp/1.3-jdbc3
compiled using 1.5. What I don't like about that is that there is
not a clean correspondence between a release tag and what gets
published (because of the source manipulation done by the Ant build).
Feedback / better ideas welcome.
Thanks!
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging
Posted by Paul Benedict <pb...@apache.org>.
JBoss Hibernate 3.5 is sitting in the same position because it has to
support both JDBC 3 and JDBC 4. There are obvious incompatibilities.
For their purposes, they created a general abstraction and then
allowed implementations to plug-in.
I would similarly follow suit. Produce separate assemblies such as:
commons-dbcp-1.3.jar (main)
commons-dbcp-jdbc3-1.3.jar (jdbc3 adapter)
commons-dbcp-jdbc4-1.3.jar (jdbc4 adapter)
Paul
On Tue, Nov 24, 2009 at 6:23 PM, Phil Steitz <ph...@gmail.com> wrote:
> The 1.3 release of dbcp will support JDK 1.4, 1.5 (JDBC 3) and 1.6
> (JDBC 4). The Ant build in trunk will work with all three,
> commenting out the JDBC 4 code when compiling under 1.4 or 1.5.
>
> It does not appear to be possible to produce a single binary jar
> which will work for both JDBC 3 and 4, so we are going to need to
> package two different 1.3 release jars.
>
> I would appreciate comments / better ideas on the following plan
>
> 1. Create a 1_3_JDBC3 branch copied from trunk
> 2. Remove the JDBC4 code from the 1_3_JDBC branch
> 3. Set the version identifier to 1.3-jdbc3 in the POM and Ant build
> in the JDBC3 branch
> 4. Change the maven group id in the trunk POM to the maven standard
> (org.apache.commons)
> 5. Create two full release distributions and tags (source, binary,
> maven), one from trunk, using JDK 1.6 to build and package and one
> from the JDBC3 branch.
> 6. Publish commons-pool-1.3-jdbc3.jar to
> commons-dbcp/commons-dbcp/1.3-jdbc3
> and commons-pool-1.3.jar to org/apache/commons/commons-dbcp/1.3
>
> I would be OK adding jdbc4 to the JDBC 4 artifactId. The rationale
> for leaving it as 1.3 and the sources in trunk is to signal that
> this is the main development line. The rationale for separate
> distros is that you end up with sources / tags / binaries all lined
> up with simple reproducibility. Cutting a JDBC 3 branch leaves open
> the possibility of future patch releases targeting JDBC 3.
>
> The disadvantage of this approach is that given the large number of
> changes and bugfixes in 1.3, there will almost certainly be patch
> releases to follow and it will be a mild PITA to maintain fixes in
> both branches.
>
> I guess an alternative is to produce only one full distro, targeting
> 1.6 with 1.3 identifier and org.apache.commons groupID and then just
> publish a "compatability jar" to commons-dbcp/commons-dbcp/1.3-jdbc3
> compiled using 1.5. What I don't like about that is that there is
> not a clean correspondence between a release tag and what gets
> published (because of the source manipulation done by the Ant build).
>
> Feedback / better ideas welcome.
>
> Thanks!
>
> Phil
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging
Posted by sebb <se...@gmail.com>.
On 25/11/2009, Phil Steitz <ph...@gmail.com> wrote:
> sebb wrote:
> > On 25/11/2009, Phil Steitz <ph...@gmail.com> wrote:
> >> The 1.3 release of dbcp will support JDK 1.4, 1.5 (JDBC 3) and 1.6
> >> (JDBC 4). The Ant build in trunk will work with all three,
> >> commenting out the JDBC 4 code when compiling under 1.4 or 1.5.
> >>
> >> It does not appear to be possible to produce a single binary jar
> >> which will work for both JDBC 3 and 4, so we are going to need to
> >> package two different 1.3 release jars.
> >>
> >> I would appreciate comments / better ideas on the following plan
> >>
> >> 1. Create a 1_3_JDBC3 branch copied from trunk
> >> 2. Remove the JDBC4 code from the 1_3_JDBC branch
> >> 3. Set the version identifier to 1.3-jdbc3 in the POM and Ant build
> >> in the JDBC3 branch
> >> 4. Change the maven group id in the trunk POM to the maven standard
> >> (org.apache.commons)
> >> 5. Create two full release distributions and tags (source, binary,
> >> maven), one from trunk, using JDK 1.6 to build and package and one
> >> from the JDBC3 branch.
> >> 6. Publish commons-pool-1.3-jdbc3.jar to
> >> commons-dbcp/commons-dbcp/1.3-jdbc3
> >> and commons-pool-1.3.jar to org/apache/commons/commons-dbcp/1.3
> >>
> >> I would be OK adding jdbc4 to the JDBC 4 artifactId. The rationale
> >> for leaving it as 1.3 and the sources in trunk is to signal that
> >> this is the main development line. The rationale for separate
> >> distros is that you end up with sources / tags / binaries all lined
> >> up with simple reproducibility. Cutting a JDBC 3 branch leaves open
> >> the possibility of future patch releases targeting JDBC 3.
> >>
> >> The disadvantage of this approach is that given the large number of
> >> changes and bugfixes in 1.3, there will almost certainly be patch
> >> releases to follow and it will be a mild PITA to maintain fixes in
> >> both branches.
> >>
> >> I guess an alternative is to produce only one full distro, targeting
> >> 1.6 with 1.3 identifier and org.apache.commons groupID and then just
> >> publish a "compatability jar" to commons-dbcp/commons-dbcp/1.3-jdbc3
> >> compiled using 1.5. What I don't like about that is that there is
> >> not a clean correspondence between a release tag and what gets
> >> published (because of the source manipulation done by the Ant build).
> >
> > I'm not sure the source manipulation really matters.
> > It's always possible to recreate the modified source from the release
> > tag by running the Ant build. I think one can regard that as part of
> > the compilation process.
> >
> > Anyway the modified source can be included in the appropriate source archive.
> >
> > I think having separate code branches is going to be a lot more work
> > for not much gain.
> >
> > The build process will need to be carefully documented, but that only
> > has to be done once.
>
>
> Thanks, Sebb. After sending I realized that my desire was really
> just to have a good tag, so in fact all I would need is separate
> tags - no need to branch. And you have made me feel better about
> even eliminating the separate tag and just publishing the
> "compatability jar" via documented process from the Ant build.
>
> Are you OK with the maven artifact names and locations?
Sorry, no idea if they are sensible or not.
>
> Phil
>
> >
> >> Feedback / better ideas welcome.
> >>
> >> Thanks!
> >>
> >> Phil
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging
Posted by Phil Steitz <ph...@gmail.com>.
sebb wrote:
> On 25/11/2009, Phil Steitz <ph...@gmail.com> wrote:
>> The 1.3 release of dbcp will support JDK 1.4, 1.5 (JDBC 3) and 1.6
>> (JDBC 4). The Ant build in trunk will work with all three,
>> commenting out the JDBC 4 code when compiling under 1.4 or 1.5.
>>
>> It does not appear to be possible to produce a single binary jar
>> which will work for both JDBC 3 and 4, so we are going to need to
>> package two different 1.3 release jars.
>>
>> I would appreciate comments / better ideas on the following plan
>>
>> 1. Create a 1_3_JDBC3 branch copied from trunk
>> 2. Remove the JDBC4 code from the 1_3_JDBC branch
>> 3. Set the version identifier to 1.3-jdbc3 in the POM and Ant build
>> in the JDBC3 branch
>> 4. Change the maven group id in the trunk POM to the maven standard
>> (org.apache.commons)
>> 5. Create two full release distributions and tags (source, binary,
>> maven), one from trunk, using JDK 1.6 to build and package and one
>> from the JDBC3 branch.
>> 6. Publish commons-pool-1.3-jdbc3.jar to
>> commons-dbcp/commons-dbcp/1.3-jdbc3
>> and commons-pool-1.3.jar to org/apache/commons/commons-dbcp/1.3
>>
>> I would be OK adding jdbc4 to the JDBC 4 artifactId. The rationale
>> for leaving it as 1.3 and the sources in trunk is to signal that
>> this is the main development line. The rationale for separate
>> distros is that you end up with sources / tags / binaries all lined
>> up with simple reproducibility. Cutting a JDBC 3 branch leaves open
>> the possibility of future patch releases targeting JDBC 3.
>>
>> The disadvantage of this approach is that given the large number of
>> changes and bugfixes in 1.3, there will almost certainly be patch
>> releases to follow and it will be a mild PITA to maintain fixes in
>> both branches.
>>
>> I guess an alternative is to produce only one full distro, targeting
>> 1.6 with 1.3 identifier and org.apache.commons groupID and then just
>> publish a "compatability jar" to commons-dbcp/commons-dbcp/1.3-jdbc3
>> compiled using 1.5. What I don't like about that is that there is
>> not a clean correspondence between a release tag and what gets
>> published (because of the source manipulation done by the Ant build).
>
> I'm not sure the source manipulation really matters.
> It's always possible to recreate the modified source from the release
> tag by running the Ant build. I think one can regard that as part of
> the compilation process.
>
> Anyway the modified source can be included in the appropriate source archive.
>
> I think having separate code branches is going to be a lot more work
> for not much gain.
>
> The build process will need to be carefully documented, but that only
> has to be done once.
Thanks, Sebb. After sending I realized that my desire was really
just to have a good tag, so in fact all I would need is separate
tags - no need to branch. And you have made me feel better about
even eliminating the separate tag and just publishing the
"compatability jar" via documented process from the Ant build.
Are you OK with the maven artifact names and locations?
Phil
>
>> Feedback / better ideas welcome.
>>
>> Thanks!
>>
>> Phil
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging
Posted by sebb <se...@gmail.com>.
On 25/11/2009, Phil Steitz <ph...@gmail.com> wrote:
> The 1.3 release of dbcp will support JDK 1.4, 1.5 (JDBC 3) and 1.6
> (JDBC 4). The Ant build in trunk will work with all three,
> commenting out the JDBC 4 code when compiling under 1.4 or 1.5.
>
> It does not appear to be possible to produce a single binary jar
> which will work for both JDBC 3 and 4, so we are going to need to
> package two different 1.3 release jars.
>
> I would appreciate comments / better ideas on the following plan
>
> 1. Create a 1_3_JDBC3 branch copied from trunk
> 2. Remove the JDBC4 code from the 1_3_JDBC branch
> 3. Set the version identifier to 1.3-jdbc3 in the POM and Ant build
> in the JDBC3 branch
> 4. Change the maven group id in the trunk POM to the maven standard
> (org.apache.commons)
> 5. Create two full release distributions and tags (source, binary,
> maven), one from trunk, using JDK 1.6 to build and package and one
> from the JDBC3 branch.
> 6. Publish commons-pool-1.3-jdbc3.jar to
> commons-dbcp/commons-dbcp/1.3-jdbc3
> and commons-pool-1.3.jar to org/apache/commons/commons-dbcp/1.3
>
> I would be OK adding jdbc4 to the JDBC 4 artifactId. The rationale
> for leaving it as 1.3 and the sources in trunk is to signal that
> this is the main development line. The rationale for separate
> distros is that you end up with sources / tags / binaries all lined
> up with simple reproducibility. Cutting a JDBC 3 branch leaves open
> the possibility of future patch releases targeting JDBC 3.
>
> The disadvantage of this approach is that given the large number of
> changes and bugfixes in 1.3, there will almost certainly be patch
> releases to follow and it will be a mild PITA to maintain fixes in
> both branches.
>
> I guess an alternative is to produce only one full distro, targeting
> 1.6 with 1.3 identifier and org.apache.commons groupID and then just
> publish a "compatability jar" to commons-dbcp/commons-dbcp/1.3-jdbc3
> compiled using 1.5. What I don't like about that is that there is
> not a clean correspondence between a release tag and what gets
> published (because of the source manipulation done by the Ant build).
I'm not sure the source manipulation really matters.
It's always possible to recreate the modified source from the release
tag by running the Ant build. I think one can regard that as part of
the compilation process.
Anyway the modified source can be included in the appropriate source archive.
I think having separate code branches is going to be a lot more work
for not much gain.
The build process will need to be carefully documented, but that only
has to be done once.
> Feedback / better ideas welcome.
>
> Thanks!
>
> Phil
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org