[Pljava-dev] Working on 1.4 beta release

Now that the move to pgfoundry is complete we can focus on the 1.4
release. I think now's a good time to put out a beta and see if we can
get some people to test it. There's a couple of questions I have:

1) What server versions to support? I was thinking of building binary
releases for 8.1 -> 8.3 for win32, linux-i386, linux-amd64, and perhaps
solaris-i386 as those are the platforms I have access to.

2) What options should the server be built with? Since pljava picks up
these options via PGXS, the server configuration will affect the pljava
builds. Shoule --enable-debug be used? On a related note, should we try
to build the java code with -g if we find --enable-debug?

3) What should be done with the docs in CVS that go into the release? They
overlap the wiki greatly, and I have no desire to duplicate that work, but
I don't think we can drop them entirely without doing some merging work.
What's the minimal amount of information that we can put into the
releases? Should we make an architecture independent doc release or do
the docs depend on the server version built against?

Kris Jurka

Kris Jurka wrote:
> Now that the move to pgfoundry is complete we can focus on the 1.4
> release. I think now's a good time to put out a beta and see if we can
> get some people to test it. There's a couple of questions I have:
>
> 1) What server versions to support? I was thinking of building binary
> releases for 8.1 -> 8.3 for win32, linux-i386, linux-amd64, and perhaps
> solaris-i386 as those are the platforms I have access to.
>
>
Personally, I think this is fairly ambitious for the PL/Java project. My
take historically has been to provide win32 and linux-x86 only since I
don't see the PL/Java project as a binary distributor. The permutations
tend to grow and the task of maintaining all of them becomes significant.

A win32 binary is important because it requires a build environment that
is less then intuitive to obtain and install correctly. For most other
variants, I think a good instruction on how to build the binary is more
important.

> 2) What options should the server be built with? Since pljava picks up
> these options via PGXS, the server configuration will affect the pljava
> builds. Shoule --enable-debug be used? On a related note, should we try
> to build the java code with -g if we find --enable-debug?
>
>
Whan a crash occurs, the JVM will make an attempt to walk the stack and
it usually prints out a fairly decent stack trace. So my vote would be
to keep it in there. There has been several occasions where I've been
able to do more then just qualified guessing based on that information.

> 3) What should be done with the docs in CVS that go into the release? They
> overlap the wiki greatly, and I have no desire to duplicate that work, but
> I don't think we can drop them entirely without doing some merging work.
> What's the minimal amount of information that we can put into the
> releases? Should we make an architecture independent doc release or do
> the docs depend on the server version built against?
>
>
Ideally, all documentation should be kept in the CVS together with the
source at some point. The use of the wiki for documenting was more an
attempt to get collaboration going. It didn't happen. At some point I
think all docs should be moved over and the wiki should point to some
place where the doc is mirrored from the CVS but I don't think this need
to happen for the 1.4 release.

I think a lot would be gained if a new 1.4 source bundle was made
available together with binaries for win32 and linux x86 for PostgreSQL
versions 8.2 and 8.3. That's the really important thing IMO.

Kind Regards,
Thomas Hallgren

On Nov 19, 2007 12:45 PM, Thomas Hallgren <thomas at tada.se> wrote:
> Kris Jurka wrote:
> > 1) What server versions to support? I was thinking of building binary
> > releases for 8.1 -> 8.3 for win32, linux-i386, linux-amd64, and perhaps
> > solaris-i386 as those are the platforms I have access to.
> >
> Personally, I think this is fairly ambitious for the PL/Java project. My
> take historically has been to provide win32 and linux-x86 only since I
> don't see the PL/Java project as a binary distributor.

Uh, if not us, then who? PL/Java is really cool technology that is
something of a pain to get to the point where you can actually use it
(esp on win32). Let's not compare with the built-in PLs. And yet I
really don't think there's anything that really *requires* it being so
fiddly.

I would really like to see, ideally, PL/Java installable by
yum/apt-get/pkg-get etc on unix-like systems. I think there's a bit of
work to do to get there, but it's not impossible. But I'll leave
discussion on that for another thread.

> The permutations tend to grow and the task of maintaining all of them becomes significant.

Well, there are three variables, right? Postgres version, JVM version
and operating system/architecture, which I'll just call "platform".
I'm pretty sure I was able to compile pljava against a 1.5 JDK and run
it against a 1.6 one. So I don't think we should need to build it for
more than one JVM. The architectures that Kris mentioned sound good to
me, although I'd like to see Solaris/sparc in there as well if
possible (although like Kris, I don't have access to a sparc machine
atm), and perhaps MacOSX/x86 (since I've got a Macbook :) ). The
question then becomes: which pgsql versions do we want to support?
8.1-8.3?

I have a build script that can build pljava, run the test suite and
spit out binaries. It works (well I've tested it) on win32,
solaris/x86 and linux/x86. I'd be more than happy to build binaries
for all of those postgres versions for those platforms.

> A win32 binary is important because it requires a build environment that
> is less then intuitive to obtain and install correctly. For most other
> variants, I think a good instruction on how to build the binary is more
> important.

I agree that good docco on how to build the binaries is necessary, but
I definitely think we should be building binaries for common
platforms.

> > 2) What options should the server be built with? Since pljava picks up
> > these options via PGXS, the server configuration will affect the pljava
> > builds. Shoule --enable-debug be used? On a related note, should we try
> > to build the java code with -g if we find --enable-debug?

Build java code with -g, but pljava c code without debugging symbols I
reckon. If someone wants to debug pljava C code, they can build it
themselves. :)

> Ideally, all documentation should be kept in the CVS together with the
> source at some point. The use of the wiki for documenting was more an
> attempt to get collaboration going. It didn't happen. At some point I
> think all docs should be moved over and the wiki should point to some
> place where the doc is mirrored from the CVS but I don't think this need
> to happen for the 1.4 release.

I have some free time over the next few weeks, so I can have a go at
getting the wiki docs into some kind of source control. What source
format do we want? HTML? Docbook a la the main distribution? HTML
would obviously require less effort at build time, so I would probably
vote for it just on those grounds...

Cheers

Tom

Tom Dunstan wrote:
> Uh, if not us, then who? PL/Java is really cool technology that is
> something of a pain to get to the point where you can actually use it
> (esp on win32). Let's not compare with the built-in PLs. And yet I
> really don't think there's anything that really *requires* it being so
> fiddly.
>
> I would really like to see, ideally, PL/Java installable by
> yum/apt-get/pkg-get etc on unix-like systems. I think there's a bit of
> work to do to get there, but it's not impossible. But I'll leave
> discussion on that for another thread.
>
>
Tom, don't get me wrong. I'm of course all for this. I'm just afraid
that the burden of creating a new release will become so heavy that it
will have a negative impact on the number of releases that will come out.

>
> ...
> I'm pretty sure I was able to compile pljava against a 1.5 JDK and run
> it against a 1.6 one. So I don't think we should need to build it for
> more than one JVM.
That's assuming that we don't want to support GCJ. That's equal to
adding a requirement to install a JVM.

> The architectures that Kris mentioned sound good to
> me, although I'd like to see Solaris/sparc in there as well if
> possible (although like Kris, I don't have access to a sparc machine
> atm), and perhaps MacOSX/x86 (since I've got a Macbook :) ). The
> question then becomes: which pgsql versions do we want to support?
> 8.1-8.3?
>
>
Perhaps an idea would be to provide binary support for the latest, or
the latest two? I.e. if you want older, build your own?

> I have a build script that can build pljava, run the test suite and
> spit out binaries. It works (well I've tested it) on win32,
> solaris/x86 and linux/x86. I'd be more than happy to build binaries
> for all of those postgres versions for those platforms.
>
>
Great! Would you like to be added to the project so that you can upload
files there?

> Build java code with -g, but pljava c code without debugging symbols I
> reckon. If someone wants to debug pljava C code, they can build it
> themselves. :)
>
>
Well, it's not so much about debugging really. It's more the information
you can get once something is crashing. As I mentioned, the JVM prints a
stack trace that can be very useful. Much is gained if the user who
experiences a crash can provide the JVM dump file in a bug-report or
attach it to a mailing list posting.

>
> I have some free time over the next few weeks, so I can have a go at
> getting the wiki docs into some kind of source control.
Awesome.

> What source format do we want? HTML? Docbook a la the main distribution? HTML
> would obviously require less effort at build time, so I would probably
> vote for it just on those grounds...
>
>
+1 for html.

Regards,
Thomas Hallgren

On Tue, 20 Nov 2007, Thomas Hallgren wrote:

> Perhaps an idea would be to provide binary support for the latest, or
> the latest two? I.e. if you want older, build your own?
>

In general this is reasonable, but at the moment I think we need to
support 8.1 because it's whats installed/supported on many linux
distros.

>> Build java code with -g, but pljava c code without debugging symbols I
>> reckon. If someone wants to debug pljava C code, they can build it
>> themselves. :)
>>
>>
> Well, it's not so much about debugging really. It's more the information
> you can get once something is crashing. As I mentioned, the JVM prints a
> stack trace that can be very useful. Much is gained if the user who
> experiences a crash can provide the JVM dump file in a bug-report or
> attach it to a mailing list posting.

Just to clarify, the java code is never built with -g (see
src/java/Makefile.global). Is there any reason not to change this to
always build with -g?

>> I have some free time over the next few weeks, so I can have a go at
>> getting the wiki docs into some kind of source control.
> Awesome.

Yes, that'd be great. From there it's easy to publish this to
http://pljava.projects.postgresql.org.

Kris Jurka

Kris Jurka wrote:
>
>
>>>
>> Well, it's not so much about debugging really. It's more the information
>> you can get once something is crashing. As I mentioned, the JVM prints a
>> stack trace that can be very useful. Much is gained if the user who
>> experiences a crash can provide the JVM dump file in a bug-report or
>> attach it to a mailing list posting.
>
> Just to clarify, the java code is never built with -g (see
> src/java/Makefile.global). Is there any reason not to change this to
> always build with -g?
>
I'm not referring to the Java code. The JVM extracts symbolic
information from the binary. If I'm not mistaking, that information is
not present when the binary is compiled without -g. If I'm wrong about
this, then we don't need debugging.

- thomas

On Nov 20, 2007 11:09 AM, Thomas Hallgren <thomas at tada.se> wrote:
> > I'm pretty sure I was able to compile pljava against a 1.5 JDK and run
> > it against a 1.6 one. So I don't think we should need to build it for
> > more than one JVM.
> That's assuming that we don't want to support GCJ. That's equal to
> adding a requirement to install a JVM.

Fair point. I think long term the need to support GCJ will probably go
away, however. OpenJDK/IcedTea will basically replace it. Redhat are
already shipping IcedTea in Fedora 8, and I expect other distros to
follow. I think the days of Linux distros not shipping with a decent
JDK by default are coming to an end. Yay!

That's not to say that someone couldn't compile against GCJ if they
like. But I doubt that it'll be a useful thing to prebuild binaries
for.

> Perhaps an idea would be to provide binary support for the latest, or
> the latest two? I.e. if you want older, build your own?

Sure. If we start getting requests to support older backend releases,
then we can revise the decision.

[Stuff about building binaries]

> Great! Would you like to be added to the project so that you can upload
> files there?

Yes, thanks. Hmm, I wasn't actually registered on pgfoundry. Now
registered as tomd.

Cheers

Tom

On Nov 20, 2007 12:08 PM, Thomas Hallgren <thomas at tada.se> wrote:
> I'm not referring to the Java code. The JVM extracts symbolic
> information from the binary. If I'm not mistaking, that information is
> not present when the binary is compiled without -g. If I'm wrong about
> this, then we don't need debugging.

Oh, duh. Yeah, you can still get stacktraces, but they won't have
line-numbers if you compile without -g. Probably doesn't matter all
that much, although it might be nice to allow someone hacking pljava
to turn it on if they like. No big deal.

Cheers

Tom

Tom Dunstan wrote:

> Yes, thanks. Hmm, I wasn't actually registered on pgfoundry. Now
> registered as tomd.
>
I added you as a senior developer.

- thomas