|Re: CSpex when project folder name != bundle id [message #1069817 is a reply to message #1069460]
||Tue, 16 July 2013 16:25
| Terran Gilman
Registered: July 2009
I'm basically maintaining an Orbit-esque p2 repository for third-party libraries that are already or that I have converted OSGi bundles. My intention is not to replace Orbit, as I think it's a great effort, but to augment the number of libraries available as OSGi bundles. As Orbit grows, I always remove the duplicate bundles and delegate their hosting to Orbit. However, I have some special needs and constraints:|
1) All my bundles use Import-Package instead of Require-Bundle to ensure maximum compatibility regardless of the environment they may be deployed into. For binary packages, this doesn't really pose a problem. However in the case of projects that build from source, the fact that Buckminster only inspects the Require-Bundle metadata when performing dependency materialization, I need some way of declaring a set of actual plugin ids/versions the source bundle requires to build successfully.
2) I need to support having multiple versions of the same library published into the p2 repository. I could create a separate repository for each bundle version and then join them into one giant compound repository, but this seems to be very over complicated and brittle from a release engineering point of view. To avoid that, I separate bundle versions by including their version information in their folder name within the source repository and within the eclipse workspace. For example:
This works quite well if the bundles use Require-Bundle, but as with #1 putting a CSpex into this folder doesn't work when the folder name is different than the actual bundle id. What I've done is to move the dependency specification to the parent feature project.
3) The p2 repository that is generated needs to only include the bundles I'm maintaining and not any of the dependencies that were pulled in from other repositories such as Orbit. As I said before, I want to augment what's already out there and not simply repackage and host their content. I was originally accomplishing this by having two separate trees for features: one for materializing the workspace and building (think hudson) and one for generating the actual p2 repository. This was a lot of additional work. I moved to leveraging CSpex to handle the materialization but ran into my current issue.
I can work with putting the CSpex into the parent feature for now as it seems to work for what I need. I guess I'm looking for advice on if my issue is a bug or just not something that should be done or if there is a better way to build this mouse trap.
Powered by FUDForum
. Page generated in 0.10524 seconds