[jira] [Resolved] (XALANJ-2650) The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression since 2.7.2)

[Joseph Kessselman (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joseph Kessselman resolved XALANJ-2650.
---
Resolution: Fixed

> The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression 
> since 2.7.2)
> -
>
> Key: XALANJ-2650
> URL: https://issues.apache.org/jira/browse/XALANJ-2650
> Project: XalanJ2
>  Issue Type: Improvement
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>  Components: Xalan
>Reporter: Vladimir Sitnikov
>Assignee: Joseph Kessselman
>Priority: Blocker
>
> See [https://repo1.maven.org/maven2/xalan/xalan/2.7.3/xalan-2.7.3.pom]
> The  tag is missing, and 2.7.3 does not refer to a parent pom.
> ---
> Please:
> 1) Specify the license via  tag
> 2) Specify the license in the jar file (Bundle-License attribute in 
> META-INF/MANIFEST.MF), see 
> [https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license]
> 3) Include license text as META-INF/LICENSE in the jar file. See 
> https://issues.apache.org/jira/browse/LEGAL-642 which clarifies each jar 
> should include a LICENSE file.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

Re: Embedded packages, architectural decision needed

[Joseph Kesselman]

I'm not sure which version of regexp the Maven build is pulling down; will 
check.

--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

Caveat: Opinionated old geezer with overcompensated writer's block. May be 
redundant, verbose, prolix, sesquipedalian, didactic, officious, or redundant.

From: Jared Davis 
Sent: Friday, March 29, 2024 11:44:34 AM
To: dev@xalan.apache.org 
Subject: Re: Embedded packages, architectural decision needed

The 1.3 version of regexp is known to be buggy. Old email thread  "Source of 
regular expression jar in Xalan 2.7.3 RC9" Jan - April 2023 suggests removing 
it.




[xalan-java.png]
xalan-java/xalan/pom.xml at master · 
apache/xalan-java
github.com



  regexp
  regexp
  1.3




Jakarta Regexp - Jakarta Regexp History of 
Changes
jakarta.apache.org
[favicon.ico]

1.4 from aug 2005 has a critical fix


  *   Fixed Bug 2121: 
'.' or '-' in bracket expression gives unexpected results (VG)



On Mar 29, 2024, at 11:07 AM, Joseph Kessselman  wrote:

(See https://issues.apache.org/jira/browse/XALANJ-2436)

At the moment, Xalan -- even the Maven build -- is still importing bcel and 
regexp into its jarfiles without renaming/"shading" them.

While XALANJ-2436 expresses the problem in terms of Endorsed Classpath (which 
is no longer needed since Sun shaded their copy of Xalan and the 
javax/JAXP/TrAX interfaces select between implementations via a properties 
setting), it is potentially a general issue. With this setup, if there are 
conflicting implementations available, it may be impossible for a user to 
select both the desired version of Xalan and the desired version of these 
dependencies.


There are only a few clean solutions. Simplest first:

#1) Make these packages external dependencies for Xalan, as are so many other 
packages. Advantage: Free ability to mix and match versions. Disadvantage: It's 
possible to run into incompatibilities as packages are independently upgraded. 
The various version-dependency systems are *supposed* to be able to manage 
this, but don't always.

#2) Shade these packages, renaming Xalan's copy of them (exactly as Sun shades 
Xalan itself to avoid having their possibly-outdated convenience copy conflict 
with ours). Advantage: Xalan always runs with a known version of these tools, 
and user doesn't have to supply them. Disadvantage: If user wants to override 
Xalan's use of that binding, they need to provide a new shaded copy of the 
library; merely putting the standard jarfile earlier on the classpath isn't 
sufficient.

#3) Have Xalan run in an independent classloader, OSGi-style. Advantage: 
Doesn't require renaming, but still isolates Xalan's choice of library version 
from that of the rest of the application. Also, opens the opportunity for OSGi 
demand-loading, which can significantly improve efficiency by not bringing in 
any classes not actually in use. Disadvantage: Complexity, potential user 
confusion when debugging, and major implementation effort to get the full 
benefit.

#Ugh) We *could* leave it as it is. I don't consider that a clean solution, but 
it is a solution. It's no worse than we have been, but no better... and given 
how many other external dependencies we have, I have trouble justifying these 
two being special cases worth embedding.


I think we need to make an architectural decision on this. As I say, I 
currently prefer #1. That *would* mean Xalan users would have to be aware of 
and provide these dependencies, which would be a change from past releases. But 
it's really not different from our dependencies upon Xerces or other external 
packages.

And I don't see a good reason to continue embedding without renaming; this 
feels like a tradition we should break.

--
` /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
 /   https://www.amazon.com/dp/B09WJ3H657/
Caveat: Opinionated old geezer with overcompensated writer's block. May be 
redundant, verbose, prolix, sesquipedalian, didactic, officious, or redundant. 
Feel free to call him on it.

Re: Embedded packages, architectural decision needed

[Jared Davis]

The 1.3 version of regexp is known to be buggy. Old email thread  "Source of 
regular expression jar in Xalan 2.7.3 RC9" Jan - April 2023 suggests removing 
it.



https://github.com/apache/xalan-java/blob/master/xalan/pom.xml
xalan-java/xalan/pom.xml at master · apache/xalan-java
github.com



  regexp
  regexp
  1.3



https://jakarta.apache.org/regexp/changes.html

1.4 from aug 2005 has a critical fix

Fixed Bug 2121 : '.' or 
'-' in bracket expression gives unexpected results (VG)



> On Mar 29, 2024, at 11:07 AM, Joseph Kessselman  wrote:
> 
> (See https://issues.apache.org/jira/browse/XALANJ-2436)
> 
> At the moment, Xalan -- even the Maven build -- is still importing bcel and 
> regexp into its jarfiles without renaming/"shading" them.
> 
> While XALANJ-2436 expresses the problem in terms of Endorsed Classpath (which 
> is no longer needed since Sun shaded their copy of Xalan and the 
> javax/JAXP/TrAX interfaces select between implementations via a properties 
> setting), it is potentially a general issue. With this setup, if there are 
> conflicting implementations available, it may be impossible for a user to 
> select both the desired version of Xalan and the desired version of these 
> dependencies.
> 
> 
> There are only a few clean solutions. Simplest first:
> 
> #1) Make these packages external dependencies for Xalan, as are so many other 
> packages. Advantage: Free ability to mix and match versions. Disadvantage: 
> It's possible to run into incompatibilities as packages are independently 
> upgraded. The various version-dependency systems are *supposed* to be able to 
> manage this, but don't always.
> 
> #2) Shade these packages, renaming Xalan's copy of them (exactly as Sun 
> shades Xalan itself to avoid having their possibly-outdated convenience copy 
> conflict with ours). Advantage: Xalan always runs with a known version of 
> these tools, and user doesn't have to supply them. Disadvantage: If user 
> wants to override Xalan's use of that binding, they need to provide a new 
> shaded copy of the library; merely putting the standard jarfile earlier on 
> the classpath isn't sufficient.
> 
> #3) Have Xalan run in an independent classloader, OSGi-style. Advantage: 
> Doesn't require renaming, but still isolates Xalan's choice of library 
> version from that of the rest of the application. Also, opens the opportunity 
> for OSGi demand-loading, which can significantly improve efficiency by not 
> bringing in any classes not actually in use. Disadvantage: Complexity, 
> potential user confusion when debugging, and major implementation effort to 
> get the full benefit.
> 
> #Ugh) We *could* leave it as it is. I don't consider that a clean solution, 
> but it is a solution. It's no worse than we have been, but no better... and 
> given how many other external dependencies we have, I have trouble justifying 
> these two being special cases worth embedding.
> 
> 
> I think we need to make an architectural decision on this. As I say, I 
> currently prefer #1. That *would* mean Xalan users would have to be aware of 
> and provide these dependencies, which would be a change from past releases. 
> But it's really not different from our dependencies upon Xerces or other 
> external packages.
> 
> And I don't see a good reason to continue embedding without renaming; this 
> feels like a tradition we should break.
> 
> -- 
> ` /_  Joe Kesselman (he/him/his)
> -/ _) My Alexa skill for New Music/New Sounds fans:
>  /   https://www.amazon.com/dp/B09WJ3H657/
> Caveat: Opinionated old geezer with overcompensated writer's block. May be 
> redundant, verbose, prolix, sesquipedalian, didactic, officious, or 
> redundant. Feel free to call him on it.
> 

Embedded packages, architectural decision needed

[Joseph Kessselman]

(See https://issues.apache.org/jira/browse/XALANJ-2436)

At the moment, Xalan -- even the Maven build -- is still importing bcel 
and regexp into its jarfiles without renaming/"shading" them.


While XALANJ-2436 expresses the problem in terms of Endorsed Classpath 
(which is no longer needed since Sun shaded their copy of Xalan and the 
javax/JAXP/TrAX interfaces select between implementations via a 
properties setting), it is potentially a general issue. With this setup, 
if there are conflicting implementations available, it may be impossible 
for a user to select both the desired version of Xalan and the desired 
version of these dependencies.



There are only a few clean solutions. Simplest first:

#1) Make these packages external dependencies for Xalan, as are so many 
other packages. Advantage: Free ability to mix and match versions. 
Disadvantage: It's possible to run into incompatibilities as packages 
are independently upgraded. The various version-dependency systems are 
*supposed* to be able to manage this, but don't always.


#2) Shade these packages, renaming Xalan's copy of them (exactly as Sun 
shades Xalan itself to avoid having their possibly-outdated convenience 
copy conflict with ours). Advantage: Xalan always runs with a known 
version of these tools, and user doesn't have to supply them. 
Disadvantage: If user wants to override Xalan's use of that binding, 
they need to provide a new shaded copy of the library; merely putting 
the standard jarfile earlier on the classpath isn't sufficient.


#3) Have Xalan run in an independent classloader, OSGi-style. Advantage: 
Doesn't require renaming, but still isolates Xalan's choice of library 
version from that of the rest of the application. Also, opens the 
opportunity for OSGi demand-loading, which can significantly improve 
efficiency by not bringing in any classes not actually in use. 
Disadvantage: Complexity, potential user confusion when debugging, and 
major implementation effort to get the full benefit.


#Ugh) We *could* leave it as it is. I don't consider that a clean 
solution, but it is a solution. It's no worse than we have been, but no 
better... and given how many other external dependencies we have, I have 
trouble justifying these two being special cases worth embedding.



I think we need to make an architectural decision on this. As I say, I 
currently prefer #1. That *would* mean Xalan users would have to be 
aware of and provide these dependencies, which would be a change from 
past releases. But it's really not different from our dependencies upon 
Xerces or other external packages.


And I don't see a good reason to continue embedding without renaming; 
this feels like a tradition we should break.


--
` /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
  /   https://www.amazon.com/dp/B09WJ3H657/
Caveat: Opinionated old geezer with overcompensated writer's block. May 
be redundant, verbose, prolix, sesquipedalian, didactic, officious, or 
redundant. Feel free to call him on it.


OpenPGP_0xFFBAFF963D937815.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature