incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Seaborne (Commented) (JIRA)" <>
Subject [jira] [Commented] (JENA-191) Jena module structure and build
Date Wed, 29 Feb 2012 21:23:57 GMT


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.

(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:
>             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:!default.jspa
For more information on JIRA, see:


View raw message