agora inbox for pljava-dev@postgresql.org
help / color / mirror / Atom feed[Pljava-dev] deployment descriptor generation
3+ messages / 0 participants
[nested] [flat]
* [Pljava-dev] deployment descriptor generation
@ 2013-02-20 21:46
2013-02-21 03:41 ` [Pljava-dev] deployment descriptor generation
0 siblings, 1 reply; 3+ messages in thread
From: @ 2013-02-20 21:46 UTC (permalink / raw)
Hi,
I've been playing with pljava since last summer but not really
following the recent work / move to github, etc., until now.
I was admiring the idea of autogenerating deployment descriptors
that I found in some old annotation-driven code in src/java5
that didn't seem to be quite integrated into the main build yet
and looked like it had not been worked on for some years.
Because Java 6 now has all the annotation processing stuff built
right into javac, it was not too hard to update that code so it
does not depend on any other package (like objectweb) any more,
and you just run javac and it creates your class files and a .ddr.
My employer has some paperwork for me before I can contribute
the code, but meanwhile I am trying to think out the best way
to integrate it so that history is preserved. I did not begin
with a github fork so right now the code is in our own svn repo.
I started by moving src/java5 to src/java6 since I rely on the
annotation support in 6. Catching up on the mailing list, I may
have seen that java 6 is now assumed in the mvn builds? In that
case, if you like the generating code, maybe it doesn't need to
be in a separate directory at all?
I have not worked on any build scripting, only on the code
itself. The way I have packaged it in-house is in a separate
jar named pljavac.jar (extra c on the end) that contains only the
org/postgresql/pljava/{annotation,sqlgen}/*.class files, the
META-INF/services/javax.annotation.processing.Processor file,
and its manifest has a Class-Path: entry naming the original,
unmodified pljava.jar that contains everything else.
With that, I can just javac -cp pljavac.jar *.java and it just
works. Of course it would also work fine if everything got added
right into pljava.jar.
I took the liberty of adding elements to the Function annotation
so it can now specify all of the PostgreSQL function properties
(cost, rows, leakproof, config settings, trusted/untrusted) and
adding an SQLType annotation for individual function parameters
to override the SQL type the mapper would come up with (it can
also specify a default value for the parameter). And I added an
SQLAction annotation that can supply arbitrary commands to be
included in the .ddr to create tables, etc.
I was assuming that the existing annotations were your own idea
and not specified in SQL/JRT so it would be ok to add to them,
am I right? (My library doesn't have SQL/JRT and ISO wants $320,
but I searched for "annotation" in the working drafts online
and didn't find it.)
So, while I wait on getting the paperwork squared away on this end,
is this still of interest, and if so, any thoughts on the best way
to work it into the new repository structure?
Cheers,
Chapman Flack
^ permalink raw reply [nested|flat] 3+ messages in thread
* [Pljava-dev] deployment descriptor generation
2013-02-20 21:46 [Pljava-dev] deployment descriptor generation
@ 2013-02-21 03:41 `
2013-02-21 08:47 ` [Pljava-dev] deployment descriptor generation
0 siblings, 1 reply; 3+ messages in thread
From: @ 2013-02-21 03:41 UTC (permalink / raw)
I'm sure as hell interested. As a first step - after paperwork constraints satisfied - you should import your code into a new github repo. The svn import is excellent and preserves history. I don't know what the cvs equivalent is, but the official github repo is a testament to the history preserving facilities in github.
Anyways, with that repo in hand many things are possible. I'd start with that and work from there, personally.
And, thanks. This would be cool to see.
Sent from my Tricorder
On Feb 20, 2013, at 1:46 PM, J Chapman Flack <jflack at math.purdue.edu> wrote:
>
> Hi,
>
> I've been playing with pljava since last summer but not really
> following the recent work / move to github, etc., until now.
>
> I was admiring the idea of autogenerating deployment descriptors
> that I found in some old annotation-driven code in src/java5
> that didn't seem to be quite integrated into the main build yet
> and looked like it had not been worked on for some years.
>
> Because Java 6 now has all the annotation processing stuff built
> right into javac, it was not too hard to update that code so it
> does not depend on any other package (like objectweb) any more,
> and you just run javac and it creates your class files and a .ddr.
>
> My employer has some paperwork for me before I can contribute
> the code, but meanwhile I am trying to think out the best way
> to integrate it so that history is preserved. I did not begin
> with a github fork so right now the code is in our own svn repo.
>
> I started by moving src/java5 to src/java6 since I rely on the
> annotation support in 6. Catching up on the mailing list, I may
> have seen that java 6 is now assumed in the mvn builds? In that
> case, if you like the generating code, maybe it doesn't need to
> be in a separate directory at all?
>
> I have not worked on any build scripting, only on the code
> itself. The way I have packaged it in-house is in a separate
> jar named pljavac.jar (extra c on the end) that contains only the
> org/postgresql/pljava/{annotation,sqlgen}/*.class files, the
> META-INF/services/javax.annotation.processing.Processor file,
> and its manifest has a Class-Path: entry naming the original,
> unmodified pljava.jar that contains everything else.
>
> With that, I can just javac -cp pljavac.jar *.java and it just
> works. Of course it would also work fine if everything got added
> right into pljava.jar.
>
> I took the liberty of adding elements to the Function annotation
> so it can now specify all of the PostgreSQL function properties
> (cost, rows, leakproof, config settings, trusted/untrusted) and
> adding an SQLType annotation for individual function parameters
> to override the SQL type the mapper would come up with (it can
> also specify a default value for the parameter). And I added an
> SQLAction annotation that can supply arbitrary commands to be
> included in the .ddr to create tables, etc.
>
> I was assuming that the existing annotations were your own idea
> and not specified in SQL/JRT so it would be ok to add to them,
> am I right? (My library doesn't have SQL/JRT and ISO wants $320,
> but I searched for "annotation" in the working drafts online
> and didn't find it.)
>
> So, while I wait on getting the paperwork squared away on this end,
> is this still of interest, and if so, any thoughts on the best way
> to work it into the new repository structure?
>
> Cheers,
> Chapman Flack
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at pgfoundry.org
> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
^ permalink raw reply [nested|flat] 3+ messages in thread
* [Pljava-dev] deployment descriptor generation
2013-02-20 21:46 [Pljava-dev] deployment descriptor generation
2013-02-21 03:41 ` [Pljava-dev] deployment descriptor generation
@ 2013-02-21 08:47 `
0 siblings, 0 replies; 3+ messages in thread
From: @ 2013-02-21 08:47 UTC (permalink / raw)
Very interesting indeed. And yes, you're right. The annotations are not
standard.
Ideally, I think you should base your work on the official Git clone.
The easiest way of getting this into main-stream is by forking
https://github.com/tada at GitHub. Create a local clone of the fork and
add your stuff on top of that. Commit and push back to GitHub. Then
submit a pull request so that we can review and comment/accept your work.
Thanks,
Thomas Hallgren
On 2013-02-21 04:41, Hal Hildebrand wrote:
> I'm sure as hell interested. As a first step - after paperwork constraints satisfied - you should import your code into a new github repo. The svn import is excellent and preserves history. I don't know what the cvs equivalent is, but the official github repo is a testament to the history preserving facilities in github.
>
> Anyways, with that repo in hand many things are possible. I'd start with that and work from there, personally.
>
> And, thanks. This would be cool to see.
>
> Sent from my Tricorder
>
> On Feb 20, 2013, at 1:46 PM, J Chapman Flack <jflack at math.purdue.edu> wrote:
>
>> Hi,
>>
>> I've been playing with pljava since last summer but not really
>> following the recent work / move to github, etc., until now.
>>
>> I was admiring the idea of autogenerating deployment descriptors
>> that I found in some old annotation-driven code in src/java5
>> that didn't seem to be quite integrated into the main build yet
>> and looked like it had not been worked on for some years.
>>
>> Because Java 6 now has all the annotation processing stuff built
>> right into javac, it was not too hard to update that code so it
>> does not depend on any other package (like objectweb) any more,
>> and you just run javac and it creates your class files and a .ddr.
>>
>> My employer has some paperwork for me before I can contribute
>> the code, but meanwhile I am trying to think out the best way
>> to integrate it so that history is preserved. I did not begin
>> with a github fork so right now the code is in our own svn repo.
>>
>> I started by moving src/java5 to src/java6 since I rely on the
>> annotation support in 6. Catching up on the mailing list, I may
>> have seen that java 6 is now assumed in the mvn builds? In that
>> case, if you like the generating code, maybe it doesn't need to
>> be in a separate directory at all?
>>
>> I have not worked on any build scripting, only on the code
>> itself. The way I have packaged it in-house is in a separate
>> jar named pljavac.jar (extra c on the end) that contains only the
>> org/postgresql/pljava/{annotation,sqlgen}/*.class files, the
>> META-INF/services/javax.annotation.processing.Processor file,
>> and its manifest has a Class-Path: entry naming the original,
>> unmodified pljava.jar that contains everything else.
>>
>> With that, I can just javac -cp pljavac.jar *.java and it just
>> works. Of course it would also work fine if everything got added
>> right into pljava.jar.
>>
>> I took the liberty of adding elements to the Function annotation
>> so it can now specify all of the PostgreSQL function properties
>> (cost, rows, leakproof, config settings, trusted/untrusted) and
>> adding an SQLType annotation for individual function parameters
>> to override the SQL type the mapper would come up with (it can
>> also specify a default value for the parameter). And I added an
>> SQLAction annotation that can supply arbitrary commands to be
>> included in the .ddr to create tables, etc.
>>
>> I was assuming that the existing annotations were your own idea
>> and not specified in SQL/JRT so it would be ok to add to them,
>> am I right? (My library doesn't have SQL/JRT and ISO wants $320,
>> but I searched for "annotation" in the working drafts online
>> and didn't find it.)
>>
>> So, while I wait on getting the paperwork squared away on this end,
>> is this still of interest, and if so, any thoughts on the best way
>> to work it into the new repository structure?
>>
>> Cheers,
>> Chapman Flack
>> _______________________________________________
>> Pljava-dev mailing list
>> Pljava-dev at pgfoundry.org
>> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at pgfoundry.org
> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2013-02-21 08:47 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2013-02-20 21:46 [Pljava-dev] deployment descriptor generation
2013-02-21 03:41 `
2013-02-21 08:47 `
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox