application as a single Jar file. The Java Runtime Environment supports
But I do think, we all might be learning a bit of the various options avaliable in Java to deploy an
================================================================================
>
>
> On Fri, Feb 19, 2010 at 7:39 AM, David Requena <
[hidden email]
> <mailto:
[hidden email]>> wrote:
>
> Fernando,
>
> I agree the '-jar' jvm switch is the way to go for your run of the
> mill app with a single entry point, which the NetRexx processor is
> not by any means.
>
>
> Good.
>
>
> I also fail to see why all the fuzz about the classpath thing. As
> soon as your projects start to grwo bigger you're likely to be
> including all kinds of third party libraries, thus being forced to
> wrestle with classpath in one way or another. Here is where IDE's
> and tools like maven, ant or even the classic make come into play.
>
>
> Are we talking about DEVELOPING an app or DEPLOYING an app? Sorry, I
> lost the plot...
>
>
>
> While including needed support jar files inside your distribution
> package (zip, tgz, or whatever) is in my view a good idea, I don't
> see the point in merging all the stuff *into a sigle jar* as was
> initially proposed in this thread.
>
>
> I don´t think I was the one who asked about merging everything in a
> single Jar, although as you reckon, it´s a good idea.
>
>
http://java.sun.com/developer/technicalArticles/java_warehouse/single_jar/>
>
http://blog.taragana.com/index.php/archive/apache-ant-how-to-include-multiple-jar-files-in-a-single-jar-file/>
>
http://one-jar.sourceforge.net/>
> "Java developers often come to a point where they wish to deliver
> their application as a single Jar file. The Java Runtime Environment
> supports running a Jar file using the following syntax:
> java -jar /jarname.jar/
>
> The only requirement of the /jarname.jar/ file is that it contains a
> manifest attribute with the key |Main-Class| a main class to run.
> Suppose the application entry point is the class
> |com.mydomain.mypackage.Main|. Add the following line to the
> |META-INF/MANIFEST.MF| file:
> Main-Class: com.mydomain.mypackage.Main
>
> So far so good. But, here's where the problems usually start. Any
> non-trivial Java application is going to rely on any number of
> supporting Jar files. For example, using the Apache Commons Logging
> capabilty to do logging an application will need to have the
> |commons-logging.jar| file on its classpath.
>
> Most developers reasonably assume that putting such a Jar file into
> their own Jar file, and adding a |Class-Path| attribute to the
> |META-INF/MANIFEST| will do the trick:
>
> jarname.jar
> | /META-INF
> | | MANIFEST.MF
> | | Main-Class: com.mydomain.mypackage.Main
> | | Class-Path: commons-logging.jar
> | /com/mydomain/mypackage
> | | Main.class
> | commons-logging.jar
>
> Unfortunately this is not the case. The Java classloader does not know
> how to load classes from a Jar inside a Jar. The entries on the
> |Class-Path| must be references to files outside the Jar file,
> defeating the goal of delivering an application in a single Jar file."
> "One-JAR uses a classloader which knows how to load classes and
> resources from Jar files inside a Jar file. To help provide some
> structure to the classloading process, the One-JAR |JarClassLoader|
> looks for a main program inside a |main| directory in the Jar file,
> and looks for supporting Jar files inside a |lib| directory"
>
> Hope this helps someone. Or perhaps I´m making assumptions about the
> way Netrexx works.
>
> FC
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ibm-netrexx mailing list
>
[hidden email]
>
>
Tom. (ths@db-123.com)
Locked
