Re: [osgi-dev] version of packages

[erwindl0]

That's an interesting perspective.

I was considering the choice of using Require-Bundle versus using 
Import-Package, more in the context of allowing the provider to 
rearrange packages in different bundles, across time. Not in the context 
of versioning.


thanks
erwin

Op 10/08/2015 om 11:14 schreef Peter Kriens:
What value does the consumer have when the provider ignores semantic 
versioning? You might then (accidentally) resolve but what would it 
mean? If you repeat this over a large number of bundles you just 
created a lot of work without any benefit.


If the provider does not use package exports, it is easier to use 
Require-Bundle because the package versions are then just busy work imho.


Therefore, in my world it be a deterioration if we made the bundle 
version the default (I think this was a very bad decision in the 
bundle plugin). You would imply some semantics that actually do not 
exist. Again, if you have a single build that creates all artifacts 
then your model works, but having no package versions would also work 
just as well.


But don’t let me stop you, bnd supports what you want:

Bundle-Version: 4.1
-includeresource: classes
-exportcontents: *;version=${Bundle-Version}

Kind regards,

Peter Kriens

On 10 aug. 2015, at 10:53, erwindl0 erwin...@gmail.com 
mailto:erwin...@gmail.com wrote:


Hi Peter,

Thank you for your detailed reply. I also feel the OSGi versioning 
approach is stronger than e.g. the maven approach.
Maven is all about their artifacts (jars), and when combining this 
with their snapshot/release and their pom/parent-pom systems, ends up 
being very limiting and complex.


On the other hand, if for whatever reason an Export-Package does not 
specify a version, the current default behaviour seems to consider 
this as a 0.0.0/unspecified.
So an Import-Package statement can not set a version either, or it 
won't resolve.


Which means that when the provider is not sufficiently strict in its 
manifest, the consumer side is also forced to forget about versioning 
constraints...


Wouldn't it be an improvement to use the bundle version as default 
value for exported packages with unspecified versions?
That would still allow the conscious people to follow all good 
practices completely, while also easying the entry from more 
maven-based thinking into the world of OSGI ;-)
I.e. they could already start working with clear dependency mgmt, 
Import-Packages with versions etc.


kind regards
erwin

Op 07/08/2015 om 15:12 schreef Peter Kriens:
Package versioning allows you to do semantic versioning, when you 
use the bundle version as package you’re just wasting manpower and 
CPU cycles since there is no benefit.


In OSGi, semantic versioning is a powerful tool because it allows 
you to significantly minimize the amount of work you have to do for 
minor changes. In contrast with maven, the OSGi package model with 
semantic version does not require changes in the metadata whenever 
there is a small change in a dependency because the semantic version 
signals if that change is compatible or not.


If you version all packages with a bundle version you are not 
telling anything about those packages compatibility anymore. If you 
want to signal anything, you should at least take the maximum change 
of any of its constituent packages. So now whenever you make a major 
change for one package, all packages are major changed.


Then again, if you use maven it is already impossible to take the 
benefits of semantic versioning during development time because 
maven creates a rigid hard coded graph. I.e. if a dependency 
changes, however minor, all upstream dependees must adjust their 
pom. That is partly why releasing on maven is so hard, you need to 
change all metadata when you go from snapshot to release.


So it all depends. If you have a single build and all gets build 
together, who cares about package versions? Only if you share 
binaries with others are package versions important. However, there 
is more than just package versions, you also have to follow the 
architectural rules.


Semantic versioning in OSGi shines if you follow the best practice 
in software engineering. You use small cohesive bundles that are 
coupled via services. Since services have a well defined contract 
you can then semantically version the contract. The advantages of 
this model are tremendous but you need to have experienced it to 
believe it :-(


That said, I know how hard it is to achieve that level in most 
software organizations. Codebases are more often than not highly 
coupled monsters. Management rarely understands what causes the 
costs. And developers usually prefer to spend umpteen hours to 
prevent getting a budget for doing it right.


So, best of luck! :-)

Kind regards,

Peter Kriens








On 6 aug. 2015, at 21:16, Endo Alejandro 
alejandro.e...@grassvalley.com 
mailto:alejandro.e...@grassvalley.com wrote:


Hello,


I understand all the disadvantages of using require-bundle over

Re: [osgi-dev] How do you use OSGi?

[erwindl0]

Hi Sergey,

My 2cts : service interfaces should be seen as strict contracts.

If someone makes an incompatible interface change, by definition the 
intention is to "break" client expectations/implementations ;-)


Then it's up to the provider to decide whether to maintain old and new 
versions operational, or whether to force all clients to adapt/upgrade.


This is independent from the topic of allowing to implement a 
"micro-services" approach locally (and remotely) as OSGi does, or 
whether to lock-in to one particular remoting protocol as REST is.


cheers
erwin


Op 30/05/2016 om 12:46 schreef Sergey Beryozkin:

Hi Peter

On 30/05/16 11:38, Peter Kriens wrote:

REST or indeed other forms of designing the way the remote client and
servers communicate with each other is IMHO quite orthogonal to what
OSGI is about.

I think you take a too literal view in this case.

Both REST and OSGi services are about loosely connecting software blocks
using an explicit API and end-point. This architectural pattern is the
successor of object oriented technology and imho the biggest value. The
advantage of OSGi over REST is then that with OSGi there is no overhead
so you can leverage this powerful pattern for even the smallest of
problems.

A good proof-point of this pattern is the ease in which an OSGi service
can be mapped to REST without having to know anything about REST using
Distributed OSGi or, for example, OSGi enRoute REST support.


And then once an interface changes the client code gets broken. And to 
avoid it people will go the super interfaces way. I'm sorry, I'm not 
really after hijacking this thread with possibly off-topic remarks 
:-), I'm only thinking that comparing OSGI vs REST is not very effective.


Thanks, Sergey



Kind regards,

Peter Kriens




On 30 mei 2016, at 11:07, Sergey Beryozkin > wrote:

Hi Peter

I only have one comment,
On 23/05/16 14:03, Peter Kriens wrote:

I think I agree with your analysis, despite the grains of salt. I find
the true innovation of OSGi the service model. To me, the service
oriented model truly allows you to decouple modules. It is hard 
work to

take an existing application with all its hairball characteristics and
turn it into a clean architecture that the OSGi service model requires
as well enforces. Trying to adapt the old patterns of class loading
hacks and overuse of statics (global variables!!) to a modular world
requires an effort. (As Jigsaw will demonstrate to non-believers.)

The interesting things is that core aspect of this service model is
becoming highly popular in a different form: micro-services. OSGi 
allows

you to reap the benefits of this architectural design primitive with a
MUCH lower cost (both performance and developer cost) than the rather
expensive REST services that are common outside OSGi.


REST or indeed other forms of designing the way the remote client and
servers communicate with each other is IMHO quite orthogonal to what
OSGI is about.
DOSGI would be the closest one here and indeed one can use arguably
expensive HTTP calls or more effective RMI/etc calls in between OSGI
consumers and services, but IMHO it is a rather different conversation
which communication style between remote parties works best :-)

Cheers, Sergey

This allows you to
reuse this design primitive in even the lowest layer of your
architecture, creating many synergies. It never ceases to amaze me how
little code you need to write significant functionality in a properly
setup OSGi system. Configuration Admin, Declarative services, Remote
Service Admin, Event Admin, and many other services are vertical
building blocks that can be used in an amazing number of applications.

That said, also the Capability model we’ve added over the years 
provides

a software management model that I think is highly under-appreciated.

I’ve sold objects from the early 80’s until they became solidly
mainstream around 2000. I know I’ve tried to sell the service model
since that time because it addresses some scalability problems in
objects. (Transitive dependencies.) Its been a long time but I still
believe that OSGi services are a similar innovation as objects were in
the early 90’s. And I therefore still have hope that one day people 
will

understand how much cleaner you can make your software systems by
embracing that service model.

Kind regards,

Peter Kriens




On 23 mei 2016, at 13:34, Craig Phillips 
> wrote:


My response below does not necessarily apply to myself, but is what I
regard the reality of the situation (which I deem unfortunate):

 With OSGi, you have to be "all in" ;

I would be nice if OSGi were to have been built in to the Java
language from the very beginning. If that were the case, I would not
be making this post / reply.

As for myself, I have worked with the "boot delegation" aspects to
allow OSGi-based 

Re: [osgi-dev] Help

[erwindl0]

+1

Op 10/20/2016 om 2:35 PM schreef Simon Chemouil:

Hi Peter,


Peter Kriens a écrit le 20/10/2016 13:52 :

I did a quick check on the last messages on this list:

[snip]

So out of more than 60 messages, there were only 5 messages related
to OSGi enRoute. Are these your problem? Since I will spend much less
time on OSGi enRoute a new release is unlikely.

Maybe I am wrong to characterize it as enRoute. I don't know.

I do count those Zigbee messages, the native library
loading, and so on, as enRoute support. Mostly because the authors come
with a "Help me solve my whole problem" mindset, and I believe they came
to post here because they are trying enRoute (because they said so).

Karaf's ML has a lot of similar "general questions about Java/shell
help/OSGi" threads, because many Karaf users consider the whole of it as
a stack and often don't know where to ask (or don't care since they get
help wherever they ask anyway!). I believe Karaf has split their lists
between karaf-users@ for general purpose and karaf-devs@ and for more
specific spec/higher-level discussion.


By my count since it moved here more than 30% of all mail count has been
posted here because osgi-dev is the enRoute support list. (~180 mails
since ~20th of september, 60+ very basic "Help me" requests).

My problem is with the quality of the discussed content. I stayed 2 days
on Karaf's users@ ML before unregistering because of the amount of
StackOverflow/IRC kind of questions. My problem is seing the content
quality of osgi-dev@ decreasing, and because the quality was satisfying
before: mostly spec discussion on specific points, not "Help me I'm
lost" questions.

If no one else has that feeling, fine. I'm asking if others do. Łukasz
Dywicki seemed to say so quite early on I suppose he and maybe other
share the sentiment.


Best regards,



___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] OSGi enRoute Maven Testers wanted ...

[erwindl0]

I have done the complete tutorial, following all the steps in detail 
(yep even using vi!).


It's a great way to learn some basic things about the enroute/bnd 
way-of-working, combined with mvn pom setup.

Most importantly : everything works as described from the first try.
(I did have one temporary mvn issue due to its untransparent caching of 
snapshot artifacts, but that was a local issue on my setup)


So thanks Peter for another great contribution for the OSGi community!

cheers
erwin

Op 10/6/2016 om 4:38 PM schreef Peter Kriens:
Then just create issues on the OSGi enRoute site 
https://github.com/osgi/osgi.enroute.site 
<https://github.com/osgi/osgi.enroute.site>. This will keep it nicely 
focused but visible to all. I’d like to get the most embarrassing 
errors out without looking like a fool on this forum but if there are 
more fundamental things then feel free to discuss it here.


You can also submit PRs with inline comments.

Kind regards,

Peter Kriens


On 6 okt. 2016, at 16:16, Milen Dyankov <milendyan...@gmail.com 
<mailto:milendyan...@gmail.com>> wrote:


Peter,

can we discuss this here or it needs to go to your e-mail?
I mean it would be nice to discuss this in a place where people can 
follow even if they don't have the time to contribute themselves.


Best,
Milen

On Thu, Oct 6, 2016 at 4:06 PM, erwindl0 <erwin...@gmail.com 
<mailto:erwin...@gmail.com>> wrote:


Peter,

I would like to try this out.

What is the test/review period you've planned for this? Is it ok
between now and mid November for instance?

regards
erwin

Op 10/6/2016 om 3:51 PM schreef Peter Kriens:

I’ve created a tutorial for OSGi enRoute with Maven and vi. I am
in need of some people that are willing to review this tutorial.

The tutorial is at
http://enroute.osgi.org/tutorial_eval/050-start.html
<http://enroute.osgi.org/tutorial_eval/050-start.html>

You can find the Github source code at:
https://github.com/osgi/osgi.enroute.site/tree/gh-pages/_tutorial_eval
<https://github.com/osgi/osgi.enroute.site/tree/gh-pages/_tutorial_eval>

Please provide tool requests and issues or just mail me
personally at peter.kri...@aqute.biz
<mailto:peter.kri...@aqute.biz>.

Any help would be HIGHLY appreciated. Kind regards,

Peter Kriens


___
OSGi Developer Mail List
osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
<https://mail.osgi.org/mailman/listinfo/osgi-dev>


___ OSGi Developer
Mail List osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
<https://mail.osgi.org/mailman/listinfo/osgi-dev> 


--
http://about.me/milen
___ OSGi Developer Mail 
List osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> 
https://mail.osgi.org/mailman/listinfo/osgi-dev


___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev


___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev