good points, Rob. Within... On 30 November 2012 19:24, Robert Matthews <[email protected]>wrote:
> I've been looking through the wiki page again at the naming. As a > comparison here are some of the Maven modules:- > > > When I look at this list, several things strike me:- > > 1) on the whole it's clean and consice, yet clear what each module is. > 2) the artifact id tells me everything I want to know about that module: > it tells me that it's part of Maven; whether it's a core part or a plugin; > and what the module is for. The group id actually adds nothing, it just > indicates who's responsible for that module. > 3) the artifact ids read easily, for example, the maven-compiler-plugin is > the Maven compiler plugin (as we say in the UK it does what it says on the > tin). > > ok, I take all that on board. > After these observation I would like to suggest the following:- > > 1) we don't need a proliferation of group ids - is it part of the core or > not. > OK, but I do think we could be a little bit more descriptive. I would like to suggest it's either core, or its an objectstore, or its a viewer etc... (More on this in a subsequent post to this thread). > 2) the names we use should read clearly, the JDO module is an object > store, so say that - ie., isis-jdo-objectstore, and not > isis-objectstore-jdo. Also this groups the components that use the same > technology, eg isis-sql-objectstore, isis-sql-security and > isis-sql-profilestore all reflect my choice to use a SQL database (if I'm > using SQL persistence then I probably want to use it for everything). > OK, I take that on board. However, in terms of directory names, I do have a preference for the component-type format (eg objectstore-jdo). That means that when I do an "ls" or a "dir", that things are not a complete jumble. > 3) non-standard abbreviations should be avoided. Can we call default > modules "default" rather than "dflt". I know you can't do the same thing > for package names, but that's fine. An alternative is to use the term > "fallback", "basic" or "simple". > OK. See subsequent post where I've updated the wiki page once more. I have now banished "dflt", in favour of choosing names that are more descriptive. > > Not directly related, but I'm still not sure about the runtime modules. > Actually I'm confused. What are they all about, what is a "runtime > runtime"? When I look at the list of core Maven modules they seem to relate > to my understanding of how Maven works. With Isis i just know I need > everything to make it work. Not a good advert for encouraging others to > get involved in the core. > OK, and so this is a concern to me. If you - who after all, wrote lots of the original code - are confused by the code structure, then that's a major impediment to others grokking it. I must take some of the blame here - I do know I have a tendency to overcomplicate on occasion. So, see my next posting where I've tried to address this ... by consolidating a number of the modules that are probably just too fine-grained. > Rob > > PS don't retire the XML store, I'm always making use of it. > > OK. I made a mistake in the wiki... intended to say should we retire just the XML *profile* store. Any component being actively used should of course live on. > > > > On 11/30/12 16:52, Dan Haywood wrote: > >> ... and, for the same reason, probably should add the component type there >> also, as suggested by both Rob and Minto. Else, "isis-sql" might be the >> object store, or might be a security impl. >> >> I guess the artifactIds are a bit long as a result, but better that than >> ambiguity and the possibility of clashes. >> >> On 30 November 2012 16:46, Dan Haywood <[email protected]> >> wrote: >> >> Ah, ok. Yeah, that does make sense... I do indeed stand corrected. >>> >>> In that case, we probably should follow the convention of other >>> frameworks. Let me go update that wiki page now [1]. >>> >>> Thx >>> 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 16:43, Rafael Chaves <[email protected]> wrote: >>> >>> Dan, I never mentioned a manual process. In the process of packaging a >>>> Java >>>> app, the common scenario is that all dependencies are fetched and placed >>>> in >>>> a single directory (for instance, the WEB-INF/lib dir for JEE webapps). >>>> Once a Java application is packaged, Maven groups disappear. No >>>> surprise, >>>> since Maven is a development/build time tool only. It is then that a >>>> common >>>> prefix makes a big difference. >>>> >>>> Hope it was clear now. Cheers, >>>> >>>> Rafael >>>> >>>> A J2EE webapp I know fetches As part of the build process all the >>>> dependencies used by the application (be it a web app, are >>>> (automatically) >>>> fetched into >>>> >>>> On Fri, Nov 30, 2012 at 8:31 AM, Dan Haywood >>>> <[email protected]>**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> >>>> >>> >>> >
