incubator-isis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Meyer" <>
Subject Re: "TCK" domain app (ISIS-108)
Date Wed, 20 Jul 2011 13:22:33 GMT
Hi Dan,

Indeed, importing the entire framework into Eclipse will solve
refactoring issues, irrespective of final layout.

I just find that workspace too cluttered and import only the modules I
care to work on (also, the rebuild is a lot quicker).

I guess it shouldn't be too difficult for me to setup a virtual parent,
outside of svn, create symlinks to the various TCK modules, and import
that. Or something..
Naturally, this is also only assuming that I'm trying to make
changes to the TCK app and not the integration test code.

Go ahead and do what you think most natural - right now I don't think
there is a wrong answer.


On Wed, July 20, 2011 11:12, Dan Haywood wrote:
> Hi Kevin,
> what I do is to import the entire framework/trunk tree into Eclipse, and
> this tree *would* include the various TCK modules.
> As things are right now in the SVN repo, the TCK modules are all in a
> single directory.  The reason I want to break it up is that -
> realistically - not every component is likely to use the TCK for a
> while.  Having the TCK together might imply to the casual browser that
> there is TCK coverage when there isn't any.
> Let me complete the commit to what I was proposing, and we can see how
> it feels.
> Cheers
> Dan
> PS: or, as an alternative, maybe we should simply delete those TCK
> modules for viewers that don't have any automated tests.
> On 20/07/2011 09:31, Kevin Meyer wrote:
>> Hi Dan,
>> I sense the usual problem of a linear file system interfering with
>> a desire to store something that conceptually belongs in two places!
>> ;)
>> I think this could work, but perhaps I would prefer if the TCK
>> application be internally complete, i.e. in Eclipse I can import 1
>> project that includes *all* TCK modules (I'm thinking about project
>> maintenance refactoring). Leaving links (either symbolic or via
>> svn:externals) doesn't quite solve this issue...
>> If we communicate well enough (and include a reference to the TCK master
>> project in the module , e.g. objectstore, documentation) we can
>> manually/intellectually be aware that each module has a tie-in to the
>> TCK application.
>> My 2c.
>> But otherwise, yes, this is a good idea.
>> Regards,
>> Kevin
>> On Wed, July 20, 2011 09:41, Dan Haywood wrote:
>>> Hi all,
>>> Just a heads-up.
>>> For the new JSON viewer (and for other viewers in the future) I want to
>>> have proper automated end-to-end tests (rather than simple unit tests).
>>> So I've hit on the idea of there being a standard "TCK" domain
>>> application (TCK = technology compatibility kit, ie for testing that
>>> new
>>> components such as viewers or object stores are compatible
>>> with/provided
>>> the same capabilities as existing viewers/object stores).
>>> Anyway... what this post is here is how to I intend to structure this
>>> TCK domain app.
>>> What I've done is use the archetype to generate a domain app; this
>>> generates multiple modules.  What I propose is that the "core" of the
>>> app (dom, fixtures and objectstore-dflt repository impls) go into an
>>> org.apache.isis.tck package (under trunk/framework/tck), but then the
>>> modules for the various viewers (dnd, html, wicket, scimpi, json,
>>> xhtml,
>>> bdd, junit) are moved out alongside the implementations to be
>>> maintained
>>> there).   Then - on a case by case/component by component basis - we
>>> can
>>> write end-to-end tests for this component and with respect to the
>>> standard TCK app.
>>> That is, in trunk/framework there will be:
>>> tck/
>>>      dom/
>>>      fixture/
>>>      objectstore-dflt/
>>> viewers/
>>>      dnd
>>>      dnd-tck    # for end-to-end tests of the DnD viewer against the
>>> TCK
>>> app (original code corresponds to the 'quickrun' module generated by
>>> the
>>> archetype)
>>>      html
>>>      html-tck  # for end-to-end tests of the HTML viewer against the
>>> TCK
>>> app (original code corresponds to the 'viewer-html' generated by the
>>> archetype)
>>>      json
>>>      json/tck   # for end-to-end tests of the JSON viewer against the
>>> TCK
>>> app (original code corresponds to the 'viewer-json' generated by the
>>> archetype)
>>>      scimpi
>>>      scimpi/tck             # etc
>>>      bdd/concordion
>>>      bdd/concordion-tck   # etc
>>>      wicket/viewer
>>>      wicket/viewer-tck   # etc
>>>      junit
>>>      junit-tck     # etc
>>>      xhtml
>>>      xhtml/tck    # etc
>>> You get the idea.
>>> Since this is new code, I don't think it'll impact anyone; but I wanted
>>> to describe here what these new modules are all about.
>>> Reply here if you have any views/modifications/improvements to this
>>> scheme.

View raw message