Hi everyone! I hope all is well with you all!!
Jonathan, I see the project with few resources (Sorry for not helping much
here!) and a lot sub-project to take care - do you understand?
So, I would focus in, for example, build and certify tomEE on the Jakarta Web
Profile (or minor one if the jakarta project create one)
I known my vision is simplistic, but I think and see that the project would
gain more engagement and resources with fewer sub-project(JSR and now JESP[1]),
taking the direction of micronaut, spring-boot, dropwizard, etc.
Regards,
Gilberto
[1] https://jakarta.ee/about/jesp/
On 2020/04/28 11:43:57, Jonathan Gallimore
wrote:
> Hi Gilberto
>
> Thanks for your post! I appreciate the you taking the time to post and give
> your views.
>
> > 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.
>
> Can you elaborate on what you mean with "this way you will [be] obligated
> to stay with all of them"?
>
> > Reading about Jakarta EE 9 I've discovered that the goal is JDK11 ->
> JAKARTA9 and of course the rename thing.
>
> That's not quite right. Java/JDK 8 is still the base for Jakarta EE 9. The
> key difference between EE8 and EE9 is the package rename. You can use JDK
> 11 with TomEE 8 today, and if you find something doesn't work, that is a
> bug, and we'd want to fix it. We'll be targeting JDK 8 and 11 for Jakarta
> EE 9.
>
> > But the main message is you do not need be backwards compatible (you can
> if you wish).
>
> I'd call this out as the key part of your post. You're correct,
> implementations do *not* need to be backwards compatible with Jakarta EE 8,
> and they do not need to allow or be forgiving of any code that references
> the old javax packages. The question we need to answer as a community is:
> do we want to allow backwards compatibility?
>
> I'll very clearly state my own personal view is "yes", for the following
> reasons:
>
> 1. One way or another, we will need to support EE 8 for a long time. TomEE
> has a wide range of users, some will find the migration easy, and some will
> take multiple years to migrate their applications. One option is to run
> parallel branches for EE8 and EE9, but it is very unlikely that changes
> will be mergeable across the two. We already have 3 active branches, and 4
> flavours of TomEE for each branch. Picking the one you want is already a
> challenge.
>
> 2. One of the principals of TomEE is for the server to bend to fit the
> user, not the other way around. Want to bring deployment descriptors from
> another app server? No problem, we'll try and parse them and do the right
> thing. I think breaking backwards compatibility would not be particularly
> friendly to our consumers.
>
> 3. All of TomEE's competitors are likely to have backwards compatibility.
>
> I'd be interesting in hearing if others are in favour of dropping backwards
> compatibility.
>
> I'm happy to look at other options to the Transformer, of course, but I
> think it merits investigation, as it potentially gives us some quick wins.
>
> Jon
>
>
>
> On Tue, Apr 21, 2020 at 8:00 PM Gilberto Caetano de Andrade <
> gilbert...@gmail.com> 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
