You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by christopher-johnson <gi...@git.apache.org> on 2018/04/15 15:40:01 UTC
[GitHub] jena pull request #399: [JENA-1524] renames jena-arq org.apache.jena.system ...
GitHub user christopher-johnson opened a pull request:
https://github.com/apache/jena/pull/399
[JENA-1524] renames jena-arq org.apache.jena.system to org.apache.jena.sys
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](https://docs.oracle.com/javase/10/docs/api/java/lang/module/ModuleFinder.html#of(java.nio.file.Path...)). These names are consistent with semantics described in [this specification](https://docs.oracle.com/javase/specs/jls/se10/html/jls-6.html#jls-6.5) and follow the conventions of other Apache projects like `org.apache.commons.io`
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/christopher-johnson/jena split-system
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/jena/pull/399.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #399
----
commit ee9fd831f588d02b500a78811b9a78c418cfc89e
Author: Christopher Hanna Johnson <ch...@...>
Date: 2018-04-15T13:35:51Z
[JENA-1524] renames jena-arq org.apache.jena.system to org.apache.jena.sys
adds Automatic-Module-Name to manifestEntries
----
---
[GitHub] jena issue #399: [JENA-1524] renames jena-arq org.apache.jena.system to org....
Posted by christopher-johnson <gi...@git.apache.org>.
Github user christopher-johnson commented on the issue:
https://github.com/apache/jena/pull/399
See https://github.com/apache/jena/pull/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?
---
[GitHub] jena issue #399: [JENA-1524] renames jena-arq org.apache.jena.system to org....
Posted by afs <gi...@git.apache.org>.
Github user afs commented on the issue:
https://github.com/apache/jena/pull/399
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.
---
[GitHub] jena issue #399: [JENA-1524] renames jena-arq org.apache.jena.system to org....
Posted by christopher-johnson <gi...@git.apache.org>.
Github user christopher-johnson commented on the issue:
https://github.com/apache/jena/pull/399
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.
---
[GitHub] jena pull request #399: [JENA-1524] renames jena-arq org.apache.jena.system ...
Posted by christopher-johnson <gi...@git.apache.org>.
Github user christopher-johnson closed the pull request at:
https://github.com/apache/jena/pull/399
---