Bringing this up again just to remind people to keep thinking about it. If we can get Tuscany integrated with other projects then the community around those other projects is opened up to joining the Tuscany community. People using that other project get exposure to Tuscany and might ask for help on the Tuscany mailing lists, report or fix our bugs, or even potentially help write new functions to make it work better. Any new participation is good for Tuscany and helps grow our community.
When Tuscany contributors become involved with other projects it helps our graduation chances. If people on the IPMC know us as helpful from our participating in other projects then they are much more likely to vote for us than if we're a bunch of unknowns. We use lots of other Apache projects in Tuscany so there's plenty of potential for contributing something back. How many times have you found some deficiency with one of the projects we use and not done something about it or even told them? It doesn't have to be through writing a lots of new code it can be all the same things we'd like people to be doing on our project such as participating in mailing list discussions, updating/correcting documentation, reporting bugs, reviewing new releases etc etc. ...ant On Nov 22, 2007 9:42 AM, Simon Laws <[EMAIL PROTECTED]> wrote: > There are quite a few Apache projects that Tuscany is already using in one > way or another. Looking through the list of all the projects on the Apache > web site gives some inspiration for other things that we could look into. > Here is a summary of a quick spin through the list trying to pick out the > Apache projects that we do/could use or that could possibly use Tuscany. > In > reality I know very little of the details of these project so this is pure > speculation. But if there are experts out there with an interested in > Tuscany we could come up with some real ideas. > > From this list the MINA project looks immediately interesting to me as it > could help out with some more performant default bindings and 'in JVM' > bindings using pipe IO. Also the OFBiz project is something that I hadn't > come across before and could provide some useful use cases. The OFBiz site > talks about a "Loosely coupled multi-layer component architecture" and it > set me thinking about how their components might sit in an SCA runtime. > > Anyhow if anyone has ideas (or time:-), or if this is already happening > and > it just isn't very visible, then it would be great to hear. > > ActiveMQ > We use in binding.jms and binding.ws > Are there adapters on ActiveMQ side that could be constructed > Coccon > Could we include SCA components in the component pipeline? > Commons > There are parts of Tuscany that could be more generally useful, for > example, > graph driven databinding framework > a scdl4j tool could be built > Validation > Could validation be used with SCDL > Data > Does DAS have a role here? > Directory > LDAP DAS > Use Directory as a registry implementation > Felix > We are using this for our OSGi support > Harmony > Could we get Tuscany running on Harmony? > James > Wrap James components with SCA services? > MINA > Could use as the domain transport > Develop a MINA binding > Myfaces (Tapestry, Struts, Tiles, Turbine, Wicket, Sling) > There are many tools related to web app development > We could certainly use some of these tools in any monitoring and > management apps we need but is there value in tighter integration? > For example, Turbine talks about SOA, could we provide some > infrastructure for them? > ODE > We are using this for our BPEL support > We could offer a patch to update their website to include Tuscany as a > user > OFBiz > Looks interesting as they talk of services and components and of service > based logic > OpenJPA > We use this in our new openJPA implementation > I don't know if we a re contributing to the project though. > Portals > Could we do something along the lines of wiring in portlets as part of > an > SCA composite like we do with javascript > Velocity > Be interesting to have a velocity implementation type > Not sure how refs would be done > Synapse > Has been discussed on the mailing list. I believe, in the first > instance, > the proposal is to use SCA composites as a configuration alternative. > Be interesting to look how be can introduce it to the SCA domain > Muse > We some management interfaces and WSDM is an option > Abdera > Use as an alternative Atom engine (we use Rome at the moment) > Cxf > Could resurrect the CxF binding. There used to be one but it doesn't > work > anymore > CxF could have an SDO binding > FTP > Would be good to have an FTP binding in a similar vein to the HTTP > binding > Could be used as a deployment vehicle in the distributed runtime case > Lokai > Don't know the details of this but we need some management framework so > we should look to see what this does > Qpid > We could use as an alternative messaging transport. Plug into > binding.jms > ? > ServiceMix > We could connect to it > Could configuration be described (as has been proposed for Synapse). > Camel? > How could it be included in the SCA Domain? > StdCxx > I seem to remember discussion about this re. the Native runtime. Can't > remember whether we use it or not now. > XAP > Could we integrate with our Web2.0 story > > Regards > > Simon >
