of course I meant "packages released as a *not* super high priority concern"
On Tue, Jun 18, 2019, 5:37 PM Adrian Cole <adrian.f.c...@gmail.com> wrote: > 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 >> >>
