isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Matthews <rmatth...@nakedobjects.org>
Subject Re: [DISCUSSION] Making releases easier and more frequent
Date Sun, 02 Dec 2012 20:02:34 GMT
Dan,

Can you be more explicit about the core and runtime submodules. There 
was an idea in there that there could be another way of building the 
core; would that be affected?

Rob

On 12/02/12 15:44, Dan Haywood wrote:
> Hmm... I'm not sure myself on this point.
>
> If we expect that the typical route into the framework is via our
> archetypes, then we probably can keep the component implementations out of
> core.  This isn't just the objectstore, also the profilestore and the two
> security components (authentication and authorization).  After all, the
> whole point of archetypes is to preassemble selected components.
>
> On the other hand, if users don't use archetypes, then it's a lot of stuff
> to explain and have them assemble.  It also means that we'd be routinely
> doing votes for the release of the in-memory object store or the no-op
> authentication manager (just to keep these simple components in sync with
> the releases of the core).
>
> On balance, I'm probably with you Kevin: keep all module implementations
> out of core and rely solely on archetypes as the entry point into the
> framework.  This would mean that the directory structure you suggest works.
>
>
> Still interested in more opinions on this thread.  For example, does anyone
> have an objection to my amalgamating the various core submodules together,
> ditto the runtime submodules?
>
>
> On 2 December 2012 10:50, Kevin Meyer - KMZ <kevin@kmz.co.za> wrote:
>
>> Just a quick response:
>>
>> It's really inconsistent, but perhaps inmemory * could be included in
>> core? As a "special case"..
>>
>> *shrug*
>>
>> Regards,
>> Kevin
>>
>>
>> On 2 Dec 2012 at 10:24, Dan Haywood wrote:
>>
>>> On 2 December 2012 10:13, Kevin Meyer - KMZ <kevin@kmz.co.za> wrote:
>>>
>>>> To express my preferences:
>>>>
>>>> *) Have subdirectories for function, and help in grouping:
>>>> e.g.:
>>>> core/
>>>> security/
>>>> viewer/
>>>> objectstore/
>>>>    inmemory
>>>>    jdo
>>>>    nosql
>>>>    sql
>>>>    ...
>>>>
>>>> likewise for viewers, security, etc...
>>>>
>>>> (I think it a little inconsistent to have "viewer-wicket" at the same
>>>> directory level as "core". I think "viewer" should be at the same
>> level as
>>>> "core", but there may be consequences that I am not aware of).
>>>>
>>>>
>>> The directory groupings aren't that significant for those components that
>>> are separately released (And, of course, if they move to their own git
>>> repos, then the issue is moot).
>>>
>>> However, putting inmemory-objectstore in this directory structure IS an
>>> issue, assuming that we want to have it as part of core.  The reason is
>>> that I don't think that the <modules> tag in the parent pom can have an
>>> entry such as:
>>>
>>> <modules>
>>>    <module>core</module>
>>>    <module>runtime</module>
>>>    <module>../objectstore/inmemory</module>   <== not sure if
this is
>> doable.
>>>     ...
>>> </modules>
>>>
>>>
>>>
>>>> *) Have groupIds grouped by function (as proposed in the wiki
>>>> 2012/12/02 10h00 GMT):
>>>> o.a.i.viewer,*
>>>> o.a.i.objectstore.*
>>>>
>>>> ok, good
>>>
>>>
>>>> *) Have artifactIds gouped by technology  (as proposed in the wiki
>>>> 2012/12/02 10h00 GMT (as proposed in the wiki 2012/12/02 10h00
>>>> GMT):
>>>> isis-jdo-*
>>>> isis-sql-*
>>>> isis-nosql-*
>>>>
>>>>
>>> ok, good ... a consensus is starting to emerge on this one
>>>
>>>
>>>> *) If I understand that git does not let you pull subdirectories, then
>> I
>>>> think I would prefer if git repositories were grouped by technology
>> (e.g.
>>>> "sql, jdo",etc for datastores (which would contain the security, etc
>>>> packages). Viewers, etc, are probably not affected, are they?
>>>> Progmodel - maybe, yes (groovy vs default (java)?).
>>>> This will let me ignore (e.g. jdo) for as long as I don't need it.
>> Please
>>>> also consider those who may still have to pay per MB, like I used to!
>> ;)
>>>>
>>> I thought about doing this, but I think a better solution if we are
>> worried
>>> about such things is to use separate git repos.  Then people can just
>> pull
>>> down the repos that they want to work on.  So, can we park this proposal
>>> for now?
>>>
>>> Thx for the input
>>> Dan
>>>
>>>
>>>
>>>
>>>
>>>> If some of my preferences have inconsistent consequences: e.g.
>>>> directory structure with separate git repositories, please point this
>> out
>>>> and I'll reconsider!!
>>>>
>>>> Regards,
>>>> Kevin
>>>>
>>
>>
>>


Mime
View raw message