Re: [DISCUSSION] Making releases easier and more frequent

[Robert Matthews]

It's all looking clearer now.  A few more points though:-
1. I know Jeroen doesn't want to be petty, but I think we should be 
consistent with our grammatical numbering. I concur with Jeroen that 
they should all be singular (which fits with the group and artifact ids).

2. The webserver module is not just for testing, it's generally 
applicable for containerless deployment. Many web apps make use of this 
allowing you run an app in an embedded Jetty instance, for example 
Jenkins allow this. Therefore it should be part of deployment, but as it 
depends on Jetty is should stay as a separate module.

2. You state, Dan, "As the table indicates, I am now proposing that we 
move the unreleased artifacts into their own subdirectory. This will 
make them easier to exclude via a Maven profile." I'm not quite sure 
which modules you are referring to. If they are potential core modules 
then the profile statement makes sense, if they are components then I 
feel I am missing something about the build process. Which is it?

3. Has anybody used the version element of the dependency element 
sufficiently to have a concrete vision of how we might effectively use 
dependency version ranges to minimise component releases. Specifically, 
how will we ensure that a small change to the core modules will not 
require new versions of all the components.

4. Didn't Kevin say he was still using the HTML viewer? You still have 
it down for retirement.

5. Why are the basic implementations like isis-file-security and 
isis-inmemory-objectstore part of the org.apache.isis.core group, yet 
are placed outside the core directory.  Surely these are just 
implementations and are not central to the framework.  While they might 
typically be used initially it is up to the archetypes to declare that.

Regards

Rob


On 12/02/12 21:06, Jeroen van der Wal wrote:
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 
<d...@haywood-associates.co.uk>wrote:

On 2 December 2012 20:02, Robert Matthews <rmatth...@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