Hi Jeroen

Having continued reading I think I'm saying the same kind of thing as Dan. But an example should help.

At the moment we have listed the component like the SQL OS, Scimpi viewer and Wicket viewer as a set of components, so specifically the Scimpi viewer is down as o.a.i.viewer:scimpi, o.a.i.viewer:scimpi-servlet and o.a.i.viewer:scimpi-dispacther. Those submodules are just part of the Scimpi viewer and not themselves components. So the list of relevant components (as far as the outside world is concerned) would be be like this:

   isis-viewer-restful
   isis-viewer-scimpi
   isis-viewer-wicket
   isis-viewer-html

instead of this:

   isis-viewer-restful
   isis-viewer-restful-applib
   isis-viewer-restful-viewer
   isis-viewer-restful-tck
   isis-viewer-scimpi
   isis-viewer-scimpi-servlet
   isis-viewer-scimpi-dispatcher
   isis-viewer-wicket
   isis-viewer-wicket-model
   isis-viewer-wicket-ui
   isis-viewer-wicket-viewer
   isis-viewer-wicket-tck
   isis-viewer-html

Hence a component is portrayed as single entity even though internally it may be complicated and made up of many things.

Another way of putting it, is that the list we are discussing is more complicated than it needs to be because many of modules are effectively not important from main view.

I hope that helps.

Rob



On 12/02/12 18:51, Jeroen van der Wal wrote:
Hi Rob

Sorry but I don't get what you're trying to tell. Perhaps you could
elaborate or give a sample?

Cheers,

Jeroen


On Sun, Dec 2, 2012 at 7:51 PM, Robert Matthews
<[email protected]>wrote:

I think the multiple modules aspect is what is adding confusion. What our
list needs to show is what top level parts there are. So there is the core
and a number of components that work with the core.  Now as far as the
components are concerned whether they simply consist of the module that is
named or a number of modules is concerned is immaterial. What is important
is that each component is known by one name; any submodules are not
relevant and are to be seen only within the module.  The core follows this
idea to a lesser degree I think.

This means that the list being discussed probably should be shorter, and
the sub modules left out.

Does this make sense?

Rob



On 12/01/12 15:36, Dan Haywood wrote:

On 1 December 2012 14:23, Minto van der Sluis <[email protected]> wrote:

  Hmm, I get confused by the artifactIds. I see both for formats
(isis-viewer-bdd and isis-wicket-viewer).

ah, that was a typo.  the intention for artifactIds was: isis-xxx-viewer,
isis-yyy-objectstore  etc.


  I also see artifactIds with 4
sections, for instance: isis-jdo-objectstore-**metamodel. This confuses
me. Is it an objectstore or a metamodel?

ok, well... some modules (in fact, most) have more than one component.
  And
I don't think we should insist that all modules have only one component.

In this particular example, isis-jdo-objectstore-metamodel would be the
additional facet factories that are added to the metamodel that interpret
JDO-specific annotations.  That is to distinguish from, say,
isis-jdo-objectstore-**datanucleus, which is the stuff that calls the
DataNucleus' specific stuff.

But there is similar layering in isis-scimpi-viewer,
isis-restfulobjects-viewer, isis-wicket-viewer, isis-sql-objectstore.


(isis-metamodel-jdo) Also is

there really a difference between model and metamodel?
(isis-jdo-objectstore-**metamodel vs isis-wicket-viewer-model).

  Yes... there is (though even if there weren't, I'm not sure it matters
too
much ... I'd rather give the authors of individual components/modules some
latitude in how they name the individual submodules.  For example, scimpi
has isis-scimpi-dispatcher and isis-scimpi-servlet.  Anyone who wants to
get involved in enhancing scimpi would grok these particular names and why
they were chosen easily enough)

To answer your question, though... jdo's metamodel submodule is as
described above, its contributions to the Isis metamodel, whereas wicket's
model is Isis' implementation of Wicket's IModel interface.



  By the way my preference here is isis-objectstore-jdo. For the same
reason as for the proposed location (easy component grouping when
viewing directory). In my own projects I usually have my directory
location match my artifactIds.

  ok, so we now we have a couple of  distinct and different preferences in
the community.

Anyone else have an explicit preferences:
a) for the artifactId: isis-jdo-objectstore vs isis-objectstore-jdo
b) for whether artifactId = directory name


  Also, isis-scimpi-viewer needs some more attention.
  the artifactIds weren't correct ... now fixed

Thanks

Dan



  Please check out the updated version of that wiki page [1] and let me
know

your thoughts.  It's important that we get this right (I don't want to

have

to do it all over in 3 months time!!!)

Dan

[1]

  https://cwiki.apache.org/**confluence/display/ISIS/Make+**
releases+easier+and+more+**frequent<https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent>



Reply via email to