In the http://ant.apache.org/manual/tutorial-HelloWorldWithAnt.html
echo Main-Class: oata.HelloWorld>myManifest
md build\jar
jar cfm build\jar\HelloWorld.jar myManifest -C build\classes .
java -jar build\jar\HelloWorld.jar
Note: Do not have blanks around the >-sign in the echo Main-Class instruction because it would falsify it!
Anyone know why there is such Note. I do not see any difference when we hae balnks around >-sign.
You are correct, it makes no difference. Not sure what the message on the tutorial means.
Just a guess.
It probably meant to stress the need for getting the line correctly copied. Main-Class attribute
Any value other than 'Main-Class:' will fail the jar creation.
With a white space after - Main - Class or
just before : 'Main-Class : gives the error invalid header field name: ..
Related
java "$homeOption" -cp "$classPath" "com.civilizer.extra.tools.DataBroker" -import "$importPath"
If $homeOption is not empty, the command above works, but $homeOption is empty, it can't find the main class
Error: Could not find or load main class
Looks like Empty $homeOption parameter affects classpath string in a bad way; It's so strange behavior to me;
Anyone running into this issue and understanding why?
Edit:
In case that it works:
The actual command line is as follows;
com.civilizer.extra.tools.DataBroker is a Java class with main method, and it is included in that verbose classpath;
in this case, $homeOption is -Dcivilizer.private_home_path=/Users/bsw/.civilizer
java -Dcivilizer.private_home_path=/Users/bsw/.civilizer -cp /Users/bsw/test/trysomething/civilizer/target/civilizer-1.0.0.CI-SNAPSHOT/WEB-INF/classes:/Users/bsw/test/trysomething/civilizer/extra/lib/:/Users/bsw/test/trysomething/civilizer/target/civilizer-1.0.0.CI-SNAPSHOT/WEB-INF/lib/:/Users/bsw/test/trysomething/civilizer/target/extra com.civilizer.extra.tools.DataBroker -import
In case that it can't find the main class:
java -cp /Users/bsw/test/trysomething/civilizer/target/civilizer-1.0.0.CI-SNAPSHOT/WEB-INF/classes:/Users/bsw/test/trysomething/civilizer/extra/lib/:/Users/bsw/test/trysomething/civilizer/target/civilizer-1.0.0.CI-SNAPSHOT/WEB-INF/lib/:/Users/bsw/test/trysomething/civilizer/target/extra com.civilizer.extra.tools.DataBroker -import
As I mentioned, only $homeOption is empty; but it just makes the issue; BTW, even if $homeOption is empty, the class will run without a problem, but you know, the main method is missing in the first place in this case, it doesn't matter
You could resolve this by populating an array and passing that to the java command instead.
opts=( )
if [[ -n "$homeOption" ]]; then
opts+=( "$homeOption" )
fi
java "${opts[#]}" -cp "$classPath" "com.civilizer.extra.tools.DataBroker" -import "$importPath"
The issue you are seeing is because bash is passing a blank string to java as the first argument, and java is taking the blank string to be the class:
compare:
$ java foo
Error: Could not find or load main class foo
vs:
$ java ''
Error: Could not find or load main class
You can see that java prints the class name it can't find in the error, but your case, and my second case above, the class name is an empty string, so the class name is blank in the error message as well.
The reason my solution works is if the array is empty then bash won't pass in any empty arguments. And the array is created empty, and left empty unless $homeOption has a non-empty string.
I'm running a jarball using
java -classpath myBatch.jar some.package.MyMainClass \
-bloodyArgument "I got the argument!" -Dbloody.prop="I got the prop!"
Then in my main I have:
Properties argsProps = BatchUtils.argsToProperties(args);
System.out.println(argsProps.getProperty("bloodyArgument"));
System.out.println(System.getProperty("bloody.prop"));
And I get output:
I got the argument!
null
I can see the command line bloodyArgument (I added it to see if "something" gets passed to the program), but I'd expect the -D argument to set the system property. Why is the "bloody.prop" null?
PS: BatchUtils.argsToProperties() does what you'd expected it to do: parse -argName "value" from command line into argName=value property pair.
Everything after the class argument of java command gets passed to your main in String[] args and doesn't make it to the JVM.
The solution was to rearrange the properties like this:
java -classpath myBatch.jar -Dbloody.prop="I got the prop!" \
some.package.MyMainClass -bloodyArgument "I got the argument!"
I didn't find this anywhere explicitly stated when waddling the web with http://duckduckgo.com or googling this queation of "null -D defined property". I figured it a lot later when printing all system properties and the whole arguments array, so am posting for others.
Running this command in the terminal works fine:
java -jar file.jar --arg1 --arg2 pathTofile
When I then try to do this from the python code using following code:
subprocess.call(['java', '-jar', 'file.jar', '--arg1' , '--arg2' , 'pathTofile'])
I get an IllegalArugmentException for --arg1.
Any ideas on why this could generate a problem?
#Benst - I encountered the same problem, this is what works for me:
subprocess.call(['java', '-Dparam1=paramValue1', '-Dparam2=paramValue2', '-jar', 'filename.jar']);
Cheers!
Ok I figuered it out.
When using the subprocess routine in python you need to quote the option and concurrent value seperatly
eg:
subprocess.call(['java', '-jar', 'file.jar', '-option', 'valueForThisOption', '-option', 'valueForThisOption', 'pathToFile'])
putting the -option and value in one quote generates this error.
I have read somewhere that you can only put the -option and value in one quote if you put shell=True at the end. (untested)
I am getting a too long line error while trying to build a jar. the long line in the manifest file is the Class-Path line as the application uses a lot of third-party libraries. needless to say, I am using Windows :-( and Eclipse Java 1.6
I tried Class-Path: lib or Class-Path: lib/ but they did not work.
The classpath is too long due to the number of jar files in it. «No line may be longer than 72 bytes (not characters), in its UTF8-encoded form.» [from docs: java 5, java 8; «Line length» section].
use as the following way to resolve the problem:
(1) use separate lines, to avoid too long a line for java package name lists
(2) type a preceding space before each folloing lines, for example:
Class-Path:
...jar
...jar
...jar
The single character didn't work for me (Java 8, IntelliJ). I used two characters at the start and no characters at the end of the line (wasn't apparent from the above example) and two new lines at the end, e.g.
Manifest-Version: 1.0
Main-Class: com.mypackage.MyApp
Implementation-Version: 2.0.0
Class-Path: newLibs/asjava.zip
newLibs/activation.jar
newLibs/axis-ant.jar
newLibs/axis.jar
newLibs/bcel-5.1.jar
newLibs/commons-discovery-0.2.jar
newLibs/commons-logging-1.0.4.jar
newLibs/datanucleus-api-jdo-4.2.0-release.jar
newLibs/datanucleus-api-jpa-4.1.4.jar
newLibs/datanucleus-cache-4.0.4.jar
newLibs/datanucleus-core-4.1.5.jar
newLibs/datanucleus-geospatial-4.1.0-release.jar
newLibs/datanucleus-guava-4.1.3.jar
newLibs/datanucleus-java8-4.2.0-release.jar
newLibs/datanucleus-jdo-query-4.2.0-release.jar
newLibs/datanucleus-jodatime-4.1.1.jar
newLibs/datanucleus-jpa-query-4.0.4.jar
newLibs/datanucleus-rdbms-4.1.6.jar
newLibs/dom4j-1.6.1.jar
newLibs/ehcache-1.1.jar
newLibs/ehcache-core-2.2.0.jar
newLibs/geronimo-jta_1.1_spec-1.1.jar
newLibs/guava-15.0.jar
newLibs/h2-1.3.168.jar
newLibs/ibmjsse.jar
newLibs/javax.jdo-3.2.0-m3.jar
newLibs/javax.persistence-2.1.1.jar
newLibs/jaxrpc.jar
newLibs/jdo-api-3.1-rc1.jar
newLibs/jdom.jar
newLibs/joda-time-1.6.jar
newLibs/jtds-1.2.jar
newLibs/log4j-1.2.14.jar
newLibs/mail.jar
newLibs/saaj.jar
newLibs/servlet-api.jar
newLibs/wsdl4j-1.5.1.jar
newLibs/xercesImpl.jar
newLibs/xml-apis.jar
I also avoided placing multiple jars on one line as that didn't appear to work (even with lines less than 72 bytes).
What led me to arrive at this solution was (1) I kept getting various class not found exceptions, of course and (2) When I examined the generated manifest file in the jar file, the spacing between the jars was missing - I assume that it was silently failing because there was no reported error apart from the class not found exceptions. My working, generated manifest file looks like this:
Manifest-Version: 1.0
Implementation-Version: 2.0.0
Class-Path: newLibs/asjava.zip newLibs/activation.jar newLibs/axis-an
t.jar newLibs/axis.jar newLibs/bcel-5.1.jar newLibs/commons-discovery
-0.2.jar newLibs/commons-logging-1.0.4.jar newLibs/datanucleus-api-jd
o-4.2.0-release.jar newLibs/datanucleus-api-jpa-4.1.4.jar newLibs/dat
anucleus-cache-4.0.4.jar newLibs/datanucleus-core-4.1.5.jar newLibs/d
atanucleus-geospatial-4.1.0-release.jar newLibs/datanucleus-guava-4.1
.3.jar newLibs/datanucleus-java8-4.2.0-release.jar newLibs/datanucleu
s-jdo-query-4.2.0-release.jar newLibs/datanucleus-jodatime-4.1.1.jar
newLibs/datanucleus-jpa-query-4.0.4.jar newLibs/datanucleus-rdbms-4.1
.6.jar newLibs/dom4j-1.6.1.jar newLibs/ehcache-1.1.jar newLibs/ehcach
e-core-2.2.0.jar newLibs/geronimo-jta_1.1_spec-1.1.jar newLibs/guava-
15.0.jar newLibs/h2-1.3.168.jar newLibs/ibmjsse.jar newLibs/javax.jdo
-3.2.0-m3.jar newLibs/javax.persistence-2.1.1.jar newLibs/jaxrpc.jar
newLibs/jdo-api-3.1-rc1.jar newLibs/jdom.jar newLibs/joda-time-1.6.ja
r newLibs/jtds-1.2.jar newLibs/junit-3.8.1.jar newLibs/log4j-1.2.14.j
ar newLibs/mail.jar newLibs/saaj.jar newLibs/servlet-api.jar newLibs/
wsdl4j-1.5.1.jar newLibs/xercesImpl.jar newLibs/xml-apis.jar
Main-Class: com.mypackage.MyApp
The answer of Voodoochild put me on the right track but wasn't so clear to me so quoting the specs:
No line may be longer than 72 bytes (not characters), in its UTF8-encoded form. If a value would make the initial line longer than this, it should be continued on extra lines (each starting with a single SPACE).
Manifest example:
Manifest-Version: 1.0
Main-Class: com.mypackage.MyApp
Class-path: commons-beanutils-1.7.0.jar commons-collections-3.1.jar
commons-dbcp-1.2.2.jar commons-discovery.jar commons-lang-2.1.jar
commons-pool-1.2.jar ezjcom18.jar jbcl.jar log4j-1.2.14.jar
sqljdbc.jar torque-3.2-rc2.jar
The multi-space solutions up there didn't work for me for some reason. So I looked at how Eclipse's export-runnable-jar dialog does it. It adds an Ascii "LF" and then a space as a linebreak.
In Java: char LF = (char) 0x0A;
For too long line error
Use Class-Path: *.*
I have a bat file with the following contents:
set logfile= D:\log.txt
java com.stuff.MyClass %1 %2 %3 >> %logfile%
when I run the bat file though, I get the following:
C:\>set logfile= D:\log.txt
C:\>java com.stuff.MyClass <val of %1> <val of %2> <val of %3> 1>>D:\log.txt
The parameter is incorrect.
I'm almost positive the "The parameter is incorrect." is due to the extraneous 1 in there. I also think this might have something with the encoding of the .bat file, but I can't quite figure out what is causing it. Anyone ever run into this before or know what might be causing it and how to fix it?
Edit
And the lesson, as always, is check if its plugged in first before you go asking for help. The bat file, in version control, uses D:\log.txt because it is intended to be run from the server which contains a D drive. When testing my changes and running locally, on my computer which doesn't have a D drive, I failed to make the change to use C:\log.txt which is what caused the error. Sorry for wasting you time, thanks for the help, try to resist the urge to downvote me too much.
I doubt that that's the problem - I expect the command processor to deal with that part for you.
Here's evidence of it working for me:
Test.java:
public class Test
{
public static void main(String args[]) throws Exception
{
System.out.println(args.length);
for (String arg : args)
{
System.out.println(arg);
}
}
}
test.bat:
set logfile= c:\users\jon\test\test.log
java Test %1 %2 %3 >> %logfile%
On the command line:
c:\Users\Jon\Test> [User input] test.bat first second third
c:\Users\Jon\Test>set logfile= c:\users\jon\test\test.log
c:\Users\Jon\Test>java Test first second third 1>>c:\users\jon\test\test.log
c:\Users\Jon\Test> [User input] type test.log
3
first
second
third
the 1 is not extraneous: it is inserted by cmd.exe meaning stdout (instead of ">>", you can also write "1>>". contrast this to redirecting stderr: "2>>"). so the problem must be with your parameters.
This may seem like a stupid question, but is there an existing D: drive in the context that the bat file runs in?
Once I had a case where a bat file was used as the command line of a task within the Task Manager, but the Run As user was set to a local user on the box, giving no access to network drives.
Interpolated for your case, if the D: drive were a network drive, running the bat file as, say, the local administrator account on that machine instead of a domain user account would likely fail to have access to D:.