directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot ...@marcelot.net>
Subject Re: [OSGi] Shared bundles update
Date Tue, 18 Jan 2011 09:33:42 GMT
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.

> 
>> - 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.

>> 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