[
https://issues.apache.org/jira/browse/JENA-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183192#comment-13183192
]
Andy Seaborne commented on JENA-191:
------------------------------------
Sketch of a redesign version:
Redesign version:
jena-top
- parent
- refers to the Apache parent POM
- has project details (SCM, mailing lists)
- has project build configuration (plugins)
- does not have dependencies for code
- released separately.
jena-iri < jena-top
- IRI library
jena-commons < jena-top
- general non-RDF code (e.g. Iter, Cache*)
jena-core < jena-top
- depends on jena-iri, jena-commons
- Graph SPI
- ? graph memory implementation
- DatasetGraph and in memory implementation (from ARQ)
- prefix mapping
jena-riot
- parsers and writers
jena-query
- SPARQL engines.
This is quite large.
jena-api
- RDF API
- OWL API
- SPARQL API (query and update)
- SPARQL graph store
Probably a lot of the testing goes here as it uses the API.
jena-tdb
jena-sdb
jena-fuseki
> Jena module structure and build
> -------------------------------
>
> Key: JENA-191
> URL: https://issues.apache.org/jira/browse/JENA-191
> Project: Jena
> Issue Type: Brainstorming
> Reporter: Andy Seaborne
>
> The current multi-trunk, multi-module, multi-version build is good for
> independent evolution but bad for making a jena a single "thing".
> Maybe we should have a single trunk, multi-module, single source-release,
> single version number build for Jena.
> There would be a single POM in the root directory that did a module build
> (this is not the parent POM).
> Advantages:
> - The build is simpler
> Disadvantages:
> - Individual release of a module is harder.
> See also JENA-190 (delivery).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
