On 07/10/2021 20:59, Konstantin Kolinko wrote:
чт, 7 окт. 2021 г. в 18:46, Mark Thomas <ma...@apache.org>:
<snip/>
Is this a problem worth solving? If it is, is there a better way?
Hi!
Last few days I was thinking of the following approaches:
<snip/>
I view users having to explicitly make a choice as a disadvantage rather
than an advantage. I'd like the solution to be automatic.
a) is essentially another variation of b), c) & d) that uses "magic" to
select the right JAR from ${cataliba.base}/lib
I wonder about another variation where the common loader syntax gets a
Java version added. I'm not sure this level of configuration flexibility
is necessary.
I *really* like e). That is very neat solution. My only concern is
licensing. There are two issues:
- the JARs are licensed under different versions of the EPL
- ASF license policy says we can't modify EPL licensed artefacts
Given we aren't making source modifications, the ASF policy concern may
not be valid.
The multiple license issue should be manageable with appropriate updates
to out LICENSE and NOTICE files although I'd be more comfortable if we
checked the Eclipse foundation were happy too.
Given the completely automatic nature, my current preference is for e)
or a).
Looking at this another way, a) and e) are similar too. The difference
is in a) Tomcat selects the correct JAR whereas in a) the JRE selects
the right classes from a single JAR.
e) is certainly the more elegant solution but it does have some admin
we'd need to do. a) is less elegant but avoids the admin. Maybe
implement a) as a stop-gap while we see if e) is possible?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
