On 27.01.2016 16:02, Charlie Mordant wrote:
Hi guys,
As I'm going to upgrade Osgiliath framework to the latest an greatest
Karaf version, I'm re-synchronizing features version (e.g. aligning
jta versions to have one and only one javax.transaction package
exported with only one version if possible).
I made this thread with some todos, some interrogations, etc...
Generic questions:
* 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 guess you refer to this Christian
http://blogs.itemis.com/xtext/author/christian-schneider. This is not me.
Aries JPA 2 should be quite production ready. In fact I tested it much
more than the old 1.x versions.
These examples use it with full JTA support
https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-ds
https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-blueprint-cdi
This might also be interesting:
https://github.com/Talend/tesb-rt-se/tree/master/examples/tesb/ebook
It is my first example that uses JMS and JDBC in the same XA transaction.
There is a catch with karaf 4.0.4 though.
http://stackoverflow.com/questions/35038491/why-am-i-getting-is-not-a-namedxaresource-in-apache-karaf-4-0-4
Unfortunately I am not very much involved with the eclipse communities
but wherever I can I try to improve the relations to the karaf and
apache communities. It is really important that we work together in the
OSGi space.
* 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...
Not sure. Recently there was no big activity around OSGi there as far as
I know.
I put great hopes into IBM though. At eclipsecon I met Emily Jiang
(https://www.linkedin.com/in/emily-jiang-60803812). She works on a new
CDI spec for IBM that includes full OSGi support.
They plan to do the implementation at Apache Aries. So I hope when they
work on this they will also either solve the JPA part or give the people
at DeltaSpike some motivation to work on this.
Until a better CDI is ready you can take a look at the
blueprint-maven-plugin. It uses CDI and JEE annoations and create
blueprint at build time. So you can work like in CDI and at runtime have
the stable blueprint impl underneath. The sceond example above uses it.
* 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).
I hope we can improve the support for repositories. Tim Ward from
Paremus has written a maven plugin to create index files from maven
depdendencies. I already started to create such indexes
for several Apache projects (CXF, Aries Transaction and JPA). This
should make it a lot easier to work with Apache Projects in bndtools.
On Karaf we also plan support for this to back feature definitions with
repositories.
* Deltaspike/CDI can be transactional, listen config from configadmin,
deltaspike-data can also be tx aware, it could be nice to dig in it.
Actually deltaspike jpa would be the missing link in making CDI really
usable in OSGi.
* Should I use Hibernate? I want JPA 2.1, search engine, auditing...
I'd love to use Apache stuff, but...
From my experience Hibernate is currently the best supported JPA
provider for Karaf. Hibernate 5 offers a karaf feature. Unfortunately
the current feature is slightly broken.
Their next version should work fine.
In my tasklist-ds example I use a patched feature that make hibernate 5
work nicely in karaf 4.0.4:
https://github.com/cschneider/Karaf-Tutorial/blob/master/tasklist-ds/features/src/main/resources/features.xml
* 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)
Karaf now supports the dependency=true attribute for bundles. This is
very helpful for spec bundles. It means that bundle will only be
installed if it is required. So the resolver can decide. Using this
allows to avoid having duplicate spec bundles installed in most cases.
Actually the current hibernate 5 feature just needed this attribute to
work correctly in karaf 4.
* 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.
It is an historic thing. A lot of the eclipse folks use the eclipse PDE
perspective which features the Manifest first style. I think many are
seeing that pom first is better but such things change slowly.
Bndtools could help a lot to show people how nice it can be to work with
generated Manifest files.
* 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>
I hope the repository support can help with that.
* 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.
Thanks for the kind works. I fully agree. Unfortunately we are a bit
disconnected with both the OSGi alliance and also with the Eclipse
community. We all need to work on improving these connections.
We can only drive OSGi by cooperating with these communities. Alone we
are too small.
Best regards,
--
Charlie Mordant
Full OSGI/EE stack made with Karaf:
https://github.com/OsgiliathEnterprise/net.osgiliath.parent
Btw. I am really looking forward to you guys working closer with the
karaf community. You are doing really great stuff with the Osgiliath
projects.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com