WIP ideas ‐ bnd 8.0.0 breaking changes - bndtools/bnd GitHub Wiki
This document collects ideas for things we would like to remove or change in a way that they will cause breaking changes. The reasons for doing so vary and include things like "deprecating and cutting off outdated features" or "revert sins from the past to make bnd easier to use"
Deprecation collector issue
Also consider https://github.com/bndtools/bnd/issues/6756
Separate / Extract maven-plugins and gradle-plugins
- e.g. there are discussions to either move them to Eclipse, Tycho (@laeubi) or OSGi
- idea: bndlib stays where it is as the core. the plugins go separate ways / maintainers. bnd focuses on bnd itself and maven / gradle knowledge goes to where a larger community is.
Make package substitution opt-in (instead of the default)
- see https://github.com/bndtools/bnd/pull/6847 and make the behaviour of
-nosubstitution: truethe default - also make behaviour of
-noimport:=truedirective forExport-Packageand-exportcontentsthe default, so that you have to explicitly enable substitution if you need that behaviour. - Why: recent discussions turned out that substitution requires deep OSGi knowledge and "know what you do". So this should be rather opt-in. It would make life for non-OSGi library authors out there easier.
Remove biz.aQute.tester and biz.aQute.junit
See https://github.com/bndtools/bnd/issues/6645
Rework Tagging
The way repository tags were added in 7.1 have the problem, that makes it hard to add new type of tags. See https://github.com/bndtools/bnd/pull/6612#issuecomment-2898763421 So this might be a topic for a breaking change in 8.x where we rework how tagging works.
Make use of interfaces in the parsing of class files
bnd contains some code to read / create java class files https://github.com/bndtools/bnd/blob/master/biz.aQute.bndlib/src/aQute/bnd/osgi/Clazz.java
I have at least one case where I want to get some customizations here in Tycho and also the JDK is preparing for providing an clazz file support API so it would be good to make the whole thing interface based also for related types like PackageRef.
Make Jar an interface and possibly introduce an inheritance
Jar is currently a monolithic object that's hard to change and even allows access to internal data-structures indirectly. It has multiple constructors with varying arguments and one can easily get things wrong.
Also there is no way to pass a jar to a function in a "read only" mode everyone can always modify it everywhere.
Because of this it would be good if a Jar becomes an interface what would make it possible to use delegation models or supply alternative implementations, possibly also we should distinguish between a Jar and a ModifiableJar. This then could maybe even handle cases that currently use [PseudoJar}(https://github.com/bndtools/bnd/blob/master/bndtools.utils/src/org/bndtools/utils/jar/PseudoJar.java)
Miscellaneous
- BndMavenPlugin: Do no longer consider distribution management repos by default (https://github.com/bndtools/bnd/pull/6946)
- Remove experimental OpenAI stuff: Since so many AI coding Agents exists now, I don't think anybody will continue maintaining the one in bndtools. See package
org.bndtools.refactor.ai - Make
-reproducible: trueand-noextraheaders: truethe default, because reproducible builds are a good thing - remove Java 8 compatibility of biz.aQute.bnd.annotation (only in case https://github.com/bndtools/bnd/pull/7033 gets merged)
- JTwig is unmaintained but used in /biz.aQute.bnd.reporter https://github.com/jtwig/jtwig