On 8/8/05, James Mitchell <[EMAIL PROTECTED]> wrote: > > The solution, from my understanding of Maven, is to decouple the build > > environments so that they explicitly do *not* benefit from the "shared > > standardization" advantage. At an absolute minimum, that seems to > > imply separate dependency lists ... and that also seems to imply that > > I'll end up with different local repositories for each individual > > project (the default build.xml generated by "maven ant" does this ... > > see all the generated build.xml scripts in Jakarta Commons). The net > > is you end up downloading multiple versions of the servlet API even > > when the independent projects happen to share a dependency on the same > > version. > > I thought I should break in here and clear up something. Maven does not > download dependent JARs into some lib directory like the way it is done for > myfaces, the 1.2.x branch of Struts and others who use the "ant get" call. > Maven keeps it's local repository (by default) under ~/.maven/repository/ so > there is only one place for a single JAR for every project on your entire > system. > > So, in effect, you'll have *less* jars on your system then if you used the > "ant get" call to a custom "lib" directory. >
Do you think the Maven developers can be convinced to make this the default behavior for generated build.xml files? It isn't at the moment. Case in point ... I generate nightly builds for a large number of Jakarta Commons (and Commons Sandbox) projects. The standard execution path for my shell script (inside a loop) is basically (a) download the latest sources, and (b) execute "ant clean dist". Unless you manually tweak them, the Maven-generated build.xml files put the dependency downloads in a directory that gets removed by "clean" ... meaning I was needlessly downloading the same files over and over again. Just making the generated build.xml files use the standard Maven user repository would be a *huge* help to us non-believers. > > > Not ideal, but not a deal breaker ... particularly because the ability > > of a subproject to make their own decisions about dependencies is > > *much* more important than a little extra disk space. > > The current Struts maven build (where project.xml extends > ../build/project.xml, and ../build is actually an svn:external to > https://svn.apache.org/repos/asf/struts/build/trunk) was structured the way > it is simply for reuse. I knew at the time of creation that any of the > subprojects could go off and use some version of a dependency that the rest > would not. In those cases, it's easier just to keep the project.xml > extending the parent, but move the dependency to the children and customize > where appropriate. > So what should struts-faces do in detail, to avoid a dependency on Struts Core 1.3.x? > > Although, I'd be much less unhappy with Maven if it wouldn't by > > default load dependencies into a directory that gets deleted when you > > do "ant clean". You can get around that, but only by something just > > as painful as updating a local build.properties file. > > I assume you meant to say "Ant download-dependencies trick" and not "Maven" > in the sentence above. As I mentioned above, Maven 'downloads to' and keeps > the dependent JARs seperate from the build. > > I hope that clears up some misunderstandings. > See above for what bothers me about the default generated build.xml files. They don't operate the same (in this respect) as when you run Maven natively. Craig > > > -- > James Mitchell > Software Engineer / Open Source Evangelist > Consulting / Mentoring / Freelance > EdgeTech, Inc. > http://www.edgetechservices.net/ > 678.910.8017 > AIM: jmitchtx > MSN: [EMAIL PROTECTED] > Skype: jmitchtx > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
