You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.fr> on 2013/02/24 17:53:00 UTC
Blocking issue on XML prefix mapping
Hello all
I'm back on work more immediately related to ISO 19115 and I'm still
facing a blocking issue. A solution exists, but is not very satisfying.
The ISO/OGC standards are huge, and use a large amount of different XML
schemas with different prefixes. The new revision of ISO 10115 (to be
published this year) adds yet more prefixes in the mix. Some of those
prefixes are hard-coded in Apache SIS [1], but this list is still
incomplete.
XML uses prefixes in order to differentiate tags of different schemas, a
little bit like Java uses package names to differentiate classes of
different libraries. Problem is: those prefixes are auto-generated by
JAXB at marshalling time, and those auto-generated names are not very
informative ("ns1", "ns2", "ns3", etc.). JAXB provides a @XmlSchema
annotation allowing us to specify explicitly the prefixes, but it
doesn't seem to work well with JAXB 2.1.
With JAXB 2.1, there is apparently no other way to control the prefixes
than subclassing com.sun.xml.internal.bind.NamespacePrefixMapper.
Problem is: this class is obviously internal, so we are not supposed to
use it. However in this particular case, Sun/Oracle seems to have made
an exception to their own rules since NamespacePrefixMapper is publicly
advised as the way to control prefixes ([2], [3]).
I have read reports on internet saying that the @XmlSchema annotation
has been fixed in JAXB 2.2.4. However while JDK 1.7.0_15 is bundled with
JAXB 2.2.4-2 (so it would theoretically work), JDK 1.6.0_37 is still
bundled with JAXB 2.1.10 so @XmlSchema would not work on that platform.
Furthermore I have not yet verified if @XmlSchema on JDK7 really works
for us, and even the JAXB 2.2.6 documentation still advise
NamespacePrefixMapper as the way to control prefix names [3].
So I'm tempted to continue to use NamespacePrefixMapper for now (this is
what was done on Geotk), until we verified that the standard annotations
work. We may have to commit the NamespacePrefixMapper hack anyway since
(in my understanding) @XmlSchema will never work on Oracle JDK6. At some
later time, we could remove the hack on the JDK7 branch while keeping it
on the JDK6 branch.
However while com.sun.xml.internal.bind.NamespacePrefixMapper exists in
every Oracle JDK6/7 distributions, it is not accessible by the javac
compiler. Some possible workaround are:
* Use the non-standard -XDignore.symbol.file javac option, which will
disable the exclusion of "com.sun" packages. However this is an
Oracle-specific option.
* Explicitly put rt.jar on the classpath as a Maven dependency using
<scope>system</scope>. But this is again Oracle-specific, and is ugly.
* Provide a skeleton of
com.sun.xml.internal.bind.NamespacePrefixMapper in the sis-utility
module with only the signature of the methods that we need to
override (hopefully it would not be a licensing violation if we do
not provide any code), and exclude that class file from the JAR file.
The last workaround seems the only JDK-independent solution to me.
However if we choose this approach, we still have to find how to exclude
the com/** classes from the JAR file. The maven-jar-plugin has an
<exclude> configuration option for that [4], but despite all my attempts
I have been unable to make it work - I tried in the root pom.xml, in the
module pom.xml, inside and outside <execution> block, with different
goals, with different paths (relative, absolute), Maven seems to just
ignores any configuration and unconditionally include the com.sun files.
Surely I'm doing something wrong, but I didn't found what. I also tried
the maven-clean-plugin execution under the "process-classes" phase,
without more luck (plugin is executed, but my include/exclude
configuration is ignored). This leave us with one more goal we could
define in our custom sis-build-helper plugin...
So in summary, one way to go forward would be:
* Use NamespacePrefixMapper despite being in a package that we are not
supposed to use.
* Commit a skeleton of NamespacePrefixMapper in sis-utility module, so
we can compile.
* Add a goal in sis-build-helper for deleting the above class before
building the JAR file.
* After we verified that the tests pass, try to replace
NamespacePrefixMapper by the standard @XmlSchema annotation on the
JDK7 branch (but we would probably have to keep
NamespacePrefixMapper on the JDK6 branch). It is possible that
@XmlSchema still doesn't work well enough on JDK7 and that we have
to wait for JDK8 before removing NamespacePrefixMapper.
Is there any comment, or an other approach that we could try? For the
record, JIRA task is at [5].
Martin
[1]
https://svn.apache.org/repos/asf/sis/trunk/sis-utility/src/main/java/org/apache/sis/xml/Namespaces.java
[2] http://java.sun.com/webservices/docs/1.5/jaxb/vendorProperties.html
[3]
http://jaxb.java.net/nonav/2.2.6/docs/ch03.html#marshalling-changing-prefixes
[4] http://maven.apache.org/plugins/maven-jar-plugin/usage.html
[5] https://issues.apache.org/jira/browse/SIS-74
RE: Blocking issue on XML prefix mapping
Posted by Adam Estrada <es...@gmail.com>.
Hey Martin,
"less bad" sounds good to me as long as it can be coerced in to a proper
implementation in the future or once the Java community can get all their
ducks in a row.
Adam
-----Original Message-----
From: Martin Desruisseaux [mailto:martin.desruisseaux@geomatys.fr]
Sent: Sunday, February 24, 2013 12:19 PM
To: dev@sis.apache.org
Subject: Re: Blocking issue on XML prefix mapping
Hello Adam
Le 24/02/13 18:09, Adam Estrada a écrit :
> Wow...There definitely seems to be a lot of (continuing) problems
> between Java version.
Yes... In this case, part of the complication come from the fact that JAXB
has a kind of special status in the JDK. It is not a "core" part of the JDK,
but rather an external library developed as part of another project (namely
Glassfish), then bundled in the JDK. Furthermore, users can override the
JAXB bundled in the JDK by an other JAXB version put in the "endorsed"
directory. So we have to think about JDK versions and JAXB versions as two
almost independent things...
> However, I do like the approach you took with making use of
> NamespacePrefixMapper in GeoTK as it would appear to cover all the
> bases for now (meaning different Java versions).
Well... this is the "less bad" approach I have found so far, in the hope
that the hack could be removed in the future.
> Does anyone know when Java 8 is supposed to be released?
According some emails I have seen on the JDK8 mailing list, the first
developer previews would be soon. But I guess that the final release would
be in a year or so.
Martin
Re: Blocking issue on XML prefix mapping
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Le 24/02/13 23:42, Adam Estrada a écrit :
> Excellent! Thanks a lot Martin...
My pleasure :-)
Martin
RE: Blocking issue on XML prefix mapping
Posted by Adam Estrada <es...@gmail.com>.
Excellent! Thanks a lot Martin...
Adam
-----Original Message-----
From: Martin Desruisseaux [mailto:martin.desruisseaux@geomatys.fr]
Sent: Sunday, February 24, 2013 5:04 PM
To: dev@sis.apache.org
Subject: Re: Blocking issue on XML prefix mapping
Hello all
So there is the proposal. The skeleton NamespacePrefixMapper class is below.
To be legally as safe as possible, the class is totally empty. It does not
even have any method signature, since we actually don't need them for method
overriding to work at the binary level (because of Java "late binding"
behaviour).
https://svn.apache.org/repos/asf/sis/branches/JDK7/sis-utility/src/main/java
/com/sun/xml/internal/bind/marshaller/NamespacePrefixMapper.java
The Apache SIS implementation of that class is
org.apache.sis.xml.OGCNamespacePrefixMapper (a package-private class).
Since we don't know at compile time if we are properly overriding the
methods from the base class, this is verified in the JUnit test using Java
reflection.
The compilation result of the above com.sun class is deleted by a
maven-antrun-plugin task after the tests have been compiled and before the
tests are run. This should guarantee us that the NamespacePrefixMapper class
used by the tests is the JDK one.
Martin
Re: Blocking issue on XML prefix mapping
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
+1 looking good, Martin.
Cheers,
Chris
On 2/24/13 2:04 PM, "Martin Desruisseaux"
<ma...@geomatys.fr> wrote:
>Hello all
>
>So there is the proposal. The skeleton NamespacePrefixMapper class is
>below. To be legally as safe as possible, the class is totally empty. It
>does not even have any method signature, since we actually don't need
>them for method overriding to work at the binary level (because of Java
>"late binding" behaviour).
>
>https://svn.apache.org/repos/asf/sis/branches/JDK7/sis-utility/src/main/ja
>va/com/sun/xml/internal/bind/marshaller/NamespacePrefixMapper.java
>
>The Apache SIS implementation of that class is
>org.apache.sis.xml.OGCNamespacePrefixMapper (a package-private class).
>Since we don't know at compile time if we are properly overriding the
>methods from the base class, this is verified in the JUnit test using
>Java reflection.
>
>The compilation result of the above com.sun class is deleted by a
>maven-antrun-plugin task after the tests have been compiled and before
>the tests are run. This should guarantee us that the
>NamespacePrefixMapper class used by the tests is the JDK one.
>
> Martin
>
Re: Blocking issue on XML prefix mapping
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello all
So there is the proposal. The skeleton NamespacePrefixMapper class is
below. To be legally as safe as possible, the class is totally empty. It
does not even have any method signature, since we actually don't need
them for method overriding to work at the binary level (because of Java
"late binding" behaviour).
https://svn.apache.org/repos/asf/sis/branches/JDK7/sis-utility/src/main/java/com/sun/xml/internal/bind/marshaller/NamespacePrefixMapper.java
The Apache SIS implementation of that class is
org.apache.sis.xml.OGCNamespacePrefixMapper (a package-private class).
Since we don't know at compile time if we are properly overriding the
methods from the base class, this is verified in the JUnit test using
Java reflection.
The compilation result of the above com.sun class is deleted by a
maven-antrun-plugin task after the tests have been compiled and before
the tests are run. This should guarantee us that the
NamespacePrefixMapper class used by the tests is the JDK one.
Martin
Re: Blocking issue on XML prefix mapping
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Paul
Le 24/02/13 18:28, Ramirez, Paul M (388J) a écrit :
> So if we package in the latest JAXB it would not override the one bundled
> with the JDK? Either way I agree with the NamespacePrefixMapper as I've
> pulled that one before too.
The users could chose the latest JAXB, in which case it would (in my
understanding) override the one bundle with the JDK. But I would like to
have SIS to work "out of the box" with as few dependencies as possible
(especially large dependencies), and let users choose if he want to
override the bundled JAXB by another one.
Thanks Adam and Paul for your feedback. I will commit a proposal on the
JDK7 branch and send the link in this thread, so peoples can share their
though if they wish.
Martin
Re: Blocking issue on XML prefix mapping
Posted by "Ramirez, Paul M (388J)" <pa...@jpl.nasa.gov>.
Hi Martin,
So if we package in the latest JAXB it would not override the one bundled
with the JDK? Either way I agree with the NamespacePrefixMapper as I've
pulled that one before too.
--Paul Ramirez
On 2/24/13 9:19 AM, "Martin Desruisseaux"
<ma...@geomatys.fr> wrote:
>Hello Adam
>
>Le 24/02/13 18:09, Adam Estrada a écrit :
>> Wow...There definitely seems to be a lot of (continuing) problems
>>between
>> Java version.
>Yes... In this case, part of the complication come from the fact that
>JAXB has a kind of special status in the JDK. It is not a "core" part of
>the JDK, but rather an external library developed as part of another
>project (namely Glassfish), then bundled in the JDK. Furthermore, users
>can override the JAXB bundled in the JDK by an other JAXB version put in
>the "endorsed" directory. So we have to think about JDK versions and
>JAXB versions as two almost independent things...
>
>> However, I do like the approach you took with making use of
>> NamespacePrefixMapper in GeoTK as it would appear to cover all the
>>bases for
>> now (meaning different Java versions).
>Well... this is the "less bad" approach I have found so far, in the hope
>that the hack could be removed in the future.
>
>> Does anyone know when Java 8 is supposed to be released?
>According some emails I have seen on the JDK8 mailing list, the first
>developer previews would be soon. But I guess that the final release
>would be in a year or so.
>
> Martin
>
Re: Blocking issue on XML prefix mapping
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Adam
Le 24/02/13 18:09, Adam Estrada a écrit :
> Wow...There definitely seems to be a lot of (continuing) problems between
> Java version.
Yes... In this case, part of the complication come from the fact that
JAXB has a kind of special status in the JDK. It is not a "core" part of
the JDK, but rather an external library developed as part of another
project (namely Glassfish), then bundled in the JDK. Furthermore, users
can override the JAXB bundled in the JDK by an other JAXB version put in
the "endorsed" directory. So we have to think about JDK versions and
JAXB versions as two almost independent things...
> However, I do like the approach you took with making use of
> NamespacePrefixMapper in GeoTK as it would appear to cover all the bases for
> now (meaning different Java versions).
Well... this is the "less bad" approach I have found so far, in the hope
that the hack could be removed in the future.
> Does anyone know when Java 8 is supposed to be released?
According some emails I have seen on the JDK8 mailing list, the first
developer previews would be soon. But I guess that the final release
would be in a year or so.
Martin
RE: Blocking issue on XML prefix mapping
Posted by Adam Estrada <es...@gmail.com>.
Wow...There definitely seems to be a lot of (continuing) problems between
Java version. I am not an expert when it comes to how the guts of the Java
ecosystem are put together so I can't comment on exactly what the best path
forward is. However, I do like the approach you took with making use of
NamespacePrefixMapper in GeoTK as it would appear to cover all the bases for
now (meaning different Java versions). I also like the skeleton
implementation idea but I don't can't comment on whether or not it would
violate any license agreements from Sun/Oracle. Seems like you have a way
ahead with that though.
So, +1 from me on your approach to adding the skeleton class in sis-utility
and modifying the maven build accordingly. Does anyone know when Java 8 is
supposed to be released?
Adam
-----Original Message-----
From: Martin Desruisseaux [mailto:martin.desruisseaux@geomatys.fr]
Sent: Sunday, February 24, 2013 11:53 AM
To: Apache SIS
Subject: Blocking issue on XML prefix mapping
Hello all
I'm back on work more immediately related to ISO 19115 and I'm still facing
a blocking issue. A solution exists, but is not very satisfying.
The ISO/OGC standards are huge, and use a large amount of different XML
schemas with different prefixes. The new revision of ISO 10115 (to be
published this year) adds yet more prefixes in the mix. Some of those
prefixes are hard-coded in Apache SIS [1], but this list is still
incomplete.
XML uses prefixes in order to differentiate tags of different schemas, a
little bit like Java uses package names to differentiate classes of
different libraries. Problem is: those prefixes are auto-generated by JAXB
at marshalling time, and those auto-generated names are not very informative
("ns1", "ns2", "ns3", etc.). JAXB provides a @XmlSchema annotation allowing
us to specify explicitly the prefixes, but it doesn't seem to work well with
JAXB 2.1.
With JAXB 2.1, there is apparently no other way to control the prefixes than
subclassing com.sun.xml.internal.bind.NamespacePrefixMapper.
Problem is: this class is obviously internal, so we are not supposed to use
it. However in this particular case, Sun/Oracle seems to have made an
exception to their own rules since NamespacePrefixMapper is publicly advised
as the way to control prefixes ([2], [3]).
I have read reports on internet saying that the @XmlSchema annotation has
been fixed in JAXB 2.2.4. However while JDK 1.7.0_15 is bundled with JAXB
2.2.4-2 (so it would theoretically work), JDK 1.6.0_37 is still bundled with
JAXB 2.1.10 so @XmlSchema would not work on that platform.
Furthermore I have not yet verified if @XmlSchema on JDK7 really works for
us, and even the JAXB 2.2.6 documentation still advise NamespacePrefixMapper
as the way to control prefix names [3].
So I'm tempted to continue to use NamespacePrefixMapper for now (this is
what was done on Geotk), until we verified that the standard annotations
work. We may have to commit the NamespacePrefixMapper hack anyway since (in
my understanding) @XmlSchema will never work on Oracle JDK6. At some later
time, we could remove the hack on the JDK7 branch while keeping it on the
JDK6 branch.
However while com.sun.xml.internal.bind.NamespacePrefixMapper exists in
every Oracle JDK6/7 distributions, it is not accessible by the javac
compiler. Some possible workaround are:
* Use the non-standard -XDignore.symbol.file javac option, which will
disable the exclusion of "com.sun" packages. However this is an
Oracle-specific option.
* Explicitly put rt.jar on the classpath as a Maven dependency using
<scope>system</scope>. But this is again Oracle-specific, and is ugly.
* Provide a skeleton of
com.sun.xml.internal.bind.NamespacePrefixMapper in the sis-utility
module with only the signature of the methods that we need to
override (hopefully it would not be a licensing violation if we do
not provide any code), and exclude that class file from the JAR file.
The last workaround seems the only JDK-independent solution to me.
However if we choose this approach, we still have to find how to exclude the
com/** classes from the JAR file. The maven-jar-plugin has an <exclude>
configuration option for that [4], but despite all my attempts I have been
unable to make it work - I tried in the root pom.xml, in the module pom.xml,
inside and outside <execution> block, with different goals, with different
paths (relative, absolute), Maven seems to just ignores any configuration
and unconditionally include the com.sun files.
Surely I'm doing something wrong, but I didn't found what. I also tried the
maven-clean-plugin execution under the "process-classes" phase, without more
luck (plugin is executed, but my include/exclude configuration is ignored).
This leave us with one more goal we could define in our custom
sis-build-helper plugin...
So in summary, one way to go forward would be:
* Use NamespacePrefixMapper despite being in a package that we are not
supposed to use.
* Commit a skeleton of NamespacePrefixMapper in sis-utility module, so
we can compile.
* Add a goal in sis-build-helper for deleting the above class before
building the JAR file.
* After we verified that the tests pass, try to replace
NamespacePrefixMapper by the standard @XmlSchema annotation on the
JDK7 branch (but we would probably have to keep
NamespacePrefixMapper on the JDK6 branch). It is possible that
@XmlSchema still doesn't work well enough on JDK7 and that we have
to wait for JDK8 before removing NamespacePrefixMapper.
Is there any comment, or an other approach that we could try? For the
record, JIRA task is at [5].
Martin
[1]
https://svn.apache.org/repos/asf/sis/trunk/sis-utility/src/main/java/org/apa
che/sis/xml/Namespaces.java
[2] http://java.sun.com/webservices/docs/1.5/jaxb/vendorProperties.html
[3]
http://jaxb.java.net/nonav/2.2.6/docs/ch03.html#marshalling-changing-prefixe
s
[4] http://maven.apache.org/plugins/maven-jar-plugin/usage.html
[5] https://issues.apache.org/jira/browse/SIS-74
Re: Blocking issue on XML prefix mapping
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Chris
Le 24/02/13 20:56, Mattmann, Chris A (388J) a écrit :
> And fixing the Maven exclude issue that you're seeing. Paul Ramirez is a
> Maven guru and I'm pretty good at it too and can probably help.
Actually I realized after I wrote the email that a very simple
maven-antrun-plugin task does the job very well, so there is no need to
hack sis-build-helper more.
Of course, understanding what I missed with the <exclude> issue would be
good. But even if <exclude> worked, I think now that the Ant task is
preferable because it removes the com.sun.xml files from the
target/classes directory instead than only from the JAR file. I think
that this is preferable for running tests, since (in my understanding)
surefire uses the content of target/classes rather than the JAR file.
Thanks for the proposal
Martin
Re: Blocking issue on XML prefix mapping
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Martin,
Sorry about all this mess. I would favor:
* Provide a skeleton of
com.sun.xml.internal.bind.NamespacePrefixMapper in the sis-utility
module with only the signature of the methods that we need to
override (hopefully it would not be a licensing violation if we do
not provide any code), and exclude that class file from the JAR file.
And fixing the Maven exclude issue that you're seeing. Paul Ramirez is a
Maven guru and I'm pretty good at it too and can probably help.
Cheers,
Chris
On 2/24/13 8:53 AM, "Martin Desruisseaux"
<ma...@geomatys.fr> wrote:
>Hello all
>
>I'm back on work more immediately related to ISO 19115 and I'm still
>facing a blocking issue. A solution exists, but is not very satisfying.
>
>The ISO/OGC standards are huge, and use a large amount of different XML
>schemas with different prefixes. The new revision of ISO 10115 (to be
>published this year) adds yet more prefixes in the mix. Some of those
>prefixes are hard-coded in Apache SIS [1], but this list is still
>incomplete.
>
>XML uses prefixes in order to differentiate tags of different schemas, a
>little bit like Java uses package names to differentiate classes of
>different libraries. Problem is: those prefixes are auto-generated by
>JAXB at marshalling time, and those auto-generated names are not very
>informative ("ns1", "ns2", "ns3", etc.). JAXB provides a @XmlSchema
>annotation allowing us to specify explicitly the prefixes, but it
>doesn't seem to work well with JAXB 2.1.
>
>With JAXB 2.1, there is apparently no other way to control the prefixes
>than subclassing com.sun.xml.internal.bind.NamespacePrefixMapper.
>Problem is: this class is obviously internal, so we are not supposed to
>use it. However in this particular case, Sun/Oracle seems to have made
>an exception to their own rules since NamespacePrefixMapper is publicly
>advised as the way to control prefixes ([2], [3]).
>
>I have read reports on internet saying that the @XmlSchema annotation
>has been fixed in JAXB 2.2.4. However while JDK 1.7.0_15 is bundled with
>JAXB 2.2.4-2 (so it would theoretically work), JDK 1.6.0_37 is still
>bundled with JAXB 2.1.10 so @XmlSchema would not work on that platform.
>Furthermore I have not yet verified if @XmlSchema on JDK7 really works
>for us, and even the JAXB 2.2.6 documentation still advise
>NamespacePrefixMapper as the way to control prefix names [3].
>
>So I'm tempted to continue to use NamespacePrefixMapper for now (this is
>what was done on Geotk), until we verified that the standard annotations
>work. We may have to commit the NamespacePrefixMapper hack anyway since
>(in my understanding) @XmlSchema will never work on Oracle JDK6. At some
>later time, we could remove the hack on the JDK7 branch while keeping it
>on the JDK6 branch.
>
>However while com.sun.xml.internal.bind.NamespacePrefixMapper exists in
>every Oracle JDK6/7 distributions, it is not accessible by the javac
>compiler. Some possible workaround are:
>
> * Use the non-standard -XDignore.symbol.file javac option, which will
> disable the exclusion of "com.sun" packages. However this is an
> Oracle-specific option.
> * Explicitly put rt.jar on the classpath as a Maven dependency using
> <scope>system</scope>. But this is again Oracle-specific, and is ugly.
> * Provide a skeleton of
> com.sun.xml.internal.bind.NamespacePrefixMapper in the sis-utility
> module with only the signature of the methods that we need to
> override (hopefully it would not be a licensing violation if we do
> not provide any code), and exclude that class file from the JAR file.
>
>
>The last workaround seems the only JDK-independent solution to me.
>However if we choose this approach, we still have to find how to exclude
>the com/** classes from the JAR file. The maven-jar-plugin has an
><exclude> configuration option for that [4], but despite all my attempts
>I have been unable to make it work - I tried in the root pom.xml, in the
>module pom.xml, inside and outside <execution> block, with different
>goals, with different paths (relative, absolute), Maven seems to just
>ignores any configuration and unconditionally include the com.sun files.
>Surely I'm doing something wrong, but I didn't found what. I also tried
>the maven-clean-plugin execution under the "process-classes" phase,
>without more luck (plugin is executed, but my include/exclude
>configuration is ignored). This leave us with one more goal we could
>define in our custom sis-build-helper plugin...
>
>So in summary, one way to go forward would be:
>
> * Use NamespacePrefixMapper despite being in a package that we are not
> supposed to use.
> * Commit a skeleton of NamespacePrefixMapper in sis-utility module, so
> we can compile.
> * Add a goal in sis-build-helper for deleting the above class before
> building the JAR file.
> * After we verified that the tests pass, try to replace
> NamespacePrefixMapper by the standard @XmlSchema annotation on the
> JDK7 branch (but we would probably have to keep
> NamespacePrefixMapper on the JDK6 branch). It is possible that
> @XmlSchema still doesn't work well enough on JDK7 and that we have
> to wait for JDK8 before removing NamespacePrefixMapper.
>
>
>Is there any comment, or an other approach that we could try? For the
>record, JIRA task is at [5].
>
> Martin
>
>
>[1]
>https://svn.apache.org/repos/asf/sis/trunk/sis-utility/src/main/java/org/a
>pache/sis/xml/Namespaces.java
>[2] http://java.sun.com/webservices/docs/1.5/jaxb/vendorProperties.html
>[3]
>http://jaxb.java.net/nonav/2.2.6/docs/ch03.html#marshalling-changing-prefi
>xes
>[4] http://maven.apache.org/plugins/maven-jar-plugin/usage.html
>[5] https://issues.apache.org/jira/browse/SIS-74
>