geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Executable config construction
Date Thu, 31 Mar 2005 18:05:17 GMT
That is the way it used to be, and it turned out to be quite painful to 
maintain the list in and external xml file.  This xml is really just 
syntactic sugar for creating a jar manifest and I think we should just 
have our maven tool take an ant sytle manifest directly.  Near the 
bottom of this page is 
an example of an inline manifest for a jar file. If we provided this 
feature, you would have the full power of the java manifest 
specification (such as service declarations), and would not be limited 
by the capabilities of our tool.  Also since it would be inline in 
maven, you don't need an external tool such as velocity to preprocess 
the file to manage the version numbers.


Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26

On Mar 31, 2005, at 9:36 AM, Jeremy Boynes wrote:

> When packaging we currently pass three manifest related parameters to 
> the Deployer:
> * classPath, used to set up the manifest Class-Path
> * mainClass, used for the manifest Main-Class
> * endorsedDirs, added as an Endorsed-Dirs attribute used by the Daemon
>   class to set the java.endorsed.dirs system property
> These are derived from similarly named options on the command line 
> tool or properties for the packaging plugin.
> These are really aspects of the configuration itself so I would like 
> to propose moving their definition into the XML file itself by 
> supporting an "executable" element:
> <configuration ...>
>    <executable
>       main-class=""
>       class-path-prefix="../repository/"
>       endorsed-dirs="../lib/endorsed"
>       />
>    <dependency class-path="true">
>       <!-- following dependency gets added to MCP -->
>       <uri>foo/jars/bar-1.0.jar</uri>
>    </dependency>
>    ...
> </configuration>
> Dependencies tagged with "class-path" get added to the Class-Path 
> attribute in the manifest (with the prefix prepended); these will be 
> loaded by the JVM classloader. We should be able to support other 
> dependencies in the future (they are not supported at all now).
> Having the dependencies spelt out will cure a couple of issues in 
> deployment where the config carfile actually needs to be in the right 
> directory structure so that the MCP references work (or where we 
> happen to be lucky because the jars happen to be on the deployer's 
> MCP).
> --
> Jeremy

View raw message