Re: [orbit-dev] Remove of ".orbit" suffix from recipes

["David M Williams" <david_williams@xxxxxxxxxx>]

Yes ... but, those sound like at best enhancement
requests.  Plus, it only helps "human readers" ... no runtime
assistance. 
And nothing that would justify causing
the ?thousands? of our consumers to break or change their code. 

Not to mention, if we do things right
(and others do things right) they should be interchangeable and not cause
conflicts. 
I have not heard of enough conflicts
to justify the churn. 

I don't mean to be argumentative, merely
trying to set expectations. Stability and OSGi correctness are our prime
directives. 

P.S. IMHO, spring used their own name
space because their packaging and bundles included modifications and constructs
that were highly specific to their needs. I do not have any first hand
knowledge of the project, but have looked at a few of their bundles in
the past. 





From:      
 Brian de Alwis <briandealwis@xxxxxxxxx>
To:      
 Orbit Developer discussion
<orbit-dev@xxxxxxxxxxx>, 
Date:      
 02/08/2016 10:50 PM
Subject:    
   Re: [orbit-dev]
Remove of ".orbit" suffix from recipes
Sent by:    
   orbit-dev-bounces@xxxxxxxxxxx

---

I would also be interested in hearing how the client
ended up with conflicting bundles. 
Was it just from "installing different things"? Or was it because
their own build was 
not precise enough? Or … something else?

It’s been several years and I no longer have access to
the code, but hey are the same issues identified in the Orbit Bundle
Naming page around evolution and naming clashes.
 In particular they had an internal team bundlify several libraries
with same bundle names but conflicting version numbers.

It can be revisited, but I can't imagine that changing
the bundle id would 
ever be the right answer.

I think the SpringSource Bundle Repository did the right
thing prefixing its bundles.  I think Orbit errs in using the publishing
group’s reverse-DNS as the bundle’s symbolic name with no identifier
indicating that it comes from Orbit.  I think branding the Bundle-SymbolicName
is a good for two reasons:

• It clearly identifies the bundles as being from Orbit (a ‘blessed’ bundle), and it avoids conflicts/clashes.  Guava 15 is an example of being ‘blessed’: Guava has been including OSGi metadata since 12.0, and the Guava-provided jar looks virtually identical to the version in Orbit except that ours is signed and has a build qualifier.
• It also distinguishes fixed bundles.  Some of our Orbit bundles fix badly produced metadata, in which case we want to ensure we don’t pick up the faulty bundles.

Brian.

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