> > > The thing is that now you cannot remove Batik (easily). It has > > > become part of the NetBeans platform and shall be supported (until > > > EOL). OracleLabs has already changed the build of IGV to rely on > > > platform's provided Batik libraries. > > > > So, it looks like it is API as opposed to an implementation detail of > > the SVG icon support. Which in hindsight is possibly a shame? > > > > I wonder if there's a different approach / deprecation strategy we > > can take to third-party library integration than our own modules in > > terms of support though? Something .external / third-party UC like > > for platform consumers? > > Batik is a module and we version on the module level. I don't see a > problem to remove Batik at some point in time. Again I refer to the > JDK: While it was not nice when JAXB and JAXWS were removed from the > JDK, it is trivial to readd them by shipping the libraries yourself. > > We did it already and will so again: JNA changed API in the lifetime of > NetBeans and thus a new major version was created, effectively dropping > org.netbeans.libs.jna/1 and introducing org.netbeans.libs.jna/2. And I > see the next breakage on the horizon.
Re-exporting 3rd party API is always associated with problems. If it changes incompatibly, then there isn't much one can do about it. Either stay on old version or transitively declare own library (e.g. NetBeans Platform) incompatible with previous version. Referring to JDK policies is interesting, but their approach to modularity is (politely said) naive. NetBeans always aimed higher and I always wanted us to do better. Btw. Chapter 19 of my Practical API Design book - End of Life Policies - describes where my expectations are. In case of Batik, there may be someone creating a plugin for NetBeans 12.0 that depends on it. It is (shall be) in our interest to make sure that such plugin continues to work "eternally". We don't have that many plugins to throw them away with every new IDE version. Once/if we decide to remove Batik, then the correct EOL procedure would be: - stop using it internally - deprecate the module - keep it around unused for few releases - either stop here or - move the module to AU, so when a plugin that depends on Batik is installed, all dependencies can be satisfied by downloading Troublesome, I agree. However it has been our decision to include Batik in the NetBeans Platform and we shall pay the price. Not the people who build modules/plugins/applications on top of NetBeans Platform. This is certainly different than the "JAXB approach", but I am convinced it is the fair one with respect to people who invest their time to use/extend NetBeans. -jt --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
