directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@gmail.com>
Subject Re: [OSGi] Shared bundles update
Date Tue, 18 Jan 2011 09:44:38 GMT


Sent from my iPhone

On Jan 18, 2011, at 11:33 AM, Pierre-Arnaud Marcelot <pa@marcelot.net>  
wrote:

> Hi Alex,
>
> My answers inline...
>
> On 18 janv. 2011, at 10:05, Alex Karasulu wrote:
>
>> Hi Pierre,
>>
>> On Mon, Jan 17, 2011 at 3:39 PM, Pierre-Arnaud Marcelot <pa@marcelot.net 
>> > wrote:
>>> Hi Alex,
>>> Thanks for converting the modules into bundles.
>>
>> No biggy just some maven xml.
>>
>>> I took some extra steps [1] [2] (the same ones as for the i18n  
>>> modules) to
>>> make the bundle fully compatible with Studio's build:
>>> - Generation of the MANIFEST.MF file in a top level META-INF  
>>> folder (ignored
>>> by SVN)
>>> - Usage of ${project.property} instead of ${pom.property} for  
>>> Maven 3
>>> compliance
>>
>> Ahh yes I should make the other bundles do the same. We have to do
>> this for all modules in ads and shared.
>>
>>> - Removal of Bundle-Version directive which is inherited  
>>> automatically from
>>> the project version
>>
>> Oh I did not know we have to do this. Can you explain why we have to
>> do this just so I can understand?
>
> There's nothing mandatory here. But I think it's safest to go with  
> the inherited default setting instead of hardcoding the current  
> default setting in each pom.
> If someday in the evolution of the plugin, the default setting  
> changes, we'll inherit it automatically. While if we hardcode this  
> value, it might break our build later.

Ok that's a good reason.

>
>>
>>> - Usage of ${project.name} as Bundle-Name (instead of $ 
>>> {project.artifactId})
>>
>> Sure we can do this too.
>>
>>> After fixing an issue with a wrong version used in Studio for  
>>> Commons Lang
>>> (2.3 instead of 2.5) I was able to replace Studio's libraries  
>>> plugins of
>>> Shared by the OSGI-fied Shared dependencies within Eclipse.
>>> Studio seems to work like a charm. :)
>
> Unfortunately, Studio only seemed to work like a charm yesterday.
> On the afternoon I ran into an issue with the loading of Schema  
> elements (syntaxes, matching rules). The classes couldn't be found.
> This is related to the fact that two modules, shared-ldap and shared- 
> ldap-schema, share a package with the same name  
> 'org.apache.directory.shared.ldap.schema'.
> Since we're using the 'Import-Package' directive to link bundles in  
> the MANIFEST.MF file, having two bundles with an identical package  
> name messes things up.
> I'm going to rename of these packages to solve this issue.
>

Just thinking this might not be needed if for ldap-schema we simple  
omit or explicitly use '-' prefix for this package in the manifest to  
prevent the export of oadsl.schema pkg. This pkg has no classes in  
ldap-schema so it could work.

>>> I think we should also turn the 'all' module as a bundle. It's  
>>> pretty easy
>>> and doesn't harm to do it.
>>
>> Yeap no problem we can do this as well. We just need to make sure we
>> use the same tactic as I did in shared-ldap-schema because of the bug
>> in the maven-bundle-plugin.
>
> Yes, indeed.
>
>>
>>> Regards,
>>> Pierre-Arnaud
>>> [1] - http://svn.apache.org/viewvc?rev=1059824&view=rev
>>> [2] - http://svn.apache.org/viewvc?rev=1059834&view=rev
>>>
>>> On 16 janv. 2011, at 14:36, Alex Karasulu wrote:
>>>
>>> The conversion of ldap-schema into a bundle is complete but I want  
>>> to
>>> test it in the OSGi environment to make sure it's working properly.
>>> Might setup an integration test using felix in the shared-integ  
>>> module
>>> and make sure the module only runs with an -Dintegration flag/ 
>>> profile.
>>>
>>> Is it worth turning the 'all' module, shared-all, into a bundle as
>>> well? Thoughts?
>>>
>>> Regards,
>>> Alex
>>>
>>> On Sun, Jan 16, 2011 at 1:53 PM, Alex Karasulu  
>>> <akarasulu@apache.org> wrote:
>>>
>>> STATUS:
>>>
>>> ------------
>>>
>>> The following modules have been converted into bundles:
>>>
>>>   o i18n
>>>
>>>   o ldap
>>>
>>>   o ldap-client-api
>>>
>>>   o dsml-parser
>>>
>>>   o dsml-engine
>>>
>>> I will not bother with the following modules for reasons that should
>>>
>>> seem apparent:
>>>
>>>   o all
>>>
>>>   o integ
>>>
>>> The following modules still need to be made into bundles:
>>>
>>>   o ldap-schema
>>>
>>>
>>> ISSUES:
>>>
>>> -----------
>>>
>>> There seems to be some issues with the default operation of the
>>>
>>> maven-bundle-plugin where the schema file names are causing the  
>>> plugin
>>>
>>> to barf. Here's something I had posted a couple years ago about the
>>>
>>> matter on felix-dev which seems still to be the case [0].
>>>
>>> Note the ldap-schema packages together schema LDIF files into the  
>>> Jar.
>>>
>>> This is extracted out by a LdifExtractor class. The maven antrun
>>>
>>> plugin is used to build index files as well and the default jar
>>>
>>> archiver is used.
>>>
>>> This however probably can be solved by just generating the OSGi
>>>
>>> manifest with the bundle plugin and letting the current process  
>>> using
>>>
>>> the jar archiver run without overwriting the manifest file.
>>>
>>> I'll play around with this.
>>>
>>>
>>> GOING FORWARD:
>>>
>>> --------------------------
>>>
>>> I guess we can start using the converted bundles in the studio build
>>>
>>> as direct dependencies. Also Pierre/Stefan could y'all update me on
>>>
>>> the steps we needed in the studio build to use the direct bundle
>>>
>>> dependency? That way I can update studio's build myself to use the
>>>
>>> ldap-schema bundle once it is complete. I also want to understand  
>>> what
>>>
>>> steps are needed to change studio's build when we break out new
>>>
>>> bundles from inside shared-ldap.
>>>
>>> --
>>>
>>> [0] -- http://goo.gl/5WT5i
>>>
>>>
>>> Thanks,
>>>
>>> --
>>>
>>> Alex Karasulu
>>>
>>> My Blog :: http://www.jroller.com/akarasulu/
>>>
>>> Apache Directory Server :: http://directory.apache.org
>>>
>>> Apache MINA :: http://mina.apache.org
>>>
>>> To set up a meeting with me: http://tungle.me/AlexKarasulu
>>>
>>>
>>>
>>
>>
>>
>> -- 
>> Alex Karasulu
>> My Blog :: http://www.jroller.com/akarasulu/
>> Apache Directory Server :: http://directory.apache.org
>> Apache MINA :: http://mina.apache.org
>> To set up a meeting with me: http://tungle.me/AlexKarasulu
>

Mime
View raw message