Hi Nicole,
Comments below. One general thing is if you have code it is better to
submit it as small patches, even if incomplete, than one big patch.
That makes our job committing it a little easier and also allows
people to comment or get involved early on. So, even if it is still
rough, we could add the code into the sandbox (the likely place if it
is a work in progress) or trunk and work on it incrementally. Let me
know.
Jim
On Nov 24, 2006, at 12:37 PM, Wengatz, Nicole wrote:
Hi Joel and Jim,
I'm trying to find out what's the best way for us to create for
the SCA extensions (packaged as JAR) the required OSGi bundles.
Currently I see two possibilities:
1) Maven-OSGi-Plugin
The Maven OSGi Plugin (under development at the Apache Felix project)
allows
you to generate OSGi bundles out of standard JARs. You have to
configure
the path
to the manifest (which could be a standard java manifest). Additonal
headers
like Bundle-ClassPath, Export/Import-Package, Bundle-Activator can be
defined.
Configuration happens in the pom.xml file.
From my point of view we could use it for the OSGi container. The only
'problem'
is that the values in the pom.xml have to be hardcoded, we cannot get
them easily
out of the scdl file.
Further information can be found here:
http://cwiki.apache.org/FELIX/osgi-plugin-for-maven-2.html
I've used the plugin to generate bundles for the OSGi launcher in the
trunk and ran into a bunch of problems with it being too aggressive
about transitive dependencies (going down to the JDK's internal
classes). I haven't used it enough though to have a good opinion
either way as whether to use it. That aside, my inclination would be
option 2 as you outlined below.
2) Creation of virtual bundles
One other possibility which might fit for Tuscany is to generate
virtual
bundles
on the fly out of the JARs. The OSGi-Spring integration provides this
virtual bundle functionality, see:
http://www.springframework.org/osgi/specification
I had a look to the Source Code. The spring-osgi-core bundle
provides a
class
VirtualBundleFactoryBean which allows you to create a bundle. It
provides methods
to set the version, the artifactId, groupId, exports, imports etc.
The bundle does only exist in the RAM, not on the disc, it's virtual.
I could imagine having something like an
Extension-Directory-Listener-Bundle which
read the configured information out of the scdl files in the extension
JARs
and creates via the VirtualBundleFactoryBean for every extension a
bundle.
Does every extension bundle require its own bundle context? I'm asking
because this might be
difficult to achieve with this approach.
I'm not sure. What we need is the ability to have the following:
There is an Extension which is distributed as two jars, Foo and Bar.
Foo contains the "core" extension classes which must be isolated from
an application. Bar contains classes an application may use to
interact with the extension. Bar would therefore need to be visible
to the application and Foo would need to be visible to Bar. It could
also be the case that Bar may need to be visible to Foo. Here is what
I think this would look like in OSGi:
Foo -----> imports Bar
Bar -----> imports Foo
Application ---> imports Bar
I think the best thing would be if we could have virtual bundles
created out of the jars. For example, the SCDLs for Foo and Bar would
declare their dependencies (the format is being worked on in the spec
group for this, Jeremy, do you want to comment more here?). The SCDL
information would be loaded and the bundle would be created. The
application could work the same way or it could also be a native OSGi
bundle, which would mean no virtual bundle would need to be created
in that case. Does this seem doable with virtual bundles?
Jim
What do you think, can we use one of the proposed possibilities?
Thanks
Nicole
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
