You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@avalon.apache.org by do...@apache.org on 2002/11/15 08:10:40 UTC
cvs commit: jakarta-avalon/src/xdocs/framework getting-started.xml
donaldp 2002/11/14 23:10:39
Modified: src/xdocs/framework getting-started.xml
Log:
Remove need for token replacement.
Revision Changes Path
1.3 +4 -4 jakarta-avalon/src/xdocs/framework/getting-started.xml
Index: getting-started.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon/src/xdocs/framework/getting-started.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- getting-started.xml 15 Nov 2002 05:35:28 -0000 1.2
+++ getting-started.xml 15 Nov 2002 07:10:39 -0000 1.3
@@ -13,15 +13,15 @@
<s1 title="Introduction">
<p>If you are completely new to Avalon, the Framework subproject is not
the easiest place to start. We suggest you take a look at the
- <link href="@AVALON_BASE@/phoenix/getting-started.html">Avalon Phoenix getting started document</link>
+ <link href="../phoenix/getting-started.html">Avalon Phoenix getting started document</link>
first, as it will take you through downloading, installing and then
running something (a very simple server program) much more concrete.</p>
<p>Probably the next smart step is to learn by example. Take a look at
- one or two of the <link href="@AVALON_BASE@/apps">applications</link>
+ one or two of the <link href="../apps/index.html">applications</link>
that use avalon and at how well these are set up, and at some of the
- available <link href="@AVALON_BASE@/excalibur">components (in Excalibur)</link>
- and <link href="@AVALON_BASE@/cornerstone">services (in Cornerstone)</link>
+ available <link href="../excalibur/index.html">components (in Excalibur)</link>
+ and <link href="../cornerstone/index.html">services (in Cornerstone)</link>
Avalon offers.</p>
<p>You will find that the Framework has an important role in each and
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: getting-started.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> On Fri, 2002-11-15 at 08:48, Stephen McConnell wrote:
>
>>Maybe it would be a good idea to include in this document some links to
>>some of the other Avalon containers. The current content suggests
>>Phoenix as a starting point which is a little like learning to swim at
>>the deep end of the pool. It could be interesting to reference Tweety
>>and the entry point, followed by Merlin and Fortress dealing with cause
>>grained components, and wrapping up Phoenix at the application level.
>>
>>Thoughts?
>
>
> I don't really like it. I feel our documentation should point to
> released and easily downloadable software; atm, the only containers with
> that status are phoenix and ECM, and I feel it is a good idea to not
> stimulate usage of ECM.
>
> When fortress,tweety etc are released it's a different thing
> alltogether.
I agree.
Such important docs should reference only released software.
Tweety will be IMHO the real entry point to new Avalon users, but it
still has to be released.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: getting-started.xml
Posted by Leo Simons <le...@apache.org>.
On Fri, 2002-11-15 at 10:08, Stephen McConnell wrote:
> Leo Simons wrote:
>
> >On Fri, 2002-11-15 at 08:48, Stephen McConnell wrote:
> >
> >
> >>Maybe it would be a good idea to include in this document some links to
> >>some of the other Avalon containers. The current content suggests
> >>Phoenix as a starting point which is a little like learning to swim at
> >>the deep end of the pool. It could be interesting to reference Tweety
> >>and the entry point, followed by Merlin and Fortress dealing with cause
> >>grained components, and wrapping up Phoenix at the application level.
> >>
> >>Thoughts?
> >
> >I don't really like it. I feel our documentation should point to
> >released and easily downloadable software; atm, the only containers with
> >that status are phoenix and ECM, and I feel it is a good idea to not
> >stimulate usage of ECM.
>
> Totally agree on the ECM point - however - I concerned about the very
> high learning curve the Phoenix represents in terms of an entry point.
yup. It's got a bit of an 'enterprise' feel to it doesn't it ;)
> Ok - on Fortress and Merlin there isn't a trealease status for good
> reasons. On Tweety I think the scenario is different bacause I don't
> think Tweety should be released - it should be part of the getting
> started with Avalon walk though. I.e. is about eduction and delivering
> concrete examples. Does the publication of good informative and
> eductional content require that we go through a product release
> procedure? Surely not.
my idea here is that a release cycle makes sure everything is bugfree.
Also, tweety is so far a model example of the way development of an
avalon component can go and the release thing is only part of that.
> I'm in favour of making things understandable based on useful examples
> and demonstrations.
me too. I'm kinda stuck in my avalon-for-beginners howto though. I think
the approach I chose is wrong and am reworking to do things more
concept-by-concept. The example application for that should be something
real like infomover :D
help welcome........doc-writing is hard.......
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: getting-started.xml
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
>On Fri, 2002-11-15 at 10:57, Nicola Ken Barozzi wrote:
>
>
>>>I think you can view Tweety as a concept implementation, but not as a
>>>reference implementation. One thing it doesn't do for example is protect
>>>components from each other, or guarantee that the stuff a component can
>>>get from its SM has run up to initialize().
>>>There's a lot of stuff like that, and adding it all in would make the
>>>code complex to the level where it will be quite a bit more difficult to
>>>understand.
>>>
>>>
>>roger
>>
>>In fact I was thinking of eventually adding other systems
>>egg-tweety-birdy-pigeon-etc, but yes, it's a concept implementation.
>>
>>Where would you position it then phisically? I have no clue.
>>
>>
>
>as in where in a potential unified CVS? In scratchpad atm, when it is
>finished it (and other stuff, like 'pigeon'), could be put into
>something like /src/tutorial/.
>
>
+1
Steve.
>cheers,
>
>- Leo
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: getting-started.xml
Posted by Leo Simons <le...@apache.org>.
On Fri, 2002-11-15 at 10:57, Nicola Ken Barozzi wrote:
> > I think you can view Tweety as a concept implementation, but not as a
> > reference implementation. One thing it doesn't do for example is protect
> > components from each other, or guarantee that the stuff a component can
> > get from its SM has run up to initialize().
> > There's a lot of stuff like that, and adding it all in would make the
> > code complex to the level where it will be quite a bit more difficult to
> > understand.
>
> roger
>
> In fact I was thinking of eventually adding other systems
> egg-tweety-birdy-pigeon-etc, but yes, it's a concept implementation.
>
> Where would you position it then phisically? I have no clue.
as in where in a potential unified CVS? In scratchpad atm, when it is
finished it (and other stuff, like 'pigeon'), could be put into
something like /src/tutorial/.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: getting-started.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> On Fri, 2002-11-15 at 10:18, Nicola Ken Barozzi wrote:
>
>>We also should decide where it goes, and some have hinted it could go
>>side by side with the framework, although not being in the same package.
>>IMVHO it could be used as a simple reference implementation of the
>>framework concepts and contracts.
>>
>>Continuing the past proposal about a new unified CVS, thinking out loud:
>>
>> ./src/framework/**.java
>> ./src/reference/**.java
>> ./src/util/**.java
>>
>> ./scratchpad/src/merlin2/**.java
>> ./scratchpad/src/fortress/**.java
>>
>>Thoughts?
>
>
> I think you can view Tweety as a concept implementation, but not as a
> reference implementation. One thing it doesn't do for example is protect
> components from each other, or guarantee that the stuff a component can
> get from its SM has run up to initialize().
> There's a lot of stuff like that, and adding it all in would make the
> code complex to the level where it will be quite a bit more difficult to
> understand.
roger
In fact I was thinking of eventually adding other systems
egg-tweety-birdy-pigeon-etc, but yes, it's a concept implementation.
Where would you position it then phisically? I have no clue.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: getting-started.xml
Posted by Leo Simons <le...@apache.org>.
On Fri, 2002-11-15 at 10:18, Nicola Ken Barozzi wrote:
> We also should decide where it goes, and some have hinted it could go
> side by side with the framework, although not being in the same package.
> IMVHO it could be used as a simple reference implementation of the
> framework concepts and contracts.
>
> Continuing the past proposal about a new unified CVS, thinking out loud:
>
> ./src/framework/**.java
> ./src/reference/**.java
> ./src/util/**.java
>
> ./scratchpad/src/merlin2/**.java
> ./scratchpad/src/fortress/**.java
>
> Thoughts?
I think you can view Tweety as a concept implementation, but not as a
reference implementation. One thing it doesn't do for example is protect
components from each other, or guarantee that the stuff a component can
get from its SM has run up to initialize().
There's a lot of stuff like that, and adding it all in would make the
code complex to the level where it will be quite a bit more difficult to
understand.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: getting-started.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote:
>
> Nicola Ken Barozzi wrote:
>
>>
>> Stephen McConnell wrote:
>>
>>>
>>> Leo Simons wrote:
>>>
>>>> On Fri, 2002-11-15 at 08:48, Stephen McConnell wrote:
>>>>
>>>>> Maybe it would be a good idea to include in this document some
>>>>> links to some of the other Avalon containers. The current content
>>>>> suggests Phoenix as a starting point which is a little like
>>>>> learning to swim at the deep end of the pool. It could be
>>>>> interesting to reference Tweety and the entry point, followed by
>>>>> Merlin and Fortress dealing with cause grained components, and
>>>>> wrapping up Phoenix at the application level.
>>>>>
>>>>> Thoughts?
>>>>
>>>> I don't really like it. I feel our documentation should point to
>>>> released and easily downloadable software; atm, the only containers
>>>> with
>>>> that status are phoenix and ECM, and I feel it is a good idea to not
>>>> stimulate usage of ECM.
>>>
>>> Totally agree on the ECM point - however - I concerned about the very
>>> high learning curve the Phoenix represents in terms of an entry
>>> point. Ok - on Fortress and Merlin there isn't a trealease status for
>>> good reasons. On Tweety I think the scenario is different bacause I
>>> don't think Tweety should be released - it should be part of the
>>> getting started with Avalon walk though. I.e. is about eduction and
>>> delivering concrete examples. Does the publication of good
>>> informative and eductional content require that we go through a
>>> product release procedure? Surely not.
>>
>> Actually we do, since it's not only documentation but a working
>> implementation of the framework.
>>
>> We also should decide where it goes, and some have hinted it could go
>> side by side with the framework, although not being in the same package.
>> IMVHO it could be used as a simple reference implementation of the
>> framework concepts and contracts.
>
> In general I agree. I do however have a problem with referencing Tweety
> as a reference implementation. The reason is that Tweety demonstrates a
> flat notion of component deployment - in that it does not have any
> notion of how to resolve things like dependecies. Without a full
> implememtation of the Avalon component model - it really cannot be
> classed as a refernce.
Correct. However notice that Tweety also has "Egg.java", which is even
simpler...
I tend to see "reference" not as the complete reference but as snippets
of it... doesn't make perfect sense though :-|
> In fact, I have a problem with classifying any
> Avalon container as a reference - Foress does not handle depedencies,
> Merlin does not handle lifestyle based on marker interfaces, Phoenix
> does not handle lifestyle at all. I.e. reference implementation is a
> goal that no container has reached just yet.
Probably it's a naming issue then, dunno.
Reference in a way that it acts as a reference to at least one aspect of
the Avalon Framework.
Egg for example can be used as a reference to lifecycle.
Tweety as a reference to Container can be a component.
How would you call it? I have difficulty in expressing the concept,
please help.
>>
>> Continuing the past proposal about a new unified CVS, thinking out loud:
>>
>> ./src/framework/**.java
>> ./src/reference/**.java
>> ./src/util/**.java
>>
>> ./scratchpad/src/merlin2/**.java
>> ./scratchpad/src/fortress/**.java
>>
>> Thoughts?
>
>
>
> Abstracting up just for a moment - yes I'm totally ok with a unified
> CVS, and I'm all for a scratchpad on the basis that a scatchpad holds
> all of the non-released projects (Avalon wide).
>
> Cheers, Steve.
>
> p.s. looks like the subject of this thread was fortuitous
>
> ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: getting-started.xml
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
>
> Stephen McConnell wrote:
>
>>
>>
>> Leo Simons wrote:
>>
>>> On Fri, 2002-11-15 at 08:48, Stephen McConnell wrote:
>>>
>>>
>>>> Maybe it would be a good idea to include in this document some
>>>> links to some of the other Avalon containers. The current content
>>>> suggests Phoenix as a starting point which is a little like
>>>> learning to swim at the deep end of the pool. It could be
>>>> interesting to reference Tweety and the entry point, followed by
>>>> Merlin and Fortress dealing with cause grained components, and
>>>> wrapping up Phoenix at the application level.
>>>>
>>>> Thoughts?
>>>
>>>
>>> I don't really like it. I feel our documentation should point to
>>> released and easily downloadable software; atm, the only containers
>>> with
>>> that status are phoenix and ECM, and I feel it is a good idea to not
>>> stimulate usage of ECM.
>>
>>
>> Totally agree on the ECM point - however - I concerned about the very
>> high learning curve the Phoenix represents in terms of an entry
>> point. Ok - on Fortress and Merlin there isn't a trealease status for
>> good reasons. On Tweety I think the scenario is different bacause I
>> don't think Tweety should be released - it should be part of the
>> getting started with Avalon walk though. I.e. is about eduction and
>> delivering concrete examples. Does the publication of good
>> informative and eductional content require that we go through a
>> product release procedure? Surely not.
>
>
> Actually we do, since it's not only documentation but a working
> implementation of the framework.
>
> We also should decide where it goes, and some have hinted it could go
> side by side with the framework, although not being in the same package.
> IMVHO it could be used as a simple reference implementation of the
> framework concepts and contracts.
In general I agree. I do however have a problem with referencing Tweety
as a reference implementation. The reason is that Tweety demonstrates a
flat notion of component deployment - in that it does not have any
notion of how to resolve things like dependecies. Without a full
implememtation of the Avalon component model - it really cannot be
classed as a refernce. In fact, I have a problem with classifying any
Avalon container as a reference - Foress does not handle depedencies,
Merlin does not handle lifestyle based on marker interfaces, Phoenix
does not handle lifestyle at all. I.e. reference implementation is a
goal that no container has reached just yet.
>
>
> Continuing the past proposal about a new unified CVS, thinking out loud:
>
> ./src/framework/**.java
> ./src/reference/**.java
> ./src/util/**.java
>
> ./scratchpad/src/merlin2/**.java
> ./scratchpad/src/fortress/**.java
>
> Thoughts?
Abstracting up just for a moment - yes I'm totally ok with a unified
CVS, and I'm all for a scratchpad on the basis that a scatchpad holds
all of the non-released projects (Avalon wide).
Cheers, Steve.
p.s. looks like the subject of this thread was fortuitous
;-)
>
>
>> I'm in favour of making things understandable based on useful
>> examples and demonstrations.
>>
>> Cheers, Steve.
>>
>>> When fortress,tweety etc are released it's a different thing
>>> alltogether.
>>>
>>> cheers,
>>>
>>> - Leo
>>>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: getting-started.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote:
>
>
> Leo Simons wrote:
>
>> On Fri, 2002-11-15 at 08:48, Stephen McConnell wrote:
>>
>>
>>> Maybe it would be a good idea to include in this document some links
>>> to some of the other Avalon containers. The current content suggests
>>> Phoenix as a starting point which is a little like learning to swim
>>> at the deep end of the pool. It could be interesting to reference
>>> Tweety and the entry point, followed by Merlin and Fortress dealing
>>> with cause grained components, and wrapping up Phoenix at the
>>> application level.
>>>
>>> Thoughts?
>>
>> I don't really like it. I feel our documentation should point to
>> released and easily downloadable software; atm, the only containers with
>> that status are phoenix and ECM, and I feel it is a good idea to not
>> stimulate usage of ECM.
>
> Totally agree on the ECM point - however - I concerned about the very
> high learning curve the Phoenix represents in terms of an entry point.
> Ok - on Fortress and Merlin there isn't a trealease status for good
> reasons. On Tweety I think the scenario is different bacause I don't
> think Tweety should be released - it should be part of the getting
> started with Avalon walk though. I.e. is about eduction and delivering
> concrete examples. Does the publication of good informative and
> eductional content require that we go through a product release
> procedure? Surely not.
Actually we do, since it's not only documentation but a working
implementation of the framework.
We also should decide where it goes, and some have hinted it could go
side by side with the framework, although not being in the same package.
IMVHO it could be used as a simple reference implementation of the
framework concepts and contracts.
Continuing the past proposal about a new unified CVS, thinking out loud:
./src/framework/**.java
./src/reference/**.java
./src/util/**.java
./scratchpad/src/merlin2/**.java
./scratchpad/src/fortress/**.java
Thoughts?
> I'm in favour of making things understandable based on useful examples
> and demonstrations.
>
> Cheers, Steve.
>
>> When fortress,tweety etc are released it's a different thing
>> alltogether.
>>
>> cheers,
>>
>> - Leo
>>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: getting-started.xml
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
>On Fri, 2002-11-15 at 08:48, Stephen McConnell wrote:
>
>
>>Maybe it would be a good idea to include in this document some links to
>>some of the other Avalon containers. The current content suggests
>>Phoenix as a starting point which is a little like learning to swim at
>>the deep end of the pool. It could be interesting to reference Tweety
>>and the entry point, followed by Merlin and Fortress dealing with cause
>>grained components, and wrapping up Phoenix at the application level.
>>
>>Thoughts?
>>
>>
>
>I don't really like it. I feel our documentation should point to
>released and easily downloadable software; atm, the only containers with
>that status are phoenix and ECM, and I feel it is a good idea to not
>stimulate usage of ECM.
>
>
Totally agree on the ECM point - however - I concerned about the very
high learning curve the Phoenix represents in terms of an entry point.
Ok - on Fortress and Merlin there isn't a trealease status for good
reasons. On Tweety I think the scenario is different bacause I don't
think Tweety should be released - it should be part of the getting
started with Avalon walk though. I.e. is about eduction and delivering
concrete examples. Does the publication of good informative and
eductional content require that we go through a product release
procedure? Surely not.
I'm in favour of making things understandable based on useful examples
and demonstrations.
Cheers, Steve.
>When fortress,tweety etc are released it's a different thing
>alltogether.
>
>cheers,
>
>- Leo
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: getting-started.xml
Posted by Leo Simons <le...@apache.org>.
On Fri, 2002-11-15 at 08:48, Stephen McConnell wrote:
> Maybe it would be a good idea to include in this document some links to
> some of the other Avalon containers. The current content suggests
> Phoenix as a starting point which is a little like learning to swim at
> the deep end of the pool. It could be interesting to reference Tweety
> and the entry point, followed by Merlin and Fortress dealing with cause
> grained components, and wrapping up Phoenix at the application level.
>
> Thoughts?
I don't really like it. I feel our documentation should point to
released and easily downloadable software; atm, the only containers with
that status are phoenix and ECM, and I feel it is a good idea to not
stimulate usage of ECM.
When fortress,tweety etc are released it's a different thing
alltogether.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
getting-started.xml
Posted by Stephen McConnell <mc...@apache.org>.
Maybe it would be a good idea to include in this document some links to
some of the other Avalon containers. The current content suggests
Phoenix as a starting point which is a little like learning to swim at
the deep end of the pool. It could be interesting to reference Tweety
and the entry point, followed by Merlin and Fortress dealing with cause
grained components, and wrapping up Phoenix at the application level.
Thoughts?
Cheers, Steve.
donaldp@apache.org wrote:
>donaldp 2002/11/14 23:10:39
>
> Modified: src/xdocs/framework getting-started.xml
> Log:
> Remove need for token replacement.
>
> Revision Changes Path
> 1.3 +4 -4 jakarta-avalon/src/xdocs/framework/getting-started.xml
>
> Index: getting-started.xml
> ===================================================================
> RCS file: /home/cvs/jakarta-avalon/src/xdocs/framework/getting-started.xml,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -r1.2 -r1.3
> --- getting-started.xml 15 Nov 2002 05:35:28 -0000 1.2
> +++ getting-started.xml 15 Nov 2002 07:10:39 -0000 1.3
> @@ -13,15 +13,15 @@
> <s1 title="Introduction">
>
> <p>If you are completely new to Avalon, the Framework subproject is not
>
> the easiest place to start. We suggest you take a look at the
>
> - <link href="@AVALON_BASE@/phoenix/getting-started.html">Avalon Phoenix getting started document</link>
>
> + <link href="../phoenix/getting-started.html">Avalon Phoenix getting started document</link>
>
> first, as it will take you through downloading, installing and then
>
> running something (a very simple server program) much more concrete.</p>
>
>
>
> <p>Probably the next smart step is to learn by example. Take a look at
>
> - one or two of the <link href="@AVALON_BASE@/apps">applications</link>
>
> + one or two of the <link href="../apps/index.html">applications</link>
>
> that use avalon and at how well these are set up, and at some of the
>
> - available <link href="@AVALON_BASE@/excalibur">components (in Excalibur)</link>
>
> - and <link href="@AVALON_BASE@/cornerstone">services (in Cornerstone)</link>
>
> + available <link href="../excalibur/index.html">components (in Excalibur)</link>
>
> + and <link href="../cornerstone/index.html">services (in Cornerstone)</link>
>
> Avalon offers.</p>
>
>
>
> <p>You will find that the Framework has an important role in each and
>
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>