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 Fri, 07 Dec 2012 08:56:32 GMT
On 7 December 2012 08:54, Dan Haywood <dan@haywood-associates.co.uk> wrote:

>
>
> There was one issue that came up during this work, to do with
> oai.core:isis-integtestsupport module's dependencies.  I'll comment on that
> in a separate post.
>
>
>
... so, let me comment on this here.

To back up a bit... the idea of integtestsupport is to allow the developer
to run up an instance of Isis within a unit test, with a minimum of effort.
 This would use default components and allow alternative components - eg
security, objectstore, profilestore etc - to be substituted in.

For example, Jeroen is using this actively right now in testing Estatio
app.  He runs the integration tests with the JDO objectstore, and then
exercises the domain application using the JDO repositories.  It works
really well.

Anyway, back to the issue.  The oai.core:isis-integtestsupport module
currently has dependencies on the inmemory objectstore, inmemory
profilestore and the noop security components: in order to be able to
instantiate Isis with aforesaid minimum of effort.  As things stand, I've
moved these components back into core.

One thought I had was that we should actually move these default
implementations into the integtestsupport module itself? In other words,
other that for testing purposes I don't know that anyone would actually use
these components in a production system.  I'm not 100% convinced myself
it's the right thing to do, but thought it worthy of mention.

There are two other alternatives: move integtestsupport out of core, or
alternatively, to require the developer to explicitly specify the
components it should use.  Neither of these particularly appeals to me.

As a first pass, I'm going to keep these modules in core.  None of this is
irreversible, so I'd rather just do the change and then we can evaluate
whether we like it or not.

Dan

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