OK, so I've replied briefly to each of the most recent posts that Rob and Kevin made, and I've now gone round the loop again with the wiki page.
This time I've listed out each and every of the current modules, and proposed how they could be moved around and in many cases amalgamated in order to simplify and aid grokkability. I've also changed the artifactIds to go with (what seems generally preferred) names such as isis-jdo-objectstore. Please check out the updated version of that wiki page [1] and let me know your thoughts. It's important that we get this right (I don't want to have to do it all over in 3 months time!!!) Dan [1] https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent ~~~~~~~ On 1 December 2012 13:40, Dan Haywood <[email protected]> wrote: > > > On 30 November 2012 19:41, Kevin Meyer - KMZ <[email protected]> wrote: > >> Just to add my 2c >> >> +1 to the general idea >> >> If I understand correctly, it supports the idea of each module having its >> own version? > > > yes, that's the main idea. > > > >> So if I (for example) take my time with the sql >> objectstore, its version number will remain low. So version number is a >> true indication of the (major) improvements behind each component? >> > > We haven't talked about version numbering, that's perhaps for a different > thread. But, top of my head, I would suggest that if the core goes up as > 0.4.0, 0.5.0, 0.6.0 etc, then I'd expect the other components to track > them, eg 0.3.0, 0.4.0, 0.5.0. If a component author wants to push out a > new feature that doesn't require a bumping of core, they could then go with > 0.6.1, 0.6.2 etc. > > But, as I say, don't want to get side-tracked by that point.... there's > probably lots of equally valid ways to deal with this. > > > >> And not (like at present) each component / package / module has the >> same version, increasing with each release? >> >> As for the html-viewer.. I have one deployed application out there that >> is still using it.. so I would like to see it migrated into the new, >> renamed, format. >> Having said this - this application is also probably locked into the >> previous version of Isis (it has a custom objectstore that I can't migrate >> into the new format since the Oid changes were made), so maybe it >> doesn't matter if the html viewer is retired. >> > > OK. > > Thx > Dan > > >> >> Regards, >> Kevin >> >> On 30 Nov 2012 at 17:18, Dan Haywood wrote: >> >> > Yup, understood. I have now updated the wiki page [1], and the >> artifactIds >> > are pretty much identical to those you suggested in your mail of >> yesterday. >> > Check it out and let me know your thoughts... >> > >> > Dan >> > [1] >> > >> https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent >> > >> > On 30 November 2012 17:17, Robert Matthews <[email protected] >> >wrote: >> > >> > > It's not about building the classpath - who'd want to do that - it's >> when >> > > you have to look at what's been added to the classpath. Only >> yesterday I >> > > was looking at the references for a project in Eclipse and, as Rafael >> says, >> > > it would have been easier if they were prefixed and hence grouped and >> I >> > > would have been able to see what I was looking for immediately. >> > > >> > > Rob >> > > >> > > >> > > >> > > On 11/30/12 16:31, Dan Haywood wrote: >> > > >> > >> Yeah, I understand. But does anyone today - especially for a >> framework >> > >> such as Isis that provides Maven archetypes - build up their >> classpath by >> > >> manually assembling jars in some sort of lib/ directory? >> > >> >> > >> I'm prepared to stand corrected, but it doesn't strike me as a >> > >> particularly >> > >> common use case. Maven, of course, builds the classpath by referring >> > >> directory to the jars in the local ~/.m2 repo. >> > >> >> > >> Dan >> > >> >> > >> >> > >> On 30 November 2012 16:23, Rafael Chaves <[email protected]> >> wrote: >> > >> >> > >> Dan, >> > >>> >> > >>> That is true for a repository - but I was referring to jars used in >> an >> > >>> *application*. >> > >>> >> > >>> Spring, Hibernate, Apache Commons, Restlet, Jackson, Camel, >> virtually >> > >>> every >> > >>> multi-artifact framework I use follows this approach. When I am >> looking >> > >>> at >> > >>> a directory with a hundred Jars trying to hunt down a specific jar >> from >> > >>> one >> > >>> of those libraries, I really appreciate they did so. >> > >>> >> > >>> Yeah, the example you mentioned takes the idea too far. >> > >>> >> > >>> Cheers, >> > >>> >> > >>> Rafael >> > >>> >> > >>> On Fri, Nov 30, 2012 at 8:14 AM, Dan Haywood >> > >>> <[email protected]>**wrote: >> > >>> >> > >>> Hi Rafael, >> > >>>> hmm, not sure that's a very good motivation... the identity of a >> Maven >> > >>>> >> > >>> jar >> > >>> >> > >>>> is also the directory, ie the full path under ~/.m2/repository. >> > >>>> >> > >>>> Funnily enough, I was teaching a Maven course last week at a >> corporation >> > >>>> that shall remain nameless, and the developers there had Maven >> modules >> > >>>> >> > >>> with >> > >>> >> > >>>> a groupId of com.verybigcorp.foo.bar and an artifactId also of >> > >>>> com.verybigcorp.foo.bar. We decided that whoever chose that >> artifactId >> > >>>> hadn't understood that the identity of the artifact is the >> combination >> > >>>> of >> > >>>> the both (plus version, plus classifier), and had chosen >> artifactIds >> > >>>> >> > >>> based >> > >>> >> > >>>> on its use as the JAR name. >> > >>>> >> > >>>> Dan >> > >>>> ~~~~ >> > >>>> >> > >>>> On 30 November 2012 16:06, Rafael Chaves <[email protected]> >> > >>>> wrote: >> > >>>> >> > >>>> The artifact id ends up by default being the jar name, right? If >> that >> > >>>>> >> > >>>> is >> > >>> >> > >>>> true, I'd go with an artifact name with a common prefix across >> > >>>>> all Isis artifacts (i.e. isis-dflt). Two benefits: people using >> Isis >> > >>>>> >> > >>>> have >> > >>> >> > >>>> an easy way of identifying the Isis jars among all the other Jars >> their >> > >>>>> application uses, and easily avoids collisions with other >> people's jar >> > >>>>> names. >> > >>>>> >> > >>>>> Cheers, >> > >>>>> >> > >>>>> Rafael >> > >>>>> >> > >>>>> On Fri, Nov 30, 2012 at 5:38 AM, Dan Haywood >> > >>>>> <[email protected]>**wrote: >> > >>>>> >> > >>>>> OK, I've tried to pull together various opinions and updated the >> wiki >> > >>>>>> >> > >>>>> page >> > >>>>> >> > >>>>>> [1] >> > >>>>>> >> > >>>>>> - yes, to idea of independent, more granular releases >> > >>>>>> - yes, flatten the modules at least as an interim step >> > >>>>>> - also, rename the groupId/artifactId's >> > >>>>>> - break linkage so that separate modules so don't share >> common >> > >>>>>> >> > >>>>> parent >> > >>>> >> > >>>>> (ie are separate artifacts) >> > >>>>>> - perhaps... move the separate modules into their own git >> repos >> > >>>>>> >> > >>>>>> With respect to groupId/artifactId's, for those components (eg >> > >>>>>> >> > >>>>> objectstore, >> > >>>>> >> > >>>>>> security) where there are implementations both core and >> alternate, we >> > >>>>>> >> > >>>>> need >> > >>>>> >> > >>>>>> to decide between (eg): >> > >>>>>> >> > >>>>>> o.a.isis.core:objectstore-dflt >> > >>>>>> vs >> > >>>>>> o.a.isis.objectstore:dflt >> > >>>>>> >> > >>>>>> The former has the benefit that all the modules that come with >> core >> > >>>>>> >> > >>>>> have >> > >>>> >> > >>>>> a >> > >>>>> >> > >>>>>> common groupId; the latter has the benefit that all >> implementations, >> > >>>>>> irrespective of whether they are core or not, have the same >> groupId. >> > >>>>>> >> > >>>>> In >> > >>>> >> > >>>>> other words, does groupId represent a packaging, or does it >> represent >> > >>>>>> common functionality? >> > >>>>>> >> > >>>>>> In the wiki page shows, I've gone with the former. But I'm >> 50:50 on >> > >>>>>> >> > >>>>> this >> > >>>> >> > >>>>> myself. >> > >>>>>> >> > >>>>>> ~~~ >> > >>>>>> Buried on the wiki page are some further questions: whether to >> retire >> > >>>>>> >> > >>>>> the >> > >>>> >> > >>>>> html-viewer, the profilestore-xml, and the monitoring component. >> My >> > >>>>>> rationale for retiring html-viewer is that the wicket viewer is >> > >>>>>> >> > >>>>> similar >> > >>> >> > >>>> but >> > >>>>> >> > >>>>>> superior; I don't think profilestore-xml makes sense for webapp >> > >>>>>> >> > >>>>> viewers >> > >>> >> > >>>> (it >> > >>>>> >> > >>>>>> might have made sense for dnd viewer in client/server, but we've >> > >>>>>> >> > >>>>> already >> > >>>> >> > >>>>> removed remoting) ; and monitoring I think is a vestige of the >> > >>>>>> >> > >>>>> remoting >> > >>> >> > >>>> should also be removed. But we don't necessarily need to come to >> an >> > >>>>>> agreement on these points (though opinions would be good). >> > >>>>>> >> > >>>>>> Thanks, all >> > >>>>>> 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 >> > >> > >>> >> > >> >> > > >> > >> >> >> -- >> Kevin Meyer, PhD, Pr.Sci.Nat >> KMZ P.O. Box 9822, Sharon Park, South Africa. >> Tel: +27 11 363 2001 Cell: +27 83 346 3045 >> >> >> >
