Thread: JDBC 3.0 / JDK 1.4 build issues

JDBC 3.0 / JDK 1.4 build issues

From
"Rene Pijlman"
Date:
I'm working on a patch which enables the driver to compile with JDBC 3.0 /
JDK 1.4 (currently beta-3). Basically we need to add a few methods and throw
"not implemented" in most of them.

Unfortunately, when the driver is modified to compile with JDK 1.4, it won't
compile with JDK 1.3 and older. There are at least two reasons for this:

1) Connection must implement the new method setSavePoint(), which returns a
new type java.sql.Savepoint

See:
http://java.sun.com/j2se/1.4/docs/api/java/sql/Connection.html#setSavepoint(
)
http://java.sun.com/j2se/1.4/docs/api/java/sql/Savepoint.html

2) PreparedStatement must implement the new method getParameterMetaData(),
which returns a new type java.sql.ParameterMetaData

See:
http://java.sun.com/j2se/1.4/docs/api/java/sql/PreparedStatement.html#getPar
ameterMetaData()
http://java.sun.com/j2se/1.4/docs/api/java/sql/ParameterMetaData.html

I think its very undesirable to fork the entire jdbc2 driver, just to be
able to add a couple of methods which throw "not implemented". In fact, I
find the current situation with jdbc1/jdbc2 too cumbersome already. It seems
the only alternative is some sort of conditional compilation using make or
ant. Any ideas?

In case someone wants to have a look, I've attached a patch which makes the
driver in current CVS compile with JDK 1.4b3. With this patch applied, the
driver _won't_ compile with JDK 1.3.x and older. Use at own risk :-)

Cheers,
René Pijlman <rene@lab.applinet.nl>

Attachment

Re: JDBC 3.0 / JDK 1.4 build issues

From
Ned Wolpert
Date:
--- Rene Pijlman <rene@lab.applinet.nl> wrote:
> Unfortunately, when the driver is modified to compile with JDK 1.4, it
> won't compile with JDK 1.3 and older. There are at least two reasons for
> this:
>
> 1) Connection must implement the new method setSavePoint(), which
> returns a > new type java.sql.Savepoint

Hm.... if we cannot reuse the org.postgresql.Connection abstract class,
then won't we need to have a org.postgresql.jdbc3.Connection class that
extends org.postgresql.jdbc2.Connection?  Then will have to have the
Driver return the jdbc3 Connection when its called.  Won't that work?
(We may not need much more ant-processing since it still called
java.sql.Connection.)  It does seem similiar to jdbc1 -> jdbc2 issues.
(See end of email for more on this...)

> 2) PreparedStatement must implement the new method
> getParameterMetaData(), which returns a new type
> java.sql.ParameterMetaData

Same thing here. Getting a PreparedStatement comming from the jdbc3
Connection would return this.  Also, we'll need a new CallableStatement
since it extends PreparedStatement. Our new callable one needs to
extend the jdbc3 one.

> I think its very undesirable to fork the entire jdbc2 driver, just to be

I agree. I don't think we have to.  But if we compile with jdk1.4, we
cannot compile the jdbc2 or jdbc1 stuff.  That's the only real issue to
me, so far.  Though this is kinda distressing since Sun could have
easilly made a java.sql.jdbc3.Connection internface themselves that
would implement the new method.  This means that our current driver cannot

compile at all in jdk1.4.  Is that correct?  That sucks.

=====
Virtually,        |                   "Must you shout too?"
Ned Wolpert       |                                  -Dante
wolpert@yahoo.com |
_________________/              "Who watches the watchmen?"
4e75                                       -Juvenal, 120 AD

-- Place your commercial here --                      fnord

__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

Re: JDBC 3.0 / JDK 1.4 build issues

From
Ned Wolpert
Date:
--- Rene Pijlman <rene@lab.applinet.nl> wrote:
> Unfortunately, when the driver is modified to compile with JDK 1.4, it
> won't compile with JDK 1.3 and older. There are at least two reasons for
> this:
>
> 1) Connection must implement the new method setSavePoint(), which
> returns a
> new type java.sql.Savepoint

Hm.... if we cannot reuse the org.postgresql.Connection abstract class,
then won't we need to have a org.postgresql.jdbc3.Connection class that
extends org.postgresql.jdbc2.Connection?  Then will have to have the
Driver return the jdbc3 Connection when its called.  Won't that work?
(We may not need much more ant-processing since it still called
java.sql.Connection.)  It does seem similiar to jdbc1 -> jdbc2 issues.
(See end of email for more on this...)

> 2) PreparedStatement must implement the new method
> getParameterMetaData(), which returns a new type
> java.sql.ParameterMetaData

Same thing here. Getting a PreparedStatement comming from the jdbc3
Connection would return this.  Also, we'll need a new CallableStatement
since it extends PreparedStatement. Our new callable one needs to
extend the jdbc3 one.

> I think its very undesirable to fork the entire jdbc2 driver, just to be

I agree. I don't think we have to.  But if we compile with jdk1.4, we
cannot compile the jdbc2 or jdbc1 stuff.  That's the only real issue to
me, so far.  Though this is kinda distressing since Sun could have
easilly made a java.sql.jdbc3.Connection internface themselves that
would implement the new method.  This means that our current driver cannot

compile at all in jdk1.4.  Is that correct?  That sucks.

=====
Virtually,        |                   "Must you shout too?"
Ned Wolpert       |                                  -Dante
wolpert@yahoo.com |
_________________/              "Who watches the watchmen?"
4e75                                       -Juvenal, 120 AD

-- Place your commercial here --                      fnord

__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

Re: JDBC 3.0 / JDK 1.4 build issues

From
Rene Pijlman
Date:
On Sat, 8 Dec 2001 18:31:51 -0800 (PST), you wrote:
>Hm.... if we cannot reuse the org.postgresql.Connection abstract class,
>then won't we need to have a org.postgresql.jdbc3.Connection class that
>extends org.postgresql.jdbc2.Connection?  Then will have to have the
>Driver return the jdbc3 Connection when its called.  Won't that work?
>(We may not need much more ant-processing since it still called
>java.sql.Connection.)  It does seem similiar to jdbc1 -> jdbc2 issues.

OK, that may do the trick. But why is for example
jdbc2/DatabaseMetaData.java a copy of
jdbc1/DatabaseMetaData.java? Why isn't this done with
inheritance to only add new methods in jdbc2?

It seems to be the same for PreparedStatement, ResultSet etc. I
see lots of duplicate code. Or am I missing something?

>This means that our current driver cannot compile at all in jdk1.4.

Indeed. Some interfaces require new methods. And some of these
methods require types which are only available in the new
version of the interfaces.

Regards,
René Pijlman <rene@lab.applinet.nl>

Re: JDBC 3.0 / JDK 1.4 build issues

From
Rene Pijlman
Date:
On Sat, 8 Dec 2001 18:31:51 -0800 (PST), you wrote:
>Hm.... if we cannot reuse the org.postgresql.Connection abstract class,
>then won't we need to have a org.postgresql.jdbc3.Connection class that
>extends org.postgresql.jdbc2.Connection?  Then will have to have the
>Driver return the jdbc3 Connection when its called.  Won't that work?

Hangon, what would the definition of
org.postgresql.jdbc2.Connection be in the new situation with
jdbc3 classes inheriting from jdbc2 classes?

It would still be:

   package org.postgresql.jdbc2;
   public class Connection extends org.postgresql.Connection
   implements java.sql.Connection

Right?

And that class won't compile with JDK 1.4 since it lacks new
methods like setHoldability() of the java.sql.Connection
interface. This raises a compile time error "class should be
declared abstract...".

And if we change the definition of this class to not implement
java.sql.Connection, then the same code won't produce a proper
implementation of JDBC2 with a JDK <= 1.3.

I think there's a conceptual flaw in this scheme. Version 3 of
the JDBC interfaces don't extend the version 2 interfaces, so I
don't think we can solve it by letting jdbc3 classes extend
jdbc2 classes.

Regards,
René Pijlman <rene@lab.applinet.nl>

Re: JDBC 3.0 / JDK 1.4 build issues

From
Ned Wolpert
Date:
--- Rene Pijlman <rene@lab.applinet.nl> wrote:
> On Sat, 8 Dec 2001 18:31:51 -0800 (PST), you wrote:
> >Hm.... if we cannot reuse the org.postgresql.Connection abstract class,
> >then won't we need to have a org.postgresql.jdbc3.Connection class that
> >extends org.postgresql.jdbc2.Connection?  Then will have to have the
> >Driver return the jdbc3 Connection when its called.  Won't that work?
>
> Hangon, what would the definition of
> org.postgresql.jdbc2.Connection be in the new situation with
> jdbc3 classes inheriting from jdbc2 classes?


Oh yeah. That's right.  Since org.postgresql.jdbc2.Connection is a
'complete' implementation of java.sql.Conenction, it cannot compile
cleanly with jdk1.4.  So, one cannot inherit from the jdbc2.Connection
object.  It has to be a clean jdbc3 Connection.  Ugh.

> I think there's a conceptual flaw in this scheme. Version 3 of
> the JDBC interfaces don't extend the version 2 interfaces, so I
> don't think we can solve it by letting jdbc3 classes extend
> jdbc2 classes.

True.  But I think its only affects Connection, PrepareredStatement
and CallableStatement.  (Which still sucks)  It means if that the ant
build script detected jdk1.4, it  must not attempt to build and jdbc1
classes, and only classes outside of those three in the jdbc2 directory.
Either that or the classes in jdbc3 dir is a true 'fork' of the existing
classes.  Personally, I would like to see the jdbc3 dir, and the classes
would extend jdbc2 classes _when_ possible.  The three mentioned would
have to be forked, but the others are saved.

So, we're left with two options.  The build process is about to get
'more' ugly as we go into the jdbc3 process.  If we fork, the build
process is 'as ugly' as it currently is, but we will then have a forked
code set.  (And in both cases, we still have the ant vs. make discussion
to solve)  thoughts?  Ideas on how can simplify this so jdbc4 doesn't
do this to us again? (Or is this accecptable/normal situation?)

=====
Virtually,        |                   "Must you shout too?"
Ned Wolpert       |                                  -Dante
wolpert@yahoo.com |
_________________/              "Who watches the watchmen?"
4e75                                       -Juvenal, 120 AD

-- Place your commercial here --                      fnord

__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

Re: JDBC 3.0 / JDK 1.4 build issues

From
Ned Wolpert
Date:
--- Rene Pijlman <rene@lab.applinet.nl> wrote:
> OK, that may do the trick. But why is for example
> jdbc2/DatabaseMetaData.java a copy of
> jdbc1/DatabaseMetaData.java? Why isn't this done with
> inheritance to only add new methods in jdbc2?
>
> It seems to be the same for PreparedStatement, ResultSet etc. I
> see lots of duplicate code. Or am I missing something?

We may have more duplicated code then desired.  I can't explain about the
DatabaseMetaData stuff, if it could have been inherited or had to be
'forked'.  I'm sure that going from jdbc1 -> jdbc2 some classes could not
be inherited, like the case of the Connection class in jdbc3.  But if all
those classes didn't need to be forked for jdbc1->jdbc2, perhaps it was
done to simplify making changes.  (making jdbc2 changes, that is.)  Of
course, by doing this we have a problem of making changes in both
packages when a new bug is found.  This is why I like inheritance when
possible, versus forking.



=====
Virtually,        |                   "Must you shout too?"
Ned Wolpert       |                                  -Dante
wolpert@yahoo.com |
_________________/              "Who watches the watchmen?"
4e75                                       -Juvenal, 120 AD

-- Place your commercial here --                      fnord

__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

Re: JDBC 3.0 / JDK 1.4 build issues

From
Rene Pijlman
Date:
On Sun, 9 Dec 2001 07:14:01 -0800 (PST), you wrote:
>Oh yeah. That's right.  Since org.postgresql.jdbc2.Connection is a
>'complete' implementation of java.sql.Conenction, it cannot compile
>cleanly with jdk1.4.  So, one cannot inherit from the jdbc2.Connection
>object.  It has to be a clean jdbc3 Connection.  Ugh.

And how about this code reorganization scheme?

org/postgresql/Connection.java
package org.postgresql;
public abstract class Connection
// Contains code that is common to jdbc1, jdbc2 and jdbc3

org/postgresql/Connection2.java
package org.postgresql;
public abstract class Connection2
extends org.postgresql.Connection
// Contains code that is common to jdbc2 and jdbc3,
// but cannot compile with jdbc1

    org/postgresql/jdbc1/Connection.java
    package org.postgresql.jdbc1;
    public class Connection
    extends org.postgresql.Connection
    implements java.sql.Connection
    // ant: only compiled when JDBC1
    // Contains code that is valid only for jdbc1

    org/postgresql/jdbc2/Connection.java
    package org.postgresql.jdbc2;
    public class Connection
    extends org.postgresql.Connection2
    implements java.sql.Connection
    // ant: only compiled when JDBC2
    // Contains code that is valid only for jdbc2

    org/postgresql/jdbc3/Connection.java
    package org.postgresql.jdbc3;
    public class Connection
    extends org.postgresql.Connection2
    implements java.sql.Connection
    // ant: only compiled when JDBC3
    // Contains code that is valid only for jdbc3

Perhaps Connection2.java should go in the jdbc2 package.

I'll see if I can get this to work with 1.3/1.4.

>(And in both cases, we still have the ant vs. make discussion
>to solve) thoughts? Ideas on how can simplify this so jdbc4 doesn't
>do this to us again? (Or is this accecptable/normal situation?)

Another interesting idea is to build all versions of the driver
into one .jar file and choose the right classes at runtime
(using reflection in JDK >= 1.1). This would reduce the number
of driver versions we have to distribute and would make
deployment easier. Building the driver this way would be more
complicated though, since it requires all JDK versions to be
available on the build platform. Just a thought :-)

Regards,
René Pijlman <rene@lab.applinet.nl>

Re: JDBC 3.0 / JDK 1.4 build issues

From
Barry Lind
Date:
Rene,

I think you have the right idea here.  I might suggest that you have an
abstract Connection3 to make things consistent.  The only hard part is
to make sure that right classes get built for each driver version.

thanks,
--Barry



Rene Pijlman wrote:

 > On Sun, 9 Dec 2001 07:14:01 -0800 (PST), you wrote:
 >
 >>Oh yeah. That's right.  Since org.postgresql.jdbc2.Connection is a
 >>'complete' implementation of java.sql.Conenction, it cannot compile
 >>cleanly with jdk1.4.  So, one cannot inherit from the jdbc2.Connection
 >>object.  It has to be a clean jdbc3 Connection.  Ugh.
 >>
 >
 > And how about this code reorganization scheme?
 >
 > org/postgresql/Connection.java
 > package org.postgresql;
 > public abstract class Connection
 > // Contains code that is common to jdbc1, jdbc2 and jdbc3
 >
 > org/postgresql/Connection2.java
 > package org.postgresql;
 > public abstract class Connection2
 > extends org.postgresql.Connection
 > // Contains code that is common to jdbc2 and jdbc3,
 > // but cannot compile with jdbc1
 >
 >     org/postgresql/jdbc1/Connection.java
 >     package org.postgresql.jdbc1;
 >     public class Connection
 >     extends org.postgresql.Connection
 >     implements java.sql.Connection
 >     // ant: only compiled when JDBC1
 >     // Contains code that is valid only for jdbc1
 >
 >     org/postgresql/jdbc2/Connection.java
 >     package org.postgresql.jdbc2;
 >     public class Connection
 >     extends org.postgresql.Connection2
 >     implements java.sql.Connection
 >     // ant: only compiled when JDBC2
 >     // Contains code that is valid only for jdbc2
 >
 >     org/postgresql/jdbc3/Connection.java
 >     package org.postgresql.jdbc3;
 >     public class Connection
 >     extends org.postgresql.Connection2
 >     implements java.sql.Connection
 >     // ant: only compiled when JDBC3
 >     // Contains code that is valid only for jdbc3
 >
 > Perhaps Connection2.java should go in the jdbc2 package.
 >
 > I'll see if I can get this to work with 1.3/1.4.
 >
 >
 >>(And in both cases, we still have the ant vs. make discussion
 >>to solve) thoughts? Ideas on how can simplify this so jdbc4 doesn't
 >>do this to us again? (Or is this accecptable/normal situation?)
 >>
 >
 > Another interesting idea is to build all versions of the driver
 > into one .jar file and choose the right classes at runtime
 > (using reflection in JDK >= 1.1). This would reduce the number
 > of driver versions we have to distribute and would make
 > deployment easier. Building the driver this way would be more
 > complicated though, since it requires all JDK versions to be
 > available on the build platform. Just a thought :-)
 >
 > Regards,
 > René Pijlman <rene@lab.applinet.nl>
 >
 > ---------------------------(end of broadcast)---------------------------
 > TIP 6: Have you searched our list archives?
 >
 > http://archives.postgresql.org
 >
 >




Re: JDBC 3.0 / JDK 1.4 build issues

From
p@netoides.com
Date:
Hello.

This idea only works if jdbc2.0 is a subset of jdbc3.0:
trying to put all jdbc 3.0 functionality in the jdbc 2.0 driver.
The only reason why a jdbc3.0 driver doesn't work with jdbc2.0
is because jdbc2.0 lacks some interfaces/classes.
But we could put this extra classes in a postgresql-2.0path.jar
This way, there would be only one driver (postgresql.jar for jdbc3.0)
and a patch for 2.0 with all the extra interfaces/classes/exceptions
in jdbc3.0.

Barry Lind wrote:
>
> Rene,
>
> I think you have the right idea here.  I might suggest that you have an
> abstract Connection3 to make things consistent.  The only hard part is
> to make sure that right classes get built for each driver version.
>
> thanks,
> --Barry
>
> Rene Pijlman wrote:
>
>  > On Sun, 9 Dec 2001 07:14:01 -0800 (PST), you wrote:
>  >
>  >>Oh yeah. That's right.  Since org.postgresql.jdbc2.Connection is a
>  >>'complete' implementation of java.sql.Conenction, it cannot compile
>  >>cleanly with jdk1.4.  So, one cannot inherit from the jdbc2.Connection
>  >>object.  It has to be a clean jdbc3 Connection.  Ugh.
>  >>
>  >
>  > And how about this code reorganization scheme?
>  >
>  > org/postgresql/Connection.java
>  > package org.postgresql;
>  > public abstract class Connection
>  > // Contains code that is common to jdbc1, jdbc2 and jdbc3
>  >
>  > org/postgresql/Connection2.java
>  > package org.postgresql;
>  > public abstract class Connection2
>  > extends org.postgresql.Connection
>  > // Contains code that is common to jdbc2 and jdbc3,
>  > // but cannot compile with jdbc1
>  >
>  >     org/postgresql/jdbc1/Connection.java
>  >     package org.postgresql.jdbc1;
>  >     public class Connection
>  >     extends org.postgresql.Connection
>  >     implements java.sql.Connection
>  >     // ant: only compiled when JDBC1
>  >     // Contains code that is valid only for jdbc1
>  >
>  >     org/postgresql/jdbc2/Connection.java
>  >     package org.postgresql.jdbc2;
>  >     public class Connection
>  >     extends org.postgresql.Connection2
>  >     implements java.sql.Connection
>  >     // ant: only compiled when JDBC2
>  >     // Contains code that is valid only for jdbc2
>  >
>  >     org/postgresql/jdbc3/Connection.java
>  >     package org.postgresql.jdbc3;
>  >     public class Connection
>  >     extends org.postgresql.Connection2
>  >     implements java.sql.Connection
>  >     // ant: only compiled when JDBC3
>  >     // Contains code that is valid only for jdbc3
>  >
>  > Perhaps Connection2.java should go in the jdbc2 package.
>  >
>  > I'll see if I can get this to work with 1.3/1.4.
>  >
>  >
>  >>(And in both cases, we still have the ant vs. make discussion
>  >>to solve) thoughts? Ideas on how can simplify this so jdbc4 doesn't
>  >>do this to us again? (Or is this accecptable/normal situation?)
>  >>
>  >
>  > Another interesting idea is to build all versions of the driver
>  > into one .jar file and choose the right classes at runtime
>  > (using reflection in JDK >= 1.1). This would reduce the number
>  > of driver versions we have to distribute and would make
>  > deployment easier. Building the driver this way would be more
>  > complicated though, since it requires all JDK versions to be
>  > available on the build platform. Just a thought :-)
>  >
>  > Regards,
>  > René Pijlman <rene@lab.applinet.nl>
>  >
>  > ---------------------------(end of broadcast)---------------------------
>  > TIP 6: Have you searched our list archives?
>  >
>  > http://archives.postgresql.org
>  >
>  >
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Re: JDBC 3.0 / JDK 1.4 build issues

From
Rene Pijlman
Date:
On Mon, 10 Dec 2001 21:18:27 -0800, you wrote:
>The only hard part is to make sure that right classes
>get built for each driver version.

I didn't follow the make vs. ant discussion very closely. Did it
reach a conclusion or some sort of consensus on the preferred
build tool?

Regards,
René Pijlman <rene@lab.applinet.nl>

Re: JDBC 3.0 / JDK 1.4 build issues

From
"Dave Cramer"
Date:
Rene,

We are going to support both for now.

Dave

-----Original Message-----
From: pgsql-jdbc-owner@postgresql.org
[mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Rene Pijlman
Sent: Friday, December 14, 2001 12:25 PM
To: Barry Lind
Cc: pgsql-jdbc@postgresql.org
Subject: Re: [JDBC] JDBC 3.0 / JDK 1.4 build issues


On Mon, 10 Dec 2001 21:18:27 -0800, you wrote:
>The only hard part is to make sure that right classes
>get built for each driver version.

I didn't follow the make vs. ant discussion very closely. Did it reach a
conclusion or some sort of consensus on the preferred build tool?

Regards,
René Pijlman <rene@lab.applinet.nl>

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: JDBC 3.0 / JDK 1.4 build issues

From
Bruce Momjian
Date:
> Rene,
>
> We are going to support both for now.

Right now we support only Ant, not Make, right?

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Re: JDBC 3.0 / JDK 1.4 build issues

From
"Dave Cramer"
Date:
Well sort of...
We are using make to start ant, but we are using the ant build file to
build the jars

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Saturday, December 15, 2001 1:01 PM
To: Dave@micro-automation.net
Cc: 'Rene Pijlman'; 'Barry Lind'; pgsql-jdbc@postgresql.org
Subject: Re: [JDBC] JDBC 3.0 / JDK 1.4 build issues


> Rene,
>
> We are going to support both for now.

Right now we support only Ant, not Make, right?

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania
19026



Re: JDBC 3.0 / JDK 1.4 build issues

From
Rene Pijlman
Date:
On Sat, 15 Dec 2001 15:16:49 -0500, you wrote:
>Well sort of...
>We are using make to start ant, but we are using the ant
>build file to build the jars

But is the plan to also enable building the driver without ant
installed?

Regards,
René Pijlman <rene@lab.applinet.nl>

Re: JDBC 3.0 / JDK 1.4 build issues

From
Bruce Momjian
Date:
> On Sat, 15 Dec 2001 15:16:49 -0500, you wrote:
> >Well sort of...
> >We are using make to start ant, but we are using the ant
> >build file to build the jars
>
> But is the plan to also enable building the driver without ant
> installed?

That is what has me confused about allowing both Ant and Make.  I guess
he was just saying we stay with our current make calls ant setup.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Re: JDBC 3.0 / JDK 1.4 build issues

From
Barry Lind
Date:
Rene,

Dave and I exchanged a few emails on this a while back, and I think what
we decided on was that we would support both make and ant independently
in 7.3.  That means two independant methods of building the code,
makefiles that don't depend on ant, and ant that doesn't depend on make
calling it.  Both build mechanisms have their pros and cons as was born
out in the long email thread on this topic a few weeks ago.  I agreed to
work on/support the make build method and Dave agreed to support the ant
one.

thanks,
--Barry




Rene Pijlman wrote:

> On Sat, 15 Dec 2001 15:16:49 -0500, you wrote:
>
>>Well sort of...
>>We are using make to start ant, but we are using the ant
>>build file to build the jars
>>
>
> But is the plan to also enable building the driver without ant
> installed?
>
> Regards,
> René Pijlman <rene@lab.applinet.nl>
>



Re: JDBC 3.0 / JDK 1.4 build issues

From
Bruce Momjian
Date:
Barry Lind wrote:
> Rene,
>
> Dave and I exchanged a few emails on this a while back, and I think what
> we decided on was that we would support both make and ant independently
> in 7.3.  That means two independant methods of building the code,
> makefiles that don't depend on ant, and ant that doesn't depend on make
> calling it.  Both build mechanisms have their pros and cons as was born
> out in the long email thread on this topic a few weeks ago.  I agreed to
> work on/support the make build method and Dave agreed to support the ant
> one.

TODO updated:

    JDBC
            o Support both 'make' and 'ant'

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Re: JDBC 3.0 / JDK 1.4 build issues

From
Rene Pijlman
Date:
On Thu, 3 Jan 2002 00:48:05 -0500 (EST), you wrote:
>TODO updated:
>
>    JDBC
>            o Support both 'make' and 'ant'

You may want to add "Support build with JDK 1.4 / JDBC 3.0
(without code duplication)". I'm still working on it.

Regards,
René Pijlman <rene@lab.applinet.nl>