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 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
