This is a saviour.

thanks.

/thilina

java -classpath ../lib/’*';resources/xml;’.’ com.myapp.MainClass

And the MainClass is a separate class file which can accessible from the current directory (’.') and not part of the jar file.

Is this will work?
Thank you.

The disingenuous ways to crunch a CLASSPATH are.
1) use symlinks e.g. ln -s /reallyannoyinglong3rdpartysoftwarepath2libdir /s1
2) use dos SUBST command e.g. SUBST J: C:\reallyannoyinglong3rdpartysoftwarepath2libdir
3) The following is dangerous, but can work when you know the products well.
unjar all jars to a temp dir and jar them up as one jar file e.g. annoyinglybig3pp.jar
4) Manually go through all jars of all 3rd party products and grow old figuring out what you don’t use and somehow exclude it.
5) Use a special shell or modify an existing one to cater for huge line or environment variable sizes.
6) Incorporate some class loading facility within the running application itself.

ALL THE ABOVE INTRODUCE MAINTENANCE CONCERNS OVER AND ABOVE NORMAL OPERATIONS.

Thanks to this blog I now can use the escaped wildcard, but even better can use an application Manifest, but does anyone know if there is a limit to the size of the Class-Path: line in a Manifest file?

The Manifest/Class-Path approach seems to imply that an app delivered with lots of lib/jars can be started by simply specifying the jar that has the full app Class-Path defined in its manifest. E.g. “java -cp /app1/lib/start_app1.jar app1.Main”

I assume that if I’m using two 3rd party apps (app1 and app2) in my application (myapp) I should be able to create a trivial startup jar for each app using the above Manifest/Class-Path technique and run it as follows
E.g. “java -cp /myapp/start_myapp.jar:/app1/lib/start_app1.jar:/app2/lib/start_app2.jar myapp.Main”

If this works then this is great at solving the long CLASSPATH issue (and the spec says you can use the wildcard in the Manifest/Class-Path as well), but stay with me because I’m now going to present a java problem that has bothered me at times.

When your application uses many external software components, then inside these external components may be common libraries that are at different revision levels. The first one that comes to mind is log4j. The developers of these external software components only think that you will be using the version that they supplied, however that particular version may interfere with other external software components when you put it at the start of the CLASSPATH. So you stick the newer version of log4j at the start of the CLASSPATH and you solve one problem but break something else. Unfortunately you don’t own the external software and cannot apply a fix/update as it is part of a bigger software baseline. This is very unlike internal software component dependencies where you have better control and can use neat tools like IVY for managing them.

However, if I were to use the Manifest/Class-Path approach and create trivial start_app jars for each app as before, is the class loader able to construct an internal search path that allows the correct use of the right version of log4j jar for the right app? That is, is there some internal search path group hierarchy that can be constructed using the above Manifest/Class-Path technique? My gut feeling is no.

Would it be a good idea for java to facilitate some form of internal search path group hierarchy when it comes to searching for classes, other than just the URL/directory path, for the specific purpose of solving dependency issues when using common family components of varying revisions across many external apps?
Using the Manifest/Class-Path technique to specify a group CLASSPATH to me seems like a good place to control this group search hierarchy, so when a class is requested by a running application the search is first performed in the local group hashtable for that class and if not found then the rest of the class hashtable is searched. I don’t think it would add too much of a runtime overhead as the whole class list is only searched once (in 2 steps that can even be run in parallel).

Unfortunately I no longer have a need to test this because I no longer work in a place that uses a horrendously complex mix of software suites (i.e. telco), but would still appreciate the feedback.

java -classpath `find jarsDir -name ‘*.jar’ | sed -e ’s/ /:/g’` Main

The find command produces all .jar files anywhere in the jarsDir directory, separated by spaces, and the sed command replaces spaces with colons, as needed by the classpath variable.

http://www.artima.com/forums/flat.jsp?forum=1&thread=120583

setLocal EnableDelayedExpansion
set JarsDir=somedirectory\lib
if defined classpath (set classpath=%classpath%;.) else (set classpath=.)
for %%i in (”%JarsDir%\*.jar”) do set classpath=!classpath!;%%i
endlocal & set classpath=%classpath%
set classpath=%CLASSPATH%
echo %CLASSPATH%

I never have a .bat / .sh file to launch my java code. Instead, I store the classpath in the main .jar’s manifest, the .jar with the class that contains the ‘public static void main(args[]s)’ . Somewhat like this:

Manifest-Version: 1.0
Main-Class: com.test.Launcher
Class-Path:
jcifs.jar
jt400.jar
swingx.jar
swixml.jar
tonytools.jar
jdom.jar
TimingFramework.jar

Just ensure that each jar file has a space before and after on each line. Once done this way, The java application can be launched by using java -jar {mainjar}.jar , or even just double clicking from the desktop.

Much easier, and more cross platform compatable (no .bat for windows, .sh for OS X, etc.)