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
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
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.
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
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
