incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Maven coordinates (was: Move the Zipkin repos back, as the community has voted to leave.)
Date Tue, 18 Jun 2019 09:32:58 GMT
On Tue, 18 Jun 2019 at 00:40, Adrian Cole <> wrote:
> on the maven topic:
> for almost all cases there will be no classpath problem. the most common
> entry point into maven was the package for "brave" which was never released
> under an apache group id. the underlying libraries had very few call sites
> in comparison. the "bom" most commonly used was also never released.

There appear to be at least 7 Maven packages under org.apache.zipkin.
These have been released, and cannot be changed.

I don't know if any of them have been used by 3rd parties, but if they have:

If any of them use the same Java package name as io.zipkin Maven
packages, then there is a chance that two jars with the same class
names but different API and behaviour will end up on the classpath.
This can cause failures that can be hard to debug.

> the server itself was explicitly marked as not supported as a library, so
> there is not much impact to group ids there. many didn't upgrade to the ASF
> build according to support chatter. like most projects, getting folks to
> upgrade is a task in itself.
> main thing, we will take this liability of group ids on as a community in
> other words, and it is less a problem than being unable to control our
> repositories which is the current dilemma. you dont need to worry about
> this.

This is not about who controls the entries in Maven Central.
It is about ensuring that Maven knows which jars can safely co-exist
on the classpath.

It may help the project to set up a relocation POM.
AIUI this may help Maven to know that org.apache.zipkin is now
io.zipkin, and thus hopefully prevent both appearing on the same

> On Tue, Jun 18, 2019, 4:13 AM sebb <> wrote:
> > I agree it's not a block, but there is scope for some classpath confusion.
> >
> > If someone has an app that includes both the ASF and non-ASF Zipkin
> > jars, both will end up on the Maven classpath.
> > There is no way to tell which version of a particular class will end
> > up being loaded.
> >
> > A Maven relocation pom might help to ensure that only one version of
> > the jars ends up on the Maven classpath, but I've not tried that.
> >
> > The recommended procedure is to always ensure that there is a 1:1
> > relationship between Maven coords and Java package name.
> > There can then be no chance of incompatible jars on the classpath.
> >
> > On Mon, 17 Jun 2019 at 14:17, Sheng Wu <> wrote:
> > >
> > > Hi
> > > Zipkin doesn’t change the java package name, and had no plan to do that.
> > > We just changed the groupid, and are reverting it back to `io.zipkin`.
> > >
> > > So, I don’t see this as a block.
> > >

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message