Re: Anyone is actually use central repository?
In first case : no matter what is the id of the requested repo it will go the url mentioned. In the second case : Only requests for repo with id thirdparty will do tthe url mentioned. And more details are on the link which is mentioned before. What we did was , created a virtual repo and put all repos behind it and then use mirrior option to send all requests to this virtual repo. -Raj On Thu, Apr 26, 2012 at 6:45 PM, Wayne Fay wayne...@gmail.com wrote: How to consolidate these two settings? This is documented online under Advanced Mirror Specification: http://maven.apache.org/guides/mini/guide-mirror-settings.html Here's a hint: mirrorOf*,!central/mirrorOf The *,!central in the mirrorOf means mirror all except central. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: No overwrite
I think suggestion is not to bump version of all the artifacts. And also Ron explained the approach they took to manage diff artifact version ( if u understood it correctly ). -Raj On Mon, Apr 9, 2012 at 12:57 PM, mike digioia mpd...@gmail.com wrote: Hi Maybe I don't understand the recommendation here! One should never change/bump the rev number of anything that has not changed, including artifacts, especially if they are known elsewhere with the original rev. If use cases require this, then it is broken. On Sat, Apr 7, 2012 at 10:27 PM, Rajwinder Makkar rmakkaroff...@gmail.comwrote: Here is a dev scenario : We are using maven 3 + artifactory + microst TFS server We dont want to over write an existing version of an artifact in our company repo , so the the consumers of artifacts should not be surprised all the sudden when producers update artifact. Now this can simply be done by removing delete permissions in artifactory but then that causes another problem. In multi module maven project if one module changes then either dev need to modify version on all artifacts ( which doesnt make sense ) or then need to modify individual pom and publish only the artifact that is changes * which again is not manageable ) So need some advice on how this can be handled ? I have couple of thoughts : - Before running mvn command , write some thing custom to go through all pom's and query artifactory is version of artifact exist. if yes then dont compile. Basically compile only artifacts who version doesnt exist in artifactory using mvn -pl - Try Jenkins , I know jenkins is aware of modules in project , but not sure if it intelligent enough to compile only those which are changed ? Please advice -Raj
Re: No overwrite
True .. but the issue is how to restrict it from happening when it comes to formal builds. -Raj On Wed, Apr 11, 2012 at 4:03 PM, mike digioia mpd...@gmail.com wrote: Sorry but I looked at this- *8 You're describing the two possible solutions. Either bump the version on all artifacts produced, or just deploy the artifact that has changed (with a new version number). Which way to go depends on My comment was this first option should not exists, unless you are just testing in your local sandbox. On Wed, Apr 11, 2012 at 12:58 PM, Rajwinder Makkar rmakkaroff...@gmail.comwrote: I think suggestion is not to bump version of all the artifacts. And also Ron explained the approach they took to manage diff artifact version ( if u understood it correctly ). -Raj On Mon, Apr 9, 2012 at 12:57 PM, mike digioia mpd...@gmail.com wrote: Hi Maybe I don't understand the recommendation here! One should never change/bump the rev number of anything that has not changed, including artifacts, especially if they are known elsewhere with the original rev. If use cases require this, then it is broken. On Sat, Apr 7, 2012 at 10:27 PM, Rajwinder Makkar rmakkaroff...@gmail.comwrote: Here is a dev scenario : We are using maven 3 + artifactory + microst TFS server We dont want to over write an existing version of an artifact in our company repo , so the the consumers of artifacts should not be surprised all the sudden when producers update artifact. Now this can simply be done by removing delete permissions in artifactory but then that causes another problem. In multi module maven project if one module changes then either dev need to modify version on all artifacts ( which doesnt make sense ) or then need to modify individual pom and publish only the artifact that is changes * which again is not manageable ) So need some advice on how this can be handled ? I have couple of thoughts : - Before running mvn command , write some thing custom to go through all pom's and query artifactory is version of artifact exist. if yes then dont compile. Basically compile only artifacts who version doesnt exist in artifactory using mvn -pl - Try Jenkins , I know jenkins is aware of modules in project , but not sure if it intelligent enough to compile only those which are changed ? Please advice -Raj
Re: No overwrite
True .. personally i am also not in favor of bumping version of all artifacts when only one artifacts has changed in the project. This also leads to addition of extra space in artifactory or any repo manager as the same artifact will be stored with just diff version number without any need. Consumers of the artifact who are watching it also get confused as for them a new version is available but functionality is same ;-) Thanks for the response. -Raj On Sun, Apr 8, 2012 at 2:12 AM, Anders Hammar and...@hammar.net wrote: Your described scenario is the common scenario for Maven. You should never change (or delete) a release. Your repo manager should always be configured to deny that. You're describing the two possible solutions. Either bump the version on all artifacts produced, or just deploy the artifact that has changed (with a new version number). Which way to go depends on the version management choice of your project. Most open source projects simply deploy a new version of all artifacts, as they go together as a family. But from a CM perspective that can sometimes be confusing as, for example, it means that the API version is bumped while there are no changes to it (in case of a bug fix in the core implementation). But having a separate version lifecycle for different parts of your application will increase the release management work. Personally I'm in favor of having separate release lifecycle for at least the API if it's clearly separate (like for a web service's wsdl). But having separate releases for different parts of an applications internal stuff most often is just too cumbersome. /Anders On Sun, Apr 8, 2012 at 07:27, Rajwinder Makkar rmakkaroff...@gmail.com wrote: Here is a dev scenario : We are using maven 3 + artifactory + microst TFS server We dont want to over write an existing version of an artifact in our company repo , so the the consumers of artifacts should not be surprised all the sudden when producers update artifact. Now this can simply be done by removing delete permissions in artifactory but then that causes another problem. In multi module maven project if one module changes then either dev need to modify version on all artifacts ( which doesnt make sense ) or then need to modify individual pom and publish only the artifact that is changes * which again is not manageable ) So need some advice on how this can be handled ? I have couple of thoughts : - Before running mvn command , write some thing custom to go through all pom's and query artifactory is version of artifact exist. if yes then dont compile. Basically compile only artifacts who version doesnt exist in artifactory using mvn -pl - Try Jenkins , I know jenkins is aware of modules in project , but not sure if it intelligent enough to compile only those which are changed ? Please advice -Raj - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
No overwrite
Here is a dev scenario : We are using maven 3 + artifactory + microst TFS server We dont want to over write an existing version of an artifact in our company repo , so the the consumers of artifacts should not be surprised all the sudden when producers update artifact. Now this can simply be done by removing delete permissions in artifactory but then that causes another problem. In multi module maven project if one module changes then either dev need to modify version on all artifacts ( which doesnt make sense ) or then need to modify individual pom and publish only the artifact that is changes * which again is not manageable ) So need some advice on how this can be handled ? I have couple of thoughts : - Before running mvn command , write some thing custom to go through all pom's and query artifactory is version of artifact exist. if yes then dont compile. Basically compile only artifacts who version doesnt exist in artifactory using mvn -pl - Try Jenkins , I know jenkins is aware of modules in project , but not sure if it intelligent enough to compile only those which are changed ? Please advice -Raj
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
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
