[Pljava-dev] deployment descriptor generation

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