Apache Maven startup batch file issues

[jcalcote]

I'm trying out apache maven (v2.2.1) on TCC 11.00.31 x64 Windows 7 [v 6.1.7600]. The maven batch file (mvn.bat) seems to be written to recognize 4NT - at least older versions of the 4NT command shell. It contains batch code that looks like this:

...

@REM -- 4NT shell
if "%@eval[2+2]" == "4" goto 4NTArgs

@REM -- Regular WinNT shell
set MAVEN_CMD_LINE_ARGS=%*
goto endInit

@REM The 4NT Shell from jp software
:4NTArgs
set MAVEN_CMD_LINE_ARGS=%$
goto endInit

...

:endInit
SET MAVEN_JAVA_EXE="%JAVA_HOME%\bin\java.exe"

@REM -- 4NT shell
if "%@eval[2+2]" == "4" goto 4NTCWJars

@REM -- Regular WinNT shell
for %%i in ("%M2_HOME%"\boot\classworlds-*) do set CLASSWORLDS_JAR="%%i"
goto runm2

@REM The 4NT Shell from jp software
:4NTCWJars
for %%i in ("%M2_HOME%\boot\classworlds-*") do set CLASSWORLDS_JAR="%%i"
goto runm2

...

I've found that maven doesn't work properly when this code is enabled, so I've REM'd out the relevant 'if' statements (e.g., @REM if "%@eval...) and used the base code path, which assumes regular cmd.exe operation.

This actually works fine for me. I guess TCC has become "more compatible" with cmd.exe in the later versions of TCC and Windows, but perhaps at the expense of backward compatibility with older versions of 4NT... (?)

Anyone know why this might be? I'd like to submit a patch to the apache maven folks so that the mvn.bat file will work with both older and newer versions of 4NT/TCC. Any idea how I might go about determining when the change took place that caused the breakage?

Thanks in advance,
John

 

[Steve Fabian]

jcalcote wrote:
| I'm trying out apache maven (v2.2.1) on TCC 11.00.31 x64 Windows 7
| [v 6.1.7600]. The maven batch file (mvn.bat) seems to be written to
| recognize 4NT - at least older versions of the 4NT command shell. It
| contains batch code that looks like this:
|
| ...
|
| @REM -- 4NT shell
| if "%@eval[2+2]" == "4" goto 4NTArgs

That technique for discerning 4NT vs. CMD was recommended over a decade ago,
but it still works. I think a much simpler method is to deliver both an
XXX.BAT and XXX.BTM file, and make sure the command passed to the command
processor is XXX (without including the file extension). Any Microsoft
command processor will interpret the XXX.BAT batch file, and ignore XXX.BTM.
A JPsoft command processor will instead interpret XXX.BTM, amd ignore
XXX.BAT. This allows each batch file to be optimized for the specific
command processor.

| I've found that maven doesn't work properly when this code is
| enabled, so I've REM'd out the relevant 'if' statements (e.g., @REM
| if "%@eval...) and used the base code path, which assumes regular
| cmd.exe operation.

One of the issues is how you set up TCC via the OPTION dialog and / or
directives in your .INI file. They may be controlling execution to be more
or less CMD-like.

| This actually works fine for me. I guess TCC has become "more
| compatible" with cmd.exe in the later versions of TCC and Windows,
| but perhaps at the expense of backward compatibility with older
| versions of 4NT... (?)

Yes, that's what has happened. Many CMD.EXE quirks found their way into
TCC.EXE
|
| Anyone know why this might be? I'd like to submit a patch to the
| apache maven folks so that the mvn.bat file will work with both
| older and newer versions of 4NT/TCC. Any idea how I might go about
| determining when the change took place that caused the breakage?

See my suggestion above.
--
HTH, Steve

 

[skanjo]

Anyone know why this might be? I'd like to submit a patch to the apache maven folks so that the mvn.bat file will work with both older and newer versions of 4NT/TCC. Any idea how I might go about determining when the change took place that caused the breakage?

Thanks in advance,
John

Here is the JIRA Issue that applied this patch in version 2.0.8:

http://jira.codehaus.org/browse/MNG-2685

Commenting the 4NT check worked for me as well.

 

[skanjo]

Here is the JIRA Issue that applied this patch in version 2.0.8:

http://jira.codehaus.org/browse/MNG-2685

Commenting the 4NT check worked for me as well.

And now it doesn't work running on Windows 2008 Server R2. I did get it working by quoting the -D option and not fixing the mvn.bat file.