classpath too long problem in Windows when running TC Maven plugin

Type: Bug
Status: Closed
Priority: 1 Critical
Resolution: Fixed
Component/s:
Labels:

Assignee:
Reporter: hhuynh
Created: October 12, 2007
Votes: 0
Watchers: 1
Updated:
November 02, 2007
Resolved:
November 02, 2007

Attachments

ekulesho (13.00 k) text/plain commandline.txt
hhuynh (10.00 k) application/x-zip-compressed log.txt.zip

Description

[INFO] Starting bootjar tool [DEBUG] cmd: cmd.exe /X /C “c:\jdk\jdk1.6.0_01\jre\bin\java -Dcom.tc.l1.modules.repositories=file:/C:/Users/hhuynh/.m2/repository/ -Dtc.classloader.writeToDisk=true -Xmx20m -Dtc.classpath=file:/c:/Users/hhuynh/AppData/Local/Temp/tc-classpath40094.tmp -cp ……very long classpath here……..

-d:\work\maven-tc-plugin\examples\tc-maven-plugin-sample\tc-config.xml” [INFO] [bootjar] The command line is too long.

Comments

Hung Huynh 2007-10-12

Here is the debug out put from running tc-maven-plugin-sample

Hung Huynh 2007-10-13

There’s a workaround by using CLASSPATH env. Wrap the command inside a BATCH script like so:

@echo off setlocal

set CLASSPATH=%CLASSPATH%;z:\org\springframework\spring-web\2.0\spring-web-2.0.jar set CLASSPATH=%CLASSPATH%;z:\xerces\xmlParserAPIs\2.6.2\xmlParserAPIs-2.6.2.jar set CLASSPATH=%CLASSPATH%;z:\oro\oro\2.0.8\oro-2.0.8.jar

…..

cmd.exe /x /c “c:\jdk\jdk1.6.0_01\jre\bin\java -Dcom.tc.l1.modules.repositories=file:/C:/Users/hhuynh/.m2/repository/ -Dtc.classloader.writeToDisk=true -Xmx20m -Dtc.classpath=file:/c:/Users/hhuynh/AppData/Local/Temp/tc-classpath40094.tmp com.tc.object.tools.BootJarTool -o d:\work\maven-tc-plugin\examples\tc-maven-plugin-sample\target\dso-boot.jar -f d:\work\maven-tc-plugin\examples\tc-maven-plugin-sample\tc-config.xml”

endlocal

Hung Huynh 2007-10-16

This is still a problem, running tc:run under /tc-maven-plugin-sample I got:

[INFO] [sample1] java.lang.NoClassDefFoundError: and [INFO] [master] java.lang.NoClassDefFoundError: and [INFO] [sample0] java.lang.NoClassDefFoundError: and [INFO] [sample1] Exception in thread “main” [INFO] [master] Exception in thread “main”

Hung Huynh 2007-10-16

the created classpath contains all the jars found under .m2 repo. This leads to a huge classpath (big problem in windows). See attachement for the classpath.

Eugene Kuleshov 2007-10-16

Jason, it seems like this happens because org\terracotta\terracotta\2.5-SNAPSHOT\terracotta-2.5-SNAPSHOT.pom has dependencies artifact:

org.terracotta dependencies ${tcVersion}

So, all unneded jars are being picked up.

Eugene Kuleshov 2007-10-16

Here is command line constructed by maven plugin because of all that info.

jvoegele 2007-10-17

The problem is that those dependencies are necessary for Maven projects to use the terracotta-2.5-SNAPSHOT.jar without having to repeat those dependencies in their own POMs. The Forge projects for instance depend on the terracotta-2.5-SNAPSHOT.jar, and if we don’t have terracotta-2.5-SNAPSHOT.jar depend on all of those other JARS, then the Forge projects will each have to repeat all of the dependencies.

Is there any way to get the Maven plugin to work with this big list of dependencies? Maybe something such as Hung suggested with the batch script?

If there is no way to get the Maven plugin to work with the big list of dependencies, I can remove the dependency declaration from terracotta-2.5-SNAPSHOT.pom, but this will break the Forge projects.

Eugene Kuleshov 2007-10-17

Jason, not all those dependencies are needed for tc.jar. More over many of dependencies you are listed should have “test” scope declared.

Here is the list I have in pom.xml (some of commons jars below may not be needed for tc.jar)

<dependency>
  <groupId>commons-lang</groupId>
  <artifactId>commons-lang</artifactId>
  <version>2.2</version>
</dependency>
<dependency>
  <groupId>commons-cli</groupId>
  <artifactId>commons-cli</artifactId>
  <version>1.0</version>
</dependency>
<dependency>
  <groupId>commons-logging</groupId>
  <artifactId>commons-logging</artifactId>
  <version>1.0.4</version>
</dependency>
<dependency>
  <groupId>commons-io</groupId>
  <artifactId>commons-io</artifactId>
  <version>1.2</version>
</dependency>
<dependency>
  <groupId>commons-collections</groupId>
  <artifactId>commons-collections</artifactId>
  <version>3.1</version>
</dependency>

<!-- Terracotta -->
<dependency>
  <groupId>org.terracotta</groupId>
  <artifactId>terracotta</artifactId>
  <version>2.5-SNAPSHOT</version>
</dependency>
<dependency>
  <groupId>org.terracotta</groupId>
  <artifactId>tcconfig</artifactId>
  <version>2.5-SNAPSHOT</version>
</dependency>
<dependency>
  <groupId>org.terracotta</groupId>
  <artifactId>tcconfig1</artifactId>
  <version>1.0</version>
</dependency>
<dependency>
  <groupId>org.terracotta</groupId>
  <artifactId>tcconfig2</artifactId>
  <version>2.0</version>
</dependency>

<!-- Terracotta runtime -->
<!-- bootjartool dependencies -->
<dependency>
  <groupId>xmlbeans</groupId>
  <artifactId>xbean</artifactId>
  <version>2.1.0</version>
</dependency>
<dependency>
  <groupId>log4j</groupId>
  <artifactId>log4j</artifactId>
  <version>1.2.9</version>
</dependency>
<dependency>
  <groupId>concurrent</groupId>
  <artifactId>concurrent</artifactId>
  <version>1.3.4</version>
</dependency>
<dependency>
  <groupId>stax</groupId>
  <artifactId>stax-api</artifactId>
  <version>1.0.1</version>
</dependency>
<dependency>
  <groupId>commons-io</groupId>
  <artifactId>commons-io</artifactId>
  <version>1.1</version>
</dependency>
<dependency>
  <groupId>trove</groupId>
  <artifactId>trove</artifactId>
  <version>1.1-beta-5</version>
</dependency>
<dependency>
  <groupId>knopflerfish-tc</groupId>
  <artifactId>knopflerfish-tc</artifactId>
  <version>2.0.1</version>
</dependency>

<!-- l2 dependencies : jetty -->
<dependency>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty-util</artifactId>
  <version>6.0.1</version>
</dependency>
<dependency>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty</artifactId>
  <version>6.0.1</version>
</dependency>
<dependency>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jsp-2.1</artifactId>
  <version>6.0.1</version>
</dependency>
<dependency>
  <groupId>javax.servlet</groupId>
  <artifactId>servlet-api</artifactId>
  <version>2.4</version>
</dependency>

<!-- l2 dependencies -->
<dependency>
  <groupId>org.beanshell</groupId>
  <artifactId>bsh</artifactId>
  <version>2.0b4</version>
</dependency>
<dependency>
  <groupId>berkeleydb</groupId>
  <artifactId>je</artifactId>
  <version>3.2.13</version>
</dependency>

<!-- jmx -->
<dependency>
  <groupId>javax.management</groupId>
  <artifactId>jmxri</artifactId>
  <version>1.2.1</version>
</dependency>
<dependency>
  <groupId>javax.management</groupId>
  <artifactId>jmxremote</artifactId>
  <version>1.0.1_04</version>
</dependency>
<dependency>
  <groupId>javax.management</groupId>
  <artifactId>jmxremote_optional</artifactId>
  <version>1.0.1_04</version>
</dependency>

<!-- admin console -->
<dependency>
  <groupId>org.dijon</groupId>
  <artifactId>appframe</artifactId>
  <version>1.0</version>
</dependency>
<dependency>
  <groupId>commons-httpclient</groupId>
  <artifactId>commons-httpclient</artifactId>
  <version>3.0.1</version>
</dependency>
<dependency>
  <groupId>treemap</groupId>
  <artifactId>treemap</artifactId>
  <version>2.5.1</version>
</dependency>
<dependency>
  <groupId>jfree</groupId>
  <artifactId>jfreechart</artifactId>
  <version>1.0.0</version>
</dependency>

Hung Huynh 2007-10-17

there’s a limit to the classpath hack in windows. Environment variable in windows limits to 8K so that’s the longest classpath we can afford.

jvoegele 2007-10-17

Currently, the dependencies are set up as follows. Excluding config modules, we have five primary Maven artifacts that we deploy:

terracotta tc-compile tcconfig tc-session tc.test-compile

The POMs for these five artifacts are located in code/base/poms. All five of these POMs declare a dependency on the big dependency list, which is located at code/base/dependencies/pom.xml. By doing this, we ensure that all of these artifacts are usable because all of the dependencies are declared. However, since the dependencies are not properly scoped, we have more than we actually need.

From what Eugene mentions above, it sounds like we should get rid of the dependencies POM, and declare more fine-grained dependencies in the individual POMs in code/base/poms, using the “test” scope as appropriate.

Eugene Kuleshov 2007-10-23

Hung, I’ve committed a workaround to filter classes from maven, cargo and spring out of the classpath. Can you please try it in your environment?

Hung Huynh 2007-10-23

The workaround works.

jvoegele 2007-11-02

Can this issue be closed or is there more that needs to be done?

Hung Huynh 2007-11-02

The workaround Eugene made is working fine.