You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2004/03/03 16:49:25 UTC
[avalon] roadmap
Following the initial discussions on the pmc concerning avalon
direction, roadmap, etc. I wanted to post my thoughts about Avalon and
the direction over the next year.
1. Development Consolidation
----------------------------
One api, one reference implementation. Rather than launch into a A5
scenario, I am in favor of moving forward by building and evolving on A4
- no radical change - but some significant and important changes in the
terms of depth.
1.1 Starting with Avalon Framework 4.2
--------------------------------------
More and more I'm seeing the need for different levels of APIs. We have
the A4 framework contract for classic container/component interaction -
but room for evolution with respect to constructor management. I see
this as an avalon framework 4.2 release.
1.2 Increasing depth
--------------------
Beyond the classic container/component model we have components that
interact in a privileged way with a container as part of an application
solution. This requires a formal API to describe meta info, meta data,
and ultimately a runtime meta-model.
A starting point for a meta-model API is already in place:
avalon-meta-api
avalon-logging-api
avalon-composition-api
avalon-repository-api
1.3 Reference implementation
----------------------------
Probably the most important thing that will need to happen in the coming
months is the elimination of different development directions. One
component architecture - one development community - one roadmap. This
involves the establishment of one and only one reference implementation
- termination of divergent streams, and the focus by the community of
the evolution of the reference implementation.
2. Systems Level Development
----------------------------
On the presumption of a single reference implementation there are a
number of development areas that I think are central to Avalon development:
* security services
* persistence state services
* transaction services
* management services
The above services would be closely tied to a set of container SPIs are
would leverage privileged access to system internals. The framework for
much of this is already in place though the work of SPI interfaces under
the composition, repository and meta packages.
3. Avalon Component Library
---------------------------
There are a number of aspects to address with respect to an Avalon Library.
3.1 Compliance with Avalon-Meta and block packaging specs.
----------------------------------------------------------
A most important factor is the requirement for single component model
compliance. Usage of standard meta-info across the board, standard
packaging of composite components, and a very complete and consistent
approach to the definition of remotely deployable units. In other words
- making sure that the component library is very easy to use and very
simple to leverage.
3.2 Content Publication
-----------------------
A second aspect concerns publication of library content and the services
supporting this. With the introduction of consistent and validated
deployment descriptors the potential exists to provide automation of the
component retrieval process - similar the avalon-repository services,
but instead of dealing with jar files - we are dealing with block
descriptions retrieval and/or creation based on service requests. I see
this as a general goal the has as a prerequisite the points identified
under sections (1) and (2) above.
3.3 Library as a managed Avalon product.
----------------------------------------
Thirdly - there is the subject of the focus of an avalon library. I see
several advantages in viewing the library as a managed platform - as
distinct from a place for arbitrary components. As a managed platform
we should be treating the library as a product in its own right -
evolving components relative to the Avalon RI, maintaining consistency
between components, and ensuring that no overlaps in functionality exist.
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Zen Framework (was Re: [avalon] roadmap)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 04 March 2004 06:16, Niclas Hedhman wrote:
> Some are saying that the second is utopia and can't happen, so let's
> concentrate on the first.
Excuse me; I am not in that group saying that .... ;o)
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Zen Framework (was Re: [avalon] roadmap)
Posted by Berin Loritsch <bl...@d-haven.org>.
Niclas Hedhman wrote:
> On Thursday 04 March 2004 03:29, Leo Simons wrote:
>
>>Berin Loritsch wrote:
>
>
>>Let's just recognize there's some rather fundamental differences of
>>opinion here.
>
>
> Yes we have;
> 1. The Duct Tape group.
> 2. The Foundation Engineers
> 3. Others.
> 4. Confused Users.
And I am trying to avoid the duct tape--I am just not good at saying it.
Merlin to me represents duct tape and heavy contracts. I need several
hundred KB of libraries just to use my components!
Now, with the advent of JDK 1.5, please at least entertain the notion of
using JDK 1.5 attributes for Avalon components if early adopters want to
use that. That would get rid of the need of the Meta package just to
read and use meta info.
IMO, the contract is with the meta info syntax in the source code--not
the XML panacea solution that requires special ANT/Maven tasks to be run
that we currently have. I realize that JDK 1.5 might bring in some constraints
on how we write the meta info, but it would be best to match that syntax
in the near term. You can still use the XML descripters until JDK 1.5
reaches critical mass. But at least we have the concrete definition of
what those attributes look like.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Zen Framework (was Re: [avalon] roadmap)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 04 March 2004 03:29, Leo Simons wrote:
> Berin Loritsch wrote:
> Let's just recognize there's some rather fundamental differences of
> opinion here.
Yes we have;
1. The Duct Tape group.
2. The Foundation Engineers
3. Others.
4. Confused Users.
> I think model-driven architecture is a really big farce, a
> bad idea, a dumb term, and a pipe dream.
> I do not know how to achieve the complete formal model (as in
> model-driven) whilst still accomodating simplicity. Indeed, being able
> to quite easily
>
> public static void main( String[] args )
> {
> /* 10 lines of code to set up and use two components here, without
> importing anything else */
> }
>
> Dismissing this as an invalid usecase is just as dumb as calling
> model-driven architecture a big farce.
So we are EQUALLY DUMB :o)
I might be Dumb, but I ain't Stupid, you know...
> The vital point to realize, and the real challenge at the same time, is
> that the world would /really/ benefit from some reuse of components
> between these two approaches.
YES. But here is the difference,
If there is a strong contract enforced on the component, it is possible to
build both types of systems, i.e. the Atlantic Bridge vs The Plank Across the
Creek.
If there is not, only the plank will be possible.
> Niclas wrote:
> > I realize that ALL software developers SHOULD be
> > forced to work on designing the electronics for a year or so, just to
> > be enlightened on how simple things could be.
>
> I have two (relatively brilliant) electronics students here on my flat.
> They plainly suck as software architects. Might I suggest software
> developers study physics instead?
I never said to turn electronics engineers into software architects. But the
software community at large should be exposed to the really nice tools those
guys use.
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Zen Framework (was Re: [avalon] roadmap)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 04 March 2004 03:29, Leo Simons wrote:
> Let's just recognize there's some rather fundamental differences of
> opinion here.
Another revelation, one much more fundamental difference;
* Avalon is about a container that should be capable to run just about
anything we throw at it.
or
* Avalon is about component contracts that will lead to true component re-use,
followed by tools development and a spiral to heaven :o)
Some are saying that the second is utopia and can't happen, so let's
concentrate on the first.
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Zen Framework (was Re: [avalon] roadmap)
Posted by Alex Karasulu <ao...@bellsouth.net>.
Ok did I mess something up? Ok ok let's just recall those emails.
:-)
Alex
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: Wednesday, March 03, 2004 9:16 PM
> To: Avalon Developers List
> Subject: Re: Zen Framework (was Re: [avalon] roadmap)
>
> Alex Karasulu wrote:
>
> >>>I definitely agree with you on this one!
> >>
> >>Beyond that - the girls from the social science department know a bunch
> >>more about forking than anyone here in Avalon.
> >
> >
> > ROTFL! It took me a while but I finally got it. Those girls are
> probably
> > prettier too I bet. Damn you're too funny!
>
> I just want everyone here to know that I have absolutely no idea what
> what Alex is talking about!
>
> Steve.
>
> --
>
> |------------------------------------------------|
> | Magic by Merlin |
> | Production by Avalon |
> | |
> | http://avalon.apache.org/merlin |
> | http://dpml.net/merlin/distributions/latest |
> |------------------------------------------------|
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Zen Framework (was Re: [avalon] roadmap)
Posted by Stephen McConnell <mc...@apache.org>.
Alex Karasulu wrote:
>>>I definitely agree with you on this one!
>>
>>Beyond that - the girls from the social science department know a bunch
>>more about forking than anyone here in Avalon.
>
>
> ROTFL! It took me a while but I finally got it. Those girls are probably
> prettier too I bet. Damn you're too funny!
I just want everyone here to know that I have absolutely no idea what
what Alex is talking about!
Steve.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Zen Framework (was Re: [avalon] roadmap)
Posted by Alex Karasulu <ao...@bellsouth.net>.
> > I definitely agree with you on this one!
>
> Beyond that - the girls from the social science department know a bunch
> more about forking than anyone here in Avalon.
ROTFL! It took me a while but I finally got it. Those girls are probably
prettier too I bet. Damn you're too funny!
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Zen Framework (was Re: [avalon] roadmap)
Posted by Stephen McConnell <mc...@apache.org>.
Alex Karasulu wrote:
>>They plainly suck as software architects. Might I suggest software
>>developers study physics instead?
>>
>>;)
>
>
> I definitely agree with you on this one!
Actually - I would suggest that software developers study basic social
psychology. If you do anything in collaborative systems, agent
technologies, peer-to-peer, etc. The guys and girls in the social
psychology domain have nailed this stuff down tap.
Beyond that - the girls from the social science department know a bunch
more about forking than anyone here in Avalon.
Steve.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Zen Framework (was Re: [avalon] roadmap)
Posted by Alex Karasulu <ao...@bellsouth.net>.
> They plainly suck as software architects. Might I suggest software
> developers study physics instead?
>
> ;)
I definitely agree with you on this one!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Zen Framework (was Re: [avalon] roadmap)
Posted by Leo Simons <le...@apache.org>.
Berin Loritsch wrote:
> Let's invent a new concept: "No Framework"
>
> If we don't do it here, then I will pursue it over at D-Haven.
Let's just recognize there's some rather fundamental differences of
opinion here. And let us not fragment CVSes over a dozen sourceforge
projects (but that's a different story ;).
Through IMing with Steve and diving a bit deeper into merlin, I can see
where its coming from and where its going, and its really fundamentally
different from where I want to go with things.
For example, I think model-driven architecture is a really big farce, a
bad idea, a dumb term, and a pipe dream. He thinks opening up a system
to try and make it completely scriptable (all "glue-ey") is even worse.
I don't see merlin becoming some components with some glue between them
(call it a JMX microkernel if you want, but its just a bit of glue): it
just doesn't fit the codebase at all. Through every successive merlin
iteration, Steve has adjusted and finetuned a formal modal, and he's
extending it into more and more parts of the problem domain, piece by piece.
This is radically different from just going like "hey, you, programmer!
Here's some really useful duck tape and a big jar of glue. Go build your
app.".
The vital point to realize, and the real challenge at the same time, is
that the world would /really/ benefit from some reuse of components
between these two approaches.
Rigidly formalizing every little bit of the avalon meta model and making
it a core part of avalon-framework will make that more difficult. The
more model-driven the avalon container-component contract becomes, the
more difficult it becomes for a piece of duck tape to act like a container.
I do not know how to achieve the complete formal model (as in
model-driven) whilst still accomodating simplicity. Indeed, being able
to quite easily
public static void main( String[] args )
{
/* 10 lines of code to set up and use two components here, without
importing anything else */
}
Dismissing this as an invalid usecase is just as dumb as calling
model-driven architecture a big farce. If it becomes impossible to
replace the container side of the container-component contract,
completely, easily, with some simple bits of pure java, avalon will have
failed as a framework, failed on its promise of seperation of concerns,
and it will probably fail as a project because it will be surpassed by
others.
Niclas wrote:
> I realize that ALL software developers SHOULD be
> forced to work on designing the electronics for a year or so, just to
> be enlightened on how simple things could be.
I have two (relatively brilliant) electronics students here on my flat.
They plainly suck as software architects. Might I suggest software
developers study physics instead?
;)
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Zen Framework (was Re: [avalon] roadmap)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 04 March 2004 22:16, Berin Loritsch wrote:
> If you are going to focus on the future, I would like the future to be more
> simple, yet invite the tooled approach that Niclas advocates. I just want
> to avoid letting the tool mask the true complexity of a system. Just
> because we have a tool doesn't mean that everyone is going to use it. For
> the die hards that still like to code in VI, without an IDE, it shouldn't
> be a complex task to create and use components like with EJBs.
With due respect, you are not looking closely at my "Spiral to Heaven".
It is NOT "Tools leads to Components", but the reverse. Unfortunately, with
the "catch" that the components has to be in accordance with a strict
specification, and not the fluffy API of 'just about everything'.
I have mentioned it so many times before. Components are so much more than
code in a JAR. Off my head;
1) Identification.
2) Packaging.
3) Component Specification.
4) Documentation
5) Meta-information
6) Supply information
Possibly also "Structural Model information" and "Behavioural Model
information", but that could be considered part of a "Component Specification
Set".
I foresee a future where you don't have a couple of dozen or hundreds of
components, but hundreds of thousands or even millions.
And that also mean I should be able to search the vast sea of components to
find what I need (Meta-information), which returns the unique Identity of
each one that fits the search criteria. I then get the Component
Specification to verify that it contains what I am looking for and I check
that the Supply (Licensing, Price, Availability whatever) is what I am
looking for. Once I start using the component, I will find all the details of
the usage in the Documentation.
And if it is not Packaged in a standardized way, tools can't deal with this
work process, and a lot of manual labour is required, just like today when I
need to find something to reuse.
Cheers
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Zen Framework (was Re: [avalon] roadmap)
Posted by Berin Loritsch <bl...@d-haven.org>.
Alex Karasulu wrote:
>
> What we need to be discussing is a simplification through changes to the
> core. Do you guys see the issue to be framework or what? Berin I presume
> your suggestions revolve around framework 5 and supporting containers using
> the new features in jdk1.5 to simply things. What examples of features do
> you and others have in mind that would help us simply things?
1) Annotations. No need for a separate library to read and write the meta-info.
The meta info is accessible using reflection, so no worries about
"serializing" components accross a stream.
2) java.util.concurrent. All the tools from Doug Lea and a better memory model
will make it easier to write thread-safe containers.
3) Generics. Many operations within the container can be made simpler using
the generics.
4) java.lang.Runtime.getNumberOfProcessors(). No need to run a shell script to
determine the number of processors on a machine so that thread pools can be
sized relative to that automatically.
5) Typesafe enums. We use enumerated values for a great number of things to
help the compiler catch potential errors. This makes it easier and gives
language support.
6) New JAR compression format. The libraries can be made much smaller, which
helps for the larger things like parsers, etc.
7) java.lang.instrument. Instrumentation is now a natively supported thing in
Java.
These are a few of the things which are used in just about every container in
Avalon land, so it helps just about everything.
If you are going to focus on the future, I would like the future to be more
simple, yet invite the tooled approach that Niclas advocates. I just want to
avoid letting the tool mask the true complexity of a system. Just because we
have a tool doesn't mean that everyone is going to use it. For the die hards
that still like to code in VI, without an IDE, it shouldn't be a complex task
to create and use components like with EJBs.
If Avalon continues down the path it has been, I feel that Avalon will grow
into a complex spec like EJBs. While tools help, they shouldn't be *necessary*
to be effective.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Zen Framework (was Re: [avalon] roadmap)
Posted by Berin Loritsch <bl...@d-haven.org>.
Stephen McConnell wrote:
> Berin Loritsch wrote:
>
>> Please come up with some
>> definition for Avalon compliant so that we don't have to ask
>> permission if
>> we want to state that fact.
>
>
> Definition:
>
> Avalon Meta for information about a component type, Avalon Framework API
> for the contract between container and the component. It's all rather
> simple and rather powerful.
Show me a TCK so I can prove compliance. I.e. "Passes Avalon Component TCK".
We can have a nice button. It'll be fun.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Zen Framework (was Re: [avalon] roadmap)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Berin Loritsch wrote:
>
> > Please come up with some
> > definition for Avalon compliant so that we don't have to ask
> > permission if we want to state that fact.
>
> Definition:
>
> Avalon Meta for information about a component type, Avalon
> Framework API
> for the contract between container and the component.
Did Avalon Meta ever get elevated to a must-have for containers?
(http://marc.theaimsgroup.com/?t=107372890700003&r=1&w=2)
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Zen Framework (was Re: [avalon] roadmap)
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Please come up with some
> definition for Avalon compliant so that we don't have to ask permission if
> we want to state that fact.
Definition:
Avalon Meta for information about a component type, Avalon Framework API
for the contract between container and the component. It's all rather
simple and rather powerful.
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Zen Framework (was Re: [avalon] roadmap)
Posted by Alex Karasulu <ao...@bellsouth.net>.
> > Reading your reply, and I realize that ALL software developers SHOULD be
> > forced to work on designing the electronics for a year or so, just to be
> > enlightened on how simple things could be.
> >
> > I will not even try to convince you anymore... :o(
>
> That's ok. You don't need to. I will pursue my vision over at D-Haven,
> and like Jicerilla it will likely be "avalon compliant" when you decide
> what that is. However, I want to play with some new Java 1.5 features
> which will in turn make what I want to do even easier.
I'm open and ready to listen to the ideas you have. Berin please do not fork
away your efforts. Could you not just create your own subproject here
inside Avalon for experimentation with these very interesting ideas? We can
start playing in a sandbox. I personally would collaborate and entertain
them. I'm already looking at some of the things you have done at D-Haven
and think we can gain much from them here.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Zen Framework (was Re: [avalon] roadmap)
Posted by Berin Loritsch <bl...@d-haven.org>.
Niclas Hedhman wrote:
> On Thursday 04 March 2004 02:07, Berin Loritsch wrote:
>
>
>>I don't mind a strict spec as long as that strict spec isn't 100 pages
>>long. If you can fully specify the strict spec in six or seven pages
>>(hopefully less), then we have something that would work for most
>>developers.
>
>
> Reading your reply, and I realize that ALL software developers SHOULD be
> forced to work on designing the electronics for a year or so, just to be
> enlightened on how simple things could be.
>
> I will not even try to convince you anymore... :o(
That's ok. You don't need to. I will pursue my vision over at D-Haven,
and like Jicerilla it will likely be "avalon compliant" when you decide
what that is. However, I want to play with some new Java 1.5 features
which will in turn make what I want to do even easier.
It's not a problem. I will keep tabs to find out what "avalon compliant"
is. I highly recommend that you have a TCK that excersizes all of the
contracts so that I can prove avalon compliance. Please come up with some
definition for Avalon compliant so that we don't have to ask permission if
we want to state that fact.
Remember that compliance is not the same as endorsement, so I really don't
expect to see any comments about "you can't say that" or some such nonsense.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Zen Framework (was Re: [avalon] roadmap)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 04 March 2004 02:07, Berin Loritsch wrote:
> I don't mind a strict spec as long as that strict spec isn't 100 pages
> long. If you can fully specify the strict spec in six or seven pages
> (hopefully less), then we have something that would work for most
> developers.
Reading your reply, and I realize that ALL software developers SHOULD be
forced to work on designing the electronics for a year or so, just to be
enlightened on how simple things could be.
I will not even try to convince you anymore... :o(
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Zen Framework (was Re: [avalon] roadmap)
Posted by Berin Loritsch <bl...@d-haven.org>.
Niclas Hedhman wrote:
> On Thursday 04 March 2004 01:10, Berin Loritsch wrote:
>
>>The current state of merlin is
>>that there are so many contracts that I feel like I need to understand that
>>I can't possibly keep them straight.
>
>
> If this is the case, then we are failing in the education sector.
> Perhaps, Stephen (and I to some extent) are too quick to refer to the advanced
> sections, instead of promoting the "simple side". Perhaps there are more we
> can do in the "kitchen sink" area, for simpler usage patterns, which I think
> we all can agree upon are desireable.
That will help, but bear in mind that if I want to do something or extend Merlin
in some way that is not how the current authors feel it should be extended, then
I either need to reimplement everything from Merlin that I need with a new
container I can control, or I need to resort to ugly hacks. So there are two
levels of education that need to be addressed.
>>I don't get the
>>feeling of simplicity, or "it just works" when I look at either Maven or
>>Fortress (and I wrote the latter). That is the main goal I want to
>>encourage you to focus on.
>
> static public void main(String[]) "just works" and are suitable sometimes, but
> without "enforcing" framework standards, you will always end up with a mess
> on the component re-use side.
Yes, but what exactly needs to be enforced? I get the feeling that too much
is enforced for little known gain--at least to me. That is where the education
comes into play. But then again, I want something so transparent that I
shouldn't need education. Perhaps it is a holy grail that can never truly be
attained, but we can make strides torward it.
What about mixing and matching components from different lifecycle contracts?
It is possible provided your container can support it. I mean, do I really need
to hand write a wrapper for a component that was designed for PicoContainer?
If I have to resort to hand coding wrappers to use components designed for
other frameworks, then it isn't very useful and it is more pain than pleasure
to work with. I.e. it doesn't "just work".
> I strongly support the "Software IC" concept, and I think it could really
> work, but the software engineering community can't or don't want to make it
> happen. As many technologies as I have investigated and used over the years,
> only Avalon is even close to really trying.
> And when we manage to get to the point where a Publishing Service exists with
> an associated TCK, slowly components will show up, with high quality,
> conformant, easy to use, et cetera, which will lead to a network effect, and
> hopefully an avalanche of converts, since "Avalon Users finish projects in a
> fraction of time..." starts to become apparent.
> The similar patterns have happened several times in the Electronics industry
> (the transistor, the IC, surface mount devices and FPGAs), but what has been
> very significant the last 5-10 years is that the TOOLS supporting the
> components have improved tremendously, since the tools has very precise
> standards to work with. A modern design tool can NOT be effectively used to
> construct a tube amplifier, but easily put together a 32bit miniature
> computer.
>
> +-------------+ +------------+ +-------+ +------------+
> | Strict Spec | --> | Components | --> | Tools | --> | Effeciency | --+
> +-------------+ +------------+ +-------+ +------------+ |
> ^ |
> | |
> +-------------------------------------------+
>
> My ambition is to bring Avalon into the "loop" in the above picture.
That is a good ambition, and it can be acheived when you have the right
contracts. I think the misunderstanding here is that I perceive that the road
Avalon taking is that it is enforcing the wrong contracts, or too many
contracts. We can really simplify things if we wanted to, both from an
implementation perspective and from a definition perspective.
I don't mind a strict spec as long as that strict spec isn't 100 pages long.
If you can fully specify the strict spec in six or seven pages (hopefully less),
then we have something that would work for most developers. Tools are great,
but if all they do is hide the underlying complexity you are going to come into
some nasty surprizes if that complex set of contracts changes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Zen Framework (was Re: [avalon] roadmap)
Posted by Alex Karasulu <ao...@bellsouth.net>.
>
> +-------------+ +------------+ +-------+ +------------+
> | Strict Spec | --> | Components | --> | Tools | --> | Effeciency | --+
> +-------------+ +------------+ +-------+ +------------+ |
> ^ |
> | |
> +-------------------------------------------+
>
Nice! Tools do make hard things easier to grok and for sure some of the
tools coming together will make things much easier like MerlinDeveloper etc.
I think we need to clarify whether it is framework 4 that makes things
complex rather than the container of choice which just upholds those
contracts. If you ask me Phoenix, Merlin and Fortress are all the same when
it comes to complexity since they're based on the same framework.
What we need to be discussing is a simplification through changes to the
core. Do you guys see the issue to be framework or what? Berin I presume
your suggestions revolve around framework 5 and supporting containers using
the new features in jdk1.5 to simply things. What examples of features do
you and others have in mind that would help us simply things?
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Zen Framework (was Re: [avalon] roadmap)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 04 March 2004 01:10, Berin Loritsch wrote:
> The current state of merlin is
> that there are so many contracts that I feel like I need to understand that
> I can't possibly keep them straight.
If this is the case, then we are failing in the education sector.
Perhaps, Stephen (and I to some extent) are too quick to refer to the advanced
sections, instead of promoting the "simple side". Perhaps there are more we
can do in the "kitchen sink" area, for simpler usage patterns, which I think
we all can agree upon are desireable.
> Remember, in a world where there are few absolutes (such as software
> development), perception is more important than fact.
I agree. My perception was that EJB was going to be easy. My reality is it
wasn't/isn't.
> I don't get the
> feeling of simplicity, or "it just works" when I look at either Maven or
> Fortress (and I wrote the latter). That is the main goal I want to
> encourage you to focus on.
static public void main(String[]) "just works" and are suitable sometimes, but
without "enforcing" framework standards, you will always end up with a mess
on the component re-use side.
I strongly support the "Software IC" concept, and I think it could really
work, but the software engineering community can't or don't want to make it
happen. As many technologies as I have investigated and used over the years,
only Avalon is even close to really trying.
And when we manage to get to the point where a Publishing Service exists with
an associated TCK, slowly components will show up, with high quality,
conformant, easy to use, et cetera, which will lead to a network effect, and
hopefully an avalanche of converts, since "Avalon Users finish projects in a
fraction of time..." starts to become apparent.
The similar patterns have happened several times in the Electronics industry
(the transistor, the IC, surface mount devices and FPGAs), but what has been
very significant the last 5-10 years is that the TOOLS supporting the
components have improved tremendously, since the tools has very precise
standards to work with. A modern design tool can NOT be effectively used to
construct a tube amplifier, but easily put together a 32bit miniature
computer.
+-------------+ +------------+ +-------+ +------------+
| Strict Spec | --> | Components | --> | Tools | --> | Effeciency | --+
+-------------+ +------------+ +-------+ +------------+ |
^ |
| |
+-------------------------------------------+
My ambition is to bring Avalon into the "loop" in the above picture.
Cheers
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Zen Framework (was Re: [avalon] roadmap)
Posted by Berin Loritsch <bl...@apache.org>.
Niclas Hedhman wrote:
> I was actually watching the Academy Awards a few moments ago...
> Some emoticons would probably been appropriate.
>
> Seriously,
> My personal opinion is that "Programmer Flexibility" is the worst thing that
> happened to software development, perhaps together with the "I can do that
> myself"-attitude.
> I like Avalon, because it not only promotes good patterns, but in fact
> enforces them, making me a better software citizen.
> I don't need flexibility, I have had that for 20 years and haven't given me
> any substantial benefits, on the contrary.
I'm CC'ing the list, because both your comments and mine are important enough
for all to see.
My main point, as always, is not promoting programmer flexibility, but avoiding
arbitrary constraints. The more shackles you put on me as a developer, the more
I have to work against or around the system set up if it doesn't exactly meet my
needs. If you start simple, and grow simple, the number of contracts you have
are small. The current state of merlin is that there are so many contracts that
I feel like I need to understand that I can't possibly keep them straight.
Remember, in a world where there are few absolutes (such as software
development), perception is more important than fact. I don't get the feeling
of simplicity, or "it just works" when I look at either Maven or Fortress (and I
wrote the latter). That is the main goal I want to encourage you to focus on.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Zen Framework (was Re: [avalon] roadmap)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 04 March 2004 00:13, Berin Loritsch wrote:
> Something radical, and a bit different: The Zen Framework.
> Let's invent a new concept: "No Framework"
I have just written a container for this marvelous framework;
public class Main
{
static public void main( String[] args )
throws Exception
{
// Insert your Logger choice here
// Insert your components here
// Insert your assembly here
// Insert your lifecycle (if any) here
}
}
"Thank you, thank you, thank you... I would like to thank Berin Loritsch for
his marvelous insight of 'The Simplest Thing that can work', and I would like
to .... "
Cheers
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Zen Framework
Posted by Stephen McConnell <mc...@apache.org>.
Tetsuya Kitahata wrote:
> Gyaa... "Samarai" -> "Samurai", perhaps.
>
> 'Zen Framework' .. very nice naming, indeed. If you might want,
> i would be able to instill the spirit of "far east", more :-)
>
> The key -- is the "harmonization".
Harmonization is a really important notion is this entire equation.
There is the question of harmonizing component models (push versus
pull), harmonizing implementation strategies (flexible versus
constrained), harmonizing development criteria (developer versus
enterprise).
Cheers, Steve.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Zen Framework (was Re: [avalon] roadmap)
Posted by Tetsuya Kitahata <te...@nifty.com>.
Hi Folks!
# I'd been off from dev@avalon. Just now I am peepin' :)
On Wed, 03 Mar 2004 11:13:38 -0500
Berin Loritsch wrote:
> Something radical, and a bit different: The Zen Framework.
> The Samarai had a concept called "No Mind". Essentially you empty your mind of
> everything, and let your body flow naturally. In this state, you just work.
> When you start to try and influence your movements based on conscious thought,
> it is too slow and not fluid enough to fight a skilled warrior.
Gyaa... "Samarai" -> "Samurai", perhaps.
'Zen Framework' .. very nice naming, indeed. If you might want,
i would be able to instill the spirit of "far east", more :-)
The key -- is the "harmonization".
Cheers, - Tetsuya.
---------------------------------------------------------------------
Tetsuya Kitahata -- Terra-International, Inc.
E-mail: tetsuya@apache.org http://www.terra-intl.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Zen Framework (was Re: [avalon] roadmap)
Posted by Alex Karasulu <ao...@bellsouth.net>.
BTW I really loved the story. It reminded me of my wrestling days. When I
used to plan every move I would loose the match and be too slow. When I
calmed down and said I have faith in my ability to handle the situation when
it happens things flowed nicely.
We need that gentle graceful process around COP.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Zen Framework (was Re: [avalon] roadmap)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Berin Loritsch wrote:
>
> Learn from Pico Container, Jicerilla, Spring framework. They
> did the simplest thing that can work, and they have something
> that can fit or be adapted to fit anyone's preferred style of
> programming.
>
+1
> Start with something simple that works.
*Simple* is the keyword here, right!
> Build with that
> design concept in mind until you just can't fit it in
> anymore. We have JDK 1.5 available, and it can remove the
> reliance on a number of libraries we currently have. If
> Avalon 5 is to come out of that, let's leverage Java 1.5.
>
This is were I don't agree :) Let's not discuss about using
Java 1.5 (I think it's way too early to require this), but
let's discuss this behaviour.
For me it seems, each time the current container implementation
here at Avalon seems to get too complicated, the result is
"Oh, let's create a new, much simpler container". Now,
we all see were we are now. I don't want to update every year
to the "much better version (and it supports this 3000 features
more than the old one". No, thank.
I would love to use ECM with just one or two more features
or perhaps upgrade to Fortress and have there some more features.
Both are simple to setup and simple to use and work perfectly.
But if those things are not really continued here and all work
goes into the next iteration, perhaps using a simple container
framework from somewhere else is much more painless. I don't know.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Zen Framework (was Re: [avalon] roadmap)
Posted by Berin Loritsch <bl...@d-haven.org>.
Something radical, and a bit different: The Zen Framework.
The Samarai had a concept called "No Mind". Essentially you empty your mind of
everything, and let your body flow naturally. In this state, you just work.
When you start to try and influence your movements based on conscious thought,
it is too slow and not fluid enough to fight a skilled warrior.
In order for this to work the Samarai has to train hard so that all his
techniques are in muscle memory. Nevertheless, when they were in battle, they
seemed as if they had a sixth sense or an intuition about what you were going
to do.
Think about it. How much conscious effort do you have to apply to use Avalon
right now? I mean, how long does it take before we realize that there is an
awful lot to remember to set up and use Avalon? The build is complex. Setting
up the container is complex. Embedding it is complex. Wiring the components
together is complex. Why? Because there is too much reliance on esoteric
things. When you combine a hard meta model, a hard component/container
contract, a number of things happening under the hood with a few configuration
files, the actual use of Avalon is not as pleasant as it otherwise could be.
Learn from Pico Container, Jicerilla, Spring framework. They did the simplest
thing that can work, and they have something that can fit or be adapted to fit
anyone's preferred style of programming.
Start with something simple that works. Build with that design concept in mind
until you just can't fit it in anymore. We have JDK 1.5 available, and it can
remove the reliance on a number of libraries we currently have. If Avalon 5 is
to come out of that, let's leverage Java 1.5.
Let's invent a new concept: "No Framework"
If we don't do it here, then I will pursue it over at D-Haven.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [avalon] roadmap - library criteria
Posted by Stephen McConnell <mc...@apache.org>.
Carsten Ziegeler wrote:
> So, perhaps it would really be better to forget Fortress and move
> everything into Merlin but of course maintain the simplicity of
> Fortress. Embedding Fortress into an own application is four or
> five lines of Java code and some simple configuration file. That's
> it.
I've just committed an example of embedding merlin so that you can get
an idea of things (available in avalon/merlin/platform/tutorials/main).
The example goes through the following steps:
1. setup an application cache -- 4 lines
2. build the application classloader -- 3 lines
3. parameterize and deploy the application -- 3 lines
In general the same pattern applies for any repository enabled
application. The demonstration will run with or without a merlin
install. If merlin is installed the demo will use the existing merlin
system repository, otherwise a new system repository will be created and
populated automatically. The actual bootstrapping is taken care of by
the single jar file avalon-repository-main.
Cheers, Steve.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [avalon] roadmap - library criteria
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stephen McConnell wrote:
>
> Carsten Ziegeler wrote:
> > And make sure that the components run out-of the box in the most
> > recent containers including at least Fortress (ECM would be good as
> > well, but perhaps we can forget that one)
>
> Carsten:
>
> Thanks for the email - there are several points I would like
> to expand on but that's for another thread. Concerning the
> above - I would like to figure out a way in which we move you
> from a implementation dependency to a service dependency.
> I.e. I don't want you to be dependent on Fortress.
Yes, I understand.
> I want
> you to be dependent on an API. If you can define that API,
> I'm ready to take a shot a delivering an implementation
> solution. Even better - if you can provide some test cases,
> I'm ready to spend some time making sure we provide a
> sustainable solution.
>
The most problematic area I currently see is Configuration. For
example in Cocoon we are using the ECM with three configuration
files: a roles configuration containg all roles, the component
configuration, containg the configuration for some components
in addition with some new components that are not in the roles
file and the logkit configuration.
Now Fortress is using a different approach, I uses for some
aspects Meta-Information and for some other aspects configuration
files that are not compatible with ECM. But you can use ECM
configuration files with Fortress but can't additionally use
the new configuration things from Fortress. So it's currently
an all or nothing approach (old or new, but not both) which
makes a smooth upgrade strategy impossible.
And if I peek at Merlin I fear that this is even worse - don't
get me wrong, I don't say Merlin is worse or Merlin is bad or
something like that. It's just that migration with regards
to Configuration is very hard.
So, this area lacks currently I think.
In addition, what I meant with my above statement is that you
should make sure that components in a component library not only
use all the latest available features of the latest container
version. They should also be runnable in older containers. For
example, if a component uses meta-info then it's not usable with
ECM. If a component uses meta-info that only Merlin supports,
than it's not useable with Fortress and so on.
The more I think about it, the more I come to the conclusion that
the current situation is bad. People, currently using ECM can
choose between Fortress and Merlin, but if they choose Fortress
they already know that they have to migrate sooner or later
to Merlin anyway.
People writing components have to choose for which container they
write components - obviously the container they are using.
So, perhaps it would really be better to forget Fortress and move
everything into Merlin but of course maintain the simplicity of
Fortress. Embedding Fortress into an own application is four or
five lines of Java code and some simple configuration file. That's
it.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [avalon] roadmap - library criteria
Posted by Stephen McConnell <mc...@apache.org>.
Carsten Ziegeler wrote:
> And make sure that the components run out-of the box in the
> most recent containers including at least Fortress (ECM would
> be good as well, but perhaps we can forget that one)
Carsten:
Thanks for the email - there are several points I would like to expand
on but that's for another thread. Concerning the above - I would like
to figure out a way in which we move you from a implementation
dependency to a service dependency. I.e. I don't want you to be
dependent on Fortress. I want you to be dependent on an API. If you
can define that API, I'm ready to take a shot a delivering an
implementation solution. Even better - if you can provide some test
cases, I'm ready to spend some time making sure we provide a sustainable
solution.
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [avalon] roadmap
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stephen McConnell wrote:
>
> Following the initial discussions on the pmc concerning
> avalon direction, roadmap, etc. I wanted to post my thoughts
> about Avalon and the direction over the next year.
>
> 1. Development Consolidation
> ----------------------------
>
> One api, one reference implementation.
+1, but please a simple to use one!
> Rather than launch
> into a A5 scenario, I am in favor of moving forward by
> building and evolving on A4
+10
> - no radical change - but some significant and important
> changes in the terms of depth.
Yes.
>
> 1.1 Starting with Avalon Framework 4.2
> --------------------------------------
>
> More and more I'm seeing the need for different levels of
> APIs. We have the A4 framework contract for classic
> container/component interaction - but room for evolution with
> respect to constructor management. I see this as an avalon
> framework 4.2 release.
>
Yes.
<SNIP 1.2 which I don't understand :) />
>
> 1.3 Reference implementation
> ----------------------------
>
> Probably the most important thing that will need to happen in
> the coming months is the elimination of different development
> directions. One component architecture - one development
> community - one roadmap. This involves the establishment of
> one and only one reference implementation
> - termination of divergent streams, and the focus by the
> community of the evolution of the reference implementation.
Sounds good, but as I wrote previously, the whole Avalon community
has to agree on which road to take and not only "the one doing
the work".
<SNIP 2 where I don't have an opinion yet/>
>
> 3. Avalon Component Library
> ---------------------------
>
Yes, please, a component library!
> There are a number of aspects to address with respect to an
> Avalon Library.
>
> 3.1 Compliance with Avalon-Meta and block packaging specs.
> ----------------------------------------------------------
>
> A most important factor is the requirement for single
> component model compliance. Usage of standard meta-info
> across the board, standard packaging of composite components,
> and a very complete and consistent approach to the definition
> of remotely deployable units. In other words
> - making sure that the component library is very easy to use
> and very simple to leverage.
>
And make sure that the components run out-of the box in the
most recent containers including at least Fortress (ECM would
be good as well, but perhaps we can forget that one)
<SNIP 3.2 and 3.3 - this should be discusses separately/>
In general, discussing these things is a very good thing!
Now, I think focusing on 4.2 as Stephen suggests is a very
good idea. In general, the next step could be to discuss
several aspects separately.
One major aspect/concern is currently imho logging (and I
will stress this point until I see a solution). There are
too many subprojects with circular dependencies and a
clear vision there is absolutely missing. If noone else
has a vision and will start a discusion about it, I will
do it in the next days.
So, keep on!
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org