+1 for ignore with a possible compromise that if you create an bundle (OSGi) project then it could be set to warning.
Also note that it seems the API tooling team is trying to get in tooling that would flag cases where you evolved the code but not the package version number so John, you second concern should be addressed. Jeff John Arthorne/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 01/15/2008 11:13 PM Please respond to Equinox development mailing list <equinox-dev@eclipse.org> To Equinox development mailing list <equinox-dev@eclipse.org> cc Subject Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Package as API My vote would be to leave the default as "ignore" for now. There is a pretty large user community that is happy to version only at the plugin level, so it's not clear that the absence of package versions is wrong. The problem I see with the quick fix is that people may run it once to get rid of the warning, and then fail to evolve the version number as the package changes. I think it's better to have no package versions than to have package versions that are never incremented in a meaningful way. Also, x-internal packages generally don't need version numbers. Darin Wright/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 01/15/2008 03:19 PM Please respond to Equinox development mailing list <equinox-dev@eclipse.org> To Equinox development mailing list <equinox-dev@eclipse.org> cc [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 01/11/2008 04:24 PM Please respond to Equinox development mailing list <equinox-dev@eclipse.org> To Equinox development mailing list <equinox-dev@eclipse.org> 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 <[EMAIL PROTECTED]> To: Equinox development mailing list <equinox-dev@eclipse.org> 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 <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 01/11/2008 03:45 PM Please respond to Equinox development mailing list <equinox-dev@eclipse.org> To Equinox development mailing list <equinox-dev@eclipse.org> 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 <[EMAIL PROTECTED]> To: equinox-dev@eclipse.org 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 ----- [EMAIL PROTECTED] 01/11/2008 10:50 AM To Jeff McAffer/Ottawa/[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
