> On Aug 14, 2019, at 1:23 AM, Alex The Rocker <alex.m3...@gmail.com> wrote:
> 
> Hello,
> 
> How about JAXB which is not EPL but EDL 1.0 ?
> (see https://github.com/eclipse-ee4j/jaxb-api/tree/2.3.2)

EDL is an approved license.  Here's the complete naughty and nice list as it 
where :)

 - https://apache.org/legal/resolved.html

The interesting thing about jaxb-api is there is only one implementation in the 
world and it is also EDL and no longer included in the JVM.  If we typed in the 
API, 98% of the other JAXB code we ship would still be EDL.


-David

> Le mer. 14 août 2019 à 10:16, David Blevins <david.blev...@gmail.com> a écrit 
> :
>> 
>> This is really the better thread to talk about how to handle the gaps in our 
>> Java EE 8 APIs and support.
>> 
>> As noted, there is not license victory to be won.  We have had EPL and CDDL 
>> dependencies since v1.0 in 2011.
>> 
>> From a Geronimo perspective, we typed in the APIs and created all those spec 
>> jars because there were no open source options that weren't the JBoss GPL 
>> versions.  GlassFish didn't exist yet.  When GlassFish came about, we kept 
>> up the practice largely out of habit.  We did have an unavoidable CDDL via 
>> the xml schemas and JAXB RI, so our licensing victory wasn't quite there.
>> 
>> This is really a resources and timeline issue.
>> 
>> Some of these specs are actually implementations, specifically:
>> 
>> - JavaMail 1.6
>> - JACC 1.6
>> - Activation 1.2
>> 
>> If we decide we want the Geronimo versions to be upgraded (implemented) and 
>> this is important for TomEE 8, we should expect that to ship sometime 2020.
>> 
>> 
>> --
>> David Blevins
>> http://twitter.com/dblevins
>> http://www.tomitribe.com
>> 
>>> On Aug 13, 2019, at 12:10 AM, David Blevins <david.blev...@gmail.com> wrote:
>>> 
>>> I did a small gap-analysis of where we're still short on Java EE 8 APIs 
>>> from the perspective of our javaee-api jar:
>>> 
>>> - https://issues.apache.org/jira/browse/TOMEE-2620
>>> 
>>> Specific callouts are these APIs are also implementations, so switching to 
>>> the equivalent Jakarta version also gains a compliant implementation:
>>> 
>>> - javax.activation 1.1 vs 1.2
>>> - javax.security.jacc 1.4 vs 1.6
>>> - javax.mail 1.5 vs 1.6
>>> 
>>> This one is a flaw in my reporting, it's included in Tomcat:
>>> 
>>> - javax.security.auth.message 1.0 vs 1.1 (JASPIC)
>>> 
>>> We should likely use the exact version cxf requires of this:
>>> 
>>> - javax.xml.ws 2.2 vs 2.3 (JAX-WS)
>>> 
>>> These we will likely not be able to change as the corresponding 
>>> implementations aren't there:
>>> 
>>> - javax.enterprise.concurrent 1.0 vs 1.1
>>> - javax.resource 1.6 vs 1.7
>>> - javax.transaction 1.2 vs 1.3 (JTA)
>>> 
>>> If we ship TomEE 8.0 with just those three lagging APIs, that would be 
>>> pretty good.  Shipping a final with 8 lagging libraries, less fantastic.
>>> 
>>> What do people think about the potential upgrades?
>>> 
>>> 
>>> --
>>> David Blevins
>>> http://twitter.com/dblevins
>>> http://www.tomitribe.com
>>> 
>> 

Reply via email to