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