Re: [architecture] Fractal packaging & deployment, bis

[Eric Bruneton <Eric.Bruneton@xxxxxxxxxxxxxxxxxxxx>]

Richard S. Hall wrote:
> I won't claim to understand everything in the packaging document,
> but I will try to comment on what I do understand.

thanks for your comments!

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

it is true that "packages", in this document, have nothing to do with 
Java packages. But "deployment unit" is a bit too long (I would 
prefer a single word). Any other idea? (since we identified the 
component and package concepts, a possibility is to always speak of 
components: "component" would then designate both runtime entities 
and serialized entities)

> I have to assume that the document is trying to be programming
> language/environment neutral, which probably leads to much of my

Indeed we would like to have deployment tools to deploy Fractal 
components as well as legacy "components" (such as debian packages). 
But this is a long term goal: we will first concentrate on tools for 
pure Fractal components.

> 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.

this seems a good approach to implement the packaging/deployment 
system. However, before implementing it, we must define the 
requirements for this system, what is a package, its relation to 
components... This is what we tried to do in section 1 and 2.

> 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.

in a top down approach, we started to look at something similar to 
your third layer in section 3. We have not yet looked at lower 
layers, but we will need to do this.

> 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.

you are totally allowed to comment on these issues (we need your 
experience on them)!

Eric