[Kolab-devel] Kolab libraries and dependencies
Christian Mollekopf
mollekopf at kolabsys.com
Mon Mar 12 21:57:02 CET 2012
On Monday 12 March 2012 11.38:48 Allen Winter wrote:
> On Monday 12 March 2012 11:28:39 AM Christian Mollekopf wrote:
> > Hey,
> >
> > I'm not quite sure about the dependencies of our libraries, and I'd like
> > to
> > get that solved rather soon as I don't like to work with multiple copies
> > of
> > the same codebase.
> >
> > I see the following components with the dependencies of each:
> >
> > - libkolabxml (not the repository but the library)
> >
> > - kcalcoreconversion (kolab to kcal core)
> >
> > - libkolabxml
> > - KCalCore
> >
> > - kolabV2 (Kontact kolabv2 implementation
> >
> > - KCalCore
> >
> > - KolabMime (based on KMime, embeds/extracts xml file in/from mime
> > message)
> >
> > - KMime
> >
> > - Migration-Utility
> >
> > - libkolabxml
> > - kolabV2
> > - KCalCore
> > - Kolab Mime
> >
> > - Kolab-Resource
> >
> > - libkolabxml
> > - kolabV2
> > - KCalCore
> > - Kolab Mime
> >
> > On the KDE side we have kdepimlibs where we currently have KMime and
> > KCalCore and kdepim-runtime where we have the Kolab-Resource and the
> > KolabV2 implementation. Since kdepim-runtime is not suitable as a
> > dependency I'd like to move the suitable parts to kdepimlibs. I have the
> > following in mind:>
> > - kdepimlibs in a new kolab directory:
> > - kolabV2
> > - kolabV3 (small wrapper using kcalcoreconversion and libkolabxml, does
> >
> > error propagation to KDE)
> >
> > - KolabMime
> > - kcalcoreconversion (KCalCore is also here)
> >
> > - kdepim-runtime:
> > - Kolab-Resource
> > - Migration-Utility
> >
> > - libkolabxml
> >
> > - libkolabxml (obviously =)
> >
> > This way we'd get the libkolabxml repository clean of KDE dependencies and
> > get at least some kind of structure (other than mutual dependencies).
> > The kdepimlibs blob sucks a bit though, and having to install
> > kdepim-runtime for the migration-utility is maybe also not ideal. Also I
> > have to check if kdepimlibs is suitable with it's binary compatibility
> > requirements. A kolab-kde repository containing the kdepimlibs parts and
> > the migration- utility would be another viable option IMO.
>
> Speaking with my KDEPIM Hat On:
>
> After discussing with Volker, we think it makes sense to keep kolab specific
> libraries separate from KDE.
>
Yes, you're right. There is indeed no point having those in kdepimlibs. I'll
take out the v2 format implementation from kdepim-runtime, make an optional
dependency on libkolabxml (or whatever kolab library will contain the
necessary code) and keep the migration utility also in the kolab repository as
we need it outside of kdepim as well. The resource will remain where it is of
course.
> But we are fine with having the resources and migration tools in
> kdepim-runtime. So the kdepim-runtime would look for optional, external
> kolab libraries and build the resource and migrator if such are found.
>
> This setup would allow the external kolab libs to follow protocol changes
> faster or on a different schedule than KDE SC.
>
> Does this make sense and work for you?
>
Yep, thanks for the push in the right direction.
Cheers,
Christian
> -Allen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20120312/1f4ab17f/attachment.sig>
More information about the devel
mailing list