incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David S <>
Subject Re: Jt Pattern Oriented Framework (looking for champion/mentors)
Date Fri, 18 Jul 2008 03:24:38 GMT
Hi Eelco,

The project site contains mainly technical/download information. We haven't been using it
for anything else (mailing list, forums, etc). We believe the Apache incubator would be a
better venue for building community. Everyone interested in contributing is welcome. On the
other hand the framework is probably one of the few pattern oriented frameworks (especially
open source). The framework (version 2.6) has also been used as part of several production



--- On Thu, 7/17/08, Eelco Hillenius <> wrote:
From: Eelco Hillenius <>
Subject: Re: Jt Pattern Oriented Framework (looking for champion/mentors)
Date: Thursday, July 17, 2008, 7:41 AM

Hi Ed,

Judging from, 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?



On Wed, Jul 16, 2008 at 8:19 PM, David S <> 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
> 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:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message