Thanks for your examples Jean-Baptiste! I was tinning more about practical business use cases, but let me comment on those.
First though a little disclaimer. Even though I'm familiar with how Blueprint works in general, I have not used it for anything serious. For me it has always been too Spring'ish and the amount of "magic" it uses is a little bit too much. I moved from iPojo to DS and this is what I have been using for the last couple of years. So I would leave aside the native OSGi (I fully agree with Christian on that one) and Blueprint (I don't feel I'm in a position to comment in a prejudice free way). Now about the examples. I don't think I need to comment on the first one at all. Assuming you are right in your estimations I don't think 5% is worth learning yet another approach. Especially one that tries to hide from you how things actually work. And as the project grows I think those 5% will quickly go down to 0 (if not in the negative range) because one can hardly do anything serious in OSGi without good understanding of how service registry (including filters, ratings, patterns, configadmin, ...) works . As for the second example - I think there is a huge difference between remote services (REST, SOAP, ...) and persistence / transactions and we should not consider those equal to automate / simplify. Remote services are straightforward. You request a resource, something builds it for you (how, is totally out of scope for the use case) and sends it back to you in the form requested. This is very very easy to automate. In fact in one of my demos (which btw I will present at ApacheCon) I do exactly that. It's bundle with a single class using standard JAX-RS annotations. I don't see how can you make it any easier than that. JPA and JTA is a whole different story. It is complex. Not because of the standard, framework or the implementation but because of the domain it operates on. Developer need to know the model, relationships, constraints, isolation levels, limitation of the underlying storage, ... thousands of things. Honestly speaking I don't see @jpa(provider="openjpa",dataSource="my") useful for anything but a very simple use case (tempted to write a "hello world" equivalent). I still remember the CMP EJB that was supposed to make this so simple and how it died naturally because simple equals limited. Then Hibernate made ORM useful. But let's be honest here, it was far from simple. And still people were moving from EJB to Hibernete to get the job done. We (the Java community) have walked a long way to bring ORM to what it is today and it's still far from simple. That is because the problem it targets is complex and flexibility is far more important for any real use case. With all the respect, I don't believe a few high level annotations will make anyone switch to Karaf for some serious projects. For personal projects and initial attraction - may be. But if you want to introduce this as a technology to be used in a real project - "it's easy" is not enough argument to convince your senior architects. In fact I would argue that if the SpringBoot didn't have the word "Spring" in it (and all the trust and marketing that goes with that) it could have existed for a number of years and none of us would have heard about it. On the other hand in the OSGi landscape we already have a bunch of projects which goal is to make it easier for Java EE folks to move to OSGi world. But even they have realized you can't completely ignore and hide OSGi. You are probably familiar with Amdatu's projects. I must admit I find their web services and DOSGi approach a lot easier than CXF. Also more flexible. But it's not only that. Out of curiosity, I just had a look at Pax CDI and surprise surprise there is a @OsgiService annotation there. There is also an explanation of requirements and capabilities which one need to understand. Sure those can be generated for you by the build tool and you can completely ignore @OsgiService annotation and only wire your beans. But in such case my question would be: why are you using OSGi ? There is also bnd and bndtools that in many cases simplify development a lot (and you can use them with ant, maven, gradle, whatever the build system of tomorrow will be). My point is, I wish we (OSGi community) were more united and more collaborating. I think there is too much internal competition in the space and efforts are focused in promoting particular projects (often by attempting to compete with a well established JEE product) and not so much the technology itself. I think OSGi (as of release 6) is simple enough. I think there are plenty (IMHO too many) of choices for developing OSGi applications to choose from to be as close as possible to what you already know. I think it will never be the case that someone would develop something serious with OSGi without investing in knowing how it works! I think what is hard is hard because it has to be hard. When it is "hard" it make you think about why you are doing what you are doing. Ultimately this results in better design and solid architecture. That is not to say there is nothing to improve. But I'm more on Christian's side here. I would look around to see how to improve what is already there. Whether that is CDI (really? people want that?) or (better) integrating with bnd/bndtools or something else. To quote Einstein "make as simple as possible but not simpler" ;) Regards, Milen On Sun, Sep 13, 2015 at 7:51 PM, Christian Schneider < [email protected]> wrote: > The CDI and JEE annotations are exactly taylored to the enterprise use > cases. I doubt that we can create better ones. > Abstracting away from the technology can only mean you introduce another > layer of indirection. This can only make sense if the underlying technology > is crappy which I think is not the case. > > I am looking forward to see what you propose but I think reinventing the > whole set of annotations will probably not be the way to go. We saw this > path in the karaf 4 commands and I think the result is not good. > Instead I propose we look at the annotations and examples you provide and > think how they could be implemented with existing standards + a minimal set > of additional > annotations that fit well into an existing technology. > > Christian > > > Am 13.09.2015 um 19:13 schrieb Jean-Baptiste Onofré: > >> Hi Christian, >> >> Workload is one thing, multi-dependencies/pom/etc is something. >> >> In the annotations, even if the workload is the same, it's the kind of >> annotations. The purpose is to provide more high level, use case centric >> annotations, more than low level technical one. >> >> I agree that we could extend the maven-blueprint-plugin, but I would >> prefer to keep it more high level and decoupled from the underlying >> technology involved. >> >> karaf-boot purpose is to be straight forward and avoid the "big mess & >> soup about what should I use, what the version, etc". >> >> I'm still convince that at least a BoM provided by karaf-boot is >> interesting. >> >> I'm also still think that an abstract Karaf oriented is valid. >> >> Regards >> JB >> > > -- http://about.me/milen
