SPI shouldn't expose impl types
Description
relates to
required for
Activity

Yoann Rodière April 25, 2018 at 8:05 AM
Resolved as part of the Search 6 proof of concept groundwork.
We also set up tooling to prevent this from happening again in the future ()

Gunnar Morling April 25, 2017 at 8:43 PM
You can also use the jQAssistant set-up we're having in HV to detect these inconsistencies: http://in.relation.to/2017/01/31/preventing-leaky-apis-with-jqassistant/.

Yoann Rodière April 25, 2017 at 2:57 PM
Note that build logs seem to actually highlight those problems:
Noticed while working on

Hardy Ferentschik September 6, 2013 at 9:57 AM
> Is AbstractDocumentBuilder actually an SPI type, i.e. are we expecting others to extend it and build their own document builder types
Not in my world, but might know more
> Regarding the getter, if it is not intended to be used by integrators, who is the intended user then? Maybe it just could be removed? Or if required internally, moved to an internally-used extension of AbstractDocumentBuilder?
It is for internal use.

Gunnar Morling September 5, 2013 at 7:40 AM
Is AbstractDocumentBuilder
actually an SPI type, i.e. are we expecting others to extend it and build their own document builder types (given all the types in *.spi it may be though that I'm having another definition of "SPI" in mind than the one used here)?
Regarding the getter, if it is not intended to be used by integrators, who is the intended user then? Maybe it just could be removed? Or if required internally, moved to an internally-used extension of AbstractDocumentBuilder
?
Should we ever want to OSGi-ify SEARCH (or restrict the public packages of the JBoss module) such leakage of non-exported types via public signatures would cause some trouble.
Details
Details
Assignee

Reporter

o.h.s.e.spi.AbstractDocumentBuilder
exposesTypeMetadata
which resides in theimpl
package:I think
TypeMetadata
et al. should be moved to*.spi
as well.