Re: ServiceMix 4.0 modularity
Yes you are crazy. I have to agree - dependency hell is not something I'd like to have to overcome. Eclipse's deal is a nice example. Kit Sent from my iPhone On Oct 4, 2007, at 4:31 PM, Bruce Snyder [EMAIL PROTECTED] wrote: On 10/4/07, Guillaume Nodet [EMAIL PROTECTED] wrote: I'd like to make ServiceMix 4.0 as modular as possible. This would mean that ServiceMix 4.0 main distribution would come with the minimal set, while additional features could be provisioned and configured using OBR, the Deployment Admin or our provisioning system. Such features could include: * an activemq broker * an apache ds server * jbi 1.0 compatibility layer * jaxws support * ... Although from a project perspective, if we could split these features in different projects, that would make things easier to release: i.e. release a single feature at a time, rather than releasing everything each time. Kinda like maven does with its plugins. I've always thought the idea of separate release cycles for different components/features was a good one. This allows for individual components to be released as they're ready. However, I've begun to reconsider this recently. Independent component releases seem like a good idea until the developer has trouble and then begins to upgrade components independently resulting in a mish-mash of versions which can cause a laundry list of other problems. It seems to me that we should not push this responsibility onto the developer because it causes them more trouble than its worth. Not unlike recent Eclipse releases, ServiceMix is a container with many modules and I think *we* should bear the burden of making each module work together to provide an overall ServiceMix release. An alternative approach would be to mix independent component releases with overall ServiceMix releases. This would give us the ability to release components independently while still providing a major release of all components packaged together as ServiceMix, say, four times a year. Am I crazy? Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\! G;6%I;\YC;VT* );' Apache ActiveMQ - http://activemq.org/ Apache ServiceMix - http://servicemix.org/ Apache Geronimo - http://geronimo.apache.org/ Castor - http://castor.org/
Re: GShell
Im using the pax-logging stuff on a project. Very nice. Kit On Oct 2, 2007, at 5:28 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: Btw, the pax project has lots of interesting things. See http://wiki.ops4j.org/confluence/display/ops4j/Pax+RadMan and much more. On 10/3/07, Guillaume Nodet [EMAIL PROTECTED] wrote: Forwarding to the dev list... FYI, Gshell is a subproject of Geronimo providing an extensible console (local and remote), kinda like bash. -- Forwarded Message From: Guillaume Nodet [EMAIL PROTECTED] Date: Wed, 03 Oct 2007 02:11:44 +0200 To: Bruce Snyder [EMAIL PROTECTED] Conversation: On duplicating effort Subject: Re: On duplicating effort On 3/10/07 2:02, Bruce Snyder [EMAIL PROTECTED] wrote: On 10/2/07 5:59 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: https://issues.apache.org/activemq/secure/IssueNavigator.jspa?reset=truemod e=hidesorter/order=DESCsorter/ field=priorityresolution=-1pid=10950fixfo r=11845 So are you using GShell for SM-1074? Not really. Imho, gshell is just an interface to access features provided by other mechanism. Lifecycle is really tied to OSGi lifecycle, but yeah, we need to create Gshell commands for OSGi related stuff (start / stop bundles, etc...), but we could also have a web console for that, or a JMX one... What I mean is that Gshell should remain a mean of accessing these features. We also need to add a JIRA issue for the 1.0 compatibility layer. Done, SM-1083. Btw, we should have this discussion on the dev list ;-) Guillaume -- End of Forwarded Message IONA Technologies SARL Identification: 415 295 930 R.C.S. Nanterre Siège: Immeuble Elysées La Défense, 7C place du Dôme, 92056 La Défense Cedex, France -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Me too. I think. -- Kit Plummer Nobody-in-Charge @ Black:Hole:Logic http://www.blackholelogic.com
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
On 8/24/07, Bruce Snyder [EMAIL PROTECTED] wrote: On 8/24/07, Nodet Guillaume [EMAIL PROTECTED] wrote: Any other people interested ? +1 Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache ActiveMQ - http://activemq.org/ Apache ServiceMix - http://servicemix.org/ Apache Geronimo - http://geronimo.apache.org/ Castor - http://castor.org/ Here here. -- Kit Plummer Nobody-in-Charge @ Black:Hole:Logic http://www.blackholelogic.com
Re: ServiceMix 4.0 and federation (was Re: ServiceMix 4.0)
Sure Guillaume. Maybe the best thing to do is explain the concept...and what we've done to meet our requirements. It is actually quite simple. We needed to be able to connect two computers together via TCP/IP, and have a publisher on one system, the consumer on the other. Granted we've got lot's of both on each - but, the premise is that link between is transparent. Currently, we are using a feature of ActiveMQ called Network of Brokers (NoB) to create a mapping of destinations/endpoints. Where it gets really complicated is when we only want to allow a specific MEPs to cross the NoB connection. In this example, bandwidth is not a commodity and must be tightly constrained. We were tolerant of all the SEDA flow handshaking, but I believe it would be nice if InOnly MEPS really were just a single transmission (turning off levels of reliability/durability). Also, in our environment multicast isn't possible, and the networks are fairly ad-hoc...meaning not stable. Plus, we need to know about the state of the link. Service registration happens also in different configurations. For example, one topology we support is a hierarchical flow (master-slaves). Imagine a simple sensor net. There would be a single point at the top, where are data were to be aggregated. So, in this example the NoBs need to support followers only communicating with their leader...and the leader only communicating with its leader. But, there might also be a need to have shared data that is available on all platforms in network (health, state, etc.). Ding lifecycle. I could keep going...but, am curious if anyone else looks at it this way. Obviously, the notion of simple performance scalability is one way to look at. There is a lot of capability in the NoB, but I think it falls a bit short. There are a few features that we'd like to see, that would help us federate better. BC/SE/SA-level authentication to the bus, as well as platform-to-platform, or NMR-to-NMR authentication would be very helpful. We've been looking at grid/cluster-like capabilities too - for example, if one platform is maxed out from a processing perspective, sending the SA and the message/task to another platform in network automatically. Thanks for taking the time to do this. On 8/23/07, Nodet Guillaume [EMAIL PROTECTED] wrote: Hi Kit, I'm quite sure you would have a very valuable input there, given your experience on ServiceMix. So I'm starting this new thread. Would you mind throwing a few ideas there ? Cheers, Guillaume Nodet On Aug 23, 2007, at 5:39 AM, Kit Plummer wrote: On 8/22/07, Terry Cox [EMAIL PROTECTED] wrote: Interesting. We need to have a very serious chat about application lifecycles and governance... Terry And Federating...distribution of the NMR across n-platforms! -- Kit Plummer Nobody-in-Charge @ Black:Hole:Logic http://www.blackholelogic.com
Re: ServiceMix 4.0
I'd be up for a few chat sessions! On 8/23/07, Nodet Guillaume [EMAIL PROTECTED] wrote: Btw, if there is sufficient interest, we could organize irc meetings to discuss these topics and post the log to the dev list for archiving and later discussion. Cheers, Guillaume Nodet On Aug 22, 2007, at 4:59 PM, Nodet Guillaume wrote: As I explained in the other thread, I've been working on a new API for ServiceMix 4.0. Hopefully this will serve as an input for JBI 2.0. This API is available at https://svn.apache.org/repos/asf/ incubator/servicemix/branches/servicemix-4.0/api So here a few key changes: * clean integration with OSGi * the NormalizedMessage can contain not only XML * no more components * no more JBI packaging (just use OSGi bundles) * move the Channel to the Endpoint * use push delivery instead of pulling exchanges * introduce a single interface for identifying the Target of an Exchange As we remove components, everything goes down to the endpoint which become a key feature. The endpoint must implement the Endpoint interface. In OSGi, the NMR would listen to endpoints registered in the OSGi registry and call the registry to register / unregister the endpoints. As part of the endpoint registration, the NMR would inject a Channel into them, thus actually activating the endpoint. I guess I could write a sequence diagram for that (anybody knows a good tool for uml ?). In a non OSGI environment, the Endpoint will be registered in the Registry by calling the register method somehow. The Endpoint receives Exchange to be processed on the process method. I think we should keep the JBI 1.0 semantics and the endpoint use the same process as for JBI 1.0, which is send the exchange back using the Channel (with the response / fault / error / done). This will put the threading, transactions and security burden on the container itself. Which means it is easier to write JBI apps :-) Exchanges can be created using the Channel#createExchange method. The only change I'd like to integrate in the messaging API is to allow for non xml payloads and maybe untyped attachments. The body could be converted automatically to a given type if supported (I think Camel does it nicely, so I'm thinking of shamelessly copying the converter layer). I have added a few helper methods on the exchanges and messages (copy, copyFrom, ensureReReadable, display) to ease message management. For the deployment part, there is no packaging anymore. One would deploy an OSGi bundle that would register the needed endpoints in the OSGi registry. For certain types of endpoints, we may need an external activation process (such as creating a server socket for listening to HTTP requests) that may need to be shared across endpoints of a given type. In such a case, you would deploy a component that listens to new endpoints implementing HttpEndpoint for example. When a new endpoint is registered, the listener would activate a server socket that could be shared across all http endpoints. In a different way, if we have a BPEL engine, the bpel component would listen for new bundles and look for a specific file containing deployment information. The component would register new endpoints in the OSGi registry as needed (we could do that for jaxws pojos using cxf for example). So I said there is no more components, because this feature is not in the api anymore, but we will certainly need these components for some use cases. For simple endpoints, you would not need any component at all. Another benefit is that you can easily deploy a whole application inside a single OSGi bundle. Using spring-osgi, the bundle would just consist in a spring configuration file containing the endpoints declaration and expose them as OSGi services. Of course, we need to write a JBI 1.0 compatibility layer, and we could have an intermediate layer where SAs and JBI components could be OSGi bundles directly, thus leveraging the OSGi classloading mechanism. The thing I'm not completely sure about if the Target interface which aims to identify the target of an exchange. I'm thinking that some metadata are associated with endpoints (like service name, interface name, wsdl location, etc..). These metadatas could be used to retrieve targets using the Registry. We could plug in different mechanisms to query the metadata (simple lookup per id, policy based, etc...). And the result itself could be not only a single Endpoint, but could include some policies like: load balance between all the endpoint implementing the given interface, etc Also, I think Target should be injected on Endpoints using spring, so you would look up a targe using a spring bean factory (or multiple ones): smx:endpoint-target id=my-endoint-id / or smx:interface-target
Re: ServiceMix 4.0
On 8/23/07, Bruce Snyder [EMAIL PROTECTED] wrote: On 8/23/07, Daryl Richter [EMAIL PROTECTED] wrote: On Aug 22, 2007, at 10:59 AM, Nodet Guillaume wrote: [snip] (anybody knows a good tool for uml ?). Take a look at JUDE Community Edition. Works great for me. http://jude.change-vision.com/jude-web/product/community.html Looks like JUDE requires Windoze: http://jude.change-vision.com/jude-web/product/system.html My biggest issues not finding a UML tool. It's finding a UML tool that generates sequence diagrams and runs on Mac OS X. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache ActiveMQ - http://activemq.org/ Apache ServiceMix - http://servicemix.org/ Apache Geronimo - http://geronimo.apache.org/ Castor - http://castor.org/ I've used MagicDraw on OS X. It's pretty terrible...but does work for sequence diagrams. I'm not sure if they have a free version or not. Doesn't OmniGraffle do some UML stuff too? -- Kit Plummer Nobody-in-Charge @ Black:Hole:Logic http://www.blackholelogic.com
Re: ServiceMix 4.0
On 8/22/07, Terry Cox [EMAIL PROTECTED] wrote: Interesting. We need to have a very serious chat about application lifecycles and governance... Terry And Federating...distribution of the NMR across n-platforms! -- Kit Plummer Nobody-in-Charge @ Black:Hole:Logic http://www.blackholelogic.com
Re: Checkstyle and PMD
On 7/25/07, Bruce Snyder [EMAIL PROTECTED] wrote: On 7/25/07, Guillaume Nodet [EMAIL PROTECTED] wrote: If people find this configuration too painful, we can easily disable the checks by default but i thought it was a good way to enforce a coherent code format. And yes, all the configuration will be moved to a single place when all the components pass the checks. Yeah, I was going to suggest this because they make experimentation very difficult. I also think that creating the source tarballs/zips should be part of deploy goal and not part of install goal. I agree that it's a good idea to enforce the code conventions when something is going to be committed, but not during every build cycle while I'm debugging and experimenting. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://activemq.org/ Apache ServiceMix - http://servicemix.org/ Castor - http://castor.org/ As long as I can comment out the feature at one place I don't mind the styleguide stuff. But, you are right...seems like it would be more of a pre-commit hook thing. -- Kit Plummer Nobody-in-Charge @ Black:Hole:Logic http://www.blackholelogic.com
Re: servicemix-sca: updating tuscany dependency
Sounds good. If you already have something set up...that's fine with me. Kit Brian O'Neill wrote: All, OK. So I officially started a new service engine. Guillaume, I figured I would use servicemix-bean as a template. Does that make sense to you? Jean-Sebastien, thanks for the pointers. I'll get the servicemix-bean up and running with the new name of servicemix-java-sca, then incorporate the tuscany stuff. Kit, we should figure out how we are going to work together on this? I've got a spare svn repo we could work out of. -brian On 6/28/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Brian O'Neill wrote: OK, per Guillaume's suggestion perhaps we start anew basing everything on 0.90 sca. So, what are peoples thoughts towards the design of the translation layer? Should we leverage Tuscany's parsing capabilities to read in the SCA contribution? Then, from the parsed structure generate the service-unit JBI artifacts? Just a thought about that translation layer... If you only need the SCA contribution and assembly models and the ability to read SCA assembly XML, you don't have to use the whole Tuscany runtime. We've rearchitected Tuscany SCA a few months ago to support that kind of scenario and make it easy to reuse / embed a subset of Tuscany modules in tools, generators, and platforms that are only interested in the SCA metadata without dragging the whole thing. The Tuscany modules are there: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/ For the SCA assembly, SCA contribution and policy metadata models alone, grab these modules: assembly interface contribution policy Support for Java and WSDL interfaces, and Java component implementations: interface-java interface-wsdl implementation-java Support for reading SCA assembly XML and handling SCA contributions: assembly-xml interface-java-xml (also introspects Java interfaces) interface-wsdl-xml (also introspects WSDL portTypes) implementation-java-xml contribution-impl These modules are self contained and should provide you with the ability to process SCA contributions and read SCA assembly XML, without dependencies on the Tuscany runtime, IoC container, etc. To draw an analogy with other projects, you could compare that level of function with packages like WSDL4J or Woden for WSDL for example: Models and the ability to read/write them. Hope this helps -- Jean-Sebastien
Re: servicemix-sca: updating tuscany dependency
kitplummer (im)Agreed...and I believe based on my limited knowledge of Tuscany that updating the TuscanyRuntime to be able to deploy a SCA POJO should be straight forward - and simpler with the EmbeddedSCADomain. I also agree on the tooling to provide the mapping between an SCA Composite to a JBI integration based on the included SCA bindings. This is definitely a sporty undertaking though. But, it could be a key discriminator (from a selling SM perspective). I believe we're all on the same page. Kit Guillaume Nodet wrote: I do think we need a SE like servicemix-sca (should be renamed to servicemix-tuscany i guess) to host the Java annotated SCA pojo. I see the translation between the SCA assembly to a JBI assembly as something somewhat independant from ServiceMix core that could be reused either at the tooling side, as a command line tool (maven ?) or at runtime in ServiceMix. The SCA annotated POJOs are just one model amongst several that SCA can support. I'm sure we could define a profile for JAX-WS / EJB3 that we could deploy on servicemix-cxf-se (when it supports EJB3 ;-) ). But we need both to support standard SCA deployments: a SE for SCA annotated POJOS and a translation layer to translate the SCA assembly to a JBI Service Assembly. But your assumptions are right about how to handle that: an implementation.bpel would be translated into a SU for Ode, same for POJOs. In addition several SUs targeted at BCs need to be generated for HTTP/SOAP wires ... Not sure if this is more clear. This is of course subject to discussion, but given my understanding of JBI and SCA, this the best solution I came up with. Any feedback is welcome. On 6/28/07, Gert Vanthienen [EMAIL PROTECTED] wrote: L.S., Just trying to grasp what the problem/question is... So, if I understand correctly, the servicemix-sca component will be somewhat different from any other JBI component. We won't be building an SCA container as a service engine (like you would do for e.g. EJBs), but rather build some kind of support for deploying SCA artifacts directly on ServiceMix. In order to do this, the 'metadata' that is available in the SCA artifact (sorry for not using the correct terminology, definitely need to read up on SCA) needs to be translated into JBI lingo, e.g. if an SCA component with implementation.bpel is being deployed, it needs to be translated into a service unit, targeted at the Ode JBI SE? We are looking at the design some kind of SCADeploymentService, with translation plugins to enable translation from e.g. an SCA (implementation.bpel) - ODE JBI SU... right? Gert Brian O'Neill wrote: OK, per Guillaume's suggestion perhaps we start anew basing everything on 0.90 sca. So, what are peoples thoughts towards the design of the translation layer? Should we leverage Tuscany's parsing capabilities to read in the SCA contribution? Then, from the parsed structure generate the service-unit JBI artifacts? Each type of implementation(e.g. implementation.bpel) will generate different artifacts. So, this will need to be pluggable / extensible. Perhaps we start with Jean-Sebastien's example, then implement the translation layer first? (independent of both tuscany and servicemix) What do people think? -brian On 6/27/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Guillaume Nodet wrote: Jean-Sebastien said that the apis are quite stable now, so I guess the best way would be upgrade to the latest released version. Maybe Jean-Sebastien can provide more inforamtions here. Imo, the tuscany code has changed so much so that it may be better to try uinderstanding how the SE works and maybe start a new one (at least for the tuscany binding classes). As for the sources, I guess we should be able to find a svn revision that would match the date somehow: March the 17th 2006. I'd recommend to use the Tuscany SCA 0.90 release and SDO 1.0 beta 1 levels... March 17th 2006 is more than a year ago :) -- Jean-Sebastien
Re: servicemix-sca: updating tuscany dependency
Guillaume, I think we figured out how to build/install the latest Tuscany, referencing it from the servicemix-sca pom.xml. I'm sure by the time we have this stuff straight Tuscany will be at 1.0 - or so. ;} On to the problem of getting up-to-date with Tuscany. The existing test case instantiates a TuscanyRuntime, which doesn't appear to be the way to do it anymore... Jean-Sebastian, do you think we can just mimic the sca/itest/interop-xsq-client/src/test/java/interop/ClientTestCase.java to get a runtime environment? Thanks for your effort, BTW. Kit Guillaume Nodet wrote: Jean-Sebastien said that the apis are quite stable now, so I guess the best way would be upgrade to the latest released version. Maybe Jean-Sebastien can provide more inforamtions here. Imo, the tuscany code has changed so much so that it may be better to try uinderstanding how the SE works and maybe start a new one (at least for the tuscany binding classes). As for the sources, I guess we should be able to find a svn revision that would match the date somehow: March the 17th 2006. On 6/26/07, Brian ONeill [EMAIL PROTECTED] wrote: Jean-Sebastien / Guillaume, I'm about to delve into the tests for servicemix-sca. As expected, they are failing out of the box. The tests are throwing NPEs down in the tuscany code (JavaContextFactoryBuilder). To make progress, I'd like to either upgrade the dependency, or grab the source for the version of tuscany that the component is presently using: tuscany_version20060317/tuscany_version Jean-Sebastien, can you recommend a stable branch to move to? Guillaume, any suggestions? -brian Kit Plummer wrote: Hey guys. Here's the direct link to the use case that Brian referenced: http://www.jbizint.org/wiki/index.php?title=SCA_translation_layer I like the target of deploy this SCA contribution to ServiceMix. Kit Brian ONeill wrote: Jean-Sebastien, It is a pleasure meeting you. Yes. I/we was/were thinking exactly along those lines. In fact, I have a nearly identical example / write-up here: http://www.jbizint.org/wiki/index.php?title=SCA_Service_Engine I appreciate all the input. Kit Plummer and I are trying to resurrect the engine and build on what Guillaume has put in place. I hope to get back to this today and will let you know when we have updates. best regards, brian Jean-Sebastien Delfino wrote: Guillaume Nodet wrote: Hi Jean-Sebastien ! The tuscany SE, as you said, is very old, and has never been finished (that's why it is in the sandbox). The idea was to be able to deploy SCA annotated POJOs onto it and leverage Tuscany to host them. I think there are some areas where I'd need a few explanations (see below). We're investigating how SCA and JBI can be bridged. I'm thinking that one way is to think about SCA as a development designer and JBI as the runtime. So one goal is to investigate how we could transform an SCA assembly into a JBI Service Assembly: each java component would be deployed onto the afore mentionned Service Engine, a bpel implementation could be deployed onto the Ode Service Engine (etc...) while wires / bindings would lead to several Service Units for Binding Components (HTTP, JMS, etc...). Yes, makes sense. To make sure that I got what you said right, let's use an example to illustrate the approach. Here's an SCA composite describing a simple banking app, made of: - a Java component providing account data - a BPEL component implementing an Account service - a StockQuote reference with a Web Service binding used to get the price of the stock in your account - a JSON RPC binding providing the Account service to JSON clients ?xml version=1.0 encoding=UTF-8? composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://mybank; xmlns:b=http://mybank; name=MyBank service name=AccountJSONService promote=AccountServiceComponent interface.java interface=bigbank.account.AccountService/ binding.jsonrpc/ /service component name=AccountServiceComponent implementation.bpel process=b:AccountProcess/ reference name=accountDataService target=AccountDataServiceComponent/ /component component name=AccountDataServiceComponent implementation.java class=mybank.AccountDataImpl/ /component reference name=StockQuoteReference promote=AccountServiceComponent/stockQuoteService binding.ws wsdlElement= http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)/ /reference /composite As an application developer, I write an SCA composite assembly, the Java class and BPEL process, use the WSDL I got for the StockQuote Web service. Then I package all these artifacts in an SCA contribution (a form of archive described in the SCA spec). When I deploy this SCA contribution to ServiceMix: - The Java component gets deployed to a Java SCA Service Engine that supports the SCA API
[jira] Updated: (SM-976) servicemix-sca is out of touch with the CheckStyle and PMD guides.
[ https://issues.apache.org/activemq/browse/SM-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kit Plummer updated SM-976: --- Attachment: checkstyle_fixes_servicemix-sca.diff This diff covers all of the CheckStyle and PMD errors currently found in the servicemix-sca codebase. There are no logical/functional changes...really. servicemix-sca is out of touch with the CheckStyle and PMD guides. --- Key: SM-976 URL: https://issues.apache.org/activemq/browse/SM-976 Project: ServiceMix Issue Type: Bug Components: servicemix-sca Reporter: Kit Plummer Attachments: checkstyle_fixes_servicemix-sca.diff The current state of the servicemix-sca codebase requires turning off the CheckStyle plugin in SMX/parent/pom.xml and installing it into the Maven repo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-976) servicemix-sca is out of touch with the CheckStyle and PMD guides.
servicemix-sca is out of touch with the CheckStyle and PMD guides. --- Key: SM-976 URL: https://issues.apache.org/activemq/browse/SM-976 Project: ServiceMix Issue Type: Bug Components: servicemix-sca Reporter: Kit Plummer The current state of the servicemix-sca codebase requires turning off the CheckStyle plugin in SMX/parent/pom.xml and installing it into the Maven repo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-761) JRuby support
[ https://issues.apache.org/activemq/browse/SM-761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37900 ] Kit Plummer commented on SM-761: Not sure if it is really related to this particular thread of discussion, but I can see where creating a JBI component (with the lifecycle features) in Ruby would be very handy. Not that writing simple services in Java is painful, but the deployment process, including the Maven build can be quite tedious. Swapping a file out of a Service Assembly and redeploying to ServiceMix would be very efficient from a development/testing perspective. JRuby support - Key: SM-761 URL: https://issues.apache.org/activemq/browse/SM-761 Project: ServiceMix Issue Type: Improvement Components: servicemix-script Reporter: Guillaume Nodet JRuby support should work with spring 2.0.2 + jruby 0.9.1 See http://forum.springframework.org/showthread.php?t=28798 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
