On Fri, 2003-11-07 at 22:10, Stephen McConnell wrote:
> Jason van Zyl wrote:
> >
> >Component deployment and an applications use of a repository are irrelavent;
> >
> An applications use of a repository represent real and tangible examples 
> of expected utility - i.e. actual functional requirements.

Functional requirements of what?

> Sure "get me a versioned artefact of a particular type" is a privative 
> operation and around this we can establish specific requirements. But 
> should this be considered in isolation of a higher-level requirement to 
> "get me the latest artefact of a particular type"? We can look up and 
> see common requirements including "get me the set of relationships for 
> this artefact" and so on and so on as you move across different 
> abstractions. However, when look at requirements from the actual usage 
> point of view we quickly notice idiosyncrasies – for example - the 
> difference between physical types (e.g. a jar file) and logical types 
> (e.g. a plugin that actually maps to physical type). The point is that 
> the real requirements are coming from the repository enabled 
> applications – and drilling down from this perspective will actually 
> ensure that the end result meets actual needs.

I think you're entirely missing the point of the task we are being
charged with.

You keep speaking of behavioural characteristics of tools performing
actions. This is clearly not what we are discussing here. We are tasked
with creating the lowest common denominator: a file based repository
accessible via http.

To answer one of your specifics above with an example I will use the
example of "get me the latest artifact". This is entirely dependent on
the tool. In Maven we use the same basic versioning strategy except use
SNAPSHOT as the version for something that most closely resembles SCM
HEAD. We will also be using RELEASE to indicate the latest release, but
these are specific to Maven and another tool might use an entirely
different. In Maven we poke a little piece of metadata into the
repository to convert SNAPSHOTS to timestamped versions but this is
again native to Maven. Even these facets which I consider fundamental to
Maven are not required for the repository because implementors are free
to put what they like in the repository.

If we so decide after the first phase of this endeavour to add a simple
decorative layer to handle snapshots, latest releases then lets do so
after the basic task is finished. 

> Stephen.

Jason van Zyl

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  -- Jacques Ellul, The Technological Society

Reply via email to