////
   Licensed to the Apache Software Foundation (ASF) under one
   or more contributor license agreements.  See the NOTICE file
   distributed with this work for additional information
   regarding copyright ownership.  The ASF licenses this file
   to you under the Apache License, Version 2.0 (the
   "License"); you may not use this file except in compliance
   with the License.  You may obtain a copy of the License at

     https://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing,
   software distributed under the License is distributed on an
   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
   KIND, either express or implied.  See the License for the
   specific language governing permissions and limitations
   under the License.
////

= Apache Felix Sigil

Another initiative to manage OSGi(TM) dependencies is the project link:https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Sigil[Apache Felix Sigil(TM)]. Sigil can also be used together with Ivy. We will try to explain here the different approach taken there compared to the built-in OSGi capabilities of Ivy.


== A different approach


Apache Felix Sigil is at its core about managing OSGi dependencies, not directly related to Ivy. Most of its core feature is about the implementation of the not yet released OBR (OSGi Bundle Repository) specification. It then provides integration layers with several tools so that developers can use the OBR API. It provides an Eclipse plugin and there are the Ant/Ivy tasks and resolvers.

On the other hand the built-in OSGi capabilities in Ivy are targeted towards users already familiar with Ivy and link:https://ant.apache.org/ivy/links.html[tools around it] like link:https://ant.apache.org/ivy/ivyde[Apache IvyDE(TM)]. So with a minimum amount of effort, they can get OSGi dependency management.


== Resulting differences


=== Resolve


The built-in OSGi resolver is __obviously__ using the Ivy engine to do the resolution of the dependencies. The OSGi capability of Ivy is mainly implemented with a module descriptor parser which understands the OSGi metadata of a `MANIFEST.MF`.

On the other hand, Sigil is using a separate "engine" to do the resolution, the OBR, an engine which is dedicated to understand the OSGi metadata and their semantics.

The immediate consequence of this difference is that the built-in resolver is probably less accurate than the Sigil one when it comes to understanding the OSGi dependencies semantics. As explained in this link:osgi-mapping{outfilesuffix}[page], the OSGi model doesn't fit well into the Ivy one.


=== Source of metadata


Apache Felix Sigil has its own format for specifying the OSGi dependencies. Whereas Ivy requires an `ivysettings.xml` and an `ivy.xml`, Sigil requires a `sigil-repos.properties` and a `sigil.properties`. Then if you want to use the Sigil resolver in Ivy, you will need 4 files, the 2 Ivy ones and the 2 Sigil ones, as described in the Sigil quickstart link:https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Sigil+Ivy+Quickstart[here].

To support OSGi directly in Ivy, you just need to add an extra namespace in the `ivy.xml`, and in the `ivysettings.xml` just declare the proper resolver and latest revision strategy.