You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "Andy Seaborne (Created) (JIRA)" <ji...@apache.org> on 2012/01/10 12:20:39 UTC
[jira] [Created] (JENA-191) Jena module structure and build
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
Re: [jira] [Commented] (JENA-191) Jena module structure and build
Posted by Andy Seaborne <an...@apache.org>.
On 29/02/12 19:19, Paolo Castagna (Commented) (JIRA) wrote:
> and
>
> /Scratch ?
> /Experimental ?
I see questions.
It does say:
[[
Move active modules from /Jena2/MOD/ to /trunk/jena-mod:
]]
/Scratch and /Experimental don't match that pattern.
Andy
[jira] [Commented] (JENA-191) Jena module structure and build
Posted by "Paolo Castagna (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JENA-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13219427#comment-13219427 ]
Paolo Castagna commented on JENA-191:
-------------------------------------
> Proposal for a first step:
> Move active modules from /Jena2/MOD/ to /trunk/jena-mod:
>
> /Jena2/IRI/trunk -> /trunk/jena-iri
> /Jena2/ARQ/trunk -> /trunk/jena-arq
> /Jena2/jena/trunk -> /trunk/jena-core
> /Jena2/TDB/trunk -> /trunk/jena-tdb
> /Jena2/Fuseki/trunk -> /trunk/jena-fuseki
> /Jena2/SDB/trunk -> /trunk/jena-sdb
> /Jena2/LARQ/trunk -> /trunk/jena-larq
> /Jena2/JenaTop/trunk -> /trunk/jena-top ?? jena-parent
> /Jena2/Examples/trunk -> /trunk/jena-examples
+1
This layout allows a single checkout and it allows to have a pom.xml in /trunk/ to drive things.
I prefer "parent", people often refers to it as the "parent" pom.xml (separate, but relevant is version numbers...)
> This leaves these alone:
>
> /dist
> /site
> /Import
and
/Scratch ?
/Experimental ?
> Jena module structure and build
> -------------------------------
>
> Key: JENA-191
> URL: https://issues.apache.org/jira/browse/JENA-191
> Project: Apache 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
[jira] [Commented] (JENA-191) Jena module structure and build
Posted by "Andy Seaborne (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JENA-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13219566#comment-13219566 ]
Andy Seaborne commented on JENA-191:
------------------------------------
Stephen - this is a first step, doing the major (disruptive) reorg , not the end game. We'll learn by experimentation.
Strong "yes" to /trunk/pom.xml driving everything -- that does not mean it has to be the parent and I don't think it should be.
The parent is an artifact that is installed; having it above other artifacts gets confusing and seems to have no advantage.
The trunk POM sets the overall version number, has the misc info (project details, scm, links, name!, not plugins or common dependencies or version details)
then it goes:
module jena-parent
module jena-iri
module jena-core
...
and jena-iri etc uses a relative path of ../jena-parent/pom.xml.
e.g. https://svn.apache.org/repos/asf/cxf/trunk/pom.xml
(note that it's modules don't all have the same parent and don't all use <relativePath>)
cxf/trunk/rt/ws/policy/pom.xml does.
> Jena module structure and build
> -------------------------------
>
> Key: JENA-191
> URL: https://issues.apache.org/jira/browse/JENA-191
> Project: Apache 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
[jira] [Commented] (JENA-191) Jena module structure and build
Posted by "Andy Seaborne (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JENA-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13219270#comment-13219270 ]
Andy Seaborne commented on JENA-191:
------------------------------------
Proposal for shuffling the existign code about as a first step:
questions:
1/ "svn mv" or "svn cp"?
2/ Do we want a root like "Jena3"?
3/ parent and top
---------------------------------------
Discussion:
1/
We can move or copy; if copy we can decide how long the old code remain in--place.
I would prefer to move the code where possible. That might be by copy, sort out the new structure then delete the old one in a single session (let's cal that a move for now - i think svn history is preserved because import->Jena2 was by copy and I see history).
2/ The proposal below puts code under /trunk, no intermediate directory. There are no plans I know of that put system outside there but (for example) Fuseki is actually a freestanding application that uses Jena, rather than a piece of fundamental code. We could have /Jena for the core system, /XYZ for other things. (Note: this is just an example: it might be nice to have a single distribution include Fuseki so that does make it fundamental code).
There are examples of every style including /trunk, and then having /extrabit/trunk.
3/ We could pull the parent in and make it a versioned-as-the-rest item. It makes it easier to change e.g. icu4j. From having tried the independent way, I'd like to use the other, in-system way (and call it "parent").
---------------------------------------
Proposal for a first step:
Move active modules from /Jena2/MOD/ to /trunk/jena-mod:
/Jena2/IRI/trunk -> /trunk/jena-iri
/Jena2/ARQ/trunk -> /trunk/jena-arq
/Jena2/jena/trunk -> /trunk/jena-core
/Jena2/TDB/trunk -> /trunk/jena-tdb
/Jena2/Fuseki/trunk -> /trunk/jena-fuseki
/Jena2/SDB/trunk -> /trunk/jena-sdb
/Jena2/LARQ/trunk -> /trunk/jena-larq
/Jena2/JenaTop/trunk -> /trunk/jena-top ?? jena-parent
/Jena2/Examples/trunk -> /trunk/jena-examples
This leaves these alone:
/dist
/site
/Import
tags (for Apache releases)
/Jena2/MODULE/tags/ABC -> /trunk/tags/ABC
branches (all I could find):
/Jena2/jena/branches/owl2/ -> /branches/owl2
/Jena2/TDB/branches/hash-ids/ -> /branches/tdb-hash-ids
> Jena module structure and build
> -------------------------------
>
> Key: JENA-191
> URL: https://issues.apache.org/jira/browse/JENA-191
> Project: Apache 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
[jira] [Commented] (JENA-191) Jena module structure and build
Posted by "Andy Seaborne (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JENA-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183295#comment-13183295 ]
Andy Seaborne commented on JENA-191:
------------------------------------
jena-examples - good idea. They should definitely be part of the build. How should deliver them? JENA-190
Inference engines - happy to separate out.
jena-iri - merely because its a reasonable sized, self-contained thing. People have used on it's own but we don't really highlight as an independent library so much now due to the time needed. It does have it's own way of doing tests built from XML IIRC. It uses jflex to build the parser/lexer but we run that separately and only use the generated code in the build proper.
> 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
[jira] [Commented] (JENA-191) Jena module structure and build
Posted by "Andy Seaborne (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JENA-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13188756#comment-13188756 ]
Andy Seaborne commented on JENA-191:
------------------------------------
How is this (the structure of the modules) related to ANNY23-19, which is about APIs?
> 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
[jira] [Commented] (JENA-191) Jena module structure and build
Posted by "Andy Seaborne (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JENA-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183191#comment-13183191 ]
Andy Seaborne commented on JENA-191:
------------------------------------
Simple version:
As currently except move RIOT to jena-core.
Split out atlas/jena shared as jena-commons
jena/trunk/pom.xml
jena/trunk/jena-top/pom.xml
jena/trunk/jena-iri/...
jena/trunk/jena-core/...
jena/trunk/pom.xml does a moudle build of jena-iri, jena-core, ...
jena-top is independently released as at the moment.
> 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
[jira] [Commented] (JENA-191) Jena module structure and build
Posted by "Andy Seaborne (Commented) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (JENA-191) Jena module structure and build
Posted by "Ian Dickinson (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JENA-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183251#comment-13183251 ]
Ian Dickinson commented on JENA-191:
------------------------------------
Looks like a reasonable repackaging to me. Some quick points:
* Why does -iri need to be separate, not in -commons? Does anything else re-use it?
* Inference engines: in -api, or separate? It's fairly big, iirc
* I'd like to have a place to build up a collection of examples, and we proposed jena-examples as a peer of -core, etc, but I haven't got around to creating it. I'd still like to have it in there somewhere.
> 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
[jira] [Commented] (JENA-191) Jena module structure and build
Posted by "Stephen Allen (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JENA-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13219531#comment-13219531 ]
Stephen Allen commented on JENA-191:
------------------------------------
I like the proposed single trunk layout and module naming/capitalization normalization. Being able to checkout and build everything in one go is attractive.
Also like the idea of /trunk/pom.xml to drive everything. If we have this, then do we need a jena-top or jena-parent project? Couldn't we just move those functions directly into the /trunk/pom.xml?
> Jena module structure and build
> -------------------------------
>
> Key: JENA-191
> URL: https://issues.apache.org/jira/browse/JENA-191
> Project: Apache 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
[jira] [Commented] (JENA-191) Jena module structure and build
Posted by "Andy Seaborne (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JENA-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189035#comment-13189035 ]
Andy Seaborne commented on JENA-191:
------------------------------------
Have ANY23 a plan that might include ANY23-19? If so, let's help - otherwise I don't think we should design the module structure based on a "maybe". If it turns into a concrete set of requirements we can engage with then great but at the moment, the discussion seems to be discussion. It would be interesting if they have any useful input to Jena design.
> 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
[jira] [Commented] (JENA-191) Jena module structure and build
Posted by "Paolo Castagna (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JENA-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13188987#comment-13188987 ]
Paolo Castagna commented on JENA-191:
-------------------------------------
Any23 is currently using Sesame, ANY23-19 lists the classes they are using from Sesame.
When I asked why Sesame was chosen the answer included: Maven artifact (at the time Jena did not have those) and size (in bytes) (this is still the case).
Any23 is a small project and probably they want as little and as small dependencies as possible (but you could/should ask them directly about this).
Any23 might be interested in the jena-core module which is one of the modules listed above: it will have Maven artifacts and it will be much smaller than the current "Jena".
This is why JENA-191 is "related" to ANY23-19.
> 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