Re: Only one POM with dependencyManagement for entire company
Hi Anders, thx for your hint. Just only a remark that i am not using jBoss poms because i am trying to be independent in java code. Instead i am using javax:javaee-api:7.0 which works very well + other artifacts with scope: provided. - BR, tibor17 -- View this message in context: http://maven.40175.n5.nabble.com/Only-one-POM-with-dependencyManagement-for-entire-company-tp5814669p5814769.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Only one POM with dependencyManagement for entire company
My strategy is for the corporate POM to contain the fundamental settings like locking down maven plugins and any global legal stuff. Then each department should come up with their own POM under that, then the same for each project. Cheers, Paul On Tue, Nov 18, 2014 at 12:26 PM, tibor17 tibo...@lycos.com wrote: Hi All, I would like to get your help. I am still trying to explain that very large commercial company (don't mean ASF) should not have one hotspot POM with only one dependencyManagement (DM). One DM is too weak rule, i would say. My arguments are that one DM section will not fit to the needs of 4 departments having many applications in each and much more Maven modules in each app. They want to override a dependency versions in each leaf in dependency section. I am calling this strategy an evil because it would stick to the dependencies forever and it would be very hard to change dependencies in all applications at once. Would you mind to explain the strategies for creating a successful corporative hierarchy of POMs? My proposal was to build a dependency tree between departments, which is very easy. Currently there are only two levels in the hierarchy. So I did this way and created BOM files with dependencyMgmt for internal and external artifacts in each level. Those artifacts are not duplicated in the first and second level. Is it good or wrong? - BR, tibor17 -- View this message in context: http://maven.40175.n5.nabble.com/Only-one-POM-with-dependencyManagement-for-entire-company-tp5814669.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Only one POM with dependencyManagement for entire company
Thx Paull This I am basically trying to explain them as well. They are newbies and the funny thing is that they are ignoring us. My proposal was to serve a contact of Maven PMC experts so that they would pay for new environment, build process, POM structures, and CI systems setup but again with no interest. :( - BR, tibor17 -- View this message in context: http://maven.40175.n5.nabble.com/Only-one-POM-with-dependencyManagement-for-entire-company-tp5814669p5814678.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Only one POM with dependencyManagement for entire company
This I am basically trying to explain them as well. They are newbies and the funny thing is that they are ignoring us. My proposal was to serve a contact of Maven PMC experts so that they would pay for new environment, build process, POM structures, and CI systems setup but again with no interest. :( Well, reality will hit them sooner or later. Unfortunately, they will by then have created several anti-patterns which will take time to undo. To add to Paul's statement, I never add depMgmt to any kind of parent POM but pure project/product parent POM. BOMs are the way to go IMHO, as they will give the flexibility to change without having to release a new parent POM as well as allowing different projects to use different platforms (or whatever the BOM handle). JBoss EAP even provides their own BOMs which you could use as-is. For several customers using other (not-so-Maven-friendly) app servers I've created similar BOMs. /Anders - BR, tibor17 -- View this message in context: http://maven.40175.n5.nabble.com/Only-one-POM-with-dependencyManagement-for-entire-company-tp5814669p5814678.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Only one POM with dependencyManagement for entire company
After I wrote my response, I realized that I neglected the whole dependency management aspect. +1 with Anders. I am with him. There is no need to lock down dependencies in any corporate/division POM. Those are product concerns which are appropriate to use dependency management. Oh and I use BOMs too :-) Cheers, Paul On Tue, Nov 18, 2014 at 1:04 PM, Anders Hammar and...@hammar.net wrote: This I am basically trying to explain them as well. They are newbies and the funny thing is that they are ignoring us. My proposal was to serve a contact of Maven PMC experts so that they would pay for new environment, build process, POM structures, and CI systems setup but again with no interest. :( Well, reality will hit them sooner or later. Unfortunately, they will by then have created several anti-patterns which will take time to undo. To add to Paul's statement, I never add depMgmt to any kind of parent POM but pure project/product parent POM. BOMs are the way to go IMHO, as they will give the flexibility to change without having to release a new parent POM as well as allowing different projects to use different platforms (or whatever the BOM handle). JBoss EAP even provides their own BOMs which you could use as-is. For several customers using other (not-so-Maven-friendly) app servers I've created similar BOMs. /Anders - BR, tibor17 -- View this message in context: http://maven.40175.n5.nabble.com/Only-one-POM-with-dependencyManagement-for-entire-company-tp5814669p5814678.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
