isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <...@haywood-associates.co.uk>
Subject Re: [DISCUSSION] Making releases easier and more frequent
Date Sun, 02 Dec 2012 20:18:01 GMT
On 2 December 2012 20:02, Robert Matthews <rmatthews@nakedobjects.org>wrote:

> Dan,
>
> Can you be more explicit about the core and runtime submodules. There was
> an idea in there that there could be another way of building the core;
> would that be affected?
>

Not sure I follow, but let me try to summarize the proposals as concisely
as I can.

The core consists of:

oai.core:isis-core                                    # the metamodel, plus
defining the main runtime APIs
oai.core:isis-cglib-bytecode                 # first of the two impls of
bytecode API, for use by objectstores
oai.core:isis-javassist-bytecode         # second of the two impls of
bytecode API, for use by objectstores
oai.core:isis-runtime                             # the default runtime impl
oai.core:isis-unittestsupport                # used by other core modules,
with scope=test
oai.core:isis-integtestsupport             # for use by tck and end-users,
with scope=test
oai.core:isis-webserver                        # for use by end-users in a
dev env

(As Jeroen identified them), the runtime components are : isis-core,
isis-runtime, isis-xxx-bytecode, the remainder are for use in the
development environment.

The above assumes that we don't bundle any default components for the
objectstore, security or viewer APIs.

For the components outside the core are separately releasable (their parent
is org.apache:apache).  In most cases these components will have
submodules.  The components are:

oia.viewer:isis-dnd-viewer
oia.viewer:isis-restfulobjects-viewer
oia.viewer:isis-scimpi-viewer
oia.viewer:isis-wicket-viewer

oia.objectstore:isis-inmemory-objectstore
oia.objectstore:isis-jdo-objectstore
oia.objectstore:isis-nosql-objectstore
oia.objectstore:isis-sql-objectstore
oia.objectstore:isis-xml-objectstore

oia.objectstore:isis-inmemory-profilestore
oia.objectstore:isis-xml-profilestore                 # not released in the
first event
oia.objectstore:isis-sql-profilestore                 # not released in the
first event

oia.security:isis-noop-security              # previously called 'dflt'
oia.security:isis-file-security
oia.security:isis-sql-security                 # not released in the first
event
oia.security:isis-ldap-security                 # not released in the first
event

To be retired:
* oia.viewer:isis-html-viewer
* oia.core:isis-monitoring

Finally, there will be archetypes:

oai.archetypes:dnd-inmemory
oai.archetypes:scimpi-nosql
oai.archetypes:wicket-restful-jdo

According to the reseach that Jeroen did, it seems feasible that we can
arrange the above into pretty much any directory structure we want.  For
example:

core/deployment/        # subdirs for: core, runtime, xxx-bytecode
core/development       # subdirs for: xxxtestsupport, webserver

components/viewers/     # subdirs for dnd, restful, scimpi, wicket,
components/objectstores/   # subdirs for inmemory, jdo, nosql, sql, xml
components/profilestores/   # subdirs for inmemory, xml, sql
components/security/   # subdirs for noop, ldap, sql

archetypes/   # subdirs for each


Hope that helps pull everything together
Dan



>
> Rob
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message