jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Identify somehow public API
Date Mon, 03 Apr 2017 11:34:55 GMT
On 3 April 2017 at 11:31, Felix Schumacher
<felix.schumacher@internetallee.de> wrote:
>
>
> Am 3. April 2017 11:47:11 MESZ schrieb Antonio Gomes Rodrigues <ra0077@gmail.com>:
>>Hi,
>>
>>I don't think it's too controle more but to allow to deprecate them
>>before
>>remove them.
>
> I don't understand, of you are pro marking public api explicitly, or for deprecating
public api that was never meant to be public and removing them later on.
>
> I would go with the second option. Using the public keyword as it was meant by java.
If we want to remove a public api, we should deprecate it and removed it in a later version
- if it is disable at all.

That's not generally possible unless a project only uses a single Java package.

Also note that changes to protected items may also affect 3rd parties.

As to how to document classes/methods:

There could be multiple .internal package names for code that is not
intended for external use.
(Oracle does this with the com.* packages)

It's also possible to define Javadoc tags when invoking javadoc.
These will appear in the source and the Javadoc.
Or JMeter could define its own annotations.
These can be propagated to class files if required.

Probably the first step is to add Clirr or similar to the build
process. Or at least to the release process.
If there are lots of changes it may be necessary to automate some of the checks.

Potentially the output from Clirr can also be used to check the @since
markers, but that would need some work to automate.

> Felix
>
>>It will allow to warn users that manipulate JMeter code through custom
>>code
>>(Groovy / Javascript
>>/Beanshell) and for plugin developers.
>>
>>Antonio
>>
>>2017-04-03 9:15 GMT+02:00 Andrey Pokhilko <apc4@ya.ru>:
>>
>>> Hi,
>>>
>>> I don't support this, because it will limit extenders to much smaller
>>> API than they have now. Just because we hit couple of methods that
>>> caused issues with extensions, does not mean we should _control more_
>>> what is used. Why limit the freedom? IMO benefits here much less than
>>> loss of extension potential.
>>>
>>> Andrey Pokhilko
>>>
>>> On 03.04.2017 08:44, Philippe Mouawad wrote:
>>> > Hello,
>>> > I think it would be interesting to identify in code public API for
>>users
>>> > that would manipulate JMeter code through custom code (Groovy /
>>> Javascript
>>> > /Beanshell) and for plugin developers.
>>> >
>>> > This is to avoid breaking backWard compatibility and to allow us to
>>make
>>> > cleanups and evolution in a fast and safe way.
>>> >
>>> >
>>> > I didn't find any existing tag to do that, maybe we could create a
>>> javadoc
>>> > or annotation to do that.
>>> >
>>> > We could then have it in javadocs and run backward cmpat checker.
>>> >
>>> > Thoughts ?
>>> >
>>> > Regards
>>> > Philippe
>>> >
>>> >
>>>
>>>

Mime
View raw message