On 30 November 2012 08:19, Minto van der Sluis <[email protected]> wrote: > > Wouldn't is be better to separate components in objstores en viewers? > Like this: > > org.apache.isis.objstores isis-objstore-sql > org.apache.isis.objstores isis-objstore-jdo > org.apache.isis.objstores isis-objstore-nosql > org.apache.isis.objstores isis-objstore-xxxxxx > org.apache.isis.viewers isis-viewer-wicket > org.apache.isis.viewers isis-viewer-restful > org.apache.isis.viewers isis-viewer-html > org.apache.isis.viewers isis-viewer-dnd > org.apache.isis.viewers isis-viewer-scimpi > org.apache.isis.viewers isis-viewer-xxxxxx > > Yes, I was thinking that too. Unlike Maven, that really only has one sort of plugin type, Isis has several (objectstores, viewer being the most significant).
> Also is security really part of the core? Or could it be like: > Well, it is, yes. In that there mus always be an authenticaiton manager and authorization manager; the 'dflt' impls are basically no-ops, allowing everything through. > > org.apache.isis.security isis-security-default > org.apache.isis.security isis-security-file > org.apache.isis.security isis-security-xxxxxx > > I think we should have security as a separate component type, analogous to viewer and objectstore. It sounds like there's an appetite to change these module names. I didn't really want to do that, because to do it properly also requires us changing the package names, which is a big and tedious job. But perhaps as a first pass we can alter the groupIds and artifactIds. Let me go back to the wiki page and collate these ideas, then go round the loop again. Dan > Regards, > > MInto > > Op 29-11-2012 23:38, Robert Matthews schreef: > > +1 for me. We'd also need a repo for the DnD. > > > > +1 for what Jeroen suggested also. > > > > While we are doing this it would be good to improve the module > > naming/identification. I have just had a look at the Maven project > > (see http://maven.apache.org/shared/index.html and > > http://maven.apache.org/plugin-management.html) and if we followed > > there lead our modules would look something like this:- > > > > GroupId ArtifactId > > ------- ---------- > > > > org.apache.isis.core isis-applib > > > > org.apache.isis.core isis-core > > org.apache.isis.core isis-bytecode > > org.apache.isis.core isis-runtime > > org.apache.isis.core isis-testsupport > > org.apache.isis.core isis-webapp > > org.apache.isis.core isis-webserver > > org.apache.isis.core isis-progmodel > > org.apache.isis.core isis-default-progmodel > > org.apache.isis.core isis-default-security > > org.apache.isis.core isis-file-security > > org.apache.isis.core isis-compatibility (was tck) > > org.apache.isis.core isis-xxxxxx > > > > > > org.apache.isis.components isis-sql-objectstore > > org.apache.isis.components isis-jdo-objectstore > > org.apache.isis.components isis-nosql-objectstore > > org.apache.isis.components isis-xxxxxx-objectstore > > org.apache.isis.components isis-wicket-viewer > > org.apache.isis.components isis-restful-viewer > > org.apache.isis.components isis-html-viewer > > org.apache.isis.components isis-dnd-viewer > > org.apache.isis.components isis-scimpi-viewer > > org.apache.isis.components isis-xxxxxx-viewer > > > > > > org.apache.isis.editions isis-quickstart-edition > > org.apache.isis.editions isis-modeller-edition > > org.apache.isis.editions isis-webapp-edition > > org.apache.isis.editions isis-xxxxxx-edition > > > > How does that look? > > > > Rob > > > > > > On 11/29/12 20:20, Dan Haywood wrote: > >> Hi Rob, > >> > >> Thanks for these thoughts... sounds like we are somewhat in the same > >> boat > >> in that we want to push out new releases, but don't know enough about > >> the > >> (state of the) other modules to know whether it is safe to do so. > >> > >> And so, yes, breaking up the codebase into separate submodules is the > >> obvious next step, and something that you and I have discussed several > >> times in the past off-list. I don't have any issue with doing it > >> myself, > >> it's an obvious evolution from my proposal. > >> > >> The concept of an edition, then, I think equates to an archetype: it's a > >> project template to get a would-be used up-and-running quickly with a > >> precanned set of modules. > >> > >> What I therefore suggest is that we: > >> > >> 1. wait for Infra to move our code from svn to git (soon, I hope...) > >> 2. flatten out the modules as I outlined in the wiki page > >> 3. raise another ticket for infra to create new repos for each of the > >> modules that we want to release separately... seems to me that these > >> could > >> start out as clones of the original > >> 4. when those new submodule repos exist, we can zap remove all the > >> foreign > >> stuff; conversely, in the original repo, we zap the code for which there > >> are now submodule repos > >> > >> The new repos that I see us needing are: > >> - viewer-wicket > >> - viewer-scimpi > >> - viewer-restful > >> - viewer-html > >> - objectstore-jdo > >> - objectstore-nosql > >> - objectstore-sql > >> - editions // for the various archetypes we might > >> want to > >> create. > >> > >> For the other modules that are not core (eg progmodel-groovy, or > >> viewer-junit), I'd rather leave them in the "default" repo, but not > >> release > >> them until there is a need. For these we can use a Maven profile to > >> exclude them from the release process. > >> > >> Although overall this introduces a little bit more formality into the > >> proceedings, I do think that the time is now right to do this. And, I > >> think it properly answers all the objections that Giovanni raised > >> earlier > >> in this thread. > >> > >> What say we all? > >> > >> Dan > >> > >> > >> On 29 November 2012 20:00, Robert Matthews > >> <[email protected]>wrote: > >> > >>> First and foremost, I think we should release things more granularly so > >>> individual components (most of our Maven modules) can be worked on more > >>> independently. I would find it great to be able to work on improving > >>> the > >>> NOSQL store or the Scimpi viewer without having to consider that every > >>> other module has to be got into a releasable state just so one ready > >>> module > >>> can be released. Most of the modules, outside of the core, are fairly > >>> independent, typically relying only on the core and will work other > >>> versions of other components, eg a viewer is not typically dependent > >>> on an > >>> object store. Basically, we have the core modules, which need to be > >>> maintained and released together, then we have a whole pile of major > >>> component, mostly that can be developed independently. > >>> > >>> The "editions", as I think someone referred to them, are a > >>> combination of > >>> the components that are useful together, but are just that. They are > >>> lightweight, just specifying how to pull those components together and > >>> providing supporting resources like examples, configurations and extra > >>> documentation. Think of these like Linux distributions, they pull > >>> together > >>> a host of programs together to create a, sometimes unique, set up. The > >>> distribution is just a collation of all the programs along with the > >>> installer, some specific graphics and preconfigured settings. The > >>> programs > >>> themselves are developed, and also available, separately. > >>> > >>> Instead of keeping it all monolithic and using profiles to control > >>> what is > >>> released (and what isn't) I think we should break it up into:- > >>> > >>> A "Core" > >>> Individual "Components" (viewer, object stores etc) > >>> Specially targetted "Editions" (SOA, Web Framework, Modeller's > >>> toolbox > >>> etc) > >>> > >>> This would obviously affect both the organisation of the code and be > >>> reflected in the site as a series of subprojects (like a number of > >>> Apache > >>> project do, like James, Maven, Velocity and Xerces). > >>> > >>> (Doesn't Eclipse actually something just like this - they have a core, > >>> there are are series of components that work with it and they provide > >>> different "editions" that target different types of user.) > >>> > >>> Another benefit of working this way is that a (new) developer can > >>> concentrate on a single component, i.e., check out a small amount of > >>> code, > >>> use Maven to sort of the dependencies to other framework classes, which > >>> will download the jars and then focus on just that one module. > >>> > >>> Just a few thoughts. > >>> > >>> Regards > >>> > >>> Rob > >>> > >>> > >>> > >>> > >>> On 11/29/12 14:36, Dan Haywood wrote: > >>> > >>>> This discussion post is mostly to the contributors, but cc:ing to user > >>>> list > >>>> for opinions also... > >>>> > >>>> ~~~ > >>>> > >>>> At the moment it's a daunting task to fully verify all the > >>>> components of > >>>> the framework are working correctly prior to pushing out a release. I > >>>> suppose that wouldn't be so much of a concern if we had better > >>>> automated > >>>> tests, but, hey, that's how things are. > >>>> > >>>> Moreover, frankly, some of the modules are best considered spikes and > >>>> probably don't constitute something that we would consider > >>>> production-ready. Or, at least, they haven't been used in a real-world > >>>> context, so it's not possible to say whether they are really > >>>> fit-for-purpose. I include here quite a lot of the stuff that I have > >>>> worked > >>>> on over the last few years, eg the wrapper-progmodel, the groovy > >>>> progmodel, > >>>> probably also the JUnit viewer and BDD viewer. Now that we are a > >>>> top-level > >>>> project, I'd like it that the code we put out is thought of as > >>>> production > >>>> ready. > >>>> > >>>> In order to make the framework easier to release, I propose that we > >>>> use > >>>> Maven profiles to be able to release subsets of modules, that a given > >>>> contributor can stand behind and say: "yes, those modules are > >>>> working and > >>>> are fit for general consumption". Each release would consist of the > >>>> certain > >>>> core modules, along with selected additional viewers and object > >>>> stores. > >>>> > >>>> For example, over time we might end up releasing: > >>>> > >>>> * v0.3.1 core + objectstore-jdo + viewer-wicket + > >>>> viewer-restfulobjects > >>>> // a "wicket/jdo release" - eg tested and released by Dan > >>>> > >>>> * v0.4.0 core + objectstore-nosql + viewer-scimpi // a > >>>> "scimpi/nosql > >>>> release" - eg tested and released by Rob > >>>> > >>>> * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd > >>>> // a > >>>> "dev env release" - eg tested and released by Rob > >>>> > >>>> * v0.6.0 core + objectstore-jdo + viewer-wicket + > >>>> viewer-restfulobjects > >>>> // another "wicket/jdo release" > >>>> > >>>> * v0.7.0 core + objectstore-sql + viewer-html // a "html/sql > >>>> release" > >>>> - > >>>> eg tested and released by Kevin > >>>> > >>>> * v0.8.0 core + objectstore-jdo + viewer-wicket + > >>>> viewer-restfulobjects > >>>> // another "wicket/jdo release" > >>>> > >>>> Whenever a release goes out, we would update our website to > >>>> indicate the > >>>> most recent version of the components. > >>>> > >>>> Now, when I say "release", what I actually mean here is the > >>>> deployment of > >>>> binary artifacts up to the Maven central repo. This, after all, is > >>>> what > >>>> most users/would-be users in the community would use and consider a > >>>> release. However, Apache's own formal definition of "release" is > >>>> actually > >>>> the source code release ... this is what the [VOTE] mechanism is > >>>> for. I > >>>> don't see this changing... the vote basically says that the software > >>>> complies with all the legal license stuff etc. The whole codebase is > >>>> tagged > >>>> with that release number, and the generated src.zip is a zip of this > >>>> release. > >>>> > >>>> One benefit of this is that it allows the deployment of other > >>>> modules to > >>>> be > >>>> performed "after the fact". For example, suppose that I (Dan) puts > >>>> out the > >>>> v0.3.1 release as above, and then Rob later on tests the scimpi > >>>> viewer in > >>>> that tag and finds it works well. He can (I think) push the release > >>>> of the > >>>> scimpi viewer up to Maven central repo. > >>>> > >>>> As I see things there are several benefits to this scheme: > >>>> > >>>> a) (as already noted) the user community will only see binary releases > >>>> that > >>>> are known to be of production ready. This should mitigate the "is > >>>> it safe > >>>> to use this component" worry > >>>> b) (as hinted at) it should be possible for individual contributors > >>>> to put > >>>> out releases of their modules more rapidly > >>>> c) we get visibility of which modules aren't being released; for > >>>> example, > >>>> we might say that if a module hasn't been released by anyone for 18 > >>>> or 24 > >>>> months, say, then it's probably time to remove it from the codebase. > >>>> > >>>> ~~~ > >>>> > >>>> In order to support the above scheme, I propose that we rearrange > >>>> some of > >>>> the modules so that they can be more easily included within Maven > >>>> modules. I've > >>>> created a page on our wiki [1] which shows my proposed > >>>> rearrangement. It > >>>> also repeats the above discussion text by way of context. > >>>> > >>>> > >>>> Opinions welcome! > >>>> > >>>> Thx > >>>> > >>>> Dan > >>>> > >>>> > >>>> [1] > >>>> https://cwiki.apache.org/**confluence/display/ISIS/Make+** > >>>> releases+easier+and+more+**frequent< > https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent > > > >>>> > >>>> > >>>> > > > > > -- > ir. ing. Minto van der Sluis > Software innovator / renovator > Xup BV > > Mobiel: +31 (0) 626 014541 > >
