Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ebr-dev] Bundle Naming

Gunnar has it exactly right: we don’t want to change the package names — ideally these recipes could/would disappear once we’ve helped fix the bundles upstream.  But we do want to indicate provenance.  This is a problem I’ve encountered with many of the Orbit bundles whose upstream have now provided properly- (or sometimes improperly-) bundlefied jars.

I wonder if we couldn’t put the EBR prefix into the version qualifier instead?

com.thoughtworks.xstream 1.4.7.EBR-v201407161345

The downside is that it doesn’t help when rebundling existing broken jars.  I can’t create a feature/product and have absolute certainty that the fixed EBR bundle will be included.

In terms of naming, my preference is to use a bundle suffix of ‘.ebr’.  It allows the bundles to sort naturally, and IDE helpers that support searching with partial-matching by bundle prefix, such as PDE’s Open Artifacts (Ctrl-Shift-A), works too.  I used to get confused as to whether a product used javax.mail as I normally used the SpringSource com.springsource.javax.mail variant.

Ideally we could make the naming policy configurable: the BSN doesn’t have to match the Maven EBR artifact, right?

Brian.

On 18-Jul-2014, at 5:12 PM, Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx> wrote:
Am 18.07.2014 um 23:05 schrieb David M Williams <david_williams@xxxxxxxxxx>:

I'm still not sure I understand, so would appreciate understanding ... how does a prefix on the bundle name, help someone at runtime, if they use import-package (and, they don't have complete control over what someone has installed there)? Or, perhaps another way of asking what I am not understanding, what problem does this solve? (And, which problems does it not solve?)

I’ll give it a try…. I believe it’s the problem of manual verification. The prefix will be part of the file name. Therefore it’s easier to spot where a jar came from. One doesn’t have to look into a jar and search for a manifest.

So it’s not a runtime issue. I think it should be totally transparent at runtime.

-Gunnar


-- 
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx





_______________________________________________
ebr-dev mailing list
ebr-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ebr-dev


Back to the top