Re: Deploy and settings.xml
My interpretation of the theory is that each project has its own deployment need so that putting the distribution management at the settings.xml level would be problematic. On the other hand all projects probably share the same sources for libraries so putting the repo config in settings makes sense. My feeling is that the right way to handle distribution is in the project's parent pom (not at the corporate level). That way each project can have its own deployment specification but the individual programmer does not have to worry about it. The parent for the project is set up once by the core team and the rest of the developers don't have any changes to make at all. Ron On 28/02/2012 11:51 PM, Rajwinder Makkar wrote: Hi, I have just setup Artifactory 2.4.2 and Maven 3.0 in our environment. I have this scenario which probably is pretty common in any dev environment but just want to take inputs on the approach. My current understanding : - Only way that maven deploy phase uses to put artifacts in remote repo is by reading distributionManagement tag in the pom.xml. There is no way to configure the repo for deployment in settings.xml ( under ../conf as well as user home dir) Scenerio is : If i have 100 development teams then : - either every one need to have distributionManagement tag in 100 pom.xml - We can has one super pom with the entries and all 100 dev team will inherit this super pom. Will appreciate if i can get some help around this on if my assumption are correct or not , secondly what is the best way to handle this scenarios. Thanks in advance -Raj -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deploy and settings.xml
If you have Artifactory 2.4.2 Pro, then I would suggest using some type of CI tool that has good integration with Artifactory. I use Jenkins Enterprise. With the provided plugins the integration between Jenkins and Artifactory is seamless and very easy to set up for a large number of builds. There should be documentation at http://wiki.jfrog.org that lists proper integration points with various CI tools. Best of luck. Steve On Wed, Feb 29, 2012 at 8:46 AM, Ron Wheeler rwhee...@artifact-software.com wrote: My interpretation of the theory is that each project has its own deployment need so that putting the distribution management at the settings.xml level would be problematic. On the other hand all projects probably share the same sources for libraries so putting the repo config in settings makes sense. My feeling is that the right way to handle distribution is in the project's parent pom (not at the corporate level). That way each project can have its own deployment specification but the individual programmer does not have to worry about it. The parent for the project is set up once by the core team and the rest of the developers don't have any changes to make at all. Ron On 28/02/2012 11:51 PM, Rajwinder Makkar wrote: Hi, I have just setup Artifactory 2.4.2 and Maven 3.0 in our environment. I have this scenario which probably is pretty common in any dev environment but just want to take inputs on the approach. My current understanding : - Only way that maven deploy phase uses to put artifacts in remote repo is by reading distributionManagement tag in the pom.xml. There is no way to configure the repo for deployment in settings.xml ( under ../conf as well as user home dir) Scenerio is : If i have 100 development teams then : - either every one need to have distributionManagement tag in 100 pom.xml - We can has one super pom with the entries and all 100 dev team will inherit this super pom. Will appreciate if i can get some help around this on if my assumption are correct or not , secondly what is the best way to handle this scenarios. Thanks in advance -Raj -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you.
Re: Deploy and settings.xml
Ron thank's you for your response , If i tweak the scenario little bit and lets assume that all the development teams need to go in same repository. Even then my understaing till now is that settings.xml can not host distribution management tag , it can only be present in pom. Any thoughts ? -Raj On Wed, Feb 29, 2012 at 5:46 AM, Ron Wheeler rwhee...@artifact-software.com wrote: My interpretation of the theory is that each project has its own deployment need so that putting the distribution management at the settings.xml level would be problematic. On the other hand all projects probably share the same sources for libraries so putting the repo config in settings makes sense. My feeling is that the right way to handle distribution is in the project's parent pom (not at the corporate level). That way each project can have its own deployment specification but the individual programmer does not have to worry about it. The parent for the project is set up once by the core team and the rest of the developers don't have any changes to make at all. Ron On 28/02/2012 11:51 PM, Rajwinder Makkar wrote: Hi, I have just setup Artifactory 2.4.2 and Maven 3.0 in our environment. I have this scenario which probably is pretty common in any dev environment but just want to take inputs on the approach. My current understanding : - Only way that maven deploy phase uses to put artifacts in remote repo is by reading distributionManagement tag in the pom.xml. There is no way to configure the repo for deployment in settings.xml ( under ../conf as well as user home dir) Scenerio is : If i have 100 development teams then : - either every one need to have distributionManagement tag in 100 pom.xml - We can has one super pom with the entries and all 100 dev team will inherit this super pom. Will appreciate if i can get some help around this on if my assumption are correct or not , secondly what is the best way to handle this scenarios. Thanks in advance -Raj -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deploy and settings.xml
If i tweak the scenario little bit and lets assume that all the development teams need to go in same repository. Even then my understaing till now is that settings.xml can not host distribution management tag , it can only be present in pom. Ron already told you what to do: The parent for the project is set up once by the core team and the rest of the developers don't have any changes to make at all. Make a single top-level corporate parent project that holds the distributionManagement information. Require all teams to use this top-level project as their project's parent pom. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deploy and settings.xml
On 12-02-29 07:34 AM, Wayne Fay wrote: If i tweak the scenario little bit and lets assume that all the development teams need to go in same repository. Even then my understaing till now is that settings.xml can not host distribution management tag , it can only be present in pom. Ron already told you what to do: The parent for the project is set up once by the core team and the rest of the developers don't have any changes to make at all. Make a single top-level corporate parent project that holds the distributionManagement information. Require all teams to use this top-level project as their project's parent pom. And when you do that you can enforce other company wide things like plugin versions.. manfred - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deploy and settings.xml
Yes, using CI Server job configuration can actually completely remove the need for distributionManagement declaration. The problem becomes a Jenkins job configuration management which I find easier has a global CM tool. Playing with pom files in VCS for handling data that are solely related to the CI environment can be very tricky to handle (especially after branching, tagging). My 2cts on this, Good luck, Fred. On Wed, Feb 29, 2012 at 4:55 PM, Stephen Wenner stephen.wen...@joann.comwrote: If you have Artifactory 2.4.2 Pro, then I would suggest using some type of CI tool that has good integration with Artifactory. I use Jenkins Enterprise. With the provided plugins the integration between Jenkins and Artifactory is seamless and very easy to set up for a large number of builds. There should be documentation at http://wiki.jfrog.org that lists proper integration points with various CI tools. Best of luck. Steve On Wed, Feb 29, 2012 at 8:46 AM, Ron Wheeler rwhee...@artifact-software.com wrote: My interpretation of the theory is that each project has its own deployment need so that putting the distribution management at the settings.xml level would be problematic. On the other hand all projects probably share the same sources for libraries so putting the repo config in settings makes sense. My feeling is that the right way to handle distribution is in the project's parent pom (not at the corporate level). That way each project can have its own deployment specification but the individual programmer does not have to worry about it. The parent for the project is set up once by the core team and the rest of the developers don't have any changes to make at all. Ron On 28/02/2012 11:51 PM, Rajwinder Makkar wrote: Hi, I have just setup Artifactory 2.4.2 and Maven 3.0 in our environment. I have this scenario which probably is pretty common in any dev environment but just want to take inputs on the approach. My current understanding : - Only way that maven deploy phase uses to put artifacts in remote repo is by reading distributionManagement tag in the pom.xml. There is no way to configure the repo for deployment in settings.xml ( under ../conf as well as user home dir) Scenerio is : If i have 100 development teams then : - either every one need to have distributionManagement tag in 100 pom.xml - We can has one super pom with the entries and all 100 dev team will inherit this super pom. Will appreciate if i can get some help around this on if my assumption are correct or not , secondly what is the best way to handle this scenarios. Thanks in advance -Raj -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- JFrog Ltd http://www.jfrog.org/
Deploy and settings.xml
Hi, I have just setup Artifactory 2.4.2 and Maven 3.0 in our environment. I have this scenario which probably is pretty common in any dev environment but just want to take inputs on the approach. My current understanding : - Only way that maven deploy phase uses to put artifacts in remote repo is by reading distributionManagement tag in the pom.xml. There is no way to configure the repo for deployment in settings.xml ( under ../conf as well as user home dir) Scenerio is : If i have 100 development teams then : - either every one need to have distributionManagement tag in 100 pom.xml - We can has one super pom with the entries and all 100 dev team will inherit this super pom. Will appreciate if i can get some help around this on if my assumption are correct or not , secondly what is the best way to handle this scenarios. Thanks in advance -Raj
Maven deploy ignores settings.xml
Hi, I am trying to deploy an artifact on a remote repository using mvn deploy:deploy-file. The command I am trying to execute is mvn deploy:deploy-file -Dfile=target/abc-1.2.0.jar -Durl=scp://remoteMachine/srv/www/htdocs/maven -DgroupId=com.example -DartifactId=abc -Dversion=1.2.0 -Dpackaging=jar -DpomFile=pom.xml -gs /home/localUser/apache-maven.-2.2.1/conf/settings.xml While in settings.xml I have server idrepo-id/id usernameremoteUser/username passwordmyPwd/password /server But whenever I execute it, it always prompts for the password with the local username instead of the username defined in the settings.xml file. such as, localu...@remotemachine.de but I was expecting remoteu...@remotemachine.de Thanks for any help in advance. Shiraz -- View this message in context: http://www.nabble.com/Maven-deploy-ignores-settings.xml-tp26091684p26091684.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven deploy ignores settings.xml
You need to set the repositoryId to repo-id on command line as well: http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html#repositoryId If not, Maven has no way of knowing how to map the defined repo url to the credentials in settings.xml. /Anders On Wed, Oct 28, 2009 at 10:30, shiraz memon shiraz.me...@yahoo.com wrote: Hi, I am trying to deploy an artifact on a remote repository using mvn deploy:deploy-file. The command I am trying to execute is mvn deploy:deploy-file -Dfile=target/abc-1.2.0.jar -Durl=scp://remoteMachine/srv/www/htdocs/maven -DgroupId=com.example -DartifactId=abc -Dversion=1.2.0 -Dpackaging=jar -DpomFile=pom.xml -gs /home/localUser/apache-maven.-2.2.1/conf/settings.xml While in settings.xml I have server idrepo-id/id usernameremoteUser/username passwordmyPwd/password /server But whenever I execute it, it always prompts for the password with the local username instead of the username defined in the settings.xml file. such as, localu...@remotemachine.de but I was expecting remoteu...@remotemachine.de Thanks for any help in advance. Shiraz -- View this message in context: http://www.nabble.com/Maven-deploy-ignores-settings.xml-tp26091684p26091684.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
