Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
MIME-Version: 1.0
References: 
 <DB5PR05MB12856794ED56F3940A4EB993A2F20@DB5PR05MB1285.eurprd05.prod.outlook.com>
 <568A9B76.5040400@artifact-software.com>
 <DB5PR05MB1285839179C93A6EFC897ADCA2F50@DB5PR05MB1285.eurprd05.prod.outlook.com>
 <568E7F08.9060208@artifact-software.com>
 <DB5PR05MB1285CB1EAC0C62EEF6231B1FA2F60@DB5PR05MB1285.eurprd05.prod.outlook.com>
 <568FCE8A.40403@artifact-software.com>
 <DB5PR05MB1285AFA926AF6B6DE3E6F842A2F70@DB5PR05MB1285.eurprd05.prod.outlook.com>
In-Reply-To: 
 <DB5PR05MB1285AFA926AF6B6DE3E6F842A2F70@DB5PR05MB1285.eurprd05.prod.outlook.com>
From: Thomas Broyer <t.broyer@gmail.com>
Date: Sat, 09 Jan 2016 15:03:51 +0000
Message-ID: 
 <CAEayHEOLi=0NbgyttYH40Uh0S5nreSyWD_vFCmnmgWF14o9mWw@mail.gmail.com>
Subject: Re: AW: AW: How to manage dependency "includes"?
To: "users@maven.apache.org" <users@maven.apache.org>,
	"rwheeler@artifact-software.com" <rwheeler@artifact-software.com>
Content-Type: multipart/alternative; boundary=001a11406636a19afa0528e803e0

--001a11406636a19afa0528e803e0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.dutz@c-ware.de> a
=C3=A9crit :

> 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 crea=
te
> 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 proble=
ms
> 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 t=
he
> 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 <rwheeler@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 somethin=
g
> like that ... what would the chances that it gets accepted be?
> >
> > Chris
> >
> >
> > ________________________________________
> > Von: Ron Wheeler <rwheeler@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 whic=
h
> > 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 <rwheeler@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 th=
at
> >> includes the correct version of the third party modules and having you=
r
> >> 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 t=
he
> >> 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=3Dmaven 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: rwheeler@artifact-software.com
> >> skype: ronaldmwheeler
> >> phone: 866-970-2435, ext 102
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
> > --
> > Ron Wheeler
> > President
> > Artifact Software Inc
> > email: rwheeler@artifact-software.com
> > skype: ronaldmwheeler
> > phone: 866-970-2435, ext 102
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

--001a11406636a19afa0528e803e0--