Blog de Justo Aguilar

Continuando con la saga del famoso personaje Robert Langdon, el autor nos vuelve a llevar hacia los misterios que rodean el mundo de la francmasonería. Esta vez, con Washingthon D.C. como escenario de la trama y que según el señor Langdon fue proyectada por los masones más importantes de la época.

Sinopsis oficial:

¿Existe un secreto tan poderoso que, de salir a la luz, sea capaz de cambiar el mundo?
Washington. El experto en simbología Robert Langdon es convocado inesperadamente por Peter Solomon, masón, filántropo y su antiguo mentor, para dar una conferencia en el Capitolio. Pero el secuestro de Peter y el hallazgo de una mano tatuada con cinco enigmáticos símbolos cambian drásticamente el curso de los acontecimientos. Atrapado entre las exigencias de una mente perturbada y la investigación oficial, Langdon se ve inmerso en un mundo clandestino de secretos masónicos, historia oculta y escenarios nunca antes vistos, que parecen arrastrarlo hacia una sencilla pero inconcebible verdad.

Lo mejor del libro, para mí, es el ritmo que tiene, vertiginoso, aunque he de reconocer que las últimas páginas son un poco pesaditas, todo sea dicho. El resto, bueno, entretenido. Muchas curiosidades sobre simbología, en la línea de El Código DaVinci. Muchas curiosidades sobre los masones. Muy en la línea del autor.

Si te gusta el estilo de Dan Brown, quitando La Fortaleza Digital que es un bodrio, éste te va a gustar también. Para mí, siguen siendo mejores El Código DaVincia y La Conspiración, aunque para gustos los colores.

Sinopsis oficial:

Los quince grandes episodios de la historia de España. Una forma apasionante de ver, y de comprender, lo que nos une y nos conforma.

La presente obra se enfrenta a quince instantes que cambiaron la historia de nuestro país: desde la expulsión de los judíos o la guerra de las Comunidades a la Constitución de 1978, pasando por la sucesión de Carlos II, la Guerra de la Independencia o la proclamación de la Segunda República. Días o semanas que cambiaron a España y la llevaron por nuevas sendas. Con una prosa espléndida y una portentosa capacidad narrativa, José Calvo Poyato rescata de la continuidad de la historia aquellos momentos que brillan con particular relieve y que nos ha constituído tal como somos.
Lo principal de la historia de España en un solo libro, muy accesible con una combinación perfecta de información y amenidad orientado a un público muy amplio, que quiere saber lo esencial sobre los grandes momentos de su historia.

Un libro que me encontré por casa, y como no, me lo tuve que leer. Y qué suerte tuve al encontrarlo porque ha resultado ser uno de los mejores textos introductorios a los últimos 500 años de la historia de España. Un libro ameno, directo, casi esquemático, con los hechos más relevantes de cada periodo. Un libro para releer.

Sin duda lo necesitan.

Fuente : ElPais.com

Introducción a la teoría de juegos y retazos de la vida su mayor exponente, John von Neumann.

Sinopsis oficial :

Los dilemas de la vida real surgen gracias a las diversas maneras con las que nuestros intereses individuales se contraponen a los de los demás y a los de la sociedad en general. Diariamente, hemos de tomar decisiones difíciles, a veces con resultados distintos de los que habíamos esperado. Se plantea entonces la siguiente cuestión, simple y a la vez apremiante: ¿existe un comportamiento racional para cada situación? En EL DILEMA DEL PRISIONERO se analiza este tipo de cuestiones a la luz de la moderna teoría matemática de juegos. WILLIAM POUNDSTONE introduce en este libro los aspectos fundamentales de tan importante teoría a través del análisis de casos concretos, en su mayoría de evidente relevancia sociológica (por ejemplo, estudia desde este punto de vista el dilema de la carrera nuclear EE.UU.-URSS durante la Guerra Fría). Asimismo, a lo largo de la obra se intercalan importantes facetas de la biografía personal y de la teoría de juegos, el genial matemático John von Neumann.

El dilema del prisionero se reduce, al final, a escoger la opción que beneficia al bien común (cooperar) o escoger la opción que sólo beneficia a uno mismo (desertar), colaboración frente a egoísmo. Si se sigue la premisa de la teoría de juegos que dice que todo jugador es racional, la elección para un jugador racional es desertar, siendo ésta un punto de equilibrio, aunque en realidad la más beneficiosa para ambos es cooperar, de ahí el dilema. Veamoslo de forma más detallada.

Supongamos que tenemos la siguiente tabla :

• C1 y C2 = J1 2 puntos, J2 2 puntos
• C1 y D1 = J1 0 puntos, J2 3 puntos
• D1 y C2 = J1 3 puntos, J2 0 puntos
• D1 y D2 = J1 1 punto, J2 1 punto

¿Qué estrategia seguir?
Tenemos que tener en cuenta que ningún jugador sabe que estrategia va a escoger el otro, y no hay ninguna forma de que puedan comunicarse para establecer una estrategia común que favorezca a los dos. ¿Qué hacemos entonces?.

• J1 coopera
  J2 puede cooperar o desertar.
  • J2 coopera, ambos obtienen 2 puntos, que es el mejor resultado común.
  • J2 deserta, J1 se queda sin puntos (hace el primo, según el libro), el peor resultado individual y J2 se lleva 3 puntos, el mejor resultado invidual.

  Por tanto si cooperamos, nos puede ir bien (2 puntos, si J2 coopera), pero nos puede ir muy mal (0 puntos, si J2 deserta).

• J1 deserta
  J2 puede cooperar o desertar.
  • J2 coopera, J1 obtiene 3 puntos, el mejor resultado individual y J2 hace el primo, 0 puntos.
  • J2 deserta, ambos se llevan 1 punto, el peor resultado común pero es un punto de equilibrio, ninguno se arrepiente de haber escogido esa opción.

  Por tanto, si desertamos, nos puede ir muy bien (3 puntos, si J2 coopera) o simplemente regular (1 punto, si J2 también deserta)

Posiblemente la carrera por la bomba atómica y la bomba de hidrógeno, entre EEUU y la URSS, fue uno de los hechos más apróximados al dilema del prisionero. La opción de cooperar significaba abandonar la construcción de la bomba. Desertar significaba intentar construirla antes que el adversario.

Vista la devastación producida sobre Japón, y conociendo que la bomba de Hidrógeno tenía un poder destructor mucho mayor, ambas potencias eran conscientes de que podían llegar a construir un arma capaz de destruir el planeta (y por tanto darle la posibilidad a alguien de usarla); por tanto, lo más beneficioso para ambas y para el resto de la humanidad era colaborar y abandonar la construcción de armas nucleares. Sin embargo, cabía la duda de que, tanto EEUU como la URSS, continuaran en secreto con la construcción de las bombas, por tanto, lo mejor para el beneficio propio era desertar y construir una bomba más potente que la del enemigo, por si acaso. Ninguna de las dos quería hacer el primo, ni ser sometida. Y así fue, ambas potencias comenzaron una carrera por construir más y mejores bombas que su rival hasta nuestros días, donde se sigue hablando del desarme nuclear, pero ahora Irán y Corea del Norte han sustituido a la antigua URSS mientras que EEUU permanece como guardian del planeta.

Por cierto, von Neumann era un ferviente partidario de lanzar un ataque preventivo contra la URSS.

En definitiva, un libro entretenido que nos introduce en la historia de la teoría de juegos y sus aplicaciones en la vida real. Recomendable, sólo, por la cantidad de curiosidades y juegos que contiene, si además te gusta el tema, seguro que lo disfrutas más es profundidad. Por cierto, no es un libro técnico, no esperéis encontrar desarrollos matemáticos en él.

• http://www.20minutos.es/noticia/581502/0/sube/precio/metrobus/
• http://www.elmundo.es/elmundo/2009/12/04/madrid/1259933260.html
• http://www.elpais.com/articulo/espana/bono/viajes/costara/euros/elpepuespmad/20091204elpepunac_20/Tes
• http://www.eleconomista.es/economia/noticias/1749289/12/09/La-Comunidad-de-Madrid-sube-un-216-el-precio-del-metrobus-hasta-9-euros.html

Ante la inclusión en el Anteproyecto de Ley de Economía sostenible de modificaciones legislativas que afectan al libre ejercicio de las libertades de expresión, información y el derecho de acceso a la cultura a través de Internet, los periodistas, bloggers, usuarios, profesionales y creadores de internet manifestamos nuestra firme oposición al proyecto, y declaramos que…

1. Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.
2. La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial -un organismo dependiente del ministerio de Cultura-, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.
3. La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.
4. La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.
5. Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.
6. Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.
7. Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.
8. Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.
9. Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.
10. En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.

Este manifiesto es obra de muchas manos, y propiedad de todos. Si te gusta, cópialo, pásalo, publícalo en tu weblog o haz lo que quieras con él.

Tanto este libro como El mundo de Sofia, se los he cogido prestados a mi hermana. Ella me dijo que este último, que ahora paso reseñar, no era tan bueno como el de El mundo de Sofía, sin embargo yo creo que no pueden ser comparables porque tratan temas distintos. Mientra El mundo de Sofía realiza un viaje sobre el pensamiento humano a lo largo de la historia, La joven de las naranjas se centra en la afortunada y efímera vida del ser humano.

Sinópsis oficial :

«Mi padre murió hace once años, cuando yo sólo tenía cuatro. Creí que no volvería a saber nada de él, pero ahora estamos escribiendo un libro juntos…» Así comienza La joven de las naranjas que hace reflexionar al lector sobre la intensidad de la Vida, pero también sobre la muerte. Una historia que nos habla del Tiempo y sobre qué somos realmente, qué misterio compartimos con el universo. ¿Elegiríamos nacer, y conocer la vida en toda su intensidad, sabiendo que quizá sea para permanecer sólo un instante en ella? ¿O rechazaríamos la oferta? Georg, un joven de 15 años apasionado por la astronomía, encuentra una antigua carta que su padre escribió para él al saber que iba a morir. En ella le cuenta el gran amor que sintió por la misteriosa Joven de las Naranjas para finalmente formularle una importante pregunta, a la que Georg debe responder. Antes de contestar, Georg habrá escrito un libro con su padre, un libro que va más allá del tiempo y de los límites de la muerte.

Resulta muy enriquecedor, a nivel personal, el pensar sobre algunas de las cuestiones que se plantean en este libro. Realmente ayudan a conocerse a uno mismo, ayudan a definir tu camino en la vida y el legado que quieres dejar cuando ya no estés aquí.

Este libro quiere hacerte saber que, el que estés aquí leyendo ésto ahora debe hacerte reflexionar sobre la gran suerte que tienes de participar temporalmente en la historia de este mundo. Siéntete afortunado y aprovecha cualquier oportunidad para disfrutar del breve momento que el azar nos ha concedido dentro de este cuento que comenzó hace 15.000 millones de años.

A continuación os incluyo un video de lo próximo que leeré, un par de libros de Carl Sagan.

El mundo de Sofía es una gran introducción a la historia de la filosofía, a la historia del pensamiento humano más fundamental. Un paseo en el tiempo para conocer a los pensadores más influyentes de la época y todo visto a través de los ojos de una joven de 14 años.

Esta extraordinaria obra de divulgación que se ha convertido ya en una obra de culto aporta una coherente visión de conjunto sobre aquellos aspectos imprescindibles para comprender la historia de la filosofía occidental. El mundo de Sofía tiene el mérito de haber conjugado, acertadamente, rigor y amenidad en una narración donde una joven irá conociendo su propia identidad mientras descubre la capacidad humana de hacer preguntas.

«Si no sabemos en todo momento a dónde vamos, puede resultar útil saber de dónde venimos. Para manejar mi propia vida también necesito entender mis raíces en la historia. La misión de la filosofía es estimular el análisis crítico para poder ayudar en el avance de la comprensión de aquello que tiene valor y por lo cual merece la pena luchar.»

Jostein Gaarder

Sin duda un libro muy, muy recomendable para releer de vez en cuando y tener una referencia rápida de la evolución del pensamiento a lo largo de la historia. Ahora estoy leyendo otra obra de Gaarder, La joven de las naranjas, a ver que tal.

Una parte fundamental dentro de la especificación OSGi es el conjunto de metadatos que deben ser situados en el fichero MANIFEST.MF y que permitirán a la implementanción OSGi instalar el bundle dentro del entorno de ejecución, resolver sus dependencias y publicar todo aquello que queramos sea visto por otros bundles.

Me voy a basar en el documento que define la especificación OSGi 4.1 para listar todas las cabeceras disponibles actualmente, su finalidad y sus características.

La lista de cabeceras, por orden alfabético, es la siguiente:

• Bundle-ActivationPolicy
• Bundle-Activator
• Bundle-Category
• Bundle-Classpath
• Bundle-ContactAddress
• Bundle-Copyright
• Bundle-Description
• Bundle-DocURL
• Bundle-Localization
• Bundle-ManifestVersion
• Bundle-Name
• Bundle-NativeCode
• Bundle-RequiredExecutionEnvironment
• Bundle-SymbolicName
• Bundle-UpdateLocation
• Bundle-Vendor
• Bundle-Version
• DynamicImport-Package
• Export-Package
• Export-Service
• Fragment-Host
• Import-Package
• Import-Service
• Require-Bundle

Bundle-ActivationPolicy
Especifica como el framework debe activar el bundle. Si debe hacerlo de forma normal cuando arranca el framework o de forma perezosa, no se activará hasta que no sea cargada una clase.
Valores permitidos : lazy
Valor por defecto : ninguno. Si no se incluye esta cabecera se activará el bundle al arranque del framework.
Ejemplo

Bundle-ActivationPolicy : lazy

Bundle-Activator
Nombre de la clase usada para arrancar y parar el bundle. La clase debe implementar la interfaz BundleActivator.
Ejemplo

Bundle-Activator : es.jmac.osgi.infrastructure.Activator

Bundle-Category
Lista de nombres de categoría, separadas por comas.
Valores permitidos : libre, valores separados por comas. OSGi recomienda utilizar los valores de una lista predefinida.
Valor por defecto : ninguno. Si no se incluye esta cabecera se activará el bundleal arranque del framework.
Ejemplo

Bundle-Category : example, device, testing

Bundle-Classpath
Define un lista, separada por comas, de rutas de ficheros JAR y directorios (dentro del bundle) con las clases y recursos del bundle. El “.” especifica el directorio raiz del JAR del bundle.
Valor por defecto : .
Ejemplo

Bundle-Classpath : lib/commons-logging-1.1.1.jar, . , resources/html

Bundle-ContactAddress
Dirección de contacto del proveedor.

Bundle-Copyright
Especificación de copyright y licencia para el bundle.

Bundle-Description
Descripción corta del bundle.

Bundle-DocURL
URL con la documentación del bundle.

Bundle-Localization
Esta cabecera debe contener el fichero base dentro del bundleque defines las información multi-idioma.
Valor por defecto : OSGI-INF/l10n/bundle
Esta ruta la resuelve el framework como OSGI-INF/l10n/bundle.properties, por tanto cada fichero de idioma debe tener el siguiente nombre : bundle_es.properties, bundle_de.propertie
Ejemplo

Bundle-Localization : resources/labels

Bundle-ManifestVersion
Define que versión de la especificación OSGi debe seguir el bundle.
La versión 1 del Manifest es para la release 3.
La versión 2 es para la release 4, la actual.
Valor por defecto : 1
Ejemplo

Bundle-ManifestVersion : 2

Bundle-Name
Nombre corto para el bundle. Puede contener espacios.
Ejemplo

Bundle-Name : Pruebas OSGi

Bundle-NativeCode
Esta cabecera contiene una especificación de las librerías de código nativo contenidas en el bundle.
Ejemplo

Bundle-NativeCode : /lib/http.DLL; osname = QNX; osversion = 3.1

Bundle-RequiredExecutionEnvironment
Contiene una lista, separada por comas, de los entornos de ejecución que deben estar presentes en la Plataforma de Servicio.
Ejemplo

Bundle-RequiredExecutionEnvironment : CDC-1.0/Foundation-1.0

Bundle-SymbolicName
Especifica un nombre único, dentro de la VM, para el bundle. El nombre debería seguir la convención de dominio inverso. Esta cabecera es obligatoria.
Ejemplo

Bundle-SymbolicName : es.jmac.osgi.infrastructure

Bundle-UpdateLocation
Especifica la URL a partir de la cual se recuperarán las actualizaciones para el bundle. Si el bundle es actualizado, esta ruta debería ser usada si está presente, para recuperar el fichero JAR actualizado.
Ejemplo

Bundle-UpdateLocation : https://justoaguilar.com/repo/osgi

Bundle-Vendor
Descripción del proveedor del bundle.
Ejemplo

Bundle-Vendor : Justo Aguilar

Bundle-Version
Especifica la versión del bundle. La versión debe seguir obligatoriamente el formato :

version ::=
major( '.' minor ( '.' micro ( '.' qualifier )? )? )?
major ::= number // See 1.3.2
minor ::= number
micro ::= number
qualifier ::= ( alphanum | ’_’ | '-' )+

Valor por defecto : 0.0.0
Ejemplo

Bundle-Version : 1.0.1.Built20090801-143221

DynamicImport-Package
Esta cabecera contiene una lista, separada por comas, de nombres de paquetes que deberían ser dinámicamente importados cuando se necesiten.
Ejemplo

DynamicImport-Package : es.jmac.osgi.*

Export-Package
Contiene la declaración de los paquetes a exportar.
Ejemplo

Export-Package : !es.jmac.osgi.infrastructure, es.jmac.osgi

Export-Service
Obsoleto. (Deprecated)

Fragment-Host
Define el bundle maestro para este fragmento.
Ejemplo

Fragment-Host : es.jmac.osgi.infrastructure;version="[1.0.0,2.0.0)"

Import-Package
Especifica los paquetes a importar por este bundle.
Ejemplo

Export-Package : !es.jmac.osgi.infrastructure, es.jmac.osgi

Import-Service
Obsoleto. (Deprecated)

Require-Bundle
Especifica la lista de bundles (paquetes) obligatorios a utilizar en este bundle.
Ejemplo

Require-Bundle : org.apache.commons.logging;version="1.1.1",org.springframework.context;version="(2.0.0,3.0.0)"

Pues sí, otro acrónimo más en el mundo Java, no sé por qué te extrañas. Y como ha pasado con muchos otros de su época, véase SOAP, el acrónimo ha pasado a ser el nombre oficial, nombre que en sus orígenes era Open Services Gateway initiative. Bueno, vamos al turrón.

Un módulo es un componente autocontenido dentro de un sistema mayor. ¿Autocontenido?, sí, que no necesita de referencias externas para su existencia y funcionamiento.

Bien, detrás de esta definición de módulo tan abstracta se esconden dos de los principios fundamentales de la programación : Alta Cohesión y Bajo Acoplamiento.

Todo módulo debe tener una responsabilidad y funcionalidad perfectamente delimitada dentro de un sistema mayor en el que se encuentre integrado (alta cohesión). Y debe evitar cualquier dependencia con el resto de módulos para realizar la tarea que tiene asignada (bajo acoplamiento). Evidentemente, siempre existirá un determinado grado de acoplamiento, que debe estar, en la medida de lo posible, articulado mediante conceptos abstractos, lo que en Java vienen a ser las interfaces.

Se podría decir que dentro de la plataforma Java la analogía de módulo sería un fichero JAR. Sin embargo, si conocemos el proceso mediante el cual es cargado un fichero jar en la JVM, podemos advertir una serie de carencias que invitan a pensar que la modularización en Java es una mera ilusión.

Actualmente, por defecto, una JVM tiene un único class loader (system class loader que es cargado por el bootstrap class loader escrito en código nativo) responsable de cargar en la JVM cualquier clase que se encuentre dentro del classpath de ejecución de una aplicación Java. Cuando existe un fichero jar en el classpath, se carga cada una de las clases que contenga ese JAR. Todo se carga en un espacio común, ahí, al montón.

Seguramente alguna vez habréis cargado el mismo jar dos o más veces, si es de la misma versión no pasa nada pero si usas distintas versiones puede que tengas un problema. Si tienes dependencias con diferentes versiones de un mismo JAR, que sepas que se cargará la clase del jar que aparezca primero en el classpath. Esto implica que no podamos usar diferentes versiones de una misma clase, al menos, con la aproximación que Java tiene por defecto, tendríamos que crear nuestro propio classloader para cargar una versión distinta de la misma clase.

[Extender este punto]

La Alianza OSGi empezó a definir allá por el año 1999 (diez añitos ya) una especificación que permitiera la construcción de aplicaciones modulares en Java.

La especificación OSGi propone una arquitectura montada sobre una JVM que permita la instalación, actualización y eliminación de módulos. Cada módulo podrá publicar las clases que serán visibles por otros módulos de la máquina virtual y podrá consumir cualquier clase que haya sido publicada por otros módulos de la VM. Entre los módulos cliente y proveedor existe un registro central, en el que los proveedores registran los servicios que desean hacer públicos al resto de módulos y los clientes solicitan los servicios que desean consumir. Evidentemente un módulo puede ser, a la vez, cliente y proveedor. Este paradigma es similar a la solución definida en SOA, por ello se dice que:

Dentro de la especificación OSGi, un módulo tiene el nombre de bundle. Un bundle OSGi es un fichero JAR con un conjunto de metadatos que especifican las características de bundle. Estos metadatos deben de incluidos dentro del fichero MANIFEST.MF, por tanto :

Un ejemplo de MANIFEST.MF adaptado para ser utilizado dentro de un entorno OSGi puede ser el siguiente :

Manifest-Version: 1.0
Export-Package: org.apache.commons.logging;version="1.1.1",org.apache.
 commons.logging.impl;version="1.1.1";uses:="javax.servlet,org.apache.
 avalon.framework.logger,org.apache.commons.logging,org.apache.log,org
 .apache.log4j"
Implementation-Title: Jakarta Commons Logging
Implementation-Version: 1.1.1
Bundle-Classpath: .
Built-By: dlg01
Specification-Vendor: Apache Software Foundation
Bundle-Name: Apache Commons Logging
Created-By: Apache Maven
X-Compile-Source-JDK: 1.2
Implementation-Vendor: Apache Software Foundation
Bundle-Vendor: SpringSource
Implementation-Vendor-Id: org.apache
Build-Jdk: 1.4.2_16
Bundle-Version: 1.1.1
Specification-Title: Jakarta Commons Logging
Bundle-ManifestVersion: 2
Import-Package: javax.servlet;version="[2.1.0, 3.0.0)";resolution:=opt
 ional,org.apache.avalon.framework.logger;version="[4.1.3, 4.1.3]";res
 olution:=optional,org.apache.log;version="[1.0.1, 1.0.1]";resolution:
 =optional,org.apache.log4j;version="[1.2.15, 2.0.0)";resolution:=opti
 onal
Bundle-SymbolicName: com.springsource.org.apache.commons.logging
Specification-Version: 1.0
Extension-Name: org.apache.commons.logging
Archiver-Version: Plexus Archiver
X-Compile-Target-JDK: 1.2

El código anterior correponde al fichero MANIFEST.MF contenido en el JAR de Apache Commons Logging 1.1.1 descargado del repositorio OSGi de SpringSource.

De todas las cabeceras (headers) que componen el fichero vamos a explicar las más significativas:

• Bundle-SymbolicName : Única cabecera obligatoria y que debe identificar unívocamente dentro de la VM al bundle.
• Bundle-Version: Versión del bundle. La dupla (Bundle-SymbolycName,BundleVersion) permite referenciar una versión de un bundle.
• Export-Package : Lista de paquetes que el bundle publica para que puedan ser consumidos por otros bundles dentro de la misma VM.
• Import-Package : Lista de paquetes que el bundle necesita consumir y que por tanto deben ser exportados por otros bundles.
• Bundle-Classpath : Lista de rutas donde se encuentran las clases del bundle

Como habréis notado, todas las referencias a paquetes van acompañadas de un rango de versiones, no es obligatorio pero si recomendable. Por ejemplo, este bundle consume, de manera opcional, el paquete javax.servlet desde la versión 2.1.0 en adelante y menor a la 3.0.0. Esto permite a un bundle importar paquetes de varias versiones de un bundle, lo que puede ser necesario en ocasiones cuando tengamos dependencias con sistemas antiguos y que tengan dependencias con versiones antiguas mientras que la parte nueva del desarrollo esté vinculada a las versiones más modernas.

Otra ventaja es la posibilidad publicar únicamente lo que quiero que sea público a otros bundles sin necesidad de utilizar modificadores de ámbito a nivel de código como private, protected o package.

Por último os dejo con la definición que Craig Walls hace en su libro, Modular Java.

OSGi is a component framework specification that brings modularity to
the Java platform. OSGi enables the creation of highly cohesive, loosely
coupled modules that can be composed into larger applications. What’s
more, each module can be individually developed, tested, deployed,
updated, and managed with minimal or no impact to the other modules.

Craig Walls,
Modular Java

Próximamente más.