Christian, sorry for the wrong announce (there's another Christian Schneider elsewhere), I'm embarassed. But the question on Aires JPA2 is already here ;).
pax-cdi supports deltaspike, weld, openwebbeans. I never tried, but it's > shipped in Karaf. But deltaspike-web and Agorava aren't. There are also IMO some lacks (intra bundle deps) and concurrent technologies (the main efforts should converge to the best solution). > We already use requirements and capabilities internally. You can also > define the reqs/caps on features using dedicated shell commands. Not for All dependencies, does the OBR spec specify it (and is it aligned on). > No idea there, but I guess we can inject the TransactionManager > (providing by the transaction feature). A little more complicated than that, I tried using CDI txmngr 'alternatives', but classloader's didn't let me happy with it. > it's related to the BOM that we gonna provide with karaf-boot. > Glad to hear, it won't be easy, but it's the right thing to reach. > For Eclipse and OSGi Alliance, it's different story. > I hope that in the mid term, these both way of doing things will join their effort. > We drive nobody: we invite people to work together with us ;) Yes but you have the best way of doing things: EE, Spring, Eclipse guys should have reach you because you're right and they're needing these features: it may be due to a lack of lobbying, also the fact that some 'commercials' are telling that it's difficult, which is the exact opposite. As always, Best regards, you're the ones! Charlie 2016-01-27 16:13 GMT+01:00 Jean-Baptiste Onofré <[email protected]>: > Hi Charlie, > > See my comments inline: > > * Is aries-jpa 2 dry? production ready, etc... Christian, I heard you'll >> join/be a recognized contributor of a new company with some awesome >> guys: will you stay to be active on this project (community), or better, >> will you 'sell' these wonderful things at these guys, which are using >> technologies that are not as mature/different (some guys in the Eclipse >> community will greet you, and the one who are not aware of this will ask >> how they did before you). >> > > I let Christian answers to this point as it's addressed to him. > > * Are Deltaspike-web and maybe Agorava soon be OSGi ready? IMO CDI is a >> very nice spec and OSGI should throw their good old injection stuff to >> move to one way of doing things (throwing blueprint, scr, direct >> whiteboard interaction, etc), also social things are more and more >> mandatory to launch a website... >> > > pax-cdi supports deltaspike, weld, openwebbeans. I never tried, but it's > shipped in Karaf. > > * Is Karaf easily adaptable to 'standard' remote dependency management >> (OBR), so is it easy to launch a Karaf fully featured server within BND >> (it brings some nice stuff: repository setup and semantic versioning >> scan). >> > > Karaf supports "old style OBR" but also R6 Bundle Repository. It's what we > name resources repositories. These repositories can be loaded using > resourcesRepositories property in etc/org.apache.karaf.features.cfg, or > directly in a features XML using <resources-repository/> element. > > I have a blog quite ready showing how to use resources repositories > provided by Karaf Cave or generated by bnd. > > * I'll love to see a Require-Capabilty='osgiEE-web' and setting up a >> fully fledged Karaf ^^. In a first time, we could remove feature >> dependencies using capabilities and resolving it). >> > > We already use requirements and capabilities internally. You can also > define the reqs/caps on features using dedicated shell commands. > > * Deltaspike/CDI can be transactional, listen config from configadmin, >> deltaspike-data can also be tx aware, it could be nice to dig in it. >> > > No idea there, but I guess we can inject the TransactionManager (providing > by the transaction feature). > > * Should I use Hibernate? I want JPA 2.1, search engine, auditing... I'd >> love to use Apache stuff, but... >> > > It should work: users reported to use Hibernate with JPA (and > annotations). A sample is in progress in the new dev guide. AFAIR, > Christian's tasklist sample uses it. > > * Will Apache community (also OPS4J one <3) will consume some 'generic' >> poms: standardizing latest versions of the servlet/injection/jta spec, >> etc... There are many frameworks 'Karaf aware' (cxf, amq, pax-*), it >> could be nice to avoid concurrent versions of 'spec' stuff. Maven pom >> fragments could help if available (at lest, osgiliath, with some help >> can be a missing part of this issue, ensuring all these different >> project are interoperable) >> > > IMHO, it's related to the BOM that we gonna provide with karaf-boot. > > * Why isn't the Eclipse community using pom-first, bnd, etc to create >> and release their product: it should be an objective to have one way of >> doing things (and throwing Tycho, P2, extension point and stuff). This >> community is already OSGI ready, they're just making the wrong choices >> and should be mentored. >> > > Christian and I are involved in the bndtools community. For Eclipse and > OSGi Alliance, it's different story. > > > * Without the Apache 'MegaPom' in place A simple jar with a main method >> could 'unpack' a feature to give standard pom informations and >> variabilizing tha feature. >> e.g. >> <feature name="stuff" version="1.0.0"> >> <bundle>mvn:bargroup/barartifact/2.0.0</> >> </feature> >> => >> <feature name="stuff" version="${stuff.version}"> >> <bundle>mvn:bargroup/barartifact/${bargourp_barartifact.version}</> >> </feature> >> <dependencyManagement> >> <dependency> >> <groupId>bargroup</groupId> >> <artifactId>bargroup</artifactId> >> <version>${bargroup_barartifact.version}</version> >> </dependency> >> </dependencyManagement> >> <dependencies> >> <dependency> >> <groupId>bargroup</groupId> >> <artifactId> barartifact </artifactId> >> </dependency> >> </dependencies> >> <properties> >> <bargroup_barartifact.version>2.0.0</bargroup_barartifact.version> >> <stuff.version>1.0.0</stuff.version> >> </properties> >> > > Again, it sounds like what we plan in karaf-boot and BOM. > > * When will you drive the OSGI community! IMO Karaf is the most advanced >> OSGi framework (or the most respectful and simply the best) of all time. >> > > We drive nobody: we invite people to work together with us ;) > > Some people are not convinced that Karaf is what they need (and I respect > that). But anybody interested by what we do are welcome, and we are > discussing with everyone ! > > The new "marketing" materials (site, documentation, etc) is part of our > "popularity" strategy. > > Regards > JB > > > >> >> >> About the issues (for now): >> * On pax-cdi: >> Issues: >> I'm using the 1.0.0.RC1 version, 'pax-cdi-1.2-web' is using >> 'pax-cdi-1.2' feature, which is inexistant: this feature should be >> removed. >> >> I'll continue on this thread posting some minor issues that migration, >> feel free to merge contributions in your respective projects and >> improving the bests technologies of all times! >> >> Best regards, >> >> -- >> Charlie Mordant >> >> Full OSGI/EE stack made with Karaf: >> https://github.com/OsgiliathEnterprise/net.osgiliath.parent >> > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com > -- Charlie Mordant Full OSGI/EE stack made with Karaf: https://github.com/OsgiliathEnterprise/net.osgiliath.parent
