From: chap at anastigmatix.net (Chapman Flack)
Date: Sat, 05 Sep 2015 17:09:06 -0400
Subject: [Pljava-dev] PL/Java version number, and a module name
Message-ID: <55EB59F2.2000408@anastigmatix.net>

As far as Maven is concerned, it is building a version of PL/Java
called 0.0.2-SNAPSHOT.

Bear's recently contributed "Installing as Extension" documentation
alludes to PL/Java's current version being 1.4.4. I'm not completely
sure how Bear knows that, but I don't have anything better to go on. :)

Should the pom.xml be updated so there are not such vastly different
notions of what the version is?

Perhaps it should be called 1.5.0-SNAPSHOT, as things are indeed
currently happening that will probably amount to at least a minor-number
update when releasable?

Also ... naming of the maven submodules.  They all have names starting
with 'pljava' (pljava-api, pljava-examples, etc.) except for the odd one
out, 'packaging'.  mvn install will put them all into the local maven
repository, under the group id org.postgresql - so maybe the packaging
module should be renamed pljava-packaging, in respect for the org.postgresql
namespace.

I don't know whether anyone is using PL/Java at present in a way that would
actually retrieve it from a maven repository - but in principle that could
work; a package of Java stored procedures could be built as a maven project
that simply declared pljava-api as a dependency.

I don't think any of the other pljava modules would be needed as
dependencies of PL/Java-based projects, and in fact perhaps the pom.xml
should be adjusted so that only pljava-api would be deployed to any maven
repository, while the rest of the built artifacts would only be packaged up
as a PostgreSQL extension to be installed on the server.

... or maybe it does make sense to install different, pre-built,
architecture-specific versions of pljava-so in repositories, so they
are easy to retrieve and stuff into a deployable extension package
on a machine without the C tools ....

Thoughts?

-Chap