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? 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? 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. 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
