[
https://issues.apache.org/jira/browse/JENA-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14319265#comment-14319265
]
Stian Soiland-Reyes edited comment on JENA-878 at 2/13/15 12:31 AM:
--------------------------------------------------------------------
I was going to say +0 to close this as I didn't imagine it would be a big
problem, but I think we would be playing dirty tricks in the OSGi world..
For jena-osgi it should not be a proper problem unless we switched to a bundle
version of Xerces and that didn't expose *.impl (as is the custom).
The question is what happens to users of jena-osgi. We bundle in xerces.jar -
but do we leak it out? As long as we keep it internal then we can use impls as
much as we like.
It turns out we DO leak these impl.dv classes out through our signatures (which
I think is the reason for the bundle plugin's warnings) - which is a bigger
OSGi problem as it means jena-osgi will need to also export
org.apache.xerces.impl.dv - which could in theory conflict with other bundles.
In other words, a second "jena" implemented the same way would not be
compatible with jena-osgi.
>From com.hp.hpl.jena.datatypes.xsd.XSDDatatype, we expose:
{code}
protected XSSimpleType typeDeclaration;
public XSDDatatype(XSSimpleType xstype, String namespace) {
public Object convertValidatedDataValue(ValidatedInfo validatedInfo) throws
DatatypeFormatException {
{code}
I don't see a real need for any of those three to be publically exposed, as
it's all semi-internal stuff (but spread over a few sub-packages). So changing
access to package or private here (with whatever workarounds are needed) should
in theory close the warnings and the need to export org.apache.xerces.impl.dv.
I'll try this out to see if the warning goes away.
was (Author: soilandreyes):
I was going to say +0 to close this as I didn't imagine it would be a big
problem, but I think we would be playing dirty tricks in the OSGi world..
For jena-osgi it should not be a proper problem unless we switched to a bundle
version of Xerces and that didn't expose *.impl (as is the custom).
The question is what happens to users of jena-osgi. We bundle in xerces.jar -
but do we leak it out? As long as we keep it internal then we can use impls as
much as we like.
It turns out we DO leak these impl.dv classes out through our signatures (which
I think is the reason for the bundle plugin's warnings) - which is a bigger
OSGi problem as it means jena-osgi will need to also export
org.apache.xerces.impl.dv - which could in theory conflict with other bundles.
In other words, a second "jena" implemented the same way would not be
compatible with jena-osgi.
>From com.hp.hpl.jena.datatypes.xsd.XSDDatatype, we expose:
protected XSSimpleType typeDeclaration;
public XSDDatatype(XSSimpleType xstype, String namespace) {
public Object convertValidatedDataValue(ValidatedInfo validatedInfo) throws
DatatypeFormatException {
I don't see a real need for any of those three to be publically exposed, as
it's all semi-internal stuff (but spread over a few sub-packages). So changing
access to package or private here (with whatever workarounds are needed) should
in theory close the warnings and the need to export org.apache.xerces.impl.dv.
I'll try this out to see if the warning goes away.
> Avoid dependencies on xerces.impl
> ---------------------------------
>
> Key: JENA-878
> URL: https://issues.apache.org/jira/browse/JENA-878
> Project: Apache Jena
> Issue Type: Task
> Components: Jena
> Affects Versions: Jena 2.13.0
> Reporter: Stian Soiland-Reyes
> Priority: Minor
>
> Building jena-osgi complains about xerces.impl dependencies:
> > [WARNING] Bundle org.apache.jena:jena-osgi:bundle:2.12.2-SNAPSHOT : Unused
> > Private-Package instructions, no such package(s) on the class path: [!*]
> > [WARNING] Bundle org.apache.jena:jena-osgi:bundle:2.12.2-SNAPSHOT : Export
> > com.hp.hpl.jena.datatypes.xsd, has 1, private references
> > [org.apache.xerces.impl.dv],
> {code}
> stain@biggie-utopic:~/src/jena/jena-core/src/main/java/com/hp/hpl/jena/datatypes$
> grep -r xerces.*impl .
> ./xsd/XSDDatatype.java:import org.apache.xerces.impl.dv.* ;
> ./xsd/XSDDatatype.java:import org.apache.xerces.impl.dv.util.Base64 ;
> ./xsd/XSDDatatype.java:import org.apache.xerces.impl.dv.util.HexBin ;
> ./xsd/XSDDatatype.java:import org.apache.xerces.impl.dv.xs.DecimalDV ;
> ./xsd/XSDDatatype.java:import org.apache.xerces.impl.dv.xs.XSSimpleTypeDecl ;
> ./xsd/XSDDatatype.java:import
> org.apache.xerces.impl.validation.ValidationState ;
> ./xsd/XSDhexBinary.java:import org.apache.xerces.impl.dv.util.HexBin ;
> ./xsd/XSDbase64Binary.java:import org.apache.xerces.impl.dv.util.Base64 ;
> ./xsd/impl/XSDGenericType.java:import org.apache.xerces.impl.dv.XSSimpleType;
> {code}
> It is not good style to depend on *.impl of a package - it is liable to fall
> over at some point. jena-osgi complains, but works in this particular case,
> because xercesImpl is shadowed in.
> Some/all of these (base64) are available through more official packages -
> org.apache.commons.codec.binary.Base64 comes to mind.
> https://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/binary/Base64.html
> https://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/binary/Hex.html
> So this task suggests to replace these dependencies with commons-codec
> versions. Remember to add commons-codec to jena-osgi as well!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
