incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Cole <adrian.f.c...@gmail.com>
Subject Re: Maven coordinates (was: Move the Zipkin repos back, as the community has voted to leave.)
Date Tue, 18 Jun 2019 09:37:24 GMT
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 <sebbaz@gmail.com> wrote:

> On Tue, 18 Jun 2019 at 00:40, Adrian Cole <adrian.f.cole@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 <sebbaz@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.841108@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message