[Pljava-dev] deployment descriptor generation

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