Re: [architecture] Fractal packaging & deployment, bis

["Richard S. Hall" <heavy@xxxxxxxxxxxxxx>]

I won't claim to understand everything in the packaging document, but I 
will try to comment on what I do understand.

First, the choice of the word "package" is a significant source of 
confusion, perhaps something like "deployment unit" would be better.

I have to assume that the document is trying to be programming 
language/environment neutral, which probably leads to much of my 
confusion when reading it. Is the goal to create a generic packaging 
approach that can be implemented in any language, like the Fractal spec 
itself, or is the goal to define a packaging approach for Fractal on Java?

Speaking from a Java perspective, I see three layers (or pieces):

  1. A foundation layer for managing/deploying file-based "deployment
     units" based on packages,
  2. A second layer that maps the file-based deployment units into
     class loaders, and
  3. A third layer that maps these concepts into a target component model.

Layers 1 and 2 can perhaps be combined, but they should be component 
model agnostic; they should provide features that the third layer can 
use to embed meta-data, policies, and so on for any component model. In 
this approach, layers 1 and 2 are purely middleware.

Again, I admit that I don't really fully comprehend the packaging 
document, so perhaps my comments are off-base, but I think more thought 
has to be placed into the requirements of the lower level deployment layers.

Interestingly, I just attended my first OSGi meeting last week and this 
is precisely the issue that they are wrestling with now; they are 
wondering if it is possible to separate the deployment aspects from the 
life cycle and service aspects so that they might be usable 
independently. This is something I highly encouraged, especially since 
Oscar tries to follow this same goal to varying degrees of success.

I am not sure how much I am allowed to comment on these issues, but I 
think the idea of providing a generic deployment "module" layer for Java 
is an ultimate middleware goal, since Java lacks a viable alternative to 
something like assemblies and the GAC in .NET.

An excellent paper in this area is:

   http://pag.lcs.mit.edu/reading-group/corwin03mj.pdf

A guy from the group where the above above project was done in IBM is 
now participating in OSGi, which gives me great hope for their 
seriousness in creating such a module deployment layer for Java. I think 
this is the right approach.

Sorry if my comments are too Java-centric...

-> richard

Eric Bruneton wrote:

> to continue the "discussion" on this topic (in fact we got very little 
> feedback), here is a document that summarizes the result of a meeting 
> on this subject that took place last week, between INRIA and FTR&D. 
> Comments are more than welcome, they are needed!
>
> the DREAM and Fractal teams
>  
>
>