[GitHub] jena issue #411: Include TDB2 in the jena-osgi module
Github user christopher-johnson commented on the issue: https://github.com/apache/jena/pull/411 BND reads the import packages from the jar manifest, which would include the bundle requirements when deployed. The question is whether a resolver (like Aether[1] ) can locate the coordinates for transitive dependencies in a provided scope (that are not explicitly referenced bundles)? The pattern seems to be for the other provided scopes that these transitive dependency coordinates are identified explicitly (like` jsonld-java`). This could be tested with something like this: `karaf@root()> bundle:install mvn:org.apache.jena/jena-osgi:3.8.0-SNAPSHOT ` It might work, but it would have to read the pom.xml from `tbd2` and then `trans-data` in separate resolution requests. Also, not sure what happens if `trans-data`, etc. are deployed in OSGI without BND manifests. [1] http://wiki.eclipse.org/Aether/Transitive_Dependency_Resolution ---
Re: new branch for JPMS?
Hi Andy and list, Thank you for the feedback. I have been working on the Jena JPMS experiment and a rough concept be reviewed here: https://github.com/christopher-johnson/jena-redux/tree/jpms These selected modules can be built now and here is a dependency graph of jena.arq: https://raw.githubusercontent.com/christopher-johnson/jena-redux/jpms/docs/jena-arq-graph.png and here is jena.dboe https://raw.githubusercontent.com/christopher-johnson/jena-redux/jpms/docs/jena-dboe-graph.png The refactoring strategy follows the "groupid.rootpackage" convention that is expected for module resolution. Since "org.apache.jena" is the group id, ambiguity would remain for resolution within the module without a specific root identifier. So the above mentioned "uber jar" is probably not possible. Within the packages themselves, no code was actually touched. Only the imports were changed. A simple migration script could be written to help existing users change their imports. The testing apparatus is where the majority of work remains. Jigsaw/JPMS does not allow test visibility between modules, so either the abstraction has to occur either in main, or the inherited test classes need to duplicated for each module. In order to get the tests to compile, the quickest option was just to duplicate the abstracted and base test classes. This is certainly not optimal. The tests do run, but certainly not without exceptions. The EarlTest classes (like "QueryTest") also needed to be disabled because the parameterized TestCase constructor classes will not compile. To discern the testing logic requires more research and time for me. As far as the benefits, the fact is that the entire JDK is built on modules now. It is the paradigm that Oracle has decided to implement and it is here to stay (whether we like it or not). There are a lot of good reasons to develop towards modules and very few negatives. Resolving a code base's problematic dependencies can be a puzzle, but for me personally, solving puzzles is interesting. Remi Forax points out in this interview <https://youtu.be/fiFzdE_U7UA> that selling Jigsaw/JPMS is difficult because it restricts (and breaks) what can be done now, but the benefits can be reaped in the added management and design functionality that is problematic to achieve while trapped in "classpath hell". Here are a few references for further information: https://mreinhold.org/blog/jigsaw-complete http://openjdk.java.net/projects/jigsaw/spec/sotms/ Christopher Johnson Scientific Associate Universitätsbibliothek Leipzig On 27 April 2018 at 18:04, Andy Seaborne <a...@apache.org> wrote: > Such a repacking is a "Jena 4" and if we're doing Jena4 the community will > which so consider other changes as well. > > In order to experiment with JPMS, it does not need a branch in the > codebase - you can clone and develop in a separate github repository now. > There is no barrier. > > There are many users of jena and there is a significant adoption tail. A > major version bump with incompatibilities will length the tail. The project > has been there at Jena1->Jena2. The experience there informed how to go > Jena2->Jena3 - there was an RDF 1.1 change so Jena3 happened as Jena went > RDF 1.0 to RDF 1.1. > > And not all users are deep technical experts in Java. > > We have yet to see just how much JPMS is adopted and at what rate. There > has not been time yet to see what common, good practice arises. > > Maybe there are other ways to get here that do not require a lot of > change. For example - make one-uber jar of the main modules, name it > "org.apache.jena". That is evolutionary for users. > > We have automatic-module-name to help the path to JPMS. If, generally, AMN > turns out to be impractical (and it was a point of contention in the Java > community vote - a part of the resolution is "we will learn > by releasing" - JPMS is not unchanging yet). or slow in adoption, > especially in open source, I wouldn't want to waste people's time. > > An experiment can lead the change - a release, with all the questions on > users@ etc, and downstream impacts, needs t be carefully timed and I for > one would like to see the experiment first. > > On 27/04/18 16:03, Christopher Johnson wrote: > >> Hi, >> JPMS is certainly a major change. I believe that it offers enormous value >> to a codebase with strong encapsulation and as such it is similar to OSGI. >> The benefits of OSGI are well known, though the implementations are >> fraught >> with complexity. Comparatively, JPMS is relatively simple. >> > > I see a major issue of timing. What value does it bring to the current > user/application base and when? > > Andy > > Retrofitting a robust platfor
[GitHub] jena issue #411: Include TDB2 in the jena-osgi module
Github user christopher-johnson commented on the issue: https://github.com/apache/jena/pull/411 TDB2 depends on dboe-trans-data and transitively on dboe-transaction and dboe-base. Should these be added to the bundle definition as well? It hinges on whether the resolver will pull the transitives with trans-data...though since they are required, it might be clearer to add them. ---
[jira] [Updated] (JENA-1536) unsynchronized collection in jena.atlas.lib.SinkToCollection causes ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/JENA-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Johnson updated JENA-1536:
--
Attachment: (was: AtlasSinkNonSynchronizedCollectionException.txt)
> unsynchronized collection in jena.atlas.lib.SinkToCollection causes
> ArrayIndexOutOfBoundsException
> --
>
> Key: JENA-1536
> URL: https://issues.apache.org/jira/browse/JENA-1536
> Project: Apache Jena
> Issue Type: Bug
> Components: Base
> Reporter: Christopher Johnson
>Priority: Major
> Attachments: AtlasSinkNonSynchronizedCollectionException.txt
>
>
> Attached is a stack trace that shows the issue.
> [^AtlasSinkNonSynchronizedCollectionException.txt]
> This is produced by a repeated client test through
> {noformat}
> RDFConnection.update{noformat}
> via this [Trellis
> method|https://github.com/trellis-ldp/trellis/blob/master/components/triplestore/src/main/java/org/trellisldp/triplestore/TriplestoreResourceService.java#L212-L227]
> that streams quads quite fast.
> Changing the method signature to this:
> {code:java}
> @Override
> public synchronized void send(T item) { c.add(item); }{code}
> Solves the problem for me.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JENA-1536) unsynchronized collection in jena.atlas.lib.SinkToCollection causes ArrayIndexOutOfBoundsException
Christopher Johnson created JENA-1536:
-
Summary: unsynchronized collection in
jena.atlas.lib.SinkToCollection causes ArrayIndexOutOfBoundsException
Key: JENA-1536
URL: https://issues.apache.org/jira/browse/JENA-1536
Project: Apache Jena
Issue Type: Bug
Components: Base
Reporter: Christopher Johnson
Attachments: AtlasSinkNonSynchronizedCollectionException.txt,
AtlasSinkNonSynchronizedCollectionException.txt
Attached is a stack trace that shows the issue.
[^AtlasSinkNonSynchronizedCollectionException.txt]
This is produced by a repeated client test through
{noformat}
RDFConnection.update{noformat}
via this [Trellis
method|https://github.com/trellis-ldp/trellis/blob/master/components/triplestore/src/main/java/org/trellisldp/triplestore/TriplestoreResourceService.java#L212-L227]
that streams quads quite fast.
Changing the method signature to this:
{code:java}
@Override
public synchronized void send(T item) { c.add(item); }{code}
Solves the problem for me.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: new branch for JPMS?
Hi, JPMS is certainly a major change. I believe that it offers enormous value to a codebase with strong encapsulation and as such it is similar to OSGI. The benefits of OSGI are well known, though the implementations are fraught with complexity. Comparatively, JPMS is relatively simple. Retrofitting a robust platform like Jena is without question a big challenge. JPMS exposes legacy APIs, so aging dependencies (like log4j 1.x and junit4) will also need to be updated. Maintaining separate branches for the long term is indeed a headache. The branch approach provides a short term path for learning how to make the break in a major version. Ultimately, it is a question of compliance and standardization. Does Jena want to "buy into" a new global standard or risk being marginalized in the future? Regarding the composition of the branch, it could start "small". Perhaps just with arq, base, and core. These would be the root packages for those modules and the ambiguous packages could be moved under them naturally. The testing infrastructure may need a different approach (i.e. using JUnit5). Christopher On Fri, 27 Apr 2018, 15:38 Rob Vesse, <rve...@dotnetrdf.org> wrote: > I am in the same boat, this sounds like it would quickly become a > maintenance headache. We don't have the time or people to maintain more > than one branch, particularly if that branch would be a significant > refactor of the code > > I am afraid that JPMS is going to kill Java open source efforts in the > same way that .Net profiles killed .Net open source. It seems to add a lot > of complexity for developers, requires the entire ecosystem to buy in > before it is truly usable i.e. even if we refactor our modules are all our > many dependencies compliant, and doesn't seem like it adds much value to > end users at least from my perspective. > > Rob > > On 27/04/2018, 14:10, "ajs6f" <aj...@apache.org> wrote: > > I'm not sure how this new branch is supposed to work. If it "just > contains modules compliant with the JPMS and that is tested for JDK9+" but > the current (Maven) modules don't have a one-to-one correspondence with > usable JPMS modules, where are the "modules" for this new branch coming > from? > > Are you suggesting decomposing the entire package structure of the > codebase and recomposing it in a branch? On what basis would packages be > grouped? > > ajs6f > > > On Apr 26, 2018, at 2:58 PM, Christopher Johnson < > chjohnso...@gmail.com> wrote: > > > > In reference to a recent PR (https://github.com/apache/jena/pull/401), > I am > > seeking input on a process to move forward towards JDK9+ (and JPMS) > support > > in Jena. As consumers of jena apis, the applications that I am > developing > > will require JPMS support going forward, so this is an important > issue for > > my use case. > > > > What I have noticed is that there will be breaking changes required > to > > structure the code in a way that meets the JPMS "non-interference" > > specification.[1] A specific problem occurs when a module does not > contain > > a single root package (which is a typical condition in several jena > > modules). This results in an "ambiguous module reference" error. To > > resolve this ambiguity may require considerable refactoring (e.g. > moving > > org.apache.jena.riot to org.apache.jena.arq.riot). I surmise that > it is > > not possible to make these changes and maintain compatibility for > existing > > consumers > > > > What I would like to propose is a new branch that just contains > modules > > compliant with the JPMS and that is tested for JDK9+. Artifacts > produced > > from this branch could be distinguished from master artifacts with an > > appropriate appendix. > > > > Thank you for your consideration, > > Christopher Johnson > > Scientific Associate > > Universitätsbibliothek Leipzig > > > > [1] > http://openjdk.java.net/projects/jigsaw/spec/reqs/#non-interference > > > > > > >
new branch for JPMS?
In reference to a recent PR (https://github.com/apache/jena/pull/401), I am seeking input on a process to move forward towards JDK9+ (and JPMS) support in Jena. As consumers of jena apis, the applications that I am developing will require JPMS support going forward, so this is an important issue for my use case. What I have noticed is that there will be breaking changes required to structure the code in a way that meets the JPMS "non-interference" specification.[1] A specific problem occurs when a module does not contain a single root package (which is a typical condition in several jena modules). This results in an "ambiguous module reference" error. To resolve this ambiguity may require considerable refactoring (e.g. moving org.apache.jena.riot to org.apache.jena.arq.riot). I surmise that it is not possible to make these changes and maintain compatibility for existing consumers What I would like to propose is a new branch that just contains modules compliant with the JPMS and that is tested for JDK9+. Artifacts produced from this branch could be distinguished from master artifacts with an appropriate appendix. Thank you for your consideration, Christopher Johnson Scientific Associate Universitätsbibliothek Leipzig [1] http://openjdk.java.net/projects/jigsaw/spec/reqs/#non-interference
[GitHub] jena issue #401: [JENA-1524] org.apache.jena.system is split by org.apache.j...
Github user christopher-johnson commented on the issue: https://github.com/apache/jena/pull/401 a quick note here about the prospect of further restructuring to support jpms. I have learned today that if a module (e.g. `org.apache.jena.arq`) does not contain a single top level package this creates an "ambiguous module". The expectation is that the module contains a hierarchy of packages and this does not exist in the primary jena library modules, It is possible for the top package to not contain any classes, but the `module-info.java` then must explictly export every subpackage it wants to make public. With a new package hierarchy, it does not seem possible to maintain compatibility with existing implementations _and_ support modules with jena master. One possibility might be to create a new branch and produce distinct artifacts that could be used downstream. It could also be used for testing and making changes to support the new jdk methods without impacting LTS. btw, I have noticed in running the tests that there are a few issues due to jdk changes (`java.nio.Byt eBuffer`, for example). This might be a question for the dev list. ---
[GitHub] jena issue #401: [JENA-1524] org.apache.jena.system is split by org.apache.j...
Github user christopher-johnson commented on the issue: https://github.com/apache/jena/pull/401 Indeed, these dependency questions are issues that I need to solve... I would prefer to simplify the über-jar `jena-osgi` dependency of `commons.rdf.jena` by creating lean modular jena artifacts (with BND manifests), that can be managed by a downstream application more easily. I have a quick related question about the shaded-guava dependency. Would you know why `org.apache.jena.atlas.lib.cache.CacheGuava` would still be looking for `org/apache/jena/ext/com/google/common/cache/RemovalNotification` even though there are absolutely no references to the shadow redirection in the code or the build scripts? This reference to the shadow redirection is buried somewhere (perhaps in my filesystem), and I know that it is not using any local maven cache now as I built `org.apache.jena.base` in offline mode. Thanks. ---
[GitHub] jena issue #401: [JENA-1524] org.apache.jena.system is split by org.apache.j...
Github user christopher-johnson commented on the issue: https://github.com/apache/jena/pull/401 Compilation in JPMS requires a `module-info.java` and is distinct from compiling in JDK 9+. > What is the issue here? Does anything break? A quick background of the use case might help here. I have been developing JPMS support for the TrellisLDP project recently and have encountered several blocking dependency issues resulting from `jena-osgi`, which is a [transitive dependency ](https://github.com/apache/commons-rdf/blob/master/commons-rdf-jena/pom.xml#L68-L72) resulting from `org.apache.commons.rdf.jena` that is a direct dependency of the `org.trellisldp.app.triplestore` implementation. JPMS compilation is strict and cannot resolve a class-containing package sourced from multiple "parent modules" (even if the package is private).[1] A good question here that you raise is what happens if a top level package contains no classes and only exports subpackages. This requires further investigation and I do not know whether this semi-split, semi-private package, multi-module configuration works, but it is probably not advisable according to the requirements of the [specification](http://openjdk.java.net/projects/jigs aw/spec/reqs/#non-interference). Regarding this PR, I am running tests now. BTW, for me, the shaded-guava jar does not work. I do not know whether it is my IDE, JRE or the maven build configuration. At any rate, I can run tests if I replace the shaded-guava with a direct dependency. Also, `guava 21.0` does not work (without hacking) in a JDK10 because it depends on `javax.annotation.Nullable`. (it seems that `guava 24.1-jre` removes the problematic jsr-305 annotations). There seems to be an initialization/lifecycle issue that can be seen when running `TestFactoryRDF`. The first test to fail there is `factoryRDF_triple_01` with this exception `java.lang.ExceptionInInitializerError`. also `com.google.common.util.concurrent.ExecutionError: java.lang.NoClassDefFoundError: Could not initialize class org.apache.jena.riot.system.RiotLib` is reported. The preceding tests pass. It could be my issue, though as an initialization related, it could be a consequence of a the changes in this PR: `java.lang.ExceptionInInitializerError` is also produced in a test runtime use of `org.apache.jena.arq` by a `org.trellisldp.vocabulary` test: ``` java.lang.ExceptionInInitializerError org.apache.jena.riot.RDFParserBuilder.buildFactoryRDF(RDFParserBuilder.java:597) org.apache.jena.riot.RDFParserBuilder.build(RDFParserBuilder.java:569) org.apache.jena.riot.RDFParserBuilder.parse(RDFParserBuilder.java:512) org.trellisldp.vocabulary.AbstractVocabularyTest.getVocabulary(AbstractVocabularyTest.java:56) org.trellisldp.vocabulary.AbstractVocabularyTest.testVocabulary(AbstractVocabularyTest.java:62) ``` [1] https://stackoverflow.com/questions/40616739/java-9-overlapping-non-exported-packages ---
[GitHub] jena issue #401: [JENA-1524] org.apache.jena.system is split by org.apache.j...
Github user christopher-johnson commented on the issue: https://github.com/apache/jena/pull/401 re: `org.apache.jena.atlas` dependents in `org.apache.jena.arq` (namely `org.apache.jena.riot`) I attach an excerpt from a `jdep`s output looking at `jena-arq-3.7.0.jar`, sorted by package dependency. The attached just includes the packages that depend on `org.apache.jena.atlas` in `org.apache.jena.arq` This is convenient to analyse interpackage relationships (that you probably know of). It shows non-module deps as "not found", but indicates the package name. [arq-atlas-jdeps.txt](https://github.com/apache/jena/files/1939950/arq-atlas-jdeps.txt) Perhaps this is useful. I guess the atlas question is a new issue? ---
[GitHub] jena issue #401: [JENA-1524] org.apache.jena.system is split by org.apache.j...
Github user christopher-johnson commented on the issue: https://github.com/apache/jena/pull/401 the module system does not allow two distinct modules (e.g. `org.apache.jena.arq` and `org.apache.jena.base`) to export the same package (e.g. `org.apache.jena.atlas`). There are two options in this situation, 1. consolidate the package into an existing module. 2. separate the package into a new module. Option 2 is only viable when the package has no dependencies to another module that depends on it (i.e. a cyclical relationship). I think that `org.apache.jena.atlas` is not a candidate for separation from `org.apache.jena.arq` as `org.apache.jena.riot` depends on it, and `org.apache.jena.atlas` depends on `org.apache.jena.riot`, so they must be in the same module (given the existing code). I agree that there is a balance between organizational convenience and radical (presumably hierarchical) package retrofitting to support strong encapsulation. The concept of one-way dependency vectors governs modularity, but this does not necessarily agree with component semantics when implemented with package names. ---
[GitHub] jena issue #401: [JENA-1524] org.apache.jena.system is split by org.apache.j...
Github user christopher-johnson commented on the issue: https://github.com/apache/jena/pull/401 In working with the automatic modules, I have also found a split with`org.apache.jena.atlas`. This is between `org.apache.jena.arq` and `org.apache.jena.base`. Would it make sense to create a separate project and artifact for `org.apache.jena.atlas`? I realize that this sort of package refactoring is a slippery slope. However, the new module idiom was to enforce a semantic relationship between the project structure, the artifact(s) it produces and the package(s) it provides. I have found furthermore that it is consistent to name a project in accordance with the qualified module name (without the top level group). So, the traditional "-" naming semantic could be replaced in archives with a "." ---
[GitHub] jena pull request #400: [JENA-1525] Add to
Github user christopher-johnson commented on a diff in the pull request:
https://github.com/apache/jena/pull/400#discussion_r181829734
--- Diff: jena-db/pom.xml ---
@@ -75,6 +79,13 @@
org.apache.maven.plugins
maven-jar-plugin
+
+
+
+
${automatic.module.name}
--- End diff --
yes. the Automatic-Module-Name is like a qualified jar name. All of the
packages in the jena-db project will be visible with Automatic-Module-Name:
org.apache.jena.db. You would not want to split the components of
`org.apache.jena.dboe` into separate modules, so it makes sense to unify them.
It generally seems to be coherent to align the module name with a top level
package name when there is one package tree per project. It might be advisable
to make a separate jar configuration for `org.apache.jena.tbd2` that has a
matching module name (if granularity is a requirement).
---
[GitHub] jena issue #399: [JENA-1524] renames jena-arq org.apache.jena.system to 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? ---
[jira] [Commented] (JENA-1525) Add to for each jar module.
[ https://issues.apache.org/jira/browse/JENA-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438865#comment-16438865 ] Christopher Johnson commented on JENA-1525: --- PR: [https://github.com/apache/jena/pull/400] https://github.com/apache/jena/pull/400/commits/188e00e3be792e71e4839d5db269fbde71468c4c > Add to for each jar module. > - > > Key: JENA-1525 > URL: https://issues.apache.org/jira/browse/JENA-1525 > Project: Apache Jena > Issue Type: Improvement >Reporter: Andy Seaborne >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] jena pull request #401: [JENA-1524] org.apache.jena.system is split by org.a...
GitHub user christopher-johnson opened a pull request:
https://github.com/apache/jena/pull/401
[JENA-1524] org.apache.jena.system is split by org.apache.jena.arq and
org.apache.jena.core
per @afs
> this renames of "jena-core:org.apache.jena.system" as
"jena-core:org.apache.jena.sys", and puts an adapter class `JenaInit` in
"jena-arq:org.apache.jena.system" that has two functions to call the real init
and shutdown.
>
> `JenaInit` will be deprecated prior to removal quite quickly (in a very
few release cycles).
>
> This way the impact is lessened: `org.apache.jena.system.Txn` is not
repackaged. The adapter class approach does not work for calls from jena-core
to jena-arq without reflection.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/christopher-johnson/jena rename-core-system
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/jena/pull/401.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 #401
commit d82328d905b0f8ae40f60ffe800728824975
Author: Christopher Hanna Johnson <chjohnson39@...>
Date: 2018-04-15T21:24:12Z
[JENA-1524] org.apache.jena.system is split by org.apache.jena.arq and
org.apache.jena.core
---
[GitHub] jena pull request #399: [JENA-1524] renames jena-arq org.apache.jena.system ...
Github user christopher-johnson closed the pull request at: https://github.com/apache/jena/pull/399 ---
[GitHub] jena pull request #400: [JENA-1524] Add to
GitHub user christopher-johnson opened a pull request: https://github.com/apache/jena/pull/400 [JENA-1524] Add to for each jar module See comments here: https://github.com/apache/jena/pull/399 It is possible that there are more artifacts that might want this. FYI: This does not include the following top level projects: apache-jena, apache-jena-libs, apache-jena-osgi, jena-elephas, jena-examples, jena-extras, jena-fuseki1, jena-fuseki, jena-integration-tests, jena-iri, jena-jdbc, jena-maven-tools, jena-permissions, jena-sdb, jena-shaded-guava You can merge this pull request into a Git repository by running: $ git pull https://github.com/christopher-johnson/jena automatic-modules Alternatively you can review and apply these changes as the patch at: https://github.com/apache/jena/pull/400.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 #400 commit 669f75891d237f441ceab93f5083076c0a10a468 Author: Christopher Hanna Johnson <chjohnson39@...> Date: 2018-04-15T18:32:11Z [JENA-1524] Add to for each jar module ---
[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 `` 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 <chjohnson39@...> 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 ---
[jira] [Created] (JENA-1524) org.apache.jena.system is split by org.apache.jena.arq and org.apache.jena.core
Christopher Johnson created JENA-1524: - Summary: org.apache.jena.system is split by org.apache.jena.arq and org.apache.jena.core Key: JENA-1524 URL: https://issues.apache.org/jira/browse/JENA-1524 Project: Apache Jena Issue Type: Bug Components: Jena Affects Versions: Jena 3.7.0 Reporter: Christopher Johnson a JPMS module cannot require both org.apache.jena.arq and org.apache.jena.core since org.apache.jena.system can be read from both. This cannot be resolved with --patch-module since arq and core provide different implementations. Suggestion is to make a distinction by renaming system to sys in either one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
