Remove Xalan?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Remove Xalan?

Carlo de Wolf
We are keeping a (old) fork around for Xalan. Now and then the question
pops whether we can backport more from upstream. Rather I want to rid of
it at all as I don't want to maintain forks of third party projects and
I don't see Xalan releasing soon with anything we would upstream.

Can we remove Xalan? (Maybe we have some weird dependency on specifics.)
What should be its replacement?

Filed https://issues.jboss.org/browse/WFLY-4704 to note any decisions.

Carlo
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Remove Xalan?

jtgreene
Administrator
The only reason we need Xalan is to provide a jaxp impl of transformer. Ideally we could just rely on the JDK, which uses a fork of xalan, but the translet code which is compiled by it is not compatible with modular classloading. So we just need that one patch. As of late the JDK fork is more current, so we could potentially switch to a fork of it instead. Since Java 9 is moving to modularity, I imagine they would fix the same issue, we could also send them a patch.

> On May 29, 2015, at 8:21 AM, Carlo de Wolf <[hidden email]> wrote:
>
> We are keeping a (old) fork around for Xalan. Now and then the question
> pops whether we can backport more from upstream. Rather I want to rid of
> it at all as I don't want to maintain forks of third party projects and
> I don't see Xalan releasing soon with anything we would upstream.
>
> Can we remove Xalan? (Maybe we have some weird dependency on specifics.)
> What should be its replacement?
>
> Filed https://issues.jboss.org/browse/WFLY-4704 to note any decisions.
>
> Carlo
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Remove Xalan?

David Lloyd-2
It was proposed to consider switching to Saxon, since Xalan has
basically been dead since 2007.  Saxon apears to include a
TransformerFactoryImpl (though I don't have any idea as to completeness
of compatibility).

On 05/29/2015 08:30 AM, Jason T. Greene wrote:

> The only reason we need Xalan is to provide a jaxp impl of transformer. Ideally we could just rely on the JDK, which uses a fork of xalan, but the translet code which is compiled by it is not compatible with modular classloading. So we just need that one patch. As of late the JDK fork is more current, so we could potentially switch to a fork of it instead. Since Java 9 is moving to modularity, I imagine they would fix the same issue, we could also send them a patch.
>
>> On May 29, 2015, at 8:21 AM, Carlo de Wolf <[hidden email]> wrote:
>>
>> We are keeping a (old) fork around for Xalan. Now and then the question
>> pops whether we can backport more from upstream. Rather I want to rid of
>> it at all as I don't want to maintain forks of third party projects and
>> I don't see Xalan releasing soon with anything we would upstream.
>>
>> Can we remove Xalan? (Maybe we have some weird dependency on specifics.)
>> What should be its replacement?
>>
>> Filed https://issues.jboss.org/browse/WFLY-4704 to note any decisions.
>>
>> Carlo
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Remove Xalan?

Tomaž Cerar-2
from their website

Saxon-HE 9.6

"The open-source implementation of XSLT 2.0, and XPath 2.0 and 3.0, and XQuery 1.0 and 3.0. This provides the "basic" conformance level of these languages; it also supports some optional features of the specifications such as serialization and support for XQuery modules.

Not included in the Home Edition are: schema processing and schema aware XSLT and XQuery; support for higher-order functions; numerous Saxon extensions; calling out to Java methods; XQuery Update support; various optimizations including join optimization; streamed processing; and byte code generation."



On Fri, May 29, 2015 at 3:46 PM, David M. Lloyd <[hidden email]> wrote:
It was proposed to consider switching to Saxon, since Xalan has
basically been dead since 2007.  Saxon apears to include a
TransformerFactoryImpl (though I don't have any idea as to completeness
of compatibility).

On 05/29/2015 08:30 AM, Jason T. Greene wrote:
> The only reason we need Xalan is to provide a jaxp impl of transformer. Ideally we could just rely on the JDK, which uses a fork of xalan, but the translet code which is compiled by it is not compatible with modular classloading. So we just need that one patch. As of late the JDK fork is more current, so we could potentially switch to a fork of it instead. Since Java 9 is moving to modularity, I imagine they would fix the same issue, we could also send them a patch.
>
>> On May 29, 2015, at 8:21 AM, Carlo de Wolf <[hidden email]> wrote:
>>
>> We are keeping a (old) fork around for Xalan. Now and then the question
>> pops whether we can backport more from upstream. Rather I want to rid of
>> it at all as I don't want to maintain forks of third party projects and
>> I don't see Xalan releasing soon with anything we would upstream.
>>
>> Can we remove Xalan? (Maybe we have some weird dependency on specifics.)
>> What should be its replacement?
>>
>> Filed https://issues.jboss.org/browse/WFLY-4704 to note any decisions.
>>
>> Carlo
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev