Re: conversion tool 9 to 10

Rob,

On 1/13/26 12:04 PM, Rob Sargent wrote:
> On 1/13/26 06:59, Christopher Schultz wrote:
>> Mark and Rob,
>>
> 
> Thank you Chris and Mark,
> 
> One more question, below.  Or five.  And maybe a feature request.
>> On 1/13/26 3:52 AM, Mark Thomas wrote:
>>> On 12/01/2026 19:12, Rob Sargent wrote:
>>>> Hello again, it's been a minute
>>>>
>>>> I may need to upgrade my embedded tomcat application and have a 
>>>> couple of questions.
>>>>
>>>> Other than the obvious javax.<servlety-stuff> -> jakarta 
>>>> substitutions what else does it change?
>>>
>>> Exactly which Java EE -> Jakarta EE conversion it does depend on 
>>> which profile you pick. Options are:
>>>
>>> - just Servlet
>>> - all the APIs Tomcat provides
>>> - all the Java EE specs
>>>
>>> There is also a Jakarta EE to Java EE profile if you need to down 
>>> convert.
>>>
>>> Other things converted:
>>>
>>> - OSGi dependencies in MANIFEST.MF files.
>>>
>>>> Can the tool "update in-place"?
>>>
>>> You can use it in three ways.
>>>
>>> 1. Standalone. Pass it a WAR/JAR/directory and it will convert it.
>>>
>>> 2. On deployment. Place your WAR file in webapps-javaee and Tomcat 
>>> will create a converted version in webapps and load it.
>>>
>>> 3. At runtime by setting the jakartaConverter attribute of the Loader 
>>> to the required conversion profile name.
>>>
>>>> I have run the tool on my "webapp" source dir, which has only a half 
>>>> a dozen servlets.  Should I also run the tool in the app source dir 
>>>> which also has some javax.servlet etc imports?  Indeed, run it over 
>>>> my entire code base?
>>>
>>> It needs to run over all your source code. For each dependency you 
>>> either need to obtain a Jakarta EE compatible JAR or use the tool to 
>>> convert a Java EE JAR. Note some dependencies will not use Java EE 
>>> APIs and won't need updating / converting.
>>
>> I do want to be perfectly clear: you can run the tool *on your source 
>> code*; it's not just a WAR/JAR converter.
>>
>> So run it on your source and check the changes with your revision 
>> control system to see what it did.
> 
> I successfully ran to tool directly against my source code, with none of 
> the options added to the command line. Wonderful.  My first guess was to 
> supply just the <source> dir but then set <destination> same as 
> <source>.  Bingo.  Perhaps a little unexpected but it works.
> 
> But now of course I have jakarta and javax (naming, sql, xml) imports. 
> Is it wiser (and part of the tool's capabilities) to replace those as 
> well?  Maybe a little future-proofing?  Wouldn't this then make one less 
> dependency? jakarta-11?

Maybe I don't understand.

The migration tool should take a project from being Java EE-based to be 
Jakarta EE-based. You shouldn't have code with e.g. imports for both 
javax.servlet and jakarta.servlet. That would never compile.

What am I missing about your situation/question?

>> Then switch any dependencies you know about for their Jakarta 
>> equivalents. Then build and test, swapping-out anything that isn't 
>> working for its Jakarta equivalent.
>>
>> For those packages which aren't available targeted at the Jakarta 
>> APIs, run those JAR files through the converter either as a part of 
>> your build or pre-build with stored-local JAR files.
>>
>> -chris
>>
> Not sure if there's any attempt to address any of the build 
> environments, but if so adding gradle's build.gradle files to the mix 
> would be greatly appreciated.

I'm totally ignorant of Gradle, other than that it's a build too. The 
migration tool doesn't have any opinions about any toolchains. You can 
feel free to integrate into your build process in whatever way you prefer.

-chris