On 2 December 2012 22:07, Robert Matthews <[email protected]>wrote:
> Some questions on the updated wiki page:- > > > 1) in the directory, why is 'unreleased' part of core - these are all > components. > When you wrote this, the wiki page was out of date with latest discussions. I've just updated it once more. As you'll see, the wiki page is now gone; as you say, we simply have a list of components, some of which will be released pretty quickly, some of which may never be. > 2) wouldn't all the top level poms (those for the components) be parented > by something core in Isis (refering to "As noted above, all of the > pom.xml's in these top-level directories are separately releaseable (have > org.apache:apache as their parent)."). > OK, that might be doable. Probably just need to be careful with its naming: although this parent pom would be released as part of core, then intention is that it can be used as the parent for any of the other components. I suggest something like "org.apache.isis:isis-parent". > 3) is isis-sql-objectstore-tests-**common for different sql object stores > or for different object stores generally. If not, could it refactored to > cover both cases? > > These are Kev's tests. I'd rather we develop the "tck" idea and have a set of common tests for all component types (objectstores, security, profilestores etc) > Separately, I'll review the monitoring module. I created it at some point > and need to see if it is still relevant, needs modernising or is now > completely redundant. > > OK > I'm still pondering the suggested structure, so I give my thoughts later. > Updated once more, as I say ... see the wiki page. Dan > > Rob > > > > On 12/01/12 13:44, Dan Haywood wrote: > >> 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<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<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+****<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<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 >>>> >>>> >>>> >>>> >
