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
