Hi gang!

Introduction
------------
Based on the recent "Where do you want to go?", "How do we get there?", "Feeler question: What is Avalon's mission?", "Avalon's Image" and other threads, but mostly based on my own multi-month evaluation of avalon's direction, I felt I needed to rethink my relationship to the avalon project.


I've considered every option available to me thoroughly and consulted with several peeps about each of them. In conclusion...

What I'm going to do
--------------------
I am going to build a container from scratch. Actually, I've already started.


Where I am going to do it
-------------------------
I've set up a sourceforge project:

http://jicarilla.org/

Why I am doing it
-----------------
This is the container I need, and this is the easiest, fastest and least offensive or intrusive (for others) way to develop it.


Furthermore, I'm pretty annoyed by the fact that the IoC/COP world, which *should* be about *portable* and *reusable* components, is hindered by a dozen incompatible implementations. Actual portability of code is worse than with, for example, a static factory design, EJBs, etc. I'm determined to solve that.

Why I am not doing it here
--------------------------
Like I wrote before...

1) merlin is great for users;
2) there's a lot of development going on surrounding merlin;
3) merlin is not so great for some developers, like me;
4) merlin is not so great for some use cases, like mine;
5) I myself am not capable of changing #3 an #4 without impacting
   #1 and #2;
6) I believe merlin needs to be the future for avalon, and active or
   radical new development around fortress or any other codebase would
   be bad for avalon as a community.

"This inevitably leads to the logical conclusion that" there is no way for me to build the container I want in the way I want, here, without causing negative side-effects to the avalon development and user community (and thus the ASF as a whole).

Why I am not doing it somewhere else
------------------------------------
Similar reasons.

My position at avalon
---------------------
Nothing changes, really. I will stay committer, pmc member, and generally vocal person. I will do no more or less development on merlin or fortress than I have in (roughly) the last 6 months (which isn't much); and the same goes for all the other codebases (which is a bit more).


I'm going to stop voicing my opinion on merlin though unless explicitly asked for it.

Can others participate?
-----------------------
Sure, everyone is welcome. But for now, I suggest everyone evaluates avalon-merlin, avalon-fortress, picocontainer and nanocontainer first (in that order, perhaps) and participate there; make sure neither of those projects fits your needs. This because the jicarilla codebase is still very young and in a state of constant flux.


Cross-pollination, opinionisms, advertising, etc
------------------------------------------------
I will use my own judgement in figuring out when it is appropriate to mention something about my progress here, *unless* enough people tell me not to (in which case I promise I will shut up).


So what am I doing?
-------------------
Here's my planned feature list:

* The 'standard' stuff
    * compact
    * fast
    * secure
    * reliable
    * extensible
    * modular
    * performant
* It is going to be compatible on a component level (as in what
  components it can run) with
    * core avalon-framework
    * avalon-ecm
    * avalon-fortress
    * avalon-phoenix
    * picocontainer
    * springframework
    * xwork
    * loom
    * dna
    * eob
    * keel
    * possibly others
* It is going to be compatible on an interface level (as in thin
  wrappers will be available around the container code to serve as
  drop-in replacement) with
    * core avalon-framework (ServiceManager, ComponentManager)
    * avalon-fortress
    * picocontainer
    * springframework
    * possibly others
* It will be able to integrate other component solutions through
    * jndi
    * jmx
    * altrmi
    * possibly soap
* the core will be "code only", meaning that there will be no dependency
  on any kind of non-java file.
* the core will be conservative about threading, meaning that any
  usage of multiple threads will be pluggable.
* the core will be environment-friendly, meaning that it should be
  simple to use in different environments.
* support code for use of the core inside several environments will be
  provided:
    * standalone (CLI)
    * standalone (GUI)
    * standalone (daemon)
    * embedded (servlet)
    * embedded (ejb)
    * embedded (avalon component)
    * embedded (picocontainer)
    * embedded (fortress)
    * exported (jndi)
    * exported (jmx)
    * possibly: embedded (JBoss)
    * possibly: embedded (merlin)
    * possibly: embedded (phoenix)
    * possibly: embedded (loom)
    * possibly: exported (soap)
    * possibly: exported (altrmi)

I've got the basic container in place, and some proof-of-concept materials like avalon, spring and picocontainer integration is in place as well. I've also set up all the 'support architecture' like mailing lists, wiki and build system that I thikn I need.

What am I building it for?
--------------------------
I'm going to use this container as the basis for developing a complete http server from the ground up (I've always wanted to write my own http implementation).


On top of that I will build a media server. I will also develop a multimedia client to connect to the media server. These latter two will likely not be open source, but the http server will be.

How am I building it?
---------------------
The architecture borrows heavily from picocontainer, but makes many compromises in order to make it simpler to support the compatibility and integration goals (and it contains some things I consider improvements on the basic picocontainer design). The architecture is based on inversion of control, seperation of concerns, seperation of interface from implementation and (contract-based programming). Furthermore, extensions will be available to support aspect-oriented programming and event-based programming.


Code development atm doesn't quite follow an XP or Agile process, but there is a focus on testing, incremental development, "doing the simplest thing that can possibly work", use case analysis, etc.

--
cheers,

- Leo Simons

-----------------------------------------------------------------------
Weblog              -- http://leosimons.com/
IoC Component Glue  -- http://jicarilla.org/
Articles & Opinions -- http://lsd.student.utwente.nl/jicarilla/Articles
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
 people wouldn't obey the rules."
                                                        -- Alan Bennett



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to