Re: No overwrite
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
Re: Error running Maven
Thanks Wayne, It now works. -- View this message in context: http://maven.40175.n5.nabble.com/Error-running-Maven-tp5622633p5625692.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: Passive Mode
Am 08.04.2012 07:15 schrieb Domingo José González Cabrera doming...@gmrcanarias.com: Hi, How I can do for set Passive mode to false with maven3 What kind of passive mode are you referring to? Please give some more context regarding what you are trying to achieve. Regards, Ansgar Un Saludo, Domingo José González Cabrera Coordinador del área de Nuevas Tecnologías doming...@gmrcanarias.com www.gmrcanarias.com C/ Subida al Mayorazgo 26, portal B Planta 2 - Polígono Industrial El Mayorazgo 38108 Santa Cruz de Tenerife Tel: 902 377 777 Fax: 922 236 109
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
Re: No overwrite
We started by changing the versions of everything but as we got to 70 modules for the application we stopped. We stepped back and started to look at our code in the same way that we looked at third party (Apache, Spring, etc.) libraries that we used. We were perfectly able to use the same version of Spring through several generations of the application so why could we not keep using the same version of com.artifact-software.util:message if the messaging utility was unchanged. At the start of a new version of the application we update a spreadsheet of all of the modules by identifying each of the modules that will change. We are usually pretty accurate in our initial scoping since the modules are organized by function. We have also moved a lot of the utility functions out of the business code so they are more stable and do not change in the usual course of maintenance. This review usually takes less than an hour and after it is done everyone is on the same page in terms of scope. The spreadsheet also give a bit of a historical view of each of the new versions. Suppose you have to go back and understand why module x changed from version 1.10.3 to 1.10.4 last year. You can see at a glance what other modules also got new versions at the same time. This can sometimes be more helpful than a list of bugs fixed. In our case, we will version the revised module with the version number of the application that caused its generation so it is legal for us to have a 1.10.3 and a 1.10.6 with no 1.10.4 or 1.10.5 if the module was unchanged from when the 1.10.3 was created until the 1.10.6 version required a modification. Ron On 08/04/2012 10:43 AM, Rajwinder Makkar wrote: 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 Hammarand...@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 Makkarrmakkaroff...@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 -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail:
[ANN] CodeNarc Maven Plugin version 0.17-1 Released
HI, The Mojo team is pleased to announce the release of the CodeNarc Maven Plugin version 0.17-1 . CodeNarc scans Groovy source code, looking for violations of predefined or custom rules and generates an HTML report of the results. These rules include checks for coding standards, or searching for unused code, possible bugs or bad coding practices. To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdcodenarc-maven-plugin/artifactId version0.17-1/version /plugin Documentation for the CodeNarc Maven Plugin can be found at http://mojo.codehaus.org/codenarc-maven-plugin/index.html For more information on CodeNarc go to: http://codenarc.sourceforge.net/ Release Notes are at: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11062version=18347 Release Notes - Mojo - Version codenarc-maven-plugin-0.17-1 ** Bug * [MOJO-1814] - Fix relative link to 'sample report' on main page * [MOJO-1815] - codenarc-maven-plugin xml file (CodeNarc.xml) contains a package element with path attribute with no value. ** Improvement * [MOJO-1822] - Update to CodeNarc 0.17 * [MOJO-1823] - Update version to a format following CodeNarc versions * [MOJO-1824] - Add CodeNarc version info to Site Introduction page Regards, Garvin LeClaire garvin.lecla...@gmail.com
