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