Thanks Rob, this makes sense. And I agree.

-Jeroen


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

> 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+****<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<https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent>
>>>>> >
>>>>>
>>>>>
>>>>>>
>

Reply via email to