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 <[email protected]> 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 <[email protected]> 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
