See below. I've deleted much of the thread, but the relevant bit remains.
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, December 04, 2006 6:13 AM > To: users@maven.apache.org > Subject: RE: MAVEN_INSTALL_DIR/conf/settings.xml > > > [ some stuff deleted ] > > (Where are the gears grinding?) > > I see: You have a build that has a dependency that relates to > build-time. > Despite the fact that Maven creates it artifacts and install > them in a local repository, there is some other thing in your > corporate environment that it is time conscience. > > If this is the case then what would be case if you are build > with Apache Ant, then this build-time dependency will still > exist regardless of the infrastructure technology. > > I am not sure, then, if Maven can solve this, especially f > you cannot isolate the build-time dependency. > > Having said, I think a user-profile related dependency can be > a problem for you. If you a user-profile that shared between > teams, divisions, departments then the environment variables > can be changed ad hoc. Therefore again Maven cannot Perhaps I mis-stated a bit. There is not a time dependency. There are two ways that we invoke maven. The first is with the mvn command, to do the java build. The second is later, after the mvn build has created the local repository, where we invoke a maven <copy> ant task to fetch some artifacts from the local repository. The fetching from the local repository is so we can build an install file using a commercial tool for building a GUI installer. We have no problem specifying a repository when initially calling mvn. We just use the mvn command line either to directly specify the repository location using -D, or use the -s argument to specify the location of the settings.xml file that in turn specifies the location of the local repository. The trouble is, the <copy> task will only look in ~/.m2/settings.xml. If we are limited to use of ~/.m2/settings.xml for specifying the location of the local repository, then a second build of a different product, BY THE SAME USER before the first build is finished, will clobber the local repository of the first build. Thus we are stuck with using the same settings.xml file for all builds done by one user, and therefore also the same local repository for all builds done by one user. The only way to have one user do multiple builds at the same time is to put the local repository on a local partition such as /tmp or /var/tmp or some such. Then, at least, we can do one build per machine per user. This is really wasteful of machine resources, however. --Marilyn > > > I've filed the JIRA request. I got the automated acknowledgment > > (MNG-2684), but that's all so far. > > --Marilyn > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
