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
