isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeroen van der Wal <jer...@stromboli.it>
Subject Re: [DISCUSSION] Making releases easier and more frequent
Date Sun, 02 Dec 2012 21:06:20 GMT
Thanks Dan, I'm in.

I could argue about the fact that I prefer to drop the extra folder level
you added (core, components) and like singular over plural but that would
make me a pettifogger ;-)

-Jeroen

There are still some parts of the source we haven't touched:
- structure101
- examples
- domain-libs
Should we catch that right away?


On Sun, Dec 2, 2012 at 9:18 PM, Dan Haywood <dan@haywood-associates.co.uk>wrote:

> 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