karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Suggested 3.x.x functionality
Date Mon, 28 Feb 2011 20:05:19 GMT
Just some more comments after reviewing the deployers source:

1/ did you take a look on wrap deployer ?
3/ the blueprint and spring deployer already scan all XML files in 
META-INF/spring and OSGI-INF/blueprint

Regards
JB

On 02/28/2011 09:00 PM, Jean-Baptiste Onofré wrote:
> Hi Mike,
>
>
> On 02/28/2011 07:36 PM, karafman wrote:
>> We've been talking in IRC about new features we could add to Karaf to
>> make it
>> more accessable to development teams who don't know much about OSGi.
>> Things
>> that would decrease the learning curve. This thread's intent is to gather
>> suggestions, and to give feedback to them.
> Be careful with this kind of statement :)
> Karaf is an OSGi container. OSGi is a technology, a programming method,
> a norm/specification. So people should learn OSGi. People should adapt
> to OSGi, and not the reverse. It's exactly the same think when JEE began.
> However, if at the end people should have a good OSGi understanding, I'm
> OK to provide ways to increase OSGi adoption :).
>
>>
>> To start the thread:
>>
>> 1) Inspect each bundle on deployment for the MANIFEST.MF header
>> "Bundle-ManifestVersion", and then automatically wrap ones missing that
>> header.
> I'm not sure to follow, what the purpose of this ? Felix
> maven-bundle-plugin populates the Bundle-ManifestVersion statement, and
> for non-OSGi jar, the wrap deployer add it too.
> So, -1 for me, the bundle should be well formed and wrapped.
> I'm ok to raise a warning message but not to do it for the users.
>> 2) Have Karaf look at each .jar or .ear being deployed for a
>> "Bundle-Version" in its Manifest.MF file, and if it doesn't have it, look
>> for a ./lib directory, wrapping and deploying everything in that
>> directory,
>> then removing it from the original .jar file, then wrapping the original
>> .jar file, and finally deploying and starting the original. This wouldn't
>> configure services, but it would provide a strong starting point for
>> teams
>> moving from JEE to Karaf.
> Why not but it could have important side effect.
> I'm more to log a warning message.
>> 3) Have karaf look in META-INF/spring and OSGI-INF for all xml files, and
>> then automatically add any packages referenced there to the
>> Import-Package
>> portion of the MANIFEST.MF file. This is probably a bnd change, but still
>> would be a nice-to-have.
> Same, as previous point, it could have side effect.
>
> I understand your points but I'm not very please to provide it
> "automatically" in Karaf.
>
> Regards
> JB
>
>>
>> -----
>> Karafman
>> Slayer of the JEE
>> Pounder of the Perl Programmer
>>

Mime
View raw message