Re: Blueprint or DS or what to use?

2016-03-21 Thread Tim Jones
I realise rereading my post that it may have been a little ambiguous as to
which direction we have taken => we have decided that Declarative Services
will be the best solution for us long term.



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045922.html
Sent from the Karaf - User mailing list archive at Nabble.com.


Re: Blueprint or DS or what to use?

2016-03-21 Thread Achim Nierbeck
If I might throw in another tech, which hasn't been talked of yet.
Another possibility would be to take a look at CDI, we have pax-cdi which
does a fair share of leveraging cdi stuff in osgi
and afaik someone from IBM started to work on something to have cdi 2.0 be
compatible to OSGi. Especially the dynamics.
Never the less pax-cdi does already work quite nicely with it, the only
drawback because the company initially working on the RFP 148 lost interest
in it, it never happend to be finished. Maybe this will change with the cdi
2.0 approach.

regards, Achim


2016-03-21 10:28 GMT+01:00 Richard Nicholson :

> np
>
> > On 21 Mar 2016, at 09:25, Jean-Baptiste Onofré  wrote:
> >
> > Hi Richard,
> >
> > Thanks again for your help, much appreciate !
> >
> > Let me send a private e-mail to you (copy with people involved in the
> decision in my company).
> >
> > Thanks !
> > Regards
> > JB
> >
> > On 03/21/2016 10:20 AM, Richard Nicholson wrote:
> >> JB -
> >>
> >> As I directly offered to you during our discussion in 2015 - if I can
> help in any way please let me know. Myself and other OSGi Board Members are
> more than happy to help any company that is considering joining the OSGi
> Alliance.
> >>
> >> Best Wishes.
> >>
> >>
> >>> On 21 Mar 2016, at 09:04, Jean-Baptiste Onofré 
> wrote:
> >>>
> >>> Hi Richard,
> >>>
> >>> we already had discussion with the OSGi Alliance. Christian and I
> asked if it would be possible to work on specifications "outside" of our
> company first, as OpenSource guys. It seems very difficult, so now, we are
> discussing internally with our company.
> >>>
> >>> Regards
> >>> JB
> >>>
> >>> On 03/21/2016 09:53 AM, Richard Nicholson wrote:
> 
> > On 21 Mar 2016, at 08:27, Christian Schneider <
> ch...@die-schneider.net> wrote:
> >
> > Indeed it is difficult to predict where the OSGi community will go
> in the future.
> 
>  No great mystery, no crystal ball need and easily addressable.
> 
>  Companies making profit out of the Karaf community (selling services
> wrapped around it, or training based upon it), also companies using Karaf
> based solutions in their production systems and worried about longevity,
> should both join the OSGi Alliance.
> 
>  Get involved, commit resources to drive forwards specifications that
> you want to see. That is how the Alliance operates. DS has moved forwards
> precisely because OSGi Alliance members have put the effort in to do this.
> 
> >
> > For DS the situation is hopefully a little better today than at the
> time I did the comparison.
> > - JPA can be solved today by using the Aries JPA and JPATemplate but
> it is not standardized. The upcoming spec hopefully will improve this.
> > - Services and Remoting can be solved by Remote Service Admin. With
> ECF and Aries rsa (CXF-DOSGi) there are now two stacks available on karaf
> that can help with this.
> > Still it can be a little rough if you want to use some special CXF
> features. We will have to prove using some good examples / pocs that Remote
> Services can fully replace the blueprint CXF namespaces.
> >
> > Btw. I have some plans for Aries RSA to support application wide
> policies. The idea is to define some common aspects of your services
> centrally and apply them to all exported OSGi services. So for example you
> could define in one central point that all your services with JAXRS
> annotations should be auto exported and have single sign on authentication
> using STS, SSL encryption and logging.
> >
> > The migration though is still a big issue.
> >
> > Some time ago I did the migration of a medium sized production
> system from servlet container + spring to karaf + blueprint. The big
> problem there was that we had to do the transition
> > while the main team was going full steam and doing releases.  It was
> the start of the blueprint-maven-plugin as this was the only way to do
> migration without a big bang. So if you
> > have to do this then the annotation based approach + the plugin
> above can help a lot. If someone wants to try this I can help with some
> good advices. If there is some interest I can also blog about
> > how to do such a transition in practice.
> >
> > A migration to DS will pretty much be a big bang as it is too
> different from spring to do a smooth transition. I think it is possible to
> do a full business application in DS but the migration step is bigger.
> >
> > Christian
> >
> > On 21.03.2016 02:24, Tim Jones wrote:
> >> Andreas you are crossing or about to cross a bridge we are crossing
> at the
> >> moment. We also have a SpringDM based application. It is 3+ years in
> >> production and so a change as large as moving away from SpringDM is
> very
> >> disruptive. For the most part we considered only Aries Blueprint vs
> DS.
> >> However as you can see 

Re: Blueprint or DS or what to use?

2016-03-21 Thread Richard Nicholson
np 

> On 21 Mar 2016, at 09:25, Jean-Baptiste Onofré  wrote:
> 
> Hi Richard,
> 
> Thanks again for your help, much appreciate !
> 
> Let me send a private e-mail to you (copy with people involved in the 
> decision in my company).
> 
> Thanks !
> Regards
> JB
> 
> On 03/21/2016 10:20 AM, Richard Nicholson wrote:
>> JB -
>> 
>> As I directly offered to you during our discussion in 2015 - if I can help 
>> in any way please let me know. Myself and other OSGi Board Members are more 
>> than happy to help any company that is considering joining the OSGi Alliance.
>> 
>> Best Wishes.
>> 
>> 
>>> On 21 Mar 2016, at 09:04, Jean-Baptiste Onofré  wrote:
>>> 
>>> Hi Richard,
>>> 
>>> we already had discussion with the OSGi Alliance. Christian and I asked if 
>>> it would be possible to work on specifications "outside" of our company 
>>> first, as OpenSource guys. It seems very difficult, so now, we are 
>>> discussing internally with our company.
>>> 
>>> Regards
>>> JB
>>> 
>>> On 03/21/2016 09:53 AM, Richard Nicholson wrote:
 
> On 21 Mar 2016, at 08:27, Christian Schneider  
> wrote:
> 
> Indeed it is difficult to predict where the OSGi community will go in the 
> future.
 
 No great mystery, no crystal ball need and easily addressable.
 
 Companies making profit out of the Karaf community (selling services 
 wrapped around it, or training based upon it), also companies using Karaf 
 based solutions in their production systems and worried about longevity, 
 should both join the OSGi Alliance.
 
 Get involved, commit resources to drive forwards specifications that you 
 want to see. That is how the Alliance operates. DS has moved forwards 
 precisely because OSGi Alliance members have put the effort in to do this.
 
> 
> For DS the situation is hopefully a little better today than at the time 
> I did the comparison.
> - JPA can be solved today by using the Aries JPA and JPATemplate but it 
> is not standardized. The upcoming spec hopefully will improve this.
> - Services and Remoting can be solved by Remote Service Admin. With ECF 
> and Aries rsa (CXF-DOSGi) there are now two stacks available on karaf 
> that can help with this.
> Still it can be a little rough if you want to use some special CXF 
> features. We will have to prove using some good examples / pocs that 
> Remote Services can fully replace the blueprint CXF namespaces.
> 
> Btw. I have some plans for Aries RSA to support application wide 
> policies. The idea is to define some common aspects of your services 
> centrally and apply them to all exported OSGi services. So for example 
> you could define in one central point that all your services with JAXRS 
> annotations should be auto exported and have single sign on 
> authentication using STS, SSL encryption and logging.
> 
> The migration though is still a big issue.
> 
> Some time ago I did the migration of a medium sized production system 
> from servlet container + spring to karaf + blueprint. The big problem 
> there was that we had to do the transition
> while the main team was going full steam and doing releases.  It was the 
> start of the blueprint-maven-plugin as this was the only way to do 
> migration without a big bang. So if you
> have to do this then the annotation based approach + the plugin above can 
> help a lot. If someone wants to try this I can help with some good 
> advices. If there is some interest I can also blog about
> how to do such a transition in practice.
> 
> A migration to DS will pretty much be a big bang as it is too different 
> from spring to do a smooth transition. I think it is possible to do a 
> full business application in DS but the migration step is bigger.
> 
> Christian
> 
> On 21.03.2016 02:24, Tim Jones wrote:
>> Andreas you are crossing or about to cross a bridge we are crossing at 
>> the
>> moment. We also have a SpringDM based application. It is 3+ years in
>> production and so a change as large as moving away from SpringDM is very
>> disruptive. For the most part we considered only Aries Blueprint vs DS.
>> However as you can see from this post there are other alternatives, some
>> fairly recent such as support for Spring namespaces in Aries Blueprint.
>> 
>> For us the most significant points to consider were
>> 
>> 1) Will there still be good support in 5-10 years (having been burnt 
>> once we
>> don't want face the same issue again)
>> 
>> 2) Where is the general OSGi community heading? Blueprint/DS/other. The
>> first sentence of Tim Ward's post is something we thought significant.
>> Something that has concerned me over the last couple of years is 
>> sometimes
>> an 

Re: Blueprint or DS or what to use?

2016-03-21 Thread Jean-Baptiste Onofré

Hi Richard,

Thanks again for your help, much appreciate !

Let me send a private e-mail to you (copy with people involved in the 
decision in my company).


Thanks !
Regards
JB

On 03/21/2016 10:20 AM, Richard Nicholson wrote:

JB -

As I directly offered to you during our discussion in 2015 - if I can help in 
any way please let me know. Myself and other OSGi Board Members are more than 
happy to help any company that is considering joining the OSGi Alliance.

Best Wishes.



On 21 Mar 2016, at 09:04, Jean-Baptiste Onofré  wrote:

Hi Richard,

we already had discussion with the OSGi Alliance. Christian and I asked if it would be 
possible to work on specifications "outside" of our company first, as 
OpenSource guys. It seems very difficult, so now, we are discussing internally with our 
company.

Regards
JB

On 03/21/2016 09:53 AM, Richard Nicholson wrote:



On 21 Mar 2016, at 08:27, Christian Schneider  wrote:

Indeed it is difficult to predict where the OSGi community will go in the 
future.


No great mystery, no crystal ball need and easily addressable.

Companies making profit out of the Karaf community (selling services wrapped 
around it, or training based upon it), also companies using Karaf based 
solutions in their production systems and worried about longevity, should both 
join the OSGi Alliance.

Get involved, commit resources to drive forwards specifications that you want 
to see. That is how the Alliance operates. DS has moved forwards precisely 
because OSGi Alliance members have put the effort in to do this.



For DS the situation is hopefully a little better today than at the time I did 
the comparison.
- JPA can be solved today by using the Aries JPA and JPATemplate but it is not 
standardized. The upcoming spec hopefully will improve this.
- Services and Remoting can be solved by Remote Service Admin. With ECF and 
Aries rsa (CXF-DOSGi) there are now two stacks available on karaf that can help 
with this.
Still it can be a little rough if you want to use some special CXF features. We 
will have to prove using some good examples / pocs that Remote Services can 
fully replace the blueprint CXF namespaces.

Btw. I have some plans for Aries RSA to support application wide policies. The 
idea is to define some common aspects of your services centrally and apply them 
to all exported OSGi services. So for example you could define in one central 
point that all your services with JAXRS annotations should be auto exported and 
have single sign on authentication using STS, SSL encryption and logging.

The migration though is still a big issue.

Some time ago I did the migration of a medium sized production system from 
servlet container + spring to karaf + blueprint. The big problem there was that 
we had to do the transition
while the main team was going full steam and doing releases.  It was the start 
of the blueprint-maven-plugin as this was the only way to do migration without 
a big bang. So if you
have to do this then the annotation based approach + the plugin above can help 
a lot. If someone wants to try this I can help with some good advices. If there 
is some interest I can also blog about
how to do such a transition in practice.

A migration to DS will pretty much be a big bang as it is too different from 
spring to do a smooth transition. I think it is possible to do a full business 
application in DS but the migration step is bigger.

Christian

On 21.03.2016 02:24, Tim Jones wrote:

Andreas you are crossing or about to cross a bridge we are crossing at the
moment. We also have a SpringDM based application. It is 3+ years in
production and so a change as large as moving away from SpringDM is very
disruptive. For the most part we considered only Aries Blueprint vs DS.
However as you can see from this post there are other alternatives, some
fairly recent such as support for Spring namespaces in Aries Blueprint.

For us the most significant points to consider were

1) Will there still be good support in 5-10 years (having been burnt once we
don't want face the same issue again)

2) Where is the general OSGi community heading? Blueprint/DS/other. The
first sentence of Tim Ward's post is something we thought significant.
Something that has concerned me over the last couple of years is sometimes
an alternative is suggested by needs some jiggery pokery to make it work, it
doesn't have wide support, little documentation, often has bugs which led to
a churn of releases. While it may be a cool, clever solution we aren't going
to bet our production system on cool and clever only.

3) We are by and large glue coders and don't have the ability nor want to
spend the time/resource building our own custom  solutions, this is where I
think Spring has suited us well until now. We tried to identify what
offerings were available for the bits we needed e.g. JPA, JDBC,
transactional control, Camel JMS, CXF. It is an opinion only, but from what
I could 

Re: Blueprint or DS or what to use?

2016-03-21 Thread Christian Schneider

Hi Tim,

On 21.03.2016 09:48, Timothy Ward wrote:

Hi Christian,


On 21 Mar 2016, at 08:27, Christian Schneider 
> wrote:


Indeed it is difficult to predict where the OSGi community will go in 
the future.


I’m not sure that I agree with this. OSGi RFPs and RFCs are publicly 
available at https://github.com/osgi/design, and questions on the OSGi 
mailing lists get pretty comprehensive answers 
(https://www.osgi.org/community/mail-lists/). In this specific 
case, there are no OSGi members driving the Blueprint RFCs (RFCs 155, 
156, 164 and 166) which is why they have had no activity since 2011 or so.


The OSGi community is more than the OSGi alliance. For example we at 
Talend are also part of the OSGi community but as we unfortunately do 
not get backing for an alliance membership none of our efforts will go 
into a RFC. On the other hand I agree with you that DS gains more 
traction at the moment. Guillaumes effort on the spring namespace 
support for blueprint is a great development

on the blueprint side but there are not many other such examples.


- Services and Remoting can be solved by Remote Service Admin. With 
ECF and Aries rsa (CXF-DOSGi) there are now two stacks available on 
karaf that can help with this.


There are also a lot of other RSA implementations which can be 
deployed in any OSGi framework.
I would like to see a lot more of these other implementations. 
Unfortunately there is not much information on how to use them 
especially on apache karaf. I think a major enabler is to find the 
bundles on maven central. Another big part is the documentation and of 
course the license.


So from the license side the Amdatu implementation would be interesting. 
Maybe someone can do a tutorial for it?

Not sure about the others. Are they are all closed source?



Still it can be a little rough if you want to use some special CXF 
features. We will have to prove using some good examples / pocs that 
Remote Services can fully replace the blueprint CXF namespaces.


Btw. I have some plans for Aries RSA to support application wide 
policies. The idea is to define some common aspects of your services 
centrally and apply them to all exported OSGi services. So for 
example you could define in one central point that all your services 
with JAXRS annotations should be auto exported and have single sign 
on authentication using STS, SSL encryption and logging.


This is configuration for the RSA distribution provider and should be 
possible to define at a central point for any RSA implementation, not 
just when using Karaf’s preferred CXF provider.
Yes. The way to specify this is configuration or more specific service 
properties and additional properties. What I am refering to is that I 
introduced an extension interface in Aries RSA that allows
to customize what the TopologyManager adds in form of additional 
properties. See 
https://github.com/apache/aries-rsa/blob/master/spi/src/main/java/org/apache/aries/rsa/spi/ExportPolicy.java

Probably other Remote Service Admin impls have similar ways to do this.

The other part of the solution of course is to then apply these 
configurations in the provider for the RemoteServiceAdmin. CXF is just 
an example here of course but it is the most widely used JAXWS and JAXRS 
impl today and people do quite some fancy configs in blueprint today. So 
to replicate this we have to make sure we can do the same using Remote 
Service Admin. CXF DOSGi supports intents implemented by Features but I 
think no one has tried to implement some of the more advanced security 
setups with this.




The migration though is still a big issue.

Some time ago I did the migration of a medium sized production system 
from servlet container + spring to karaf + blueprint. The big problem 
there was that we had to do the transition
while the main team was going full steam and doing releases.  It was 
the start of the blueprint-maven-plugin as this was the only way to 
do migration without a big bang. So if you
have to do this then the annotation based approach + the plugin above 
can help a lot. If someone wants to try this I can help with some 
good advices. If there is some interest I can also blog about

how to do such a transition in practice.

A migration to DS will pretty much be a big bang as it is too 
different from spring to do a smooth transition. I think it is 
possible to do a full business application in DS but the migration 
step is bigger.


This is also incorrect - OSGi is a modular environment, and the whole 
point is that modules can be changed individually. Both DS and 
Blueprint communicate between bundles using OSGi services so there is 
no problem at all with having one bundle using DS while the other uses 
Blueprint. The migration from blueprint to DS can occur one bundle at 
a time, and does not have to be a big bang across the whole codebase.

That is also what I thought when starting the migration :-)

Re: Blueprint or DS or what to use?

2016-03-21 Thread Richard Nicholson
JB - 

As I directly offered to you during our discussion in 2015 - if I can help in 
any way please let me know. Myself and other OSGi Board Members are more than 
happy to help any company that is considering joining the OSGi Alliance.

Best Wishes.


> On 21 Mar 2016, at 09:04, Jean-Baptiste Onofré  wrote:
> 
> Hi Richard,
> 
> we already had discussion with the OSGi Alliance. Christian and I asked if it 
> would be possible to work on specifications "outside" of our company first, 
> as OpenSource guys. It seems very difficult, so now, we are discussing 
> internally with our company.
> 
> Regards
> JB
> 
> On 03/21/2016 09:53 AM, Richard Nicholson wrote:
>> 
>>> On 21 Mar 2016, at 08:27, Christian Schneider  
>>> wrote:
>>> 
>>> Indeed it is difficult to predict where the OSGi community will go in the 
>>> future.
>> 
>> No great mystery, no crystal ball need and easily addressable.
>> 
>> Companies making profit out of the Karaf community (selling services wrapped 
>> around it, or training based upon it), also companies using Karaf based 
>> solutions in their production systems and worried about longevity, should 
>> both join the OSGi Alliance.
>> 
>> Get involved, commit resources to drive forwards specifications that you 
>> want to see. That is how the Alliance operates. DS has moved forwards 
>> precisely because OSGi Alliance members have put the effort in to do this.
>> 
>>> 
>>> For DS the situation is hopefully a little better today than at the time I 
>>> did the comparison.
>>> - JPA can be solved today by using the Aries JPA and JPATemplate but it is 
>>> not standardized. The upcoming spec hopefully will improve this.
>>> - Services and Remoting can be solved by Remote Service Admin. With ECF and 
>>> Aries rsa (CXF-DOSGi) there are now two stacks available on karaf that can 
>>> help with this.
>>> Still it can be a little rough if you want to use some special CXF 
>>> features. We will have to prove using some good examples / pocs that Remote 
>>> Services can fully replace the blueprint CXF namespaces.
>>> 
>>> Btw. I have some plans for Aries RSA to support application wide policies. 
>>> The idea is to define some common aspects of your services centrally and 
>>> apply them to all exported OSGi services. So for example you could define 
>>> in one central point that all your services with JAXRS annotations should 
>>> be auto exported and have single sign on authentication using STS, SSL 
>>> encryption and logging.
>>> 
>>> The migration though is still a big issue.
>>> 
>>> Some time ago I did the migration of a medium sized production system from 
>>> servlet container + spring to karaf + blueprint. The big problem there was 
>>> that we had to do the transition
>>> while the main team was going full steam and doing releases.  It was the 
>>> start of the blueprint-maven-plugin as this was the only way to do 
>>> migration without a big bang. So if you
>>> have to do this then the annotation based approach + the plugin above can 
>>> help a lot. If someone wants to try this I can help with some good advices. 
>>> If there is some interest I can also blog about
>>> how to do such a transition in practice.
>>> 
>>> A migration to DS will pretty much be a big bang as it is too different 
>>> from spring to do a smooth transition. I think it is possible to do a full 
>>> business application in DS but the migration step is bigger.
>>> 
>>> Christian
>>> 
>>> On 21.03.2016 02:24, Tim Jones wrote:
 Andreas you are crossing or about to cross a bridge we are crossing at the
 moment. We also have a SpringDM based application. It is 3+ years in
 production and so a change as large as moving away from SpringDM is very
 disruptive. For the most part we considered only Aries Blueprint vs DS.
 However as you can see from this post there are other alternatives, some
 fairly recent such as support for Spring namespaces in Aries Blueprint.
 
 For us the most significant points to consider were
 
 1) Will there still be good support in 5-10 years (having been burnt once 
 we
 don't want face the same issue again)
 
 2) Where is the general OSGi community heading? Blueprint/DS/other. The
 first sentence of Tim Ward's post is something we thought significant.
 Something that has concerned me over the last couple of years is sometimes
 an alternative is suggested by needs some jiggery pokery to make it work, 
 it
 doesn't have wide support, little documentation, often has bugs which led 
 to
 a churn of releases. While it may be a cool, clever solution we aren't 
 going
 to bet our production system on cool and clever only.
 
 3) We are by and large glue coders and don't have the ability nor want to
 spend the time/resource building our own custom  solutions, this is where I
 think Spring has suited us well until now. We tried to identify what

Re: Blueprint or DS or what to use?

2016-03-21 Thread Jean-Baptiste Onofré

Hi Tim,

FYI, Guillaume was involved in the Blueprint specification (and he's 
OSGi Alliance member via RedHat if I remember well).


Regards
JB

On 03/21/2016 09:48 AM, Timothy Ward wrote:

Hi Christian,



On 21 Mar 2016, at 08:27, Christian Schneider > wrote:

Indeed it is difficult to predict where the OSGi community will go in
the future.


I’m not sure that I agree with this. OSGi RFPs and RFCs are publicly
available at https://github.com/osgi/design, and questions on the OSGi
mailing lists get pretty comprehensive answers
(https://www.osgi.org/community/mail-lists/). In this specific
case, there are no OSGi members driving the Blueprint RFCs (RFCs 155,
156, 164 and 166) which is why they have had no activity since 2011 or so.



For DS the situation is hopefully a little better today than at the
time I did the comparison.
- JPA can be solved today by using the Aries JPA and JPATemplate but
it is not standardized. The upcoming spec hopefully will improve this.


Specifically RFC 221
(https://github.com/osgi/design/tree/master/rfcs/rfc0221)


- Services and Remoting can be solved by Remote Service Admin. With
ECF and Aries rsa (CXF-DOSGi) there are now two stacks available on
karaf that can help with this.


There are also a lot of other RSA implementations which can be deployed
in any OSGi framework.


Still it can be a little rough if you want to use some special CXF
features. We will have to prove using some good examples / pocs that
Remote Services can fully replace the blueprint CXF namespaces.

Btw. I have some plans for Aries RSA to support application wide
policies. The idea is to define some common aspects of your services
centrally and apply them to all exported OSGi services. So for example
you could define in one central point that all your services with
JAXRS annotations should be auto exported and have single sign on
authentication using STS, SSL encryption and logging.


This is configuration for the RSA distribution provider and should be
possible to define at a central point for any RSA implementation, not
just when using Karaf’s preferred CXF provider.



The migration though is still a big issue.

Some time ago I did the migration of a medium sized production system
from servlet container + spring to karaf + blueprint. The big problem
there was that we had to do the transition
while the main team was going full steam and doing releases.  It was
the start of the blueprint-maven-plugin as this was the only way to do
migration without a big bang. So if you
have to do this then the annotation based approach + the plugin above
can help a lot. If someone wants to try this I can help with some good
advices. If there is some interest I can also blog about
how to do such a transition in practice.

A migration to DS will pretty much be a big bang as it is too
different from spring to do a smooth transition. I think it is
possible to do a full business application in DS but the migration
step is bigger.


This is also incorrect - OSGi is a modular environment, and the whole
point is that modules can be changed individually. Both DS and Blueprint
communicate between bundles using OSGi services so there is no problem
at all with having one bundle using DS while the other uses Blueprint.
The migration from blueprint to DS can occur one bundle at a time, and
does not have to be a big bang across the whole codebase.

Regards,

Tim



Christian

On 21.03.2016 02:24, Tim Jones wrote:

Andreas you are crossing or about to cross a bridge we are crossing
at the
moment. We also have a SpringDM based application. It is 3+ years in
production and so a change as large as moving away from SpringDM is very
disruptive. For the most part we considered only Aries Blueprint vs DS.
However as you can see from this post there are other alternatives, some
fairly recent such as support for Spring namespaces in Aries Blueprint.

For us the most significant points to consider were

1) Will there still be good support in 5-10 years (having been burnt
once we
don't want face the same issue again)

2) Where is the general OSGi community heading? Blueprint/DS/other. The
first sentence of Tim Ward's post is something we thought significant.
Something that has concerned me over the last couple of years is
sometimes
an alternative is suggested by needs some jiggery pokery to make it
work, it
doesn't have wide support, little documentation, often has bugs which
led to
a churn of releases. While it may be a cool, clever solution we
aren't going
to bet our production system on cool and clever only.

3) We are by and large glue coders and don't have the ability nor want to
spend the time/resource building our own custom  solutions, this is
where I
think Spring has suited us well until now. We tried to identify what
offerings were available for the bits we needed e.g. JPA, JDBC,
transactional control, Camel JMS, CXF. It is an opinion only, but
from what
I could see 

Re: Blueprint or DS or what to use?

2016-03-21 Thread Jean-Baptiste Onofré

Hi Richard,

we already had discussion with the OSGi Alliance. Christian and I asked 
if it would be possible to work on specifications "outside" of our 
company first, as OpenSource guys. It seems very difficult, so now, we 
are discussing internally with our company.


Regards
JB

On 03/21/2016 09:53 AM, Richard Nicholson wrote:



On 21 Mar 2016, at 08:27, Christian Schneider  wrote:

Indeed it is difficult to predict where the OSGi community will go in the 
future.


No great mystery, no crystal ball need and easily addressable.

Companies making profit out of the Karaf community (selling services wrapped 
around it, or training based upon it), also companies using Karaf based 
solutions in their production systems and worried about longevity, should both 
join the OSGi Alliance.

Get involved, commit resources to drive forwards specifications that you want 
to see. That is how the Alliance operates. DS has moved forwards precisely 
because OSGi Alliance members have put the effort in to do this.



For DS the situation is hopefully a little better today than at the time I did 
the comparison.
- JPA can be solved today by using the Aries JPA and JPATemplate but it is not 
standardized. The upcoming spec hopefully will improve this.
- Services and Remoting can be solved by Remote Service Admin. With ECF and 
Aries rsa (CXF-DOSGi) there are now two stacks available on karaf that can help 
with this.
Still it can be a little rough if you want to use some special CXF features. We 
will have to prove using some good examples / pocs that Remote Services can 
fully replace the blueprint CXF namespaces.

Btw. I have some plans for Aries RSA to support application wide policies. The 
idea is to define some common aspects of your services centrally and apply them 
to all exported OSGi services. So for example you could define in one central 
point that all your services with JAXRS annotations should be auto exported and 
have single sign on authentication using STS, SSL encryption and logging.

The migration though is still a big issue.

Some time ago I did the migration of a medium sized production system from 
servlet container + spring to karaf + blueprint. The big problem there was that 
we had to do the transition
while the main team was going full steam and doing releases.  It was the start 
of the blueprint-maven-plugin as this was the only way to do migration without 
a big bang. So if you
have to do this then the annotation based approach + the plugin above can help 
a lot. If someone wants to try this I can help with some good advices. If there 
is some interest I can also blog about
how to do such a transition in practice.

A migration to DS will pretty much be a big bang as it is too different from 
spring to do a smooth transition. I think it is possible to do a full business 
application in DS but the migration step is bigger.

Christian

On 21.03.2016 02:24, Tim Jones wrote:

Andreas you are crossing or about to cross a bridge we are crossing at the
moment. We also have a SpringDM based application. It is 3+ years in
production and so a change as large as moving away from SpringDM is very
disruptive. For the most part we considered only Aries Blueprint vs DS.
However as you can see from this post there are other alternatives, some
fairly recent such as support for Spring namespaces in Aries Blueprint.

For us the most significant points to consider were

1) Will there still be good support in 5-10 years (having been burnt once we
don't want face the same issue again)

2) Where is the general OSGi community heading? Blueprint/DS/other. The
first sentence of Tim Ward's post is something we thought significant.
Something that has concerned me over the last couple of years is sometimes
an alternative is suggested by needs some jiggery pokery to make it work, it
doesn't have wide support, little documentation, often has bugs which led to
a churn of releases. While it may be a cool, clever solution we aren't going
to bet our production system on cool and clever only.

3) We are by and large glue coders and don't have the ability nor want to
spend the time/resource building our own custom  solutions, this is where I
think Spring has suited us well until now. We tried to identify what
offerings were available for the bits we needed e.g. JPA, JDBC,
transactional control, Camel JMS, CXF. It is an opinion only, but from what
I could see Blueprint offered the broadest support (see Christian's
ecosystems-compared
http://www.slideshare.net/mfrancis/osgi-ecosystems-compared-on-apache-karaf-christian-schneider).

The big one for us was lack of JPA/JDBC/transactional control for DS, while
there were some solutions we wanted something with a 'spec behind it'. This
is currently been worked on at the moment
(https://github.com/apache/aries/tree/trunk/tx-control) and I think it is a
significant piece of work that will make DS a much more attractive
proposition in the enterprise/applications 

Re: Blueprint or DS or what to use?

2016-03-21 Thread Richard Nicholson

> On 21 Mar 2016, at 08:27, Christian Schneider  wrote:
> 
> Indeed it is difficult to predict where the OSGi community will go in the 
> future.

No great mystery, no crystal ball need and easily addressable. 

Companies making profit out of the Karaf community (selling services wrapped 
around it, or training based upon it), also companies using Karaf based 
solutions in their production systems and worried about longevity, should both 
join the OSGi Alliance. 

Get involved, commit resources to drive forwards specifications that you want 
to see. That is how the Alliance operates. DS has moved forwards precisely 
because OSGi Alliance members have put the effort in to do this.

> 
> For DS the situation is hopefully a little better today than at the time I 
> did the comparison.
> - JPA can be solved today by using the Aries JPA and JPATemplate but it is 
> not standardized. The upcoming spec hopefully will improve this.
> - Services and Remoting can be solved by Remote Service Admin. With ECF and 
> Aries rsa (CXF-DOSGi) there are now two stacks available on karaf that can 
> help with this.
> Still it can be a little rough if you want to use some special CXF features. 
> We will have to prove using some good examples / pocs that Remote Services 
> can fully replace the blueprint CXF namespaces.
> 
> Btw. I have some plans for Aries RSA to support application wide policies. 
> The idea is to define some common aspects of your services centrally and 
> apply them to all exported OSGi services. So for example you could define in 
> one central point that all your services with JAXRS annotations should be 
> auto exported and have single sign on authentication using STS, SSL 
> encryption and logging.
> 
> The migration though is still a big issue.
> 
> Some time ago I did the migration of a medium sized production system from 
> servlet container + spring to karaf + blueprint. The big problem there was 
> that we had to do the transition
> while the main team was going full steam and doing releases.  It was the 
> start of the blueprint-maven-plugin as this was the only way to do migration 
> without a big bang. So if you
> have to do this then the annotation based approach + the plugin above can 
> help a lot. If someone wants to try this I can help with some good advices. 
> If there is some interest I can also blog about
> how to do such a transition in practice.
> 
> A migration to DS will pretty much be a big bang as it is too different from 
> spring to do a smooth transition. I think it is possible to do a full 
> business application in DS but the migration step is bigger.
> 
> Christian
> 
> On 21.03.2016 02:24, Tim Jones wrote:
>> Andreas you are crossing or about to cross a bridge we are crossing at the
>> moment. We also have a SpringDM based application. It is 3+ years in
>> production and so a change as large as moving away from SpringDM is very
>> disruptive. For the most part we considered only Aries Blueprint vs DS.
>> However as you can see from this post there are other alternatives, some
>> fairly recent such as support for Spring namespaces in Aries Blueprint.
>> 
>> For us the most significant points to consider were
>> 
>> 1) Will there still be good support in 5-10 years (having been burnt once we
>> don't want face the same issue again)
>> 
>> 2) Where is the general OSGi community heading? Blueprint/DS/other. The
>> first sentence of Tim Ward's post is something we thought significant.
>> Something that has concerned me over the last couple of years is sometimes
>> an alternative is suggested by needs some jiggery pokery to make it work, it
>> doesn't have wide support, little documentation, often has bugs which led to
>> a churn of releases. While it may be a cool, clever solution we aren't going
>> to bet our production system on cool and clever only.
>> 
>> 3) We are by and large glue coders and don't have the ability nor want to
>> spend the time/resource building our own custom  solutions, this is where I
>> think Spring has suited us well until now. We tried to identify what
>> offerings were available for the bits we needed e.g. JPA, JDBC,
>> transactional control, Camel JMS, CXF. It is an opinion only, but from what
>> I could see Blueprint offered the broadest support (see Christian's
>> ecosystems-compared
>> http://www.slideshare.net/mfrancis/osgi-ecosystems-compared-on-apache-karaf-christian-schneider).
>> 
>> The big one for us was lack of JPA/JDBC/transactional control for DS, while
>> there were some solutions we wanted something with a 'spec behind it'. This
>> is currently been worked on at the moment
>> (https://github.com/apache/aries/tree/trunk/tx-control) and I think it is a
>> significant piece of work that will make DS a much more attractive
>> proposition in the enterprise/applications space. Admittedly there is a risk
>> in being new adopter however we think the risk is worth it in this case.
>> Camel has a recent DS offering 

Re: Blueprint or DS or what to use?

2016-03-21 Thread Timothy Ward
Hi Christian,


> On 21 Mar 2016, at 08:27, Christian Schneider  wrote:
> 
> Indeed it is difficult to predict where the OSGi community will go in the 
> future.

I’m not sure that I agree with this. OSGi RFPs and RFCs are publicly available 
at https://github.com/osgi/design , and 
questions on the OSGi mailing lists get pretty comprehensive answers 
(https://www.osgi.org/community/mail-lists/ 
). In this specific case, there are 
no OSGi members driving the Blueprint RFCs (RFCs 155, 156, 164 and 166) which 
is why they have had no activity since 2011 or so.

> 
> For DS the situation is hopefully a little better today than at the time I 
> did the comparison.
> - JPA can be solved today by using the Aries JPA and JPATemplate but it is 
> not standardized. The upcoming spec hopefully will improve this.

Specifically RFC 221 (https://github.com/osgi/design/tree/master/rfcs/rfc0221 
)

> - Services and Remoting can be solved by Remote Service Admin. With ECF and 
> Aries rsa (CXF-DOSGi) there are now two stacks available on karaf that can 
> help with this.

There are also a lot of other RSA implementations which can be deployed in any 
OSGi framework.

> Still it can be a little rough if you want to use some special CXF features. 
> We will have to prove using some good examples / pocs that Remote Services 
> can fully replace the blueprint CXF namespaces.
> 
> Btw. I have some plans for Aries RSA to support application wide policies. 
> The idea is to define some common aspects of your services centrally and 
> apply them to all exported OSGi services. So for example you could define in 
> one central point that all your services with JAXRS annotations should be 
> auto exported and have single sign on authentication using STS, SSL 
> encryption and logging.

This is configuration for the RSA distribution provider and should be possible 
to define at a central point for any RSA implementation, not just when using 
Karaf’s preferred CXF provider.

> 
> The migration though is still a big issue.
> 
> Some time ago I did the migration of a medium sized production system from 
> servlet container + spring to karaf + blueprint. The big problem there was 
> that we had to do the transition
> while the main team was going full steam and doing releases.  It was the 
> start of the blueprint-maven-plugin as this was the only way to do migration 
> without a big bang. So if you
> have to do this then the annotation based approach + the plugin above can 
> help a lot. If someone wants to try this I can help with some good advices. 
> If there is some interest I can also blog about
> how to do such a transition in practice.
> 
> A migration to DS will pretty much be a big bang as it is too different from 
> spring to do a smooth transition. I think it is possible to do a full 
> business application in DS but the migration step is bigger.

This is also incorrect - OSGi is a modular environment, and the whole point is 
that modules can be changed individually. Both DS and Blueprint communicate 
between bundles using OSGi services so there is no problem at all with having 
one bundle using DS while the other uses Blueprint. The migration from 
blueprint to DS can occur one bundle at a time, and does not have to be a big 
bang across the whole codebase.

Regards,

Tim

> 
> Christian
> 
> On 21.03.2016 02:24, Tim Jones wrote:
>> Andreas you are crossing or about to cross a bridge we are crossing at the
>> moment. We also have a SpringDM based application. It is 3+ years in
>> production and so a change as large as moving away from SpringDM is very
>> disruptive. For the most part we considered only Aries Blueprint vs DS.
>> However as you can see from this post there are other alternatives, some
>> fairly recent such as support for Spring namespaces in Aries Blueprint.
>> 
>> For us the most significant points to consider were
>> 
>> 1) Will there still be good support in 5-10 years (having been burnt once we
>> don't want face the same issue again)
>> 
>> 2) Where is the general OSGi community heading? Blueprint/DS/other. The
>> first sentence of Tim Ward's post is something we thought significant.
>> Something that has concerned me over the last couple of years is sometimes
>> an alternative is suggested by needs some jiggery pokery to make it work, it
>> doesn't have wide support, little documentation, often has bugs which led to
>> a churn of releases. While it may be a cool, clever solution we aren't going
>> to bet our production system on cool and clever only.
>> 
>> 3) We are by and large glue coders and don't have the ability nor want to
>> spend the time/resource building our own custom  solutions, this is where I
>> think Spring has suited us well until now. We tried to identify what
>> offerings were available for the bits we needed e.g. JPA, JDBC,
>> 

Re: Blueprint or DS or what to use?

2016-03-21 Thread Christian Schneider
Indeed it is difficult to predict where the OSGi community will go in 
the future.


For DS the situation is hopefully a little better today than at the time 
I did the comparison.
- JPA can be solved today by using the Aries JPA and JPATemplate but it 
is not standardized. The upcoming spec hopefully will improve this.
- Services and Remoting can be solved by Remote Service Admin. With ECF 
and Aries rsa (CXF-DOSGi) there are now two stacks available on karaf 
that can help with this.
Still it can be a little rough if you want to use some special CXF 
features. We will have to prove using some good examples / pocs that 
Remote Services can fully replace the blueprint CXF namespaces.


Btw. I have some plans for Aries RSA to support application wide 
policies. The idea is to define some common aspects of your services 
centrally and apply them to all exported OSGi services. So for example 
you could define in one central point that all your services with JAXRS 
annotations should be auto exported and have single sign on 
authentication using STS, SSL encryption and logging.


The migration though is still a big issue.

Some time ago I did the migration of a medium sized production system 
from servlet container + spring to karaf + blueprint. The big problem 
there was that we had to do the transition
while the main team was going full steam and doing releases.  It was the 
start of the blueprint-maven-plugin as this was the only way to do 
migration without a big bang. So if you
have to do this then the annotation based approach + the plugin above 
can help a lot. If someone wants to try this I can help with some good 
advices. If there is some interest I can also blog about

how to do such a transition in practice.

A migration to DS will pretty much be a big bang as it is too different 
from spring to do a smooth transition. I think it is possible to do a 
full business application in DS but the migration step is bigger.


Christian

On 21.03.2016 02:24, Tim Jones wrote:

Andreas you are crossing or about to cross a bridge we are crossing at the
moment. We also have a SpringDM based application. It is 3+ years in
production and so a change as large as moving away from SpringDM is very
disruptive. For the most part we considered only Aries Blueprint vs DS.
However as you can see from this post there are other alternatives, some
fairly recent such as support for Spring namespaces in Aries Blueprint.

For us the most significant points to consider were

1) Will there still be good support in 5-10 years (having been burnt once we
don't want face the same issue again)

2) Where is the general OSGi community heading? Blueprint/DS/other. The
first sentence of Tim Ward's post is something we thought significant.
Something that has concerned me over the last couple of years is sometimes
an alternative is suggested by needs some jiggery pokery to make it work, it
doesn't have wide support, little documentation, often has bugs which led to
a churn of releases. While it may be a cool, clever solution we aren't going
to bet our production system on cool and clever only.

3) We are by and large glue coders and don't have the ability nor want to
spend the time/resource building our own custom  solutions, this is where I
think Spring has suited us well until now. We tried to identify what
offerings were available for the bits we needed e.g. JPA, JDBC,
transactional control, Camel JMS, CXF. It is an opinion only, but from what
I could see Blueprint offered the broadest support (see Christian's
ecosystems-compared
http://www.slideshare.net/mfrancis/osgi-ecosystems-compared-on-apache-karaf-christian-schneider).

The big one for us was lack of JPA/JDBC/transactional control for DS, while
there were some solutions we wanted something with a 'spec behind it'. This
is currently been worked on at the moment
(https://github.com/apache/aries/tree/trunk/tx-control) and I think it is a
significant piece of work that will make DS a much more attractive
proposition in the enterprise/applications space. Admittedly there is a risk
in being new adopter however we think the risk is worth it in this case.
Camel has a recent DS offering camel-scr (although I think there are some
issues with it). Hopefully in time more libraries will offer DS support out
of the box.

4) We are not yet sure we will be able to fully realise the pros of the
service dynamics that DS offers vs Blueprint as although one of our goals is
to be able to 'hot swap' bundles into a running system this may be harder to
achieve than we had hoped. We currently do some limited hot swapping with
our SpringDM system.

5) Perhaps counter intuitively of less importance to us was the actual ease
of transition, Blueprint would almost certainly be easier to migrate to from
SpringDM but we think that this is a one off cost that will be outweighed in
the long term.

Tim





--
View this message in context: 

Re: Blueprint or DS or what to use?

2016-03-20 Thread Tim Jones
Andreas you are crossing or about to cross a bridge we are crossing at the
moment. We also have a SpringDM based application. It is 3+ years in
production and so a change as large as moving away from SpringDM is very
disruptive. For the most part we considered only Aries Blueprint vs DS.
However as you can see from this post there are other alternatives, some
fairly recent such as support for Spring namespaces in Aries Blueprint. 

For us the most significant points to consider were

1) Will there still be good support in 5-10 years (having been burnt once we
don't want face the same issue again)

2) Where is the general OSGi community heading? Blueprint/DS/other. The
first sentence of Tim Ward's post is something we thought significant.
Something that has concerned me over the last couple of years is sometimes
an alternative is suggested by needs some jiggery pokery to make it work, it
doesn't have wide support, little documentation, often has bugs which led to
a churn of releases. While it may be a cool, clever solution we aren't going
to bet our production system on cool and clever only.

3) We are by and large glue coders and don't have the ability nor want to
spend the time/resource building our own custom  solutions, this is where I
think Spring has suited us well until now. We tried to identify what
offerings were available for the bits we needed e.g. JPA, JDBC,
transactional control, Camel JMS, CXF. It is an opinion only, but from what
I could see Blueprint offered the broadest support (see Christian's
ecosystems-compared
http://www.slideshare.net/mfrancis/osgi-ecosystems-compared-on-apache-karaf-christian-schneider).
 

The big one for us was lack of JPA/JDBC/transactional control for DS, while
there were some solutions we wanted something with a 'spec behind it'. This
is currently been worked on at the moment
(https://github.com/apache/aries/tree/trunk/tx-control) and I think it is a
significant piece of work that will make DS a much more attractive
proposition in the enterprise/applications space. Admittedly there is a risk
in being new adopter however we think the risk is worth it in this case.
Camel has a recent DS offering camel-scr (although I think there are some
issues with it). Hopefully in time more libraries will offer DS support out
of the box.

4) We are not yet sure we will be able to fully realise the pros of the
service dynamics that DS offers vs Blueprint as although one of our goals is
to be able to 'hot swap' bundles into a running system this may be harder to
achieve than we had hoped. We currently do some limited hot swapping with
our SpringDM system.

5) Perhaps counter intuitively of less importance to us was the actual ease
of transition, Blueprint would almost certainly be easier to migrate to from
SpringDM but we think that this is a one off cost that will be outweighed in
the long term.

Tim





--
View this message in context: 
http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045892.html
Sent from the Karaf - User mailing list archive at Nabble.com.


RE: Blueprint or DS or what to use?

2016-03-20 Thread CLEMENT Jean-Philippe
We use Blueprint mainly to have a code which makes use of services but without 
dealing with OSGi or annotations (as far as possible => few wappers). As long 
with the maven-bundle-plugin it is a kind of magic. I would say 
Blueprint+Maven+Karaf makes things really easy.

I would suggest to make a simple but representative example using CDI, DS, and 
Blueprint. Take time to have a full picture with you editor, plugins and 
compilation / assembly. See what is means in terms of effort to make, and think 
about what it would cost to enhance and maintain.

JP

-Message d'origine-
De : akuhtz [mailto:andreas.ku...@gmail.com] 
Envoyé : vendredi 18 mars 2016 11:24
À : user@karaf.apache.org
Objet : Blueprint or DS or what to use?

Hello,

I've an application running with spring-dm and because spring-dm is no longer 
developed I'm looking for a replacement.

Now I'm confused because there was a shift in karaf (core) from blueprint to DS 
and today I saw a post on the dev list, saying that DS does not support as much 
as blueprint does. 
As an end-user I would like to know what the proposed way to go is: DS or 
blueprint, both or what else?



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845.html
Sent from the Karaf - User mailing list archive at Nabble.com.


Re: Blueprint or DS or what to use?

2016-03-19 Thread Guillaume Nodet
No, there aren't any docs at the moment, and it has not been much used yet.
I haven't had any time to write a karaf feature for it yet ...

The blueprint-spring bundle allows you to use the standard spring namespace
along with spring custom namespaces from blueprint applications.
The blueprint-spring-extender bundle will act as the Spring-DM extender and
create a blueprint application for a spring-dm bundle.

Let me know if you hit any problem, I'd be happy to help you.

2016-03-18 18:17 GMT+01:00 Nick Baker :

> Can you point me to any documentation on this? I found a thread on the
> aries-dev but that's about it. When we abandoned Gemini we lost some of the
> functionality and would be interested in trying this out.
>
>
> http://mail-archives.apache.org/mod_mbox/aries-dev/201511.mbox/%3ccaa66tppfyb33d7m234ddeugxa6dj5jv24m09vv7u77dbjlo...@mail.gmail.com%3E
>
> Thanks!
>
> From: Guillaume Nodet 
> Reply-To: "user@karaf.apache.org" 
> Date: Friday, March 18, 2016 at 8:40 AM
> To: user 
> Subject: Re: Blueprint or DS or what to use?
>
> Fwiw, Aries Blueprint now has almost full support for Spring namespaces
> and Spring-DM bundles, you simply need to deploy blueprint, spring and the
> blueprint-spring + blueprint-spring-extender bundles.
>
> 2016-03-18 11:24 GMT+01:00 akuhtz :
>
>> Hello,
>>
>> I've an application running with spring-dm and because spring-dm is no
>> longer developed I'm looking for a replacement.
>>
>> Now I'm confused because there was a shift in karaf (core) from blueprint
>> to
>> DS and today I saw a post on the dev list, saying that DS does not support
>> as much as blueprint does.
>> As an end-user I would like to know what the proposed way to go is: DS or
>> blueprint, both or what else?
>>
>>
>>
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845.html
>> Sent from the Karaf - User mailing list archive at Nabble.com.
>>
>
>
>
> --
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>


-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/


Re: Blueprint or DS or what to use?

2016-03-19 Thread ellirael
I personally use Blueprint cause of:
1. common spring-like xml style of DI
2. prototype scopes
3. creating and describing internal skeleton of bundle in one file
4. CXF integration




--
View this message in context: 
http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045852.html
Sent from the Karaf - User mailing list archive at Nabble.com.


Re: Blueprint or DS or what to use?

2016-03-19 Thread Guillaume Nodet
Fwiw, you need to use the following bundles (blueprint-core,
blueprint-spring, blueprint-spring-extender) which are being released:
  https://repository.apache.org/content/repositories/orgapachearies-1061


2016-03-18 17:08 GMT+01:00 akuhtz :

> Hello,
>
> Thank you for all the helpful answers and pointers!
>
> I'll try to go first with the solution proposed by Guillaume and see if I
> get it working.
>
> Regards,
> Andreas
>
> 2016-03-18 14:10 GMT+01:00 CLEMENT Jean-Philippe [via Karaf] <
> ml-node+s922171n4045858...@n3.nabble.com>:
>
> > We use Blueprint mainly to have a code which makes use of services but
> > without dealing with OSGi or annotations (as far as possible => few
> > wappers). As long with the maven-bundle-plugin it is a kind of magic. I
> > would say Blueprint+Maven+Karaf makes things really easy.
> >
> > I would suggest to make a simple but representative example using CDI,
> DS,
> > and Blueprint. Take time to have a full picture with you editor, plugins
> > and compilation / assembly. See what is means in terms of effort to make,
> > and think about what it would cost to enhance and maintain.
> >
> > JP
> >
> > -Message d'origine-
> > De : akuhtz [mailto:[hidden email]
> > ]
> > Envoyé : vendredi 18 mars 2016 11:24
> > À : [hidden email]  /user/SendEmail.jtp?type=node=4045858=1>
> > Objet : Blueprint or DS or what to use?
> >
> > Hello,
> >
> > I've an application running with spring-dm and because spring-dm is no
> > longer developed I'm looking for a replacement.
> >
> > Now I'm confused because there was a shift in karaf (core) from blueprint
> > to DS and today I saw a post on the dev list, saying that DS does not
> > support as much as blueprint does.
> > As an end-user I would like to know what the proposed way to go is: DS or
> > blueprint, both or what else?
> >
> >
> >
> > --
> > View this message in context:
> >
> http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845.html
> > Sent from the Karaf - User mailing list archive at Nabble.com.
> >
> >
> > --
> > If you reply to this email, your message will be added to the discussion
> > below:
> >
> >
> http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045858.html
> > To unsubscribe from Blueprint or DS or what to use?, click here
> > <
> http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=4045845=YW5kcmVhcy5rdWh0ekBnbWFpbC5jb218NDA0NTg0NXwtNjQyODAyMjE1
> >
> > .
> > NAML
> > <
> http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer=instant_html%21nabble%3Aemail.naml=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
> >
>
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045860.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/


Blueprint or DS or what to use?

2016-03-19 Thread akuhtz
Hello,

I've an application running with spring-dm and because spring-dm is no
longer developed I'm looking for a replacement.

Now I'm confused because there was a shift in karaf (core) from blueprint to
DS and today I saw a post on the dev list, saying that DS does not support
as much as blueprint does. 
As an end-user I would like to know what the proposed way to go is: DS or
blueprint, both or what else?



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845.html
Sent from the Karaf - User mailing list archive at Nabble.com.


Re: Blueprint or DS or what to use?

2016-03-19 Thread Christian Schneider

I have a comparison in my DS tutorial.

http://www.liquid-reality.de/display/liquid/2015/06/30/Apache+Karaf+Tutorial+part+10+-+Declarative+services

The main two things missing in DS are the namespaces and the 
interceptors. In karaf internally we would not need those.

In a typical user application blueprint is probably still better.

Christian

On 18.03.2016 11:24, akuhtz wrote:

Hello,

I've an application running with spring-dm and because spring-dm is no
longer developed I'm looking for a replacement.

Now I'm confused because there was a shift in karaf (core) from blueprint to
DS and today I saw a post on the dev list, saying that DS does not support
as much as blueprint does.
As an end-user I would like to know what the proposed way to go is: DS or
blueprint, both or what else?



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845.html
Sent from the Karaf - User mailing list archive at Nabble.com.



--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com



Re: Blueprint or DS or what to use?

2016-03-19 Thread Christian Schneider

On 18.03.2016 13:07, Charlie Mordant wrote:

Let introduce an other player: Pax-CDI!

It is fully annotation based and a well known JavaEE standard with 
some additional annotations to deal with OSGi services.

I really prefer this way for development.

I'm used to deal with these 3 technologies and here are the case where 
I use one or another:


* I'm using blueprint when:
* * I would do spring xml binding to third parties classes: e.g. 
declaring ciphers or crypto algorthms binding... In this case 
Annotation-based configurations comes with some boilerplate code.
* * When dealing with JPA/JTA: Aries Jpa and Aries transactions are 
really nice OSGi integration stacks and they're blueprint based.

* * When I dealing with some init/destroy-methods in a bundle fragment.

* I'm using Declarative service when I have to code some low-level 
modules (all modules where the stack shouldn't need BP or CDI): DS is 
lighter than its concurrent.


* I'm using Pax-CDI everywhere else: its really a pleasure to just add 
@Inject @OsgiService on a bean attribute.


You can also mix CDI and blueprint using the blueprint-maven-plugin. It 
allows to use the cdi annotations even when you also need to specify 
parts of the blueprint by hand.
Of course the annotations are then parsed at build time only and you 
only have a subset of CDI but it is better than hand coding xml.


Christian


--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com



Re: Blueprint or DS or what to use?

2016-03-19 Thread Nick Baker
Can you point me to any documentation on this? I found a thread on the 
aries-dev but that's about it. When we abandoned Gemini we lost some of the 
functionality and would be interested in trying this out.

http://mail-archives.apache.org/mod_mbox/aries-dev/201511.mbox/%3ccaa66tppfyb33d7m234ddeugxa6dj5jv24m09vv7u77dbjlo...@mail.gmail.com%3E

Thanks!

From: Guillaume Nodet >
Reply-To: "user@karaf.apache.org" 
>
Date: Friday, March 18, 2016 at 8:40 AM
To: user >
Subject: Re: Blueprint or DS or what to use?

Fwiw, Aries Blueprint now has almost full support for Spring namespaces and 
Spring-DM bundles, you simply need to deploy blueprint, spring and the 
blueprint-spring + blueprint-spring-extender bundles.

2016-03-18 11:24 GMT+01:00 akuhtz 
>:
Hello,

I've an application running with spring-dm and because spring-dm is no
longer developed I'm looking for a replacement.

Now I'm confused because there was a shift in karaf (core) from blueprint to
DS and today I saw a post on the dev list, saying that DS does not support
as much as blueprint does.
As an end-user I would like to know what the proposed way to go is: DS or
blueprint, both or what else?



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845.html
Sent from the Karaf - User mailing list archive at Nabble.com.



--

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/



Re: Blueprint or DS or what to use?

2016-03-19 Thread Jamie G.
Depends upon your application, and what you want to do.

Each has their benefits, and detractions.

Personally I tend to use Blueprint for small wiring setups (say an AMQ
connection factory, and a Camel Context).

On Fri, Mar 18, 2016 at 7:54 AM, akuhtz  wrote:
> Hello,
>
> I've an application running with spring-dm and because spring-dm is no
> longer developed I'm looking for a replacement.
>
> Now I'm confused because there was a shift in karaf (core) from blueprint to
> DS and today I saw a post on the dev list, saying that DS does not support
> as much as blueprint does.
> As an end-user I would like to know what the proposed way to go is: DS or
> blueprint, both or what else?
>
>
>
> --
> View this message in context: 
> http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845.html
> Sent from the Karaf - User mailing list archive at Nabble.com.


Re: Blueprint or DS or what to use?

2016-03-18 Thread Charlie Mordant
Let introduce an other player: Pax-CDI!

It is fully annotation based and a well known JavaEE standard with some
additional annotations to deal with OSGi services.
I really prefer this way for development.

I'm used to deal with these 3 technologies and here are the case where I
use one or another:

* I'm using blueprint when:
* * I would do spring xml binding to third parties classes: e.g. declaring
ciphers or crypto algorthms binding... In this case Annotation-based
configurations comes with some boilerplate code.
* * When dealing with JPA/JTA: Aries Jpa and Aries transactions are really
nice OSGi integration stacks and they're blueprint based.
* * When I dealing with some init/destroy-methods in a bundle fragment.

* I'm using Declarative service when I have to code some low-level modules
(all modules where the stack shouldn't need BP or CDI): DS is lighter than
its concurrent.

* I'm using Pax-CDI everywhere else: its really a pleasure to just add
@Inject @OsgiService on a bean attribute.

Regards,
Charlie



2016-03-18 12:21 GMT+01:00 ellirael :

> I personally use Blueprint cause of:
> 1. common spring-like xml style of DI
> 2. prototype scopes
> 3. creating and describing internal skeleton of bundle in one file
> 4. CXF integration
>
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045852.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>



-- 
Charlie Mordant

Full OSGI/EE stack made with Karaf:
https://github.com/OsgiliathEnterprise/net.osgiliath.parent


Re: Blueprint or DS or what to use?

2016-03-18 Thread akuhtz
Hello,

Thank you for all the helpful answers and pointers!

I'll try to go first with the solution proposed by Guillaume and see if I
get it working.

Regards,
Andreas

2016-03-18 14:10 GMT+01:00 CLEMENT Jean-Philippe [via Karaf] <
ml-node+s922171n4045858...@n3.nabble.com>:

> We use Blueprint mainly to have a code which makes use of services but
> without dealing with OSGi or annotations (as far as possible => few
> wappers). As long with the maven-bundle-plugin it is a kind of magic. I
> would say Blueprint+Maven+Karaf makes things really easy.
>
> I would suggest to make a simple but representative example using CDI, DS,
> and Blueprint. Take time to have a full picture with you editor, plugins
> and compilation / assembly. See what is means in terms of effort to make,
> and think about what it would cost to enhance and maintain.
>
> JP
>
> -Message d'origine-
> De : akuhtz [mailto:[hidden email]
> ]
> Envoyé : vendredi 18 mars 2016 11:24
> À : [hidden email] 
> Objet : Blueprint or DS or what to use?
>
> Hello,
>
> I've an application running with spring-dm and because spring-dm is no
> longer developed I'm looking for a replacement.
>
> Now I'm confused because there was a shift in karaf (core) from blueprint
> to DS and today I saw a post on the dev list, saying that DS does not
> support as much as blueprint does.
> As an end-user I would like to know what the proposed way to go is: DS or
> blueprint, both or what else?
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045858.html
> To unsubscribe from Blueprint or DS or what to use?, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845p4045860.html
Sent from the Karaf - User mailing list archive at Nabble.com.


Re: Blueprint or DS or what to use?

2016-03-18 Thread Timothy Ward
Hi,

From an OSGi standards perspective it’s worth pointing out that the Blueprint 
specification has not been touched since it was first released in OSGi 4.2. 
There are a few proposed extension RFCs for Blueprint, but none have seen much 
activity in five years or more.

Declarative Services, however, has been actively extended with new features 
over the last few specification releases. Annotation-based metadata, type-safe 
configuration, PrototypeServiceFactory support, field injection support, and 
dynamic service wiring control using Configuration Admin are all cool DS 
features that seem unlikely to ever make it into a Blueprint standard.

Karaf and Apache Aries have done a lot of work to enhance the Blueprint 
Container with namespaces and interceptors, however all of these additions are 
implementation specific and tie you in to that particular stack. This is not a 
problem for some applications, and is a problem for others. 

In summary, moving your application from Spring DM to Blueprint will almost 
certainly be faster to achieve because Blueprint was heavily based on Spring 
DM. I, however, would use this opportunity to move to DS because the standard 
is actively being maintained and extended. As further food for thought, the 
OSGi enRoute project (http://enroute.osgi.org ) is 
entirely DS based, and doesn’t offer Blueprint in its platform at all.

I wish you all the best with your decision.

Regards,

Tim

> On 18 Mar 2016, at 10:30, Christian Schneider  wrote:
> 
> I have a comparison in my DS tutorial.
> 
> http://www.liquid-reality.de/display/liquid/2015/06/30/Apache+Karaf+Tutorial+part+10+-+Declarative+services
> 
> The main two things missing in DS are the namespaces and the interceptors. In 
> karaf internally we would not need those.
> In a typical user application blueprint is probably still better.
> 
> Christian
> 
> On 18.03.2016 11:24, akuhtz wrote:
>> Hello,
>> 
>> I've an application running with spring-dm and because spring-dm is no
>> longer developed I'm looking for a replacement.
>> 
>> Now I'm confused because there was a shift in karaf (core) from blueprint to
>> DS and today I saw a post on the dev list, saying that DS does not support
>> as much as blueprint does.
>> As an end-user I would like to know what the proposed way to go is: DS or
>> blueprint, both or what else?
>> 
>> 
>> 
>> --
>> View this message in context: 
>> http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845.html
>> Sent from the Karaf - User mailing list archive at Nabble.com.
> 
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Open Source Architect
> http://www.talend.com
>