Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (117)
games submitted by our members
Games in WIP (564)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Jar Manifest Properties  (Read 2286 times)
0 Members and 1 Guest are viewing this topic.
Offline kevglass

JGO Kernel


Medals: 165
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Posted 2003-06-22 16:46:43 »

I've been using properties in manifest files to make Jar files executables. This suits me very well.. but... I want to use some properties to the JVM.. is there a property in the manifest file I can use to set these up?

Kev

Offline leknor

Junior Member




ROCK!!!


« Reply #1 - Posted 2003-06-22 20:01:28 »

I doubt it. The manifest is parsed in the JVM, after the JVM has loaded. Command line options are probably parsed  during JVM initilization.
Offline duncanIdaho

Junior Member




invert mouse


« Reply #2 - Posted 2003-09-25 19:32:53 »

I looked and looked, but to no avail.  I wanted a double-click jar with JVM flags set, but that isn't possible.

You can, however, specify the classpath.  yippee.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ryanm

Senior Member


Projects: 1
Exp: 15 years


Used to be bleb


« Reply #3 - Posted 2003-10-22 14:27:17 »

Quote

You can, however, specify the classpath.  yippee.


I'm having trouble doing this though.

java -jar ignores all -cp and environment variable settings, so the only way to give a classpath is through the jar's manifest.

So with this in mind, why does the following simple example work as expected with the compile and test targets, but the jar file generated complain of not finding com.sun.jdi.BootStrap when i try to run it with java -jar?

the code:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
import com.sun.jdi.*;
import com.sun.jdi.connect.*;

import java.util.*;

public class ObjectGraph
{

      public static void main( String[] args )
      {

            System.out.println( "Classpath set to :" );
            System.out.println( System.getProperty( "java.class.path" ) );

            Bootstrap bs = new Bootstrap();
            VirtualMachineManager vmm = bs.virtualMachineManager();

            List connectors = vmm.allConnectors();

            ListIterator iter = connectors.listIterator();

            while( iter.hasNext() )
            {
                  System.out.println( ( ( Connector ) iter.next() ).description() );
            }
      }
}


the ant build.xml file
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
<project name="ObjectGraph" default="compile" basedir=".">

      <description>
            Builds ObjectGraph to varying degrees
      </description>
      <!-- set global properties for this build -->
      <property name="build" location="build"/>
      <property name="JDIlib" location="/usr/java/j2sdk1.4.2/lib/tools.jar"/>

      <target name="init">
            <!-- Create the time stamp -->
            <tstamp/>
            <!-- Create the build directory structure used by compile -->
            <mkdir dir="${build}"/>
      </target>

      <target name="compile" depends="init"
                  description="compile the source" >
            <!-- Compile the java code from ${src} into ${build}-->
            <record name="compilelog.txt" action="start" append="false" emacsmode="true"/>

            <javac srcdir="." destdir="${build}" debug="true"
                                          classpath="${JDIlib}"
                                          debuglevel="source,lines,vars" />

            <record name="compilelog.txt" action="stop"/>
      </target>

      <target name="jar" depends="compile"
                  description="generate the distribution" >

            <!-- Put everything in ${build} into the ObjectGraph.jar file-->
            <jar jarfile="ObjectGraph.jar" basedir="${build}" index="true">
                  <manifest>
                        <attribute name="Class-Path" value="${JDIlib}"/>
                        <attribute name="Main-Class" value="ObjectGraph"/>
                  </manifest>
            </jar>
      </target>

      <target name="test" depends="compile"
                  description="start up the application for testing" >
            <record name="runlog.txt" action="start" append="false" emacsmode="true"/>

            <java classname="ObjectGraph" fork="true" >
                  <classpath>
                        <pathelement location="${build}"/>
                        <pathelement location="${JDIlib}"/>
                  </classpath>
            </java>

            <record name="runlog.txt" action="stop"/>
      </target>

      <target name="clean" description="clean up" >
            <!-- Delete the ${build} directory tree -->
            <delete dir="${build}"/>
            <delete file="compilelog.txt"/>
            <delete file="runlog.txt"/>
      </target>

</project>


You may have to alter the value of JDIlib in the ant file to get it running on your system.

No doubt there's some trivial, obvious reason for this annoying behaviour, and i would love for someone to enlighten me.

Cheers
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #4 - Posted 2003-10-22 23:04:56 »

Personally I don't find that executable jar files are flexable enough.  Sure - I normally give them a Main-Class tag (and Class Path tag) anyway as it's pretty simple - but I always supply OS dependant shell scripts with them.

This two pronged approach means that people who like executable jar's have them. But the following benifits from shell scripts are also added:

* power users edit them and see what commands you can change.
* the "jar" file association might have been lost preventing exectuable jars from working (I have seen this - WinRAR I think did it).
* If java isnt' installed - a clever batch script can alert the user ie. "echo Make sure you hava Java (java.com) installed! - followed by a "pause""
* JVM flags can be set
* Some users don't know what a .jar file is!  It's easy to forget when you use java every day but for the newer users a .bat file is probably easier to understand
* there is no debugging output from a crashing .jar file.  Worse - if it crashes on load nothing happens.  That is the worst thing for the user "um I double clicked and nothing happened".  Since Java stack traces are quite useful and somthing even a novice end user can submit to you why cut this option out?

the last .bat file I made for my application has a big chunk of text at the top explaining that Java 1.4 or better is needed.   I use "java -showversion" so an end user with half a clue can work it out, I mention java.com and my own support forums.  After the java command, I print more text - and have a pause statement (else the .bat will simply exit straight away).  I am hoping this will reduce the number of emails I have to send to people saying "download Java 1.4!"

I am also against the idea that all java applications should be a single jar file.  While some may be suited to this - if you have editable (text) options and the likes it may be favourable to have other files in the directory as well.

Jar files are great - and exectuable ones can be handy but I am wary of their limitations and always provide alternatives.

Cheers,

Willl.

Offline ryanm

Senior Member


Projects: 1
Exp: 15 years


Used to be bleb


« Reply #5 - Posted 2003-10-23 08:10:43 »

Fair enough, but I'd still quite like to know why the above doesn't work.

Ah well, I suppose I can use System.setProperty() for now.
Offline ryanm

Senior Member


Projects: 1
Exp: 15 years


Used to be bleb


« Reply #6 - Posted 2003-10-23 11:38:25 »

Aha!

Found the problem, it seems that the "index" flag in Ant's jar task does not generate the index properly, and so you need to do it seperately like so:

1  
2  
3  
4  
5  
            <echo>Generate *correct* index files for jar. Bloody ant...</echo>
            <exec executable="jar">
                  <arg value="-i"/>
                  <arg value="MyJar.jar"/>
            </exec>


All's well
Smiley
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #7 - Posted 2003-10-23 22:14:13 »

sorry - I hadn't read your code, I was just giving my $0.02 on Jar files Smiley

You can't have absolute paths in your Class-Path attribute - they all must be relitive to the jar file (this is so it works when you put them on other peoples systems, or the internet etc) if you do java just ignores them.

You would need to bundle the tools.jar file in say a "lib/" directory then specify it as "lib/tools.jar" as the Class-Path.

I learned that inadvertantly yesterday when trying to work out how to get two jar files recognised in the Class-Path (and the answer to that is just add a space between them, eg. "lib/foo.jar lib/bar.jar".

The other option is to pop "tools.jar" into your default class path ie. "/jre/lib/ext/" which would then negate the need of specifying it as in a class path.

Cheers,

Will.

Offline ryanm

Senior Member


Projects: 1
Exp: 15 years


Used to be bleb


« Reply #8 - Posted 2003-10-27 08:51:50 »

Quote
You can't have absolute paths in your Class-Path attribute - they all must be relitive to the jar file


I suppose that's fair enough, but it could be documented better ( or indeed at all )

I suppose the real problem is that, while tools.jar is part of the JRE distribution ( It contains, among other things, the [link=http://java.sun.com/j2se/1.4.2/docs/guide/jpda/index.html]JPDA[/link] classes ), it strangely is not in a place where it will automatically be part of the classpath :-/
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Grunnt (20 views)
2014-09-23 14:38:19

radar3301 (14 views)
2014-09-21 23:33:17

BurntPizza (31 views)
2014-09-21 02:42:18

BurntPizza (22 views)
2014-09-21 01:30:30

moogie (20 views)
2014-09-21 00:26:15

UprightPath (29 views)
2014-09-20 20:14:06

BurntPizza (33 views)
2014-09-19 03:14:18

Dwinin (48 views)
2014-09-12 09:08:26

Norakomi (75 views)
2014-09-10 13:57:51

TehJavaDev (108 views)
2014-09-10 06:39:09
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!