Emmanuel, Looks like your cool running - you know everything I know now, and by the looks of it you will soon be De Masta.
I'm still experimenting as well, so I'll let you know results as I complete tests. Cheers, - Ole --- Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > I gonna auto-answer some of my questions, but it > induces more other > questions :) > > > I'm playing with Maven an try to set my dream > environment : > > > - I want two repos : one for jars, one for plugins > : is it possible ? > > Definitively. There is a <repositories> element and > a > <pluginRepositories> one. Great ! > > > - I want those repos be at the same level than the > top level pom.xml : > > jars and plugins respectively : > > > > . > > .. > > /jars > > /plugins > > /project1 > > /project2 > > pom.xml > > > > and my pom.xml will contain : > > <snip/> > > > > > Is it correct ? > > Part of my new pom.xml : > <repositories> > <repository> > <id>central</id> > <name>Apache Directory Repository</name> > <url>jars</url> > <layout>default</layout> > </repository> > </repositories> > > Well, now have a problem : how do I set up the url > to point on jars. If > I go up to a subproject (like project1), then I > can't build my project, > because there is no 'jars' directory in it. So the > url should be > something like $basedir/jars, where $basedir is the > pom.xml path where > $basedir is declared. is it possible? > > > - Now, I don't want Maven to look after jars or > plugins in the outer > > world. Modifying settings.xml does not fit me, > because that means > > other users have to set it on their computer, and > tis is a global > > element. I want to disable external repos from the > top level pom.xml. > > Is it possible ? > > Don't know yet. My RTFM session was not completely > satisfying : the > "better build with maven" is a great doco, but very > general. And > browsing the web site lead me to something I > strongly desagree with : > "It is not recommended that you store your JARs in > CVS. ... With Maven > these standard utilities can be stored in your local > repository and > shared by any number of builds. > > This has the following advantages: > *1) It uses less storage" > *Who cares ??? For less than 200$, I can buy 300Go > disks. ApacheDS > repository is only 55 Mb big. This is NOTHING. > *2) It makes checking out a project quicker > *Who cares? I do check out ADS completely very often > (around once a > week), and I really think I'm very untypical. You > generally checkout a > project a few times in its whole life, and even if > it takes 10 minutes, > big deal. > *3) No need for versioning > *This is all but an advantage. This is the way to > break a configuration > managment. As you don't version, you have no way to > guarantee that a jar > you are downloading is the one which has been use > for the current > version of the product you are building. It is said > on Maven web site > that you don't need to store in CVS immutable files, > because if the file > change, its name change accordingly (junit-3.8.1.jar > -> junit-4.1.0.jar, > for instance). Badly wrong. Not that far away, many > jar's name weren't > changed. You had to look at the manifest to know > which version it was, > if the developper has put this number in it :(. IBM > Websphere is still > using this naming scheme (poor poor deployers ...). > And I have seen sooo > many times a developper modifying a jar to add the > last forgotten patch > without modifying the jar's name (and of course, > this patch break > something in your code, and of course he was subtle > enough to > re-generate the sha1 files so that its last minute > and at nigth > modification went through all the Q&A processes ...) > > Ok, ok, personnal opinion expressed... > > More RTFM to come ! I may finally adopt maven and > use it frantically :) > > > Emmanuel > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
