geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <dsundst...@gluecode.com>
Subject Re: Executable config construction
Date Thu, 31 Mar 2005 20:06:12 GMT
On Mar 31, 2005, at 10:49 AM, Jeremy Boynes wrote:

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

Actually I wasn't thinking of that nasty problem :)  I can't count the 
times I've bitten by the classpath in the service.xml stuff.  I'm 
really just thinking of the boot strap problem, so my view may be to 
myopic.  Does this plugin address that problem?

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

Ya, that was the issue I was talking about, not the bigger problem of 
dependencies, just how you get the initial kernel running with a repo 
and config store.  Do you have any ideas on building the manifest class 
path?

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

Sweet!  So we really end up with a tool that is "compiling" the xml 
into a config.ser file (and I'm sure other stuff).

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

Absolutely.  This is why when I look at this issue I see two different 
deployers: the command line accessible one and a maven based one that 
can do the bootstrap stuff (in addition to the other stuff).

-dain


Mime
View raw message