SMILA/Project Concepts/OSGi Bundles

3rd party bundles

Juergen Schumacher Generally: There is an Eclipse project named [[1]] that cares about providing bundles for third party libraries that are often used in eclipse projects. We should probaby reuse those bundles as far as possible. See

org.eclipse.orbit

in CVS repository

:pserver:anonymous@dev.eclipse.org:/cvsroot/tools

for details.

Here is another source for OSGi-bundles third party libraries: [[2]]. Though coming from a Spring context, they seem to be just ordinary bundles that can used without Spring.

The Big Ones...

Here is the list of 3rd party components that need to be integrated in SMILA as a OSGi bundle: \\

• Tuscany SCA Java: [[3]] Version 1.1 has just been released. But i think we will often need current development snapshots because features that we need are still in development. So it would be cool to have an automated process that would get the latest snapshot from their SVN and create the bundles as we need them.
  • The Tuscany SCA Java source code contains a maven build script (in itests/osgi-tuscany) that creates five OSGi bundles that can be used in Equinox (committed to our SVN under [[4]]). However, they do not contain the Tuscany source code so debugging inside of Tuscany is not possible with them. While Tuscany itself provides eclipse project files that refer to the source code, they result in having about 100 additional projects in your workspace, so a more compact solution would be nice.

Tuscany comes with a lot of 3rd party libs itself. However, I am not sure at this point which of them are really all needed and which of the should be put in their own bundles. In fact, the next components on the list are all part of Tuscany SCA, too. But the binary release does not necessary contain the latest releases of the components. And again, we will often need the development snapshots of these components, too, because of enhancements we need, or bugfixes. Also, there are certainly quite a lot of 4th-party-components used by more than one of them:

• Tuscany SDO Java *ASSIGNED*: [[5]]
• Apache ActiveMQ Client Lib *ASSIGNED*: [[6]]: Probably it makes sense to seperate this into a generic javax.jms bundle and into a activemq bundle so that it would be easier to make SMILA independent of the actual JMS provider.
• Apache ODE BPEL Engine *ASSIGNED*: [[7]]; see also SMILA/Project_Concepts/Apache ODE bundle
• Apache Lucene *ASSIGNED*: [[8]]
• Berkeley DB for XML *ASSIGNED*: [[9]]; also see [[10]]
• Stellent *ASSIGNED*: [[11]]
• ActiveMQ *ASSIGNED*: [[12]]; also see SMILA/Project_Concepts/ActiveMQ bundle

Common libs

• Apache Commons *ASSIGNED*: [[13]] The above components already use a lot of them, so it makes sense to package them as seperate bundles.
• Apache Commons-IOUtils *ASSIGNED*: [[14]]
• Apache log4j *ASSIGNED*: [[15]]: Which versions? Move to 2.0?

JDBC drivers

We need a simple way to include deliberate JDBC drivers (depending on customer needs). For testing we need at least the following:

• PostgreSQL *ASSIGNED*: [[16]]: BSD License - is EPL compatible
• Oracle *ASSIGNED*: [[17]] Multiple versions, check License. Can we redistribute? Probably not. Have never seen it in other products.
• MySQL *ASSIGNED*: [[18]] GPL'd, so we cannot include it in distribution.
• jTDS *ASSIGNED*: [[19]]

XML processing

• Apache Xerces *ASSIGNED*: [[20]]
• Apache Xalan *ASSIGNED*: [[21]]
• SAXON *ASSIGNED*: See [[22]]