|
| Re: CSpex when project folder name != bundle id [message #1069405 is a reply to message #1069347] |
Mon, 15 July 2013 20:37   |
|
On 2013-07-15 20:09, Terran Gilman wrote:
> 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
|
|
|
|
|
| Re: CSpex when project folder name != bundle id [message #1069817 is a reply to message #1069460] |
Tue, 16 July 2013 16:25 |
 Terran Gilman
Messages: 67
Registered: July 2009 |
Member |
|
|
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:
Repository Root/
....org.apache/
........commons/
............plugins/
................org.apache.commons.jexl_1.1.0/
................org.apache.commons.jexl_2.1.1/
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.03729 seconds
] 
Search
Help
Register
Login
Home
