geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: Executable config construction
Date Thu, 31 Mar 2005 18:49:58 GMT
Dain Sundstrom wrote:
> 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.  

I assume you're thinking of the nested geronimo-service.xml files. This 
is not like that.

We're currently building the MCP from a combination of the deployment 
plan, the project.xml file (with magic properties), project.properties 
and custom jelly in maven.xml. Or we're requiring the user to supply the 
value as a command line parameter to the standalone deployer. Neither is 
particularly friendly.

> This xml is really just 
> syntactic sugar for creating a jar manifest 

No, its an extension to the dependency mechanism we use for 
non-executable configurations to support initializing the root 
classloader by using the Class-Path entry from the manifest.

By declaring the dependency in the XML in the normal way the 
Configuration can be loaded using normal dependency resolution as well 
(e.g. by a deployer). We can't do that right now as dependencies don't 
work in executable configurations (as there is no Repository started 
that can be used to resolve them).

> 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.
> 

I think being able to specify the entire manifest is a different 
feature. It might be useful to add, in which case it should be done in 
the same way Maven's jar plugin does it.

In fact, let's do that - have the packager build the target 
configuration exploded under ${maven.build.dir} and then have the jar 
plugin zip it up? That way we get to reuse all the features of the jar 
plugin.

Even if we do that, we will still need the expanded syntax in the 
configuration file itself so that it can be used with the standalone 
deployer (i.e. without maven).

--
Jeremy

Mime
View raw message