On 29/03/13 09:19, Peter Kriens wrote:
If you set the Configuration Policy to required than the DS components
will not register automatically, they need to be configured. So if both
runtimes are installed they will at least not provide the same service both.
That said ... for the small dependency of DS (107k) I think it is silly
*not* to require it. If I had to do OSGi again I would fight to have DS
included in the framework. Looking at some old code (and some code
Exactly what I proposed during the OSGi+Javascript workshop @ EclipseCon
yesterday.
We should not expose the low level API by default (but still have it
available) but the default API should DS (alike), and keep in mind that
we might want to evolve it (if needed).
My point was that it should be easy first and cover most of the use
cases in order to gain acceptance.
IMHO DS provides that.
people provide to highlight their problems with OSGi) I have no idea
what we were smoking at the time :-(
Since DS is much smaller, simpler, much more reliable (no damping and
timeout! than Blueprint and has annotations support I would just focus
on DS. DS should imho be a no-brainer dependency.
So even though you can, I would strongly advise against providing both,
in that vein you also have to provide iPojo, etc.
Kind regards,
Peter Kriens
On 28 mrt. 2013, at 15:10, Cristiano Gavião wrote:
Yep,
I got this conclusion too.. mix both in same bundle is not good.
What I was trying was to avoid to obligate people to install a runtime
just because our bundle...
The only way to do this is return to activators. but that I want to
avoid too :)
2013/3/28 Neil Bartlett <njbartl...@gmail.com
<mailto:njbartl...@gmail.com>>
Both will be registered. DS will register the service(s), and
Blueprint will also register the service(s). If there are any
overlaps then you may get two instances of some services.
I don't think it's a very good idea to do this. A more sensible
approach to migration would -- I believe -- to have some bundles
which are DS-based and some which are Blueprint-based. Mixing
together both DS and Blueprint in the *same* bundle probably means
that your bundle has poor coherency. Nevertheless, it's perfectly
possible.
Neil
On Thu, Mar 28, 2013 at 1:32 PM, Cristiano Gavião
<cvgav...@gmail.com <mailto:cvgav...@gmail.com>> wrote:
Hey Neil,
Ok. Suppose I included service definitions (for same service
name and same impl) for both.
My concern is: what could happen if both runtime is installed
and active in the same environment. The framework will fail to
register both or only one service?
thanks a lot,
Cristiano
2013/3/28 Neil Bartlett <njbartl...@gmail.com
<mailto:njbartl...@gmail.com>>
Yes you can do this without any problems. Just include
both the Service-Component header for DS, and the
blueprint XML files under OSGI-INF/blueprint. You will
also need both the corresponding runtime bundles installed
and active. Then it will all "Just Work" (TM).
Neil
On Thu, Mar 28, 2013 at 1:01 PM, Cristiano Gavião
<cvgav...@gmail.com <mailto:cvgav...@gmail.com>> wrote:
Hello,
I need to osgify an existent API and expose services
based on it.
There are people that uses Blueprint by default
(karaf) and there are people that uses DS (equinox).
could I provide both type of services in a same bundle ?
and what could happen if the system have both runtime
installed ? can I choose one at runtime?
thanks for any tip.
Cristiano
_______________________________________________
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 <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
"Tudo vale a pena se a alma não é pequena..."
_______________________________________________
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 <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
"Tudo vale a pena se a alma não é pequena..."
_______________________________________________
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
--
Ferry Huberts
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
