Re: [equinox-dev] OBR

2008-01-11 Thread Jeff McAffer
Great! Never having looked at the OBR implementation I can't really say which is the best path. I'm imagining that they have some code that reads repositories and some code that does resolution etc. What you need is the repository reading/parsing code. You would take that input information

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

2008-01-11 Thread John Arthorne
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

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

2008-01-11 Thread BJ Hargrave
You need to, as part of the release process, use tooling, like japitools, to examine each package for changes, including non-backwards compatible changes. Then, at the end of the release, the package and bundle version numbers can be properly increased. We do this in the OSGi release process.

Re: [equinox-dev] OBR

2008-01-11 Thread Thomas Hallgren
This makes a lot of sense. We don't have any use for the artifact fetching. Our objective is to be able to publish OSGi bundles to a generic repository (in the spaces project) and to be able to consume OBR's from Buckminster. The latter might well be Buckminster consuming p2 IU's that in turn

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

2008-01-11 Thread Thomas Watson
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