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