Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Package a

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

the EMF issue is that they use some
stuff from the org.eclipse.core.runtime bundle.  That bundle is tied
directly to org.eclipse.osgi.  EMF needs to get off the old runtime
stuff.  This is independent of how they spec their dependencies.

We should IMHO spec package versions
regardless of whether or not we use import package.  Others cannot
use import package safely if we do not spec them.  p2 uses import
package alot and we will have to start specing versions.

We already have tooling place that tells
us about api changes relative to another version etc.  The trick right
now is to get the version number management in place and at the package
level.  the API tools team has commented that this should be doable
but they have alot of other stuff going on and need to assess the priorities.

Jeff

Thomas Watson <tjwatson@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

01/11/2008 05:24 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject	Re: [equinox-dev] Fw: [Bug 214801] [api        tools]        consider        Export-Package        as API

I agree that tooling is needed in order to make this somewhat
feasable.

On the OSGi mailing list there was a question posted about using EMF on
another framework implementation. One of the issues was that EMF uses Require-Bundle
on org.eclipse.core.runtime. This ends up pulling in lots of dependencies,
one of which is org.eclipse.osgi. This makes it impossible to use EMF on
another Framework impl. If EMF instead used Import-Package to get its packages
then it is conceivable that EMF could have its dependancies resolved in
another Framework impl. But using Import-Package for the eclipse packages
without versions is dangerous because you do not know what you will get.

Eclipse team rarely uses Import-Package, this maybe because it is a bit
harder. But for now I would advise against it because it is dangerous without
versions. Until versions are established EMF should *not* move to Import-Package
IMO.

Tom

John
Arthorne ---01/11/2008 03:27:00 PM---I don't think we can even contemplate
this without full tooling automation. As Tom says, we struggle to keep
our bundle version

From:	John Arthorne <John_Arthorne@xxxxxxxxxx>
To:	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Date:	01/11/2008 03:27 PM
Subject:	Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Package as API

---

I don't think we can even contemplate this without full tooling automation.
As Tom says, we struggle to keep our bundle version numbers correct as
it is. We can maintain package versions manually up to a point, such as
base framework packages and service packages, but any wider scope would
become unmanageable. For most of the wider Eclipse team that rarely/never
uses import package, there is no immediate need to version at the package
level.

Thomas Watson <tjwatson@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

01/11/2008 03:45 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject	Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Package as API

Without tooling this will be difficult. If we wanted to use the big hammer
approach the we would have the API tooling (or plain old PDE) mark exports
without versions as a warning/error by default or update each project settings
in eclipse to make it an error. Now the question is what version would
all the well established packages use? Most eclipse packages do not specify
a version which means they have been using the default version of 0.0.0.
If a package is being versioned for the first time what should its version
be?

- Start off using 1.0.0
- Use the Bundle-Version

I favor using the Bundle-Version for well established packages because
if we decide to add versions to the maintenance streams then we have room
to downgrade the versions as appropriate. Completely new packages in a
release should start off with version 1.0.

I have been trying to version the exports of org.eclipse.osgi for the past
few releases. It is hard to keep track of without tooling. Just look at
how many times we forget to increment the bundle versions in Eclipse and
that is just one version number per bundle to maintain. Now we will have
to maintain each package version individually which is a much bigger task.
Hopefully more advanced API tooling could detect that the API package has
changed since last release and needs to be incremented. Does the new API
tooling currently do something like this for Bundle-Version? 

Tom

Jeff
McAffer ---01/11/2008 02:17:11 PM---Tom raises a good point that we keep
letting slide. Are we going to ensure that all export package statements
have version num

From:	Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
To:	equinox-dev@xxxxxxxxxxx
Date:	01/11/2008 02:17 PM
Subject:	[equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Package as API

---

Tom raises a good point that we keep letting slide. Are we going to ensure
that all export package statements have version numbers for 3.4? If we
have API tooling for this then it would likely be reasonable to start doing.
Even without tooling today, we could introduce version numbers based on
the bundle version number for this release and then evolve from there (with
tooling that will come in the future). 

Jeff 

----- Forwarded by Jeff McAffer/Ottawa/IBM on 01/11/2008 01:22 PM -----

bugzilla-daemon@xxxxxxxxxxx

01/11/2008 10:50 AM

To	Jeff McAffer/Ottawa/IBM@IBMCA
cc
Subject	[Bug 214801] [api tools] consider Export-Package as API

https://bugs.eclipse.org/bugs/show_bug.cgi?id=214801
 
Product/Component: PDE / Incubators




--- Comment #2 from Thomas Watson <tjwatson@xxxxxxxxxx>  2008-01-11
10:50:13 -0400 ---
I agree with the concept.  All exported packages which are not marked
x-internal:=true should be versioned.  Without this it makes using
Import-Package very limiting because you cannot specify what version of
the
package you require.  Packages marked as x-friends are questionable,
but I can
see friend bundles depending on a particular friend package version.


-- 
Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug._______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev