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 > > On 2 Dec 2012 at 1:18, Giovanni Júnior wrote: > > > +1, except that for question a) I prefer "isis-jdo-objectstore". > > > > > > 2012/12/1 Jeroen van der Wal <[email protected]> > > > > > Wow, what a useful thread this is, thanks for all the contributions in > > > unraveling Isis (at least for me)! > > > > > > I would go for option a. > > > > > > I even like to take it a step further and move out every component in > core > > > (released or not) into it's respective folder. For the JDO objectstore > the > > > groupId would org.apache.isis.objectstore and the artifactId isis- > > > objectstore-jdo > > > > > > It's still hard for met to get why things are under core or not and > what's > > > used in every deployment (imho equals core) and what is used in > > > development. Given that thought my ideal top-level folder layout would > be > > > something like this: > > > core/ > > > applib > > > bytecode-cglib > > > bytecode-javassist > > > core > > > runtime > > > development/ > > > tck > > > unittestsupport > > > integtestsupport > > > webserver > > > objectstore/ > > > inmemory > > > jdo > > > nosql > > > sql > > > xml > > > profilestore/ > > > inmemory > > > sql > > > xml > > > progmodel/ > > > java > > > groovy > > > wrapper > > > security/ > > > ldap > > > sql > > > noop > > > file > > > viewer/ > > > bdd > > > junit > > > html > > > dnd > > > restfulobjects > > > scimpi > > > wicket > > > archetype/ > > > dnd-xml > > > scimpi-nosql > > > wicket-restful-jdo > > > retired/ > > > core/ > > > monitoring > > > > > > Still not sure if we need the retired folder though, releasing is all > about > > > picking the right combination of modules right? > > > > > > Cheers, > > > > > > Jeroen > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent > > >
