isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <...@haywood-associates.co.uk>
Subject Re: [DISCUSSION] Making releases easier and more frequent
Date Sun, 02 Dec 2012 15:44:51 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message