On Thu, 9 Nov 2017 00:48:47 +0100
Michael Vorburger <[email protected]> wrote:
> while starting to work on
> https://jira.opendaylight.org/browse/INFRAUTILS-19, I've realized
> something I wanted to run by you / anyone else interested on list
> before I raise respective Gerrits:
> 
> In https://git.opendaylight.org/gerrit/#/c/65100/ we bumped it but
> it's already outdated, that's 3.2.3 but current is 3.2.5 already. But
> IMHO we should just remove the dependencyManagement for
> dropwizard.metric from odlparent, because:
> 
> Today it's not much used anyway - only 2 artifacts in controller
> depend on it - /sal-clustering-commons & sal-distributed-datastore,
> and they could well just declare it themselves directly. The only
> other usage of io.dropwizard.metrics I've found in all of autorelease
> was in netvirt, but that one was fake / left-over - about to be gone
> with the wind via https://git.opendaylight.org/gerrit/#/c/65339/.

That’s good enough for me...

> Tomorrow, projects wishing to expose metrics will get use
> dropwizard.metrics by way of an (upcoming) infrautils.metrics
> dependency anyway, instead of a direct dependency to
> dropwizard.metrics in their POM. While we cannot enforce this of
> course, remove it from odlparent dependencyManagement would make it
> clearer IMHO. More importantly though, a quick test reveals that
> parent POM depenencyManagement appears to be "stronger" than an
> indirect transitive dependency - PITA. So, in this specific case,
> best IMHO jst not to have a parent POM depenencyManagement - it's not
> required, and will only cause problems to projects who are going to
> depend on infrautils.metrics.

... although in general I’d rather have an actual change in use before
we decide how to migrate.

I know you’ve heard this already, but it makes it an *awful* lot
easier to get things right if you write something in a project which
uses it, before moving it to somewhere shareable. One day hopefully
you’ll understand this ;-). In this particular case, since having the
dependency management is a hindrance to alternative solutions, and it’s
only used in one project, I don’t mind removing it.

> Makes sense to you & OK for you guys if I raise a controller change
> to add the fixed dependency, and another one to remove
> dropwizard.metric dependencyManagement from odlparent?

OK for me, but hurry up if you want it in odlparent 3 (you don’t need
to wait for the controller change).

Regards,

Stephen

Attachment: pgpc3E2aVr0y1.pgp
Description: OpenPGP digital signature

_______________________________________________
controller-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Reply via email to