On 3 December 2012 23:00, Robert Matthews <[email protected]>wrote:
> It's all looking clearer now. A few more points though:- > > slowly getting there... > 1. I know Jeroen doesn't want to be petty, but I think we should be > consistent with our grammatical numbering. I concur with Jeroen that they > should all be singular (which fits with the group and artifact ids). > Updated wiki page, now singular. > > 2. The webserver module is not just for testing, it's generally applicable > for containerless deployment. Many web apps make use of this allowing you > run an app in an embedded Jetty instance, for example Jenkins allow this. > Therefore it should be part of deployment, but as it depends on Jetty is > should stay as a separate module. > Moved. > > 2. You state, Dan, "As the table indicates, I am now proposing that we > move the unreleased artifacts into their own subdirectory. This will make > them easier to exclude via a Maven profile." I'm not quite sure which > modules you are referring to. If they are potential core modules then the > profile statement makes sense, if they are components then I feel I am > missing something about the build process. Which is it? > > That statement on the wiki page (referring to an 'unreleased' subdirectory) was out of date. Instead, I think what we're saying is simply: we have a bunch of components; each of these is potentially separately releasable; we'll document their release status/date clearly (indeed, I've already started on this, see [1]). I've updated the wiki page to this effect. 3. Has anybody used the version element of the dependency element > sufficiently to have a concrete vision of how we might effectively use > dependency version ranges to minimise component releases. Specifically, how > will we ensure that a small change to the core modules will not require new > versions of all the components. > My understanding is that version ranges are no longer encouraged in Maven, even though they aren't officially deprecated. I can tell you that DataNucleus (for JDO) does use version ranges, and it causes us a few difficulties in places [2] I'd rather we didn't use version ranges... if we did then it would require us to lock down the core and maintain strict backward compatibility at all times. This isn't a constraint I particularly want to impose on myself just yet. Rather, I see the process similar to the way I originally described it: one of the committers wants to put out a new "edition" with the latest and greatest of their components (Scimpi/NoSQL, say). This might have required a few changes to core to support it. The committer prepares several releases to be voted on: one for core, and one for each of their components. The components refer to the exact version of the core that they are compatible with. If another committer wants to push out a release of their components for this version of core, they can either co-ordinate with the first committer or they can simply push out a release of their components at any time thereafter the core release has gone through. I'd like to suggest we at least start with the above process, and only refine it if it doesn't work well enough for us? > > 4. Didn't Kevin say he was still using the HTML viewer? You still have it > down for retirement. > > I had thought the opposite, but I'm happy to keep it in for now. We can assess all of the components in 18 months or so, say, to see which have actually been released, and do a tidy up then if either Wicket or Scimpi has fully replaced it. To avoid confusion, I've updated the wiki page, removing this statement about retiring this module. > 5. Why are the basic implementations like isis-file-security and > isis-inmemory-objectstore part of the org.apache.isis.core group, yet are > placed outside the core directory. Surely these are just implementations > and are not central to the framework. While they might typically be used > initially it is up to the archetypes to declare that. > Again, this related to an earlier version when I was proposing these components were bundled as part of core. This is now fixed... as you say, their groupId should and does now relate to the component type. ~~~ As I was updating the wiki, a few other things occurred to me that I want to highlight: * just to flag it: there are two exceptions to this idea that components are released separately from core: (a) the default progmodel, and (b) the identity bytecode. I don't have a problem with this, but yell if you do. * I'd like to rename oai.core:isis-core to oai.core:isis-metamodel. Two reasons: first, I always think of this stuff as mostly being about the metamodel, and second, it'll disambiguate the word "core" to mean a set of artifacts with "core" as their groupId, (rather than one particular artifact within that groupId) * I think the way in which we handle release process is to split the current parent oai:isis pom into two: - oai:isis-parent will be the *ultimate *parent of all modules, hence will define release management confirmation, but will not be an aggregagator (will have no <modules> element) - oai.core:isis will be the aggregator for all the groupId=core artifacts, ie it WILL have the <modules> element. Its parent will be oai:isis-parent * similarly, the other components will have their own analogous top-level pom. For example, oai.viewer:isis-scimpi-viewer will be an aggregator that will reference the isis-scimpi-viewer-dispatcher and isis-scimpi-viewer-servlet artifacts via its <modules>, and will have parented by oai:isis-parent. Dan > Regards > > Rob > > [1] http://isis.apache.org/documentation.html [2] http://isis.apache.org/components/objectstores/jdo/hints-and-tips.html
