if you would like to do, this feel free. this type of concern seems more like a github issue vs an incubator discussion. we have changed group ids in the past prior to Apache without complaints.
again the most important project from a dependency pinning pov, brave, was never released. knowing the community as I do I would rate the other packages released as a super high priority concern these are low level or niche libraries. it would have been a problem if we released brave but we didn't luckily. On Tue, Jun 18, 2019, 5:33 PM sebb <seb...@gmail.com> wrote: > 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 > >
