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

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

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

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

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

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

[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

[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

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

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

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

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

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

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

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

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

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