You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2012/11/30 23:27:41 UTC
Re: svn commit: r1414683
On Thu, 2012-11-29 at 21:02 +0000, sebb wrote:
> On 28 November 2012 13:47, <ol...@apache.org> wrote:
> > Author: olegk
> > Date: Wed Nov 28 13:47:28 2012
> > New Revision: 1414683
> >
> > URL: http://svn.apache.org/viewvc?rev=1414683&view=rev
> > Log:
> > Had to make ClientExecChain and related classes public in order to make them accessible by the caching module
>
> If the classes are not intended to be part of the public API, this
> should at least be indicated in the Javadoc.
>
> Perhaps consider a rename to make it more obvious?
>
Hi Sebastian
The new APIs are still far from being final. With the latest changes I
am trying to reduce the public API footprint and ideally I would like to
keep ClientExecChain and related classes package private. However, I am
not sure it is possible since those APIs need to be accessible by the
caching module and potentially JMX module. We could theoretically
document those APIs as being internal, but then, again, we would end up
in a similar situation as with deprecated code. Would we really want to
change them and risk breaking existing applications that might rely on
them despite the warning in javadocs?
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: svn commit: r1414683
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2012-12-01 at 16:56 -0500, Gary Gregory wrote:
> How about using a .internal package?
>
> Gary
>
Sounds very reasonable if we decide to take the approach proposed by
Sebastian. There is still time to consider various options before the
4.3 API is frozen.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: svn commit: r1414683
Posted by Gary Gregory <ga...@gmail.com>.
How about using a .internal package?
Gary
On Dec 1, 2012, at 16:19, sebb <se...@gmail.com> wrote:
> On 30 November 2012 22:27, Oleg Kalnichevski <ol...@apache.org> wrote:
>> On Thu, 2012-11-29 at 21:02 +0000, sebb wrote:
>>> On 28 November 2012 13:47, <ol...@apache.org> wrote:
>>>> Author: olegk
>>>> Date: Wed Nov 28 13:47:28 2012
>>>> New Revision: 1414683
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=1414683&view=rev
>>>> Log:
>>>> Had to make ClientExecChain and related classes public in order to make them accessible by the caching module
>>>
>>> If the classes are not intended to be part of the public API, this
>>> should at least be indicated in the Javadoc.
>>>
>>> Perhaps consider a rename to make it more obvious?
>>>
>>
>> Hi Sebastian
>>
>> The new APIs are still far from being final. With the latest changes I
>> am trying to reduce the public API footprint and ideally I would like to
>> keep ClientExecChain and related classes package private.
>
> Good plan.
>
>> However, I am
>> not sure it is possible since those APIs need to be accessible by the
>> caching module and potentially JMX module. We could theoretically
>> document those APIs as being internal, but then, again, we would end up
>> in a similar situation as with deprecated code. Would we really want to
>> change them and risk breaking existing applications that might rely on
>> them despite the warning in javadocs?
>
> If application developers deliberately use classes etc. that are
> documented as being for internal use only then they need to deal with
> the consequences.
>
> So long as the internal classes etc. are clearly labelled as such, I
> don't have a problem with breaking strict binary compatibility.
>
>> Oleg
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: svn commit: r1414683
Posted by sebb <se...@gmail.com>.
On 30 November 2012 22:27, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Thu, 2012-11-29 at 21:02 +0000, sebb wrote:
>> On 28 November 2012 13:47, <ol...@apache.org> wrote:
>> > Author: olegk
>> > Date: Wed Nov 28 13:47:28 2012
>> > New Revision: 1414683
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1414683&view=rev
>> > Log:
>> > Had to make ClientExecChain and related classes public in order to make them accessible by the caching module
>>
>> If the classes are not intended to be part of the public API, this
>> should at least be indicated in the Javadoc.
>>
>> Perhaps consider a rename to make it more obvious?
>>
>
> Hi Sebastian
>
> The new APIs are still far from being final. With the latest changes I
> am trying to reduce the public API footprint and ideally I would like to
> keep ClientExecChain and related classes package private.
Good plan.
> However, I am
> not sure it is possible since those APIs need to be accessible by the
> caching module and potentially JMX module. We could theoretically
> document those APIs as being internal, but then, again, we would end up
> in a similar situation as with deprecated code. Would we really want to
> change them and risk breaking existing applications that might rely on
> them despite the warning in javadocs?
If application developers deliberately use classes etc. that are
documented as being for internal use only then they need to deal with
the consequences.
So long as the internal classes etc. are clearly labelled as such, I
don't have a problem with breaking strict binary compatibility.
> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org