Jason van Zyl wrote:

On Fri, 2003-11-07 at 15:38, Stephen McConnell wrote:

Jason van Zyl wrote:

On Fri, 2003-11-07 at 11:48, Stephen McConnell wrote:

Adam R. B. Jack wrote:

Three comments (probably all repetitions) :

1) Perl/Python have a package index/identification approaches. We might want
a similar concept, i.e. queriable metadata that associates keywords/concepts
with packages/groups/artefacts. These concepts could be language sensitive
(so either different, or extended). These concepts/approaches could be
argued as complimentary/orthogonal to repository, i.e. not in scope.

2) I am already overwhelmed by this information produced just around the
discussion of the URL (location) of files, and the differences in needs for
Java and/or others. We've not even started on the meat of the issues with
this venture. My gut tells me that having a repo effort, with per language
sub-efforts is the only way to achieve success & not a
one-size-doesn't-fit-all-kludge. [I could be wrong, but I point to 1 above
for this.]

3) Maybe we just phase things, and be happy with that. Maybe phase one is
the Maven-like/Avalon-like repository on an HTTP server w/ minimal metadata.
However hard we discuss the issues I doubt we'll get the "real world"
experience maintaining a repository (with mirrors, and such) unless we roll
up our sleeves and manage one on Apache hardware w/ partner mirrors. I think
prototyping and phasing are keys here.

I tend to agree.

Based on the experience gained in the Avalon repository work there are a
number of distinct viewpoints: structural, relational, organizational/legal, and application.

The structural viewpoint deals with naming conventions (group, type, artefact, version) and the associated access machinery - getting, putting, navigation.

* The relational viewpoint concerns information about artefacts such as
dependencies - and here we start see language specifics. For example a jar file with structural dependencies. This leads to the necessity to include a artefact descriptors. One example is the Maven POM - but its not good example at this level of abstract because its a descriptor of build and test time dependencies (amongst other things).

The POM is not an artifact descriptor at all. The work done by Michal is
more akin to what you speak of where types of artifacts themselves are
described and controlled by handlers associated with the type.

My impression is that this is specific to the Maven POM model - which is for all intensive purposes meta-data for the purpose of artifact generation.

The counter example to that is how plugins currently work. It is seen as a plugin type, prepared and installed. Very simple process, but extrapolate and you have component deployment.

In principal I agree - but I think you and both know that we are talking about heavyweight :-)

When you are looking at runtime service deployment model there are bunch of things that the POM does not address (which is to be expected as the POM is not addressing service management).

No, the POM doesn't at all address components, services or particular
component models.

But it does address overlapping concerns such as organization and in part - legal. In addition if you were to create an abstract meta model you would end up with an artifact descriptor together with the notion of a dependency. Now I know you don't look at a POM as an artifact descriptor - but is describe the artifact name, its group, references the owning organization, the artifact units of composition, and aspects of the creation process. What is interesting is the abstract view - an artifact and its relationship to other artifacts. Under the abstract view you not concerned with the process directly, your concerned with the description of a relational model with sufficient abstract that can be used to build the artifact, to deploy the artifiact, to validate or test the artifact, etc.

However, if we look at repository enabled applications in general, covering applications such as Maven with a focus on development process together with applications such as the avalon-repository with its focus on runtime service deployment, you draw from these common information model requirements and potential common services that map into a shared abstraction. It's that common abstraction which is a subject I'm interested in.

To me this discussion is focused on an artifact repository. Not that
component deployment isn't important (I'm doing it myself) but you can
build whatever information you require from the artifacts you put into
the repository that are made to work with your system. In your case

Just for reference - the avalon-repository iniative is designed to be container independent. Merlin just happens to be a hell of a good example of a repository aware application.

There is absolutely nothing stopping you, with the structure of the
current Maven repository, from keeping a directory of available
components for use with, say, Merlin or Plexus. I believe the discussion
of dynamic component deployment is beyond the scope of the discussion
here. I'm definitely interested but I don't think it's a notion that
should be baked into the notion of the repository.

I believe the discussion of dynamic component deployment is totally relevant as a use case. I agree completely that it is out of scope in terms of tools and technologies evolving from this process - howwever, just as Maven is a valid use case - the subject of component deployment does introduce requirements that are not met by the basic maven model.

I currently keep a primitive list of components that can be used with
Plexus and users can select them. Anything that I've needed I have been
able to add to the repository simply as another artifact type. So in our
case it may be a component descriptor which you may want to process in
whatever way is necessary to make it work with your component model and
component deployment model.

Sure - an this is what we do today. We describe deployment scenarios and publish these as your describe above. What is interesting is that there is a significant overlaps between between development process and the deployment process. Take the subset of common concerns and you will find an overlap with other Java langage inatives. Consider multiple languages and I am confident you will find further overlaps.

What specific problems have you run into? I haven't run into any yet

* duplication - similar code doing the same thing - for example, the subject of artificate publication and retival - sharing a common code base is something that benefits everyone and will ultimately lead to strong more secure "repository aware" applications
* consistency in approach - it makes sense for Apache projects to collaborate when dealing with common abstractions - as as you pointed out, Maven plugin management is an area that can leverage a great deal from the work in Avalon - just as Avalon can leverage a great deal from Maven - just as a repository iniative can leverage a great deal from the common set of requires the Maven, Avalon and other Java projects represent in terms of the Java language abstraction.
* extensibility - being able to deal with repository meta-info (e.g. depednecies, artificats, etc.) in a way that is more abstract than Maven or Avalon is a massive plus - think MDA, etc. - it basically set the environment for a much greater audience and overall value. The extensibility question is directly linked to the underlying repository protocol and repository meta information.

This idea has been thoroughly discussed in Maven-land.

Based on the [EMAIL PROTECTED] (which I've been following closely since Febraury) the discussions are properly grounded on the development process abstraction.

Most definitely.

I think we are talking about something more generic both in terms of meta information and services. However, if we dig down, there are clealy common facilities. In fact this (common facilities) is where a lot of value can be gained.

This should not be baked into the repository simply because there are so
many ways to define what the meta information is and you will never get
a consensus on what that should be and it simply isn't needed. Not for
the repository itself.

I completely agree - and I'm sure you would agree that a repository model should provide the appropriate services that needed not only for Maven - but also for the sort of things being addressed in Avalon. Consider for a moment the subjects of repository utilization in an IDE - here we want the ability to select repositories, manafe and manipulate repository content, navigate repsoitories, and deliver interactive composition of compoents (we already have programatic compoention by interactive composition really pushed up the set of requirements on the underlying repository).

For any use case you can provide I think I could suggest a way to
utilize what exists right now.

Yep - but I would not call it optimal. I think the Maven repository model is close -add some more semantics on group, a formal definition of the repository structure via a meta model, the ability to artifact descriptions and relational descriptors - and we would be looking at something really valuable.

What this basically comes down to is probably something like:

         Maven                        Avalon
 (development process focus)   (service deployment focus)
           |                             |
           |                             |
                 Java Langauge Focus
                      Repository Aware Application Focus

Service deploy, and Repository Aware applications are outside the scope
of the repository.

Service deployment is relavant as a use case. Repository aware application are in my opinion the driving requirement.

You can build whatever information stores you want
and deploy them to the repository for use. I am ardently opposed to
baking any of these specific notions into the repository structure

Me to.

I'm also ardently in favour of a repository that meets or exceed the requirements introduced by these applications areas.

Building or composing?

Simply building, I compose using component descriptors of my own

Consider interactive and programtatic discovery based composition of systems and will will quickly come to the conclusion that a generic repository solution is a killer aplication - and that what we have today is not sufficient. This is the reason I'm subscribed to this list. There are huge benefits in getting this right - benefits for Avalon, Maven, Jakarta, Cocoon, James, etc., etc.

Michal has been working on Wagon

Do you know if Michal is subscribed to this list?

Not sure if he is yet, but I've asked him to.

Great - I'm rather keen to discuss what he has been up to and how it could be applied to the more generic repository aware solution space.

Can you give me a URL to the Wagon iniative?

Not yet, but I will be able to soon. The Maven PMC members are discussing the finer details now.

<question> Why don't you guys discuss this sort of stuff on [EMAIL PROTECTED] I.e. in public. </question>



Stephen J. McConnell

Reply via email to