Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of eelco.hillenius@gmail.com
 designates 209.85.146.176 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=MKFKkSpvapdrStN/+50ILdepfOHdeqsc9r1IeadSmLYEqDQxLkax53EmZAUbAKkXHS
         kRH8Bc6js09VJ9/9NkDw3+oiU9PvslCQwxk+nu6xw4/zf15IbT3Jh85oPVjOy7JK+9Z9
         DcGa1/UMs9rbPowFLlZKu0tCHCI0gyXwr0Lrc=
Message-ID: <ceb609d80807170041r6032d1deuf30f53595ced868c@mail.gmail.com>
Date: Thu, 17 Jul 2008 00:41:07 -0700
From: "Eelco Hillenius" <eelco.hillenius@gmail.com>
To: general@incubator.apache.org
Subject: Re: Jt Pattern Oriented Framework (looking for champion/mentors)
In-Reply-To: <608276.37100.qm@web45712.mail.sp1.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <608276.37100.qm@web45712.mail.sp1.yahoo.com>

Hi Ed,

Judging from http://jt.dev.java.net/, there is one active person on
the project, and now discussion or other signs of community
whatshowever. Wouldn't it be a good idea to start building up a
community on that site first?

Regards,

Eelco


On Wed, Jul 16, 2008 at 8:19 PM, David S <dsheppard2k@yahoo.com> wrote:
>
> Hi folks,
>
> Our project (Jt Pattern Oriented Framework) is interested in joining the ASF incubator.
>
> After getting familiar with the incubator policies and procedures, we are looking for people interested in becoming a champion or a mentor.  We hope to learn more about ASF and pursue the proposal process.
>
> Additional information about this Open Source project can be found at http://jt.dev.java.net/
>
> The framework should address the following goals:
>
> A) The pattern oriented framework should implement and/or facilitate the implementation of well-known design patterns like GoF design patterns and J2EE Design patterns. The framework itself should be conceived and implemented based on design patterns (from the ground up). The framework should also facilitate and accelerate the implementation of applications based on design patterns.
> B) The framework architecture should be based on a messaging design pattern: framework objects should be able to interchange information and perform computations by sending, receiving and processing messages. A messaging API provides strong encapsulation and loose coupling; framework components can be easily plugged into complex framework applications using a "lego/messaging" architecture. The framework should take full advantage of the power and simplicity of the messaging design pattern.
> C) The framework lego/messaging architecture should provide transparent access to remote components: remote framework objects should be treated as local objects. Design patterns implemented by the framework (adapters, remote proxies and facades) should make this posible by hiding the complexities associated with remote APIs.
> D) The framework should provide transparent integration with other technologies via framework adapters, proxies and the implementation of related design patterns. These technologies include BPM, DAO implementations, MVC implementations, EJBs, JMS, XML and Web Services.
> E) The framework should be designed to be lightweight and fast in terms of performance (low overhead).
> F) The framework messaging/lego architecture should improve and simplify design/development efforts. There should be a tight correspondence between UML design diagrams and the framework messaging based applications and components needed for the implementation. Ideally, the framework should provide wizards and automated capabilities for generating framework applications. Framework components should be easily added to BPM process diagrams. In future versions of the framework, it should be possible for applications to be generated directly from the UML design diagrams.
> G) The framework messaging architecture should facilitate testing and debugging efforts. The framework should provide capabilities for testing components independently (each component as a unit) by sending messages and verifying the reply (output) messages.
> H) In order to provide additional productivity benefits, the framework should be integrated with open source IDEs.
>
> Thanks in advance for your feedback and suggestions.  I look forward to hearing from you.
>
> Ed
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org