Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
MIME-Version: 1.0
References: <CAB917RK6U5np3V8CBe7yjswF8KC6tM1xEzbJOc6DMhzF77cVwQ@mail.gmail.com>
 <CAOGo0VYueT-=br6+vJ5A5tnd2YKYsNMfYD9sVSN8SEoim_jY4Q@mail.gmail.com>
 <5754668F.7080900@apache.org> <CAOGo0Vang51CVoNua6O-u0+2qReYwDz3U5YjWVgaiJdnX03Z5A@mail.gmail.com>
 <CACZkXPxEEXAQjeBanqt5JGRiCfCUpThitmccqTX2eU-Rsg0UAA@mail.gmail.com>
 <CALznzY4Da7jU7ut+WL9mnRJY_wE0AG7Aqa3E40E+FdT+anM-Ng@mail.gmail.com>
 <db4b12cf-fa3b-092b-6fa5-131844d7e00b@apache.org> <CALznzY66_Z5GaYq7dz+60RkwFnzOcV7hLV2Gw5LxUu-emdJWiA@mail.gmail.com>
 <4cdd3f7c-b2fa-171c-02b0-68e1e510d7e1@apache.org> <CALznzY7QfJu4GZn2binewzWLjVJZxiao-iM+-MKbBv634r9f_Q@mail.gmail.com>
 <njoacf$qsp$1@ger.gmane.org> <trinity-d67252df-6a88-40e3-bd61-c3584d2997fa-1465888458376@3capp-gmx-bs18>
 <CAE9L6G38moTBpwH=tJUWGa+RxFqLtHA8EAPvdae9yeejpMprKA@mail.gmail.com>
 <CACZkXPyCROVM3p=QHsmBVkq+7YYV8QvA_1pcB6-cOvfYnQXr4w@mail.gmail.com> <CAE9L6G3uf9HUpOr+ob32-Rxw0gOAFCBsL+P=Et1MndiDcFYw4w@mail.gmail.com>
In-Reply-To: <CAE9L6G3uf9HUpOr+ob32-Rxw0gOAFCBsL+P=Et1MndiDcFYw4w@mail.gmail.com>
From: James Carman <james@carmanconsulting.com>
Date: Tue, 14 Jun 2016 15:24:58 +0000
Message-ID: <CALznzY5pM-mc935_kkQvTx6eB9G61Eg0Ge-A8dZ7jaVMqoOXcg@mail.gmail.com>
Subject: Re: Re: [ALL] About binary compatibility
To: Commons Developers List <dev@commons.apache.org>, gudnabrsam@gmail.com
Content-Type: multipart/alternative; boundary=94eb2c07ccfc368af205353e9c01
archived-at: Tue, 14 Jun 2016 15:25:16 -0000

--94eb2c07ccfc368af205353e9c01
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Perhaps the new ASM-based replacement for CLIRR could have those as one of
its "components" in its TLP?

On Tue, Jun 14, 2016 at 11:00 AM Matt Benson <gudnabrsam@gmail.com> wrote:

> On Jun 14, 2016 9:55 AM, "Gary Gregory" <garydgregory@gmail.com> wrote:
> >
> >
> > On Jun 14, 2016 7:45 AM, "Matt Benson" <gudnabrsam@gmail.com> wrote:
> > >
> > > On Tue, Jun 14, 2016 at 2:14 AM, Andrey Loskutov <loskutov@gmx.de>
> wrote:
> > >
> > > > I like the way Eclipse it does for years:
> > > >
> > > > 1) Everything inside **/internal/ packages is non API by definition
> > > > 2) MANIFEST.MF to use OSGI "Export-Package" attribute for "publishe=
d"
> > > > packages
> > > > 3) Javadoc @noextend tag for classes not intended to be extended
> > > > 4) Javadoc @noimplement tag for interfaces
> > > >
> > > > If "real" annotations were used for points 3 and 4, they could live
> > > alongside a Java (6) Processor that, if the user had annotation
> processing
> > > enabled, could fail the build (pretty sure this is doable).
> >
> > But where do these annotations live? Does each Commons component
> duplicate them?
> >
>
> I thought about that, and would conclude that they should live in a thin
> compile-time-only dependency library (it may be the case that usable
> versions of these annotations already exist someplace, but the processor
> would still have to be provided in this manner, so it doesn't really chan=
ge
> anything). No reason this couldn't be used outside Commons either,
> actually.
>
> Matt
>
> > Gary
> >
> > >
> > > Matt
> > >
> > >
> > > > A bonus for libraries with correct MANIFEST.MF is that they can be
> > > > directly used as bundles inside any OSGI container (also Eclipse).
> > > >
> > > > Example:
> > > > /**
> > > >  * An observable value whose changes can be vetoed by listeners.
> > > >  *
> > > >  * @param <T>
> > > >  *            the type of value being observed
> > > >  *
> > > >  * @noextend This interface is not intended to be extended by
> clients.
> > > >  * @noimplement This interface is not intended to be implemented by
> > > > clients.
> > > >  *              Clients should instead subclass one of the classes
> that
> > > >  *              implement this interface. Note that direct
> implementers of
> > > > this
> > > >  *              interface outside of the framework will be broken i=
n
> future
> > > >  *              releases when methods are added to this interface.
> > > >  *
> > > >  * @since 1.0
> > > >  *
> > > >  */
> > > > public interface IVetoableValue<T> extends IObservableValue<T> {
> > > >
> > > > Kind regards,
> > > > Andrey Loskutov
> > > >
> > > > http://google.com/+AndreyLoskutov
> > > >
> > > >
> > > > > Gesendet: Dienstag, 14. Juni 2016 um 09:03 Uhr
> > > > > Von: "J=C3=B6rg Schaible" <joerg.schaible@bpm-inspire.com>
> > > > > An: dev@commons.apache.org
> > > > > Betreff: Re: [ALL] About binary compatibility
> > > > >
> > > > > Hi,
> > > > >
> > > > > James Carman wrote:
> > > > >
> > > > > > Agree we should have a "source of truth". Is there something
> wrong with
> > > > > > using an "internal" or "impl" package name? The bundle plugin f=
or
> OSGi
> > > > > > doesn't export these by default, which would be a nice side
> effect! :).
> > > > >
> > > > > While it is a step in the right direction, a package scoped
> solution does
> > > > > not solve the problem of a public interface that should not be
> > > > implemented
> > > > > directly (as we've seen with the BCEL visitor). Time for Java 8 a=
nd
> its
> > > > > default implementations ...
> > > > >
> > > > > Cheers,
> > > > > J=C3=B6rg
> > > >
> > > > -------------------------------------------------------------------=
--
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
>

--94eb2c07ccfc368af205353e9c01--