You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2002/06/30 15:48:01 UTC
organisation of avalon subprojects
all,
we have had the discussions of how to organize the avalon code before,
and it came up again in recent discussions. The important thing
mentioned recently was some input by newbies -- they find the
organisation pretty difficult to understand.
looking at the parts of which avalon consists, and not looking at their
current names, I'd say it *should* be possible to split avalon into the
same basic parts you find in most software:
1 - specification
2 - implementation
3 - extension specification(s)
4 - extension implementation(s)
5 - utility
6 - non-normative documentation
7 - external
8 - examples
9 - client software
10 - sandbox
roughly, the current subprojects fit as follows:
framework == 1 + part of 2 + 6 + 7 + part of 10
excalibur == part of 2 + part of 3 + part of 4 + part of 5* +
part of 10
logkit == part of 5
phoenix == part of 2 + part of 3 + part of 4
cornerstone == part of 3 + part of 4
apps == 8 + 9
(* -> largely moving to jakarta-commons)
where a better subproject organisation would be something like the
following:
framework == 1
excalibur == 2
container == 3(a), 3(b)
fortress == 4(a)
phoenix == 4(a), 4(b)
utility == 5 + 7
site == 6
apps == 8 + 9
sandbox == 10
with the explicit goal to have next to nothing in "utility" (as that
stuff is usually of more general use). That would also make it a goal to
move logkit out into a separate place.
I'm not saying this is what we should do (just throwing the current
organisation completely overboard would be somewhat stupid; and then
there's jakarta politics), would just like to hear from y'all whether we
are somewhat in agreement of where we would like to be in a perfect
world.
I'm also not saying this organisation should also dictate CVS setup
(though I do think it should, I'd like to keep that a separate
discussion).
That makes it easier to figure out what to do in an imperfect world.
grz,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: organisation of avalon subprojects
Posted by Peter Donald <pe...@apache.org>.
On Mon, 1 Jul 2002 01:00, Pete Carapetyan wrote:
> In a perfect (simple dumb) world, if would be easiest for me if there was
> 1 - framework
> 2 - one container implementing the framework that would work with any
> component
> 3 - components - working, non working, dependent on others or not, or
> any combination of otherwise.
> 4 - one set of documentation for framework, container, and generic
> component
> 5 - one doc for each component - stored with that component in exactly
> same place, way, and format.
> Goes without saying that this is an intentionally stupid - as in too
> oversimplified - approach. But the closer you could get to it, the
> simpler, dumber avalon would be.
Actually in an ideal world thats exactly what I would like it to look like.
--
Cheers,
Peter Donald
Doubt is not a pleasant condition, but certainty is absurd.
-- Voltaire
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: organisation of avalon subprojects
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
Leo's analysis is dead on the money.
Leo's suggestions for improvements would be a dramatic improvement.
Here are mine, an even simpler version of what Leo has offered.
In a perfect (simple dumb) world, if would be easiest for me if there was
1 - framework
2 - one container implementing the framework that would work with any
component
3 - components - working, non working, dependent on others or not, or
any combination of otherwise.
4 - one set of documentation for framework, container, and generic
component
5 - one doc for each component - stored with that component in exactly
same place, way, and format.
Goes without saying that this is an intentionally stupid - as in too
oversimplified - approach. But the closer you could get to it, the
simpler, dumber avalon would be.
Leo's comments left in entirety below without further comments:
Leo Simons wrote:
>all,
>
>we have had the discussions of how to organize the avalon code before,
>and it came up again in recent discussions. The important thing
>mentioned recently was some input by newbies -- they find the
>organisation pretty difficult to understand.
>
>looking at the parts of which avalon consists, and not looking at their
>current names, I'd say it *should* be possible to split avalon into the
>same basic parts you find in most software:
>
>1 - specification
>2 - implementation
>3 - extension specification(s)
>4 - extension implementation(s)
>5 - utility
>6 - non-normative documentation
>7 - external
>8 - examples
>9 - client software
>10 - sandbox
>
>roughly, the current subprojects fit as follows:
>
>framework == 1 + part of 2 + 6 + 7 + part of 10
>excalibur == part of 2 + part of 3 + part of 4 + part of 5* +
> part of 10
>logkit == part of 5
>phoenix == part of 2 + part of 3 + part of 4
>cornerstone == part of 3 + part of 4
>apps == 8 + 9
>
>(* -> largely moving to jakarta-commons)
>
>where a better subproject organisation would be something like the
>following:
>
>framework == 1
>excalibur == 2
>container == 3(a), 3(b)
>fortress == 4(a)
>phoenix == 4(a), 4(b)
>utility == 5 + 7
>site == 6
>apps == 8 + 9
>sandbox == 10
>
>with the explicit goal to have next to nothing in "utility" (as that
>stuff is usually of more general use). That would also make it a goal to
>move logkit out into a separate place.
>
>I'm not saying this is what we should do (just throwing the current
>organisation completely overboard would be somewhat stupid; and then
>there's jakarta politics), would just like to hear from y'all whether we
>are somewhat in agreement of where we would like to be in a perfect
>world.
>
>I'm also not saying this organisation should also dictate CVS setup
>(though I do think it should, I'd like to keep that a separate
>discussion).
>
>That makes it easier to figure out what to do in an imperfect world.
>
>grz,
>
>- Leo
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: organisation of avalon subprojects
Posted by Stephen McConnell <mc...@osm.net>.
Leo Simons wrote:
>all,
>
>we have had the discussions of how to organize the avalon code before,
>and it came up again in recent discussions. The important thing
>mentioned recently was some input by newbies -- they find the
>organisation pretty difficult to understand.
>
>
Agreed.
>looking at the parts of which avalon consists, and not looking at their
>current names, I'd say it *should* be possible to split avalon into the
>same basic parts you find in most software:
>
>1 - specification
>2 - implementation
>3 - extension specification(s)
>4 - extension implementation(s)
>5 - utility
>6 - non-normative documentation
>7 - external
>8 - examples
>9 - client software
>10 - sandbox
>
>roughly, the current subprojects fit as follows:
>
>framework == 1 + part of 2 + 6 + 7 + part of 10
>
That makes sense.
>excalibur == part of 2 + part of 3 + part of 4 + part of 5* +
> part of 10
>
What sort of mix do you have in mind here ?
>logkit == part of 5
>
Yep.
>phoenix == part of 2 + part of 3 + part of 4
>
Yep.
>cornerstone == part of 3 + part of 4
>
Yep.
>apps == 8 + 9
>
>(* -> largely moving to jakarta-commons)
>
>where a better subproject organisation would be something like the
>following:
>
>framework == 1
>excalibur == 2
>container == 3(a), 3(b)
>fortress == 4(a)
>phoenix == 4(a), 4(b)
>utility == 5 + 7
>site == 6
>apps == 8 + 9
>sandbox == 10
>
I would really like to see the death of the container seperation - its
way too early to be brainding anything in the container area just yet.
Phoenix I think will survive as a brand but will be restructured.
Merlin is going throiugh the same process of restructuring but probably
more radical at this point in time. What is important is that we
seperate out container framework content, container services, and
container tools and that should be the defintion of a container.
Merlin, Fortress and antything else calling itself a containing has to
evolve and leverage that platform (or die).
>
>with the explicit goal to have next to nothing in "utility" (as that
>stuff is usually of more general use). That would also make it a goal to
>move logkit out into a separate place.
>
>I'm not saying this is what we should do (just throwing the current
>organisation completely overboard would be somewhat stupid; and then
>there's jakarta politics), would just like to hear from y'all whether we
>are somewhat in agreement of where we would like to be in a perfect
>world.
>
I'm in agreement about the restructed view. As you have noted below I
don't see this as a CVS structural thing any time soon. But if we
simply look at the logical breakdown of what is Avalon - I think you
have outlined an breakdown that makes a lot of sense.
Cheers, Steve.
>I'm also not saying this organisation should also dictate CVS setup
>(though I do think it should, I'd like to keep that a separate
>discussion).
>
>That makes it easier to figure out what to do in an imperfect world.
>
>grz,
>
>- 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>
Avalon Components from an outsider's view
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
The primary confusion about Avalon components from the outsider's view
is context, not whether they belong in Avalon or not.
-Does this mean I have to use Avalon containers?
-Which container or containers is required ?
-What other dependencies will I run up against? - other components,
other jars etc.
-Where on the tree of Avalon complexity is this component from easy to
hard ?
-How many minutes of a committment would that take ? 20 minutes ? 5 days
with debugging? How much?
This could actually be presented in a table, for that matter. Kind of
like consumer's reports rates products.
If the casual passerby could answer these questions before or while he
reviewed the list of components, the list would be more meaningful. If
these were unknowns, the impulse to run away fast would be just as great
as the impulse to run away fast that I get when I go to sourceforge and
do a search on a blah + java and come up with a 6 page list. Argh. Run
away fast.
The Avalon brand is supposed to be software engineering, which by
definition conotes an easier, more bolt up approach. So don't make the
guy guess at how many trips to the hardware store it is going to take to
get all the bolts, not if we are looking to gain more users.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: organisation of avalon subprojects
Posted by Stephen McConnell <mc...@osm.net>.
Paul Hammant wrote:
> Pete,
>
>>> I am -10 on chainsaw-grade reduction.
>>
>>
>>
>> To be fair, there is a lot of very high grade emotional investment in
>> Avalon by all committers. Paul, you make the above outline, and then
>> say that you are against the chainsaw-grade reduction. But to another
>> viewer, the very outline you proposed is a such a chainsaw approach,
>> it just didn't seem like a chain saw to you.
>
>
> No, I think that the naming suggestions proposed are the solution.
> That with improved xdocs. I don't want to trim any projects from our
> CVS or rename any CVS entities. That is, unless they have garnered a
> larger community, and need self-suffciency. If CVS is hacked to bits
> and no work is done of the xdocs, then we weill be no nearer having a
> clear message for newbies in six months.
> Naming/branding/documentation is our issue not packaging/directories.
+1
--
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: organisation of avalon subprojects
Posted by Paul Hammant <Pa...@yahoo.com>.
Pete,
>> I am -10 on chainsaw-grade reduction.
>
>
> To be fair, there is a lot of very high grade emotional investment in
> Avalon by all committers. Paul, you make the above outline, and then
> say that you are against the chainsaw-grade reduction. But to another
> viewer, the very outline you proposed is a such a chainsaw approach,
> it just didn't seem like a chain saw to you.
No, I think that the naming suggestions proposed are the solution. That
with improved xdocs. I don't want to trim any projects from our CVS or
rename any CVS entities. That is, unless they have garnered a larger
community, and need self-suffciency. If CVS is hacked to bits and no
work is done of the xdocs, then we weill be no nearer having a clear
message for newbies in six months. Naming/branding/documentation is our
issue not packaging/directories.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: organisation of avalon subprojects
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
Paul Hammant wrote:
> <snip/>
> - Avalon Framework
> - Avalon Containers (codename excalibur)
> - educational (codename tweety)
> - micro (codename micro)
> - basic (codename fortress)
> - server (codename phoenix)
> - Avalon Services (codename cornerstone)
>
> I am -10 on chainsaw-grade reduction.
To be fair, there is a lot of very high grade emotional investment in
Avalon by all committers. Paul, you make the above outline, and then say
that you are against the chainsaw-grade reduction. But to another
viewer, the very outline you proposed is a such a chainsaw approach, it
just didn't seem like a chain saw to you.
So in a nice kind of way, some of what is being discussed is differences
in semantics and how emotionally loaded certain approaches are. Doesn't
seem that the actual differences are all that great..
And the components are very significant, no matter where they go. After
all, none of that stuff just showed up, it is all represents a big
investment by the authors. That is no small thing.
Whether the components go to the commons or go to the Avalon Component
commons, either is peachy, because either is very easy to understand and
digest by the casual person passing by attempting to get a handle on it.
What is important probably has more to do with the chapter titles and
organization than the contents of the pages in the book.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: organisation of avalon subprojects
Posted by Stephen McConnell <mc...@osm.net>.
Nicola Ken Barozzi wrote:
>
> Paul Hammant wrote:
>
>> Leo,
>>
>> Our principal problem is that we use the term 'Avalon' to represent a
>> lot of thing, bit how many app are hosted under the avalon/
>> conceptual directory. Fixing the organisation of sub-projects is not
>> the solution, correct usage by us of terms is. Moving sub-projects to
>> SourceForge (where else can a project with two or one occasional
>> committer go?) will not solve our central brand issue. I like the
>> proposal by PeterC, Nicola Ken and Kasper at the end of the '[Vote]
>> User requirements for A5' thread :
>>
>> - Avalon Framework
>> - Avalon Containers (codename excalibur)
>> - educational (codename tweety)
>> - micro (codename micro)
>> - basic (codename fortress)
>> - server (codename phoenix)
>> - Avalon Services (codename cornerstone)
>
>
> IIUC, the above scheme is exactly what Leo advocates, ie "In short, I
> want Avalon to be: Framework + Three Containers + Component
> Directory", so there seems to be agreement here :-)
You wish!
--
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: organisation of avalon subprojects
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote:
> Leo,
>
> Our principal problem is that we use the term 'Avalon' to represent a
> lot of thing, bit how many app are hosted under the avalon/ conceptual
> directory. Fixing the organisation of sub-projects is not the solution,
> correct usage by us of terms is. Moving sub-projects to SourceForge
> (where else can a project with two or one occasional committer go?) will
> not solve our central brand issue. I like the proposal by PeterC,
> Nicola Ken and Kasper at the end of the '[Vote] User requirements for
> A5' thread :
>
> - Avalon Framework
> - Avalon Containers (codename excalibur)
> - educational (codename tweety)
> - micro (codename micro)
> - basic (codename fortress)
> - server (codename phoenix)
> - Avalon Services (codename cornerstone)
IIUC, the above scheme is exactly what Leo advocates, ie "In short, I
want Avalon to be: Framework + Three Containers + Component Directory",
so there seems to be agreement here :-)
> I am -10 on chainsaw-grade reduction. To say the least, it will reduce
> my commitments to Avalon.
This is a reorganization, not a cheap sell.
If we move utilities to Commons, the above stuff is what we will remain
with.
--
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: organisation of avalon subprojects
Posted by Paul Hammant <Pa...@yahoo.com>.
Leo,
Our principal problem is that we use the term 'Avalon' to represent a
lot of thing, bit how many app are hosted under the avalon/ conceptual
directory. Fixing the organisation of sub-projects is not the solution,
correct usage by us of terms is. Moving sub-projects to SourceForge
(where else can a project with two or one occasional committer go?) will
not solve our central brand issue. I like the proposal by PeterC,
Nicola Ken and Kasper at the end of the '[Vote] User requirements for
A5' thread :
- Avalon Framework
- Avalon Containers (codename excalibur)
- educational (codename tweety)
- micro (codename micro)
- basic (codename fortress)
- server (codename phoenix)
- Avalon Services (codename cornerstone)
I am -10 on chainsaw-grade reduction. To say the least, it will reduce
my commitments to Avalon.
- Paul
> The tendency is to start a subproject (Avalon) and then another
> subproject under that (Excalibur) and then projects under that
> (MicroContainer) and so on. I could devote some hundred lines to this
> and the reasons for the process, but that's neither here nor there...
>
> Anyway, the result is that the scope of the Avalon project has grown
> immensely - it is not just a framework, it is a replacement for RMI
> (AltRMI). It is a Database (AvalonDB). In no way do I want to
> criticise these projects, but do they really belong under the Avalon
> umbrella? Are they really not projects at the same level as Avalon itself?
>
> Another issue with this is that doing this walls us off from the rest
> of Jakarta. Avalon becomes a Jakarta in scope - self-sufficient in
> itself and utterly isolated. I want to see Phoenix-based apps on the
> front Jakarta page. That's the only way to spread Avalon through Jakarta.
>
> As Pete C says, I think we should slim the Avalon project
> *significantly*. And now I am talking about some chainsaw-grade reduction.
>
> With MicroContainer a new possibility has emerged: All Avalon
> components previously in Excalibur can move to Commons. I am currently
> thinking through what restrictions MicroContainer puts on the
> components it manages, but it appears to be quite few. I have already
> made DataSource work, and I think I can do the same for just about any
> component in Excalibur.
>
> MicroContainer would work with Avalon/Apps, but it seems a bit silly
> and palindromic to provide a non-Avalon wrapper for a wrapper for
> non-Avalon applications...
>
> So I see:
>
> 1. framework
> Avalon Framework interfaces and reference implementation.
>
> 2. containers
> 2a. common container code (metainfo, etc.)
> 2b. microcontainer
> 2c. fortress
> 2d. phoenix
> Again, this is my 3-container approach.
>
> 3. component directory
> This is a list of components that work with Avalon containers. This is
> basically Apps + Excalibur + all components in Commons that we export
> from Excalibur with MicroContainer. The actual components are *not*
> stored here unless they are wrappers for non-avalon components (like
> some of the current Apps). It is basically a list of "this is the
> stuff you can put in your container.
>
> 4. site
> 5. sandbox
>
> The 4 and 5 is basically just for developers. So a newbie user comes
> in and sees this:
>
> 1. Get the framework.
> 2. Check the list of containers (all 3 of them). Pick one that suits
> your needs.
> 3. Pick all the stuff you want to put in your container.
> 4. Good to go!
>
> Like Pete, I'd prefer just one container. But given the different
> requirements for containers I don't think "one single container" will
> work. I do think that all containers will be able to run all
> components, but the way they are managed and the grade of committment
> to Avalon architecture differs - and I do not see how that can be avoided.
>
> Maybe we can provide some three-point checklist for the containers.
> Like (I'm sure we can argue over the list below. I'm only quite
> certain about MicroContainer and its "upper limit" against Fortress.
> As for the upper limit of Fortress, I'm a bit unsure.):
>
> MicroContainer
> + You are primarily interested in using one or two Avalon components
> in another architecture.
> + You are not interested in the Avalon architecture and would like to
> know as little as possible about it.
> + Basically: Just give me the darn component!
>
> Fortress
> + You are considering using Avalon for part or all of your application.
> + Your application is not a stand-alone server or server application.
> + Basically: You are writing a servlet.
>
> Phoenix
> + You are considering using Avalon for a stand-alone server.
> + Basically: You are writing an entire server.
>
> Maybe even a checklist. Check all checkboxes, click on submit, and
> we'll tell you what container you want. :)
>
> Other points:
> + Logkit out of Avalon and to top-level or Commons.
> + Testlet DIE DIE DIE kill it already for the love of God.
> + Excalibur/Event (SEDA/SILK) to Framework or sandbox.
> + Excalibur/Command (SEDA/SILK???) to Framework or sandbox.
> + AltRMI to top-level within Jakarta
> + Rest of Excalibur minus Fortress and MicroContainer to
> Jakarta-Commons.
> + Concurrent to Commons (already done?) or ditch in favour of
> util.concurrent:
> http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
>
>
> In short, I want Avalon to be: Framework + Three Containers +
> Component Directory
>
> And nothing more.No Utility package (put it in framework if it is for
> users, in containers-common if it is for container writers (2a on my
> list above), or ship it off to Commons if neither).
>
> That's my perfect world.
>
> And that's all I have to say about that.
>
> /LS
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: organisation of avalon subprojects
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
...
>>Another issue with this is that doing this walls us off from the rest of
>>Jakarta. Avalon becomes a Jakarta in scope - self-sufficient in itself and
>>utterly isolated. I want to see Phoenix-based apps on the front Jakarta
>>page. That's the only way to spread Avalon through Jakarta.
>
> another one is to get existing projects adopt avalon.
IMHO these will not solve the ivory-tower problem, because Avalon has
never been a technical issue in Jakarta, only a political one.
You can bring a horse to water, but you can't make him drink.
> Agree though.
> Problem: jakarta itself hasn't really got a use for "phoenix-based
> apps", just for active communities (to support a piece of software).
> AvalonDB or AltRMI (or ...., or ....) is *not* ready for 'top-level'.
Which means IMHO that they are suited to a kind of "sandbox".
>>As Pete C says, I think we should slim the Avalon project *significantly*.
>>And now I am talking about some chainsaw-grade reduction.
>
> I think any radical approach is bad. As I said before: evolution instead
> of revolution is what we need right now.
I think that you two mean the same thing ;-)
it would be an evolution from the code perspective, but a revolution as
project organization, community and communication.
>>With MicroContainer a new possibility has emerged: All Avalon components
>>previously in Excalibur can move to Commons.
>
> cool; but do all of them fill all the commons requirments? (moving them
> there would, fa, mean no support from me on them as I have no time to
> involve myself in commons)
? I don't see the problem of having the code in another repository, does
it really matter that much where utility code is?
Anyway, "All Avalon components previously in Excalibur" is a bit drastic
;-) , let's do it gradually.
> IOW: there's a theoretical possibility. That is what you ment, no?
>
>
>>So I see:
>>
>>1. framework
>>Avalon Framework interfaces and reference implementation.
>
> I personally feel RI should be separate from impl, as if you can have
> multiple impls, people that have a say about spec should not have to
> concern themselves with the RI.
+1 The containers *are* our RIs.
>>2. containers
>>2a. common container code (metainfo, etc.)
>>2b. microcontainer
>>2c. fortress
>>2d. phoenix
>>Again, this is my 3-container approach.
>
>
> if a specification were to state a RI would have to provide a way for a
> component built to the specification to be run etc, a container would in
> fact be an RI.
ok, now you say it too, cool :-)
> analogy: we have the servlet spec, a servlet RI should provide a way to
> run any app conforming to the servlet spec.
>
>
>>3. component directory
>>This is a list of components that work with Avalon containers. This is
>>basically Apps + Excalibur + all components in Commons that we export from
>>Excalibur with MicroContainer. The actual components are *not* stored here
>>unless they are wrappers for non-avalon components (like some of the
>>current Apps). It is basically a list of "this is the stuff you can put in
>>your container.
>
> I like, partially. Separation between reusable components on micro level
> (threadutils) and macro level (hsql) is nice.
Reusable components in Commons instead of Avalon is what I like best of
this.
>>4. site
>>5. sandbox
>>
>>The 4 and 5 is basically just for developers.
>
> hmm. "site" would contain docs, which target users too. Feel I miss the
> point?
>
>
>>So a newbie user comes in and
>>sees this:
>>
>>1. Get the framework.
>>2. Check the list of containers (all 3 of them). Pick one that suits your
>>needs.
>>3. Pick all the stuff you want to put in your container.
>>4. Good to go!
>
>
> I like this one:
>
> 1. get development kit (with kitchen sink and microwave)
> 2. go!
> 3. read some docs
> 4. add own stuff
> 5. remove example stuff
> 6. go!
> 7. read more docs
> 8. modify own stuff
> 9. go!
> 10. run distribution "wizard"
> 11. go!
>
> as the approach for newbies.
:-)
>>Like Pete, I'd prefer just one container. But given the different
>>requirements for containers I don't think "one single container" will work.
>>I do think that all containers will be able to run all components, but the
>>way they are managed and the grade of committment to Avalon architecture
>>differs - and I do not see how that can be avoided.
>
> +1
+1 Once they said that users needed only on Java... ;-)
>>Maybe we can provide some three-point checklist for the containers.
>
> +1, put in a disclaimer ("this is informative and not completely correct
> or agreed upon", or whatever) and put it in xdoc, I say.
>
>>Maybe even a checklist. Check all checkboxes, click on submit, and we'll
>>tell you what container you want. :)
>
> +1
>
>
>>Other points:
>> + Logkit out of Avalon and to top-level or Commons.
>
> will never happen =(
> politics.
I disagree ;-)
Never say never ;-)
>> + Testlet DIE DIE DIE kill it already for the love of God.
>
> I'd say propose a vote
+1
>> + Excalibur/Event (SEDA/SILK) to Framework or sandbox.
>
> sandbox
+1
>> + Excalibur/Command (SEDA/SILK???) to Framework or sandbox.
>
> sandbox
+1
>> + AltRMI to top-level within Jakarta
>
> not ready, so sandbox
+1
>> + Rest of Excalibur minus Fortress and MicroContainer to Jakarta-Commons.
>
> have reservations.
Let's decide package per package, as we are doing now.
>> + Concurrent to Commons (already done?) or ditch in favour of
>>util.concurrent:
>>http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
>
>
> ?
>
> why mix this up into the discussion? What is (yep, being lazy)
0 Kelvin (doh)
>>In short, I want Avalon to be: Framework + Three Containers + Component
>>Directory
>>
>>And nothing more.
>
>
> hmm.
>
> I want Avalon to be: Specification + Implementation + Component
> Directory + Development Kit + Nurturing place for avalon-based stuff.
Whic means that you agree, since the sandbox is implicitly needed and
Dev kits are implicitly needed for each container :-)
--
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: organisation of avalon subprojects
Posted by Leo Simons <le...@apache.org>.
> Anyway, the result is that the scope of the Avalon project has grown
> immensely - it is not just a framework, it is a replacement for RMI
> (AltRMI). It is a Database (AvalonDB). In no way do I want to criticise
> these projects, but do they really belong under the Avalon umbrella? Are
> they really not projects at the same level as Avalon itself?
'level' is a broad term. In terms of user and committer base, nope.
Which is why they are not at the jakarta level.
> Another issue with this is that doing this walls us off from the rest of
> Jakarta. Avalon becomes a Jakarta in scope - self-sufficient in itself and
> utterly isolated. I want to see Phoenix-based apps on the front Jakarta
> page. That's the only way to spread Avalon through Jakarta.
another one is to get existing projects adopt avalon. Agree though.
Problem: jakarta itself hasn't really got a use for "phoenix-based
apps", just for active communities (to support a piece of software).
AvalonDB or AltRMI (or ...., or ....) is *not* ready for 'top-level'.
> As Pete C says, I think we should slim the Avalon project *significantly*.
> And now I am talking about some chainsaw-grade reduction.
I think any radical approach is bad. As I said before: evolution instead
of revolution is what we need right now.
> With MicroContainer a new possibility has emerged: All Avalon components
> previously in Excalibur can move to Commons.
cool; but do all of them fill all the commons requirments? (moving them
there would, fa, mean no support from me on them as I have no time to
involve myself in commons)
IOW: there's a theoretical possibility. That is what you ment, no?
> So I see:
>
> 1. framework
> Avalon Framework interfaces and reference implementation.
I personally feel RI should be separate from impl, as if you can have
multiple impls, people that have a say about spec should not have to
concern themselves with the RI.
> 2. containers
> 2a. common container code (metainfo, etc.)
> 2b. microcontainer
> 2c. fortress
> 2d. phoenix
> Again, this is my 3-container approach.
if a specification were to state a RI would have to provide a way for a
component built to the specification to be run etc, a container would in
fact be an RI.
analogy: we have the servlet spec, a servlet RI should provide a way to
run any app conforming to the servlet spec.
> 3. component directory
> This is a list of components that work with Avalon containers. This is
> basically Apps + Excalibur + all components in Commons that we export from
> Excalibur with MicroContainer. The actual components are *not* stored here
> unless they are wrappers for non-avalon components (like some of the
> current Apps). It is basically a list of "this is the stuff you can put in
> your container.
I like, partially. Separation between reusable components on micro level
(threadutils) and macro level (hsql) is nice.
> 4. site
> 5. sandbox
>
> The 4 and 5 is basically just for developers.
hmm. "site" would contain docs, which target users too. Feel I miss the
point?
> So a newbie user comes in and
> sees this:
>
> 1. Get the framework.
> 2. Check the list of containers (all 3 of them). Pick one that suits your
> needs.
> 3. Pick all the stuff you want to put in your container.
> 4. Good to go!
I like this one:
1. get development kit (with kitchen sink and microwave)
2. go!
3. read some docs
4. add own stuff
5. remove example stuff
6. go!
7. read more docs
8. modify own stuff
9. go!
10. run distribution "wizard"
11. go!
as the approach for newbies.
> Like Pete, I'd prefer just one container. But given the different
> requirements for containers I don't think "one single container" will work.
> I do think that all containers will be able to run all components, but the
> way they are managed and the grade of committment to Avalon architecture
> differs - and I do not see how that can be avoided.
+1
> Maybe we can provide some three-point checklist for the containers.
+1, put in a disclaimer ("this is informative and not completely correct
or agreed upon", or whatever) and put it in xdoc, I say.
> Maybe even a checklist. Check all checkboxes, click on submit, and we'll
> tell you what container you want. :)
+1
> Other points:
> + Logkit out of Avalon and to top-level or Commons.
will never happen =(
politics.
> + Testlet DIE DIE DIE kill it already for the love of God.
I'd say propose a vote
> + Excalibur/Event (SEDA/SILK) to Framework or sandbox.
sandbox
> + Excalibur/Command (SEDA/SILK???) to Framework or sandbox.
sandbox
> + AltRMI to top-level within Jakarta
not ready, so sandbox
> + Rest of Excalibur minus Fortress and MicroContainer to Jakarta-Commons.
have reservations.
> + Concurrent to Commons (already done?) or ditch in favour of
> util.concurrent:
> http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
?
why mix this up into the discussion? What is (yep, being lazy)
> In short, I want Avalon to be: Framework + Three Containers + Component
> Directory
>
> And nothing more.
hmm.
I want Avalon to be: Specification + Implementation + Component
Directory + Development Kit + Nurturing place for avalon-based stuff.
> And that's all I have to say about that.
but you never know what you're gonna get (in the end).
- LSD
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: organisation of avalon subprojects
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Sutic wrote:
>
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>
>>The idea is that MicroCont will run only the simplest components, and
>>*must* avoid duplicating definitions-semantics.
>>It should not propagate informal component model, and I think
>>that Leo
>>Sutic agrees with this.
>>If you need more, get the next-level container.
>
>
> No. The idea is this:
>
> MicroContainer should allow Avalon components
> to be used without any committment to Avalon architecture.
> That is, realize the "no strings attached" goal.
It's a nonsense, if you use Avalon components you *are* committing to
the Avalon architecture ;-)
But I understand the meaning :-)
> It should also be extremely easy to use, follow Java idioms whenever
> possible, etc. I wanted to enable people to use Avalon components in the
> same way as they use standard Java classes.
Ok, this is more clear :-)
> The "upper limit" in functionality for MicroContainer is therefore
> defined in terms of the degree of committment to a particular
> architecture by the user. I draw the line at requiring XML config files
> and assembly descriptors. If you can not get your component via a static
> factory method, without having to specify any config files, then it is
> not part of MicroContainer's scope.
Ok, cool :-)
> That it would only run the simplest components was something of an
> implication, and not a goal in itself.
Ok, understand.
> After looking at Merlin, I think MicroContainer's goal can be realized
> better via it.
>
> Fortress and Phoenix are very powerful, but are absolute nightmares to
> start up. You need assembly files, config files etc. etc. All of that,
> to run a single simple component. This is how you obtain a
> DataSourceComponent in MicroContainer:
>
> DataSourceComponent ds = DataSourceFactory.getDataSource(
> driver, // JDBC Driver
> dbUrl, // Database URL
> userName, // user name
> password, // user's password
> null, // Connection keep-alive command (none)
> 1, // Minimum number of connections in pool.
> 3, // Maximum number of connections in pool.
> -1, // Connection timeout (disabled)
> true, // Auto commit
> false, // Using oracle
> null); // Override name of connection class (null ==
> use default).
>
> What you get back is a proxy that will dispose the component properly
> when GC'd, that can work as a factory to enable you to handle components
> with dependencies, and so on. No need to specify config files. Nothing
> of that. Just call your factory method just like you are used to do to
> obtain a SAX parser and MicroContainer will take care of the rest for
> you.
>
> If something like this can be realized via Merlin, then that's better.
:-)
> And just one final statement: MicroContainer handles dependencies. It
> just does not assemble anything automatically. You handle dependencies
> by connecting several MicroContainer instances, instead of, like Merlin,
> load all dependencies into one container.
ok :-)
--
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: organisation of avalon subprojects
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> The idea is that MicroCont will run only the simplest components, and
> *must* avoid duplicating definitions-semantics.
> It should not propagate informal component model, and I think
> that Leo
> Sutic agrees with this.
> If you need more, get the next-level container.
No. The idea is this:
MicroContainer should allow Avalon components
to be used without any committment to Avalon architecture.
That is, realize the "no strings attached" goal.
It should also be extremely easy to use, follow Java idioms whenever
possible, etc. I wanted to enable people to use Avalon components in the
same way as they use standard Java classes.
The "upper limit" in functionality for MicroContainer is therefore
defined in terms of the degree of committment to a particular
architecture by the user. I draw the line at requiring XML config files
and assembly descriptors. If you can not get your component via a static
factory method, without having to specify any config files, then it is
not part of MicroContainer's scope.
That it would only run the simplest components was something of an
implication, and not a goal in itself.
After looking at Merlin, I think MicroContainer's goal can be realized
better via it.
Fortress and Phoenix are very powerful, but are absolute nightmares to
start up. You need assembly files, config files etc. etc. All of that,
to run a single simple component. This is how you obtain a
DataSourceComponent in MicroContainer:
DataSourceComponent ds = DataSourceFactory.getDataSource(
driver, // JDBC Driver
dbUrl, // Database URL
userName, // user name
password, // user's password
null, // Connection keep-alive command (none)
1, // Minimum number of connections in pool.
3, // Maximum number of connections in pool.
-1, // Connection timeout (disabled)
true, // Auto commit
false, // Using oracle
null); // Override name of connection class (null ==
use default).
What you get back is a proxy that will dispose the component properly
when GC'd, that can work as a factory to enable you to handle components
with dependencies, and so on. No need to specify config files. Nothing
of that. Just call your factory method just like you are used to do to
obtain a SAX parser and MicroContainer will take care of the rest for
you.
If something like this can be realized via Merlin, then that's better.
And just one final statement: MicroContainer handles dependencies. It
just does not assemble anything automatically. You handle dependencies
by connecting several MicroContainer instances, instead of, like Merlin,
load all dependencies into one container.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: organisation of avalon subprojects
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote:
>
> Leo Sutic wrote:
...
>> As Pete C says, I think we should slim the Avalon project
>> *significantly*. And now I am talking about some chainsaw-grade
>> reduction.
>
> Put away the chainsaw and think instead about the words
> "consolidation".
+1 It's a matter of terms ;-)
> Go back to MicroContainer and rip out the lifecycle
> processing code - put in place something from a common codebase - reduce
> the duplication. Phoenix has already done this, Merlin is
> transitioning, if you do it you reduce unnecessary code - that
> simplifies things - lots of little actions like that will have a big
> impact. The second and really important thing to consider is community
> growth. If you take a look at
> http://home.osm.net/technical/avalon/trends.html you will see that the
> Avalon project is steadily building. With the resolution of reusable
> components I'm very confident that we will see significant jump in
> growth - because all of a sudden you will see components that are
> formally complete and consistent and that means reuse and that means
> value an value means attention and attention means commercially
> interesting. But we are not there yet - its still in the nurturing phase.
>
>>
>> With MicroContainer a new possibility has emerged: All Avalon
>> components previously in Excalibur can move to Commons. I am currently
>> thinking through what restrictions MicroContainer puts on the
>> components it manages, but it appears to be quite few.
>
> Providing we limit ourselves to non-meta based components. Sorry Leo,
> but MicroContainer will not run ANY of my components - NONE. For the
> sort of things I'm doing it is only valid for the simplest type of
> component. I'm not complaining about the work you have done - but its
> way too focussed on the the ECM style/pattern of component usage to be
> usafull in a general context - and that is the big concern - you end up
> propagating the informal component model - and the proliferation of
> components that will not work across other containers. That's the
> important thing right now - eliminating those "semantics" gray areas -
> getting this stuff really solid so that users can use the tool that best
> matches the task.
The idea is that MicroCont will run only the simplest components, and
*must* avoid duplicating definitions-semantics.
It should not propagate informal component model, and I think that Leo
Sutic agrees with this.
If you need more, get the next-level container.
>> I have already made DataSource work, and I think I can do the same for
>> just about any component in Excalibur.
>>
>> MicroContainer would work with Avalon/Apps, but it seems a bit silly
>> and palindromic to provide a non-Avalon wrapper for a wrapper for
>> non-Avalon applications...
>
>
> Slow down a bit. MicroContainer has nothing to support components with
> formal dependencies. I can guarantee you that MicroContainer will not
> support the Avalon/Apps suite of components because it has NO
> UNDERSTANDING OF FORMAL DEPENDENCIES AND SERVICES. I said that in big
> letters because I really think that we should be a lot more strict about
> addressing limitation and potential of different activities in a much
> more consistent manner. That is the critical all import key - 100%
> reusable components - nothing less.
With this I don't fully agree.
Micro should not have to be able to run Merlin components, while the
opposite being true.
No dependencies and starting? Use Micro.
Need more? Upgrade to the next-level container.
>>
>> So I see:
>>
>> 1. framework
>> Avalon Framework interfaces and reference implementation.
>>
>> 2. containers
>> 2a. common container code (metainfo, etc.)
>> 2b. microcontainer
>> 2c. fortress
>> 2d. phoenix
>> Again, this is my 3-container approach.
>
>
>
> What about Merlin? - Shouldn't it be included with the three musketeers
> - or I should I head over to the axis-of-evil?
:-))
Finally you step in!
I was wondering the day you came out of the dark and joined the
container discussion :-)
> Seriously - I would like
> to throw the "three-container-approach" a long long way away. I don't
> want to think about different containers. I do want a common container
> solution and that would involve (a) completing the containerkit core (b)
> building services around that core, and (c) providing tools that
> leverage those services. Those tools would provide solutions to
> different users - tools such component documentors, application assembly
> generators, validators, deployment packagers, component and application
> execution for the developer, an application server, application and
> component motoring and analysis, etc., etc. With any luck - Fortress
> will be rebuilt or at least broken down into a set of services that
> leverage the container core.
> MicroContainer needs to be reviewed in
> terms of its immediate value against potential damage through component
> fragmentation.
True
> Merlin (yes - its a container too) is already being
> totally re-written to leverage containerkit and its structure is being
> broken out into general assembly services with the objective of
> eliminating the which-container issue. Bottom line - Phoenix is
> restructuring - Merlin is restructuring - Fortress needs to restructure
> - is there a trend here ? ;-)
Yes, there is :-)
Please, explain me what Merlin gives us that Fortress doesn't or can't
yet do, and the opposite.
If you can make a simple list of features that each container has more
than the previous, it would be great for me.
IE:
Micro
-----
- use single component
- run lifecycle
- ...
Merlin
------
- adds also...
Fortress
----------
- adds also...
Phoenix
--------
- adds also .sar server apps
- adds JMX support
- ...
>> 3. component directory
>> This is a list of components that work with Avalon containers. This is
>> basically Apps + Excalibur + all components in Commons that we export
>> from Excalibur with MicroContainer. The actual components are *not*
>> stored here unless they are wrappers for non-avalon components (like
>> some of the current Apps). It is basically a list of "this is the
>> stuff you can put in your container.
>
> I have to confess that my use of Excalibur has been limited to
> utilities. Can you provide a summary of the different "components" that
> exist in Excalibur.
easy, just look at the names of the dirs in CVS ;-)
Anyway, most are already moving to Commons, since they have no
avalon.framework dependency.
>> 4. site
>> 5. sandbox
>>
>> The 4 and 5 is basically just for developers. So a newbie user comes
>> in and sees this:
>>
>> 1. Get the framework.
>> 2. Check the list of containers (all 3 of them). Pick one that suits
>> your needs.
>> 3. Pick all the stuff you want to put in your container.
>> 4. Good to go!
>>
>> Like Pete, I'd prefer just one container. But given the different
>> requirements for containers I don't think "one single container" will
>> work. I do think that all containers will be able to run all
>> components, but the way they are managed and the grade of committment
>> to Avalon architecture differs - and I do not see how that can be
>> avoided.
>
>
> This has to be solved - existance of different semantic approaches to
> component management mean that components are designed and implememtated
> today relative to a target container family. We have two semantic
> models - the ECM/Fortress/MicroContainer model and the
> containerkit/Phoenix/Merlin. Either of these two approaches must die or
> we must make a formal distrinction between them and live with the
> consequences.
+1
But what *could* be nice is that there are different profiles of the
same semantical model, ie bigger containers implement more features.
This creates no overlap.
>> Maybe we can provide some three-point checklist for the containers.
>> Like (I'm sure we can argue over the list below. I'm only quite
>> certain about MicroContainer and its "upper limit" against Fortress.
>> As for the upper limit of Fortress, I'm a bit unsure.):
>>
>> MicroContainer
>> + You are primarily interested in using one or two Avalon components
>> in another architecture.
>> + You are not interested in the Avalon architecture and would like to
>> know as little as possible about it.
>> + Basically: Just give me the darn component!
>
> And hope like hell its not a component that expects anything substantial
> from its container - i.e. no meta support. Very limited validation - no
> enforcement of a formal compoenent defintion - usefull for lifecycle
> handling.
Exactly.
>> Fortress
>> + You are considering using Avalon for part or all of your application.
>> + Your application is not a stand-alone server or server application.
>> + Basically: You are writing a servlet.
>
> And hope like hell its not a formal component that you using.
? Could you explain more in detail please?
>> Phoenix
>> + You are considering using Avalon for a stand-alone server.
>> + Basically: You are writing an entire server.
>
> And hope like hell it is a formal component or your hosed.
? Same as above :-?
>> Maybe even a checklist. Check all checkboxes, click on submit, and
>> we'll tell you what container you want. :)
>
> Today - do the checklist and you will end up with one or more containers
> YOU MUST USE because of inconsitent and incompatible component models.
Yes, this is the issue.
We must instead end up with the *minimum* required container to host
your components.
...
> There are actually several Avalon Apps projects that could escalate -
> but the bottom line here is that those issue noted above must be sorted
> out. Those projects are reusable components and the infrastructure needs
> to exit beta before the majority can consider exiting the Avalon. That
> means working on containerkit - it means re-engineering all of the
> current containers (even MicroConbtainer:-) ).
I think so too.
Containerkit is in infancy though, let's see what happens.
> It means every component coming out of Avalon passes a component
> conformance test-suite.
Good proposal, I like it :-)
--
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: organisation of avalon subprojects
Posted by Stephen McConnell <mc...@osm.net>.
Leo Sutic wrote:
> The tendency is to start a subproject (Avalon) and then another
> subproject under that (Excalibur) and then projects under that
> (MicroContainer) and so on. I could devote some hundred lines to this
> and the reasons for the process, but that's neither here nor there...
>
> Anyway, the result is that the scope of the Avalon project has grown
> immensely - it is not just a framework, it is a replacement for RMI
> (AltRMI). It is a Database (AvalonDB). In no way do I want to
> criticise these projects, but do they really belong under the Avalon
> umbrella? Are they really not projects at the same level as Avalon
> itself?
>
> Another issue with this is that doing this walls us off from the rest
> of Jakarta. Avalon becomes a Jakarta in scope - self-sufficient in
> itself and utterly isolated. I want to see Phoenix-based apps on the
> front Jakarta page. That's the only way to spread Avalon through Jakarta.
Agree with the principal - object to the approach.
Getting the spread means delivering applications that work against a
solid base - the solid base in the Avalon world is primarily the
framework. Phoenix is in alpha today - stable - nearing beta -
potentially (preferably) facing internal reworking to synchronize with
containerkit. ECM is declared as going the direction of the dinosaur,
Fortress is proclaimed as the replacement, MicroContainer pups up on the
screen - early stage discussions are moving forward on cross-container
interoperability - which today is totally out of scope - there is lots
to be done in solving the back-office of Avalon (containers etc.) and
that needs to be done in a focused environment when people are sorting
out similar goals. Spreading Avalon today means destruction of the
community.
>
> As Pete C says, I think we should slim the Avalon project
> *significantly*. And now I am talking about some chainsaw-grade
> reduction.
Put away the chainsaw and think instead about the words
"consolidation". Go back to MicroContainer and rip out the lifecycle
processing code - put in place something from a common codebase - reduce
the duplication. Phoenix has already done this, Merlin is
transitioning, if you do it you reduce unnecessary code - that
simplifies things - lots of little actions like that will have a big
impact. The second and really important thing to consider is community
growth. If you take a look at
http://home.osm.net/technical/avalon/trends.html you will see that the
Avalon project is steadily building. With the resolution of reusable
components I'm very confident that we will see significant jump in
growth - because all of a sudden you will see components that are
formally complete and consistent and that means reuse and that means
value an value means attention and attention means commercially
interesting. But we are not there yet - its still in the nurturing phase.
>
> With MicroContainer a new possibility has emerged: All Avalon
> components previously in Excalibur can move to Commons. I am currently
> thinking through what restrictions MicroContainer puts on the
> components it manages, but it appears to be quite few.
Providing we limit ourselves to non-meta based components. Sorry Leo,
but MicroContainer will not run ANY of my components - NONE. For the
sort of things I'm doing it is only valid for the simplest type of
component. I'm not complaining about the work you have done - but its
way too focussed on the the ECM style/pattern of component usage to be
usafull in a general context - and that is the big concern - you end up
propagating the informal component model - and the proliferation of
components that will not work across other containers. That's the
important thing right now - eliminating those "semantics" gray areas -
getting this stuff really solid so that users can use the tool that best
matches the task.
> I have already made DataSource work, and I think I can do the same for
> just about any component in Excalibur.
>
> MicroContainer would work with Avalon/Apps, but it seems a bit silly
> and palindromic to provide a non-Avalon wrapper for a wrapper for
> non-Avalon applications...
Slow down a bit. MicroContainer has nothing to support components with
formal dependencies. I can guarantee you that MicroContainer will not
support the Avalon/Apps suite of components because it has NO
UNDERSTANDING OF FORMAL DEPENDENCIES AND SERVICES. I said that in big
letters because I really think that we should be a lot more strict about
addressing limitation and potential of different activities in a much
more consistent manner. That is the critical all import key - 100%
reusable components - nothing less.
>
> So I see:
>
> 1. framework
> Avalon Framework interfaces and reference implementation.
>
> 2. containers
> 2a. common container code (metainfo, etc.)
> 2b. microcontainer
> 2c. fortress
> 2d. phoenix
> Again, this is my 3-container approach.
What about Merlin? - Shouldn't it be included with the three musketeers
- or I should I head over to the axis-of-evil? Seriously - I would like
to throw the "three-container-approach" a long long way away. I don't
want to think about different containers. I do want a common container
solution and that would involve (a) completing the containerkit core (b)
building services around that core, and (c) providing tools that
leverage those services. Those tools would provide solutions to
different users - tools such component documentors, application assembly
generators, validators, deployment packagers, component and application
execution for the developer, an application server, application and
component motoring and analysis, etc., etc. With any luck - Fortress
will be rebuilt or at least broken down into a set of services that
leverage the container core. MicroContainer needs to be reviewed in
terms of its immediate value against potential damage through component
fragmentation. Merlin (yes - its a container too) is already being
totally re-written to leverage containerkit and its structure is being
broken out into general assembly services with the objective of
eliminating the which-container issue. Bottom line - Phoenix is
restructuring - Merlin is restructuring - Fortress needs to restructure
- is there a trend here ? ;-)
>
> 3. component directory
> This is a list of components that work with Avalon containers. This is
> basically Apps + Excalibur + all components in Commons that we export
> from Excalibur with MicroContainer. The actual components are *not*
> stored here unless they are wrappers for non-avalon components (like
> some of the current Apps). It is basically a list of "this is the
> stuff you can put in your container.
I have to confess that my use of Excalibur has been limited to
utilities. Can you provide a summary of the different "components" that
exist in Excalibur.
>
>
> 4. site
> 5. sandbox
>
> The 4 and 5 is basically just for developers. So a newbie user comes
> in and sees this:
>
> 1. Get the framework.
> 2. Check the list of containers (all 3 of them). Pick one that suits
> your needs.
> 3. Pick all the stuff you want to put in your container.
> 4. Good to go!
>
> Like Pete, I'd prefer just one container. But given the different
> requirements for containers I don't think "one single container" will
> work. I do think that all containers will be able to run all
> components, but the way they are managed and the grade of committment
> to Avalon architecture differs - and I do not see how that can be
> avoided.
This has to be solved - existance of different semantic approaches to
component management mean that components are designed and implememtated
today relative to a target container family. We have two semantic
models - the ECM/Fortress/MicroContainer model and the
containerkit/Phoenix/Merlin. Either of these two approaches must die or
we must make a formal distrinction between them and live with the
consequences.
>
> Maybe we can provide some three-point checklist for the containers.
> Like (I'm sure we can argue over the list below. I'm only quite
> certain about MicroContainer and its "upper limit" against Fortress.
> As for the upper limit of Fortress, I'm a bit unsure.):
>
> MicroContainer
> + You are primarily interested in using one or two Avalon components
> in another architecture.
> + You are not interested in the Avalon architecture and would like to
> know as little as possible about it.
> + Basically: Just give me the darn component!
And hope like hell its not a component that expects anything substantial
from its container - i.e. no meta support. Very limited validation - no
enforcement of a formal compoenent defintion - usefull for lifecycle
handling.
>
>
> Fortress
> + You are considering using Avalon for part or all of your application.
> + Your application is not a stand-alone server or server application.
> + Basically: You are writing a servlet.
And hope like hell its not a formal component that you using.
>
>
> Phoenix
> + You are considering using Avalon for a stand-alone server.
> + Basically: You are writing an entire server.
And hope like hell it is a formal component or your hosed.
>
>
> Maybe even a checklist. Check all checkboxes, click on submit, and
> we'll tell you what container you want. :)
Today - do the checklist and you will end up with one or more containers
YOU MUST USE because of inconsitent and incompatible component models.
>
>
> Other points:
> + Logkit out of Avalon and to top-level or Commons.
> + Testlet DIE DIE DIE kill it already for the love of God.
I agree - Testlet should disappear.
>
> + Excalibur/Event (SEDA/SILK) to Framework or sandbox.
Sandbox.
>
> + Excalibur/Command (SEDA/SILK???) to Framework or sandbox.
Sandbox.
>
> + AltRMI to top-level within Jakarta
There are actually several Avalon Apps projects that could escalate -
but the bottom line here is that those issue noted above must be sorted
out. Those projects are reusable components and the infrastructure needs
to exit beta before the majority can consider exiting the Avalon. That
means working on containerkit - it means re-engineering all of the
current containers (even MicroConbtainer:-) ).
It means every component coming out of Avalon passes a component
conformance test-suite.
Cheers, Steve.
--
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: organisation of avalon subprojects
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote:
>
>
> Nicola Ken Barozzi wrote:
>
>>
>>
>> Leo Sutic wrote:
>> ...
>>
>>> In short, I want Avalon to be: Framework + Three Containers +
>>> Component Directory
>>
>>
>>
>> Basically I agree.
>>
>
> So what you are saying is that you:
>
> 1. agree to continuing with different component models?
-1
> 2. oppose rationalization of the different containers?
-1, ie I want rationalization
> 3. support the ongoing inability to use different component across
> containers?
-1
> I await in eager anticipation for you speedy clarification !
Three containers means three containers that support increased
functionalities, ie upgrade *must* be with no code change whatsoever.
--
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: organisation of avalon subprojects
Posted by Stephen McConnell <mc...@osm.net>.
Nicola Ken Barozzi wrote:
>
>
> Leo Sutic wrote:
> ...
>
>> In short, I want Avalon to be: Framework + Three Containers +
>> Component Directory
>
>
> Basically I agree.
>
So what you are saying is that you:
1. agree to continuing with different component models?
2. oppose rationalization of the different containers?
3. support the ongoing inability to use different component across
containers?
I await in eager anticipation for you speedy clarification !
Cheers, Steve.
--
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: organisation of avalon subprojects
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Sutic wrote:
...
> In short, I want Avalon to be: Framework + Three Containers + Component
> Directory
Basically I agree.
--
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: organisation of avalon subprojects
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
The tendency is to start a subproject (Avalon) and then another subproject
under that (Excalibur) and then projects under that (MicroContainer) and so
on. I could devote some hundred lines to this and the reasons for the
process, but that's neither here nor there...
Anyway, the result is that the scope of the Avalon project has grown
immensely - it is not just a framework, it is a replacement for RMI
(AltRMI). It is a Database (AvalonDB). In no way do I want to criticise
these projects, but do they really belong under the Avalon umbrella? Are
they really not projects at the same level as Avalon itself?
Another issue with this is that doing this walls us off from the rest of
Jakarta. Avalon becomes a Jakarta in scope - self-sufficient in itself and
utterly isolated. I want to see Phoenix-based apps on the front Jakarta
page. That's the only way to spread Avalon through Jakarta.
As Pete C says, I think we should slim the Avalon project *significantly*.
And now I am talking about some chainsaw-grade reduction.
With MicroContainer a new possibility has emerged: All Avalon components
previously in Excalibur can move to Commons. I am currently thinking
through what restrictions MicroContainer puts on the components it manages,
but it appears to be quite few. I have already made DataSource work, and I
think I can do the same for just about any component in Excalibur.
MicroContainer would work with Avalon/Apps, but it seems a bit silly and
palindromic to provide a non-Avalon wrapper for a wrapper for non-Avalon
applications...
So I see:
1. framework
Avalon Framework interfaces and reference implementation.
2. containers
2a. common container code (metainfo, etc.)
2b. microcontainer
2c. fortress
2d. phoenix
Again, this is my 3-container approach.
3. component directory
This is a list of components that work with Avalon containers. This is
basically Apps + Excalibur + all components in Commons that we export from
Excalibur with MicroContainer. The actual components are *not* stored here
unless they are wrappers for non-avalon components (like some of the
current Apps). It is basically a list of "this is the stuff you can put in
your container.
4. site
5. sandbox
The 4 and 5 is basically just for developers. So a newbie user comes in and
sees this:
1. Get the framework.
2. Check the list of containers (all 3 of them). Pick one that suits your
needs.
3. Pick all the stuff you want to put in your container.
4. Good to go!
Like Pete, I'd prefer just one container. But given the different
requirements for containers I don't think "one single container" will work.
I do think that all containers will be able to run all components, but the
way they are managed and the grade of committment to Avalon architecture
differs - and I do not see how that can be avoided.
Maybe we can provide some three-point checklist for the containers. Like
(I'm sure we can argue over the list below. I'm only quite certain about
MicroContainer and its "upper limit" against Fortress. As for the upper
limit of Fortress, I'm a bit unsure.):
MicroContainer
+ You are primarily interested in using one or two Avalon components in
another architecture.
+ You are not interested in the Avalon architecture and would like to
know as little as possible about it.
+ Basically: Just give me the darn component!
Fortress
+ You are considering using Avalon for part or all of your application.
+ Your application is not a stand-alone server or server application.
+ Basically: You are writing a servlet.
Phoenix
+ You are considering using Avalon for a stand-alone server.
+ Basically: You are writing an entire server.
Maybe even a checklist. Check all checkboxes, click on submit, and we'll
tell you what container you want. :)
Other points:
+ Logkit out of Avalon and to top-level or Commons.
+ Testlet DIE DIE DIE kill it already for the love of God.
+ Excalibur/Event (SEDA/SILK) to Framework or sandbox.
+ Excalibur/Command (SEDA/SILK???) to Framework or sandbox.
+ AltRMI to top-level within Jakarta
+ Rest of Excalibur minus Fortress and MicroContainer to Jakarta-Commons.
+ Concurrent to Commons (already done?) or ditch in favour of
util.concurrent:
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
In short, I want Avalon to be: Framework + Three Containers + Component
Directory
And nothing more.No Utility package (put it in framework if it is for
users, in containers-common if it is for container writers (2a on my list
above), or ship it off to Commons if neither).
That's my perfect world.
And that's all I have to say about that.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>