Re: javax -> jakarta

[Mark Struberg]

Hi Cesar!

EPLv2 is basically LGPL but allows sub-licensing.

https://www.eclipse.org/legal/epl-2.0/faq.php#h.tokw8l7u084o 


"that means that if you have modified EPL-2.0 licensed source code and you 
distribute that code or binaries built from that code outside y. our company, 
you must make the source code available under the EPL-2.0."

See the license text for the full details:
https://www.eclipse.org/legal/epl-2.0/ 

I'd say that makes not much problems to us, but 

a.) whenever we package some binary which includes some EPLv2 artifact 
(tomee.zip) we need to properly attribute this.
b.) whenever we change or repackage EPLv2 source code (javaee-api) we need to 
make those parts available.

b is not tragic for us but all DOWNSTREAM users also need to do it IF they 
change the source code. 

Nothing tragic, but we need to comply to it. Probably well worth it. That's why 
I started the discussion.
And of course there's the OSGi thingy...

LieGrue,
strub



> Am 21.04.2020 um 17:01 schrieb Cesar Hernandez :
> 
> Hi Mark,
> 
> I'm didn't notice the licensing aspect you mention on b).
> What would be the work need it, for example in java-ee-api, to add the
> reciprocity you are mentioning?
> Just a license header change?
> 
> El dom., 19 abr. 2020 a las 3:34, Mark Struberg ( >)
> escribió:
> 
>> Hi folks!
>> 
>> While moving over to jakartaee we need to discuss which specs we want to
>> include in our maven builds.
>> 
>> We have a jakarta.* branch for the geronimo specs since a year.
>> http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ 
>>  <
>> http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ 
>> >
>> In fact, this was the first ever attempt whether moving the packages was
>> possible at all.
>> 
>> The other possible option would be to use the now existing official
>> packages from eclipse.
>> There are a few issues with those though.
>> 
>> a.) they are not OSGi capable. Not a bit deal for most, but there are
>> projects like karaf, Camel, etc which make use of OSGi.
>> I have not checked whether Eclipse has plans to add this feature to their
>> official artifacts. Anyone?
>> 
>> b.) The EPLv2 is a weak copyleft license. So it still requires some
>> reciprocity. ALv2 does not.
>> https://apache.org/legal/resolved.html <
>> https://apache.org/legal/resolved.html 
>> >
>> See section 3 in https://www.eclipse.org/legal/epl-2.0/ 
>> 
>> I think this would be fine as long as we make sure not to modify it. Our
>> java-ee-api super-jar might be such a case.
>> 
>> c.) Software Maintenance
>> With maintaining our own versions of the specs we can rather quickly test
>> out new features currently under discussion. This would be harder if we do
>> not maintain those sources ourselves.
>> Of course this also has downsides: we _need_ to maintain it and we need to
>> make sure it finally is binary compatible. Checking signatures and stuff...
>> 
>> For the record: Apache Tomcat still maintains all the apis for themselves
>> as well:
>> https://github.com/apache/tomcat/tree/master/java/jakarta
> 
> 
> 
> -- 
> Atentamente:
> César Hernández.

Re: Javax -> Jakarta rename

[Gilberto Caetano de Andrade]

On 2020/04/21 19:00:54, Gilberto Caetano de Andrade  
wrote: 
> Hi,
> 
> On 2020/04/16 13:23:26, Jonathan Gallimore  
> wrote: 
> > Hi All,
> > 
> > You may be aware that as part of the Jakarta EE 9 release later this year,
> > the various APIs provided in TomEE will be shifting from javax namespaces
> > to jakarta.
> > 
> > I'm currently researching the use of the Eclipse Transformer project (
> > https://projects.eclipse.org/projects/technology.transformer) to translate
> > both the TomEE server itself, and the source code for the examples.
> > 
> > So far, I have a converted javaee-api.jar, and a Jakarta-ized version of
> > TomEE that boots. There's *lots* that doesn't work at the present moment,
> > but I'm expecting to have the moviefun example running fairly soon - that
> > covers EJB, Servlets, JSPs, JPA. The REST version of the sample also covers
> > JAX-RS too.
> > 
> > I'm aware that there's also a migration tool that Tomcat have been working
> > on too, and will be looking at.
> > 
> > We ought to have some discussion about the approach here - in my mind there
> > are some high-level goals:
> > 
> > * Try and maintain a single codebase for javax and jakarta. 
> I my opinion is the worst idea. TomEE has had a history of spread projects 
> and this way you will obligated to stay with all of them. 
> 
> >It's tempting to fork master and embark on a massive renaming exercise. 
> 
> I would like to suggest another way for the TomEE project with this great 
> opportunity (please consider my words, I'm not expert in lib, just user here 
> ok!)
> Reading about Jakarta EE 9 I've discovered that the goal is JDK11 -> JAKARTA9 
> and of course the rename thing. But the main message is you do not need be 
> backwards compatible (you can if you wish).
> My suggestion is to follow the train like JDK11 -> JAKARTA9-> TomEE9
> The TomEE9 branch (I suggest it be the master one) will suffer the rename 
> task and prune the legacy project/dependency one
> 
> Hardly I will upgrade or port my ee projects to jakata9 - I'm having a hard 
> time to update to jdk11 :)
> I prefer stay with JDK8->TomEE8!
> 
I mean I prefer stay with JDK8->JAKARTA8->TomEE8 for my current projects. For 
the new ones I prefer  JDK11 -> JAKARTA9-> TomEE9.

Sorry!

> Regards,
> Gilberto
> 
> PS.: Thank you all for great project
> 
> >That's complex as we'd need to do that for various dependencies as well, who 
> >may
> > also have other branches and timelines. Having two codebases also means
> > that any changes need to be applied twice, and with renamed packages, its
> > unlikely the git merging or cherry-picking will work.
> > 
> > * Be backwards compatible - One goal I had in my mined, is that if you have
> > an application that uses javax, you'd probably like to be able to run it on
> > a new Jakarta EE server. There are some options here - I quite like the
> > idea of running the Transformer as a javaagent, so any applications
> > deployed using the old namespaces are converted on the fly at the bytecode
> > level.
> > 
> > * Tooling - I wonder what tooling we could potentially provide? One thought
> > I had was a Maven plugin that can transform a war/ear file for you as part
> > of a build.
> > 
> > Anyway, just wanted to give a heads-up on the research. Any thoughts /
> > discussions / questions are encouraged.
> > 
> > Jon
> > 
> 

Re: Javax -> Jakarta rename

[Gilberto Caetano de Andrade]

Hi,

On 2020/04/16 13:23:26, Jonathan Gallimore  
wrote: 
> Hi All,
> 
> You may be aware that as part of the Jakarta EE 9 release later this year,
> the various APIs provided in TomEE will be shifting from javax namespaces
> to jakarta.
> 
> I'm currently researching the use of the Eclipse Transformer project (
> https://projects.eclipse.org/projects/technology.transformer) to translate
> both the TomEE server itself, and the source code for the examples.
> 
> So far, I have a converted javaee-api.jar, and a Jakarta-ized version of
> TomEE that boots. There's *lots* that doesn't work at the present moment,
> but I'm expecting to have the moviefun example running fairly soon - that
> covers EJB, Servlets, JSPs, JPA. The REST version of the sample also covers
> JAX-RS too.
> 
> I'm aware that there's also a migration tool that Tomcat have been working
> on too, and will be looking at.
> 
> We ought to have some discussion about the approach here - in my mind there
> are some high-level goals:
> 
> * Try and maintain a single codebase for javax and jakarta. 
I my opinion is the worst idea. TomEE has had a history of spread projects and 
this way you will obligated to stay with all of them. 

>It's tempting to fork master and embark on a massive renaming exercise. 

I would like to suggest another way for the TomEE project with this great 
opportunity (please consider my words, I'm not expert in lib, just user here 
ok!)
Reading about Jakarta EE 9 I've discovered that the goal is JDK11 -> JAKARTA9 
and of course the rename thing. But the main message is you do not need be 
backwards compatible (you can if you wish).
My suggestion is to follow the train like JDK11 -> JAKARTA9-> TomEE9
The TomEE9 branch (I suggest it be the master one) will suffer the rename task 
and prune the legacy project/dependency one

Hardly I will upgrade or port my ee projects to jakata9 - I'm having a hard 
time to update to jdk11 :)
I prefer stay with JDK8->TomEE8!

Regards,
Gilberto

PS.: Thank you all for great project

>That's complex as we'd need to do that for various dependencies as well, who 
>may
> also have other branches and timelines. Having two codebases also means
> that any changes need to be applied twice, and with renamed packages, its
> unlikely the git merging or cherry-picking will work.
> 
> * Be backwards compatible - One goal I had in my mined, is that if you have
> an application that uses javax, you'd probably like to be able to run it on
> a new Jakarta EE server. There are some options here - I quite like the
> idea of running the Transformer as a javaagent, so any applications
> deployed using the old namespaces are converted on the fly at the bytecode
> level.
> 
> * Tooling - I wonder what tooling we could potentially provide? One thought
> I had was a Maven plugin that can transform a war/ear file for you as part
> of a build.
> 
> Anyway, just wanted to give a heads-up on the research. Any thoughts /
> discussions / questions are encouraged.
> 
> Jon
> 

Re: javax -> jakarta

[Cesar Hernandez]

Hi Mark,

I'm didn't notice the licensing aspect you mention on b).
What would be the work need it, for example in java-ee-api, to add the
reciprocity you are mentioning?
Just a license header change?

El dom., 19 abr. 2020 a las 3:34, Mark Struberg ()
escribió:

> Hi folks!
>
> While moving over to jakartaee we need to discuss which specs we want to
> include in our maven builds.
>
> We have a jakarta.* branch for the geronimo specs since a year.
> http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ <
> http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/>
> In fact, this was the first ever attempt whether moving the packages was
> possible at all.
>
> The other possible option would be to use the now existing official
> packages from eclipse.
> There are a few issues with those though.
>
> a.) they are not OSGi capable. Not a bit deal for most, but there are
> projects like karaf, Camel, etc which make use of OSGi.
> I have not checked whether Eclipse has plans to add this feature to their
> official artifacts. Anyone?
>
> b.) The EPLv2 is a weak copyleft license. So it still requires some
> reciprocity. ALv2 does not.
> https://apache.org/legal/resolved.html <
> https://apache.org/legal/resolved.html>
> See section 3 in https://www.eclipse.org/legal/epl-2.0/
> I think this would be fine as long as we make sure not to modify it. Our
> java-ee-api super-jar might be such a case.
>
> c.) Software Maintenance
> With maintaining our own versions of the specs we can rather quickly test
> out new features currently under discussion. This would be harder if we do
> not maintain those sources ourselves.
> Of course this also has downsides: we _need_ to maintain it and we need to
> make sure it finally is binary compatible. Checking signatures and stuff...
>
> For the record: Apache Tomcat still maintains all the apis for themselves
> as well:
> https://github.com/apache/tomcat/tree/master/java/jakarta



-- 
Atentamente:
César Hernández.