Executable config construction

[Jeremy Boynes <jb...@apache.org>]

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

Re: Executable config construction

[Jeremy Boynes <jb...@apache.org>]

Dain Sundstrom wrote:
<snip/>
> I'm really just thinking of the boot strap problem, so my view may be
> to myopic. Does this plugin address that problem?
> 

Bootstrap? Kind of. By making the plugin itself available from the repo, 
  it can be used to rebuild the geronimo-gbean-deployer configuration to 
upgrade the service builder it itself uses. In other words, there is a 
seed there that can bootstrap later versions.


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

There were those in the original mail which probably most apply to 
command line operation.

An alternative which would work for the Maven plugin would be to have 
all the configuration's dependencies be generated by the plugin based on 
properties from the POM. This would work for normal configurations and 
could work in conjunction with the jar plugin to build the MCP for 
executable ones.

I didn't do that at first as I was trying to avoid changes to the 
deployer (avoiding disruption). I'll look at adding it in as an option.


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

Yep. Generating the config.ser and exploding source archives into the 
right place.

It might also be worth adding goals for generating deployment plans for 
EAR, WAR type modules; perhaps that should be a separate plugin though.

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

I think we ultimately end up with many:
* JSR-88 commmand line
* JSR-88 plugin for IDEs etc. to use
* Geronimo specific command line
* Maven integrated
* IDE integrated (IDEA, Eclipse, ...)
+ others as people see the need.

--
Jeremy

Re: Executable config construction

[Dain Sundstrom <ds...@gluecode.com>]

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

Re: Executable config construction

[Jeremy Boynes <jb...@apache.org>]

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

Re: Executable config construction

[Dain Sundstrom <ds...@gluecode.com>]

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