Remove non-existent provider from META-INF/services

[carlosame]

org.apache.bsf.BSFManager is not available from this Jar file, which is causing issues with modular JDKs. See for example:

• https://issues.apache.org/jira/browse/XALANJ-2632
• https://marc.info/?l=xalan-dev&m=164935208630930&w=2
• https://stackoverflow.com/questions/54682417/unable-to-derive-module-descriptor-provider-class-x-not-in-module
• https://issues.redhat.com/browse/WFLY-10279
• http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012147.html

And the workarounds aren't nice: moditect/moditect-gradle-plugin#12 (comment)

Please fix this.

[jkesselm]

Xalan-Java does reference BSF during compilation, because ExtensionHandlerGeneral.java has the ability to use the BSF API to run scripts. But I agree that we should not be saying we provide BSF; folks who want to use it should fetch the current release of bsf.jar separately.

This change looks reasonable to me. Unfortunately I do not have write access and so can't accept and merge the pull request.

[jkesselm]

This is resolved in the migration from Ant to Maven, now in progress.

[vlsi]

@jkesselm , unfortunately, by closing the PRs you effectively decline the contribution which is demotivating. As you implement the same thing on your own, you effectively steal the contribution and put your name on it.
Of course, a single line is not a big deal, however, the change was perfectly valid, it was helpful for many people, so why not just merge it directly?

I suggest reconsidering and merging the suggestion instead. It would result in showing carlosame among the contributors (e.g. https://github.com/apache/xalan-java/graphs/contributors ), and it would encourage the others.

[carlosame]

I suggest reconsidering and merging the suggestion instead. It would result in showing carlosame among the contributors (e.g. https://github.com/apache/xalan-java/graphs/contributors ), and it would encourage the others.

Thank you for your comment, however yesterday after this PR was closed I removed my Xalan fork and I'd rather not redo the work.

Moreover I have no interest in having my name associated with Apache Xalan. I watched how 2.7.3 directly included the BCEL packages despite my warn about split packages (modular JDKs will reject Xalan if BCEL happens to be also in the modulepath). Then how your PR was ignored "because we do not need CI now" despite it offering other improvements, and then for example a more quirky alternative for test execution being merged instead. Etc... you just have to read the mailing list discussions.

I do not think that giving negative opinions on other open source projects is desirable, however I'm puzzled to see how the ASF keeps pushing Github as a way to get more contributions to their projects but then it continues with "The Apache Way" as described above. I wonder how many other people are going to get their time wasted due to this.

[jkesselm]

Apologies if I offended. I'm just getting back into Apache, and I'm used to working in company git environments where people are less concerned about individual credit than about whether the improvement gets made, so I may be a bit fast on the gun in trying to simplify our backlog, and in closing before consensus is reached. Objection accepted, I'll try to be more careful about that.

…

-- /_ Joe Kesselman (he/him/his) -/ _) My Alexa skill for New Music/New Sounds fans: / https://www.amazon.com/dp/B09WJ3H657/ () Plaintext Ribbon Campaign /\ Stamp out HTML mail!

________________________________ From: carlosame ***@***.***> Sent: Thursday, October 19, 2023 6:22:31 AM To: apache/xalan-java ***@***.***> Cc: Joe Kesselman ***@***.***>; Mention ***@***.***> Subject: Re: [apache/xalan-java] Remove non-existent provider from META-INF/services (PR #1) I suggest reconsidering and merging the suggestion instead. It would result in showing carlosame among the contributors (e.g. https://github.com/apache/xalan-java/graphs/contributors ), and it would encourage the others. Thank you for your comment, however yesterday after this PR was closed I removed my Xalan fork and I'd rather not redo the work. Moreover I have no interest in having my name associated with Apache Xalan. I watched how 2.7.3 directly included the BCEL packages despite my warn about split packages (modular JDKs will reject Xalan if BCEL happens to be also in the modulepath). Then how your PR was ignored "because we do not need CI now" despite it offering other improvements, and then for example a more quirky alternative for test execution being merged instead. Etc... you just have to read the mailing list discussions. I do not think that giving negative opinions on other open source projects is desirable, however I'm puzzled to see how the ASF keeps pushing Github as a way to get more contributions to their projects but then it continues with "The Apache Way" as described above. I wonder how many other people are going to get their time wasted due to this. — Reply to this email directly, view it on GitHub<#1 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A7OJ6W7HDWG6MC4IZR3BQYTYAD5OPAVCNFSM5S2FZPC2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZXGA2TCNZUHAZA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[carlosame]

Apologies if I offended. I'm just getting back into Apache, and I'm used to working in company git environments where people are less concerned about individual credit than about whether the improvement gets made, so I may be a bit fast on the gun in trying to simplify our backlog, and in closing before consensus is reached. Objection accepted, I'll try to be more careful about that.

Hi @jkesselm, my comment wasn't aimed at you specifically (I actually see you as a positive force in this project), but please consider that this isn't an environment where people are paid to work, and in any case ignoring contributors implies lack of interest in future contributions. For example, either @vlsi or me could have easily come up with a Maven or Gradle build in a few hours (a reminder that I offered the Gradle build in EchoXSL more than a year ago). But the ASF projects tend to work in a different way.