[equinox-dev] new version of equinox aspects available

2008-01-11 Thread Martin Lippert
Hi all, I am pleased to announce that a new version of equinox aspects is ready for download. The new version 1.0.4 fixes two bugs and works well with Eclipse 3.3.1.1 and AJDT 1.5.0. Fixed bugs: - folder layout of feature within the download zip is now correct - aspect weaving works without

Re: [equinox-dev] OBR

2008-01-11 Thread Thomas Hallgren
I agree with this and I'd be willing to actually write the OBR repository adaptor for p2. Would you agree that the simplest way to do that is probably to write it on top of the OBR API's and the Felix bundle repository implementation? - thomas Jeff McAffer wrote: We currently do host an

Re: [equinox-dev] OBR

2008-01-11 Thread Jeff McAffer
We currently do host an OBR repo with the major releases. Don't remember the URL but the required repository.xml/zip file is there for Callisto and Europa. The OBR client code may be interesting but our strategic direction is p2. For the most part p2 has (or can be made to have) the same

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

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

2008-01-11 Thread Jeff McAffer
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

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

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

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