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 http://ant.apache.org/manual/CoreTasks/jar.html 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
--
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="foo.bar.RunME"
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
