AW: AW: AW: How to manage dependency "includes"?
But yes ... it's exactly what I want ... a "replace-with" option. But with exlucdes and includes I thought it should be possible to implement with the least impact on the rest of the Maven ecosystem. Chris Von: Thomas Broyer <t.bro...@gmail.com> Gesendet: Samstag, 9. Januar 2016 16:03 An: users@maven.apache.org; rwhee...@artifact-software.com Betreff: Re: AW: AW: How to manage dependency "includes"? IIUC, what you really want is a "replace with" rule. Couldn't that be done by a plugin? You could then configure it in the parent POM and have it executed everywhere. Le sam. 9 janv. 2016 10:59, Christofer Dutz <christofer.d...@c-ware.de> a écrit : > Thanks for that detailed post, but it's still not what I asked for :-( > I just finished the transition of ALL of the projects of a large > international bank from Ant to Maven. In parallell > what was initially about 70 more or less separate projects, that were > assembled to one huge monolithic application was changed in order to create > modules and the ability to assemble several applications, each with > different focusses. > > It was a huge challenge as you have to coordinate the wishes of > uncountable project-managers, developers and other stakeholders. We > encountered quite a large number of serious problems. Everyone that has > worked for a Bank knows you can't just go there and tell them what the > standard is, cause they'll tell you what their standard is ;-) > > So in the end we prohibited (by maven plugin) providing the version of > third party libraries, enforced the usage of a company-wide > dependencyManagement pom that is used in every project. Additionally we > enforced the rules of the dependency plugin to declare used dependencies > and not to rely on transitive dependencies. With this a lot of our problems > were solved. Even if the developers complain every now and then, but I > guess that's the price to pay for giving them the freedom they need and the > flexibility they want. Introducing a rather strict policy on the process as > you describe, is completely out of the question. You can't get 40 project > managers to discuss new versions. This meeting would probably never, ever > end ;-) > > So back to the question none has answered yet (would be cool if maybe > someone on the dev-team of Maven could respond): > Would an "EXCLUSION"/"INCLUSION" mechanism in dependencyManagement break > things, and would it be ok to fix up a Pull request implementing that > functionality? > > Chris > > ________________ > Von: Ron Wheeler <rwhee...@artifact-software.com> > Gesendet: Freitag, 8. Januar 2016 15:58 > An: users@maven.apache.org > Betreff: Re: AW: AW: How to manage dependency "includes"? > > In our setup, each project has its own parent POM and set of aggregated > third party libraries. Some sharing is done between products for really > common stuff like Spring, Apache Commons, Tomcat, etc. > The library com.artifact_software.projectA:reporting-library:1.2 might > be different from com.artifact_software.projectB:reporting-library:1.2 > if one used BIRT and the other used Jasper Reports. > > These should be under the control of the person/team that is responsible > for deciding what version of the third party libraries are to be allowed. > The following might be involved in the selection of a new library or a > request by a developer to upgrade a library. > - Product Manager - legal/licensing, market acceptance, documentation, > functionality issues > - Project manager - scheduling, testing, risk assessment, aggregation > strategy > - Lead developer - risk assessment, alternatives, technical analysis, > aggregation strategy > > At the beginning of each development sprint, we review the current > libraries to see what versions should be updated. > This does not completely eliminate changes to versions during the > development process as programmers run into opportunities to use > features from newer versions or discovery of critical bugs that require > a library upgrade in mid-sprint. > > This review is pretty short and usually involves the entire team so that > we can estimate the cost of changing a library - what modules will be > affected and require testing even if they are not being modified as part > of the sprint. > > Once this is done, the developers do not have to worry about > dependencies. Once the version of > com.artifact_software.projectA:commons-library:1.2 is set, the > developers do not have to worry about what version of each of the Apache > Commons libraries are included and module POMs should not include any > third party libraries unless there is a
AW: AW: AW: How to manage dependency "includes"?
Wasn't the option to add dependencies programatically by a plugin removed in 3.3.9? At least this is causing quite some problems with my FLexmojos plugin :-( Chris Von: Thomas Broyer <t.bro...@gmail.com> Gesendet: Samstag, 9. Januar 2016 16:03 An: users@maven.apache.org; rwhee...@artifact-software.com Betreff: Re: AW: AW: How to manage dependency "includes"? IIUC, what you really want is a "replace with" rule. Couldn't that be done by a plugin? You could then configure it in the parent POM and have it executed everywhere. Le sam. 9 janv. 2016 10:59, Christofer Dutz <christofer.d...@c-ware.de> a écrit : > Thanks for that detailed post, but it's still not what I asked for :-( > I just finished the transition of ALL of the projects of a large > international bank from Ant to Maven. In parallell > what was initially about 70 more or less separate projects, that were > assembled to one huge monolithic application was changed in order to create > modules and the ability to assemble several applications, each with > different focusses. > > It was a huge challenge as you have to coordinate the wishes of > uncountable project-managers, developers and other stakeholders. We > encountered quite a large number of serious problems. Everyone that has > worked for a Bank knows you can't just go there and tell them what the > standard is, cause they'll tell you what their standard is ;-) > > So in the end we prohibited (by maven plugin) providing the version of > third party libraries, enforced the usage of a company-wide > dependencyManagement pom that is used in every project. Additionally we > enforced the rules of the dependency plugin to declare used dependencies > and not to rely on transitive dependencies. With this a lot of our problems > were solved. Even if the developers complain every now and then, but I > guess that's the price to pay for giving them the freedom they need and the > flexibility they want. Introducing a rather strict policy on the process as > you describe, is completely out of the question. You can't get 40 project > managers to discuss new versions. This meeting would probably never, ever > end ;-) > > So back to the question none has answered yet (would be cool if maybe > someone on the dev-team of Maven could respond): > Would an "EXCLUSION"/"INCLUSION" mechanism in dependencyManagement break > things, and would it be ok to fix up a Pull request implementing that > functionality? > > Chris > > ________________ > Von: Ron Wheeler <rwhee...@artifact-software.com> > Gesendet: Freitag, 8. Januar 2016 15:58 > An: users@maven.apache.org > Betreff: Re: AW: AW: How to manage dependency "includes"? > > In our setup, each project has its own parent POM and set of aggregated > third party libraries. Some sharing is done between products for really > common stuff like Spring, Apache Commons, Tomcat, etc. > The library com.artifact_software.projectA:reporting-library:1.2 might > be different from com.artifact_software.projectB:reporting-library:1.2 > if one used BIRT and the other used Jasper Reports. > > These should be under the control of the person/team that is responsible > for deciding what version of the third party libraries are to be allowed. > The following might be involved in the selection of a new library or a > request by a developer to upgrade a library. > - Product Manager - legal/licensing, market acceptance, documentation, > functionality issues > - Project manager - scheduling, testing, risk assessment, aggregation > strategy > - Lead developer - risk assessment, alternatives, technical analysis, > aggregation strategy > > At the beginning of each development sprint, we review the current > libraries to see what versions should be updated. > This does not completely eliminate changes to versions during the > development process as programmers run into opportunities to use > features from newer versions or discovery of critical bugs that require > a library upgrade in mid-sprint. > > This review is pretty short and usually involves the entire team so that > we can estimate the cost of changing a library - what modules will be > affected and require testing even if they are not being modified as part > of the sprint. > > Once this is done, the developers do not have to worry about > dependencies. Once the version of > com.artifact_software.projectA:commons-library:1.2 is set, the > developers do not have to worry about what version of each of the Apache > Commons libraries are included and module POMs should not include any > third party libraries unless there is a good reason not to have it under > team management.
Re: AW: AW: AW: How to manage dependency "includes"?
HI, On 1/9/16 10:59 AM, Christofer Dutz wrote: Everyone that has worked for a Bank knows you can't > just go there and tell them what the standard is, > cause they'll tell you what their standard is ;-) Unfortunately true... So in the end we prohibited (by maven plugin) providing the version of third party libraries, > enforced the usage of a company-wide dependencyManagement pom > that is used in every project. Sounds like a good idea... > Additionally we enforced the rules of the dependency plugin to > declare used dependencies and not to rely on transitive dependencies. That is what i don't understand...where is the relationship to maven-dependency-plugin.May be i missed things here > With this a lot of our problems were solved. Which kind of problems...may be i missed things here... Would an "EXCLUSION"/"INCLUSION" mechanism in dependencyManagement break things, >and would it be ok to fix up a Pull request implementing that functionality? Hm...so you can do things like this (exclusion) single parts... group-a artifact-a 1.0 group-c excluded-artifact and since Maven 3.2.1 you exclude all transitive dependencies via: group-a artifact-a 1.0 * * ... Apart from that...an include does not make sense from my point of view cause this could lead to the impression that you you could add dependencies transitively..which makes no sense.. Furthermore changing the pom structure here would break all things This kind of changed could only be made (may be ...) in Maven 4??? Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: AW: AW: AW: How to manage dependency "includes"?
Well the maven-dependency-plugin has a goal "analyze-only" (https://maven.apache.org/plugins/maven-dependency-plugin/analyze-only-mojo.html) which reports dependencies, that are used, but not declared and that reports unused, but declared dependencies. We are simply using this. We had problems like if the Application consists of Project A, B and C then xml-apis is in version X, if we only use A and B, then it's a different version, because a different dependency imported another version transitively. We had a lot of problems with code that worked in 10 different Applications, but in one it broke. Usually it tuned out to be exactly one of these problems. Well for an example there is one lib, that references some other lib, that contains part of the JMS API 1.0. Unfortunately only part of it. Then in a different place we import the real JMS API 1.1. Now we needed to make sure the 1.1 versions are taken and then all of the API is imported. Without this we would have some parts be JMS 1.0 and the other half of the API classes be 1.1. We solved the problem by excluding the half JMS 1.0 api artifact and manually added the full JMS 1.1 artifact in parallel. This works, but it's ugly. So I had the idea that it would be good to have something like this: group-a artifact-a 1.0 half-apis jms javax.jms jms 1.1 To actually fully manage the dependencies of "artifact-a" Hope that's a little clearer. And I don't quite understand how it would break things. After all, all I'm doing is declare ... if you add a dependency to "artifact-a" leave away "half-apis:jms" and add "javax.jms:jms:1.1" instead. Chris Von: Karl Heinz Marbaise <khmarba...@gmx.de> Gesendet: Samstag, 9. Januar 2016 13:39 An: Maven Users List Betreff: Re: AW: AW: AW: How to manage dependency "includes"? HI, On 1/9/16 10:59 AM, Christofer Dutz wrote: > Everyone that has worked for a Bank knows you can't > just go there and tell them what the standard is, > cause they'll tell you what their standard is ;-) Unfortunately true... > > So in the end we prohibited (by maven plugin) providing the version of third > party libraries, > enforced the usage of a company-wide dependencyManagement pom > that is used in every project. Sounds like a good idea... > Additionally we enforced the rules of the dependency plugin to > declare used dependencies and not to rely on transitive dependencies. That is what i don't understand...where is the relationship to maven-dependency-plugin.May be i missed things here > With this a lot of our problems were solved. Which kind of problems...may be i missed things here... > Would an "EXCLUSION"/"INCLUSION" mechanism in dependencyManagement break > things, >and would it be ok to fix up a Pull request implementing that functionality? Hm...so you can do things like this (exclusion) single parts... group-a artifact-a 1.0 group-c excluded-artifact and since Maven 3.2.1 you exclude all transitive dependencies via: group-a artifact-a 1.0 * * ... Apart from that...an include does not make sense from my point of view cause this could lead to the impression that you you could add dependencies transitively..which makes no sense.. Furthermore changing the pom structure here would break all things This kind of changed could only be made (may be ...) in Maven 4??? Kind regards Karl Heinz Marbaise - 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: AW: AW: AW: How to manage dependency "includes"?
I was not expecting that you could adopt our solution completely. I does sound like you have a lot of it already incorporated into your processes. The aggregated POMs would probably fix your remaining issue with exclusions and version conflicts and would be easy to add to your existing practices. I suspect that the problem that you will have in getting acceptance of the kind of change that you are suggesting is that you seem to want to change the definition of the POM schema. There is a lot of infrastructure and third party tools that might be affected and getting a buy-in could take years. There are people in this forum who are in a better position than me to advise you on the possibility of acceptance of this idea. My opinion is that support from the m2e community would be important and Sonatype's support would move your idea a long way forward. Ron On 09/01/2016 4:59 AM, Christofer Dutz wrote: Thanks for that detailed post, but it's still not what I asked for :-( I just finished the transition of ALL of the projects of a large international bank from Ant to Maven. In parallell what was initially about 70 more or less separate projects, that were assembled to one huge monolithic application was changed in order to create modules and the ability to assemble several applications, each with different focusses. It was a huge challenge as you have to coordinate the wishes of uncountable project-managers, developers and other stakeholders. We encountered quite a large number of serious problems. Everyone that has worked for a Bank knows you can't just go there and tell them what the standard is, cause they'll tell you what their standard is ;-) So in the end we prohibited (by maven plugin) providing the version of third party libraries, enforced the usage of a company-wide dependencyManagement pom that is used in every project. Additionally we enforced the rules of the dependency plugin to declare used dependencies and not to rely on transitive dependencies. With this a lot of our problems were solved. Even if the developers complain every now and then, but I guess that's the price to pay for giving them the freedom they need and the flexibility they want. Introducing a rather strict policy on the process as you describe, is completely out of the question. You can't get 40 project managers to discuss new versions. This meeting would probably never, ever end ;-) So back to the question none has answered yet (would be cool if maybe someone on the dev-team of Maven could respond): Would an "EXCLUSION"/"INCLUSION" mechanism in dependencyManagement break things, and would it be ok to fix up a Pull request implementing that functionality? Chris Von: Ron Wheeler <rwhee...@artifact-software.com> Gesendet: Freitag, 8. Januar 2016 15:58 An: users@maven.apache.org Betreff: Re: AW: AW: How to manage dependency "includes"? In our setup, each project has its own parent POM and set of aggregated third party libraries. Some sharing is done between products for really common stuff like Spring, Apache Commons, Tomcat, etc. The library com.artifact_software.projectA:reporting-library:1.2 might be different from com.artifact_software.projectB:reporting-library:1.2 if one used BIRT and the other used Jasper Reports. These should be under the control of the person/team that is responsible for deciding what version of the third party libraries are to be allowed. The following might be involved in the selection of a new library or a request by a developer to upgrade a library. - Product Manager - legal/licensing, market acceptance, documentation, functionality issues - Project manager - scheduling, testing, risk assessment, aggregation strategy - Lead developer - risk assessment, alternatives, technical analysis, aggregation strategy At the beginning of each development sprint, we review the current libraries to see what versions should be updated. This does not completely eliminate changes to versions during the development process as programmers run into opportunities to use features from newer versions or discovery of critical bugs that require a library upgrade in mid-sprint. This review is pretty short and usually involves the entire team so that we can estimate the cost of changing a library - what modules will be affected and require testing even if they are not being modified as part of the sprint. Once this is done, the developers do not have to worry about dependencies. Once the version of com.artifact_software.projectA:commons-library:1.2 is set, the developers do not have to worry about what version of each of the Apache Commons libraries are included and module POMs should not include any third party libraries unless there is a good reason not to have it under team management. This also minimizes the changes to POMs. The parent POM's dependency management sets the versions for the release b
AW: AW: AW: How to manage dependency "includes"?
Thanks for that detailed post, but it's still not what I asked for :-( I just finished the transition of ALL of the projects of a large international bank from Ant to Maven. In parallell what was initially about 70 more or less separate projects, that were assembled to one huge monolithic application was changed in order to create modules and the ability to assemble several applications, each with different focusses. It was a huge challenge as you have to coordinate the wishes of uncountable project-managers, developers and other stakeholders. We encountered quite a large number of serious problems. Everyone that has worked for a Bank knows you can't just go there and tell them what the standard is, cause they'll tell you what their standard is ;-) So in the end we prohibited (by maven plugin) providing the version of third party libraries, enforced the usage of a company-wide dependencyManagement pom that is used in every project. Additionally we enforced the rules of the dependency plugin to declare used dependencies and not to rely on transitive dependencies. With this a lot of our problems were solved. Even if the developers complain every now and then, but I guess that's the price to pay for giving them the freedom they need and the flexibility they want. Introducing a rather strict policy on the process as you describe, is completely out of the question. You can't get 40 project managers to discuss new versions. This meeting would probably never, ever end ;-) So back to the question none has answered yet (would be cool if maybe someone on the dev-team of Maven could respond): Would an "EXCLUSION"/"INCLUSION" mechanism in dependencyManagement break things, and would it be ok to fix up a Pull request implementing that functionality? Chris Von: Ron Wheeler <rwhee...@artifact-software.com> Gesendet: Freitag, 8. Januar 2016 15:58 An: users@maven.apache.org Betreff: Re: AW: AW: How to manage dependency "includes"? In our setup, each project has its own parent POM and set of aggregated third party libraries. Some sharing is done between products for really common stuff like Spring, Apache Commons, Tomcat, etc. The library com.artifact_software.projectA:reporting-library:1.2 might be different from com.artifact_software.projectB:reporting-library:1.2 if one used BIRT and the other used Jasper Reports. These should be under the control of the person/team that is responsible for deciding what version of the third party libraries are to be allowed. The following might be involved in the selection of a new library or a request by a developer to upgrade a library. - Product Manager - legal/licensing, market acceptance, documentation, functionality issues - Project manager - scheduling, testing, risk assessment, aggregation strategy - Lead developer - risk assessment, alternatives, technical analysis, aggregation strategy At the beginning of each development sprint, we review the current libraries to see what versions should be updated. This does not completely eliminate changes to versions during the development process as programmers run into opportunities to use features from newer versions or discovery of critical bugs that require a library upgrade in mid-sprint. This review is pretty short and usually involves the entire team so that we can estimate the cost of changing a library - what modules will be affected and require testing even if they are not being modified as part of the sprint. Once this is done, the developers do not have to worry about dependencies. Once the version of com.artifact_software.projectA:commons-library:1.2 is set, the developers do not have to worry about what version of each of the Apache Commons libraries are included and module POMs should not include any third party libraries unless there is a good reason not to have it under team management. This also minimizes the changes to POMs. The parent POM's dependency management sets the versions for the release being developed so once the reference to the parent POM is changed, all the right versions of everything is automatically included in the module. This makes life really easy for developers - change one number in the module POM and start working. I hope that this helps. Ron On 08/01/2016 5:03 AM, Christofer Dutz wrote: > I agree, but this only woks as long as there is "THE" project manager. Here > there are several ones. The central instance that manages libraries and their > versions and handles conflict resolution is simply the one managing the > central dependencyManagement pom. All the project POMs are part of the > projects and these are responsibility of those teams and even live in > separate repos. > > But coming back to my initial question: > Would maven support of "exclusions" and "inclusions" in dependency management > break anything? If y
