On Tue, 18 Jun 2019 at 00:40, Adrian Cole <adrian.f.c...@gmail.com> 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 classpath. > On Tue, Jun 18, 2019, 4:13 AM sebb <seb...@gmail.com> 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 <wu.sheng.841...@gmail.com> 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: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
