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