Eclipse Community Forums - RDF feed
https://www.eclipse.org/forums/
Eclipse Community ForumsCSpex when project folder name != bundle id
https://www.eclipse.org/forums/index.php/mv/msg/491249/1069347/#msg_1069347
The problem I'm running into relates to the fact that my eclipse project name (name of the actual folder resource) is different than the actual bundle symbolic name. I often have to package several different versions of the same library so we use the convention "symbolic.name_bundleversion" as the folder name to allow multiple source projects for the same library within the same workspace, version control branch, and ultimately into a combined p2 repository.
It appears that the Buckminster IDE tooling uses the project name (folder resource name) when resolving CSpex documents instead of the actual bundle id. When viewing the auto-generated CSpec contents, the resolution is correct (pulling the bundle id from the manifest). Is this a bug?]]>Terran Gilman2013-07-15T18:09:36-00:00Re: CSpex when project folder name != bundle id
https://www.eclipse.org/forums/index.php/mv/msg/491249/1069405/#msg_1069405
> I have a third-party library that i'm building from source and packaging as an OSGi bundle. I want to declare all of my
> dependencies through import package instead of require bundle. However, due to the nature of Buckminster dependency
> resolution only required bundles are actually materialized from the CQuery. To work around this limitation, I tried to
> add a CSpex to the source project for my bundle.
>
> The problem I'm running into relates to the fact that my eclipse project name (name of the actual folder resource) is
> different than the actual bundle symbolic name. I often have to package several different versions of the same library
> so we use the convention "symbolic.name_bundleversion" as the folder name to allow multiple source projects for the same
> library within the same workspace, version control branch, and ultimately into a combined p2 repository.
>
> It appears that the Buckminster IDE tooling uses the project name (folder resource name) when resolving CSpex documents
> instead of the actual bundle id. When viewing the auto-generated CSpec contents, the resolution is correct (pulling the
> bundle id from the manifest). Is this a bug?
It sounds like a bug although I don't know how it can happen. The cspex is just an overlay on the auto generated cspec.
It shouldn't change the name. Just to verify:
1. You view the auto generated cspec and you see the correct name (the bundle symbolic name).
2. You add a buckminster.cspex file to that same project.
3. You now view the auto generated cspec again and see the project name instead.
Is that an accurate description?
- thomas]]>Thomas Hallgren2013-07-15T20:37:27-00:00Re: CSpex when project folder name != bundle id
https://www.eclipse.org/forums/index.php/mv/msg/491249/1069432/#msg_1069432
Terran Gilman2013-07-15T21:56:24-00:00Re: CSpex when project folder name != bundle id
https://www.eclipse.org/forums/index.php/mv/msg/491249/1069460/#msg_1069460
Terran Gilman2013-07-15T23:26:32-00:00Re: CSpex when project folder name != bundle id
https://www.eclipse.org/forums/index.php/mv/msg/491249/1069817/#msg_1069817
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.]]>Terran Gilman2013-07-16T16:25:07-00:00