On Sat, 10 Feb 2018 08:08:12 -0700, Gary Gregory wrote:
If a Java package and artifact ID contain "internal" or "private" in
the
name, that would be pretty clear.
Do you suggest that, say, the benchmarking codes in
"commons-rng-jmh" should be located in a top package
named "o.a.c.rng.jmh.internal"?
If all codes in a module are internal, it is redundant.
As I've written, it is pretty clear that "examples" or
"benchmarks" are not part of the "library".
What I'm asking is how to convey that <some_module>
should not be limited in its evolution (through
successive versions) by JAR hell considerations,
or Clirr errors.
Gilles
Gary
On Feb 10, 2018 07:17, "Stefan Bodewig" <[email protected]> wrote:
On 2018-02-10, Gilles wrote:
> Is there a convention for distinguishing codes with
> compatibility requirements from codes provided as
> development tools (unit tests, benchmarking, usage
> examples, integration tests, ...)?
In Compress we once had a package named _internal_ and a package
level
javadoc that said "This package is not part of Commons Compress'
published API."
http://commons.apache.org/proper/commons-compress/
javadocs/api-1.7/org/apache/commons/compress/compressors/
z/_internal_/package-summary.html
There also is a package that says "Experimental" in its javadocs,
but to
be honest it hasn't change din years (but likely isn't really used
by
anybody either).
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
