Philip, Why not use the provided JBI schema to describe your design time properties, something like:
<?xml version="1.0" encoding="UTF-8"?> <jbi xmlns="http://java.sun.com/xml/ns/jbi"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:ext="http://www.example.org/jbi/extension"; xsi:schemaLocation="http://java.sun.com/xml/ns/jbi ./jbi.xsd" version="1"> <component type="binding-component"> <identification> <name>GroovyScript</name> <description>A component that can be deployed with an embedded Groovy Script</description> </identification> <component-class-name>org.example.jbi.GroovyScriptBinding</component-class-n ame> <component-class-path> <path-element>.</path-element> </component-class-path> <bootstrap-class-name>org.example.jbi.GroovyScriptBootstrap</bootstrap-class -name> <bootstrap-class-path> <path-element>.</path-element> </bootstrap-class-path> <ext:component> <componentUuid>1e194e80-7ee0-11da-bb92-0002a5d5c51b</componentUuid> <assets> <embeddedArtifact name="script.groovy" extension="groovy" description="Your Groovy Script"/> <parameter name="exampleparameter" defaultValue="haha" description="Example parameter"/> <connection default="true" name="defaultDestination" description="Default destination" mep="robustInOnly"/> </assets> </ext:component> </component> </jbi> So the document would be reusable for both design time and deployment. My team is using a similar approach. We created a UML 2.0 profile for JBI; used deployment diagrams to define components and related artifacts, annotating them using the profile stereotypes. We then export the model into an XMI document, and at build time, we run an XQuery against the exported document to generate the descriptors. Cheers, Hossam Karim _____ From: Philip Dodds [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 17, 2006 9:12 PM To: servicemix-dev@geronimo.apache.org Subject: JBI Deployer We've been working on a re-usable deployment plugin for eclipse to try and simplify the process of create components and actually making them re-usable. The basic idea is fairly simple, when you build you JBI component, whether it be a binding component or a service engine you include a components.xml in the META-INF directory, which holds information about your component, and example of which is below: <components> <component type="binding-component"> <componentUuid>1e194e80-7ee0-11da-bb92-0002a5d5c51b</componentUuid> <name>Groovy Script</name> <description> A component that can be deployed with an embedded Groovy Script </description> <assets> <embeddedArtifact name="script.groovy" extension="groovy" description="Your Groovy Script" /> <parameter name="exampleparameter" defaultValue="haha" description="Example parameter"/> <connection default="true" name="defaultDestination" description="Default destination" mep="robustInOnly" /> </assets> </component> In essence the idea of your components.xml is to describe your components, which can be either binding-components or service-engine, you can also define embedded artifacts which are files you expect to be bundles with either your service engine or binding-component, there is also space for parameters and also connections to other services. The idea behind this is to express your requirements for your component so that someone knows what they need to provide to get your working, the idea here is to make your component re-usable without needing the source code. Then basically we have two projects, one which is the descriptors for this components.xml and also a file called assets.xml and the second is an eclipse plugin that you can install and then register your components with, once you have the eclipse plugin installed in your eclipse you basically can goto preferences in eclipse and add all the packaged JBI components, basically those JBI components with a jbi.xml that are your usual stuff but also with a components.xml in there. Once you have registered them you can create a project and add a file with the extension .jbi, this will open the JBI deployer which is basically just a GEF diagramming component, however you will see you components (as registered from your components.xml) in the pallette, if you drop one on the canvas you will be able to configure the settings (those also defined in the components.xml) and therefore configure a re-usable JBI component. If you component is a service engine you will see component and be able to press the + button to create service units inside, note that in this case you can gather parameters at a service unit by added parameters etc at the service unit level ie: <component type="service-engine"> <componentUuid>658c0460-7ee0-11da-ba83-0002a5d5c51c</componentUuid> <name>Translator</name> <description> Unity's transformation service engine </description> <serviceUnit> <assets> <embeddedArtifact name="translator.xml" extension="trslr" description="Translator Configuration" /> <parameter name="exampleparameter" defaultValue="haha" description="Example parameter"/> <connection default="true" name="defaultDestination" description="Default destination" mep="robustInOnly" /> </assets> </serviceUnit> </component> </components> Once you have set up your digram as you want it you can right click on a component or service assembly and choose deploy, this will create the component zips by basically exploding the base jar (which the components.xml) and creating a new component injecting both the embeddedArtifacts and also the assets (which are the parameters gathered from the deployment editor), therefore you would have META-INF/stored-assets.xml in either your binding-component or your service unit ie. <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <storedAssets> <artifactReference><name>script.groovy</name><path>whizbang.groovy</path></a rtifactReference><resourceReference><name>defaultDestination</name><resource xmlns:ns3=" http://openuri.org";>ns3:newService2</resource></resourceReference><serviceNa me xmlns:ns3="http://openuri.org";>ns3:newService</serviceName></storedAssets> In the descriptor package with then supply a simple StoredAssetFactory you can give either your service unit deploy path to or your component context to get your assets back. The basic idea here is to make the packaging of a JBI component or re-use and also the deployment of complex patterns easier with a graphical environment and a mechanism for exposing your code and requesting the artifacts etc you want. We (Unity Systems) have been working on this for the past couple of months and believe that the ServiceMix project would benefit from this style of deployment as it would enable easier configuration and deployment. There are a couple of downsides first is it was written for Java 5 and the second is a dependency on JAXB2. If the team think this is a good idea or have comments we can place a cut of the code somewhere for review or we can make it a tooling project and examine maybe how we could document the lw-container to make it a good basis to writing a component and passing it parameters, also we might want to see if some of the service-components could be modified to be able to use the stored assets if available. All comments and thoughts are welcome :) Cheers P
