From: thomas at tada.se (Thomas Hallgren) Date: Thu, 21 Feb 2013 09:47:16 +0100 Subject: [Pljava-dev] deployment descriptor generation In-Reply-To: <64EF9C50-5D5A-4CAB-8B29-C52938724EF5@me.com> References: <5125444E.8020604@math.purdue.edu> <64EF9C50-5D5A-4CAB-8B29-C52938724EF5@me.com> Message-ID: <5125DF14.6000400@tada.se> 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 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