[JENA-1524] renames jena-arq org.apache.jena.system to org.apache.jena.sys

[christopher-johnson]

The changes are superficial, but will break existing implementations. The thinking pattern here is shallow, and there may be better ways to restructure the org.apache.jena.system package (like merging the split in a new project).

Since this PR is JPMS related, I also added the Automatic-Module-Name to <manifestEntries> for most of the projects. This ModuleFinder mechanism is documented here. These names are consistent with semantics described in this specification and follow the conventions of other Apache projects like org.apache.commons.io

[afs]

Hi there - could you please split out the automatic module name name part then we can get that into the codebase soon and separately from the API impact of the rest?

I've create JENA-1525 for the automatic module name.

For the package split:

The problematic classes are JenaInit (functions init() and to a lesser extent shutdown()) and the interface JenaSubsystemLifecycle in jena-core, and Txn in jena-arq. The rest of the jena-core classes are only used by extensions of Jena and by other jena components, not by applications. There is a chance 3rd party use but it is going to be very uncommon as far as I know. Serializable is jena-internal for wiring up RIOT (in jena-arq) into the code engine.

Of the classes, Txn is more important for applications, and its use encouraged in general user code. JenaInit normally isn't called by application code but can be to be sure or to force initialization before calling into internal code very early in the application startup, before proper Jena code.

I think it is less disruptive to do the split as a rename of "jena-core:org.apache.jena.system" as "jena-core:org.apache.jena.sys", then put an adapter class JenaInit in "jena-core:org.apache.jena.system" that has two functions to call the real init and shutdown. We immediately deprecate "jena-arq:JenaInit" prior to removal quite quickly (in a very few release cycles).

This way the impact is lessened: Txn is not repackaged. The adapter class approach does not work for calls from jena-core to jena-arq without reflection.

[christopher-johnson]

it may be clearer to close this PR and submit a new one with "system" to "sys" changes to org.apache.jena.core rather than try to merge with this one since there is no overlap.

[christopher-johnson]

See #401.

If I understood you correctly, the adapter jena-arq:org.apache.jena.system.JenaInit just provides a short cut for using the renamed jena-core:org.org.apache.jena.sys.JenaSystem in the context of jena-arq (for external implementations).

The jena-arq services that formerly used jena-core:org.org.apache.jena.system.JenaSystem and will now use jena-core:org.apache.jena.sys.JenaSystem will continue to do so and not change their import to the jena-arq:org.apache.jena.system.JenaInit adapter, correct?