cowwoc wrote > Chris, > > On 18/09/2014 1:07 AM, Chris Travers wrote: >> On Wed, Sep 17, 2014 at 9:42 PM, cowwoc < > cowwoc@.darktech > > > <mailto: > cowwoc@.darktech > >> wrote: >> >> Tom, >> >> For starters, let's talk strictly about improving the deployment >> situation, which the core team *is* uniquely positioned to do. >> >> The pl/java author(s) should figure out what needs to be done but >> once that's known we need to do *something* in core so the >> deployment process is reduced to 1-2 steps max (CREATE EXTENSION >> pljava, and add Java to Postgresql's library path). >> >> >> But what the core team has done is provide a pretty stable interface >> for getting to that point. The extension interface is well documented >> and quite stable IME. If the pl/java project can't get it to a point >> where you can make && make install, then I don't see what would >> possibly benefit from getting into core. > > Bare with me for a moment while I walk you through the Windows (for > dummies) experience I had in mind. > > If you take a look at the Windows installation, it ships with > lib/hstore.dll which enables users to invoke "make extension hstore" (no > need to build anything). I'm talking about doing the same thing for > pljava. I suggest adding an optional feature in the Windows installer (I > believe it's called Application Stack Builder) for pljava. When enabled, > it would unpack lib/pljava.dll and a private JRE (so users don't have to > mess around with library paths). Users can then enable the extension > with a simple invocation of "CREATE EXTENSION pljava". What distributions of JRE are available on the Windows platform and which ones are allowed to be "privately distributed"? For this scenario your target audience is the people, at EnterpriseDB, who package the Windows installer. IIRC PostGIS is part of the builder - and it is definitely not core maintained - so pl/java should be no different. Each platform is different and the package builders should deal with making pl/java easy deploy - but the project itself needs to help facilitate that end (through code and documentation). Regardless, the core team, for reasons already stated, likely will not and should not be the maintainers of pl/java. It needs to be an extension and interface with PostgreSQL via the provided mechanisms. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819489.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
