I wasn't aware of this fact, and I find it rather disturbing. Till now I was under the impression that the maven-blueprint-plugin was just another complementary way of creating the blueprint.xml Not a replacement. Especially since those annotations are just build-time and not runtime annotations and there is no way of using std. CDI annotations for Blueprint beans, I can't see much of a benefit. And while at it, you remember spring? Spring can always be configured in two ways and even mixed. Therefore this is very worrying for me. Cause that Announcement was as clear as your statement right now.
regards, Achim 2015-09-16 19:39 GMT+02:00 Christian Schneider <ch...@die-schneider.net>: > Your are not wrong Aries JPA 2 and Aries transaction 3 will be annotation > only. > You will only have the enable elements in the xml. This was announced > quite a while ago on the dev list. > In fact the disruptive nature is why both are major versions. > > The JPA and JTA annotations are not related in any way to the old > blueprint annotation support. > The old blueprint annotations were completely Aries proprietary. As far as > I know they were never really used much. > > The maven-blueprint-plugin is also unrelated to the old blueprint > annotation support. > My goal for all these developments is to rely as much on standard > annotations as possible. I think the reason why the old blueprint > annotations never took off is that they introduced one more proprietary > injection model. People are not willing to throw all they learned over board > and learn some proprietary model that will even lock them in. Another > argument for the standard annotations is that we need much less > documentation as > they are well documented in the standards. > > About the xml support for JPA and JTA. It would have been possible to keep > it but I do not really see a big advantage for the xml. It is much more > verbose and made the > code quite complicated. The new code for JPA and JTA is much simpler to > read and maintain. > > If you want to keep with the xml support then you can stay on the 1.x > versions. The IBM developers on Aries announced that they will keep using > them for quite some while. > So I hope they will provide maintenance releases. > > Btw. For the new annotations you do not need to annotate each method. You > can use @Transactional on the class level and override on methods were you > need different behaviour. > > Christian > > > Am 16.09.2015 um 16:50 schrieb jochenw: > >> Hello Christian, >> >> ok, then my expectation was wrong, that the mechanisms to use annotations >> or >> definitions in xml always exist in parallel, and one can use the one or >> the >> other. >> >> So if up to now one decided to use the blueprint.xml file since >> annotations >> were still in experimental state, it is not possible to completely >> continue >> with that, since the xml support for some functions is discontinued (here >> jpa:context). These things need to be defined via an annotation. >> >> Will Aries Transaction 3 also be "disruptive", i.e. tx:transaction >> method="*" ... will no longer be supported? Is quite handy if I want to >> have >> transaction activated for all methods in my persistence bundle, without >> the >> need to have an annotation for each method. >> >> Please don't get me wrong - it's not a complaint. I just haven't expected >> that blueprint xml support for JPA is deprecated, and want to make sure >> that >> it is really like this - to we *have *to switch to annotations for JPA and >> maybe JTA (in future). (The Aries documentation still tells that blueprint >> annotations is prototype work ...) >> >> Best Regards, >> >> Jochen >> >> >> >> >> >> >> >> -- >> View this message in context: >> http://karaf.922171.n3.nabble.com/Bundle-is-waiting-for-namespace-handlers-http-aries-apache-org-xmlns-jpa-v1-0-0-tp4042275p4042630.html >> Sent from the Karaf - User mailing list archive at Nabble.com. >> > > -- Apache Member Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> Software Architect / Project Manager / Scrum Master