Re: [pre-verify over deploy]
Well I knew I'd written something on that topic... but re-reading I am surprised at how much information I managed to cram in there without it feeling over dense (for me) BTW I am of the *never deploy -SNAPSHOTs* camp but I recognise that there are other people out there... and I have to interact with them some times and that post is helpful to explain things to them! On 3 November 2014 01:57, Barrie Treloar baerr...@gmail.com wrote: On 29 October 2014 20:18, Stephen Connolly stephen.alan.conno...@gmail.com wrote: http://developer-blog.cloudbees.com/2012/12/should-you-deploy-snapshots.html Thanks for writing that up! I'll remember to point people there instead of having to remember half-baked stuff and type :) This is a useful piece of advice especially in conjunction with the Versions Maven Plugin http://mojo.codehaus.org/versions-maven-plugin/lock-snapshots-mojo.html which has goals for “locking” and “unlocking” your -SNAPSHOT dependencies to the current timestamp version, thereby removing uncertainty. It will allow you to live dangerously on shifting sands and then when you get sucked under to go back and lock to a working version. But I still think you are better off avoiding that problem in the first place.
Apache Maven - Checkstyle Plugin - Java 8
Hi guys, I like to use the Apache Maven Checkstyle-Plugin with Java 8 but unfortunately it uses Checkstyle 5.7 that doesn't support Java 8. Checkstyle itself support Java 8 since version 5.9. Is there a plan to migrate the Checkstyle-Plugin to this version or can I migrate myself? Thanks for any advice. Best regards Alexander
Re: [pre-verify over deploy]
On 3 November 2014 20:07, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Well I knew I'd written something on that topic... but re-reading I am surprised at how much information I managed to cram in there without it feeling over dense (for me) BTW I am of the *never deploy -SNAPSHOTs* camp but I recognise that there are other people out there... and I have to interact with them some times and that post is helpful to explain things to them! I think its important for people to try things, because this stuff is complicated, and unless you get yours hands dirty it is difficult to understand and get a feel for why it doesn't work. After you have been burnt by a dependency being updated from underneath you - one that you have your own changes in - then you realise that you need to build twice to rebuild the other snapshot to keep going, and that the other developers haven't gotten their head around the build process and why things sometimes dont work... It makes life simpler to avoid deploying the snapshots for developer consumption.
Re: [pre-verify over deploy]
Hello, Thanks Stephen for that writeup. It is a good read. For my taste it over-emphasises the moving ground problem. I mean when cooperating with larger projects and lots of developers you get all kinds of problems, but beeing affected by breaking changes of updating snapshots - I cant remember to ever experience that. In fact when SNAPSHOTs change in a severe way it is most likely that I have waited for it, I manually refreshed the dependencies and I am actually happy to see the changes as early as possible (before integrating into a system which isnt working since days and only my old snapshots hide this from me). But having said that, I also do enjoy an environment with releasing often. This allows each team to decide when to pull in which (released) changes, and this indeed lowers the frequency of broken builds (however it also encourages developers to wait too long with the integration, if you dont nudge them with deoendency upgrade reports). Gruss Bernd Am 03.11.2014 10:39 schrieb Stephen Connolly stephen.alan.conno...@gmail.com: Well I knew I'd written something on that topic... but re-reading I am surprised at how much information I managed to cram in there without it feeling over dense (for me) BTW I am of the *never deploy -SNAPSHOTs* camp but I recognise that there are other people out there... and I have to interact with them some times and that post is helpful to explain things to them! On 3 November 2014 01:57, Barrie Treloar baerr...@gmail.com wrote: On 29 October 2014 20:18, Stephen Connolly stephen.alan.conno...@gmail.com wrote: http://developer-blog.cloudbees.com/2012/12/should-you-deploy-snapshots.html Thanks for writing that up! I'll remember to point people there instead of having to remember half-baked stuff and type :) This is a useful piece of advice especially in conjunction with the Versions Maven Plugin http://mojo.codehaus.org/versions-maven-plugin/lock-snapshots-mojo.html which has goals for “locking” and “unlocking” your -SNAPSHOT dependencies to the current timestamp version, thereby removing uncertainty. It will allow you to live dangerously on shifting sands and then when you get sucked under to go back and lock to a working version. But I still think you are better off avoiding that problem in the first place.
Maven Developer Hangout
Here's the link for this week: https://plus.google.com/u/0/events/c7v61ah88ifc9e0vh6hnum87vro There are a couple things I plan to talk about: - demo of a new lifecycle profiling and visualization tool i've been working on - discussion of the history of Maven Central and how I'd like to see the content be made available to all for research and analysis - possibly a demo the target platform editor we've been working on Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Be not afraid of growing slowly, be only afraid of standing still. -- Chinese Proverb
Re: Apache Maven - Checkstyle Plugin - Java 8
You can overwrite the checkstyle version. My configuration looks like this: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-checkstyle-plugin/artifactId version2.12.1/version configuration configLocationcheckstyle.xml/configLocation includeTestSourceDirectoryfalse/includeTestSourceDirectory failsOnErrortrue/failsOnError /configuration executions execution phaseverify/phase goals goalcheckstyle/goal /goals /execution /executions dependencies dependency groupIdcom.puppycrawl.tools/groupId artifactIdcheckstyle/artifactId version5.9/version /dependency /dependencies /plugin Kind regards, Joachim On 2014-11-03 11:39, Alexander Wessel wrote: Hi guys, I like to use the Apache Maven Checkstyle-Plugin with Java 8 but unfortunately it uses Checkstyle 5.7 that doesn't support Java 8. Checkstyle itself support Java 8 since version 5.9. Is there a plan to migrate the Checkstyle-Plugin to this version or can I migrate myself? Thanks for any advice. Best regards Alexander - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] RPM Maven Plugin version 2.1 - Released
Hi, The Mojo team is pleased to announce the release of the RPM Maven Plugin version 2.1. The RPM Maven Plugin allows artifacts from one or more projects to be packaged in an RPM for distribution. In addition to project artifacts, the RPM can contain other resources to be installed with the artifacts and scripts to be run while the package is being installed and removed. This plugin does not support the full range of features available to RPMs. In particular, source RPMs can not be generated and the spec files which are used do not do any build process (the plugin collects the files and installs them for packaging). http://mojo.codehaus.org/rpm-maven-plugin/ To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdrpm-maven-plugin/artifactId version2.1/version /plugin Release Notes: *http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11970version=20367 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11970version=20367* Enjoy, The Mojo team. Dan Tran
[ANN] Apache Maven Clean Plugin Version 2.6.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Clean Plugin, version 2.6.1 The Clean Plugin is used when you want to remove files generated at build-time in a project's directory. http://maven.apache.org/plugins/maven-clean-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-clean-plugin/artifactId version2.6.1/version /plugin Release Notes - Maven Clean Plugin - Version 2.6.1 Bugs: * [MCLEAN-47] - On windows if there are junctions on the cleaned directories, clean deletes .* resources under junction's target along with junction. * [MCLEAN-55] - maven clean seems to use old java.io API to clean the target directory * [MCLEAN-58] - Maven Clean Plugin ignores followSymLinks parameter on Windows Improvements: * [MCLEAN-59] - Upgrade maven-plugins-testing-harness from 1.1 to 1.3 * [MCLEAN-60] - Fixed Checkstyle reported errors / warnings * [MCLEAN-61] - Upgrade to org.apache.maven.plugins:maven-plugins:26 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Apache Maven - Checkstyle Plugin - Java 8
On 4 Nov 2014, at 2:59, Joachim Van der Auwera wrote: You can overwrite the checkstyle version. My configuration looks like this: Unfortunately this doesn't work with the latest checkstyle version _if_ you use inline configuration, and the DTD version has changed and no longer matches, so you end up with broken behaviour. -- Mark Derricutt http://www.theoryinpractice.net http://plus.google.com/+MarkDerricutt http://twitter.com/talios http://facebook.com/mderricutt signature.asc Description: OpenPGP digital signature
explicit dependencies in maven
hello, is there any good doc/blog which describes the handling of explicit declaration of dependencies. when we build the code, we use certain dependencies , how we can make sure that when we reproduce the same build after the gap of 6 months , same and exact dependencies will be used. ??? i know we can have artifactory/nexus , but that does not guarantee the exact version of dependency when developer changes the code and make it public keeping the version same please suggest regards
Re: explicit dependencies in maven
Your pom.xml should declare all dependency versions explicitly. And to prevent any changes, do not use any snapshots. Furthermore, use dependency:analyze on your project to make sure all libraries in use are explicitly declared. After you lock them all down, tell your developers not to update the pom.xml file. That will ensure it. Cheers, Paul On Mon, Nov 3, 2014 at 10:33 PM, Irfan Sayed irfu.sa...@gmail.com wrote: hello, is there any good doc/blog which describes the handling of explicit declaration of dependencies. when we build the code, we use certain dependencies , how we can make sure that when we reproduce the same build after the gap of 6 months , same and exact dependencies will be used. ??? i know we can have artifactory/nexus , but that does not guarantee the exact version of dependency when developer changes the code and make it public keeping the version same please suggest regards
Re: explicit dependencies in maven
Have you scanned the Maven books referenced on the Maven web site? Best starting place. With a repository (Nexus), people are prevented from deploying the same version twice so you are guaranteed that if you build with version 2.3.15 of ourNiceUtility, you will always get the same code. The repo will simply not allow them to overwrite version 2.3.15 once it is deployed into the wild(public). Beats firing developers but stops them from doing silly things. On 03/11/2014 11:33 PM, Irfan Sayed wrote: hello, is there any good doc/blog which describes the handling of explicit declaration of dependencies. when we build the code, we use certain dependencies , how we can make sure that when we reproduce the same build after the gap of 6 months , same and exact dependencies will be used. ??? i know we can have artifactory/nexus , but that does not guarantee the exact version of dependency when developer changes the code and make it public keeping the version same please suggest regards -- 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: explicit dependencies in maven
so, lets say if i am using x dependency with version 1.1 and if the developer changes the code of that dependency, keeping the same version as 1.1 then nexus will not download the latest code changes for that dependency because the version still refers to 1.1 ??? if that is the case, this is really nice regards On Tue, Nov 4, 2014 at 10:20 AM, Ron Wheeler rwhee...@artifact-software.com wrote: Have you scanned the Maven books referenced on the Maven web site? Best starting place. With a repository (Nexus), people are prevented from deploying the same version twice so you are guaranteed that if you build with version 2.3.15 of ourNiceUtility, you will always get the same code. The repo will simply not allow them to overwrite version 2.3.15 once it is deployed into the wild(public). Beats firing developers but stops them from doing silly things. On 03/11/2014 11:33 PM, Irfan Sayed wrote: hello, is there any good doc/blog which describes the handling of explicit declaration of dependencies. when we build the code, we use certain dependencies , how we can make sure that when we reproduce the same build after the gap of 6 months , same and exact dependencies will be used. ??? i know we can have artifactory/nexus , but that does not guarantee the exact version of dependency when developer changes the code and make it public keeping the version same please suggest regards -- 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: explicit dependencies in maven
Yes, that's how it works. /Anders (mobile) Den 4 nov 2014 06:06 skrev Irfan Sayed irfu.sa...@gmail.com: so, lets say if i am using x dependency with version 1.1 and if the developer changes the code of that dependency, keeping the same version as 1.1 then nexus will not download the latest code changes for that dependency because the version still refers to 1.1 ??? if that is the case, this is really nice regards On Tue, Nov 4, 2014 at 10:20 AM, Ron Wheeler rwhee...@artifact-software.com wrote: Have you scanned the Maven books referenced on the Maven web site? Best starting place. With a repository (Nexus), people are prevented from deploying the same version twice so you are guaranteed that if you build with version 2.3.15 of ourNiceUtility, you will always get the same code. The repo will simply not allow them to overwrite version 2.3.15 once it is deployed into the wild(public). Beats firing developers but stops them from doing silly things. On 03/11/2014 11:33 PM, Irfan Sayed wrote: hello, is there any good doc/blog which describes the handling of explicit declaration of dependencies. when we build the code, we use certain dependencies , how we can make sure that when we reproduce the same build after the gap of 6 months , same and exact dependencies will be used. ??? i know we can have artifactory/nexus , but that does not guarantee the exact version of dependency when developer changes the code and make it public keeping the version same please suggest regards -- 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: explicit dependencies in maven
thanks :) On Tue, Nov 4, 2014 at 10:57 AM, Anders Hammar and...@hammar.net wrote: Yes, that's how it works. /Anders (mobile) Den 4 nov 2014 06:06 skrev Irfan Sayed irfu.sa...@gmail.com: so, lets say if i am using x dependency with version 1.1 and if the developer changes the code of that dependency, keeping the same version as 1.1 then nexus will not download the latest code changes for that dependency because the version still refers to 1.1 ??? if that is the case, this is really nice regards On Tue, Nov 4, 2014 at 10:20 AM, Ron Wheeler rwhee...@artifact-software.com wrote: Have you scanned the Maven books referenced on the Maven web site? Best starting place. With a repository (Nexus), people are prevented from deploying the same version twice so you are guaranteed that if you build with version 2.3.15 of ourNiceUtility, you will always get the same code. The repo will simply not allow them to overwrite version 2.3.15 once it is deployed into the wild(public). Beats firing developers but stops them from doing silly things. On 03/11/2014 11:33 PM, Irfan Sayed wrote: hello, is there any good doc/blog which describes the handling of explicit declaration of dependencies. when we build the code, we use certain dependencies , how we can make sure that when we reproduce the same build after the gap of 6 months , same and exact dependencies will be used. ??? i know we can have artifactory/nexus , but that does not guarantee the exact version of dependency when developer changes the code and make it public keeping the version same please suggest regards -- 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: generate maven dependency difference between two Jenkins builds
thanks. what i figured out is , nexus / artifactory will not download the dependency unless there is change in the version. if dependency x refers version 1.1 , then maven will see if nexus/artifactory has this version along with local maben repo of build machine if it does both, maven will not download the dependency even if developer changes the code keeping the version same regards On Mon, Oct 20, 2014 at 5:55 AM, Bernd Eckenfels e...@zusammenkunft.net wrote: Hello, I was looking a bit deeper into making the dependency plugin to print out the resolved timestamps. I noticed there is already an option -DoutputAbsoluteArtifactFilename=true which would give me the path of the files in the local directory. This is all good for released versions, but it still points to the non-unique snapshot version files. I am not wondering, is there a way to configure the maven resolver/dependency management to actually not do that. When I look at the build output, it does download the meta data and a specific timestamped version: Downloaded: https://.../2.1-SNAPSHOT/maven-metadata.xml (2 KB at 0.6 KB/sec) Downloaded: https://.../2.1-SNAPSHOT/commons-vfs2-2.1-20141016.153538-385.pom (12 KB at 22.1 KB/sec) Downloading: https://.../2.1-SNAPSHOT/commons-vfs2-2.1-20141016.153538-385.jar Downloaded: https://.../2.1-SNAPSHOT/commons-vfs2-2.1-20141016.153538-385.jar (423 KB at 209.7 KB/sec) But it still creates a copy of that version without timestamp. I can imagine this is not really the best situation, why does it not stick to the uniquely named file? BTW: whats the best API way to get the snapshot timestamp from a Artifact object after it was resolved? I tried getDownloadURL(), but it is null for the Artifacts which are present in the list of org.apache.maven.plugin.dependency.utils.DependencyStatusSets.buildArtifactListOutput(SetArtifact, boolean, boolean, boolean) Gruss Bernd Am Sun, 19 Oct 2014 19:11:50 +0200 schrieb Bernd Eckenfels e...@zusammenkunft.net: Ah another thing, I always wished there is an option to archive the effective POM instead of the tear downed POM with the maven-archiver (addMavenDesciptor). Especially when the effective pom also contains the resolved snapshot timestamps (which it currently not does). Speaking of effective pom, you can create and archive it, then you have at least all expressions and profiles locked down. Gruss Bernd Am Sun, 19 Oct 2014 22:17:45 +0530 schrieb Irfan Sayed irfu.sa...@gmail.com: thanks bernd. anyone has any other suggestions please? regards On Sun, Oct 19, 2014 at 9:49 PM, Bernd Eckenfels e...@zusammenkunft.net wrote: Hello, I dont have a good method for that (especially not if all dependencies arent fully version-specified. You can use and add dependencies:list as a target to the maven build, then the resolved list will be printed in the build log. This list can change depending on what is available at build time. Gruss Bernd Am Sun, 19 Oct 2014 20:57:29 +0530 schrieb Irfan Sayed irfu.sa...@gmail.com: hello, we have java project and using maven to build the same. we are using Jenkins. in Jenkins , we can generate the delta of source code changes between two builds. in the same way, do we have any way wherein , we can generate the delta of maven dependencies changed between two builds. please suggest regards - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: generate maven dependency difference between two Jenkins builds
Please be aware, changing the code of a released library (not SNAPSHOT) is not allowed and maven can not take any responsibility for any errors this will cause. Thats why nexus/artifactory do not allow to change the artifact of a released version once its uploaded. Only SNAPSHOT versions are allowed to be changed. Domi On 04.11.2014, at 08:10, Irfan Sayed irfu.sa...@gmail.com wrote: thanks. what i figured out is , nexus / artifactory will not download the dependency unless there is change in the version. if dependency x refers version 1.1 , then maven will see if nexus/artifactory has this version along with local maben repo of build machine if it does both, maven will not download the dependency even if developer changes the code keeping the version same regards On Mon, Oct 20, 2014 at 5:55 AM, Bernd Eckenfels e...@zusammenkunft.net wrote: Hello, I was looking a bit deeper into making the dependency plugin to print out the resolved timestamps. I noticed there is already an option -DoutputAbsoluteArtifactFilename=true which would give me the path of the files in the local directory. This is all good for released versions, but it still points to the non-unique snapshot version files. I am not wondering, is there a way to configure the maven resolver/dependency management to actually not do that. When I look at the build output, it does download the meta data and a specific timestamped version: Downloaded: https://.../2.1-SNAPSHOT/maven-metadata.xml (2 KB at 0.6 KB/sec) Downloaded: https://.../2.1-SNAPSHOT/commons-vfs2-2.1-20141016.153538-385.pom (12 KB at 22.1 KB/sec) Downloading: https://.../2.1-SNAPSHOT/commons-vfs2-2.1-20141016.153538-385.jar Downloaded: https://.../2.1-SNAPSHOT/commons-vfs2-2.1-20141016.153538-385.jar (423 KB at 209.7 KB/sec) But it still creates a copy of that version without timestamp. I can imagine this is not really the best situation, why does it not stick to the uniquely named file? BTW: whats the best API way to get the snapshot timestamp from a Artifact object after it was resolved? I tried getDownloadURL(), but it is null for the Artifacts which are present in the list of org.apache.maven.plugin.dependency.utils.DependencyStatusSets.buildArtifactListOutput(SetArtifact, boolean, boolean, boolean) Gruss Bernd Am Sun, 19 Oct 2014 19:11:50 +0200 schrieb Bernd Eckenfels e...@zusammenkunft.net: Ah another thing, I always wished there is an option to archive the effective POM instead of the tear downed POM with the maven-archiver (addMavenDesciptor). Especially when the effective pom also contains the resolved snapshot timestamps (which it currently not does). Speaking of effective pom, you can create and archive it, then you have at least all expressions and profiles locked down. Gruss Bernd Am Sun, 19 Oct 2014 22:17:45 +0530 schrieb Irfan Sayed irfu.sa...@gmail.com: thanks bernd. anyone has any other suggestions please? regards On Sun, Oct 19, 2014 at 9:49 PM, Bernd Eckenfels e...@zusammenkunft.net wrote: Hello, I dont have a good method for that (especially not if all dependencies arent fully version-specified. You can use and add dependencies:list as a target to the maven build, then the resolved list will be printed in the build log. This list can change depending on what is available at build time. Gruss Bernd Am Sun, 19 Oct 2014 20:57:29 +0530 schrieb Irfan Sayed irfu.sa...@gmail.com: hello, we have java project and using maven to build the same. we are using Jenkins. in Jenkins , we can generate the delta of source code changes between two builds. in the same way, do we have any way wherein , we can generate the delta of maven dependencies changed between two builds. please suggest regards - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
