felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Litton" <Rick.Lit...@ktd-kyocera.com>
Subject RE: Felix Product Plugin and/or Initial Provisioning Service?
Date Wed, 19 Apr 2006 19:08:49 GMT
Thanks again for the info.  I'm currently on 3.1.2 and will probably
look into 3.2 shortly as suggested.  Out of curiosity (and this is
addressed to everyone), is anyone thinking about implementing extension
points in Felix?  If there has been such a plan, I must have missed it.
Got to look into my junk email folder again... ;)

-- rick

-----Original Message-----
From: Jeff McAffer [mailto:Jeff_McAffer@ca.ibm.com] 
Sent: Wednesday, April 19, 2006 10:46 AM
To: felix-dev@incubator.apache.org
Subject: RE: Felix Product Plugin and/or Initial Provisioning Service?

You should get on Eclipse 3.2.  We are locking down now so things are 
pretty stable.  If you were back on 3.0 you will notice alot of changes 
around bundle tooling etc.  There are also more launch facilities in 
support of developing and running/debugging/testing bundles etc.  Check
it 
out and see. 

The plugin.xml file is still used but just for extension and extension 
point declarations.  Everything else is pretty much standard OSGi and
goes 
in the manifest.mf.

Jeff




"Rick Litton" <Rick.Litton@ktd-kyocera.com> 
04/19/2006 01:33 PM
Please respond to
felix-dev@incubator.apache.org


To
<felix-dev@incubator.apache.org>
cc

Subject
RE: Felix Product Plugin and/or Initial Provisioning Service?






Jeff,

Thanks for clarifying this up.  It is apparent that I have not worked on
PDE in Eclipse 3.1.  Does this mean that the plugin.xml file is done
away with?  Is it an optional feature? 

-- rick


-----Original Message-----
From: Jeff McAffer [mailto:Jeff_McAffer@ca.ibm.com] 
Sent: Wednesday, April 19, 2006 10:26 AM
To: felix-dev@incubator.apache.org
Subject: RE: Felix Product Plugin and/or Initial Provisioning Service?

Historically the plugin.xml was the plugin manifest but that changed in 
Eclipse 3.0 (June 2004) with the adoption of OSGi as the underlying 
runtime framework and the move to the plugin==bundle mentality.  As of 
3.1(June 2005), we fully adopted the "manifest.mf defines a plugin" 
notion.  Due to some of that history if you open a plugin.xml or a 
manifest.mf in the IDE you get the same editor with different tabs along

the bottom for the different aspects of a bundle (e.g, dependencies, 
runtime, overview, extensions, ...).  The values you enter there are in 
fact stored in collection of different files depending on the data.
Going 
forward there is some discussion of adding Declarative Service related 
tabs to that editor making it a one-stop-shop for things relate to the 
bundle.

In any event, I don't think there is (should be) much of a shift when 
moving between Equinox, Felix, ...  There certainly will be some 
differences and where those are annoying/problematic/goofy we are all
for 
working together either in the OSGi context of simply as open source 
communities to make things better for OSGi adoptors.  Please do
highlight 
issues and incompatibilities wherever you see fit (felix-dev,
equinox-dev, 
bugzilla, jira, osgi-dev, ...)

Jeff




"Rick Litton" <Rick.Litton@ktd-kyocera.com> 
04/19/2006 12:04 PM
Please respond to
felix-dev@incubator.apache.org


To
<felix-dev@incubator.apache.org>
cc

Subject
RE: Felix Product Plugin and/or Initial Provisioning Service?






Jeff,

As I was cleaning up my junk email folder, I was *shocked* to find your
email.  Somehow, our email server decided to place it here for some
reason. And I thought that I was totally being ignored... ;)  To respond
to your question, I was referring to the use of extension points and
plugin.xml file for configuration in addition to the modifications to
the bundle manifest file that you mentioned.  Don't get me wrong, I do
like the concept of extension points.  In fact, I implemented this
concept (as well as the plugin.xml) where I work.  Interestingly,
Eclipse calls the plugin.xml as the plug-in's manifest file as opposed
to the bundle manifest file that comes with the jar.  Hope this helps!

--rick


-----Original Message-----
From: Jeff McAffer [mailto:Jeff_McAffer@ca.ibm.com] 
Sent: Tuesday, March 14, 2006 6:58 PM
To: felix-dev@incubator.apache.org
Subject: RE: Felix Product Plugin and/or Initial Provisioning Service?

"Rick Litton" <Rick.Litton@ktd-kyocera.com> wrote on 03/14/2006 12:34:05

PM:
> Pardon my ignorance on initial provisioning...but are you referring to
> the Eclipse Plug-in Architecture?  If so, adoption of this
architecture
> is a major shift in current Oscar or Felix thinking.  For one thing,
> reconciling the bundle manifest with the Equinox version is a major
> undertaking.  Regards.

As a point of interest, can you clarify how you are differentiating the 
Eclipse plugin architecture from the OSGi bundle model?  Eclipse plugins

ARE OSGi bundles and Equinox is a standalone implementation of the OSGi
R4 
spec.  It is true that Eclipse adds a couple of additional headers to
the 
manifest and we have a mess of additional services but for the most part

these headers can be (and are) safely ignored when running on
non-Equinox 
frameworks and the additional services, like any service, can be either 
reused or re-implemented as needed.

I don't want to over sell anything here.  The reality today is that most

Eclipse bundles will not run on other existing OSGi frameworks.  This is

either because a) other frameworks do not fully support R4 (fragments
and 
require-bundle figure heavily in Eclipse) or b) some of the Eclipse 
codebase makes implementation assumptions about the framework (Equinox).

The former is changing as Felix and Knopflerfish work towards R4 
completeness.  The latter is still evolving.  The Eclipse codebase is 
large and we are reworking individual bundles as the need/demand arises.

In general the Equinox bundles are are clean of Eclipse assumptions.

Jeff



Mime
View raw message