| Message ID | 87y217gjfa.fsf@Ginko.local.i-did-not-set--mail-host-address--so-tickle-me |
|---|---|
| State | New |
| Headers | show |
| Series | [bug#32947] Add java-xalan. | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/comparison | success | View comparision |
| cbaines/git branch | success | View Git branch |
| cbaines/applying patch | fail | View Laminar job |
| cbaines/issue | success | View issue |
Frank Pursel schreef op vr 18-03-2022 om 19:16 [+0000]: > + (origin > + (method url-fetch) > + (uri (string-append "mirror://apache/xalan/xalan-j/source/xalan-j_" > + (string-replace-substring > + version "." "_") > + "-src.tar.gz")) > + (sha256 > + (base32 "166vg9i11qzi0vbv09abfb50q8caq8wr6zrwg0cwqws9k394l62w")) > + (modules '((guix build utils))) > + (snippet '(begin > + ;; Removing bundled jars > + (for-each > + (lambda (f) > + (delete-file f)) > + (find-files "." "\\.(jar|tar\\.gz)$")))))) Can be simplified to: (snippet '(for-each delete-file (delete-files "." "\\.(jar|tar\\.gz)$"))) Also, xalan-j_2_7_2/samples/AppletXMLtoHTML/rabbitwhorn.jpg is an (uncoloured) picture of a rabbit from Alice in Wonderland (not asl2.0). According to <https://commons.wikimedia.org/wiki/File:Alice_par_John_Tenniel_37.png>, the copyright has been expired. As such, perhaps the 'license' field needs to be changed to (license (list license:asl2.0 ; almost everything ;; samples/AppletXMLtoHTML/rabbitwhorn.jpg, according to ;; <https://commons.wikimedia.org/wiki/File:Alice_par_John_Tenniel_37.png> license:public-domain)) Aside from that, LGTM. I've been reading the source code, not seeing anything ‘suspicous’ (malware etc.) so far (I'm currently at xalan-j_2_7_2/src/org/apache/xalan/templates/FuncKey.java, 25%). Greetings, Maxime.
Very thorough! Apache is a bit sloppy, '(for-each delete-file (find-file...) is the minimalistic scheme we adore and I'll be happy to post a revised patch with all of that but I may wait until you've finished the source review because there is no telling what else has Apache has packed in there. Please let me know. Thanks, Frank On Fri, Mar 18, 2022 at 8:07 PM Maxime Devos <maximedevos@telenet.be> wrote: > Frank Pursel schreef op vr 18-03-2022 om 19:16 [+0000]: > > + (origin > > + (method url-fetch) > > + (uri (string-append > "mirror://apache/xalan/xalan-j/source/xalan-j_" > > + (string-replace-substring > > + version "." "_") > > + "-src.tar.gz")) > > + (sha256 > > + (base32 "166vg9i11qzi0vbv09abfb50q8caq8wr6zrwg0cwqws9k394l62w")) > > + (modules '((guix build utils))) > > + (snippet '(begin > > + ;; Removing bundled jars > > + (for-each > > + (lambda (f) > > + (delete-file f)) > > + (find-files "." "\\.(jar|tar\\.gz)$")))))) > > Can be simplified to: > > (snippet '(for-each delete-file (delete-files "." > "\\.(jar|tar\\.gz)$"))) > > Also, xalan-j_2_7_2/samples/AppletXMLtoHTML/rabbitwhorn.jpg is an > (uncoloured) > picture of a rabbit from Alice in Wonderland (not asl2.0). According to > <https://commons.wikimedia.org/wiki/File:Alice_par_John_Tenniel_37.png>, > the copyright has been expired. As such, perhaps the 'license' field > needs to be changed to > > (license (list license:asl2.0 ; almost everything > ;; samples/AppletXMLtoHTML/rabbitwhorn.jpg, according to > ;; < > https://commons.wikimedia.org/wiki/File:Alice_par_John_Tenniel_37.png> > license:public-domain)) > > Aside from that, LGTM. I've been reading the source code, not seeing > anything > ‘suspicous’ (malware etc.) so far (I'm currently at > xalan-j_2_7_2/src/org/apache/xalan/templates/FuncKey.java, 25%). > > Greetings, > Maxime. >
Maxime Devos schreef op vr 18-03-2022 om 21:07 [+0100]: > I've been reading the source code, not seeing anything > ‘suspicous’ (malware etc.) so far (I'm currently at > xalan-j_2_7_2/src/org/apache/xalan/templates/FuncKey.java, 25%). Now at src/org/apache/xalan/xsltc/compiler/IdKeyPattern.java, line 36%. I noticed some Java code does some classpath and class loader things, so I'm not sure that the java-xalan package will actually work. Greetings, Maxime.
Maxime Devos schreef op vr 18-03-2022 om 21:07 [+0100]: > I've been reading the source code, not seeing anything > ‘suspicous’ (malware etc.) so far (I'm currently at > xalan-j_2_7_2/src/org/apache/xalan/templates/FuncKey.java, 25%). Now I'm at 42% (src/org/apache/xalan/xsltc/compiler/XPathLexer.java). I've found two binaries (*): * src/org/apache/xalan/xsltc/compiler/XPathLexer.java * src/org/apache/xalan/xsltc/compiler/XPathParser.java They appear to be generated by a lexer and parser generator -- apparently it's named ‘java_cup’? Given that they are in the 'xsltc' part, which is currently unused in the java-xalan package IIUC, I believe it would be sufficient to just delete these two files. (*) Here I mean 'binaries'='generated, not source code' -- it's still .java and not .class. Greetings, Maxime.
On March 22, 2022 6:45:15 PM GMT+01:00, Maxime Devos <maximedevos@telenet.be> wrote: >Maxime Devos schreef op vr 18-03-2022 om 21:07 [+0100]: >> I've been reading the source code, not seeing anything >> ‘suspicous’ (malware etc.) so far (I'm currently at >> xalan-j_2_7_2/src/org/apache/xalan/templates/FuncKey.java, 25%). > >Now I'm at 42% (src/org/apache/xalan/xsltc/compiler/XPathLexer.java). >I've found two binaries (*): > > * src/org/apache/xalan/xsltc/compiler/XPathLexer.java > * src/org/apache/xalan/xsltc/compiler/XPathParser.java > >They appear to be generated by a lexer and parser generator -- >apparently it's named ‘java_cup’? Given that they are in the 'xsltc' >part, which is currently unused in the java-xalan package IIUC, I >believe it would be sufficient to just delete these two files. To add to your comment. I've encountered java_cup in tge past. It's not bootstrappable as far as I can see. It has a dependency on jflex and itself, and jflex requires itself and java_cup. I looked at the first commit of jflex, and it already depends on itself (but not cup). According to the devs, chey used a hand-written lexer that was too aweful to commit, and so we can't rebuild jflex. If someone is interested, they would have to write a lexer for an early version of jflex :) > >(*) Here I mean 'binaries'='generated, not source code' -- it's still >.java and not .class. > >Greetings, >Maxime.
Maxime Devos schreef op vr 18-03-2022 om 21:07 [+0100]: > (I'm currently at > xalan-j_2_7_2/src/org/apache/xalan/templates/FuncKey.java, 25%). I've continued reading and I'm now at xalan- j_2_7_2/src/org/apache/xalan/xsltc/dom/DocumentCache.java, 49%. I think I see a bug there, in getStatistics: out.print("<tr><td><a href=\""+_URIs[i]+"\">"+ "<font size=-1>"+_URIs[i]+"</font></a></td>"); what if the URI contains &, <, > or " characters? Looks like then the XML would be malformed. To be reported upstream ... (not a blocker, since xsltc is unused in the Guix package) Greetings, Maxime.
Maxime Devos schreef op wo 30-03-2022 om 19:43 [+0200]: > what if the URI contains &, <, > or " characters? Looks like then > the > XML would be malformed. To be reported upstream ... (not a blocker, > since xsltc is unused in the Guix package) Reported upstream at <https://issues.apache.org/jira/browse/XALANJ-2630>.
Thank you Maxime. On Wed, Mar 30, 2022 at 6:41 PM Maxime Devos <maximedevos@telenet.be> wrote: > Maxime Devos schreef op wo 30-03-2022 om 19:43 [+0200]: > > what if the URI contains &, <, > or " characters? Looks like then > > the > > XML would be malformed. To be reported upstream ... (not a blocker, > > since xsltc is unused in the Guix package) > > Reported upstream at > <https://issues.apache.org/jira/browse/XALANJ-2630>. >
Maxime Devos schreef op vr 18-03-2022 om 21:07 [+0100]: > (I'm currently at > xalan-j_2_7_2/src/org/apache/xalan/templates/FuncKey.java, 25%). Now at 57% (xalan- j_2_7_2/src/org/apache/xml/dtm/ref/DTMStringPool.java). No new ‘suspicious’ things found. Greetings, Maxime.
Maxime Devos schreef op vr 18-03-2022 om 21:07 [+0100]: > (I'm currently at > xalan-j_2_7_2/src/org/apache/xalan/templates/FuncKey.java, 25%). Now at 62% (src/org/apache/xml/serializer/ToTextSAXHandler.java). Greetings, Maxime.
Cool. On Tue, Apr 5, 2022, 09:12 Maxime Devos <maximedevos@telenet.be> wrote: > Maxime Devos schreef op vr 18-03-2022 om 21:07 [+0100]: > > (I'm currently at > > xalan-j_2_7_2/src/org/apache/xalan/templates/FuncKey.java, 25%). > > Now at 62% (src/org/apache/xml/serializer/ToTextSAXHandler.java). > > Greetings, > Maxime. >
Maxime Devos schreef op vr 18-03-2022 om 21:07 [+0100]: > (I'm currently at > xalan-j_2_7_2/src/org/apache/xalan/templates/FuncKey.java, 25%). I'm now at 68%, xalan-j_2_7_2/src/org/apache/xml/utils/IntStack.java. According to the header, it is asl2.0 licensed. But there's also a line * @since JDK1.0 which seems to imply that this file was based on some Java code of JDK1.0. TBI: is this the case, what is the license of JDK1.0, and does it appear to be followed or not? Greetings, Maxime.
Maxime, I looked at the org.apache.xml/uitls/IntStack.java file you pointed out. I think the header license certainly prevails here for several reasons. First it is subpackage of the org.apache tree for which the source license is clearly stated. Second, looking at the code (without being a java guru; the code is that simple) we can see that there is no dependency on any JDK. The statement '@since JDK1.0' appears to be true in the sense that any JDK can compile this since 1.0. We demonstrate that it builds with JDK8 whenever we run this package through guix build and so, I see no licensing concerns over the '@since JDK1.0' annotation. Regards, Frank
Frank Pursel schreef op ma 11-04-2022 om 16:36 [+0000]: > I looked at the org.apache.xml/uitls/IntStack.java file you pointed > out. I think the header license certainly prevails here for > several reasons. First it is subpackage of the org.apache tree for > which the source license is clearly stated. I can search for a leak of the source code of Windows, copy it to another project, obfuscate its origin a bit by removing author information, copyright information and the old license header and add a ASL license header and rename it to fit inside the other project. That doesn't make it actually ASL, it just makes it a copyright violation. > Second, looking at the code (without being a java guru; the code is > that simple) we can see that there is no dependency on any JDK. > The statement '@since JDK1.0' appears to be true in the sense that > any JDK can compile this since 1.0. We demonstrate that it builds > with JDK8 whenever we run this package through guix build and so, I > see no licensing concerns over the '@since JDK1.0' annotation. This is not what @since means, at least according to the Javadoc documentation (maybe Apache Xalan assigns its own custom meaning). According to <https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javadoc.html>:, This tag means that this change or feature has existed since the software release specified by the since-text value, for example: @since 1.5. For Java platform source code, the @since tag indicates the version of the Java platform API specification [...] so IMO it looks like this code was once part of JDK 1.0. Maybe this is OK, maybe the license of JDK 1.0 allows this, maybe it doesn't but Apache has gained some kind of permission from Sun, maybe it's not legally OK, maybe it never was part of JDK 1.0. I think we'll just have to ask upstream what's going on, WDYT? Greetings, Maxime.
Maxime, You wrote, WDIT? I think that IntStack.java has almost no economic value and so the comparison to a commercial package is not really appropriate. We could ask upstream (file a bug report) but the question is pretty awkward. We are not asking for a bug fix, or for clarification of a behaviour. We are questioning if they are meeting their own stated licensing criteria! Besides that such a ticket is very difficult to resolve. I would feel bad asking this of them because I imagine they are no better equipped to answer questions about JDK1.0 than we are. Worse, if we believe such impropriety is possible why would be believe what they tell us anyway? I think to ask for this to be investigated, at minimum, you would need to find the actual file from JDK1.0 that you feel was appropriated. I don't think we should be asking upstream to work on investigation of a suspicious licensing that cannot improve their software in any functional way. I appreciate your keen sensitivity to the code but I don't think this feedback to apache is helpful and is likely not even true. Sincerely, Frank Pursel On Tue, Apr 12, 2022 at 9:33 AM Maxime Devos <maximedevos@telenet.be> wrote: > Frank Pursel schreef op ma 11-04-2022 om 16:36 [+0000]: > > I looked at the org.apache.xml/uitls/IntStack.java file you pointed > > out. I think the header license certainly prevails here for > > several reasons. First it is subpackage of the org.apache tree for > > which the source license is clearly stated. > > I can search for a leak of the source code of Windows, copy it to > another project, obfuscate its origin a bit by removing author > information, copyright information and the old license header and > add a ASL license header and rename it to fit inside the other project. > That doesn't make it actually ASL, it just makes it a copyright > violation. > > > Second, looking at the code (without being a java guru; the code is > > that simple) we can see that there is no dependency on any JDK. > > The statement '@since JDK1.0' appears to be true in the sense that > > any JDK can compile this since 1.0. We demonstrate that it builds > > with JDK8 whenever we run this package through guix build and so, I > > see no licensing concerns over the '@since JDK1.0' annotation. > > This is not what @since means, at least according to the Javadoc > documentation (maybe Apache Xalan assigns its own custom meaning). > According to > < > https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javadoc.html > >:, > > This tag means that this change or feature has existed since the > software release specified by the since-text value, for example: > @since 1.5. > > For Java platform source code, the @since tag indicates the version > of the Java platform API specification [...] > > so IMO it looks like this code was once part of JDK 1.0. > > Maybe this is OK, maybe the license of JDK 1.0 allows this, maybe it > doesn't but Apache has gained some kind of permission from Sun, maybe > it's not legally OK, maybe it never was part of JDK 1.0. I think we'll > just have to ask upstream what's going on, WDYT? > > Greetings, > Maxime. >
Frank Pursel schreef op wo 13-04-2022 om 23:43 [+0000]: > I think that IntStack.java has almost no economic value and so the > comparison to a commercial package is not really appropriate. It is not about the commercial aspect, it is about the potential proprietariness. > We are not asking for a bug fix, or for clarification of a > behaviour. Violating the (copyright, maybe contract) law seems like a bug to me (TBC it is not known yet if this is the case, it just seems plausible to me at this moment). > We are questioning if they are meeting their own stated > licensing criteria! The problem is not if Apacha meets their own license (it seems that they do, since they explicitly release the source code with their license headers etc. The potential problem is Sun's licensing of JDK1.0, which we (as distribution) might indirectly be in violation of by including java-xalan. Also, it's all about how the question is framed -- asking ‘did you violate the licensing terms’ doesn't seem advisable, but ‘Does IntStack indeed come from JDK1.0, and if so, can I use it under the ASL license like the rest?’ would just be asking for confirmation (and somewhat positive, because it seems to imply we want to use xalan). > I would feel bad asking this of them because I imagine they > are no better equipped to answer questions about JDK1.0 than we are. They are probably not well-equipped to answer questions about JDK1.0. However, they _are_ well-equiped to answer questions about theirselves, presumably they remember what they mean by @since and where their source code came from. > Worse, if we believe such impropriety is possible why would be > believe what they tell us anyway? FWIW, IMO it would only be impropriety because of the current law (and somewhat unclear attribution). Also, by assuming good faith. > I think to ask for this to be investigated, > at minimum, you would need to find the actual file from JDK1.0 that > you feel was appropriated. JDK1.0 is propietary, why would I look into its sources? Also, probably the sources aren't available anyway, given that it is proprietary. > I don't think we should be asking upstream > to work on investigation of a suspicious licensing that cannot > improve their software in any functional way. Moving from being in violation in the law to not seems like a functional improvement to me (assuming it was actually in violation, which has not been determined). Illegal software is, for many practical purposes, not functional. More generally, ignorance is not an excuse, and I imagine willfull ignorance to be even less so. Anyway, I've sent a mail upstream, presumably it will eventually appear in the archive at <https://marc.info/?l=xalan-j-users&r=1&b=202204&w=2>. Greetings, Maxime.
Well, I certainly have never intended to be an accomplice to intellectual property theft. Having formally asked the question that cannot be the case. I also thought you handled the 'framing' of the issue nicely. Your perspective caused me to further investigate IntStack.java. It may be helpful to know that the class IntStack is an extension of IntVector.java which contains none of the suspicious references to JDK1.0. For IntStack.java to have originated in the JDK so too must have IntVector.java and there doesn't appear to be any similar evidence that this is the case. I can also offer that xdocs/sources/xalan/history.xml documents that IntStack.java has been modified multiple times to address bug reports and for optimizations. I really don't know how those attributable modifications would affect the licensing but apache has clearly tailored this code to suite the needs of xalan. It also provides the email addresses of past modifiers that might still be around to more clearly identify the origin of the code. Though it was some time ago. This code appears to have been settled since 2006. 15 year old open source code is unusual by today's standards. Regards, Frank On Thu, Apr 14, 2022 at 8:30 AM Maxime Devos <maximedevos@telenet.be> wrote: > Frank Pursel schreef op wo 13-04-2022 om 23:43 [+0000]: > > I think that IntStack.java has almost no economic value and so the > > comparison to a commercial package is not really appropriate. > > It is not about the commercial aspect, it is about the potential > proprietariness. > > > We are not asking for a bug fix, or for clarification of a > > behaviour. > > Violating the (copyright, maybe contract) law seems like a bug to me > (TBC it is not known yet if this is the case, it just seems plausible > to me at this moment). > > > We are questioning if they are meeting their own stated > > licensing criteria! > > The problem is not if Apacha meets their own license (it seems that > they do, since they explicitly release the source code with their > license headers etc. The potential problem is Sun's licensing of > JDK1.0, which we (as distribution) might indirectly be in violation of > by including java-xalan. > > Also, it's all about how the question is framed -- asking ‘did you > violate the licensing terms’ doesn't seem advisable, but ‘Does IntStack > indeed come from JDK1.0, and if so, can I use it under the ASL license > like the rest?’ would just be asking for confirmation (and somewhat > positive, because it seems to imply we want to use xalan). > > > I would feel bad asking this of them because I imagine they > > are no better equipped to answer questions about JDK1.0 than we are. > > They are probably not well-equipped to answer questions about JDK1.0. > However, they _are_ well-equiped to answer questions about theirselves, > presumably they remember what they mean by @since and where their > source code came from. > > > Worse, if we believe such impropriety is possible why would be > > believe what they tell us anyway? > > FWIW, IMO it would only be impropriety because of the current law (and > somewhat unclear attribution). Also, by assuming good faith. > > > I think to ask for this to be investigated, > > at minimum, you would need to find the actual file from JDK1.0 that > > you feel was appropriated. > > JDK1.0 is propietary, why would I look into its sources? Also, > probably the sources aren't available anyway, given that it is > proprietary. > > > I don't think we should be asking upstream > > to work on investigation of a suspicious licensing that cannot > > improve their software in any functional way. > > Moving from being in violation in the law to not seems like a > functional improvement to me (assuming it was actually in violation, > which has not been determined). Illegal software is, for many > practical purposes, not functional. > > More generally, ignorance is not an excuse, and I imagine willfull > ignorance to be even less so. > > Anyway, I've sent a mail upstream, presumably it will eventually appear > in the archive at > <https://marc.info/?l=xalan-j-users&r=1&b=202204&w=2>. > > Greetings, > Maxime. >
Maxime Devos schreef op di 05-04-2022 om 15:12 [+0200]:
> Now at 62% (src/org/apache/xml/serializer/ToTextSAXHandler.java).
Now at 74% (src/org/apache/xpath/XPathException.java). No new
potential problems found, except for ObjectStack which is a similar
situation as IntStack.
Greetings,
Maxime.
Nice progress. I believe there is an entry regarding the creation of ObjectStack.java in history.xml. On Thu, Apr 14, 2022, 13:33 Maxime Devos <maximedevos@telenet.be> wrote: > Maxime Devos schreef op di 05-04-2022 om 15:12 [+0200]: > > Now at 62% (src/org/apache/xml/serializer/ToTextSAXHandler.java). > > Now at 74% (src/org/apache/xpath/XPathException.java). No new > potential problems found, except for ObjectStack which is a similar > situation as IntStack. > > Greetings, > Maxime. >
Hi,
While looking superficially into the source for problems isn't a slow
process (I didn't time it thoroughly but I'd say 20 minutes for 10% or
so, and possibly less if the files are small, or maybe more if the
timing was inaccurate or unrepresentative), I'm not exactly swimming in
free time or something, so don't expect an ‘it's done!’ response
anytime soon.
I see two options here:
* you could look into the rest yourself (though technically a COI I
suppose ...)
* consider the current checks into the source code to be sufficient
Also, about the IntStack thing:
* as you wrote, upstream has modified it a lot
* IIRC and IIUC (though I only looked rather superficially) it's
a rather basic class anyway, probably not many other plausible
ways to do it. Also tiny.
* current OpenJDK's are freely licensed anyway
* upstream has been asked what, exactly, is the situation
(though it hasn't been answered yet)
* so I don't think this is a blocker
Greetings,
Maxime.
I concur. WDYT is next? Thanks, Frank (acrow#guix) On Sat, Apr 16, 2022 at 9:02 PM Maxime Devos <maximedevos@telenet.be> wrote: > Hi, > > While looking superficially into the source for problems isn't a slow > process (I didn't time it thoroughly but I'd say 20 minutes for 10% or > so, and possibly less if the files are small, or maybe more if the > timing was inaccurate or unrepresentative), I'm not exactly swimming in > free time or something, so don't expect an ‘it's done!’ response > anytime soon. > > I see two options here: > > * you could look into the rest yourself (though technically a COI I > suppose ...) > > * consider the current checks into the source code to be sufficient > > Also, about the IntStack thing: > > * as you wrote, upstream has modified it a lot > * IIRC and IIUC (though I only looked rather superficially) it's > a rather basic class anyway, probably not many other plausible > ways to do it. Also tiny. > * current OpenJDK's are freely licensed anyway > * upstream has been asked what, exactly, is the situation > (though it hasn't been answered yet) > * so I don't think this is a blocker > > Greetings, > Maxime. >
Frank Pursel schreef op di 19-04-2022 om 17:13 [+0000]: > I concur. WDYT is next? With which of the two options do you concur: > > I see two options here: > > > > * you could look into the rest yourself (though technically a COI > > I > > suppose ...) > > > > * consider the current checks into the source code to be > > sufficient Greetings, Maxime.
I think the current checks are sufficient but that I could also do additional checks if you feel that would be helpful. On Tue, Apr 19, 2022, 11:44 Maxime Devos <maximedevos@telenet.be> wrote: > Frank Pursel schreef op di 19-04-2022 om 17:13 [+0000]: > > I concur. WDYT is next? > > With which of the two options do you concur: > > > > I see two options here: > > > > > > * you could look into the rest yourself (though technically a COI > > > I > > > suppose ...) > > > > > > * consider the current checks into the source code to be > > > sufficient > > Greetings, > Maxime. >
diff --git a/gnu/packages/xml.scm b/gnu/packages/xml.scm index 3ce5e771c7..2a0a8e2949 100644 --- a/gnu/packages/xml.scm +++ b/gnu/packages/xml.scm @@ -33,6 +33,7 @@ ;;; Copyright © 2021 Guillaume Le Vaillant <glv@posteo.net> ;;; Copyright © 2021 David Larsson <david.larsson@selfhosted.xyz> ;;; Copyright © 2021 Matthew James Kraai <kraai@ftbfs.org> +;;; Copyright © 2022 Frank Pursel <frank.pursel@gmail.com> ;;; ;;; This file is part of GNU Guix. ;;; @@ -2592,3 +2593,58 @@ (define-public python-xmltodict (description "This package provides a Python library to convert XML to @code{OrderedDict}.") (license license:expat))) + +(define-public java-xalan-interp + (package + (name "java-xalan-interp") + (version "2.7.2") + (source + (origin + (method url-fetch) + (uri (string-append "mirror://apache/xalan/xalan-j/source/xalan-j_" + (string-replace-substring + version "." "_") + "-src.tar.gz")) + (sha256 + (base32 "166vg9i11qzi0vbv09abfb50q8caq8wr6zrwg0cwqws9k394l62w")) + (modules '((guix build utils))) + (snippet '(begin + ;; Removing bundled jars + (for-each + (lambda (f) + (delete-file f)) + (find-files "." "\\.(jar|tar\\.gz)$")))))) + (build-system ant-build-system) + (arguments + `(#:phases (modify-phases + %standard-phases + (add-after 'unpack 'prepare-for-build + (lambda* (#:key inputs outputs #:allow-other-keys) + (setenv "ANT_OPTS" "-Dxsltc.java_cup.not_needed=true") + (substitute* "build.xml" + ;; Only the interpretive compiler. xsltc contains a + ;; circular reference java_cup. + (("(<target name=\"jar\" depends=\"xalan-interpretive.compile),.*" + all pre) + (string-append pre "\"")) + (("xml-apis") "jaxp")) + (substitute* (list "src/MANIFEST.MF" + "src/manifest.xalan-interpretive" + "src/MANIFEST.SERIALIZER" + "src/manifest.xsltc") + ;; This stops the indexing phase from searching for + ;; xml-apis in the wrong location -- java-xerces and + ;; java-jaxp are propagated, so the eventual Java + ;; application package will still have access to it. + (("^Class-Path:(.*)$") "")))) + (replace 'install + (install-jars "build"))))) + (native-inputs (list java-junit java-hamcrest-core)) + (propagated-inputs (list java-jaxp java-xerces)) + (home-page "https://xalan.apache.org/xalan-j/index.html") + (synopsis "Java XSLT processor") + (description "XSLT processor in java implementing XSLT Version 1.0, XPath +Version 1.0, and JAXP 1.3. It builds on SAX2 and DOM level 3. This version +is the fully functional interpreter, xslt, not the xsltc version which may be +faster.") + (license license:asl2.0)))
Guix!, Maxime, Thank you for the feedback. The result is a better package! These changes have built successfully and incorporate the identified changes. Regards, Frank Pursel acrow#guix From 4018f56893077df82c67c06e341339fd3c00e14a Mon Sep 17 00:00:00 2001 Message-Id: <4018f56893077df82c67c06e341339fd3c00e14a.1647630491.git.frank.pursel@gmail.com> From: Frank Pursel <frank.pursel@gmail.com> Date: Wed, 23 Feb 2022 13:59:26 -0800 Subject: [PATCH] gnu: Add java-xalan-interp * gnu/packages/xml.scm (java-xalan-interp): New variable --- gnu/packages/xml.scm | 56 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+)