How to detect dependency convergence violations between *independent* projects using maven enforcer plugin
When running dependency convergence with the maven enforcer pluginhttp://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html, we can easily detect that a certain project transitively depends on 2 different versions of the same artifact. But consider a large group that is writing plugins for the same system. And consider 2 teams in this group. One team is developing plugin A and has the following dependency chain: A - B - C (v 1.1) the other team develops plugin X and has the following dependency chain: X - Y - C (v 2.0) Projects A and X are completely independent but in in production, both plugins are deployed and there is a collision. Although both teams share CI, the enforcer plugin does not detect this collision since collisions are detected only if they share a common ancestor. (for example, if A also had: A - D - C (v 1.4), this would have been detected). It seems that the solution is to define a 3rd 'super module' that will aggregate A and X and feed it to the enforcer plugin. I am having trouble with this: I defined such a module. Added A and X as dependencies (of type 'pom') but when I execute the enforcer, it does not detect the collisions! It is as if the super pom fails to 'absorb' the transitive dependencies. What am I missing here? I am using maven 3.0.4.
Re: usage with Jenkins
On 23 September 2014 02:23, Curtis Rueden ctrue...@wisc.edu wrote: Also, stay away from the Jenkins Maven style job. Freestyle is more flexible and less buggy. Based on ..?
Re: usage with Jenkins
Freestyle does not mess with your build and change it from building the way maven intends. Google stephen's java adventures Jenkins maven considered evil for a more detailed discussion On Tuesday, 23 September 2014, James Green james.mk.gr...@gmail.com wrote: On 23 September 2014 02:23, Curtis Rueden ctrue...@wisc.edu javascript:; wrote: Also, stay away from the Jenkins Maven style job. Freestyle is more flexible and less buggy. Based on ..? -- Sent from my phone
Re: usage with Jenkins
The Maven style build will also lock you in to a small subset of Jenkins's usual features. And when you eventually need a feature not available with a Maven-style build, there is no conversion path from Maven-style to Freestyle -- you have to recreate the job (losing the build history etc.). -Curtis On Sep 23, 2014 7:33 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Freestyle does not mess with your build and change it from building the way maven intends. Google stephen's java adventures Jenkins maven considered evil for a more detailed discussion On Tuesday, 23 September 2014, James Green james.mk.gr...@gmail.com wrote: On 23 September 2014 02:23, Curtis Rueden ctrue...@wisc.edu javascript:; wrote: Also, stay away from the Jenkins Maven style job. Freestyle is more flexible and less buggy. Based on ..? -- Sent from my phone
Re: usage with Jenkins
News to me. Ironically I'm just setting up a new Jenkins job so tried the freeform style - I can no longer see Deploy artifacts to Maven repository as a post-build action. Dare I ask what I'm missing having chosen the full-fat option..? On 23 September 2014 14:02, Curtis Rueden ctrue...@wisc.edu wrote: The Maven style build will also lock you in to a small subset of Jenkins's usual features. And when you eventually need a feature not available with a Maven-style build, there is no conversion path from Maven-style to Freestyle -- you have to recreate the job (losing the build history etc.). -Curtis On Sep 23, 2014 7:33 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Freestyle does not mess with your build and change it from building the way maven intends. Google stephen's java adventures Jenkins maven considered evil for a more detailed discussion On Tuesday, 23 September 2014, James Green james.mk.gr...@gmail.com wrote: On 23 September 2014 02:23, Curtis Rueden ctrue...@wisc.edu javascript:; wrote: Also, stay away from the Jenkins Maven style job. Freestyle is more flexible and less buggy. Based on ..? -- Sent from my phone
Re: usage with Jenkins
That's interesting, James. Something to consider. We're using the open source version of Artifactory, btw, and I the Artifactory Plugin has it's own post build option. I'd probably use that. Curtis, I had Netbeans create the new job for me through it's Hudson plugin. It created a multi-configuration project and didn't have the publish artifacts options you mentioned. All my Ant projects, do, though. I'm going to do a free-style and report back. On Tue, Sep 23, 2014 at 9:56 AM, James Green james.mk.gr...@gmail.com wrote: News to me. Ironically I'm just setting up a new Jenkins job so tried the freeform style - I can no longer see Deploy artifacts to Maven repository as a post-build action. Dare I ask what I'm missing having chosen the full-fat option..? On 23 September 2014 14:02, Curtis Rueden ctrue...@wisc.edu wrote: The Maven style build will also lock you in to a small subset of Jenkins's usual features. And when you eventually need a feature not available with a Maven-style build, there is no conversion path from Maven-style to Freestyle -- you have to recreate the job (losing the build history etc.). -Curtis On Sep 23, 2014 7:33 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Freestyle does not mess with your build and change it from building the way maven intends. Google stephen's java adventures Jenkins maven considered evil for a more detailed discussion On Tuesday, 23 September 2014, James Green james.mk.gr...@gmail.com wrote: On 23 September 2014 02:23, Curtis Rueden ctrue...@wisc.edu javascript:; wrote: Also, stay away from the Jenkins Maven style job. Freestyle is more flexible and less buggy. Based on ..? -- Sent from my phone -- “If the American people ever allow private banks to control the issue of their currency, first by inflation, then by deflation, the banks...will deprive the people of all property until their children wake-up homeless on the continent their fathers conquered... The issuing power should be taken from the banks and restored to the people, to whom it properly belongs. -- Thomas Jefferson Government big enough to supply everything...is big enough to take everything you have. The course of history shows that as a government grows, liberty decreases --- Thomas Jefferson www.CampaignForLiberty.org
Re: usage with Jenkins
Hi James, I can no longer see Deploy artifacts to Maven repository as a post-build action. Just add a build step that does mvn deploy or similar. Dare I ask what I'm missing having chosen the full-fat option..? If you're asking what you cannot do with freeform jobs: I don't know of anything. I think the Maven-style job is just a convenience to get very basic CI set up as quickly as possible, for people without much technical know-how. If you're asking for more details on limitations of the Maven-style job: it's been awhile, but IIRC my group had several problems. One such was that the Jenkins Git plugin did not fire Maven-style jobs upon receiving the push notification from GitHub. Another really serious problem is that you can't add arbitrary shell script as a post-build step. And needing to do this is, in my experience, extremely common. It wouldn't be that big of an issue if there were an easy way to later convert a Maven-style job to a freestyle job should the need arise. But try a web search on that topic and you'll see what I mean about it being a highly non-trivial problem. Regards, Curtis On Tue, Sep 23, 2014 at 8:56 AM, James Green james.mk.gr...@gmail.com wrote: News to me. Ironically I'm just setting up a new Jenkins job so tried the freeform style - I can no longer see Deploy artifacts to Maven repository as a post-build action. Dare I ask what I'm missing having chosen the full-fat option..? On 23 September 2014 14:02, Curtis Rueden ctrue...@wisc.edu wrote: The Maven style build will also lock you in to a small subset of Jenkins's usual features. And when you eventually need a feature not available with a Maven-style build, there is no conversion path from Maven-style to Freestyle -- you have to recreate the job (losing the build history etc.). -Curtis On Sep 23, 2014 7:33 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Freestyle does not mess with your build and change it from building the way maven intends. Google stephen's java adventures Jenkins maven considered evil for a more detailed discussion On Tuesday, 23 September 2014, James Green james.mk.gr...@gmail.com wrote: On 23 September 2014 02:23, Curtis Rueden ctrue...@wisc.edu javascript:; wrote: Also, stay away from the Jenkins Maven style job. Freestyle is more flexible and less buggy. Based on ..? -- Sent from my phone
Re: usage with Jenkins
FYI my aim is to supersede the evil job type with some enhanced reporting in what is currently called the literate job type. That would mean you'd get the per-module reporting. The current evil job type's other killer feature is automatic downstream job triggering... Which is actually broken as it does not take into account the local repo that the -SNAPSHOTs may or may not have been deployed into and assumes that `package` is the same as `deploy` as far as triggering is concerned as well as ignoring that deployment might be to a staging repo, so the artifacts may not be available downstream... However, despite being fundamentally broken at every level, you would be surprised how many people feel locked into the evil job type because of this... In short, there is so many issues with it that I cannot recommend its use... The only semi useful feature from my PoV is per module reporting. (Sadly my day job has me having to support the evil job type from time to time... Though usually those tickets get picked up by Kohsuke if I start another evil job type tirade ;-) ) On Tuesday, 23 September 2014, Curtis Rueden ctrue...@wisc.edu wrote: Hi James, I can no longer see Deploy artifacts to Maven repository as a post-build action. Just add a build step that does mvn deploy or similar. Dare I ask what I'm missing having chosen the full-fat option..? If you're asking what you cannot do with freeform jobs: I don't know of anything. I think the Maven-style job is just a convenience to get very basic CI set up as quickly as possible, for people without much technical know-how. If you're asking for more details on limitations of the Maven-style job: it's been awhile, but IIRC my group had several problems. One such was that the Jenkins Git plugin did not fire Maven-style jobs upon receiving the push notification from GitHub. Another really serious problem is that you can't add arbitrary shell script as a post-build step. And needing to do this is, in my experience, extremely common. It wouldn't be that big of an issue if there were an easy way to later convert a Maven-style job to a freestyle job should the need arise. But try a web search on that topic and you'll see what I mean about it being a highly non-trivial problem. Regards, Curtis On Tue, Sep 23, 2014 at 8:56 AM, James Green james.mk.gr...@gmail.com javascript:; wrote: News to me. Ironically I'm just setting up a new Jenkins job so tried the freeform style - I can no longer see Deploy artifacts to Maven repository as a post-build action. Dare I ask what I'm missing having chosen the full-fat option..? On 23 September 2014 14:02, Curtis Rueden ctrue...@wisc.edu javascript:; wrote: The Maven style build will also lock you in to a small subset of Jenkins's usual features. And when you eventually need a feature not available with a Maven-style build, there is no conversion path from Maven-style to Freestyle -- you have to recreate the job (losing the build history etc.). -Curtis On Sep 23, 2014 7:33 AM, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; wrote: Freestyle does not mess with your build and change it from building the way maven intends. Google stephen's java adventures Jenkins maven considered evil for a more detailed discussion On Tuesday, 23 September 2014, James Green james.mk.gr...@gmail.com javascript:; wrote: On 23 September 2014 02:23, Curtis Rueden ctrue...@wisc.edu javascript:; javascript:; wrote: Also, stay away from the Jenkins Maven style job. Freestyle is more flexible and less buggy. Based on ..? -- Sent from my phone -- Sent from my phone
Re: usage with Jenkins
I'd like to weigh in on this. The maven-based job type is great for quick or single-dimensional project, especially when you know the scope will not change. I tend to prefer freestyle because of flexibility. In reality, the solution is to just have one project type with varied initialization types. I'm pretty sure that's happening in the backend, but the details are hidden (needs confirmation). BTW, in order to have artifacts listed one has to enable artifact archiving, not publishing. Everything works now (except for the job stalling on deployment to a self-signed cert GF 4.1 installation. :) On Tue, Sep 23, 2014 at 2:43 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: FYI my aim is to supersede the evil job type with some enhanced reporting in what is currently called the literate job type. That would mean you'd get the per-module reporting. The current evil job type's other killer feature is automatic downstream job triggering... Which is actually broken as it does not take into account the local repo that the -SNAPSHOTs may or may not have been deployed into and assumes that `package` is the same as `deploy` as far as triggering is concerned as well as ignoring that deployment might be to a staging repo, so the artifacts may not be available downstream... However, despite being fundamentally broken at every level, you would be surprised how many people feel locked into the evil job type because of this... In short, there is so many issues with it that I cannot recommend its use... The only semi useful feature from my PoV is per module reporting. (Sadly my day job has me having to support the evil job type from time to time... Though usually those tickets get picked up by Kohsuke if I start another evil job type tirade ;-) ) On Tuesday, 23 September 2014, Curtis Rueden ctrue...@wisc.edu wrote: Hi James, I can no longer see Deploy artifacts to Maven repository as a post-build action. Just add a build step that does mvn deploy or similar. Dare I ask what I'm missing having chosen the full-fat option..? If you're asking what you cannot do with freeform jobs: I don't know of anything. I think the Maven-style job is just a convenience to get very basic CI set up as quickly as possible, for people without much technical know-how. If you're asking for more details on limitations of the Maven-style job: it's been awhile, but IIRC my group had several problems. One such was that the Jenkins Git plugin did not fire Maven-style jobs upon receiving the push notification from GitHub. Another really serious problem is that you can't add arbitrary shell script as a post-build step. And needing to do this is, in my experience, extremely common. It wouldn't be that big of an issue if there were an easy way to later convert a Maven-style job to a freestyle job should the need arise. But try a web search on that topic and you'll see what I mean about it being a highly non-trivial problem. Regards, Curtis On Tue, Sep 23, 2014 at 8:56 AM, James Green james.mk.gr...@gmail.com javascript:; wrote: News to me. Ironically I'm just setting up a new Jenkins job so tried the freeform style - I can no longer see Deploy artifacts to Maven repository as a post-build action. Dare I ask what I'm missing having chosen the full-fat option..? On 23 September 2014 14:02, Curtis Rueden ctrue...@wisc.edu javascript:; wrote: The Maven style build will also lock you in to a small subset of Jenkins's usual features. And when you eventually need a feature not available with a Maven-style build, there is no conversion path from Maven-style to Freestyle -- you have to recreate the job (losing the build history etc.). -Curtis On Sep 23, 2014 7:33 AM, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; wrote: Freestyle does not mess with your build and change it from building the way maven intends. Google stephen's java adventures Jenkins maven considered evil for a more detailed discussion On Tuesday, 23 September 2014, James Green james.mk.gr...@gmail.com javascript:; wrote: On 23 September 2014 02:23, Curtis Rueden ctrue...@wisc.edu javascript:; javascript:; wrote: Also, stay away from the Jenkins Maven style job. Freestyle is more flexible and less buggy. Based on ..? -- Sent from my phone -- Sent from my phone -- “If the American people ever allow private banks to control the issue of their currency, first by inflation, then by deflation, the banks...will deprive the people of all property until their children wake-up homeless on the continent their fathers conquered... The issuing power should be taken from the banks and restored to the people, to whom it properly belongs. -- Thomas
Re: usage with Jenkins
On Tuesday, 23 September 2014, Grover Blue grover.b...@gmail.com wrote: I'd like to weigh in on this. The maven-based job type is great for quick or single-dimensional project, especially when you know the scope will not change. I tend to prefer freestyle because of flexibility. In reality, the solution is to just have one project type with varied initialization types. I'm pretty sure that's happening in the backend, Ha! So not the case. The evil job type sets up a remoting connection to within the maven process and this lets Jenkins muck about. Regular jobs fork a shell on the slave doing the obvious thing... Ie Jenkins drives the build Maven jobs have two back-to-back remoting channels and drive Jenkins to an extent When I say its evil, I'm not joking but the details are hidden (needs confirmation). BTW, in order to have artifacts listed one has to enable artifact archiving, not publishing. Everything works now (except for the job stalling on deployment to a self-signed cert GF 4.1 installation. :) On Tue, Sep 23, 2014 at 2:43 PM, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; wrote: FYI my aim is to supersede the evil job type with some enhanced reporting in what is currently called the literate job type. That would mean you'd get the per-module reporting. The current evil job type's other killer feature is automatic downstream job triggering... Which is actually broken as it does not take into account the local repo that the -SNAPSHOTs may or may not have been deployed into and assumes that `package` is the same as `deploy` as far as triggering is concerned as well as ignoring that deployment might be to a staging repo, so the artifacts may not be available downstream... However, despite being fundamentally broken at every level, you would be surprised how many people feel locked into the evil job type because of this... In short, there is so many issues with it that I cannot recommend its use... The only semi useful feature from my PoV is per module reporting. (Sadly my day job has me having to support the evil job type from time to time... Though usually those tickets get picked up by Kohsuke if I start another evil job type tirade ;-) ) On Tuesday, 23 September 2014, Curtis Rueden ctrue...@wisc.edu javascript:; wrote: Hi James, I can no longer see Deploy artifacts to Maven repository as a post-build action. Just add a build step that does mvn deploy or similar. Dare I ask what I'm missing having chosen the full-fat option..? If you're asking what you cannot do with freeform jobs: I don't know of anything. I think the Maven-style job is just a convenience to get very basic CI set up as quickly as possible, for people without much technical know-how. If you're asking for more details on limitations of the Maven-style job: it's been awhile, but IIRC my group had several problems. One such was that the Jenkins Git plugin did not fire Maven-style jobs upon receiving the push notification from GitHub. Another really serious problem is that you can't add arbitrary shell script as a post-build step. And needing to do this is, in my experience, extremely common. It wouldn't be that big of an issue if there were an easy way to later convert a Maven-style job to a freestyle job should the need arise. But try a web search on that topic and you'll see what I mean about it being a highly non-trivial problem. Regards, Curtis On Tue, Sep 23, 2014 at 8:56 AM, James Green james.mk.gr...@gmail.com javascript:; javascript:; wrote: News to me. Ironically I'm just setting up a new Jenkins job so tried the freeform style - I can no longer see Deploy artifacts to Maven repository as a post-build action. Dare I ask what I'm missing having chosen the full-fat option..? On 23 September 2014 14:02, Curtis Rueden ctrue...@wisc.edu javascript:; javascript:; wrote: The Maven style build will also lock you in to a small subset of Jenkins's usual features. And when you eventually need a feature not available with a Maven-style build, there is no conversion path from Maven-style to Freestyle -- you have to recreate the job (losing the build history etc.). -Curtis On Sep 23, 2014 7:33 AM, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; javascript:; wrote: Freestyle does not mess with your build and change it from building the way maven intends. Google stephen's java adventures Jenkins maven considered evil for a more detailed discussion On Tuesday, 23 September 2014, James Green james.mk.gr...@gmail.com javascript:; javascript:; wrote: On 23 September 2014 02:23, Curtis Rueden ctrue...@wisc.edu javascript:; javascript:;
Re: usage with Jenkins
Thanks for the educations! :) On Tue, Sep 23, 2014 at 3:55 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Tuesday, 23 September 2014, Grover Blue grover.b...@gmail.com wrote: I'd like to weigh in on this. The maven-based job type is great for quick or single-dimensional project, especially when you know the scope will not change. I tend to prefer freestyle because of flexibility. In reality, the solution is to just have one project type with varied initialization types. I'm pretty sure that's happening in the backend, Ha! So not the case. The evil job type sets up a remoting connection to within the maven process and this lets Jenkins muck about. Regular jobs fork a shell on the slave doing the obvious thing... Ie Jenkins drives the build Maven jobs have two back-to-back remoting channels and drive Jenkins to an extent When I say its evil, I'm not joking but the details are hidden (needs confirmation). BTW, in order to have artifacts listed one has to enable artifact archiving, not publishing. Everything works now (except for the job stalling on deployment to a self-signed cert GF 4.1 installation. :) On Tue, Sep 23, 2014 at 2:43 PM, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; wrote: FYI my aim is to supersede the evil job type with some enhanced reporting in what is currently called the literate job type. That would mean you'd get the per-module reporting. The current evil job type's other killer feature is automatic downstream job triggering... Which is actually broken as it does not take into account the local repo that the -SNAPSHOTs may or may not have been deployed into and assumes that `package` is the same as `deploy` as far as triggering is concerned as well as ignoring that deployment might be to a staging repo, so the artifacts may not be available downstream... However, despite being fundamentally broken at every level, you would be surprised how many people feel locked into the evil job type because of this... In short, there is so many issues with it that I cannot recommend its use... The only semi useful feature from my PoV is per module reporting. (Sadly my day job has me having to support the evil job type from time to time... Though usually those tickets get picked up by Kohsuke if I start another evil job type tirade ;-) ) On Tuesday, 23 September 2014, Curtis Rueden ctrue...@wisc.edu javascript:; wrote: Hi James, I can no longer see Deploy artifacts to Maven repository as a post-build action. Just add a build step that does mvn deploy or similar. Dare I ask what I'm missing having chosen the full-fat option..? If you're asking what you cannot do with freeform jobs: I don't know of anything. I think the Maven-style job is just a convenience to get very basic CI set up as quickly as possible, for people without much technical know-how. If you're asking for more details on limitations of the Maven-style job: it's been awhile, but IIRC my group had several problems. One such was that the Jenkins Git plugin did not fire Maven-style jobs upon receiving the push notification from GitHub. Another really serious problem is that you can't add arbitrary shell script as a post-build step. And needing to do this is, in my experience, extremely common. It wouldn't be that big of an issue if there were an easy way to later convert a Maven-style job to a freestyle job should the need arise. But try a web search on that topic and you'll see what I mean about it being a highly non-trivial problem. Regards, Curtis On Tue, Sep 23, 2014 at 8:56 AM, James Green james.mk.gr...@gmail.com javascript:; javascript:; wrote: News to me. Ironically I'm just setting up a new Jenkins job so tried the freeform style - I can no longer see Deploy artifacts to Maven repository as a post-build action. Dare I ask what I'm missing having chosen the full-fat option..? On 23 September 2014 14:02, Curtis Rueden ctrue...@wisc.edu javascript:; javascript:; wrote: The Maven style build will also lock you in to a small subset of Jenkins's usual features. And when you eventually need a feature not available with a Maven-style build, there is no conversion path from Maven-style to Freestyle -- you have to recreate the job (losing the build history etc.). -Curtis On Sep 23, 2014 7:33 AM, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; javascript:; wrote: Freestyle does not mess with your build and change it from building the way maven intends. Google stephen's java adventures Jenkins maven considered evil
