Le 24/06/2020 à 08:57, Francesco Chicchiriccò a écrit :
On 23/06/20 23:20, Cédric Damioli wrote:
<snip/>
Why not, but are we sure that we won't have regressions due to downgrade of
jakarta-regexp (the xalan bundled version is 1.2 AFAIU) ?
From a design POV, I find it quite strange to rely on an XSLT lib (ie Xalan)
to provide regexp processing.
Could it be better to remove org.apache.bcel and org.apache.regexp from the
xalan jar and keep the existing librairies ?
I suppose that was how it has been done previously for xalan-2.7.1
It seems you are quite right.
I took cocoon-2.1.12-deps.tar.gz from
http://cocoon.apache.org/mirror.html
then extracted
lib/endorsed/xalan-2.7.1.jar
and found that it is *not the same* you can download from Maven Central under
https://repo1.maven.org/maven2/xalan/xalan/2.7.1/xalan-2.7.1.jar
but that it matches the one you can download from
http://archive.apache.org/dist/xalan/xalan-j/binaries/xalan-j_2_7_1-bin-2jars.zip
because it does not contain any org.apache.bcel.* nor any org.apache.regexp.*
class.
So I went ahead and replaced the current
lib/endorsed/xalan-2.7.2.jar
in the source tree with the one contained in
http://archive.apache.org/dist/xalan/xalan-j/binaries/xalan-j_2_7_2-bin-2jars.zip
and all went out smoothly.
Problem solved :-)
Regards.
It can't be that easy :)
The xalan-2.7.2 you just uploaded does not contains xsltc, whereas the previous
xalan-2.7.1 did contain it.
And the xsltc.jar comes bundled with cled and regexp.
But you're completely right, it seems we did not have an official xalan jar.
My suggestion, to preserve legacy behaviour, is to remove
org.apache.(bcel|regexp).* from the full xalan jar.
What do you think ?
Well, in this era of reproducible builds, taking another project's dist
artifact, mangle it and include it our own sources looks a bit... weird.
At least, the current file comes actually unchanged from Xalan's release
artifact.
I totally agree. But the Cocoon 2.1.x build system was made in a
pre-(ivy|maven) era and I think we don't want to take the time to
re-engineer it.
Maybe we could do as you suggest - e.g. restore the previous xalan-2.7.2.jar
and strip out the indicated classes - but also renaming it somehow, e.g.
xalan-2.7.2-cocoon-2.1.13.jar and adding some explanation in lib/jars.xml about
how we obtained this JAR from official Xalan's JAR.
Does it sound reasonable?
+1 with your proposal
Regards,
Cédric
