When I was reading the specification, I was really annoyed by the fact that a Service Unit would require a deployment descriptor by itself regardless of the container Service Assembly. After I started practicing JBI I realized the great reusability this requirement offers. The expert group really had tooling in mind. When you use the same deployment artifact at design time, you would perfectly allow other tools, if any, to do their job. For example, the method I mentioned earlier, that my team is currently using, would allow us to use both approaches back and forth. I attached the profile and a sample implementation, it might be helpful.
I have a few other suggestions: - You mentioned in your first post that one needs to register a component first to be visible on the palette, can you enable dynamic lookup of existing JAR or ZIP files. And as you said, you would read or inject your configurations into the descriptor. - Should I be able to register or look up a Service Assembly or a Service Unit and see it on the palette as well?? Ok, what about a Shared Library? - May be in the future you can directly or indirectly support UML 2.0 XMI export and import (quite a job) from Eclipse. Tools like Borland Together and IBM RSA will understand this. Am I going too far? I really hope I would be able to checkout and play with this tool soon. Thanks, Hossam Karim -----Original Message----- From: Philip Dodds [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 18, 2006 6:01 PM To: servicemix-dev@geronimo.apache.org Subject: Re: JBI Deployer Hossam, I've been thinking and we can probably switch it so that in the event of us not finding the components.xml we can switch it back to the jbi.xml and see if there are any assets in place there, in this way we can support multiple components and the more natural single component approach, I'll try and get that in place in the next week :) Cheers P On 1/17/06, Philip Dodds <[EMAIL PROTECTED]> wrote: > > Currently there are three projects...not sure quite where to put them, > basically they are: > > servicemix-packaging-descriptors - The packaging descriptors and helper > factories > servicemix-packaging-eclipse-plugin - The Eclipse plugin itself > > maven2-eclipse-plugin-plugin - Horribly named but does what it says, > basically a Maven2 plugin that can be used to generate the MANFEST.MF for > Eclipse 3.0 based on the pom.xml > > On the beer note I'm still working out if I'll be in Aylesbury in Feb so I > might be able to make claim to a few :) > > Cheers > > P > > On 1/17/06, James Strachan <[EMAIL PROTECTED]> wrote: > > > > > > On 17 Jan 2006, at 11:11, Philip Dodds wrote: > > > 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></ > > > artifactReference><resourceReference><name>defaultDestination</ > > > name><resource xmlns:ns3=" http://openuri.org";>ns3:newService2</ > > > resource></resourceReference><serviceName 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. > > > > Awesome! > > > > FWIW thanks to the retrotranslator project - and the maven2 plugin - > > we can actually generate 1.4 jars for Java 5 code and JAXB2 HEAD > > works on it! > > http://retrotranslator.sourceforge.net/ > > > > Many thanks to Kohsuke from the JAXB team for helping fix JAXB/JAXP > > and Hiram for the m2 retrotranslator plugin (with lots of help from > > Brett) and mostly for Taras for doing all the hard work of > > translating 1.5 code into working 1.4 bytecode (including generics, > > annotations, java-util-concurrent etc). > > > > So depending on Java 5 and JAXB2 is fine; we can just generate 1.4 > > versions where we need to. It does mean that the build itself depends > > on Java 5 but thats no big deal. > > > > > > > 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 :) > > > > Sounds awesome - bring it on Philip! :) > > > > By all means just check the code into the Apache ServiceMix repo if > > you want. If you didn't write all the code we'll need CLAs to be on > > file at Apache. > > > > I owe you a few more beers for this :) > > > > James > > ------- > > http://radio.weblogs.com/0112098/ > > > > > > >
