isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <>
Subject Re: [DISCUSSION] Making releases easier and more frequent
Date Tue, 04 Dec 2012 19:46:31 GMT
On 3 December 2012 23:00, Robert Matthews <>wrote:

> It's all looking clearer now.  A few more points though:-
> slowly getting there...

> 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).

Updated wiki page, now singular.

> 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?
> That statement on the wiki page (referring to an 'unreleased'
subdirectory) was out of date.

Instead, I think what we're saying is simply: we have a bunch of
components; each of these is potentially separately releasable; we'll
document their release status/date clearly  (indeed, I've already started
on this, see [1]).

I've updated the wiki page to this effect.

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.

My understanding is that version ranges are no longer encouraged in Maven,
even though they aren't officially deprecated.  I can tell you that
DataNucleus (for JDO) does use version ranges, and it causes us a few
difficulties in places [2]

I'd rather we didn't use version ranges... if we did then it would require
us to lock down the core and maintain strict backward compatibility at all
times.  This isn't a constraint I particularly want to impose on myself
just yet.

Rather, I see the process similar to the way I originally described it: one
of the committers wants to put out a new "edition" with the latest and
greatest of their components (Scimpi/NoSQL, say).  This might have required
a few changes to core to support it.

The committer prepares several releases to be voted on: one for core, and
one for each of their components.  The components refer to the exact
version of the core that they are compatible with.

If another committer wants to push out a release of their components for
this version of core, they can either co-ordinate with the first committer
or they can simply push out a release of their components at any time
thereafter the core release has gone through.

I'd like to suggest we at least start with the above process, and only
refine it if it doesn't work well enough for us?

> 4. Didn't Kevin say he was still using the HTML viewer? You still have it
> down for retirement.
I had thought the opposite, but I'm happy to keep it in for now.  We can
assess all of the components in 18 months or so, say, to see which have
actually been released, and do a tidy up then if either Wicket or Scimpi
has fully replaced it.

To avoid confusion, I've updated the wiki page, removing this statement
about retiring this module.

> 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.

Again, this related to an earlier version when I was proposing these
components were bundled as part of core.

This is now fixed... as you say, their groupId should and does now relate
to the component type.

As I was updating the wiki, a few other things occurred to me that I want
to highlight:

* just to flag it: there are two exceptions to this idea that components
are released separately from core: (a) the default progmodel, and (b) the
identity bytecode.  I don't have a problem with this, but yell if you do.

* I'd like to rename oai.core:isis-core to oai.core:isis-metamodel.  Two
reasons: first, I always think of this stuff as mostly being about the
metamodel, and second, it'll disambiguate the word "core" to mean a set of
artifacts with "core" as their groupId, (rather than one particular
artifact within that groupId)

* I think the way in which we handle release process is to split the
current parent oai:isis pom into two:
   -  oai:isis-parent will be the *ultimate *parent of all modules, hence
will define release management confirmation, but will not be an
aggregagator (will have no <modules> element)
   - oai.core:isis will be the aggregator for all the groupId=core
artifacts, ie it WILL have the <modules> element.  Its parent will be

* similarly, the other components will have their own analogous top-level
pom.  For example, oai.viewer:isis-scimpi-viewer will be an aggregator that
will reference the isis-scimpi-viewer-dispatcher and
isis-scimpi-viewer-servlet artifacts via its <modules>, and will have
parented by oai:isis-parent.


> Regards
> Rob

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