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 yes - what? I still think that this could solve a lot of > problems we were having and shouldn't have a big impact on Maven itself. If > it doesn't break anything and I would implement something like that ... what > would the chances that it gets accepted be? > > Chris > > > ________________________________________ > Von: Ron Wheeler <rwhee...@artifact-software.com> > Gesendet: Donnerstag, 7. Januar 2016 16:06 > An: users@maven.apache.org > Betreff: Re: AW: How to manage dependency "includes"? > > If you are using Eclipse with the m2e plug-ins (we use Eclipse/STS which > comes with this), it will tell you what versions are being included as > transitive dependencies. > > Our approach removed the decision about library versions from the > developers and put it into the project manager's hand so that: > - Adding a library had some management visibility - license > compatibility, vendor/developer stability, avoiding duplication of > functionality, library testing > - Programmers did not have to worry about incorrect or missing dependencies > - Programmers could move to a new project quickly. > - updating a library version updated automatically updated all projects > > It took a bit of work once we decided to get organized but it paid off > very quickly in programmer productivity and improved project schedule > stability > > Once you have found the source jar for the library and included it in > one of your libraries, it is available for every module. > > Ron > > > On 07/01/2016 9:25 AM, Christofer Dutz wrote: >> Hi Ron, >> >> Well I guess that's out of the question. >> >> We were thinking about that, but the normal workflow would be: >> - Search in the company nexus which lib provides a given package >> - Include that in the pom >> >> That would work around the "managed-pom" approach. So users would have to >> look at each dependency, if there is a special pom version in the system. I >> think that's definitely not going to work. >> >> In this company there are about 200 developers working on 50-60 different >> projects, that are assembled to about 20 different products. Currently we'll >> live with excluding stuff and having users add missing dependencies during >> the unit-, integration- , acceptance-test phases, but it would have been >> easier with some "exclusions/inclusions" mechanism. >> >> Chris >> >> ________________________________________ >> Von: Ron Wheeler <rwhee...@artifact-software.com> >> Gesendet: Montag, 4. Januar 2016 17:19 >> An: users@maven.apache.org >> Betreff: Re: How to manage dependency "includes"? >> >> You can simplify the problem that you are having by making a module that >> includes the correct version of the third party modules and having your >> modules depend on that with a "provided" scope. >> This also makes all of your jars and wars a lot smaller since only one >> copy of each API is included in the whole project rather than having the >> code appear in every one of your modules that needs it. >> >> This speeds your builds by a lot and save individual developers from >> having to think about the "correct" version of each library. They just >> include the aggregated libraries that they need. For example Apache >> Commons stuff would be supplied by your module >> com.example:myapachecommons:1.0-SNAPSHOT with scope provided. >> >> http://blog.artifact-software.com/tech/?tag=maven might be a useful set >> of articles. >> >> >> Ron >> On 04/01/2016 3:38 AM, Christofer Dutz wrote: >>> Hi, >>> >>> >>> I am currently cleaning up in the dependencies of a quite big set of big >>> projects. For this I am making a lot of use of dependency management. One >>> thing I did come across quite a lot of times is this problem: >>> >>> >>> Some libs reference undesired libs, mostly API libs (in most cases they >>> reference artifacts that contain parts of some API packages). To prevent >>> them from being used, we exclude them in the dependencyManagement section. >>> Now the downside is that now the API packages are missing. In order to fix >>> this, we now have to manually add dependencies to the API modules wherever >>> the artifact is used. It would be cool, if there was not only an >>> "exclusion" but also an "inclusion" mechanism in dependencyManagement, so >>> we could actually manage situations like this. >>> >>> >>> Is there a better way of resolving this type of problem? Would adding a >>> feature like the "inclusions" to Maven be a good idea? If not, what are the >>> problems with it? If yes, what can I do to help get it in (Would be glad to >>> contribute something like this)? >>> >>> >>> Chris >>> >>> >>> >>> >> -- >> 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 >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > -- > 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 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- 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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
