Am 30.09.2026 um 22:31 schrieb Julian Reschke:
Am 30.09.2026 um 21:05 schrieb Gary Gregory:
Hi.
Unless the plug in figures out what's what by itself on a per package
It does.
basis, this will be unmaintanable IMO. I don't see the point of this
anyway
since we publish a JAR file, not packages.
The JAR files contains packages, no?
OSGi allows you to restrict what other components see (can use), and it
also declares which other packages (versions) it needs. That's useful
when using generic stuff like other commons components or maybe SLF4J
etc. All that goes into MANIFEST.MF.
(and yes, there likely are other approaches, but OSGi is what I know)
Let me experiment with this, and I'll come back with the results.
Best regards, Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Ok.
On the current master checkout, run:
mvn bundle:baseline
You'll get warnings like
[WARNING] org.apache.commons.collections4.bag: Excessive version
increase; detected 4.6.1, suggested 4.6.0
because the export version needlessly changed.
Then remove the deprecated ArrayStack class (and test); run again:
[ERROR] org.apache.commons.collections4: Version increase required;
detected 4.6.1, suggested 5.0.0
(correctly)
Of course running the bundle plugin can be integrated into the normal
build process.
The *correct* (semver) export versions can be configured in the pom, or,
better in the package-info files (with the obvious advantage of the
metadata being closer to the java code).
Like that:
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-commons/src/main/java/org/apache/jackrabbit/oak/commons/sort/package-info.java
Note that the above case is a nice example; it makes the build fail as
soon as ArrayStack is removed.
Best regards, Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
