Re: Maven coordinates (was: Move the Zipkin repos back, as the community has voted to leave.)
of course I meant "packages released as a *not* super high priority concern" On Tue, Jun 18, 2019, 5:37 PM Adrian Cole 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 wrote: > >> 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 >> classpath. >> >> > 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: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >>
Re: Maven coordinates (was: Move the Zipkin repos back, as the community has voted to leave.)
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 wrote: > 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 > classpath. > > > 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: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Maven coordinates (was: Move the Zipkin repos back, as the community has voted to leave.)
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 classpath. > 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: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
