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