+1 Sounds also very easy for a novice. Core is the engine and describes the interfaces for components. The rest is components.
Regards, Minto Op 2-12-2012 16:44, Dan Haywood schreef: > 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 >>>> >> >> >> -- ir. ing. Minto van der Sluis Software innovator / renovator Xup BV Mobiel: +31 (0) 626 014541
