Prepare result jars/maven modules for use in Java Platform Module System (JPMS).

[AndreasWBartels]

Hey,

Please prepare the result jars/maven modules postgres-jdbc and postgis-geometry for use in Java Platform Module System (JPMS).

With version 2.5.0 the jars are no longer usable in projects that JPMS use.

This was done with this step: #79 Decoupled geometry and encoder/decoder from postgres-jdbc

• Introduced postgis-geometry module which now contain geometry classes, parser, and encoder/decoder

Because we have now to jars/JPMS modules, who use the same package path.

a) Migrate to JPMS modules or add Automatic-Module-Name b) Solve shared package problem c) may solve #32 repackage classes as net.postgis instead of org.postgis

[phillipross]

If I'm not mistaken, adding Automatic-Module-Name alone would not address the shared package issue. The next major version will refactor code, packages, etc and use JPMS properly.

The current shared package issue arose from a short term requirement to decouple the postgis geometry and parsing from the postgis jdbc driver itself, but required backwards compatibilty. The next major version will have the luxury of being able to break backward compatibility allowing much cleaner and more straightforward approach to organizing functionality, code, modules, artifacts, etc while targeting more modern JDKs.

[AndreasWBartels]

You are right with, adding Automatic-Module-Name alone would not address the shared package issue.

Solving the shared package issue. Is the main problem, to make 2.5.0 usable with JPMS.

Adding Automatic-Module-Name, is an alternative to support IDEs and build systems to create a stable buildpath, if there is no plan to migrate the modules to JPMS modules.

"The next major version will have the luxury of being able to break backward compatibility", did this address Version 3.0.0? Exists a release or time plan?

Would it be possible to ship 2.5.0 as postgis-jdbc-all maven module to make the other changes usable for projects that use JPMS? The module postgis-jdbc-all should contain postgis-jdbc and postgis-geometry. If so, adding the Automatic-Module-Name property would be nice.

[phillipross]

The next major version will be 3.x, yes. And this next major version unfortunately has been stuck in the planning stages for quite awhile as there's a lot of things to consider.

The idea of a new module named postgis-jdbc-all for a 2.6.x release sounds like a workable idea. It could probably be done without breaking compatibility and simply being a module that uses maven share plugin to combine the jdbc and geometry module contents into a single artifact. Is this something you'd be capable and willing to help with? Contributions would be very welcome!

[soc]

@phillipross I'm wondering – would it make sense to bundle the fix of this issue plus the package rename (#32) into a new major version, instead of trying to fix this in a possibly more compatibility-endangering changes in 2.x?

(My thinking is that the package rename is a breaking change anyway, so whatever change is necessary to resolve this issue might not add too much pain on top of that.)

... and then "this next major version unfortunately has been stuck in the planning stages for quite awhile" could be 4.x?

If you think this makes sense, I'm happy to look into #32/#84.

[phillipross]

@soc it does make sense, and I'd already begun to formulate things this way, but every week I keep getting stalled by unrelated projects 😆

One other thing that I was planning for the next major release was to NOT continue with the major release number as 3, but of something else... maybe the year 2020 or something. While I'm not completely sure of the implications of time-based releases, I wanted to get away from the confusion that release v2 was for postgis v2, and upcoming v3 would be postgis v3. The major version numbers are not meant to coincide with the postgis release numbers at all, but many people mistakenly assume that the major version numbers imply compatibility. The postgres jdbc driver ran into this issue and chose to increment the major release version to some arbitrary number and chose v42 (ala hitchhikers guide to the galaxy) but didn't take into account that the number 42 also happen to coincide with a jdbc specification version and now some mistakenly assume the 42.x jdbc drivers support jdbc v4.2 🤣

I was thinking changing the major version number to the current year would be harmless enough while fulfilling the goals. Any thoughts on this?

[soc]

Interesting idea – I think you would still need some kind of version particle that indicates the targeted postgis version.

Also, having time-based versions would really mess with Maven plugins that check your Maven dependencies for newer versions, because these tools don't understand the versioning scheme.

But I guess that's the same with the "normal" versioning – if the tools saw 2.6 (targeted at postgis 2) and 3.2 (targeted at postgis 3), it would list 3.2 as the "latest" version, even the current version was e. g. 2.4.

Edit: But yeah, something like 20200818-postgis2 would probably work. (The dependency checker things are broken either way.) It's similar to what the Postgres driver does with JDBC versions: https://jdbc.postgresql.org/download.html

[phillipross]

That's correct. I figured all of this would be solved by totally decoupling the postgis java release version from the postgis supported version. As it stands right now, postgis-java is very compatible with even the oldest pre 1.0 postgis releases and older unsupported versions of Postgres. There's even more backwards compatibility maintained than the postgres jdbc driver itself. Decoupling the postgis-java artifact versions from the postgis release versions or any other versions of anything is really the way to go. Well-maintained documentation with support matrices mentioning postgres versions, postgis versions, postgis-java versions, and other affiliated projects can bridge the gap.

[soc]

Sounds good! The only question remaining is how to distinguish major releases from minor ones with a date-based versioning scheme.

Apart from that, do you have any big plans for 2.x that would be painful to keep in sync, if there was a new branch that did the renaming and the Java module system fixes?

[phillipross]

Sounds good! The only question remaining is how to distinguish major releases from minor ones with a date-based versioning scheme.

Something that seems to work for other projects is to break out of strict semantic versioning scheme and do a YEAR.MAJOR.MINOR.PATCH versioning scheme.

Apart from that, do you have any big plans for 2.x that would be painful to keep in sync, if there was a new branch that did the renaming and the Java module system fixes?

There were basically no plans for v2.x. There are a few unfiled issues pertaining to road map that I had floating around outside of github, but I've not had time to marshal them into github issues or any kind of roadmap that would make sense. The requirement to make postgis-java work with JPMS projects came up and my idea of a separate maven module that would transform the existing modules via maven-shade-plugin was just an idea that would maintain compatibility (for existing modules) and provide a way to get the package sharing out of the mix so minimal JPMS could be utilized. Other than that, there were no real plans for current v2.

[soc]

YEAR.MAJOR.MINOR.PATCH versioning scheme

But wouldn't you then have the same issue with the major version being misinterpreted as before? I guess you could also just pick another random number (except 42). :-)

Anyway, what about me starting a branch with the package rename and the module fixes, and you pick whatever version scheme you prefer? :-)

[phillipross]

I would say there's much less chance of confusion if the leading number is easily recognized as corresponding to a year. The "major version" would restart at 1 again every year, and maybe shouldn't be called "major version" any more since it's not so major anymore if it's preceded by the year. It's only major in that it would indicate that there may be breaking changes. Of course, this is also something that can be spelled out within documentation, but adding the year to the version scheme seems to be a low-cost way to add an extra indicator in there that the version numbers do not correspond to postgres version.

[soc]

@phillipross https://github.com/postgis/postgis-java/pull/85.

[soc]

This should be fixed in the upcoming 2020-series releases!

[soc]

Hey @phillipross, this could be closed (https://github.com/postgis/postgis-java/issues/32 too), right?

That only leaves one issue in the existing milestone ... what's the chance to get a release out?

(Though perhaps it makes sense to update JTS first, as version 1.17.0 had an incompatible change.) EDIT: See https://github.com/postgis/postgis-java/pull/91.

[phillipross]

If this issue and #32 are both addressed by commits in master, I would say the issues are closable, yes.

If anybody is waiting on a release, I think it would be fine to cut a release with what is on master now WITHOUT addressing issue #90 which may actually be inappropriately assigned to the 2020.1.0 milestone at this point. The name of the milestone may actually not be appropriate either given that we're now in y2021, so I'll rearrange the issues and milestones too.

I saw the PR for the JTS update and the PR for the CI update, which also reminds me that this repo would be better served by Github Actions as well. I'll see about merging these PRs but if travis-ci creates more work than necessary then I'll switch over to Github Actions.