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