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 <[email protected]>
Gesendet: Freitag, 8. Januar 2016 15:58
An: [email protected]
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 <[email protected]>
Gesendet: Donnerstag, 7. Januar 2016 16:06
An: [email protected]
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 <[email protected]>
Gesendet: Montag, 4. Januar 2016 17:19
An: [email protected]
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: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
