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
