incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Incubator Wiki] Updated: CastleProposal
Date Fri, 01 Oct 2004 18:36:37 GMT
   Date: 2004-10-01T11:36:37
   Editor: HamiltonVerissimo <>
   Wiki: Incubator Wiki
   Page: CastleProposal

   no comment

Change Log:

@@ -1,3 +1,4 @@
 ''' Proposal for new project Castle (Draft 1) '''
 ''01 Oct 2004, Hamilton Verissimo (hammett at apache dot org)''
@@ -7,163 +8,7 @@
 == Castle or Realm ==
 Temporary name.
-=== 1.1. Rationale ===
-A big empty space lies in the open source community for those who happens to use CLI 
-running on Windows (.Net Framework from MS) and|or Linux (Mono implementation). This empty
space refers to a model which set the example, as reference of how to build a Good Application
(tm) from the developer's point of view.
-Of course there are several aspects that contribute to create a Good Application, and from
our standpoint one them is Inversion of Control, which deserves attention. However the usage
of Inversion of Control is a matter of taste, and people should not feel obligate to use,
or might disagree with the benefits.
-Castle's goal is to provide a set of standalone tools and an Inversion of Control implementation
that provide a rendezvous point for these tools - and possible other - although they are totally
independent. Initially our set of tools will consist of:
-* Aspect#
-* DynamicProxy
-* ManagedExtensions
-* Castle Microkernel
-And the container
-* Windsor
-AOP is an AOP framework for CLI. It uses dynamic proxies to generate new types on the fly
which implements your aspect rules. Aspect# gained attention since the first day it was released.
It's easy to say why: its based on simplicity. We don't rely on creepy xml configuration files,
instead a simple configuration language (inspired by Ruby) was conceived. 
-Aspect# extends an application providing mixins and method interceptors easily. Within a
few months of existence, Aspect# had more than one thousand downloads.
-DynamicProxy generates proxies for interfaces or classes on the fly through the generation
of IL code, just like Java proxies, which is unavailable in CLI. 
-It's been used by Aspect#, NHibernate project and Castle and we already had some nice testemonials
and some suggestions for the next version.
-ManagedExtensions is an application extension inspired by Java Management Extensions. As
 JMX it directs the overall application architecture but simplify some other aspect like remoting
access to applications, configuration and service invocation.
-Castle Microkernel
-If one only wants a very simple - almost naive - Inversion of Control container to set up
and assemble his application he can rely on Castle Microkernel to do so. 
-The microkernel is easily extensible orthogonally, which means that features can be plugged
and transparently combined to achieve a major goal.
-Castle Windsor 
-If one wants a more complex container it can uses the Windsor container which extends the
Microkernel to provide a more complex solution. It aims to provide external configuration,
configuration overriding, subcontainers and a profile concept that will allow the user to
switch to different configurations modes, ie 'production', 'development', 'profiling'.
-The profile only defines a set of service implementation and facilities configurations.
-Castle's goal is to serve as an umbrella for some problem-resolution stardards and default
implementation of these standards - for the CLI world. Meanwhile it will provide a simple
yet powerfull inversion of control container.
-More Orthogonal extensions
-We're are concern to not reinvent the wheel, so we plan to offer adapters to existent open
source solutions provided that licenses are compatible with ASF. We plan to support, for instance:
-* PersistenceLayer
-  - Ibatis.Net
-  - NHibernate
-  - OJB.Net
-  - Prevayler
-* SecurityLayer
-  - To be analyzed
-* PresentationLayer
-  - Maverick.Net
-  - NVelocity
-  - ASP.Net (possibly not available due to Microsoft license, to be analyzed)
-Inspired by Ruby language and concepts we're going to provide a more easily way of configure
and use applications, in an attempt to avoid XML descriptors, complex deployments, complex
setup and steep learning curve. This is subject to research, but should be constantly in our
minds when planning and coding.
-==== 1.1.1. Criteria ====
-===== Meritocracy =====
-We've been living in meritocracy environment with the project we've been involved to and
even from our work environment. We plan to support meritocracy by all means, setting the example
with every message posted to the list.
-===== Community =====
-The Aspect# project have three developers involved, and the Castle container has only one.
This incubation process has the objective of attract more contributors, new ideas, new perceptions
and even new use cases that will drive our roadmap.
-===== Core Developers =====
-Currently only the people that are already involved with these projects. People that are
involved with this project as user may be invited to join our efforts as well.
-===== Alignment =====
-We're concern in not delivering only Microsoft CLI compatible code so the project must be
tested against Mono before being release. For logging purposes we're going to use log4net
available through the ASF Logging TLP.
-For building purposes we're currently using NAnt, which is a port of Apache ANT, but its
licensed as GPL. Test cases are implemented using NUnit, a port of JUnit, another standard
and is currently licensed as zlib/libpng License.
-==== 1.1.2. Warning Signs ====
-===== Orphaned products =====
-We've been using our projects in commercial applications to practice the eat-your-own-dog-food
and consequently improve the design and features as needed. However this is not enough and
this incubation process is exactly to make our community stronger.
-===== Inexperience with open source =====
-Just one committer is new to open source project environment, the others are involved with
open source for more than one year. Hamilton is a committer of with Apache Avalon, a PMC member
of Excalibur project and in the spare time browses the Geronimo source code looking for bugs.
-===== Homogenous developers =====
-Two of the developers share a common employer, but are not working on the project as salaried
employees. One had work with them but only communicates by email nowadays.
-===== Reliance on salaried developers =====
-Developers work on a volunteer basis. The project does not rely on salaried developers.
-===== No ties to other Apache products =====
-We plan to use Log4Net available in the Logging project. This is just the first CLI project
available in the ASF. 
-===== A fascination with the Apache brand =====
-We're fascinated by the Apache-Way, the meritocracy and community dynamics. We know that
being a committer ASF is guarantee of learning, not only how to develop software properly,
but how to grow a healthful community.
-==== 1.2. Scope of the subprojects ====
-Castle Container and Tools are the main subprojects. 
-==== 1.3. Identify the initial source from which the subproject is to be populated ====
-All Castle related code, DynamicProxy and ManagedExtension is on Avalon SVN repository. The
Aspect# code is on  sourceforge and is already licensed under Apache License 2.0
-==== 1.4. Identify the ASF resources to be created ====
-===== 1.4.1. mailing list(s) =====
-castle-ppmc via (with moderated subscriptions) 
-castle-dev via 
-castle-commits via 
-===== 1.4.2. Subversion repositories =====
-===== 1.4.3. Jira =====
-We plan to use XProject for issue tracking, based on Extremme programming. 
-==== 1.5. Identify the initial set of committers ====
-  * Hamilton Verissimo
-  * Rafael Steil
-  * Henry Conceicao
-==== 1.6. Identify Apache sponsoring individual ====
-..........., champion and mentor for the project, (as defined in

+=== 1.1. Item ===
+=== 1.2. Second item ===

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message