Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (athena.apache.org: domain of gnodet@gmail.com designates
 64.233.182.188 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=YKOoVmHCN30uDOpS1X5dUumwFUGg69+YrT9jaugrWSWnEpBNLCpXXwpUu99jVlIqJY
         gEgwB4wwTZ9SrPmTEgdzfRzhD4aPxKfPGOa4NnrWwTccfydEAP0lupvlo2aUkz88CnkR
         muh75ZSQC6xpx+5JMl44m2P6hs4y71hP9vUZ4=
Message-ID: <b23ecedc0810271350o32d082a8l7fea2b67d440bcd1@mail.gmail.com>
Date: Mon, 27 Oct 2008 21:50:40 +0100
From: "Guillaume Nodet" <gnodet@gmail.com>
To: "Apache Directory Developers List" <dev@directory.apache.org>
Subject: Re: OSGi Packaging for ApacheDS
In-Reply-To: <43b026c70810271315v58828baakd6059640d59951a2@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <43b026c70810271315v58828baakd6059640d59951a2@mail.gmail.com>

The other alternative may be to create a single bundle which contains
all the apacheds classes without the third party dependencies.
CXF hit the same problem and they have included this big bundle into
their build process so that users can still deploy it in OSGi.  Such a
jar can also be used when embedding ApacheDS and can be used by
non-OSGi users too as it avoids dealing with all the small jars.
I guess, in the short term, this may be the easiest way, pending a
reorganization of the packages.
My 2 cents.

On Mon, Oct 27, 2008 at 9:15 PM, Chris Custine <ccustine@apache.org> wrote:
> Hi Guys,
> As an interim step to eventually deploying inside an OSGi container, I have
> started working out packaging the jar files as OSGi bundles just to see how
> much work it will be.  The idea is that in the short term nothing should
> affect ongoing development because the bundle packaging is just some
> modifications to the module pom.xml files which add the OSGi headers to the
> MANIFEST.MF files at build time.
>
> In doing this I have realized that there are quite a few cases of split
> packages where two (sometimes three or more) projects have classes in the
> same package.  This is important for the OSGi packaging because package
> names are the primary descriptor for importing and exporting code from
> bundles and if more than one bundle exports from the same package there is
> quite a bit more work to maintaining the packaging configuration (in this
> case, a plugin config in the pom.xml).  One big example is the
> org.apache.directory.server.core.partition.* packages which are contained in
> multiple partition implementations as well as apacheds-core.
>
> So my first question is if this is something that we want to discuss and
> start taking care of now?  There are several solutions obviously, and it is
> quite possible that we can work around this with hand crafted packaging
> descriptors for the OSGi bundles.  This is a bit of work however and long
> term maintenance of the packaging will be much higher.  Other options
> include re-organizing packages to have more unique structure (my personal
> preference), or we could also combine some of the scattered code into
> consolidated jar files.
>
> Any input or alternative ideas?
>
> Thanks,
> Chris
>
> --
> Chris Custine
> My Blog :: http://blog.organicelement.com
> Apache ServiceMix :: http://servicemix.apache.org
> Apache Directory Server :: http://directory.apache.org
>


-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com