You are viewing a plain text version of this content. The canonical link for it is here.
Posted to repository@apache.org by Stephen McConnell <mc...@apache.org> on 2003/11/07 17:48:58 UTC
Re: Scope/Phasing
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 organizational/legal viewpoint is partly reflected in the Maven POM
model with information concerning the organization name, contributors and
so forth. One of the important aspects here is licensing.
* The application viewpoint is where a repository really shines. For
example
the Maven project uses a repository as the source of build-time artefacts.
The Avalon team are using the repository as a source of artefacts for
things
like dynamic classloader hierarchy creation, automated bootstrapping of
components, coordinated management of apis, spis and implementations. At
this level what is largely missing in the underlying repository service is
a flexible meta-model and an efficient protocol.
In order to address these limitations we are currently extending our
existing
repository model to support bootstrapping of alternative back-end storage
strategies and protocols - with LDAP as the primary candidate (based on a
collaboration with the Apache Directory Project team). There is also
some initial work going on with respect to a repository plugin for eclipse
that is aiming at drag-and-drop component assembly relative to repository
content.
One of the things that I think will be really important is simply getting
this up and running here at Apache in order to facilitate a better
understanding different repository aware applications and from that ..
a better understanding of the common requirements across different
projects.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
RE: Scope/Phasing
Posted by Alex Karasulu <ao...@bellsouth.net>.
> 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. 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).
Yes this is a good point. Jason you have expressed your own adventures
In using the repository in this light ;-). I think you guys agree more
than disagree. Steve is looking at his own specific layer or application
stacked on top of the baseline as another decorator.
> 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.
>
> >This idea has been thoroughly discussed in Maven-land.
> >
>
> Based on the dev@maven (which I've been following closely since
> Febraury) the discussions are properly grounded on the development
> process abstraction. 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.
>
> 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
>
And this is a great picture. At the lowest level we need an API to get
at the content and query the repository for the meta data. All apps
independent of language can build on these services.
> Can you give me a URL to the Wagon iniative?
Yeah I'm still ignorant ;-).
Alex
Re: Scope/Phasing
Posted by Jason van Zyl <jv...@maven.org>.
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.
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
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
Re: Scope/Phasing
Posted by Stephen McConnell <mc...@apache.org>.
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.
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.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Re: Scope/Phasing
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jason van Zyl wrote:
> On Fri, 2003-11-07 at 17:21, Stephen McConnell wrote:
>
>>Jason van Zyl wrote:
>>
>>
>>>On Fri, 2003-11-07 at 15:38, Stephen McConnell wrote:
>
> I just snipped the whole thing because I think that discussion is
> heading in the wrong direction and we could go on ad nauseum vis-a-vis
> containers and MDA.
>
> I think that Nick's idea for a simple set of requirements would be a
> good start and I think they are simple. As I said I will take a stab at
> a proposal this weekend and it will be very short and simple not much
> different than what has been discussed. I hope that others do the same
> so that we can compare.
>
> Maven's POM is irrelavent; Component deployment and an applications use
> of a repository are irrelavent; Searching is irrevlant. This with
> respect to the task this group has been charged with. All these things
> are above and beyond what is required here which is essentially easy
> access to versioned artifacts. It's really not that much more than that.
> Sophisticated systems that are reliable are built upon simplicity not
> complexity
>
> Someone should be able to look at one page and in five mintues
> understand everything that the repository should be.
>
> I will follow Nick's lead and draft a response to the request for goals
> and requirements.
>
> It's not that complicated and these discussions shouldn't go on and on
> and on into a 2000 word discourse on the all singing, all dancing
> repository.
Exactly. +1 all the way
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Scope/Phasing
Posted by Stephen McConnell <mc...@apache.org>.
Adam R. B. Jack wrote:
>>It's really not that much more than that.
>>Sophisticated systems that are reliable are built upon simplicity not
>>complexity
>>
>>
>
>I agree. I'd like to think of what we are doing as laying out a simple file
>system, and later building services that index/query. Compare this to
>/cvsroot, cvs protocol (clients to a remote server), then viewcvs (a
>'server' behind HTTP, implemented as a client to CVS). Each built on top of
>the other, nice and simple, nice and powerful at each level. Compare this to
>a www site w/ search, text indexing, whatever. Each layer is independent,
>independently specified, and independently useful.
>
Yep.
>
>I feel that if we nailed down the first, we can build the second and third
>server side, as and when need arises. Metadata-less at the lowest level,
>optionally richer as on moves up. Simplicity is the key at each level, I
>completely agree w/ Jason there.
>
>Nick is right ... we need to specify based upon requirements,
>
This is my primary focus. I looking from the point of view of something
similar to a cvs server and cvs client - and from that perspective, looking
down with respect to the requirements of the underlying systems and
protocols. This usecase approach is much more about identifiying needs
that can be used to validate that stack of simple facilities.
Cheers, Steve.
>and code (whose-ever) can follow.
>
>regards
>
>Adam
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Re: Scope/Phasing
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> It's really not that much more than that.
> Sophisticated systems that are reliable are built upon simplicity not
> complexity
I agree. I'd like to think of what we are doing as laying out a simple file
system, and later building services that index/query. Compare this to
/cvsroot, cvs protocol (clients to a remote server), then viewcvs (a
'server' behind HTTP, implemented as a client to CVS). Each built on top of
the other, nice and simple, nice and powerful at each level. Compare this to
a www site w/ search, text indexing, whatever. Each layer is independent,
independently specified, and independently useful.
I feel that if we nailed down the first, we can build the second and third
server side, as and when need arises. Metadata-less at the lowest level,
optionally richer as on moves up. Simplicity is the key at each level, I
completely agree w/ Jason there.
Nick is right ... we need to specify based upon requirements, and code
(whose-ever) can follow.
regards
Adam
Re: Scope/Phasing
Posted by Jason van Zyl <jv...@maven.org>.
On Fri, 2003-11-07 at 17:21, Stephen McConnell wrote:
> Jason van Zyl wrote:
>
> >On Fri, 2003-11-07 at 15:38, Stephen McConnell wrote:
I just snipped the whole thing because I think that discussion is
heading in the wrong direction and we could go on ad nauseum vis-a-vis
containers and MDA.
I think that Nick's idea for a simple set of requirements would be a
good start and I think they are simple. As I said I will take a stab at
a proposal this weekend and it will be very short and simple not much
different than what has been discussed. I hope that others do the same
so that we can compare.
Maven's POM is irrelavent; Component deployment and an applications use
of a repository are irrelavent; Searching is irrevlant. This with
respect to the task this group has been charged with. All these things
are above and beyond what is required here which is essentially easy
access to versioned artifacts. It's really not that much more than that.
Sophisticated systems that are reliable are built upon simplicity not
complexity
Someone should be able to look at one page and in five mintues
understand everything that the repository should be.
I will follow Nick's lead and draft a response to the request for goals
and requirements.
It's not that complicated and these discussions shouldn't go on and on
and on into a 2000 word discourse on the all singing, all dancing
repository.
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
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
Re: Scope/Phasing
Posted by Stephen McConnell <mc...@apache.org>.
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
>Merlin.
>
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
>myself.
>
* 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 dev@maven (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
>itself.
>
>
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
>creation.
>
>
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 dev@maven?
I.e. in public.
</question>
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
RE: Scope/Phasing
Posted by Jason van Zyl <jv...@maven.org>.
On Sat, 2003-11-08 at 00:42, Alex Karasulu wrote:
> Building in the ability to query meta-data attributes on artifacts
> is all that I'm personally asking. This is not over complicating
> the repository concept. It's a natural progression.
It most certainly is an unecessary facitly at the base-line level. The
query mechanism is not something that is needed at the base-line level.
> 100% agree but don't stop the evolution of an idea because it may
> seems to add more complexity.
>
> I am convinced that
> > the discussion of the repository need not delve into topics of service
> > deployment or repository aware applications. This is entirely within the
> > domain of the implementors of these systems and I am one them so I speak
>
> Right these are use case examples that support the need for meta-data
> Attributes in the repo.
I don't think it does if you mean at a base-line level you will required
a mechanism like LDAP or WebDAV. Is that what you're trying to say? If
so then I couldn't disagree more.
Anything information required to deploy an application which may require
information about given artifacts can be stored in the repository
itself. If you are saying that attributes for artifacts are to be
primitives in the repository then I certainly disagree.
> > from some practical experience in the matter. Plexus and Merlin may both
> > have their own component deployment model and repository aware
> > applications and I have certainly thought of these things and I have yet
> > to be hindered with what currently exists. Additionally there is no way
> > you could ever standardize on these things given the existence of Pico,
> > Nano, Loom, Plexus, Carbon, Merlin, Spring, SOFA, Fractal just to name a
>
> Nothing is impossible.
It's simply never going to happen and there is no need for it to. I
highly recommend a reading of Syperski's Component Software. It serves
not only as a technical guide but clearly gives reasons why multiple
standards exist and why each one can thrive.
> > few of the existing containers and component models. There is simply no
> > chance you're going to get them all to converge and you don't have to.
>
> That's a very gloomy picture for the confused user who spends as
> much time trying to find the right container. It has become a real
> mess out there for the user.
I don't think so at all. Competition is a good thing, a great thing in
fact. You can't stop and there will always be different implementations
for personal, political, and practical reasons.
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
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
RE: Scope/Phasing
Posted by di...@multitask.com.au.
"Alex Karasulu" <ao...@bellsouth.net> wrote on 08/11/2003 04:42:43 PM:
[snip]
> I don't intend to inflame anyone so please don't take it in the wrong
way
> but the Maven PMC sounds like a closed society to me. The maven-new
details
>
> are hidden pending some PMC conclusions. The Wagon details are hidden
> as well again pending PMC conclusions. There just seems to me to be an
> extreme amount of caution/secrecy with regard to involving the community
> which counteracts the benefits of having one in the first place.
[snip]
Can we please keep conjecture and flame-bait to private email?
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
RE: Scope/Phasing
Posted by Alex Karasulu <ao...@bellsouth.net>.
Jason,
> 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 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.
I don't think anyone is saying that the repo has to support
the needs of avalon for the sake of the runtime aspects of
component deployment. The attempt is to express the specific
application space Avalon is interested in. This as well as
countless other application will require a meta data facility
to be able to tag components with attributes.
Some of these attributes may be maven specific and for the
build process and some will be application specific. Once that
is agreed upon the Avalon folks can follow their application
specific path.
The key is to agree on the common set of functionality that
will support every possible application. This means keeping
it simple and generic.
Building in the ability to query meta-data attributes on artifacts
is all that I'm personally asking. This is not over complicating
the repository concept. It's a natural progression.
> Service deploy, and Repository Aware applications are outside the scope
> of the repository. 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
> itself.
Again sorry for sounding like a broken record I don't think the trail
is about that. It's a use case justification for the need to associate
meta-data (attributes) with an artifact.
> > 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.
I don't intend to inflame anyone so please don't take it in the wrong way
but the Maven PMC sounds like a closed society to me. The maven-new details
are hidden pending some PMC conclusions. The Wagon details are hidden
as well again pending PMC conclusions. There just seems to me to be an
extreme amount of caution/secrecy with regard to involving the community
which counteracts the benefits of having one in the first place.
> In summary I would say we keep the notions simple.
100% agree but don't stop the evolution of an idea because it may
seems to add more complexity.
I am convinced that
> the discussion of the repository need not delve into topics of service
> deployment or repository aware applications. This is entirely within the
> domain of the implementors of these systems and I am one them so I speak
Right these are use case examples that support the need for meta-data
Attributes in the repo.
> from some practical experience in the matter. Plexus and Merlin may both
> have their own component deployment model and repository aware
> applications and I have certainly thought of these things and I have yet
> to be hindered with what currently exists. Additionally there is no way
> you could ever standardize on these things given the existence of Pico,
> Nano, Loom, Plexus, Carbon, Merlin, Spring, SOFA, Fractal just to name a
Nothing is impossible.
> few of the existing containers and component models. There is simply no
> chance you're going to get them all to converge and you don't have to.
That's a very gloomy picture for the confused user who spends as
much time trying to find the right container. It has become a real
mess out there for the user.
Alex
Re: Scope/Phasing
Posted by Jason van Zyl <jv...@maven.org>.
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.
> 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.
> 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
Merlin.
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 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.
What specific problems have you run into? I haven't run into any yet
myself.
> >This idea has been thoroughly discussed in Maven-land.
> >
>
> Based on the dev@maven (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.
For any use case you can provide I think I could suggest a way to
utilize what exists right now.
> 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. 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
itself.
> Building or composing?
Simply building, I compose using component descriptors of my own
creation.
> >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.
> 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.
In summary I would say we keep the notions simple. I am convinced that
the discussion of the repository need not delve into topics of service
deployment or repository aware applications. This is entirely within the
domain of the implementors of these systems and I am one them so I speak
from some practical experience in the matter. Plexus and Merlin may both
have their own component deployment model and repository aware
applications and I have certainly thought of these things and I have yet
to be hindered with what currently exists. Additionally there is no way
you could ever standardize on these things given the existence of Pico,
Nano, Loom, Plexus, Carbon, Merlin, Spring, SOFA, Fractal just to name a
few of the existing containers and component models. There is simply no
chance you're going to get them all to converge and you don't have to.
Each implementation can do what they like.
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
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
Re: Scope/Phasing
Posted by Stephen McConnell <mc...@apache.org>.
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. 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).
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.
>This idea has been thoroughly discussed in Maven-land.
>
Based on the dev@maven (which I've been following closely since
Febraury) the discussions are properly grounded on the development
process abstraction. 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.
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
>>* The organizational/legal viewpoint is partly reflected in the Maven POM
>> model with information concerning the organization name, contributors and
>> so forth. One of the important aspects here is licensing.
>>
>>* The application viewpoint is where a repository really shines. For
>> example the Maven project uses a repository as the source of
>> build-time artefacts. The Avalon team are using the repository as a
>> source of artefacts for things like dynamic classloader hierarchy
>> creation, automated bootstrapping of components, coordinated
>> management of apis, spis and implementations. At this level what is
>> largely missing in the underlying repository service is a flexible
>> meta-model and an efficient protocol.
>>
>>
>
>As far as building applications, I have been doing this for well over a
>year with Plexus and its runtime builder.
>
Building or composing?
>Michal has been working on Wagon
>
Do you know if Michal is subscribed to this list?
>
>
>
>
>>In order to address these limitations we are currently extending our
>>existing
>>repository model to support bootstrapping of alternative back-end storage
>>strategies and protocols - with LDAP as the primary candidate (based on a
>>collaboration with the Apache Directory Project team).
>>
>>
>
>Again, as I've mentioned before information as a decoration is certainly
>valuable. LDAP is certainly one possibility, object stores using
>something like OJB and Prevayler are also things I've personally
>experimented with.
>
>But really I think the notion of a repository is really not that complex
>and I will work this weekend in order to submit a proposal based on the
>valuable experience I've gained from Maven usesr and some of the ideas
>we've come up while developing Wagon (which will be showing up in a
>repository near you asap).
>
Can you give me a URL to the Wagon iniative?
Cheers, Steve.
>>There is also
>>some initial work going on with respect to a repository plugin for eclipse
>>that is aiming at drag-and-drop component assembly relative to repository
>>content.
>>
>>One of the things that I think will be really important is simply getting
>>this up and running here at Apache in order to facilitate a better
>>understanding different repository aware applications and from that ..
>>a better understanding of the common requirements across different
>>projects.
>>
>>
>
>That's definitely a good idea. Hopefully the existing Avalon Maven
>repository may serve as a valuable example. Over the next week I will
>finish a tool to extract artifacts from the standard archives produced
>by the various projects here in order to facilitate the mirroring of
>Apache artifacts to Ibiblio as requested by the board. So shortly there
>will be fully populated maven-style repository and hopefully that too
>may serve as a valuble example we can all work from.
>
>
>
>>Stephen.
>>
>>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
RE: Scope/Phasing
Posted by Alex Karasulu <ao...@bellsouth.net>.
> > * 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. This idea
> has been thoroughly discussed in Maven-land.
The POM does contain information regarding describing the artifacts
generated by a project. The dependencies are what I think are being
referred to here by Steve. Or perhaps the fact that some of the info is
There but its not the sole purpose for the POM.
> > * The application viewpoint is where a repository really shines. For
> > example
> > the Maven project uses a repository as the source of build-time
> artefacts.
> > The Avalon team are using the repository as a source of artefacts for
> > things
> > like dynamic classloader hierarchy creation, automated bootstrapping
> of
> > components, coordinated management of apis, spis and implementations.
> At
> > this level what is largely missing in the underlying repository
> service is
> > a flexible meta-model and an efficient protocol.
> As far as building applications, I have been doing this for well over a
> year with Plexus and its runtime builder. The Loom and Pico folks are
> also doing similiar things so we have a wealth of information and
> experience to gain from those folks too. Michal has been working on
> Wagon and has had many discussions with Peter Donald who has some
> fantastic ideas vis-a-vis repositories and application production and
> application runtime.
This is all the more reason to go to incubation with this. We want all
the players to be part of a discussion ( referring to Nicola's email ).
> > In order to address these limitations we are currently extending our
> > existing
> > repository model to support bootstrapping of alternative back-end
> storage
> > strategies and protocols - with LDAP as the primary candidate (based on
> a
> > collaboration with the Apache Directory Project team).
> Again, as I've mentioned before information as a decoration is certainly
> valuable. LDAP is certainly one possibility, object stores using
> something like OJB and Prevayler are also things I've personally
> experimented with.
Yes decorations are good. But LDAP or any database functionality
should be a central facility offered by the repository. Why not
put POM deployment data into the repository this way? It can be
queried and projects can be cross referenced and made relational.
Leave it up to the user to determine project specific attributes
that can be added. Use a decorator pattern to enable this feature
but it should be added. Whether used or not is an application
specific decision but something tells me it will be used extensively.
Let's face it the maven repo at ibiblio is a directory of artifacts
and all you're missing is a hierarchical database to associate these
artifacts with attributes. I don't care (maybe a little) if you
use webdav or LDAP to do that but the value proposition is huge
when it comes to facilitating development life-cycle models. The
implications to the field of SCM alone are huge.
Directories and the repository notion fit extremely well together.
Think about the hierarchy and dependency synergy. Think about how
the repository is used: read frequently written to very infrequently.
LDAP is also a very fast line protocol to front end a hierarchical
attribute database. The power of referrals also makes it a very
attractive proposition to create cross references between projects
tying several distributed repositories together into a directory
system. Also consider the replication capability needed for
high availability (did not mean for that to rhyme). LDAP is great
for replicating (mirroring) these attributes. No other access model
gives you such a bang in one tight package.
As I said before Maven took an incredible leap with the innovation of
the repository used for the build process. The concept here is massive
and bigger than all of us. We need to bring everything together to
take it even further and be open to all the possibilities. That's
why perhaps Nicola's attempts to make it an incubator project are
so appealing.
>
> But really I think the notion of a repository is really not that complex
> and I will work this weekend in order to submit a proposal based on the
> valuable experience I've gained from Maven usesr and some of the ideas
> we've come up while developing Wagon (which will be showing up in a
> repository near you asap).
You know I'm still confused about what Wagon is.
> > There is also
> > some initial work going on with respect to a repository plugin for
> eclipse
> > that is aiming at drag-and-drop component assembly relative to
> repository
> > content.
> >
I drool thinking about this every night!
Alex
Re: Scope/Phasing
Posted by Jason van Zyl <jv...@maven.org>.
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. This idea
has been thoroughly discussed in Maven-land.
> * The organizational/legal viewpoint is partly reflected in the Maven POM
> model with information concerning the organization name, contributors and
> so forth. One of the important aspects here is licensing.
>
> * The application viewpoint is where a repository really shines. For
> example
> the Maven project uses a repository as the source of build-time artefacts.
> The Avalon team are using the repository as a source of artefacts for
> things
> like dynamic classloader hierarchy creation, automated bootstrapping of
> components, coordinated management of apis, spis and implementations. At
> this level what is largely missing in the underlying repository service is
> a flexible meta-model and an efficient protocol.
As far as building applications, I have been doing this for well over a
year with Plexus and its runtime builder. The Loom and Pico folks are
also doing similiar things so we have a wealth of information and
experience to gain from those folks too. Michal has been working on
Wagon and has had many discussions with Peter Donald who has some
fantastic ideas vis-a-vis repositories and application production and
application runtime.
> In order to address these limitations we are currently extending our
> existing
> repository model to support bootstrapping of alternative back-end storage
> strategies and protocols - with LDAP as the primary candidate (based on a
> collaboration with the Apache Directory Project team).
Again, as I've mentioned before information as a decoration is certainly
valuable. LDAP is certainly one possibility, object stores using
something like OJB and Prevayler are also things I've personally
experimented with.
But really I think the notion of a repository is really not that complex
and I will work this weekend in order to submit a proposal based on the
valuable experience I've gained from Maven usesr and some of the ideas
we've come up while developing Wagon (which will be showing up in a
repository near you asap).
> There is also
> some initial work going on with respect to a repository plugin for eclipse
> that is aiming at drag-and-drop component assembly relative to repository
> content.
>
> One of the things that I think will be really important is simply getting
> this up and running here at Apache in order to facilitate a better
> understanding different repository aware applications and from that ..
> a better understanding of the common requirements across different
> projects.
That's definitely a good idea. Hopefully the existing Avalon Maven
repository may serve as a valuable example. Over the next week I will
finish a tool to extract artifacts from the standard archives produced
by the various projects here in order to facilitate the mirroring of
Apache artifacts to Ibiblio as requested by the board. So shortly there
will be fully populated maven-style repository and hopefully that too
may serve as a valuble example we can all work from.
> Stephen.
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
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