Some random thoughts in random order...
- At some level the problem is similar to the
Bundle-RequiredExecutionEnvironment problem. There are certain core
framework implementation features that a bundle might need (e.g.,
fragments, buddy loading, ...) and the services that are required.
- Note that the BREE is somewhat overloaded. It is used to talk both
about the language level features of a EE and the base class library.
For example, people often think they need Java 5 because they want to
use JMX (you can get JMX addons for Foundation 1.0). So in this context
it is the same as people saying they need Felix/Equinox because they are
using a service bundle that comes from that team.
The Import/Export-Service headers have been deprecated but perhaps they
can be revived and enhanced for this use.
- having markup in OBR is cool but it would be good to make this
independent somehow. Not all provisioning systems are going to use OBR
metadata. One idea was to have info to be in the manifest and then
systems like OBR and p2 can extract and construct their metadata however
they like. much of this data is relevant to resolution so having it in
the manifest is relevant.
- Somewhat aside, we have sound it useful for producers to spec
intentions as well as reality. This tells the community, for example,
that we want this bundle to work on any framework but for now it only
works on Felix. This kind of info may not be in the manifest but its
likely good to keep the usecase in mind when putting together the other
infrastructure.
Like I said, random thoughts in random order...
Jeff
Karl Pauls wrote:
On Feb 8, 2008 6:20 AM, Jeff McAffer <[EMAIL PROTECTED]> wrote:
We've been suffering from this "framework tainting" for quite sometime
now. Equinox ships many bundles/services that work on other frameworks
(as well as ones that work without OSGi at all!). The Equinox community
(well at least me) would like to participate in figuring out a way to
depict or communicate the state or expectations of bundles.
In my ideal world this information would be somehow included in or
associated with the bundles so that website tables could be
autogenerated and provisioning systems could filter accordingly. I can
see a lot of issues in setting this up but also feel it is worthwhile to
do and to do in sort of common approach so the OSGi community gets a
consistent picture.
Thats sounds like a very interesting idea. There is some data
available already in the manifest of a bundle but adding a pointer to
a standard documentation extension would be nice. Maybe we could make
it something that could point to something inside the bundle or to a
remote location (that way a bundle could come with or without it). It
sounds like this could be potentially something that could be combined
with OBR as well, no?
regards,
Karl
Jeff
Richard S. Hall wrote:
Stuart McCulloch wrote:
also the subproject documentation that is there is (imho) not visible
enough
( have to click Documentation->...um...->Subproject
Documentation->aha... )
perhaps we could add a direct link to the subprojects page from the main
page?
Yes, something like that would be a good idea too. Our menu on the
side is getting a little long, though, so perhaps there is some way to
shorten it to make it more useful, e.g., grouping related items into a
new page so that they only have one link in the menu.
yes - a matrix of bundles against frameworks/EE would be really cool
and we
could perhaps find a way to display it on the main page (in reduced
form, so
it doesn't takeover the whole page, but shows our bundles can be used
with
many other frameworks)
each sub-project page could have a banner at the top with specific
results
Yes, exactly my thinking.
+1 for something like a matrix, but I'm no good at web-design ;)
Me either and currently lack any time.
-> richard
-> richard
Guillaume Nodet wrote:
On Jan 15, 2008 8:32 PM, Richard S. Hall <[EMAIL PROTECTED]> wrote:
Further, I am not really certain about what is being said here. This
thread seems to imply that if we did "rm -rf framework" in our trunk
directory, then it would be possible for our bundles to be seen as
framework independent and good OSGi citizens. However, since one
of our
subprojects happens to be a framework implementation, then all of our
subprojects are tainted and seen as "Felix-only"? Is that right?
I think the situation is a bit more complicated. We have the same
problems
in ServiceMix where we have both a JBI container and JBI components.
I think users are tempted to assume that there is an implicit tie
between
the runtime and the services provided. OPS4j does not provide any
OSGi
runtime, thus, it easier to look at it as independent of the runtime.
