Re: [orbit-dev] [eclipse-dev] OSGi reintroduction to Orbit

[David M Williams <david_williams@xxxxxxxxxx>]

Krzysztof, 

I can't quite tell if you are complaining about an
issue with an existing Orbit bundle, or just that the "naming principles"
are not sufficient? 

In either case, you are welcome to open a bug to document
what you think should be changed, and what it should be changed to. 

> Yet another point:
> The wiki page shows certain age and neglects OSGi guidelines
>
http://wiki.osgi.org/wiki/Bundle-SymbolicName
which is very strict about
> BSN shape in maven environment.

I do not read that link the same way you do. It says,
"A BSN often takes the form of a reverse domain name.
If automatically generated via Maven
Bundle Plugin, 
takes the form ${pom.groupId}.${pom.artifactId}, or
${pom.artifactId} if it already starts with ${pom.groupId}. " ...
so, to me, that is talking 
about what one specific tool does, and that tool likely
(blindly) assumes that "groupId" and "artifactId" are
named correctly to begin with. Do you think they 
are for com.sun.mail:javax.mail? That is, is that
following well established maven conventions? [I'm sincerely asking ...
I'd be the last to know.]
That tool appears to be provided by the Felix project.
It's not bad a bad rule or assumption, but I think discussing how one tool
handles auto-naming 
is a far cry from claiming the "OSGI guidelines
[are] very strict about BSN shape in maven environment". So, the debate
will continue. 

> I know we can't remove Orbit, but I'd really love to see Orbit
> containing only snapshots of upstream builds.

"Snapshots" ... an odd choice of words given
the context :) I assume you mean "you'd like us to leave bundles as
they are, if they are already an OSGi bundle". I think Gunner has
already explained that is the intent. Have you found a place we do not
do that? Perhaps where was a reason for it. If, instead, you are saying
you'd like us to follow that Felix tool's choice for converting a maven
plugin to an OSGi bundle, instead of our own naming conventions, I think
that'd be a tough sell for us to do blindly. But, by all means ... please
continue to try and convince us that is the best thing to do, if you believe
it is true. 

Thanks for your observations, 





From:      
 Krzysztof Daniel <kdaniel@xxxxxxxxxx>
To:      
 Gunnar Wagenknecht
<gunnar@xxxxxxxxxxxxxxx>, 
Cc:      
 Orbit Developer discussion
<orbit-dev@xxxxxxxxxxx>
Date:      
 07/15/2013 05:07 AM
Subject:    
   Re: [orbit-dev]
[eclipse-dev] OSGi reintroduction to Orbit
Sent by:    
   orbit-dev-bounces@xxxxxxxxxxx

---

On Mon, 2013-07-15 at 10:29 +0200, Gunnar Wagenknecht
wrote:
> Hi,
> 
> Am 15.07.2013 um 10:15 schrieb Krzysztof Daniel <kdaniel@xxxxxxxxxx>:
> > Anyway, the point is that BSN change (or introducing it to upstream
> > project) is something undesired from the integrators point of
view, as
> > it fragmentates the software and blurs the origin of the library.
> 
> But we do require those name changes for *modified* libraries. Most
of the time, those modifications come from IP team requirements.

Understood. Are those modification kept somewhere? Are they contributed
upstream?

> For all other cases, the "policy" should be as outlined,
i.e. re-use original BSN if there is no other good reason not to. For all
others, it's documented here: http://wiki.eclipse.org/Bundle_Naming

I guess my problem goes into http://wiki.eclipse.org/Bundle_Naming#Issue_2_:_Evolution
where policy lists questions without answers :-).

Yet another point:
The wiki page shows certain age and neglects OSGi guidelines
http://wiki.osgi.org/wiki/Bundle-SymbolicName
which is very strict about
BSN shape in maven environment.


I know we can't remove Orbit, but I'd really love to see Orbit
containing only snapshots of upstream builds.

> -Gunnar
> 


-- 
Krzysztof Daniel <kdaniel@xxxxxxxxxx>
Red Hat

_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev