On 12/09/2013 09:27, Felix Meschberger wrote:
Hi
Am 12.09.2013 um 09:10 schrieb [email protected]:
Yes it make sense. We will continue this investigation with iPojo
community.
Excellent. You reach them here on this list, too ;-)
Yep but I was thinking on writting some JIRA issue to be more precise or
maybe we can continue with technical stuff in the user mailing list ?
Anyway I just saw another thread with same problem so I guess this is
the good one to follow ;)
Anyway good to know that OSGi API is fully backwards compatible... But
I'm curious : is that one of the reasons why Felix osgi version is still
4.2 in the svn trunk ? Are there other points which explain that version
is still 4.2 in the felix trunk ?
What specific project are you referring to ?
Unlike other open-source projects, the different Apache Felix subprojects are
pretty much independent of each other (or have limited dependencies like for
example the main project depending on and using the framework project).
So, some projects may refer to OSGi 4.2 while other refer to OSGi 5 depending
on the actual requirements of these projects.
Well I'm discovering the felix trunk and I did a very quick grep on
<osgi.version> and I saw only 4.2 everywhere... And as you say I was
wrong to believe there was only 4.2 from my grep ;)
Thank you
Regards
Felix
Thank you
On 12/09/2013 08:50, Felix Meschberger wrote:
Hi
Am 12.09.2013 um 08:33 schrieb [email protected]:
Thank you for this first and quick answer... Let me be more precise.
Currently we are working on Apache Felix iPojo integration into WildFly
alpha. As you may know the WildFly alpha OSGI is based on JBoss OSGI 2.1
which is using org.osgi.core 5.0.0 and we believe this is the reason why
our integration of iPojo to WildFly is not working because as far as I
see in the svn Felix trunk pom the current OSGI version is 4.2.0...
I don't think this is the problem: iPojo may be written against OSGi R4.2 but
there is no reason to believe it would not run on an OSGi R5 Core compliant
framework. The OSGi API is (up to now) always fully backwards compatible so
that code written against old versions will work with newer versions (unless
they implement OSGi API, which may require updates, but AFAICT that is not the
case with iPojo)
I think the iPojo community would be more than willing to help you on concrete
issues you may encounter deploying WildFly with iPojo on JBoss OSGi. But you
would probably have to be more specific reporting issues.
Does that make sense ?
Regards
Felix
Depending on the Felix roadmap we may postpone our iPojo integration
into WildFly and use JBoss EAP 6 - which is using OSGI 4.2 through JBoss
OSGI 1.X ... But maybe some people on this list already try and succeed
this integration ?
Thank you
On 12/09/2013 08:20, Felix Meschberger wrote:
Hi
What exactly do you want to know ?
OSGi R5 (Core, Compendium, Enterprise) is a collection of specifications. Some
are implemented in the Apache Felix project, some are not.
As for OSGi R5 Core, IIRC the Felix Framework is almost complete (there has
been done a gap analysis once). As for OSGi R5 Compendium and Enterprise: We
have for example implementations of a number of service specifications (Log,
Http, Configuration Admin, Declarative Services, Metatype, Preferences), which
AFAICT are reasonably complete or even passing the OSGi R5 CT -- Configuration
Admin is even the reference implementation.
Other specifications, such as JTA, JDBC, etc., are implemented by the Apache
Aries project.
Does that help answer your question ?
Regards
Felix
Am 12.09.2013 um 07:33 schrieb [email protected]:
Hello,
I would like to get some news about OSGI R5 implementation in Apache
Felix and Apache Felix iPojo as I just see a mail archived thread about
that here :
http://www.mail-archive.com/[email protected]/msg13638.html
Do you now have "some people" and roadmap on that subject ?
Thank you !
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
