packaging for Fractal

[Eric Bruneton <Eric.Bruneton@xxxxxxxxxxxxxxxxxxxx>]

Hi,

I would like to start a discussion on the Fractal mailing list about 
packaging for Fractal components. Indeed packaging is a first 
important step to develop configuration, deployment and 
administration tools for Fractal, but nothing has been done yet in 
this area for Fractal (AFAIK).

The first step is to gather requirements for the content of Fractal 
packages. Here are some ideas:

- a Fractal package is a kind of jar file (which could be named .car 
or .far) that contains classes, resources and meta information about 
one or more component(s)

- the meta information must include, in particular, the ADL files 
describing the components and their Fractal dependencies. Other 
possible meta information include "legacy" dependencies, i.e. 
dependencies on "legacy components" (native libraries, OS, ...)

- a versioning system is also required. This system could distinguish 
interface and implementation versions (multiple implementation 
versions per interface version are useful to capture "minor" 
implementation changes such as bug fixes). It must also be possible 
to define (in)compatibility relations between versions.

- other possible meta information include: author name, short 
description of the component, ...

- like Fractal components can be assembled into composite components, 
and so on recursively, it should be possible to aggregate several 
Fractal packages in a single package, and so on recursively (this is 
convenient to distribute complete Fractal applications,  made of many 
small components, as single self contained Fractal packages)

there are also requirements about Fractal packages "installation" and 
"instantiation". For instance, it could be useful to have several 
versions of a component installed simultaneously on a given system, 
or even to have several versions of a component instantiated 
simultaneously in the same JVM (which could differ at the interface 
and/or implementation level).

In addition to the requirements, several questions must also be 
resolved in order to precisely define the packaging system:

- where is the meta information in a Fractal package? Should we put 
everything in the ADL files, with new ADL modules?

- is it necessary to explicitly define what a package "exports" and 
what it "imports" (cf OSGi)? or could this be deduced automatically 
(with a transitive closure operation) from the provided and required 
interfaces of the component, as declared in the ADL files?

- how must be defined the compatibility relations between versions, 
especially if interface and implementation versions are 
distinguished? Dependency relations from an itf version to another 
itf version is ok, likewise for an impl version to an itf version, 
but itf to impl and impl to impl relations should probably be 
avoided.

- a Fractal package must include the interfaces provided by the 
components, as well as the classes that implement them, but should it 
also include the interfaces required by these components?

- normal or inheritance references betwen ADL files may also introduce 
problems or new kind of dependency relations between Fractal 
packages. Do we need separate version numbers for the ADL files, in 
addition to the version numbers for interfaces and classes?


Another important question is the relation with existing packaging 
systems. Indeed, since we will never have a situation where 
everything is Fractal based, we (at France Telecom) would like to 
have deployment tools (made of Fractal components) that could deploy 
not only Fractal components, but also "legacy" components (Debian or 
Redhat packages, raw data, script or configuration files, EJB 
components...) [this is a long term goal].

The question is then: should we define a generic packaging system that 
could work with Fractal components, but that could also "encapsulate" 
other packages such as Debian or Redhat packages, OSGi bundles, ...? 
is it even possible? or should we handle the problem at the tools 
level, i.e. develop tools that can work with various packaging 
systems?

---

Any feedback is welcome, especially from user needs, and from people 
who know very well existing packaging systems such as Debian, Redhat, 
OSGi, EJB and CCM (in order to keep the good ideas and to try to 
solve the drawbacks of these systems)

Eric