[pde-ui-dev] Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Exp

[Darin Wright <Darin_Wright@xxxxxxxxxx>]

Thanks Tom,

I agree - there should be two flags
- one for consumer and one for producer. And we should only flag the consumer
when the producer provides a version to import.

I like bundle versions for initial values
as well.

The initial severity of the problem
is up for debate - i.e. warn vs. ignore. If we warn, it adds a bunch of
noise. If we ignore, nobody is forced to fix the problems...

Darin

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

01/15/2008 02:39 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

Darin,

The bug report you refer to also mentions flagging when version ranges
are missing from the consumers (Import-Package/Require-Bundle). Turning
both the producer (Export-Package) and consumer (Import-Package/Require-Bundle)
flags to "warning" at the same time will likely cause some issues
when the producer has not yet added proper versions. Now consumers of the
package will not be able to fix their own warnings until the producer is
fixed because they will not have a version they can refer to. I guess they
could put a version of "0.0.0" to get rid of the import version
warning, but that would defeat the purpose.

Perhaps you should have two flags for this? One for the consumer (ignore
by default) and one for the producer (warning by default) of the package.
Another option would be to only flag the consumer of the package if the
producer has actually defined a version.

As I said earlier in the thread, I prefer using the current bundle version
as the initial package version if we are going to have a quick fix.

Tom

Darin
Wright ---01/15/2008 02:25:59 PM---PDE is planning to add support to flag
missing version numbers on package

From:	Darin Wright <Darin_Wright@xxxxxxxxxx>
To:	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Cc:	pde-ui-dev@xxxxxxxxxxx
Date:	01/15/2008 02:25 PM
Subject:	Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Package as API

---

PDE is planning to add support to flag missing version numbers on package
exports (https://bugs.eclipse.org/bugs/show_bug.cgi?id=205198).
The bug 
report suggest the default severity for a missing package version should
be "ignore", but I would suggest to start it at "warning",
and add a quick 
fix to set the initial version to match the current bundle version (if
we 
agree that the initial package version should be the initial bundle 
version).

API tooling will aim to add support to detect invalid version numbers on
package exports as content of a package changes - similar to the support
API tooling will provide for bundle version number validation.

Darin Wright




Thomas Watson <tjwatson@xxxxxxxxxx> 
Sent by: equinox-dev-bounces@xxxxxxxxxxx
01/11/2008 04: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


_______________________________________________
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