[Pljava-dev] Source code move to Git

The source code has now been moved to GitHub and can be viewed at
https://github.com/tada/pljava. This repository is a fork of the CVS
HEAD (forked using git cvsimport) as of today with all history and
committer identities retrained. It's public and viewable by all.

I've also created a PL/Java Developers team with push access to this
repository. At present, the one and only member of this team is Johann
(Myrkraverk). The intention with the push access is to be able to review
and commit pull requests, not to push directly.

Going forward, I'd like us to follow a process where nothing happens in
the source code unless there's an issue for it (a pull request is also
considered an issue). All issues must be entered in the GitHub issue
tracker: https://github.com/tada/pljava/issues . I want to avoid direct
pushes to the tada/pljava repository. In essence, everything that
happens from now on should be in the form of a pull request that origins
from a fork. That also applies to us that has push access.

Kris Jurka and Filip Hrbek are the only two committers that has made
commits in the PL/Java source tree. That was however several years ago
so Kris, Filip, at present you're no longer committers but let me know
if you have any plans participate and want that status restored.

Regards,
Thomas Hallgren

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20130113/39b65eee/attachment.html>

So, seems like I have to apply all the transforms again to get this in the form I current have it. Thus....

Is Maven still desirable?
What group id do you want to use?
Is the break out of the maven modules acceptable?
Was the code formatting desirable?

Let me know the answers above and I'll have a pull request for your review soon.

Also, too, y'all should know that git doesn't keep track of the refactoring of individual file movement. It tries to do some stuff, but I'm not sure how much history is maintained. So if I refactor the project to the maven modules that I currently have in my repository, then some history information will likely be lost.

I think the maven refactoring is a good thing, personally. But I don't know if it's worth (potentially) losing the history in your valuation.

On Jan 13, 2013, at 1:10 AM, Thomas Hallgren <thomas at tada.se> wrote:

> The source code has now been moved to GitHub and can be viewed at https://github.com/tada/pljava. This repository is a fork of the CVS HEAD (forked using git cvsimport) as of today with all history and committer identities retrained. It's public and viewable by all.
>
> I've also created a PL/Java Developers team with push access to this repository. At present, the one and only member of this team is Johann (Myrkraverk). The intention with the push access is to be able to review and commit pull requests, not to push directly.
>
> Going forward, I'd like us to follow a process where nothing happens in the source code unless there's an issue for it (a pull request is also considered an issue). All issues must be entered in the GitHub issue tracker: https://github.com/tada/pljava/issues . I want to avoid direct pushes to the tada/pljava repository. In essence, everything that happens from now on should be in the form of a pull request that origins from a fork. That also applies to us that has push access.
>
> Kris Jurka and Filip Hrbek are the only two committers that has made commits in the PL/Java source tree. That was however several years ago so Kris, Filip, at present you're no longer committers but let me know if you have any plans participate and want that status restored.
>
> Regards,
> Thomas Hallgren
>
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at pgfoundry.org
> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20130113/89fbe506/attachment.html>

On 2013-01-13 18:10, Hal Hildebrand wrote:
> So, seems like I have to apply all the transforms again to get this in
> the form I current have it. Thus....
>
> Is Maven still desirable?

Yes, absolutely! And I think that later on, we should strive to make the
Maven Central the main distribution point for PL/Java.

> What group id do you want to use?

I searched Maven Central. The standard PostgreSQL jdbc driver uses the
group id 'postgresql'. Incidentally, that's also what I used the first
time a pljava jar was published (pljava-public). So lets stick with
that. I can't find any other groupid that is used for Postgres and I
think that creating additional ones will just lead to confusion.

> Is the break out of the maven modules acceptable?

Yes, although I'd prefer if the module named 'jdbc' was named 'plugin'
or 'module' since it contains the complete module to be installed into
the backend server. It's more than just jdbc. Other name suggestions are
of course welcome. I'd also like the current src/C directory to also end
up in this sub-project under src/main/c (C becomes smallcaps c) and
src/main/include. Reason being that I think that the maven-nar-plugin
http://duns.github.com/maven-nar-plugin/ looks like a good candidate for
building it and I'd prefer to use it's default layout. Does that sound
agreeable to you?

> Was the code formatting desirable?
>
Yes, although it's a bit hard to see what's really changed in a commit
that massive so please don't mix the reformatting with any other type of
change.

I'm not sure what formatting rules you are using. Is it Eclipse built-in
rules? One thing that often annoys me with that is that 80 characters is
very narrow nowadays. I usually increase that to at least 120. What's
your opinion about that?

> Let me know the answers above and I'll have a pull request for your
> review soon.
>
> Also, too, y'all should know that git doesn't keep track of the
> refactoring of individual file movement. It tries to do some stuff,
> but I'm not sure how much history is maintained. So if I refactor the
> project to the maven modules that I currently have in my repository,
> then some history information will likely be lost.
Git is usually very good in finding what has been moved if you are
careful not to change the content of the files in the same commit. So be
careful to have one commit where you only move files without changing
any of their content.

In order to accomplish all of this, and also to be able to keep good
track of what has happened, I think it would be ideal if pull-requests
are very distinct. That means that you'll need to submit more than one.
I would suggest the following:

1. A pull request that creates the Maven structure and adds the pom's.
This pull request must not change the content of any file. Just move
them. In addition to what you did earlier, I think the C-code needs to
move into a separate sub-project as well (with it's own src/main/c

2. A pull request that takes care of the formatting. Given the magnitude
of the change, I think it's essential that this pull request only deals
with formatting. It must not change any logic whatsoever since that
change would be come completely impossible to find later on.

3. Other pull requests that change logic. Ideally, those requests should
be preceded by an issue (bug or enhancement request) where other
interested parties (like myself) has had a chance to discuss the nature
of the change.

>
> I think the maven refactoring is a good thing, personally. But I
> don't know if it's worth (potentially) losing the history in your
> valuation.
>
I agree that the refactoring is a good thing. And as I wrote, I suspect
that the history will be retained in full if it's done right.

I'm looking forward to your submissions.

Thanks and Regards,
Thomas Hallgren

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20130113/ced9cbaa/attachment.html>

On 2013-01-13 19:20, Thomas Hallgren wrote:
> On 2013-01-13 18:10, Hal Hildebrand wrote:
>> Is the break out of the maven modules acceptable?
>
> Yes, although I'd prefer if the module named 'jdbc' was named 'plugin'
> or 'module'

On second thought, 'plugin' is a bad name. We might want to create a
maven plug-in for pljava at some point. What about 'server' to signify
that this is the part that runs in the server?

- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20130113/949ba8ec/attachment.html>

Yep. Incremental rules. Will get something to y'all soon.

Thx.

Sent from my Tricorder

On Jan 13, 2013, at 10:20 AM, Thomas Hallgren <thomas at tada.se> wrote:

> On 2013-01-13 18:10, Hal Hildebrand wrote:
>> So, seems like I have to apply all the transforms again to get this in the form I current have it. Thus....
>>
>> Is Maven still desirable?
>
> Yes, absolutely! And I think that later on, we should strive to make the Maven Central the main distribution point for PL/Java.
>
>> What group id do you want to use?
>
> I searched Maven Central. The standard PostgreSQL jdbc driver uses the group id 'postgresql'. Incidentally, that's also what I used the first time a pljava jar was published (pljava-public). So lets stick with that. I can't find any other groupid that is used for Postgres and I think that creating additional ones will just lead to confusion.
>
>> Is the break out of the maven modules acceptable?
>
> Yes, although I'd prefer if the module named 'jdbc' was named 'plugin' or 'module' since it contains the complete module to be installed into the backend server. It's more than just jdbc. Other name suggestions are of course welcome. I'd also like the current src/C directory to also end up in this sub-project under src/main/c (C becomes smallcaps c) and src/main/include. Reason being that I think that the maven-nar-plugin http://duns.github.com/maven-nar-plugin/ looks like a good candidate for building it and I'd prefer to use it's default layout. Does that sound agreeable to you?
>
>> Was the code formatting desirable?
> Yes, although it's a bit hard to see what's really changed in a commit that massive so please don't mix the reformatting with any other type of change.
>
> I'm not sure what formatting rules you are using. Is it Eclipse built-in rules? One thing that often annoys me with that is that 80 characters is very narrow nowadays. I usually increase that to at least 120. What's your opinion about that?
>
>> Let me know the answers above and I'll have a pull request for your review soon.
>>
>> Also, too, y'all should know that git doesn't keep track of the refactoring of individual file movement. It tries to do some stuff, but I'm not sure how much history is maintained. So if I refactor the project to the maven modules that I currently have in my repository, then some history information will likely be lost.
> Git is usually very good in finding what has been moved if you are careful not to change the content of the files in the same commit. So be careful to have one commit where you only move files without changing any of their content.
>
> In order to accomplish all of this, and also to be able to keep good track of what has happened, I think it would be ideal if pull-requests are very distinct. That means that you'll need to submit more than one. I would suggest the following:
>
> 1. A pull request that creates the Maven structure and adds the pom's. This pull request must not change the content of any file. Just move them. In addition to what you did earlier, I think the C-code needs to move into a separate sub-project as well (with it's own src/main/c
>
> 2. A pull request that takes care of the formatting. Given the magnitude of the change, I think it's essential that this pull request only deals with formatting. It must not change any logic whatsoever since that change would be come completely impossible to find later on.
>
> 3. Other pull requests that change logic. Ideally, those requests should be preceded by an issue (bug or enhancement request) where other interested parties (like myself) has had a chance to discuss the nature of the change.
>
>>
>> I think the maven refactoring is a good thing, personally. But I don't know if it's worth (potentially) losing the history in your valuation.
> I agree that the refactoring is a good thing. And as I wrote, I suspect that the history will be retained in full if it's done right.
>
> I'm looking forward to your submissions.
>
> Thanks and Regards,
> Thomas Hallgren
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20130113/f2916cfc/attachment-0001.html>

Oddly enough, I also created a maven plugin for pljava.

Sent from my Tricorder

On Jan 13, 2013, at 11:34 AM, Thomas Hallgren <thomas at tada.se> wrote:

> On 2013-01-13 19:20, Thomas Hallgren wrote:
>> On 2013-01-13 18:10, Hal Hildebrand wrote:
>>> Is the break out of the maven modules acceptable?
>>
>> Yes, although I'd prefer if the module named 'jdbc' was named 'plugin' or 'module'
>
> On second thought, 'plugin' is a bad name. We might want to create a maven plug-in for pljava at some point. What about 'server' to signify that this is the part that runs in the server?
>
> - thomas

Related to this - I created a project on google code a while back that has
a number of advanced examples for a series of blog posts I wrote - things
like user-defined types, triggers, etc. I don't know if it makes sense to
integrate the examples into the main source tree (as an 'examples'
artifact), have it as a sibling project, or have it totally independent.
The project makes it clear that it was never intended to be used as an
actual library, it just contains examples of how to use pl/java.

https://code.google.com/p/postgresql-pljava-examples/

Also I might be able to devote a few cycles to improving the crypto stuff.
The motivation is that server-side crypto means you could have a relatively
unprivileged user perform some tightly constrained functions. E.g., you may
have a database containing encrypted salaries but be willing to provide an
average salary. (Setting aside the crypto this is actually a hard problem
to solve since a series of careful queries may reveal individual
information. But at a minimum you could have a function that makes sure
there's at least a dozen data points, decrypts them, then averages them.)

The standard crypto extension provides a bit of this but we really want to
be able to toss BouncyCastle onto the jar path. I've started playing with
it but some key standard Jave-SE classes are missing.

On Sun, Jan 13, 2013 at 3:15 PM, Hal Hildebrand <hal.hildebrand at me.com>wrote:

> Oddly enough, I also created a maven plugin for pljava.
>
> Sent from my Tricorder
>
> On Jan 13, 2013, at 11:34 AM, Thomas Hallgren <thomas at tada.se> wrote:
>
> > On 2013-01-13 19:20, Thomas Hallgren wrote:
> >> On 2013-01-13 18:10, Hal Hildebrand wrote:
> >>> Is the break out of the maven modules acceptable?
> >>
> >> Yes, although I'd prefer if the module named 'jdbc' was named 'plugin'
> or 'module'
> >
> > On second thought, 'plugin' is a bad name. We might want to create a
> maven plug-in for pljava at some point. What about 'server' to signify that
> this is the part that runs in the server?
> >
> > - thomas
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at pgfoundry.org
> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20130113/1dfceaa3/attachment.html>

P.S. the blog entries were at http://invariantproperties.com/

On Sun, Jan 13, 2013 at 4:33 PM, Bear Giles <bgiles at coyotesong.com> wrote:

> Related to this - I created a project on google code a while back that has
> a number of advanced examples for a series of blog posts I wrote - things
> like user-defined types, triggers, etc. I don't know if it makes sense to
> integrate the examples into the main source tree (as an 'examples'
> artifact), have it as a sibling project, or have it totally independent.
> The project makes it clear that it was never intended to be used as an
> actual library, it just contains examples of how to use pl/java.
>
> https://code.google.com/p/postgresql-pljava-examples/
>
> Also I might be able to devote a few cycles to improving the crypto stuff.
> The motivation is that server-side crypto means you could have a relatively
> unprivileged user perform some tightly constrained functions. E.g., you may
> have a database containing encrypted salaries but be willing to provide an
> average salary. (Setting aside the crypto this is actually a hard problem
> to solve since a series of careful queries may reveal individual
> information. But at a minimum you could have a function that makes sure
> there's at least a dozen data points, decrypts them, then averages them.)
>
> The standard crypto extension provides a bit of this but we really want to
> be able to toss BouncyCastle onto the jar path. I've started playing with
> it but some key standard Jave-SE classes are missing.
>
>
>
> On Sun, Jan 13, 2013 at 3:15 PM, Hal Hildebrand <hal.hildebrand at me.com>wrote:
>
>> Oddly enough, I also created a maven plugin for pljava.
>>
>> Sent from my Tricorder
>>
>> On Jan 13, 2013, at 11:34 AM, Thomas Hallgren <thomas at tada.se> wrote:
>>
>> > On 2013-01-13 19:20, Thomas Hallgren wrote:
>> >> On 2013-01-13 18:10, Hal Hildebrand wrote:
>> >>> Is the break out of the maven modules acceptable?
>> >>
>> >> Yes, although I'd prefer if the module named 'jdbc' was named 'plugin'
>> or 'module'
>> >
>> > On second thought, 'plugin' is a bad name. We might want to create a
>> maven plug-in for pljava at some point. What about 'server' to signify that
>> this is the part that runs in the server?
>> >
>> > - thomas
>> _______________________________________________
>> Pljava-dev mailing list
>> Pljava-dev at pgfoundry.org
>> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20130113/def405ed/attachment.html>

Okay, first pull request in. This is just the initial structural refactoring to a maven build, no source changes.

Doesn't refactor src/test, doesn't refactor C.

On Jan 13, 2013, at 2:15 PM, Hal Hildebrand <hal.hildebrand at me.com> wrote:

> Yep. Incremental rules. Will get something to y'all soon.
>
> Thx.
>
> Sent from my Tricorder
>
> On Jan 13, 2013, at 10:20 AM, Thomas Hallgren <thomas at tada.se> wrote:
>
>> On 2013-01-13 18:10, Hal Hildebrand wrote:
>>> So, seems like I have to apply all the transforms again to get this in the form I current have it. Thus....
>>>
>>> Is Maven still desirable?
>>
>> Yes, absolutely! And I think that later on, we should strive to make the Maven Central the main distribution point for PL/Java.
>>
>>> What group id do you want to use?
>>
>> I searched Maven Central. The standard PostgreSQL jdbc driver uses the group id 'postgresql'. Incidentally, that's also what I used the first time a pljava jar was published (pljava-public). So lets stick with that. I can't find any other groupid that is used for Postgres and I think that creating additional ones will just lead to confusion.
>>
>>> Is the break out of the maven modules acceptable?
>>
>> Yes, although I'd prefer if the module named 'jdbc' was named 'plugin' or 'module' since it contains the complete module to be installed into the backend server. It's more than just jdbc. Other name suggestions are of course welcome. I'd also like the current src/C directory to also end up in this sub-project under src/main/c (C becomes smallcaps c) and src/main/include. Reason being that I think that the maven-nar-plugin http://duns.github.com/maven-nar-plugin/ looks like a good candidate for building it and I'd prefer to use it's default layout. Does that sound agreeable to you?
>>
>>> Was the code formatting desirable?
>>>
>> Yes, although it's a bit hard to see what's really changed in a commit that massive so please don't mix the reformatting with any other type of change.
>>
>> I'm not sure what formatting rules you are using. Is it Eclipse built-in rules? One thing that often annoys me with that is that 80 characters is very narrow nowadays. I usually increase that to at least 120. What's your opinion about that?
>>
>>> Let me know the answers above and I'll have a pull request for your review soon.
>>>
>>> Also, too, y'all should know that git doesn't keep track of the refactoring of individual file movement. It tries to do some stuff, but I'm not sure how much history is maintained. So if I refactor the project to the maven modules that I currently have in my repository, then some history information will likely be lost.
>> Git is usually very good in finding what has been moved if you are careful not to change the content of the files in the same commit. So be careful to have one commit where you only move files without changing any of their content.
>>
>> In order to accomplish all of this, and also to be able to keep good track of what has happened, I think it would be ideal if pull-requests are very distinct. That means that you'll need to submit more than one. I would suggest the following:
>>
>> 1. A pull request that creates the Maven structure and adds the pom's. This pull request must not change the content of any file. Just move them. In addition to what you did earlier, I think the C-code needs to move into a separate sub-project as well (with it's own src/main/c
>>
>> 2. A pull request that takes care of the formatting. Given the magnitude of the change, I think it's essential that this pull request only deals with formatting. It must not change any logic whatsoever since that change would be come completely impossible to find later on.
>>
>> 3. Other pull requests that change logic. Ideally, those requests should be preceded by an issue (bug or enhancement request) where other interested parties (like myself) has had a chance to discuss the nature of the change.
>>
>>>
>>> I think the maven refactoring is a good thing, personally. But I don't know if it's worth (potentially) losing the history in your valuation.
>>>
>> I agree that the refactoring is a good thing. And as I wrote, I suspect that the history will be retained in full if it's done right.
>>
>> I'm looking forward to your submissions.
>>
>> Thanks and Regards,
>> Thomas Hallgren
>>
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at pgfoundry.org
> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20130113/85128bd8/attachment-0001.html>

On 01/14/2013 03:34 AM, Thomas Hallgren wrote:
> On 2013-01-13 19:20, Thomas Hallgren wrote:
>> On 2013-01-13 18:10, Hal Hildebrand wrote:
>>> Is the break out of the maven modules acceptable?
>>
>> Yes, although I'd prefer if the module named 'jdbc' was named
>> 'plugin' or 'module'
>
> On second thought, 'plugin' is a bad name. We might want to create a
> maven plug-in for pljava at some point. What about 'server' to signify
> that this is the part that runs in the server?

Follow the PostgreSQL naming convention - backend and front-end parts?

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20130114/69025c20/attachment.html>

On 01/14/2013 09:20 AM, Hal Hildebrand wrote:
> Okay, first pull request in. This is just the initial structural
> refactoring to a maven build, no source changes.
>
> Doesn't refactor src/test, doesn't refactor C.

The builds use PGXS for the C code, and I think that's the right
approach. Maybe we can run the pgxs makefiles from Maven?

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20130114/121fb010/attachment.html>

You can execute anything from Maven using the exec maven plugin (http://mojo.codehaus.org/exec-maven-plugin/) There's a specialization for executing Ant, if that's useful (https://maven.apache.org/plugins/maven-antrun-plugin/) So, the mechanics of integrating Make aren't especially difficult.

The bigger difficulty, from my POV, is setting up the environment correctly. Having done this a couple of times, it still seems like quite the chore to actually build the C portion of pl/java. I'm not sure if that's just inherent difficulty or if there's something that can be done to make the process painless. I'm guessing the former because that's the way C programs roll.

In any event, however, it'll be easy to add a Maven module for building the C portion. I just didn't do it right off the bat because I wanted to get the Java portion squared away first, and the fact that I do most of my development on the Mac and I have had no luck getting pl/java to build on the Mac so I'll have to switch to Linux to get that portion squared away.

On Jan 13, 2013, at 7:06 PM, Craig Ringer <craig at 2ndQuadrant.com> wrote:

> On 01/14/2013 09:20 AM, Hal Hildebrand wrote:
>> Okay, first pull request in. This is just the initial structural refactoring to a maven build, no source changes.
>>
>> Doesn't refactor src/test, doesn't refactor C.
>
> The builds use PGXS for the C code, and I think that's the right approach. Maybe we can run the pgxs makefiles from Maven?
> --
> Craig Ringer http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20130113/e2480c97/attachment.html>

On 01/14/2013 12:04 PM, Hal Hildebrand wrote:
> You can execute anything from Maven using the exec maven plugin
> (http://mojo.codehaus.org/exec-maven-plugin/) There's a
> specialization for executing Ant, if that's useful
> (https://maven.apache.org/plugins/maven-antrun-plugin/) So, the
> mechanics of integrating Make aren't especially difficult.
>
> The bigger difficulty, from my POV, is setting up the environment
> correctly. Having done this a couple of times, it still seems like
> quite the chore to actually build the C portion of pl/java. I'm not
> sure if that's just inherent difficulty or if there's something that
> can be done to make the process painless. I'm guessing the former
> because that's the way C programs roll.
>
It "just worked" for me, thanks to PGXS. Put `pg_config` on the PATH and
run "make", it just builds.

Were you trying to build the sources directly, without using the PGXS
integration - say via some other build system instead of using the
makefiles?

One thing that worries me is that AFAIK PGXS doesn't work with the
Visual Studio builds on Windows. The PL/Java builds for Windows seem to
be compiled with MinGW, which is kind of ugly when Pg is built with
MSVC. I haven't looked into what's involved in building extensions
out-of-tree on Windows yet as I've always just moved them into contrib/
in the source tree and built them as part of a PostgreSQL source build.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20130114/cd08cce1/attachment.html>

Hi Bear,

I think examples like these are very valuable to the community. They are
candidates for inclusion in our example module (we already have such a
module). Would it be possible for you to provide them in the form of a
pull request?

Regarding the crypto stuff, also interesting. I'd love to see that too
as a (separate) pull request. What JDK version is required for it to run?

Regards,
Thomas Hallgren

On 2013-01-14 00:35, Bear Giles wrote:
> P.S. the blog entries were at http://invariantproperties.com/
>
>
> On Sun, Jan 13, 2013 at 4:33 PM, Bear Giles <bgiles at coyotesong.com
> <mailto:bgiles at coyotesong.com>> wrote:
>
> Related to this - I created a project on google code a while back
> that has a number of advanced examples for a series of blog posts
> I wrote - things like user-defined types, triggers, etc. I don't
> know if it makes sense to integrate the examples into the main
> source tree (as an 'examples' artifact), have it as a sibling
> project, or have it totally independent. The project makes it
> clear that it was never intended to be used as an actual library,
> it just contains examples of how to use pl/java.
>
> https://code.google.com/p/postgresql-pljava-examples/
>
> Also I might be able to devote a few cycles to improving the
> crypto stuff. The motivation is that server-side crypto means you
> could have a relatively unprivileged user perform some tightly
> constrained functions. E.g., you may have a database containing
> encrypted salaries but be willing to provide an average salary.
> (Setting aside the crypto this is actually a hard problem to solve
> since a series of careful queries may reveal individual
> information. But at a minimum you could have a function that makes
> sure there's at least a dozen data points, decrypts them, then
> averages them.)
>
> The standard crypto extension provides a bit of this but we really
> want to be able to toss BouncyCastle onto the jar path. I've
> started playing with it but some key standard Jave-SE classes are
> missing.
>
>
>
> On Sun, Jan 13, 2013 at 3:15 PM, Hal Hildebrand
> <hal.hildebrand at me.com <mailto:hal.hildebrand at me.com>> wrote:
>
> Oddly enough, I also created a maven plugin for pljava.
>
> Sent from my Tricorder
>
> On Jan 13, 2013, at 11:34 AM, Thomas Hallgren <thomas at tada.se
> <mailto:thomas at tada.se>> wrote:
>
> > On 2013-01-13 19:20, Thomas Hallgren wrote:
> >> On 2013-01-13 18:10, Hal Hildebrand wrote:
> >>> Is the break out of the maven modules acceptable?
> >>
> >> Yes, although I'd prefer if the module named 'jdbc' was
> named 'plugin' or 'module'
> >
> > On second thought, 'plugin' is a bad name. We might want to
> create a maven plug-in for pljava at some point. What about
> 'server' to signify that this is the part that runs in the server?
> >
> > - thomas
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at pgfoundry.org <mailto:Pljava-dev at pgfoundry.org>
> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20130114/84183a47/attachment-0001.html>

Has any of you looked at the maven-nar-plugin? Seems it might be capable
to even out some of the quirks when building on different platforms.
http://duns.github.com/maven-nar-plugin/. My idea was to somehow use it
in conjunction with PGXS.

A functional Windows build is a must of course but I'd be totally fine
if MinGW was stripped out of the equation in favor of more "proper" ways
of doing it.

The support for GCJ can be dropped as far as I'm concerned. I think that
project stalled some three-four years ago.

- thomas

On 2013-01-14 05:10, Craig Ringer wrote:
> On 01/14/2013 12:04 PM, Hal Hildebrand wrote:
>> You can execute anything from Maven using the exec maven plugin
>> (http://mojo.codehaus.org/exec-maven-plugin/) There's a
>> specialization for executing Ant, if that's useful
>> (https://maven.apache.org/plugins/maven-antrun-plugin/) So, the
>> mechanics of integrating Make aren't especially difficult.
>>
>> The bigger difficulty, from my POV, is setting up the environment
>> correctly. Having done this a couple of times, it still seems like
>> quite the chore to actually build the C portion of pl/java. I'm not
>> sure if that's just inherent difficulty or if there's something that
>> can be done to make the process painless. I'm guessing the former
>> because that's the way C programs roll.
>>
> It "just worked" for me, thanks to PGXS. Put `pg_config` on the PATH
> and run "make", it just builds.
>
> Were you trying to build the sources directly, without using the PGXS
> integration - say via some other build system instead of using the
> makefiles?
>
> One thing that worries me is that AFAIK PGXS doesn't work with the
> Visual Studio builds on Windows. The PL/Java builds for Windows seem
> to be compiled with MinGW, which is kind of ugly when Pg is built with
> MSVC. I haven't looked into what's involved in building extensions
> out-of-tree on Windows yet as I've always just moved them into
> contrib/ in the source tree and built them as part of a PostgreSQL
> source build.
>
> --
> Craig Ringerhttp://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20130114/e2e8dcab/attachment.html>

Haven't looked at it, but it does look quite good. Seems like its worth a go at it.

Sent from my Tricorder

On Jan 14, 2013, at 2:04 AM, Thomas Hallgren <thomas at tada.se> wrote:

> Has any of you looked at the maven-nar-plugin? Seems it might be capable to even out some of the quirks when building on different platforms. http://duns.github.com/maven-nar-plugin/. My idea was to somehow use it in conjunction with PGXS.
>
> A functional Windows build is a must of course but I'd be totally fine if MinGW was stripped out of the equation in favor of more "proper" ways of doing it.
>
> The support for GCJ can be dropped as far as I'm concerned. I think that project stalled some three-four years ago.
>
> - thomas
>
>
> On 2013-01-14 05:10, Craig Ringer wrote:
>> On 01/14/2013 12:04 PM, Hal Hildebrand wrote:
>>> You can execute anything from Maven using the exec maven plugin (http://mojo.codehaus.org/exec-maven-plugin/) There's a specialization for executing Ant, if that's useful (https://maven.apache.org/plugins/maven-antrun-plugin/) So, the mechanics of integrating Make aren't especially difficult.
>>>
>>> The bigger difficulty, from my POV, is setting up the environment correctly. Having done this a couple of times, it still seems like quite the chore to actually build the C portion of pl/java. I'm not sure if that's just inherent difficulty or if there's something that can be done to make the process painless. I'm guessing the former because that's the way C programs roll.
>> It "just worked" for me, thanks to PGXS. Put `pg_config` on the PATH and run "make", it just builds.
>>
>> Were you trying to build the sources directly, without using the PGXS integration - say via some other build system instead of using the makefiles?
>>
>> One thing that worries me is that AFAIK PGXS doesn't work with the Visual Studio builds on Windows. The PL/Java builds for Windows seem to be compiled with MinGW, which is kind of ugly when Pg is built with MSVC. I haven't looked into what's involved in building extensions out-of-tree on Windows yet as I've always just moved them into contrib/ in the source tree and built them as part of a PostgreSQL source build.
>>
>> --
>> Craig Ringer http://www.2ndQuadrant.com/
>> PostgreSQL Development, 24x7 Support, Training & Services
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20130114/f339ef4c/attachment.html>

Hi Thomas,

thanks for you report.

I don't have any particular plans regarding contributing to pljava. However, the product based on pljava that I created in my former employment is still alive (I guess for 9 years already!) and I provide support for them from time to time. It can happed that we'll be solving an issue in future and in that case, if it requires changes in the code, I will contact you.

Filip

Dne 13.1.2013 10:10, Thomas Hallgren napsal(a):
> The source code has now been moved to GitHub and can be viewed at https://github.com/tada/pljava. This repository is a fork of the CVS HEAD (forked using git cvsimport) as of today with all history and committer identities retrained. It's public and viewable by all.
>
> I've also created a PL/Java Developers team with push access to this repository. At present, the one and only member of this team is Johann (Myrkraverk). The intention with the push access is to be able to review and commit pull requests, not to push directly.
>
> Going forward, I'd like us to follow a process where nothing happens in the source code unless there's an issue for it (a pull request is also considered an issue). All issues must be entered in the GitHub issue tracker: https://github.com/tada/pljava/issues . I want to avoid direct pushes to the tada/pljava repository. In essence, everything that happens from now on should be in the form of a pull request that origins from a fork. That also applies to us that has push access.
>
> Kris Jurka and Filip Hrbek are the only two committers that has made commits in the PL/Java source tree. That was however several years ago so Kris, Filip, at present you're no longer committers but let me know if you have any plans participate and want that status restored.
>
> Regards,
> Thomas Hallgren
>

I'm not sure what you need. I'm using the public google subversion server -
I think the link is on the download page/tab/whatever.

On Mon, Jan 14, 2013 at 2:56 AM, Thomas Hallgren <thomas at tada.se> wrote:

> Hi Bear,
>
> I think examples like these are very valuable to the community. They are
> candidates for inclusion in our example module (we already have such a
> module). Would it be possible for you to provide them in the form of a pull
> request?
>
> Regarding the crypto stuff, also interesting. I'd love to see that too as
> a (separate) pull request. What JDK version is required for it to run?
>
> Regards,
> Thomas Hallgren
>
>
> On 2013-01-14 00:35, Bear Giles wrote:
>
> P.S. the blog entries were at http://invariantproperties.com/
>
>
> On Sun, Jan 13, 2013 at 4:33 PM, Bear Giles <bgiles at coyotesong.com>wrote:
>
>> Related to this - I created a project on google code a while back that
>> has a number of advanced examples for a series of blog posts I wrote -
>> things like user-defined types, triggers, etc. I don't know if it makes
>> sense to integrate the examples into the main source tree (as an 'examples'
>> artifact), have it as a sibling project, or have it totally independent.
>> The project makes it clear that it was never intended to be used as an
>> actual library, it just contains examples of how to use pl/java.
>>
>> https://code.google.com/p/postgresql-pljava-examples/
>>
>> Also I might be able to devote a few cycles to improving the crypto
>> stuff. The motivation is that server-side crypto means you could have a
>> relatively unprivileged user perform some tightly constrained functions.
>> E.g., you may have a database containing encrypted salaries but be willing
>> to provide an average salary. (Setting aside the crypto this is actually a
>> hard problem to solve since a series of careful queries may reveal
>> individual information. But at a minimum you could have a function that
>> makes sure there's at least a dozen data points, decrypts them, then
>> averages them.)
>>
>> The standard crypto extension provides a bit of this but we really want
>> to be able to toss BouncyCastle onto the jar path. I've started playing
>> with it but some key standard Jave-SE classes are missing.
>>
>>
>>
>> On Sun, Jan 13, 2013 at 3:15 PM, Hal Hildebrand <hal.hildebrand at me.com>wrote:
>>
>>> Oddly enough, I also created a maven plugin for pljava.
>>>
>>> Sent from my Tricorder
>>>
>>> On Jan 13, 2013, at 11:34 AM, Thomas Hallgren <thomas at tada.se> wrote:
>>>
>>> > On 2013-01-13 19:20, Thomas Hallgren wrote:
>>> >> On 2013-01-13 18:10, Hal Hildebrand wrote:
>>> >>> Is the break out of the maven modules acceptable?
>>> >>
>>> >> Yes, although I'd prefer if the module named 'jdbc' was named
>>> 'plugin' or 'module'
>>> >
>>> > On second thought, 'plugin' is a bad name. We might want to create a
>>> maven plug-in for pljava at some point. What about 'server' to signify that
>>> this is the part that runs in the server?
>>> >
>>> > - thomas
>>> _______________________________________________
>>> Pljava-dev mailing list
>>> Pljava-dev at pgfoundry.org
>>> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20130114/446a6128/attachment.html>

On 2013-01-14 19:16, Bear Giles wrote:
> I'm not sure what you need. I'm using the public google subversion
> server - I think the link is on the download page/tab/whatever.
>
I can find the code in your SVN repository for sure but I'm trying to
establish a process for submissions that will ensure that the correct
author gets credit while at the same time making the submission
traceable and easy. I plan to write a page where this process is
outlined soon enough but here's a short brief:

1. You ensure that you have an account at GitHub.
2. You fork the tada/pljava repository at GitHub (just navigate to that
repository and click 'Fork'). This creates a fork named <your account
name>/pljava.
3. Create a local clone of that repository and add your examples to the
example module.
4. Commit your changes to your local clone with an explanatory commit
comment. You can do several commits.
5. Push the local clone (updates your fork at GitHub). This can also be
repeated.
6. Submit a "pull request" at GitHub (in other words, ask tada/pljava
maintainers to merge your changes). This will automatically create an
issue with the tada/pljava repository where your commit(s) can be
reviewed and accepted. Once accepted, they are merged and will then
appear in the repository just as you entered them, with comments,
correct author, and all.

Regards,
Thomas Hallgren

>
> On Mon, Jan 14, 2013 at 2:56 AM, Thomas Hallgren <thomas at tada.se
> <mailto:thomas at tada.se>> wrote:
>
> Hi Bear,
>
> I think examples like these are very valuable to the community.
> They are candidates for inclusion in our example module (we
> already have such a module). Would it be possible for you to
> provide them in the form of a pull request?
>
> Regarding the crypto stuff, also interesting. I'd love to see that
> too as a (separate) pull request. What JDK version is required for
> it to run?
>
> Regards,
> Thomas Hallgren
>
>
> On 2013-01-14 00:35, Bear Giles wrote:
>> P.S. the blog entries were at http://invariantproperties.com/
>>
>>
>> On Sun, Jan 13, 2013 at 4:33 PM, Bear Giles
>> <bgiles at coyotesong.com <mailto:bgiles at coyotesong.com>> wrote:
>>
>> Related to this - I created a project on google code a while
>> back that has a number of advanced examples for a series of
>> blog posts I wrote - things like user-defined types,
>> triggers, etc. I don't know if it makes sense to integrate
>> the examples into the main source tree (as an 'examples'
>> artifact), have it as a sibling project, or have it totally
>> independent. The project makes it clear that it was never
>> intended to be used as an actual library, it just contains
>> examples of how to use pl/java.
>>
>> https://code.google.com/p/postgresql-pljava-examples/
>>
>> Also I might be able to devote a few cycles to improving the
>> crypto stuff. The motivation is that server-side crypto means
>> you could have a relatively unprivileged user perform some
>> tightly constrained functions. E.g., you may have a database
>> containing encrypted salaries but be willing to provide an
>> average salary. (Setting aside the crypto this is actually a
>> hard problem to solve since a series of careful queries may
>> reveal individual information. But at a minimum you could
>> have a function that makes sure there's at least a dozen data
>> points, decrypts them, then averages them.)
>>
>> The standard crypto extension provides a bit of this but we
>> really want to be able to toss BouncyCastle onto the jar
>> path. I've started playing with it but some key standard
>> Jave-SE classes are missing.
>>
>>
>>
>> On Sun, Jan 13, 2013 at 3:15 PM, Hal Hildebrand
>> <hal.hildebrand at me.com <mailto:hal.hildebrand at me.com>> wrote:
>>
>> Oddly enough, I also created a maven plugin for pljava.
>>
>> Sent from my Tricorder
>>
>> On Jan 13, 2013, at 11:34 AM, Thomas Hallgren
>> <thomas at tada.se <mailto:thomas at tada.se>> wrote:
>>
>> > On 2013-01-13 19:20, Thomas Hallgren wrote:
>> >> On 2013-01-13 18:10, Hal Hildebrand wrote:
>> >>> Is the break out of the maven modules acceptable?
>> >>
>> >> Yes, although I'd prefer if the module named 'jdbc'
>> was named 'plugin' or 'module'
>> >
>> > On second thought, 'plugin' is a bad name. We might
>> want to create a maven plug-in for pljava at some point.
>> What about 'server' to signify that this is the part that
>> runs in the server?
>> >
>> > - thomas
>> _______________________________________________
>> Pljava-dev mailing list
>> Pljava-dev at pgfoundry.org <mailto:Pljava-dev at pgfoundry.org>
>> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20130114/94353bbf/attachment-0001.html>

A submission page has been added to the (not yet complete) wiki.
Comments are welcome.

https://github.com/tada/pljava/wiki/Contribution-guide

- thomas

On 2013-01-14 22:30, Thomas Hallgren wrote:
> On 2013-01-14 19:16, Bear Giles wrote:
>> I'm not sure what you need. I'm using the public google subversion
>> server - I think the link is on the download page/tab/whatever.
>>
> I can find the code in your SVN repository for sure but I'm trying to
> establish a process for submissions that will ensure that the correct
> author gets credit while at the same time making the submission
> traceable and easy. I plan to write a page where this process is
> outlined soon enough but here's a short brief:
>
> 1. You ensure that you have an account at GitHub.
> 2. You fork the tada/pljava repository at GitHub (just navigate to
> that repository and click 'Fork'). This creates a fork named <your
> account name>/pljava.
> 3. Create a local clone of that repository and add your examples to
> the example module.
> 4. Commit your changes to your local clone with an explanatory commit
> comment. You can do several commits.
> 5. Push the local clone (updates your fork at GitHub). This can also
> be repeated.
> 6. Submit a "pull request" at GitHub (in other words, ask tada/pljava
> maintainers to merge your changes). This will automatically create an
> issue with the tada/pljava repository where your commit(s) can be
> reviewed and accepted. Once accepted, they are merged and will then
> appear in the repository just as you entered them, with comments,
> correct author, and all.
>
> Regards,
> Thomas Hallgren
>
>
>>
>> On Mon, Jan 14, 2013 at 2:56 AM, Thomas Hallgren <thomas at tada.se
>> <mailto:thomas at tada.se>> wrote:
>>
>> Hi Bear,
>>
>> I think examples like these are very valuable to the community.
>> They are candidates for inclusion in our example module (we
>> already have such a module). Would it be possible for you to
>> provide them in the form of a pull request?
>>
>> Regarding the crypto stuff, also interesting. I'd love to see
>> that too as a (separate) pull request. What JDK version is
>> required for it to run?
>>
>> Regards,
>> Thomas Hallgren
>>
>>
>> On 2013-01-14 00:35, Bear Giles wrote:
>>> P.S. the blog entries were at http://invariantproperties.com/
>>>
>>>
>>> On Sun, Jan 13, 2013 at 4:33 PM, Bear Giles
>>> <bgiles at coyotesong.com <mailto:bgiles at coyotesong.com>> wrote:
>>>
>>> Related to this - I created a project on google code a while
>>> back that has a number of advanced examples for a series of
>>> blog posts I wrote - things like user-defined types,
>>> triggers, etc. I don't know if it makes sense to integrate
>>> the examples into the main source tree (as an 'examples'
>>> artifact), have it as a sibling project, or have it totally
>>> independent. The project makes it clear that it was never
>>> intended to be used as an actual library, it just contains
>>> examples of how to use pl/java.
>>>
>>> https://code.google.com/p/postgresql-pljava-examples/
>>>
>>> Also I might be able to devote a few cycles to improving the
>>> crypto stuff. The motivation is that server-side crypto
>>> means you could have a relatively unprivileged user perform
>>> some tightly constrained functions. E.g., you may have a
>>> database containing encrypted salaries but be willing to
>>> provide an average salary. (Setting aside the crypto this is
>>> actually a hard problem to solve since a series of careful
>>> queries may reveal individual information. But at a minimum
>>> you could have a function that makes sure there's at least a
>>> dozen data points, decrypts them, then averages them.)
>>>
>>> The standard crypto extension provides a bit of this but we
>>> really want to be able to toss BouncyCastle onto the jar
>>> path. I've started playing with it but some key standard
>>> Jave-SE classes are missing.
>>>
>>>
>>>
>>> On Sun, Jan 13, 2013 at 3:15 PM, Hal Hildebrand
>>> <hal.hildebrand at me.com <mailto:hal.hildebrand at me.com>> wrote:
>>>
>>> Oddly enough, I also created a maven plugin for pljava.
>>>
>>> Sent from my Tricorder
>>>
>>> On Jan 13, 2013, at 11:34 AM, Thomas Hallgren
>>> <thomas at tada.se <mailto:thomas at tada.se>> wrote:
>>>
>>> > On 2013-01-13 19:20, Thomas Hallgren wrote:
>>> >> On 2013-01-13 18:10, Hal Hildebrand wrote:
>>> >>> Is the break out of the maven modules acceptable?
>>> >>
>>> >> Yes, although I'd prefer if the module named 'jdbc'
>>> was named 'plugin' or 'module'
>>> >
>>> > On second thought, 'plugin' is a bad name. We might
>>> want to create a maven plug-in for pljava at some point.
>>> What about 'server' to signify that this is the part
>>> that runs in the server?
>>> >
>>> > - thomas
>>> _______________________________________________
>>> Pljava-dev mailing list
>>> Pljava-dev at pgfoundry.org <mailto:Pljava-dev at pgfoundry.org>
>>> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
>>>
>>>
>>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20130115/ac074266/attachment.html>