[Pljava-dev] deployment descriptor generation

From: thomas at tada(dot)se (Thomas Hallgren)
To:
Subject: [Pljava-dev] deployment descriptor generation
Date: 2013-02-21 08:47:16
Message-ID: 5125DF14.6000400@tada.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pljava-dev

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

In response to

Browse pljava-dev by date

  From Date Subject
Next Message Thomas Hallgren 2013-02-21 23:59:17 [Pljava-dev] Functional Maven Builds!
Previous Message Hal Hildebrand 2013-02-21 03:41:23 [Pljava-dev] deployment descriptor generation