You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/04/08 19:33:33 UTC
DevWAv (was Re: Minimum Set of Tags (Revisited))
Stephen McConnell wrote:
>
>
> Disagree - "Developing with Avalon" describes ECM semantics. ECM
> semantic are a superset of Avalon semantics. Avalon semantics are
> defined in the Javadoc and the lifecycle specifications.
>
> Chers, Steve.
>
Disagree all you want--Developing with Avalon was written to document
AF4.0 contracts. That was its intent.
It also happens to document some ECM implementation details.
If you disagree with anything written in there, let's put it out on
the table as I suggested. Please use the appropriate thread so that
the topics can stay on track.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: DevWAv (was Re: Minimum Set of Tags (Revisited))
Posted by Leo Simons <le...@apache.org>.
Note to Steve: e-mail to long, setences to complex (had to reread it
three times!)
Stephen McConnell wrote:
> Nicola Ken Barozzi wrote:
>
> For me it is about identifying the problem your trying to solve before
> attempting to solve the problem. I happen to think that there is a
> fundamental flaw in the common denominator approach - you end with
> something that is not usable by anyone.
phoenix/a != merlin/b
trick is that
(phoenix*b)/(a*b) = (merlin*a)/(a*b)
simplifies to
phoenix*b = merlin*a
meaning easier portability by adding *b onto phoenix and/or *a onto
merlin. Surely, (a*b) is not usable by itself, but making use of it
increases common ground and portability.
> I see the following four things that are needed - and I have the
> impression that the focus is on (4) without resolution of (1), (2) or (3).
I have the impression we all have nearly the same implicit assumptions
about (1),(2) and (3), and dragging out all those assumptions takes ages
and is unneccessary.
> 1. be clear about the objective
make it easier for component developers to write-once,
maintain-in-a-single-place, deploy-into-multiple-environments. Coupled
to that, reduce to the max by removing code and concept duplication.
> 2. identify where your moving from
1) ECM
2) Phoenix
IOW, released materials. To lesser extend
3) fortress
4) merlin
whose metainformation capability are unknown to most hence should not be
taken for granted, whereas the capabilities of 1) and 2) are much more
commonly known. Couple to that we have decided to dislike some of the
ECM semantics, and we move from AF+Phoenix, also because it is a rather
common subset of 1,2,3,4.
> 3. figure out the possible approaches
> 4. move to a solution
Berin has tried to constrain the talks to 1) and 2) :D
now to dissect rest of your mail :D
> 1. What is the objective:
> -------------------------
> Conclusion - basic objective needs more discussion. If the objective is
> to define a set of tags capable of supporting AF4 then this should be
> stated.
the objective is *not* to write
avalon.apache.org/framework/metatags.html and impose that onto anyone as
the standard. Look at the bigger picture.
> If the objective is to define a set of tags that are restricted
> to the @phoenix @fortress subset
yes, the objective is exactly to figure out what parts of those subsets
can be elevated to a common subset, where I am not up to speed on the
@fortress subset so disregarding that for now. "Common subset" does not
mean "support required in all AF4 containers"!
> then you have add all of the implicit
> semantics introduced by Phoenix and Fortress.
in the light of product continuity and a stable platform we have to deal
with those anyway.
> Maybe the objective is
> just for Berin to figure out the tags structure and semantics for
> @fortress
it is not.
> 2. Where are we moving from:
> ----------------------------
>
> AF+ECM
> ------
> Components with AF+ECM semantics and without markup
> indicating the implicit ECM assumptions
these assumptions are documented in DwA, so it should be easy enough to
talk about them. Of course, most of these assumptions are currently
pretty invalid for the majority of containers. Which we all know.
> AF+Phoenix
> ----------
> Components with AF+Phoenix semantics are less problematic
> because the Phoenix components include meta-info from which
> a container can adapt to address the assumed semantics such
> as BlockContext and implicit singleton lifestyle.
these semantics are also pretty explicitly documented. And we know them
pretty well.
> AF+Type
> -------
> Components with AF+Type semantics
these semantics are documented, but I haven't been keeping up so I'm not
up to speed on those. IIUC they are way more elaborate than what other
containers do, so they cannot be sensibly used as a starting point.
Since AIUI merlin supports the phoenix semantics, it makes all the more
sense to start from those.
> 3. Possible Approaches
> ----------------------
>
> (a) tag based markup
> (b) a common meta-info model
>
> Tag based markup is easier because in principal you can generate the
> meta from the tags. In practice its not that simple because you cannot
> just say "let's start with @phoenix because @phoenix carries with it
> implicit assumptions (as described above). What you can do is start
> with @phoenix plus declaration of the implicit assumptions which can be
> achieved by declaring the Phoenix BlockContext assumptions (context type
> and context entries) and singleton lifestyle.
I suggest you volunteer to declare the implicit assumptions in phoenix
by writing an e-mail to this list or looking the appropriate stuff up in
the archives, and we can then mark those as explicit and move from there.
I really can't see why we cannot talk implementation detail in the
meantime, assumping all implicit assumptions are assumed.
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: DevWAv (was Re: Minimum Set of Tags (Revisited))
Posted by Berin Loritsch <bl...@apache.org>.
Peter Royal wrote:
> On Wednesday, April 9, 2003, at 09:27 AM, Berin Loritsch wrote:
>
>> Wrong. XML is only one representation of info. It happens to be what
>> Phoenix/Merlin uses. XML is not end all and be all, and packaging
>> is of a secondary issue right now.
>
>
> But unless we agree on how the container reads out this meta
> information, one will have to recompile their components with the "meta
> generation method of choice" for whichever container they are using.
It is a matter of generating the information.
> No longer can you just download excalibur-datasource-1.2.jar, you need
> to get the source, and parse out the metainfo from the source and
> package it up into the format that the container-of-the-day needs.
> That's a pain in the rear for users, imho.
You can't do that now. There is no "no longer" about it. The first
step is agree on the tags. The second step is agree on how to package
it.
> Why don't we attack this from the other direction: How will the
> container get this information?
>
> I see this discussion as the meta-info xml format discussions of last
> summer in different clothing.
Because I don't want to dredge up this right now. Remember: one step
at a time.
Technically speacking, we can generate the meta information for all
three of the containers and have them peacefully coexist without
problem in the short term. I just want to adress one problem at
a time.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: DevWAv (was Re: Minimum Set of Tags (Revisited))
Posted by Paul Hammant <Pa...@ThoughtWorks.net>.
Peter,
> Why don't we attack this from the other direction: How will the
> container get this information?
-1 (vote, not veto) I don;t think we should look down that road either.
Leave as diverse.
> I see this discussion as the meta-info xml format discussions of last
> summer in different clothing.
> -pete
+1
--
http://www.thoughtworks.com : The art of heavy lifting.
Home for many Agile-practicing Open Source activists...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: DevWAv (was Re: Minimum Set of Tags (Revisited))
Posted by Peter Royal <pr...@apache.org>.
On Wednesday, April 9, 2003, at 09:27 AM, Berin Loritsch wrote:
>> I'm quite happy with Lowest Common Denominator (LCD ?) generally.
>> The LCD in this case is Avalon-Framework's Java interfaces.
>> I am going to suggest that this quest for doclet tags is completely
>> abandoned.
>
> We need a definition if we are going to allow users to not have to
> change *several* files in their source code every time they have
> to switch containers.
>
>> Containers use XML meta info, that is usually put in the same jar as
>> the class files.
>
> Wrong. XML is only one representation of info. It happens to be what
> Phoenix/Merlin uses. XML is not end all and be all, and packaging
> is of a secondary issue right now.
But unless we agree on how the container reads out this meta
information, one will have to recompile their components with the "meta
generation method of choice" for whichever container they are using.
No longer can you just download excalibur-datasource-1.2.jar, you need
to get the source, and parse out the metainfo from the source and
package it up into the format that the container-of-the-day needs.
That's a pain in the rear for users, imho.
Why don't we attack this from the other direction: How will the
container get this information?
I see this discussion as the meta-info xml format discussions of last
summer in different clothing.
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: DevWAv (was Re: Minimum Set of Tags (Revisited))
Posted by Berin Loritsch <bl...@apache.org>.
Paul Hammant wrote:
> Berin,
>> Paul, I disagree whole-heartedly with you. We are agreeing on standards
>> that will be used in the containers we will be using. To denounce your
>> claims:
>>
>> 1) "There is no need for (b)"
>> It is for precisely this reason that components cannot work within
>> all containers. There are no standards for letting the developer
>> declare their meta-information. Therefore, no container can agree
>> on how to represent it.
>
> No components just need additional/alternative meta-information to get
> them to work. The java code works quite well (A-F is our core art). I
> would find it trivial to retrofit an xinfo file to some conp I found
> elsewhere. You mean 'out of the box' they fail to work.
The fact that these components need additional meta information shows
that the components do not interoperate as defined in A-F alone. This
deficiency in the code contracts has to be made up somewhere.
I do not want to alter my source code several times for each container
I forsee deploying my component in. If I use an ANT task to produce
the proper meta-information by-products, all I should have to do is
swap out the ANT task and I can use the the JAR in the new container.
For the short term this is acceptable. However, hand editing meta
information directly, or altering my source code to accommodate a new
container is not. By source code, I am including any JavaDoc tasks.
>> 2) "Diversity is a good thing"
>> Only when there are standards so that I do not have to duplicate
>> work when migrating from container to container. Already
>> attributes have greatly improved the productivity of the GUIApp
>> project, and the ease of deploying several JARs and piecing
>> together functionality of an application. If I don't have to
>> alter all the tags every time I want to migrate to another
>> container, then it increases my productivity more. It also
>> *encourages* diversity because I am no longer locked into one
>> container as is the case now.
>
> You are not locked to a single container.
You are if you don't want to mess with hand editing meta information,
or writing several different styles of meta information.
>> 3) "(a) implies attribute support in Java"
>> We can explore different options in packaging later. However, it
>> is only a minor thing to repackage a JAR.
>
> That's my point ?!
Not the point I saw coming accross. If I have a tool do the packaging
for me, it is a minor thing. If I have to hand edit several files,
pull some patch cables, and hard wire something then it isn't very
useful.
My point is that I want to define the SOURCE code now, and then worry
about how it is stored and referenced at run time later. Step 1 then
Step 2. We can take more time for Step 2.
>> Rewriting the way we
>> represent meta information for each container has a much greater
>> impact.
Which you neglected to mention anything about. The difference in change
that I am talking about is an entry in one (1) file: the build file.
The difference you are promoting requires that I alter several files
(one for each component) to make the components deployable in other
containers.
See the difference in impact?
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: DevWAv (was Re: Minimum Set of Tags (Revisited))
Posted by Paul Hammant <Pa...@ThoughtWorks.net>.
Berin,
>> I'm quite happy with Lowest Common Denominator (LCD ?) generally.
>> The LCD in this case is Avalon-Framework's Java interfaces.
>>
>> I am going to suggest that this quest for doclet tags is completely
>> abandoned.
>
>
> We need a definition if we are going to allow users to not have to
> change *several* files in their source code every time they have
> to switch containers.
Correction dude, Switching containers does not necessarily mean
recompiling code.
Once compiled This ...
class Foo implements Serviceable {
public void service(ServiceManager sm) {
}
}
Will work in any SM supporting container. Well with Phoenix it will
need a .xinfo entry and assembly. Merlin, ECM, Fortress require
different entries. EOB requires neither (but is not a standalone
container).
The meta-information in XML form is the difference, once compiled (and
QDox'd ... IF QDox'd ) the source is irrelvant. Thus doclet tages are
not the driver to container compatability, meta-information is. And
yes, I resist that too at this stage. JSR-111 is likely to explipse any
efforts here on meta information.
>> Containers use XML meta info, that is usually put in the same jar as
>> the class files.
>
>
> Wrong. XML is only one representation of info. It happens to be what
> Phoenix/Merlin uses. XML is not end all and be all, and packaging
> is of a secondary issue right now.
And doclet tags are? No, doclet tags are source. There is an object for
it whatever it is (XML, props like from commons-attributes).
Answer me this : Is it possible (_possible_) to make a component on the
final vision container without doclet tags?
>>> (a) tag based markup
>>> (b) a common meta-info model
>>
>>
>>
>> (c) no meta-model and no standard tag model (yet).
>>
>> There is no need for (b). Diversity is a good thing,
>> And (a), as I say, implies attribute support in Java.
>
>
> Paul, I disagree whole-heartedly with you. We are agreeing on standards
> that will be used in the containers we will be using. To denounce your
> claims:
>
> 1) "There is no need for (b)"
> It is for precisely this reason that components cannot work within
> all containers. There are no standards for letting the developer
> declare their meta-information. Therefore, no container can agree
> on how to represent it.
No components just need additional/alternative meta-information to get
them to work. The java code works quite well (A-F is our core art). I
would find it trivial to retrofit an xinfo file to some conp I found
elsewhere. You mean 'out of the box' they fail to work.
> 2) "Diversity is a good thing"
> Only when there are standards so that I do not have to duplicate
> work when migrating from container to container. Already
> attributes have greatly improved the productivity of the GUIApp
> project, and the ease of deploying several JARs and piecing
> together functionality of an application. If I don't have to
> alter all the tags every time I want to migrate to another
> container, then it increases my productivity more. It also
> *encourages* diversity because I am no longer locked into one
> container as is the case now.
You are not locked to a single container.
> 3) "(a) implies attribute support in Java"
> We can explore different options in packaging later. However, it
> is only a minor thing to repackage a JAR.
That's my point ?!
> Rewriting the way we
> represent meta information for each container has a much greater
> impact.
- Paul
--
http://www.thoughtworks.com : The art of heavy lifting.
Home for many Agile-practicing Open Source activists...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: DevWAv (was Re: Minimum Set of Tags (Revisited))
Posted by Berin Loritsch <bl...@apache.org>.
Paul Hammant wrote:
> Stephen,
>
>>> For me it's all hairsplitting and trying to solve it all in one go.
>>
>>
>
> I'm quite happy with Lowest Common Denominator (LCD ?) generally. The
> LCD in this case is Avalon-Framework's Java interfaces.
>
> I am going to suggest that this quest for doclet tags is completely
> abandoned.
We need a definition if we are going to allow users to not have to
change *several* files in their source code every time they have
to switch containers.
> Containers use XML meta info, that is usually put in the same jar as the
> class files.
Wrong. XML is only one representation of info. It happens to be what
Phoenix/Merlin uses. XML is not end all and be all, and packaging
is of a secondary issue right now.
>> Berin's view:
>>
>> It is the minimum set of tags that are required
>> to *define* a component and its role interfaces.
>>
>> The minimal set is not intended to provide any
>> information that is used for validation purposes.
>> There is no notion of signaling the container that
>> they cannot deploy the component.
>>
>> Conclusion - basic objective needs more discussion. If the objective
>> is to define a set of tags capable of supporting AF4 then this should
>> be stated. If the objective is to define a set of tags that are
>> restricted to the @phoenix @fortress subset then you have add all of
>> the implicit semantics introduced by Phoenix and Fortress. Maybe the
>> objective is just for Berin to figure out the tags structure and
>> semantics for @fortress - if so, that should be stated.
No. The objective is what I stated. You are adding more onto what
I am trying to solve. We can worry about validation later. Fortress
isn't doing validation, and it would be too much work to fit it in now.
ECM did not do validation. It wasn't a design requirement at this time.
We need something that will scale up from Fortress to Phoenix.
These tags are used by the packaging tool to generate the meta info
that the respective containers use.
>> 3. Possible Approaches
>> ----------------------
>>
>> (a) tag based markup
>> (b) a common meta-info model
>
>
> (c) no meta-model and no standard tag model (yet).
>
> There is no need for (b). Diversity is a good thing,
> And (a), as I say, implies attribute support in Java.
Paul, I disagree whole-heartedly with you. We are agreeing on standards
that will be used in the containers we will be using. To denounce your
claims:
1) "There is no need for (b)"
It is for precisely this reason that components cannot work within
all containers. There are no standards for letting the developer
declare their meta-information. Therefore, no container can agree
on how to represent it.
2) "Diversity is a good thing"
Only when there are standards so that I do not have to duplicate
work when migrating from container to container. Already
attributes have greatly improved the productivity of the GUIApp
project, and the ease of deploying several JARs and piecing
together functionality of an application. If I don't have to
alter all the tags every time I want to migrate to another
container, then it increases my productivity more. It also
*encourages* diversity because I am no longer locked into one
container as is the case now.
3) "(a) implies attribute support in Java"
We can explore different options in packaging later. However, it
is only a minor thing to repackage a JAR. Rewriting the way we
represent meta information for each container has a much greater
impact.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: DevWAv (was Re: Minimum Set of Tags (Revisited))
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote, On 09/04/2003 8.42:
> Stephen,
>
...
>> 3. Possible Approaches
>> ----------------------
>>
>> (a) tag based markup
>> (b) a common meta-info model
>
>
> (c) no meta-model and no standard tag model (yet).
Yup.
> There is no need for (b).
There is, but it has to be decided.
> Diversity is a good thing,
> And (a), as I say, implies attribute support in Java.
Nope.
> This is needless.
IMHO no. If Phoenix didn't use these tags, I would say too it's useless
till we decide upon it. But we want to have consistency between
container, and since Phoenix has them, it's good that consistency, where
feasable and possible, is acieved.
Now, as yuo say, we need a meta-model design to do a finished work. But
Phoenix uses them. So we should simply ATM IMHO follow suit and adapt
Fortress to be as similar as possible, using also *-x tags, and then
tackling the common metamodel later.
All this IMHO. That's why I think Stephen is pushing too much meat on
the table. We are not ready yet for a comprehensive Avalon metamodel.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: DevWAv (was Re: Minimum Set of Tags (Revisited))
Posted by Paul Hammant <Pa...@thoughtworks.net>.
Stephen,
>> For me it's all hairsplitting and trying to solve it all in one go.
>
> For me it is about identifying the problem your trying to solve before
> attempting to solve the problem. I happen to think that there is a
> fundamental flaw in the common denominator approach - you end with
> something that is not usable by anyone.
I'm quite happy with Lowest Common Denominator (LCD ?) generally. The
LCD in this case is Avalon-Framework's Java interfaces.
I am going to suggest that this quest for doclet tags is completely
abandoned.
> I see the following four things that are needed - and I have the
> impression that the focus is on (4) without resolution of (1), (2) or
> (3).
>
> 1. be clear about the objective
> 2. identify where your moving from
> 3. figure out the possible approaches
> 4. move to a solution
>
> 1. What is the objective:
> -------------------------
>
> My view:
>
> Definition of a set of tags that can be used
> independently of any container to provide the
> supplementary meta info needed for any container
> to either deploy the component, or signal an
> inability to deploy
Tags are not used by containers. Not unless the container is using
Commons-Attributes or the JSR-whatever thing that will be rolled into JDK1.5
Containers use XML meta info, that is usually put in the same jar as the
class files.
> Berin's view:
>
> It is the minimum set of tags that are required
> to *define* a component and its role interfaces.
>
> The minimal set is not intended to provide any
> information that is used for validation purposes.
> There is no notion of signaling the container that
> they cannot deploy the component.
>
> Conclusion - basic objective needs more discussion. If the objective
> is to define a set of tags capable of supporting AF4 then this should
> be stated. If the objective is to define a set of tags that are
> restricted to the @phoenix @fortress subset then you have add all of
> the implicit semantics introduced by Phoenix and Fortress. Maybe the
> objective is just for Berin to figure out the tags structure and
> semantics for @fortress - if so, that should be stated.
>
> 2. Where are we moving from:
> ----------------------------
>
> AF+ECM
> ------
> Components with AF+ECM semantics and without markup
> indicating the implicit ECM assumptions - these components
> will typically fail when used in non-ECM environments due
> to non-declaration of assumptions concerning selectors and
> lifestyle requirements.
Show me the user story + Caveat Emptor. The deployer takes some care
lacing together comps from different sources.
> AF+Phoenix
> ----------
> Components with AF+Phoenix semantics are less problematic
> because the Phoenix components include meta-info from which
> a container can adapt to address the assumed semantics such
> as BlockContext and implicit singleton lifestyle.
Yup, Phoenix deployers are away of those rules.
> 3. Possible Approaches
> ----------------------
>
> (a) tag based markup
> (b) a common meta-info model
(c) no meta-model and no standard tag model (yet).
There is no need for (b). Diversity is a good thing,
And (a), as I say, implies attribute support in Java.
This is needless. We should spend more time with the MX4J team trying
to prevent their project implementing a bespoke (possibly non)
componentized design.
- Paul
--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile-practicing, Open Source activists...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: DevWAv (was Re: Minimum Set of Tags (Revisited))
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
> For me it's all hairsplitting and trying to solve it all in one go.
For me it is about identifying the problem your trying to solve before
attempting to solve the problem. I happen to think that there is a
fundamental flaw in the common denominator approach - you end with
something that is not usable by anyone.
I see the following four things that are needed - and I have the
impression that the focus is on (4) without resolution of (1), (2) or (3).
1. be clear about the objective
2. identify where your moving from
3. figure out the possible approaches
4. move to a solution
1. What is the objective:
-------------------------
My view:
Definition of a set of tags that can be used
independently of any container to provide the
supplementary meta info needed for any container
to either deploy the component, or signal an
inability to deploy
Berin's view:
It is the minimum set of tags that are required
to *define* a component and its role interfaces.
The minimal set is not intended to provide any
information that is used for validation purposes.
There is no notion of signaling the container that
they cannot deploy the component.
Conclusion - basic objective needs more discussion. If the objective is
to define a set of tags capable of supporting AF4 then this should be
stated. If the objective is to define a set of tags that are restricted
to the @phoenix @fortress subset then you have add all of the implicit
semantics introduced by Phoenix and Fortress. Maybe the objective is
just for Berin to figure out the tags structure and semantics for
@fortress - if so, that should be stated.
2. Where are we moving from:
----------------------------
AF+ECM
------
Components with AF+ECM semantics and without markup
indicating the implicit ECM assumptions - these components
will typically fail when used in non-ECM environments due
to non-declaration of assumptions concerning selectors and
lifestyle requirements.
AF+Phoenix
----------
Components with AF+Phoenix semantics are less problematic
because the Phoenix components include meta-info from which
a container can adapt to address the assumed semantics such
as BlockContext and implicit singleton lifestyle.
AF+Type
-------
Components with AF+Type semantics include meta-info however
there are four context entries provided by Merlin that create
a potential for non-interoperability (home dir, temp dir, name,
and partition).
3. Possible Approaches
----------------------
(a) tag based markup
(b) a common meta-info model
Tag based markup is easier because in principal you can generate the
meta from the tags. In practice its not that simple because you cannot
just say "let's start with @phoenix because @phoenix carries with it
implicit assumptions (as described above). What you can do is start
with @phoenix plus declaration of the implicit assumptions which can be
achieved by declaring the Phoenix BlockContext assumptions (context type
and context entries) and singleton lifestyle. Another approach is to
start with ECM and construct a set of tags that make explicit what is
currently implicit - e.g. a tag on the Serviceable/Composable
implementation such as
@avalon.dependency type="whatever" semantics="ECM"
.. as opposed to:
@avalon.dependency type="whatever" key="my-key"
If we consider the above two statements - the first statement is simply
the declaration by a ECM style component that it is expecting semantics
over and above the AF4 contract. If we consider the second declaration
it is clear that an ECM/Fortress implementation would need to handle
mapping between "my-key" and "whatever".
Why - because we are talking about an @avalon scope and that means
digging into all of those nasty little details.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: DevWAv (was Re: Minimum Set of Tags (Revisited))
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote, On 08/04/2003 19.56:
...
>
> Really - take another look at the document.
He wrote it, man.
Stephen, I'm not understanding a single thing of what you are saying.
For me it's all hairsplitting and trying to solve it all in one go.
We can use avalon-x, and then discuss, and later decide we move it to
the proper namespace. Be patient. We are *not* deciding the
overcomprehensive component model that makes components completely
interoperable. Please leave that for later. Or continue on the thread as
Berin has suggested.
If you want to help, please also follow the flow, don't always stand in
its way. Or else the flow will find its way around you.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: DevWAv (was Re: Minimum Set of Tags (Revisited))
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>>
>> Disagree - "Developing with Avalon" describes ECM semantics. ECM
>> semantic are a superset of Avalon semantics. Avalon semantics are
>> defined in the Javadoc and the lifecycle specifications.
>>
>> Chers, Steve.
>>
>
> Disagree all you want--Developing with Avalon was written to document
> AF4.0 contracts. That was its intent.
>
> It also happens to document some ECM implementation details.
Berin:
Really - take another look at the document.
It a good document - but its an ECM document.
>
> If you disagree with anything written in there, let's put it out on
> the table as I suggested. Please use the appropriate thread so that
> the topics can stay on track.
>
What your asking for is unrealistic. It's like me taking the position
that every tutorial and example about Avalon included in the Merlin
product documentation is definitive Avalon - reality - it isn't. The
reason why is that Avalon contracts for containers are insufficiently
defined. It not a case of going the "Developing with Avalon" (a,k.a.
Developing with ECM) - it a case of building a complete and proper
container/component contract. We have three variations on this the
Phoenix/component, the ECM(Fortress)/component and the
Merlin/component. Of all of these the Merlin/component model is the
closest to the Avalon model (yes believe it or not).
Converging these distinct models can be achieved in a step by step
process. Resolving Fortress/Merlin differences mainly concern the
semantics of interpretation on component manager or service manager
lookups. In addition there is the general requirement for recognition
of lifestyle marker interfaces. With those two things in place we have
a complete transition scenario for ECM and Fortress component into a
neutral Avalon container environment. The focus of Merlin has been to
provide very good support for the A4 contracts. That exercise is
largely complete and the ECM semantics support is now in immediate
sights. It's one of the reasons why I'm being so stubborn about the
point concerning implicit semantics. If someone declares a ECM
component using @avalon xxx, and @avalon yyy, - this is only meaningful
if this can be used in multiple environments. Clearly, ECM and Fortress
environments imply more that the Avalon classic spec. This needs to be
turned into a declarative statement that I can recognize.
Today - I need to read in such a component and reject it because I know
that Merlin is not provided the semantics that are assumed. Tomorrow
that can change. But simply getting recognition of assumptions is the
fundamental framework to getting interoperability and supporting migration.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org