You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2020/12/10 11:39:51 UTC
[VOTE] Apache Tomcat migration tool for Jakarta EE
The proposed Apache Tomcat migration tool for Jakarta EE 0.1.0 is now
available for voting.
This is (potentially) the first release.
It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/jakartaee-migration/v0.1.0/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1291/
The tag is:
https://github.com/apache/tomcat-jakartaee-migration/tree/0.1.0
cbada3204bf9c43ca0cf481cd88c7521690b30a0
The proposed 0.1.0 release is:
[ ] -1: Broken. Do not release because...
[ ] +1: Acceptable. Go ahead and release.
Thanks,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
Posted by Martin Grigorov <mg...@apache.org>.
On Thu, Dec 10, 2020 at 1:39 PM Mark Thomas <ma...@apache.org> wrote:
> The proposed Apache Tomcat migration tool for Jakarta EE 0.1.0 is now
> available for voting.
>
> This is (potentially) the first release.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/jakartaee-migration/v0.1.0/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1291/
>
> The tag is:
> https://github.com/apache/tomcat-jakartaee-migration/tree/0.1.0
> cbada3204bf9c43ca0cf481cd88c7521690b30a0
>
> The proposed 0.1.0 release is:
>
> [ ] -1: Broken. Do not release because...
> [ X ] +1: Acceptable. Go ahead and release.
>
Regards,
Martin
>
> Thanks,
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 12/10/20 09:13, Mark Thomas wrote:
> On 10/12/2020 13:58, Christopher Schultz wrote:
>> Mark,
>>
>> On 12/10/20 06:39, Mark Thomas wrote:
>>> The proposed Apache Tomcat migration tool for Jakarta EE 0.1.0 is now
>>> available for voting.
>>>
>>> This is (potentially) the first release.
>>>
>>> It can be obtained from:
>>> https://dist.apache.org/repos/dist/dev/tomcat/jakartaee-migration/v0.1.0/
>>>
>>> The Maven staging repo is:
>>> https://repository.apache.org/content/repositories/orgapachetomcat-1291/
>>>
>>> The tag is:
>>> https://github.com/apache/tomcat-jakartaee-migration/tree/0.1.0
>>> cbada3204bf9c43ca0cf481cd88c7521690b30a0
>>>
>>> The proposed 0.1.0 release is:
>>>
>>> [ ] -1: Broken. Do not release because...
>>> [ ] +1: Acceptable. Go ahead and release.
>>
>> Do we even need (a) a release and (b) a VOTE?
>
> If we want a release, we MUST have a VOTE.
I was kind of thinking that if we didn't need (a) then (b) would be
unnecessary.
>> Since this is a developer tool and not a runtime library or anything
>> like that, maybe we can just say "YMMV, this is available any time you
>> want it"?
>
> It could be a runtime library. One possibility is that we integrate it
> into Tomcat 10 somehow so that if you try and deploy a Java EE 8 WAR it
> gets automatically converted to a Jakarta EE 9 WAR.
Witchcraft.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 12/10/20 11:14, Mark Thomas wrote:
> On 10/12/2020 14:52, Romain Manni-Bucau wrote:
>> Le jeu. 10 déc. 2020 à 15:49, Rémy Maucherat <re...@apache.org> a écrit :
>>> On Thu, Dec 10, 2020 at 3:13 PM Mark Thomas <ma...@apache.org> wrote:
>>>> On 10/12/2020 13:58, Christopher Schultz wrote:
>
> <snip/>
>
>>>>> Since this is a developer tool and not a runtime library or anything
>>>>> like that, maybe we can just say "YMMV, this is available any time you
>>>>> want it"?
>>>>
>>>> It could be a runtime library. One possibility is that we integrate it
>>>> into Tomcat 10 somehow so that if you try and deploy a Java EE 8 WAR it
>>>> gets automatically converted to a Jakarta EE 9 WAR.
>>>>
>>>
>>> It sounds doable with a special folder of the host (like a legacyAppBase),
>>> and it creates the result in the host's appBase. Like HostConfig.deployApps
>>> simply does this first, then moves down the usual deployments. I'm not sure
>>> that this is really useful though.
>>>
>>
>> Does it sound stupid to make the library a ClassFileTransformer added on
>> the webapp classloader? Sounds the most hurtless for users even if it will
>> adds a small overhead (and avoids a lot of file duplication which can be
>> harder to maintain at some point).
>
> It doesn't sound stupid at all. It was one of the options considered
> when we first started thinking about this. That was before we had the
> current implementation. With the experience of what the current
> implementation looks like we might want to revisit that discussion.
>
> My own thinking was to convert appBase/javaee.war to
> appBase/javaee##converted.war and let the parallel deployment code take
> care of deploying just the updated version.
>
> Doing conversion on the fly or at deployment/start-up time raises
> various issues that boil down to "How do we detect if conversion is
> required?" and "What are the performance impacts of doing so?". There
> are users who want to squeeze every last drop of performance out of the
> system so I think that leads to some sort of configuration option.
>
> Just thinking about that I thought of:
> - watch what classes are requested
> - as soon as javax.servlet.* (or one of the others is detected) stop the
> context, enable conversion and restart the context
>
> Then I thought that apps might try to determine if they are running on
> Java EE or Jakarta EE by trying to load classes. That could incorrectly
> trigger the conversion.
>
> Hmm. Anything apart from an explicitly user set flag starts to look
> potentially tricky for some use cases.
>
> Thoughts?
Read the WEB-INF/web.xml file for the web-app version?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 12/10/20 11:14, Mark Thomas wrote:
> [snip]
>
> Doing conversion on the fly or at deployment/start-up time raises
> various issues that boil down to "How do we detect if conversion is
> required?" and "What are the performance impacts of doing so?". There
> are users who want to squeeze every last drop of performance out of the
> system so I think that leads to some sort of configuration option.
This conversion is only applied at class-loading time, yes? Not on every
request, etc. I would imagine that a one-time hit for all classes
wouldn't be that big of a deal.
Tomcat could allow admins to either allow auto-conversion or not, for
the whole server. Or, maybe, for the whole <Host> or something.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le jeu. 10 déc. 2020 à 17:14, Mark Thomas <ma...@apache.org> a écrit :
> On 10/12/2020 14:52, Romain Manni-Bucau wrote:
> > Le jeu. 10 déc. 2020 à 15:49, Rémy Maucherat <re...@apache.org> a écrit :
> >> On Thu, Dec 10, 2020 at 3:13 PM Mark Thomas <ma...@apache.org> wrote:
> >>> On 10/12/2020 13:58, Christopher Schultz wrote:
>
> <snip/>
>
> >>>> Since this is a developer tool and not a runtime library or anything
> >>>> like that, maybe we can just say "YMMV, this is available any time you
> >>>> want it"?
> >>>
> >>> It could be a runtime library. One possibility is that we integrate it
> >>> into Tomcat 10 somehow so that if you try and deploy a Java EE 8 WAR it
> >>> gets automatically converted to a Jakarta EE 9 WAR.
> >>>
> >>
> >> It sounds doable with a special folder of the host (like a
> legacyAppBase),
> >> and it creates the result in the host's appBase. Like
> HostConfig.deployApps
> >> simply does this first, then moves down the usual deployments. I'm not
> sure
> >> that this is really useful though.
> >>
> >
> > Does it sound stupid to make the library a ClassFileTransformer added on
> > the webapp classloader? Sounds the most hurtless for users even if it
> will
> > adds a small overhead (and avoids a lot of file duplication which can be
> > harder to maintain at some point).
>
> It doesn't sound stupid at all. It was one of the options considered
> when we first started thinking about this. That was before we had the
> current implementation. With the experience of what the current
> implementation looks like we might want to revisit that discussion.
>
> My own thinking was to convert appBase/javaee.war to
> appBase/javaee##converted.war and let the parallel deployment code take
> care of deploying just the updated version.
>
Hmm, there are env the parallel deployment has pitfalls and it assumes the
not converted app would work no?
>
> Doing conversion on the fly or at deployment/start-up time raises
> various issues that boil down to "How do we detect if conversion is
> required?" and "What are the performance impacts of doing so?". There
> are users who want to squeeze every last drop of performance out of the
> system so I think that leads to some sort of configuration option.
>
Using a transformer it can be configured in context.xml so sounds "easy"
(requires to move to static constant to field instances but nothing crazy).
In terms of performances it is acceptable for such apps - don't forget we
often add javaagents doing potentially worse + JPA adds a transformer
already visiting all classes most of the time. That said a config with some
jar exclusions would be welcomed to only include a few jars.
>
> Just thinking about that I thought of:
> - watch what classes are requested
> - as soon as javax.servlet.* (or one of the others is detected) stop the
> context, enable conversion and restart the context
> Then I thought that apps might try to determine if they are running on
> Java EE or Jakarta EE by trying to load classes. That could incorrectly
> trigger the conversion.
>
> Hmm. Anything apart from an explicitly user set flag starts to look
> potentially tricky for some use cases.
>
> Thoughts?
>
That's why the transformer looked handy from my window: it is configurable
and easy - we must keep in mind these cases will be rare, the move to
jakarta is not for tomorrow IMHO and when it will come it will be all at
once per spec or not.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le ven. 11 déc. 2020 à 10:59, Rémy Maucherat <re...@apache.org> a écrit :
> On Thu, Dec 10, 2020 at 5:14 PM Mark Thomas <ma...@apache.org> wrote:
>
> > On 10/12/2020 14:52, Romain Manni-Bucau wrote:
> > > Le jeu. 10 déc. 2020 à 15:49, Rémy Maucherat <re...@apache.org> a
> écrit :
> > >> On Thu, Dec 10, 2020 at 3:13 PM Mark Thomas <ma...@apache.org> wrote:
> > >>> On 10/12/2020 13:58, Christopher Schultz wrote:
> >
> > <snip/>
> >
> > >>>> Since this is a developer tool and not a runtime library or anything
> > >>>> like that, maybe we can just say "YMMV, this is available any time
> you
> > >>>> want it"?
> > >>>
> > >>> It could be a runtime library. One possibility is that we integrate
> it
> > >>> into Tomcat 10 somehow so that if you try and deploy a Java EE 8 WAR
> it
> > >>> gets automatically converted to a Jakarta EE 9 WAR.
> > >>>
> > >>
> > >> It sounds doable with a special folder of the host (like a
> > legacyAppBase),
> > >> and it creates the result in the host's appBase. Like
> > HostConfig.deployApps
> > >> simply does this first, then moves down the usual deployments. I'm not
> > sure
> > >> that this is really useful though.
> > >>
> > >
> > > Does it sound stupid to make the library a ClassFileTransformer added
> on
> > > the webapp classloader? Sounds the most hurtless for users even if it
> > will
> > > adds a small overhead (and avoids a lot of file duplication which can
> be
> > > harder to maintain at some point).
> >
> > It doesn't sound stupid at all. It was one of the options considered
> > when we first started thinking about this. That was before we had the
> > current implementation. With the experience of what the current
> > implementation looks like we might want to revisit that discussion.
> >
> > My own thinking was to convert appBase/javaee.war to
> > appBase/javaee##converted.war and let the parallel deployment code take
> > care of deploying just the updated version.
> >
>
> I would think a separate appBase is preferable since it's easier, and
> there's nothing to detect. Everything gets processed by the conversion tool
> and that's it.
>
>
> >
> > Doing conversion on the fly or at deployment/start-up time raises
> > various issues that boil down to "How do we detect if conversion is
> > required?" and "What are the performance impacts of doing so?". There
> > are users who want to squeeze every last drop of performance out of the
> > system so I think that leads to some sort of configuration option.
> >
>
> Still not convinced by the classloading magic (the tool does a bit more
> than this) and AOT would be a problem.
>
Same applies for the different app base, basically AOT can only work if
done at build time so having a cllassfiletransfomer wired either in the
config of the classloader (once again, when tuned to ignored most of
commons etc by jar name and packages it will not slow down the app
significantly enough to not be worth it as proven by other transformers out
there - take tomee as an example ;)) and another wiring in a main - as of
today - where it enables to get a new binary, potentially integrated with
tomcat embedded/standalone (new Tomcat()) and then go through graalvm.
>
> Rémy
>
>
> >
> > Just thinking about that I thought of:
> > - watch what classes are requested
> > - as soon as javax.servlet.* (or one of the others is detected) stop the
> > context, enable conversion and restart the context
> >
> > Then I thought that apps might try to determine if they are running on
> > Java EE or Jakarta EE by trying to load classes. That could incorrectly
> > trigger the conversion.
> >
> > Hmm. Anything apart from an explicitly user set flag starts to look
> > potentially tricky for some use cases.
> >
> > Thoughts?
> >
> > Mark
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
Posted by Rémy Maucherat <re...@apache.org>.
On Thu, Dec 10, 2020 at 5:14 PM Mark Thomas <ma...@apache.org> wrote:
> On 10/12/2020 14:52, Romain Manni-Bucau wrote:
> > Le jeu. 10 déc. 2020 à 15:49, Rémy Maucherat <re...@apache.org> a écrit :
> >> On Thu, Dec 10, 2020 at 3:13 PM Mark Thomas <ma...@apache.org> wrote:
> >>> On 10/12/2020 13:58, Christopher Schultz wrote:
>
> <snip/>
>
> >>>> Since this is a developer tool and not a runtime library or anything
> >>>> like that, maybe we can just say "YMMV, this is available any time you
> >>>> want it"?
> >>>
> >>> It could be a runtime library. One possibility is that we integrate it
> >>> into Tomcat 10 somehow so that if you try and deploy a Java EE 8 WAR it
> >>> gets automatically converted to a Jakarta EE 9 WAR.
> >>>
> >>
> >> It sounds doable with a special folder of the host (like a
> legacyAppBase),
> >> and it creates the result in the host's appBase. Like
> HostConfig.deployApps
> >> simply does this first, then moves down the usual deployments. I'm not
> sure
> >> that this is really useful though.
> >>
> >
> > Does it sound stupid to make the library a ClassFileTransformer added on
> > the webapp classloader? Sounds the most hurtless for users even if it
> will
> > adds a small overhead (and avoids a lot of file duplication which can be
> > harder to maintain at some point).
>
> It doesn't sound stupid at all. It was one of the options considered
> when we first started thinking about this. That was before we had the
> current implementation. With the experience of what the current
> implementation looks like we might want to revisit that discussion.
>
> My own thinking was to convert appBase/javaee.war to
> appBase/javaee##converted.war and let the parallel deployment code take
> care of deploying just the updated version.
>
I would think a separate appBase is preferable since it's easier, and
there's nothing to detect. Everything gets processed by the conversion tool
and that's it.
>
> Doing conversion on the fly or at deployment/start-up time raises
> various issues that boil down to "How do we detect if conversion is
> required?" and "What are the performance impacts of doing so?". There
> are users who want to squeeze every last drop of performance out of the
> system so I think that leads to some sort of configuration option.
>
Still not convinced by the classloading magic (the tool does a bit more
than this) and AOT would be a problem.
Rémy
>
> Just thinking about that I thought of:
> - watch what classes are requested
> - as soon as javax.servlet.* (or one of the others is detected) stop the
> context, enable conversion and restart the context
>
> Then I thought that apps might try to determine if they are running on
> Java EE or Jakarta EE by trying to load classes. That could incorrectly
> trigger the conversion.
>
> Hmm. Anything apart from an explicitly user set flag starts to look
> potentially tricky for some use cases.
>
> Thoughts?
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
Posted by Mark Thomas <ma...@apache.org>.
On 10/12/2020 14:52, Romain Manni-Bucau wrote:
> Le jeu. 10 déc. 2020 à 15:49, Rémy Maucherat <re...@apache.org> a écrit :
>> On Thu, Dec 10, 2020 at 3:13 PM Mark Thomas <ma...@apache.org> wrote:
>>> On 10/12/2020 13:58, Christopher Schultz wrote:
<snip/>
>>>> Since this is a developer tool and not a runtime library or anything
>>>> like that, maybe we can just say "YMMV, this is available any time you
>>>> want it"?
>>>
>>> It could be a runtime library. One possibility is that we integrate it
>>> into Tomcat 10 somehow so that if you try and deploy a Java EE 8 WAR it
>>> gets automatically converted to a Jakarta EE 9 WAR.
>>>
>>
>> It sounds doable with a special folder of the host (like a legacyAppBase),
>> and it creates the result in the host's appBase. Like HostConfig.deployApps
>> simply does this first, then moves down the usual deployments. I'm not sure
>> that this is really useful though.
>>
>
> Does it sound stupid to make the library a ClassFileTransformer added on
> the webapp classloader? Sounds the most hurtless for users even if it will
> adds a small overhead (and avoids a lot of file duplication which can be
> harder to maintain at some point).
It doesn't sound stupid at all. It was one of the options considered
when we first started thinking about this. That was before we had the
current implementation. With the experience of what the current
implementation looks like we might want to revisit that discussion.
My own thinking was to convert appBase/javaee.war to
appBase/javaee##converted.war and let the parallel deployment code take
care of deploying just the updated version.
Doing conversion on the fly or at deployment/start-up time raises
various issues that boil down to "How do we detect if conversion is
required?" and "What are the performance impacts of doing so?". There
are users who want to squeeze every last drop of performance out of the
system so I think that leads to some sort of configuration option.
Just thinking about that I thought of:
- watch what classes are requested
- as soon as javax.servlet.* (or one of the others is detected) stop the
context, enable conversion and restart the context
Then I thought that apps might try to determine if they are running on
Java EE or Jakarta EE by trying to load classes. That could incorrectly
trigger the conversion.
Hmm. Anything apart from an explicitly user set flag starts to look
potentially tricky for some use cases.
Thoughts?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le jeu. 10 déc. 2020 à 15:49, Rémy Maucherat <re...@apache.org> a écrit :
> On Thu, Dec 10, 2020 at 3:13 PM Mark Thomas <ma...@apache.org> wrote:
>
> > On 10/12/2020 13:58, Christopher Schultz wrote:
> > > Mark,
> > >
> > > On 12/10/20 06:39, Mark Thomas wrote:
> > >> The proposed Apache Tomcat migration tool for Jakarta EE 0.1.0 is now
> > >> available for voting.
> > >>
> > >> This is (potentially) the first release.
> > >>
> > >> It can be obtained from:
> > >>
> >
> https://dist.apache.org/repos/dist/dev/tomcat/jakartaee-migration/v0.1.0/
> > >>
> > >> The Maven staging repo is:
> > >>
> > https://repository.apache.org/content/repositories/orgapachetomcat-1291/
> > >>
> > >> The tag is:
> > >> https://github.com/apache/tomcat-jakartaee-migration/tree/0.1.0
> > >> cbada3204bf9c43ca0cf481cd88c7521690b30a0
> > >>
> > >> The proposed 0.1.0 release is:
> > >>
> > >> [ ] -1: Broken. Do not release because...
> > >> [ ] +1: Acceptable. Go ahead and release.
> > >
> > > Do we even need (a) a release and (b) a VOTE?
> >
> > If we want a release, we MUST have a VOTE.
> >
> > > I once heard Ross say that there was an ASP project (Subversion?) that
> > > never had votes; they only had releases. That seemed to cut-down on the
> > > red-tape required to get things out into the world. I can't find a
> > > reference for that, now.
> >
> > That doesn't sound right. From memory, Subversion doesn't have votes for
> > new committers but PMC membership and releases require a VOTE.
> >
> > > Since this is a developer tool and not a runtime library or anything
> > > like that, maybe we can just say "YMMV, this is available any time you
> > > want it"?
> >
> > It could be a runtime library. One possibility is that we integrate it
> > into Tomcat 10 somehow so that if you try and deploy a Java EE 8 WAR it
> > gets automatically converted to a Jakarta EE 9 WAR.
> >
>
> It sounds doable with a special folder of the host (like a legacyAppBase),
> and it creates the result in the host's appBase. Like HostConfig.deployApps
> simply does this first, then moves down the usual deployments. I'm not sure
> that this is really useful though.
>
Does it sound stupid to make the library a ClassFileTransformer added on
the webapp classloader? Sounds the most hurtless for users even if it will
adds a small overhead (and avoids a lot of file duplication which can be
harder to maintain at some point).
>
> Rémy
>
>
> >
> > > That said, I have no objections whatsoever with holding a vote. I am an
> > > unsigned "0" on the vote itself; I have not even downloaded the source
> > > let alone attempted to migrate a project using it.
> >
> > Fair enough.
> >
> > I think the naming of some of the artefacts could be improved. As this
> > is the first ever release I'm leaning towards cancelling / voting
> > against to get them fixed so all releases will (hopefully) use a
> > consistent naming convention rather it changing after the first release.
> >
> > Mark
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
Posted by Rémy Maucherat <re...@apache.org>.
On Thu, Dec 10, 2020 at 3:13 PM Mark Thomas <ma...@apache.org> wrote:
> On 10/12/2020 13:58, Christopher Schultz wrote:
> > Mark,
> >
> > On 12/10/20 06:39, Mark Thomas wrote:
> >> The proposed Apache Tomcat migration tool for Jakarta EE 0.1.0 is now
> >> available for voting.
> >>
> >> This is (potentially) the first release.
> >>
> >> It can be obtained from:
> >>
> https://dist.apache.org/repos/dist/dev/tomcat/jakartaee-migration/v0.1.0/
> >>
> >> The Maven staging repo is:
> >>
> https://repository.apache.org/content/repositories/orgapachetomcat-1291/
> >>
> >> The tag is:
> >> https://github.com/apache/tomcat-jakartaee-migration/tree/0.1.0
> >> cbada3204bf9c43ca0cf481cd88c7521690b30a0
> >>
> >> The proposed 0.1.0 release is:
> >>
> >> [ ] -1: Broken. Do not release because...
> >> [ ] +1: Acceptable. Go ahead and release.
> >
> > Do we even need (a) a release and (b) a VOTE?
>
> If we want a release, we MUST have a VOTE.
>
> > I once heard Ross say that there was an ASP project (Subversion?) that
> > never had votes; they only had releases. That seemed to cut-down on the
> > red-tape required to get things out into the world. I can't find a
> > reference for that, now.
>
> That doesn't sound right. From memory, Subversion doesn't have votes for
> new committers but PMC membership and releases require a VOTE.
>
> > Since this is a developer tool and not a runtime library or anything
> > like that, maybe we can just say "YMMV, this is available any time you
> > want it"?
>
> It could be a runtime library. One possibility is that we integrate it
> into Tomcat 10 somehow so that if you try and deploy a Java EE 8 WAR it
> gets automatically converted to a Jakarta EE 9 WAR.
>
It sounds doable with a special folder of the host (like a legacyAppBase),
and it creates the result in the host's appBase. Like HostConfig.deployApps
simply does this first, then moves down the usual deployments. I'm not sure
that this is really useful though.
Rémy
>
> > That said, I have no objections whatsoever with holding a vote. I am an
> > unsigned "0" on the vote itself; I have not even downloaded the source
> > let alone attempted to migrate a project using it.
>
> Fair enough.
>
> I think the naming of some of the artefacts could be improved. As this
> is the first ever release I'm leaning towards cancelling / voting
> against to get them fixed so all releases will (hopefully) use a
> consistent naming convention rather it changing after the first release.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
Posted by Mark Thomas <ma...@apache.org>.
On 10/12/2020 13:58, Christopher Schultz wrote:
> Mark,
>
> On 12/10/20 06:39, Mark Thomas wrote:
>> The proposed Apache Tomcat migration tool for Jakarta EE 0.1.0 is now
>> available for voting.
>>
>> This is (potentially) the first release.
>>
>> It can be obtained from:
>> https://dist.apache.org/repos/dist/dev/tomcat/jakartaee-migration/v0.1.0/
>>
>> The Maven staging repo is:
>> https://repository.apache.org/content/repositories/orgapachetomcat-1291/
>>
>> The tag is:
>> https://github.com/apache/tomcat-jakartaee-migration/tree/0.1.0
>> cbada3204bf9c43ca0cf481cd88c7521690b30a0
>>
>> The proposed 0.1.0 release is:
>>
>> [ ] -1: Broken. Do not release because...
>> [ ] +1: Acceptable. Go ahead and release.
>
> Do we even need (a) a release and (b) a VOTE?
If we want a release, we MUST have a VOTE.
> I once heard Ross say that there was an ASP project (Subversion?) that
> never had votes; they only had releases. That seemed to cut-down on the
> red-tape required to get things out into the world. I can't find a
> reference for that, now.
That doesn't sound right. From memory, Subversion doesn't have votes for
new committers but PMC membership and releases require a VOTE.
> Since this is a developer tool and not a runtime library or anything
> like that, maybe we can just say "YMMV, this is available any time you
> want it"?
It could be a runtime library. One possibility is that we integrate it
into Tomcat 10 somehow so that if you try and deploy a Java EE 8 WAR it
gets automatically converted to a Jakarta EE 9 WAR.
> That said, I have no objections whatsoever with holding a vote. I am an
> unsigned "0" on the vote itself; I have not even downloaded the source
> let alone attempted to migrate a project using it.
Fair enough.
I think the naming of some of the artefacts could be improved. As this
is the first ever release I'm leaning towards cancelling / voting
against to get them fixed so all releases will (hopefully) use a
consistent naming convention rather it changing after the first release.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
Posted by Igal Sapir <is...@apache.org>.
On Thu, Dec 10, 2020 at 11:45 PM Mark Thomas <ma...@apache.org> wrote:
> On 11/12/2020 06:58, Martin Grigorov wrote:
> > On Thu, Dec 10, 2020 at 11:50 PM Igal Sapir <is...@apache.org> wrote:
> >
> >> On Thu, Dec 10, 2020 at 5:58 AM Christopher Schultz <
> >> chris@christopherschultz.net> wrote:
> >>
> >>> Mark,
> >>>
> >>> On 12/10/20 06:39, Mark Thomas wrote:
> >>>> The proposed Apache Tomcat migration tool for Jakarta EE 0.1.0 is now
> >>>> available for voting.
> >>>>
> >>>> This is (potentially) the first release.
> >>>>
> >>>> It can be obtained from:
> >>>>
> >>>
> >>
> https://dist.apache.org/repos/dist/dev/tomcat/jakartaee-migration/v0.1.0/
> >>>>
> >>>> The Maven staging repo is:
> >>>>
> >>
> https://repository.apache.org/content/repositories/orgapachetomcat-1291/
> >>>>
> >>>> The tag is:
> >>>> https://github.com/apache/tomcat-jakartaee-migration/tree/0.1.0
> >>>> cbada3204bf9c43ca0cf481cd88c7521690b30a0
> >>>>
> >>>> The proposed 0.1.0 release is:
> >>>>
> >>>> [ ] -1: Broken. Do not release because...
> >>>> [ ] +1: Acceptable. Go ahead and release.
> >>>
> >>> Do we even need (a) a release and (b) a VOTE?
> >>>
> >>> I once heard Ross say that there was an ASP project (Subversion?) that
> >>> never had votes; they only had releases. That seemed to cut-down on the
> >>> red-tape required to get things out into the world. I can't find a
> >>> reference for that, now.
> >>>
> >>> Since this is a developer tool and not a runtime library or anything
> >>> like that, maybe we can just say "YMMV, this is available any time you
> >>> want it"?
> >>>
> >>> That said, I have no objections whatsoever with holding a vote. I am an
> >>> unsigned "0" on the vote itself; I have not even downloaded the source
> >>> let alone attempted to migrate a project using it.
> >>>
> >>
> >> I'm a +0 on this one. Like Chris, I also did not even download nor
> tested
> >> that tool.
> >>
> >> Did we use that tool to migrate the Tomcat examples? Were they all
> >> migrated successfully?
> >>
> >
> > No. The examples were migrated manually, i.e. their source code was
> > migrated.
> > The tool migrates binary files (.war,.jar, .class). It is useful when
> your
> > application depends on third party libraries which still use javax.**
>
> Martin is correct, the examples were migrated using a package rename in
> the IDE.
>
> The JSTL JARs (used by the examples webapp) were migrated with this tool.
>
Thank you both for clarifying. My question just shows why at this point I
should remain a +0 on this one.
Igal
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
Posted by Mark Thomas <ma...@apache.org>.
On 11/12/2020 06:58, Martin Grigorov wrote:
> On Thu, Dec 10, 2020 at 11:50 PM Igal Sapir <is...@apache.org> wrote:
>
>> On Thu, Dec 10, 2020 at 5:58 AM Christopher Schultz <
>> chris@christopherschultz.net> wrote:
>>
>>> Mark,
>>>
>>> On 12/10/20 06:39, Mark Thomas wrote:
>>>> The proposed Apache Tomcat migration tool for Jakarta EE 0.1.0 is now
>>>> available for voting.
>>>>
>>>> This is (potentially) the first release.
>>>>
>>>> It can be obtained from:
>>>>
>>>
>> https://dist.apache.org/repos/dist/dev/tomcat/jakartaee-migration/v0.1.0/
>>>>
>>>> The Maven staging repo is:
>>>>
>> https://repository.apache.org/content/repositories/orgapachetomcat-1291/
>>>>
>>>> The tag is:
>>>> https://github.com/apache/tomcat-jakartaee-migration/tree/0.1.0
>>>> cbada3204bf9c43ca0cf481cd88c7521690b30a0
>>>>
>>>> The proposed 0.1.0 release is:
>>>>
>>>> [ ] -1: Broken. Do not release because...
>>>> [ ] +1: Acceptable. Go ahead and release.
>>>
>>> Do we even need (a) a release and (b) a VOTE?
>>>
>>> I once heard Ross say that there was an ASP project (Subversion?) that
>>> never had votes; they only had releases. That seemed to cut-down on the
>>> red-tape required to get things out into the world. I can't find a
>>> reference for that, now.
>>>
>>> Since this is a developer tool and not a runtime library or anything
>>> like that, maybe we can just say "YMMV, this is available any time you
>>> want it"?
>>>
>>> That said, I have no objections whatsoever with holding a vote. I am an
>>> unsigned "0" on the vote itself; I have not even downloaded the source
>>> let alone attempted to migrate a project using it.
>>>
>>
>> I'm a +0 on this one. Like Chris, I also did not even download nor tested
>> that tool.
>>
>> Did we use that tool to migrate the Tomcat examples? Were they all
>> migrated successfully?
>>
>
> No. The examples were migrated manually, i.e. their source code was
> migrated.
> The tool migrates binary files (.war,.jar, .class). It is useful when your
> application depends on third party libraries which still use javax.**
Martin is correct, the examples were migrated using a package rename in
the IDE.
The JSTL JARs (used by the examples webapp) were migrated with this tool.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
Posted by Martin Grigorov <mg...@apache.org>.
On Thu, Dec 10, 2020 at 11:50 PM Igal Sapir <is...@apache.org> wrote:
> On Thu, Dec 10, 2020 at 5:58 AM Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
> > Mark,
> >
> > On 12/10/20 06:39, Mark Thomas wrote:
> > > The proposed Apache Tomcat migration tool for Jakarta EE 0.1.0 is now
> > > available for voting.
> > >
> > > This is (potentially) the first release.
> > >
> > > It can be obtained from:
> > >
> >
> https://dist.apache.org/repos/dist/dev/tomcat/jakartaee-migration/v0.1.0/
> > >
> > > The Maven staging repo is:
> > >
> https://repository.apache.org/content/repositories/orgapachetomcat-1291/
> > >
> > > The tag is:
> > > https://github.com/apache/tomcat-jakartaee-migration/tree/0.1.0
> > > cbada3204bf9c43ca0cf481cd88c7521690b30a0
> > >
> > > The proposed 0.1.0 release is:
> > >
> > > [ ] -1: Broken. Do not release because...
> > > [ ] +1: Acceptable. Go ahead and release.
> >
> > Do we even need (a) a release and (b) a VOTE?
> >
> > I once heard Ross say that there was an ASP project (Subversion?) that
> > never had votes; they only had releases. That seemed to cut-down on the
> > red-tape required to get things out into the world. I can't find a
> > reference for that, now.
> >
> > Since this is a developer tool and not a runtime library or anything
> > like that, maybe we can just say "YMMV, this is available any time you
> > want it"?
> >
> > That said, I have no objections whatsoever with holding a vote. I am an
> > unsigned "0" on the vote itself; I have not even downloaded the source
> > let alone attempted to migrate a project using it.
> >
>
> I'm a +0 on this one. Like Chris, I also did not even download nor tested
> that tool.
>
> Did we use that tool to migrate the Tomcat examples? Were they all
> migrated successfully?
>
No. The examples were migrated manually, i.e. their source code was
migrated.
The tool migrates binary files (.war,.jar, .class). It is useful when your
application depends on third party libraries which still use javax.**
Martin
>
> Igal
>
>
>
> >
> > -chris
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
Posted by Igal Sapir <is...@apache.org>.
On Thu, Dec 10, 2020 at 5:58 AM Christopher Schultz <
chris@christopherschultz.net> wrote:
> Mark,
>
> On 12/10/20 06:39, Mark Thomas wrote:
> > The proposed Apache Tomcat migration tool for Jakarta EE 0.1.0 is now
> > available for voting.
> >
> > This is (potentially) the first release.
> >
> > It can be obtained from:
> >
> https://dist.apache.org/repos/dist/dev/tomcat/jakartaee-migration/v0.1.0/
> >
> > The Maven staging repo is:
> > https://repository.apache.org/content/repositories/orgapachetomcat-1291/
> >
> > The tag is:
> > https://github.com/apache/tomcat-jakartaee-migration/tree/0.1.0
> > cbada3204bf9c43ca0cf481cd88c7521690b30a0
> >
> > The proposed 0.1.0 release is:
> >
> > [ ] -1: Broken. Do not release because...
> > [ ] +1: Acceptable. Go ahead and release.
>
> Do we even need (a) a release and (b) a VOTE?
>
> I once heard Ross say that there was an ASP project (Subversion?) that
> never had votes; they only had releases. That seemed to cut-down on the
> red-tape required to get things out into the world. I can't find a
> reference for that, now.
>
> Since this is a developer tool and not a runtime library or anything
> like that, maybe we can just say "YMMV, this is available any time you
> want it"?
>
> That said, I have no objections whatsoever with holding a vote. I am an
> unsigned "0" on the vote itself; I have not even downloaded the source
> let alone attempted to migrate a project using it.
>
I'm a +0 on this one. Like Chris, I also did not even download nor tested
that tool.
Did we use that tool to migrate the Tomcat examples? Were they all
migrated successfully?
Igal
>
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 12/10/20 06:39, Mark Thomas wrote:
> The proposed Apache Tomcat migration tool for Jakarta EE 0.1.0 is now
> available for voting.
>
> This is (potentially) the first release.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/jakartaee-migration/v0.1.0/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1291/
>
> The tag is:
> https://github.com/apache/tomcat-jakartaee-migration/tree/0.1.0
> cbada3204bf9c43ca0cf481cd88c7521690b30a0
>
> The proposed 0.1.0 release is:
>
> [ ] -1: Broken. Do not release because...
> [ ] +1: Acceptable. Go ahead and release.
Do we even need (a) a release and (b) a VOTE?
I once heard Ross say that there was an ASP project (Subversion?) that
never had votes; they only had releases. That seemed to cut-down on the
red-tape required to get things out into the world. I can't find a
reference for that, now.
Since this is a developer tool and not a runtime library or anything
like that, maybe we can just say "YMMV, this is available any time you
want it"?
That said, I have no objections whatsoever with holding a vote. I am an
unsigned "0" on the vote itself; I have not even downloaded the source
let alone attempted to migrate a project using it.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
Posted by Rémy Maucherat <re...@apache.org>.
On Thu, Dec 10, 2020 at 12:39 PM Mark Thomas <ma...@apache.org> wrote:
> The proposed Apache Tomcat migration tool for Jakarta EE 0.1.0 is now
> available for voting.
>
> This is (potentially) the first release.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/jakartaee-migration/v0.1.0/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1291/
>
> The tag is:
> https://github.com/apache/tomcat-jakartaee-migration/tree/0.1.0
> cbada3204bf9c43ca0cf481cd88c7521690b30a0
>
> The proposed 0.1.0 release is:
>
> [ ] -1: Broken. Do not release because...
> [X] +1: Acceptable. Go ahead and release.
>
> Very good IMO for a first release.
Rémy
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 10/12/2020 à 12:39, Mark Thomas a écrit :
> The proposed 0.1.0 release is:
>
> [ ] -1: Broken. Do not release because...
> [X] +1: Acceptable. Go ahead and release.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[VOTE][RESULT] Apache Tomcat migration tool for Jakarta EE 0.1.0
Posted by Mark Thomas <ma...@apache.org>.
The following votes were cast:
Binding:
+1 remm, ebourg, mgrigorov
0: schultz, isapir
No other votes were cast.
Since this is the first release of this component rather more work that
usual is required to updated the website. I might not get to that until
early January. I'll get the release out to Maven central and to the
mirrors shortly but I'll hold off on the official announcement until the
web site is ready.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org