You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@gmail.com> on 2019/08/13 07:10:02 UTC
Java EE 8 versions of APIs
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
Re: Java EE 8 versions of APIs
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
See comments below
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Tue, Aug 13, 2019 at 9:10 AM David Blevins <da...@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
>
>
We have geronimo versions for all of them. I worked to make JavaMail
compliant for instance.
I just need to trigger some votes for api and provider.
Happy to use the jakarta versions if the EPL licence is fine for everyone.
> This one is a flaw in my reporting, it's included in Tomcat:
>
> - javax.security.auth.message 1.0 vs 1.1 (JASPIC)
>
>
We use Tomcat APIs when applicable already (servlet, websocket), so not a
big deal. We have a tomcat classifier for Tomcat usage where we take
already provided APIs off the java api. So we should be good to use Tomcat
jar.
> 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)
>
Those don't exist indeed and we need to create them
>
> 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
>
>
Re: Java EE 8 versions of APIs
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Thanks David.
Fantastic job with the review and summary. I am currently working on
Jakarta EE 8 compliancy. I have noticed some gaps and attempted to fix some
of them.
I'm happy to give it a try with them but the 3 last until we can move on.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Tue, Aug 13, 2019 at 9:10 AM David Blevins <da...@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
>
>
Re: Java EE 8 versions of APIs
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Security and annotations are up for vote.
I have JavaMail 1.6 created and almost ready for VOTE.
We don't have standalone TCK to run for those, but when they are released,
I'll get them all integrated and I'll push a TCK build on TomEE so we have
a view on what we need to fix.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Tue, Sep 3, 2019 at 6:16 PM David Blevins <da...@gmail.com>
wrote:
> See this note on our activation thread. Long story short, our version 1.1
> is legitimate and the exact version expected for Java EE 8 on Java 8.
>
> -
> https://lists.apache.org/thread.html/89f81b0584dffca7d979a4fdedc6fe7b4f3c547848b0159b1702857e@
> <dev.tomee.apache.org>
>
> On JavaMail, my recommendation would be to update asap, but not hold up
> the TomEE 8.0.0 final release.
>
> IMHO, we should try to be vote-ready on Friday. If we can get it done in
> that time, cool.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On Sep 3, 2019, at 8:48 AM, Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com> wrote:
> >
> > Trying to pull this message up in the list.
> >
> > If we want to release Apache TomEE 8.0.0 before CodeOne, we need
> JavaMail,
> > Activation and some others.
> > For the others, I think I managed to get them up for vote and ready.
> >
> > For Activation and JavaMail it's also an implementation so there is more
> > work involved and I am not sure we can get it done by CodeOne.
> > Of course it's not a good reason, but I still want to revive this topic
> so
> > we can decide all together how we want to proceed.
> >
> > Do we update/create our specs in Geronimo?
> > Do we use the eclipse jars?
> >
> > thoughts
> >
> >
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Thu, Aug 15, 2019 at 5:53 AM David Blevins <da...@gmail.com>
> > wrote:
> >
> >>> On Aug 14, 2019, at 2:05 AM, Alex The Rocker <al...@gmail.com>
> >> wrote:
> >>>
> >>> Okay; for EDL I see it's compatible with Apache licensing, but
> >>> strangely, JAXB license does not look like an EDL:
> >>> https://github.com/eclipse-ee4j/jaxb-api/blob/2.3.2/LICENSE.md
> >>>
> >>> Am I mistaking or this is actually "cheesy" ?
> >>
> >> I pulled down the official text here and did a quick reformat to match
> it
> >> to the LICENSE.md
> >>
> >> - https://www.eclipse.org/org/documents/edl-v10.php
> >>
> >> Sans the copyright statement, both came out identical in a diff, so we
> >> appear good.
> >>
> >> We will want to make sure our NOTICE file does contain the copyright
> >> statement, so that is a definitely good catch.
> >>
> >>
> >> -David
> >>
> >>> Le mer. 14 août 2019 à 10:37, David Blevins <db...@tomitribe.com> a
> >> écrit :
> >>>>
> >>>>> On Aug 14, 2019, at 1:23 AM, Alex The Rocker <al...@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.blevins@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.blevins@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
> >>>>>>>
> >>>>>>
> >>>>
> >>
> >>
>
>
Re: Java EE 8 versions of APIs
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Security and annotations are up for vote.
I have JavaMail 1.6 created and almost ready for VOTE.
We don't have standalone TCK to run for those, but when they are released,
I'll get them all integrated and I'll push a TCK build on TomEE so we have
a view on what we need to fix.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Tue, Sep 3, 2019 at 6:16 PM David Blevins <da...@gmail.com>
wrote:
> See this note on our activation thread. Long story short, our version 1.1
> is legitimate and the exact version expected for Java EE 8 on Java 8.
>
> -
> https://lists.apache.org/thread.html/89f81b0584dffca7d979a4fdedc6fe7b4f3c547848b0159b1702857e@
> <dev.tomee.apache.org>
>
> On JavaMail, my recommendation would be to update asap, but not hold up
> the TomEE 8.0.0 final release.
>
> IMHO, we should try to be vote-ready on Friday. If we can get it done in
> that time, cool.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On Sep 3, 2019, at 8:48 AM, Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com> wrote:
> >
> > Trying to pull this message up in the list.
> >
> > If we want to release Apache TomEE 8.0.0 before CodeOne, we need
> JavaMail,
> > Activation and some others.
> > For the others, I think I managed to get them up for vote and ready.
> >
> > For Activation and JavaMail it's also an implementation so there is more
> > work involved and I am not sure we can get it done by CodeOne.
> > Of course it's not a good reason, but I still want to revive this topic
> so
> > we can decide all together how we want to proceed.
> >
> > Do we update/create our specs in Geronimo?
> > Do we use the eclipse jars?
> >
> > thoughts
> >
> >
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Thu, Aug 15, 2019 at 5:53 AM David Blevins <da...@gmail.com>
> > wrote:
> >
> >>> On Aug 14, 2019, at 2:05 AM, Alex The Rocker <al...@gmail.com>
> >> wrote:
> >>>
> >>> Okay; for EDL I see it's compatible with Apache licensing, but
> >>> strangely, JAXB license does not look like an EDL:
> >>> https://github.com/eclipse-ee4j/jaxb-api/blob/2.3.2/LICENSE.md
> >>>
> >>> Am I mistaking or this is actually "cheesy" ?
> >>
> >> I pulled down the official text here and did a quick reformat to match
> it
> >> to the LICENSE.md
> >>
> >> - https://www.eclipse.org/org/documents/edl-v10.php
> >>
> >> Sans the copyright statement, both came out identical in a diff, so we
> >> appear good.
> >>
> >> We will want to make sure our NOTICE file does contain the copyright
> >> statement, so that is a definitely good catch.
> >>
> >>
> >> -David
> >>
> >>> Le mer. 14 août 2019 à 10:37, David Blevins <db...@tomitribe.com> a
> >> écrit :
> >>>>
> >>>>> On Aug 14, 2019, at 1:23 AM, Alex The Rocker <al...@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.blevins@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.blevins@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
> >>>>>>>
> >>>>>>
> >>>>
> >>
> >>
>
>
Re: Java EE 8 versions of APIs
Posted by David Blevins <da...@gmail.com>.
See this note on our activation thread. Long story short, our version 1.1 is legitimate and the exact version expected for Java EE 8 on Java 8.
- https://lists.apache.org/thread.html/89f81b0584dffca7d979a4fdedc6fe7b4f3c547848b0159b1702857e@<dev.tomee.apache.org>
On JavaMail, my recommendation would be to update asap, but not hold up the TomEE 8.0.0 final release.
IMHO, we should try to be vote-ready on Friday. If we can get it done in that time, cool.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
> On Sep 3, 2019, at 8:48 AM, Jean-Louis Monteiro <jl...@tomitribe.com> wrote:
>
> Trying to pull this message up in the list.
>
> If we want to release Apache TomEE 8.0.0 before CodeOne, we need JavaMail,
> Activation and some others.
> For the others, I think I managed to get them up for vote and ready.
>
> For Activation and JavaMail it's also an implementation so there is more
> work involved and I am not sure we can get it done by CodeOne.
> Of course it's not a good reason, but I still want to revive this topic so
> we can decide all together how we want to proceed.
>
> Do we update/create our specs in Geronimo?
> Do we use the eclipse jars?
>
> thoughts
>
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Thu, Aug 15, 2019 at 5:53 AM David Blevins <da...@gmail.com>
> wrote:
>
>>> On Aug 14, 2019, at 2:05 AM, Alex The Rocker <al...@gmail.com>
>> wrote:
>>>
>>> Okay; for EDL I see it's compatible with Apache licensing, but
>>> strangely, JAXB license does not look like an EDL:
>>> https://github.com/eclipse-ee4j/jaxb-api/blob/2.3.2/LICENSE.md
>>>
>>> Am I mistaking or this is actually "cheesy" ?
>>
>> I pulled down the official text here and did a quick reformat to match it
>> to the LICENSE.md
>>
>> - https://www.eclipse.org/org/documents/edl-v10.php
>>
>> Sans the copyright statement, both came out identical in a diff, so we
>> appear good.
>>
>> We will want to make sure our NOTICE file does contain the copyright
>> statement, so that is a definitely good catch.
>>
>>
>> -David
>>
>>> Le mer. 14 août 2019 à 10:37, David Blevins <db...@tomitribe.com> a
>> écrit :
>>>>
>>>>> On Aug 14, 2019, at 1:23 AM, Alex The Rocker <al...@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 <da...@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 <da...@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
>>>>>>>
>>>>>>
>>>>
>>
>>
Re: Java EE 8 versions of APIs
Posted by David Blevins <da...@gmail.com>.
See this note on our activation thread. Long story short, our version 1.1 is legitimate and the exact version expected for Java EE 8 on Java 8.
- https://lists.apache.org/thread.html/89f81b0584dffca7d979a4fdedc6fe7b4f3c547848b0159b1702857e@<dev.tomee.apache.org>
On JavaMail, my recommendation would be to update asap, but not hold up the TomEE 8.0.0 final release.
IMHO, we should try to be vote-ready on Friday. If we can get it done in that time, cool.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
> On Sep 3, 2019, at 8:48 AM, Jean-Louis Monteiro <jl...@tomitribe.com> wrote:
>
> Trying to pull this message up in the list.
>
> If we want to release Apache TomEE 8.0.0 before CodeOne, we need JavaMail,
> Activation and some others.
> For the others, I think I managed to get them up for vote and ready.
>
> For Activation and JavaMail it's also an implementation so there is more
> work involved and I am not sure we can get it done by CodeOne.
> Of course it's not a good reason, but I still want to revive this topic so
> we can decide all together how we want to proceed.
>
> Do we update/create our specs in Geronimo?
> Do we use the eclipse jars?
>
> thoughts
>
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Thu, Aug 15, 2019 at 5:53 AM David Blevins <da...@gmail.com>
> wrote:
>
>>> On Aug 14, 2019, at 2:05 AM, Alex The Rocker <al...@gmail.com>
>> wrote:
>>>
>>> Okay; for EDL I see it's compatible with Apache licensing, but
>>> strangely, JAXB license does not look like an EDL:
>>> https://github.com/eclipse-ee4j/jaxb-api/blob/2.3.2/LICENSE.md
>>>
>>> Am I mistaking or this is actually "cheesy" ?
>>
>> I pulled down the official text here and did a quick reformat to match it
>> to the LICENSE.md
>>
>> - https://www.eclipse.org/org/documents/edl-v10.php
>>
>> Sans the copyright statement, both came out identical in a diff, so we
>> appear good.
>>
>> We will want to make sure our NOTICE file does contain the copyright
>> statement, so that is a definitely good catch.
>>
>>
>> -David
>>
>>> Le mer. 14 août 2019 à 10:37, David Blevins <db...@tomitribe.com> a
>> écrit :
>>>>
>>>>> On Aug 14, 2019, at 1:23 AM, Alex The Rocker <al...@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 <da...@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 <da...@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
>>>>>>>
>>>>>>
>>>>
>>
>>
Re: Java EE 8 versions of APIs
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Trying to pull this message up in the list.
If we want to release Apache TomEE 8.0.0 before CodeOne, we need JavaMail,
Activation and some others.
For the others, I think I managed to get them up for vote and ready.
For Activation and JavaMail it's also an implementation so there is more
work involved and I am not sure we can get it done by CodeOne.
Of course it's not a good reason, but I still want to revive this topic so
we can decide all together how we want to proceed.
Do we update/create our specs in Geronimo?
Do we use the eclipse jars?
thoughts
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Thu, Aug 15, 2019 at 5:53 AM David Blevins <da...@gmail.com>
wrote:
> > On Aug 14, 2019, at 2:05 AM, Alex The Rocker <al...@gmail.com>
> wrote:
> >
> > Okay; for EDL I see it's compatible with Apache licensing, but
> > strangely, JAXB license does not look like an EDL:
> > https://github.com/eclipse-ee4j/jaxb-api/blob/2.3.2/LICENSE.md
> >
> > Am I mistaking or this is actually "cheesy" ?
>
> I pulled down the official text here and did a quick reformat to match it
> to the LICENSE.md
>
> - https://www.eclipse.org/org/documents/edl-v10.php
>
> Sans the copyright statement, both came out identical in a diff, so we
> appear good.
>
> We will want to make sure our NOTICE file does contain the copyright
> statement, so that is a definitely good catch.
>
>
> -David
>
> > Le mer. 14 août 2019 à 10:37, David Blevins <db...@tomitribe.com> a
> écrit :
> >>
> >>> On Aug 14, 2019, at 1:23 AM, Alex The Rocker <al...@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 <da...@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 <da...@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
> >>>>>
> >>>>
> >>
>
>
Re: Java EE 8 versions of APIs
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Trying to pull this message up in the list.
If we want to release Apache TomEE 8.0.0 before CodeOne, we need JavaMail,
Activation and some others.
For the others, I think I managed to get them up for vote and ready.
For Activation and JavaMail it's also an implementation so there is more
work involved and I am not sure we can get it done by CodeOne.
Of course it's not a good reason, but I still want to revive this topic so
we can decide all together how we want to proceed.
Do we update/create our specs in Geronimo?
Do we use the eclipse jars?
thoughts
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Thu, Aug 15, 2019 at 5:53 AM David Blevins <da...@gmail.com>
wrote:
> > On Aug 14, 2019, at 2:05 AM, Alex The Rocker <al...@gmail.com>
> wrote:
> >
> > Okay; for EDL I see it's compatible with Apache licensing, but
> > strangely, JAXB license does not look like an EDL:
> > https://github.com/eclipse-ee4j/jaxb-api/blob/2.3.2/LICENSE.md
> >
> > Am I mistaking or this is actually "cheesy" ?
>
> I pulled down the official text here and did a quick reformat to match it
> to the LICENSE.md
>
> - https://www.eclipse.org/org/documents/edl-v10.php
>
> Sans the copyright statement, both came out identical in a diff, so we
> appear good.
>
> We will want to make sure our NOTICE file does contain the copyright
> statement, so that is a definitely good catch.
>
>
> -David
>
> > Le mer. 14 août 2019 à 10:37, David Blevins <db...@tomitribe.com> a
> écrit :
> >>
> >>> On Aug 14, 2019, at 1:23 AM, Alex The Rocker <al...@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 <da...@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 <da...@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
> >>>>>
> >>>>
> >>
>
>
Re: Java EE 8 versions of APIs
Posted by David Blevins <da...@gmail.com>.
> On Aug 14, 2019, at 2:05 AM, Alex The Rocker <al...@gmail.com> wrote:
>
> Okay; for EDL I see it's compatible with Apache licensing, but
> strangely, JAXB license does not look like an EDL:
> https://github.com/eclipse-ee4j/jaxb-api/blob/2.3.2/LICENSE.md
>
> Am I mistaking or this is actually "cheesy" ?
I pulled down the official text here and did a quick reformat to match it to the LICENSE.md
- https://www.eclipse.org/org/documents/edl-v10.php
Sans the copyright statement, both came out identical in a diff, so we appear good.
We will want to make sure our NOTICE file does contain the copyright statement, so that is a definitely good catch.
-David
> Le mer. 14 août 2019 à 10:37, David Blevins <db...@tomitribe.com> a écrit :
>>
>>> On Aug 14, 2019, at 1:23 AM, Alex The Rocker <al...@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 <da...@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 <da...@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
>>>>>
>>>>
>>
Re: Java EE 8 versions of APIs
Posted by Alex The Rocker <al...@gmail.com>.
Okay; for EDL I see it's compatible with Apache licensing, but
strangely, JAXB license does not look like an EDL:
https://github.com/eclipse-ee4j/jaxb-api/blob/2.3.2/LICENSE.md
Am I mistaking or this is actually "cheesy" ?
Kind regads,
Alexandre
Le mer. 14 août 2019 à 10:37, David Blevins <db...@tomitribe.com> a écrit :
>
> > On Aug 14, 2019, at 1:23 AM, Alex The Rocker <al...@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 <da...@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 <da...@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
> >>>
> >>
>
Re: Java EE 8 versions of APIs
Posted by David Blevins <db...@tomitribe.com>.
> On Aug 14, 2019, at 1:23 AM, Alex The Rocker <al...@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 <da...@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 <da...@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
>>>
>>
Re: Java EE 8 versions of APIs
Posted by Alex The Rocker <al...@gmail.com>.
Hello,
How about JAXB which is not EPL but EDL 1.0 ?
(see https://github.com/eclipse-ee4j/jaxb-api/tree/2.3.2)
Kind regards,
Alexandre
Le mer. 14 août 2019 à 10:16, David Blevins <da...@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 <da...@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
> >
>
Re: Java EE 8 versions of APIs
Posted by David Blevins <da...@gmail.com>.
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 <da...@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
>
Re: Java EE 8 versions of APIs
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
David,
May I ask where you got all the versions please?
I was looking at this page and I see some mismatches.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Tue, Aug 13, 2019 at 9:10 AM David Blevins <da...@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
>
>