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
_______________________________________________ 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
|