> One last question: how do I switch off the default behaviour of "mvn deploy"? I want to only run the deploy:deploy-file goal in the deploy > phase, and not try to deploy my empty pom with no artifacts (which I am using to configure the deploy-file).
Hmmm. It sounds to me like you're using the deploy:deploy-file goal incorrectly. You don't need a pom (empty or otherwise) to run this goal. Perhaps that's some of the confusion. If it helps, here's the bat file I use (incidentally, this file is in version control, although the jar files it references aren't): set LIBDIR=c:/home/devel/java/lib set REPOINFO=-Durl=scp://repo-server/repo-release -DrepositoryId=repo-release call mvn deploy:deploy-file %REPOINFO% -DgroupId=com.sybase -DartifactId=jconnect -Dversion=5.5.EBF11656 -Dpackaging=jar -DgeneratePom=true -Dfile=%LIBDIR%/jConnect5.5.EBF11656.jar call mvn deploy:deploy-file %REPOINFO% -DgroupId=javax.media -DartifactId=jai-core -Dversion=1.1.2 -Dpackaging=jar -DgeneratePom=true -Dfile=%LIBDIR%/jai-1.1.2 This is run in an directory containing only this file - no pom, no nothing. If you don't want to do with the repository, you could write this same script with the install:install-file goal: set LIBDIR=c:/home/devel/java/lib set REPOINFO=-Durl=scp://repo-server/repo-release -DrepositoryId=repo-release call mvn install:install-file -DgroupId=com.sybase -DartifactId=jconnect -Dversion=5.5.EBF11656 -Dpackaging=jar -DgeneratePom=true -Dfile=%LIBDIR%/jConnect5.5.EBF11656.jar call mvn install:install-file -DgroupId=javax.media -DartifactId=jai-core -Dversion=1.1.2 -Dpackaging=jar -DgeneratePom=true -Dfile=%LIBDIR%/jai-1.1.2/jai_core.jar -----Original Message----- From: Dave Syer [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2006 3:53 AM To: [email protected] Subject: RE: Automating install:install-file > I would disagree that this is somehow harder than what you're talking > about. You are correct, it is at least equally hard. However I have made some progress though with the deploy plugin. It seems there is some duplication of effort between deploy:deploy-file and install:install-file. Also the former is more robust and has a richer configuration, so it was good advice to use it. The docos for wagon are pitifully bad (possibly because of a bug in the site generation), but I managed to piece it together. The short story is: if you use <url>file://<path-to-my-local-repo></url> in the configuration for deploy-file it works pretty much the same as install-file. This is fine by me, and I can switch to ftp or scp if I ever need to (and can find some decent documentation). One last question: how do I switch off the default behaviour of "mvn deploy"? I want to only run the deploy:deploy-file goal in the deploy phase, and not try to deploy my empty pom with no artifacts (which I am using to configure the deploy-file). Is there a <packaging>none</packaging> or something in the distributionManagement section of the pom I can use? > And aren't you going to want an internal repo at some point > anyway? Maybe, but that doesn't mean it's going to be easy to get control of ftp or shared filesystem permissions. I only wanted to be able to test the deployment before going through the pain of setting up an internal repo. > Although I'm sure the install plugin could be modified to not > have the read-only params Actually it already has been modified, but not yet published (see earlier post). Presumably the deploy plugin never had this restriction. -- View this message in context: http://www.nabble.com/Automating-install%3Ainstall-file-tf2071058.html#a 5721358 Sent from the Maven - Users forum at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
