We work on rewriting the build system for a software company. Their build has lots of generators, that use various 3rd party deps, one of them is whole Weblogic. We have a "depchain" pom, that consists of all weblogic dependencies. When we run some kind of generators with this depchain in classpath, we fail on CreateProcess error=206, The filename or extension is too long on 32 bit JVM, but everything works well with 64. It's quite obvious, that it fails on the length of the classpath, because every jar in the depchain is the absolute location within .m2 folder (previously they did not have the understanding of binary repository and the classpath was a simple directory). We execute generators with simple antrun plugin executions. Is there a way to make it work on 32bit java, besides trimming the classpath?
UPD After a day of sweating I finally made it working using #Evgeniy Dorofeev 's idea. I couldn't use mvn plugin because the part of creating the artifact I run in, is executing this generator. So I had to use ant to build a manifest only jar that contains this giant classpath string. The issue that the classpath string used absolute paths, and I had to convert it to relative (MANIFEST.MF format). It was a headache of it's own:
<var name="relative.classpath.property"/>
<for param="curr.dep" list="${combined_classpath}" delimiter=";">
<sequential>
<local name="relative.dep.location"/>
<property name="relative.dep.location" relative="true" basedir="${project.build.directory}" value="#{curr.dep}"/>
<local name="classpath.hack.temp"/>
<propertyregex property="classpath.hack.temp"
input="${relative.dep.location}"
regexp="\\"
replace="\/"
default="${relative.dep.location}"
global="true"/>
<var name="relative.classpath.property" value="${relative.classpath.property} ${classpath.hack.temp}"/>
</sequential>
</for>
And to build a jar with all this stuff later:
<jar jarfile="${project.build.directory}/classpath.hack.jar">
<manifest>
<attribute name="Class-Path" value="${relative.classpath.property}"/>
</manifest>
</jar>
And then my <java> will have only ${project.build.directory}/classpath.hack.jar in the classpath
You can add Class-Path attr to your app jar manifest, this is how we do it in Maven
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
...
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
</manifest>
</archive>
</configuration>
...
</plugin>
this way there's no limit for classpath length
Java's 64-bit javac generates the same code as the 32-bit version so you should don't need to use Java 32-bit unless you only have a 32-bit OS.
Java 6 added directory/* to include all JARS in a directory and this can shorted a classpath significantly.
The source of your problem is that all 32-bit programs run in the Windows XP/32-bit emulator and has all the same restrictions such as maximum command line length and environment variable length. Changing/fixing this is something MS themselves didn't try and I suggest you avoid this too.
Related
I have JAVA library that I am working on and I am using Ant build system, I am trying to generate a .jar file from and using in another application, what I am trying to do is to enable some specific ENV variables only in Debug build and have them disabled in production/release, and I was wondering how can I achieve that?
In my build.xml I have a property called "debug", which is boolean.
In C/C++ You have the NDEBUG macros where you can define what you will exclude/include in debug mode,
is there something similar in JAVA?
I have tried to read Ant documentation, I see that they use properties but the documentation doesn't state exactly how you can pass those properties into the source code, In fact, I tried to do that but with no success.
As mentioned by #Joachim Sauer above, Java does not feature conditional compilation. You can argue either way for this being a good feature, but it's not available.
What can you do, then?
One method you can use is to write information into the jar's manifest.
For example, you could include the build version and your debug flag like so:
<jar destfile="my.jar" basedir="build/classes">
<manifest>
<attribute name="Package-Title" value="My Package Title" />
<attribute name="Package-Version" value="${build.current.version}" />
<attribute name="Debug" value="${debug}" />
</manifest>
</jar>
Then, in your code, you would attempt to read your own jar's manifest: Reading my own Jar's Manifest
Another simpler option might be to include a properties file in your jar, and just read that. You can use the ant task 'echo' to write out a properties file before the jar task:
<echo file="build/classes/my.properties" encoding="ISO-8859-1" append="false">
Package-Title: ${package-title}
Package-Version: ${build.current.version}
com.example.app.debug=${debug}
</echo>
Then, you can just open "my.properties" in the code as a resource, and use that.
I am stuck in a very common problem.
I am plugging my jar (which has many dependencies on third party vendor) into an application server lib directory. If I just copy my jar along with its dependencies into server lib then server classpath becomes to long and hence server is not able to work. Therefore I want to package this Jar with all its dependencies in a single jar so that server's classpath doesn't become too long. I found on various forums that there is a utility to do this i.e. OneJar. But this utility works on executable jar. In my case, my final jar will not be executable.
Also I tried ZIPFileSetGroup utility provided by ANT but that is causing security issues with Manifest file.
Can you please help me in resolving this issue?
Thanks!
If you use Maven to build, you can use the maven dependency plugin and use the copy-dependency task. It will copy all dependencies into your jar file when it creates it.
If you manually add the jars to your jar file, then you need to make sure your jar file has a Manifest.mf file in it and specify the main class and classpath inside of that.
Manifest-Version: 1.0
Main-Class: com.mypackage.MainClass
Class-Path: my.jar log4j.jar
Another option may be to build an .ear file, that is usually how you see enterprise apps or a .war file for web apps when they package specific jar files with them. It sounds like you are using a server, so one of those formats may be a better fit for you.
Using zipgroupfileset in the jar task in ANT is the easiest approach.
<jar destfile="MyApplication.jar" filesetmanifest="mergewithoutmain">
<zipgroupfileset dir="lib" includes="*.jar" />
<!-- other options -->
<manifest>
<attribute name="Main-Class" value="Main.MainClass" />
</manifest>
</jar>
Note the filesetmanifest flag set to mergewithoutmain merges everything but the Main section of the manifests.
Signed jars are causing the SecurityException which need to be handled manually. If any classes associated with signed jars verify the signature on the jar as a whole then those will fail at runtime. Digest signatures against a particular file will be added to the manifest without a problem. Since problem is your classpath getting too large you may not be able to bundle all the jars into a single jar but merge most of them making the CLASSPATH manageable.
There is also : http://code.google.com/p/jarjar/
Create target directory with all dependent jars. Next move 10 jars into a temp directory and keep moving the jars in batches of 10 and each time try to create the single jar from that group. When you get the security exception you can isolate which one is causing the problem. Try divide-and-conquer approach. If you have 300 jars then only have to do this 30 times.
When you say
child process picks up classpath from server/lib directory
is this a process that is under your control? If the parent process were to specify the classpath just as
server/lib/*
(i.e. a literal *) then the target java process will enumerate the jar files in the lib directory itself - they do not all need to be named on the classpath.
But if the parent process is explicitly enumerating server/lib/*.jar to build the -cp value then you could take advantage of the fact that the Class-Path in a JAR manifest takes effect even if a JAR is not "executable". You could use a stanza like this to create a manifest-only JAR file
<!-- location of your 300 dependency JAR files, file1.jar ... file300.jar -->
<property name="lib.dir" location="lib" />
<fileset id="dependencies" dir="${lib.dir}" includes="*.jar" />
<pathconvert property="manifest.classpath" dirsep="/" pathsep=" "
refid="dependencies">
<map from="${lib.dir}" to="myapp" />
</pathconvert>
<jar destfile="myapp-manifest.jar">
<manifest>
<attribute name="Class-Path" value="${manifest.classpath}" />
</manifest>
</jar>
This will produce a JAR file named myapp-manifest.jar whose manifest contains
Class-Path: myapp/file1.jar myapp/file2.jar ... myapp/file300.jar
You put this file into server/lib and the 300 dependencies into a new directory server/lib/myapp. Now the generated -cp will include just one file (myapp-manifest.jar) but the resulting java process will have all the 300 myapp JAR files available to it.
I actualy have 2 problems
I use eclipse -> export project to generate a jar file for my simple desktop (GUI) program
It generates a jar file and an ant script.
first problem:
the generated jar works fine when double-clicked.
When I use the generated ant script to generate the jar
by myself, it doesn't work.
What can be wrong with a target like this (assuming that all dependencies are met)
<target name="create_run_jar">
<jar destfile="G:/dev/myproj/myproj.jar">
<manifest>
<attribute name="Main-Class" value="view.myproj"/>
<attribute name="Class-Path" value=". myproj_lib/grouplayout.jar"/>
</manifest>
<fileset dir="G:/dev/myproj/bin"/>
</jar>
<delete dir="G:/dev/myproj/myproj_lib"/>
<mkdir dir="G:/dev/myproj/myproj_lib"/>
<copy file="G:/dev/.metadata/.plugins/org.dyno.visual.swing/layoutext/grouplayout.jar" todir="G:/dev/myproj/myproj"/>
</target>
//nevemind
//Second problem:
//when I double click on the auto-generated jar file the program launches and works fine.
//when I do java myjar from the command-line I get main class not found exception..
//weird huh?
I suggest that you take the JAR files generated the two ways, use the jar command to expand them into temporary directories, and then use diff in recursive mode to compare them.
However, I suspect that #Pace has put his finger on the problem; i.e. that you are using relative paths in the Class-Path manifest entry and this is liable to cause problems.
java -jar <jar name> is the proper way to execute a jar.
The ant target is creating a manifest with a classpath attribute. If you look at those paths you'll notice that they are relative to the current directory. When you execute java -jar from the command line are you in the...
G:/dev/myproj
...directory?
Is there any way that i can give a version number to my application in netbeans.And then access that version number inside my code.
Something similar to the Assembly number that we use in .Net.Is there anything like that in java or in netbeans...?
Define an Implementation-Version in the manifest of the Jar at build time. It is common to use some form of the date as the version number. E.G. 14.07.28
The value can be retrieved in code using..
String version = this.getClass().getPackage().getImplementationVersion();
<tstamp>
<format property="now" pattern="yy.MM.dd"/>
</tstamp>
...
<jar
destfile="build/dist/lib/${jar.name}"
update='true'
index='true' >
<manifest>
<attribute name="Created-By" value="${vendor}"/>
<attribute name="Implementation-Title" value="${application.title}"/>
<attribute name="Implementation-Vendor" value="${vendor}"/>
<attribute name="Implementation-Vendor-Id" value="org.pscode"/>
<!-- This next property is retrieved in code above. -->
<attribute name="Implementation-Version" value="${now}"/>
</manifest>
<fileset dir="build/share">
<include name="${package.name}/*.class" />
<include name="${package.name}/*.png" />
</fileset>
</jar>
This comes from a build file for a project I have open at the moment. The relevant attribute is the last one in the manifest section.
In my JavaFX app created in Netbeans, I can set the build version (Implementation version) in the Project Properties window shown here:
This number is then used everywhere, for example it is automatically inserted into the filename of the installer. It is also the number retrieved by this.getClass().getPackage().getImplementationVersion(); mentioned by the accepted answer.
I don't know about .NET assembly numbers, but if you're creating a web application you can certainly put a version number into the manifest of your WAR file.
Any Java package can have a build info text file added to it so you can tell these things.
Your version number could be a build number from Ant, a version number from Subversion, or a combination of the two.
I am attempting to create a JAR based on two separate Java packages. I can compile and run within Eclipse, but cannot get the code to function from the command line. I have Ant and the JDK correctly configured for usage, as I have an almost working Ant build script. The only problem is that the resulting JAR throws a ClassNotFoundException when I attempt to execute it.
The archive contains all the .class files from both packages in the correct directory hierarchy. Regardless, the JAR will throw the above mentioned exception.
The idea is to run this script from the top level directory that contains both packages.
Here are the relevant lines from my build script:
<manifest file="MANIFEST.MF">
<attribute name="Built-By" value="XBigTK13X"/>
<attribute name="Main-Class" value="com.main.MainClass"/>
<attribute name="Class-Path" value="./com/main/ ./secondpackage/shapes/" />
</manifest>
<jar destfile="App.jar"
basedir="./bin"
includes="**/*.class"
manifest="MANIFEST.MF"
excludes="App.jar"
/>
The JAR was correct the whole time. This error was thrown because I was attempting to run the JAR with the following command after creating a JAR:
java MainClass
I now realize that I need to explicitly target the JAR by using the following command:
java -jar MainClass.jar
Look in the resulting JAR file to make sure that the two packages have the correct path from the root. Your Class-Path statement in the manifest may not match the structure of folders containing the .class files.
Verify it by opening the JAR with a zip util.