nicolaken 2003/10/08 06:58:40
Added: src/documentation/content/xdocs/projects/geronimo
geronimo-proposal.xml geronimo.xml STATE.txt
STATUS.cwiki
src/documentation/content/xdocs/projects index.cwiki
src/documentation/content/xdocs/projects/pluto pluto.xml
STATUS.cwiki
src/documentation/content/xdocs/projects/tapestry
PROPOSAL.txt STATUS.txt
src/documentation/content/xdocs/projects/jaxme STATUS.cwiki
src/documentation/content/xdocs/projects/juddi STATUS.cwiki
src/documentation/content/xdocs/projects/wsrp4j STATUS.cwiki
src/documentation/content/xdocs/projects/xmlbeans
STATUS.cwiki
src/documentation/content/xdocs/projects/template
STATUS.cwiki
Removed: src/documentation/content/xdocs/projects
geronimo-proposal.xml geronimo.xml index.xml
pluto.xml
Log:
First stab at a global information about incubation status for all projects.
Revision Changes Path
1.1
incubator/src/documentation/content/xdocs/projects/geronimo/geronimo-proposal.xml
Index: geronimo-proposal.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN"
"document-v11.dtd">
<document>
<header>
<title>Proposal for an Apache J2EE Server Project</title>
<authors>
<person name="The Apache Incubator Project"
email="[email protected]" />
</authors>
<abstract>Apache Geronimo - J2EE Container</abstract>
</header>
<body>
<section>
<title>Submission Date and Submitters</title>
<p>
05 Aug 2003 : Geir Magnusson Jr., James Strachan and Richard Monson-Haefel
</p>
</section>
<section>
<title>Section 0 : Rationale</title>
<p>
The Java 2, Enterprise Edition (J2EE) platform is employed widely by
organizations implementing enterprise applications. It is commonly used in
business-to-consumer and most recently in Web service deployments. Most
of
the largest business organizations today have deployed applications on a
J2EE platform.
</p>
<p>
While the J2EE specification is implemented by a number of large and small
vendors, there is no open source J2EE container available with a BSD or
BSD-derived licence nor is there an open source project today that
provides
a fully compliant implementation. Verifiable compliance with the J2EE
specification is important to business because it ensures that
applications
deployed by developers are portable and interoperable across J2EE
providers.
As a result organizations large and small have felt compelled to pay
thousands of dollars to commercial vendors in order to deploy applications
based on J2EE compliant servers.
</p>
<p>
The Apache foundation supports several projects that implement pieces of
the
J2EE platform such as Servlets, JSP, Tag Libraries, and a Web services
stack. However, Apache does not currently support a J2EE project.
</p>
<p>
The aim of the project is to produce a large and healthy community of J2EE
developers tasked with the development of an open source, certified J2EE
server which is ASF licensed and passes Sun's TCK reusing the best ASF/BSD
licensed code available today and adding new code to complete the J2EE
stack.
</p>
</section>
<section>
<title>Section 0.1 : criteria</title>
<p>
We feel that this project has a good chance for success as the following
project aspects are carefully considered :
</p>
<ul>
<li>
Meritocracy: The project will be meritocratic - the usual Apache
meritocracy rules would apply.
</li>
<li>
Community: The user community for this project is potentially massive.
The initial developer community for this project consists of developers
from
Apache, Castor, JBoss, mx4j, and OpenEJB projects. The aim is for this
community to grow considerably once this project goes public.
</li>
<li>
Core Developers: The initial developers are listed below and consist of
some existing Apache committers together with committers from Castor,
JBoss, mx4j and OpenEJB. We believe that as the project grows, the
modular
nature of the J2EE stack will require steady expansion of the committer
group that is considered 'core' - thus providing a healthier, more robust
developer community.
</li>
<li>
Alignment: There is clear alignment with many existing Apache projects.
From Jakarta projects such as Tomcat, James and log4j initially as well as
possibly others along the way. J2EE now includes a web services stack and
so
there will be some alignment with the WS project, Axis in particular,
along
with the reuse of several XML projects. In addition the J2EE Server
project
may reuse other ASF/BSD licensed code which is not currently hosted in
source form at Apache such as (at time of writing) mx4j, openjms and
tyrex.
</li>
</ul>
<p>
However we see the J2EE Server project as a separate project to existing
Apache projects, serving two primary roles
</p>
<ul>
<li>
integration of various existing and new code bases into a J2EE stack,
with those codebases existing both inside and outside of the project
</li>
<li>
certification of the J2EE stack
</li>
</ul>
<p>
Note that the J2EE server project can happily support competition within
the
J2EE services stack (for example, offering choices for elements such as
the
servlet engine like Tomcat or Jetty, or some new JTA implementation versus
Tyrex or some new JMS implementation versus OpenJMS etc).
</p>
</section>
<section>
<title>Section 0.2 : warning signs</title>
<p>
We feel that this project has a good chance for success as the following
warning signs do not apply to the project we are proposing :
</p>
<ul>
<li>
Orphaned products: This project is starting with a new code base together
with reusing lots of the currently available high quality J2EE open source
code out there which is ASF/BSD licensed.
</li>
<li>
Inexperience with open source: The initial community is made up of
existing Apache, Castor, JBoss, mx4j , and OpenEJB committers.
</li>
<li>
Homogeneous developers: The current list of committers represents
developers from various backgrounds and open source projects, employed by
various companies and based around the globe in the US, Europe, Asia and
Australia. There will be no majority bloc, at least from the start.
</li>
<li>
Reliance on salaried developers: None of the initial developers are
currently paid to work on the J2EE project.
</li>
<li>
No ties to other Apache products: The J2EE Server project is
complementary to existing technologies at Apache. Indeed it will integrate
many of those technologies in an effort to provide a code base that can be
J2EE certified according to the JCP process.
</li>
<li>
A fascination with the Apache brand: The committers are interested in
developing a healthy open source community around an ASF/BSD licensed J2EE
certified server, whether Apache is the right place or not. The aspects
of
Apache that attract this effort are the experienced stewardship of open
source projects by the ASF, the non-profit status of the ASF for TCK
certification, and the existing Java community that has been a
longstanding
part of the ASF.
</li>
</ul>
</section>
<section>
<title>Section 1 : scope of the project</title>
<p>
There are two main aspects to this Apache project :
</p>
<ul>
<li>
a complete J2EE certified server which is fully ASF/BSD licensed and
backed by a healthy open source community.
</li>
<li>
to create a fully modular J2EE stack so that the Apache community can use
whichever parts of the J2EE stack they require separate from the J2EE
server
project.
</li>
</ul>
</section>
<section>
<title>Section 2 : initial source from which the project is to be
populated</title>
<p>
There are several potential initial contributions. Upon formation of the
project our first action will be an open, public call for contribution and
comment from the J2EE community. Because of recent circumstances in the
J2EE OSS community, all code proposed for inclusion must be publicly
reviewed and open to public comment.
</p>
</section>
<section>
<title>Section 3: identify the ASF resources to be created</title>
<section>
<title>Section 3.1 : mailing lists</title>
<ul>
<li>
geronimo-dev
</li>
<li>
geronimo-user
</li>
</ul>
</section>
<section>
<title>Section 3.2: CVS repositories</title>
<ul>
<li>
geronimo
</li>
</ul>
</section>
<section>
<title>Section 3.3: Bugzilla</title>
<ul>
<li>
geronimo
</li>
</ul>
<p>
Though would there be an issue with using JIRA?
</p>
</section>
</section>
<section>
<title>Section 4: identify the initial set of committers</title>
<p>
The committers are listed below, along with the open source project(s)
where
they also have commit privileges.
</p>
<ul>
<li>
Bruce Snyder (Castor JDO)
</li>
<li>
Dain Sundstrom (JBoss)
</li>
<li>
David Blevins (OpenEJB)
</li>
<li>
David Jencks (JBoss)
</li>
<li>
Geir Magnusson Jr. (Apache)
</li>
<li>
Greg Wilkins (JBoss/Jetty)
</li>
<li>
James Strachan (Apache)
</li>
<li>
Jan Bartel (JBoss/Jetty)
</li>
<li>
Jason Dillon (JBoss)
</li>
<li>
Jeremy Boynes (JBoss)
</li>
<li>
Jim Jagielski (Apache)
</li>
<li>
Jules Golsnell (JBoss/Jetty)
</li>
<li>
Richard Monson-Haefel (OpenEJB)
</li>
<li>
Remigio Chirino (JBoss)
</li>
<li>
Simone Bordet (mx4j)
</li>
</ul>
</section>
<section>
<title>Section 5: identify apache sponsoring individual</title>
<ul>
<li>
Ceki Gulcu
</li>
<li>
Geir Magnusson Jr.
</li>
<li>
James Strachan
</li>
<li>
Jim Jagielski
</li>
</ul>
</section>
</body>
</document>
1.1
incubator/src/documentation/content/xdocs/projects/geronimo/geronimo.xml
Index: geronimo.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN"
"document-v11.dtd">
<document>
<header>
<title>Apache Geronimo</title>
<authors>
<person name="The Apache Incubator Project"
email="[email protected]" />
</authors>
<abstract>Apache Geronimo - J2EE Container</abstract>
</header>
<body>
<section>
<title>Overview</title>
<p>
Apache Geronimo is a new effort coordinated by the Apache Software
Foundation to make a
J2EE compatible container. Please read the <link
href="geronimo-proposal.html">proposal</link>
that started the project in the incubator.
</p>
<p>
For more information, please read the latest snapshot of the <link
href="#FAQ">FAQ</link> below
or look <link
href="http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheJ2EE/FAQ";>here</link>
for the live one.
</p>
<p>
This is the official site for Geronimo while it's in the incubation
phase at Apache.
We have an alpha version of our
<link href="http://www.apache.org/~jstrachan/geronimo/";>future project
site</link>.
</p>
</section>
<section>
<title>How do I get Involved?</title>
<p>
<strong>Quick Summary</strong>
</p>
<ul>
<li>
Subscribe to the <link href="#Mailing+Lists">mail lists</link>
</li>
<li>
Download code and materials from <link
href="#Where+is+the+source+and+download%3F">CVS</link>
</li>
<li>
Read the <link href="#FAQ">FAQ</link>
</li>
<li>
Participate and contribute!
</li>
</ul>
<p>
The most important step is to join the <link
href="#Mailing+Lists">mailing list</link>
It is not necessary to post a "Hi" message or to join the project.
By subscribing to
the list, you're joining the project. After that, it is all down to
participation.
</p>
<p>
As with all <link href="http://www.apache.org/";>Apache</link>
projects, the usual form is to get the
project's source via CVS tools, join the mailing list(s), find
something to do, and submit a patch to the mailing list for
their approval and application.
</p>
<p>
We assume that patch donators
are familiar with CVS, diff and patch. If you are not
familiar with those tools, or want additional information
about how things work, here are some links:
</p>
<ul>
<li>
<link href="http://www.apache.org/dev/contributors.html";>Apache
Contributors Technical Guide</link>
</li>
<li>
<link
href="http://jakarta.apache.org/site/getinvolved.html";>Jakarta's Get Involved
page.</link>
</li>
</ul>
<p>
Geronimo, if it passes the incubation stage, will become an
<link href="http://www.apache.org/";>Apache</link> project.
As an Apache project, the Apache approach to open source community and
development will apply. If you aren't familar with how things are
done
by Apache projects, please familiarize yourself with the information
available on the <link href="http://www.apache.org";>site</link>.
Here are some good selections from the Jakarta project site that
should help you understand the Apache community process :
</p>
<ul>
<li>
<link href="http://jakarta.apache.org/site/roles.html";>Roles and
Responsibilities</link>
</li>
<li>
<link href="http://jakarta.apache.org/site/decisions.html";>Decision
Making</link>
</li>
<li>
<link href="http://jakarta.apache.org/site/source.html";>Source
Repositories</link>
</li>
</ul>
</section>
<section>
<title>Mailing Lists</title>
<p>
Apache Geronimo has two mailing lists of interest, the
geronimo-dev list, where all the discussion
occurs, and the geronimo-cvs list, which receives commit mails each
time a commit is made to the incubator-geronimo <link
href="#Where+is+the+source+and+download%3F">CVS</link> module.
</p>
<p>
You can subscribe to the mailing lists by sending an email to
one or both of the following addresses :
</p>
<ul>
<li><link href="mailto:[EMAIL PROTECTED]">[EMAIL
PROTECTED]</link></li>
<li><link href="mailto:[EMAIL PROTECTED]">[EMAIL
PROTECTED]</link></li>
</ul>
<p>
To send a message to the Geronimo mailing list without subscribing,
try the following link:
</p>
<ul>
<li><link
href="mailto:[email protected]";>[email protected]</link></li>
</ul>
<p>
<strong>However</strong>,
unless you subscribe to the list, you may not get a response.
Subscribing to the list
is how you join the project, and follow events.
</p>
<p>
There is also a <link
href="http://nagoya.apache.org/eyebrowse/SummarizeList?listId=140";>mailing list
archive</link>,
where you can catch up on prior discussion.
</p>
</section>
<section>
<title>The Wiki</title>
<p>
The project Wiki is <link
href="http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheJ2EE";>here</link>.
</p>
</section>
<section>
<title>Where is the source and download?</title>
<p>
We have a number of code donations "on deck" which are being
evaluated. Once those donations are processed, then they will
be checked into the Apache Geronimo CVS module.
</p>
<p>
The CVS module is named <code>incubator-geronimo</code>. Here is
an example of checking out Apache Geronimo with the CVS
command-line client:
</p>
<source>
$ export CVSROOT=:pserver:[EMAIL PROTECTED]:/home/cvspublic
$ cvs login
Logging in to :pserver:[EMAIL PROTECTED]:2401/home/cvspublic
CVS password:
$ cvs checkout incubator-geronimo
...
</source>
<note>
Use "anoncvs" for the anoncvs user's CVS password.
</note>
<p>
The code can be browsed through ViewCVS at
<link
href="http://cvs.apache.org/viewcvs/incubator-geronimo/";>http://cvs.apache.org/viewcvs/incubator-geronimo/</link>.
</p>
</section>
<section>
<title>FAQ</title>
<note>
Updated : 2003-08-07 1500 GMT
</note>
<note>
The following is a snapshot from the FAQ on the Apache Wiki. It's here for
your convenience, but may be out of date at any moment.
For the
updated FAQ, please go <link
href="http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheJ2EE/FAQ";>here</link>.
</note>
<p>
These are questions that have come up on the mailing list so far. They are
unofficial, but are best efforts by community members to record useful answers.
</p>
<p>
Some questions are unanswered as yet. Have an answer? Please discuss it on
the mailing list, and record the conclusion here.
</p>
<p>
<strong>Q: I'd like to find out more and help etc. What do I do next?</strong>
</p>
<p>
A: Participation on the project is via the mailing list and the source code
repository. You join by joining the mailing list, and by participating in
discussion. You help by contributing your ideas, enthusiasm, code,
documentation, tests, and intangibles.
</p>
<p>
The fundamental tenet of the ASF is that Great Communities build great code.
The emphasis is on Community; the code comes from that. If you want to help,
just join the mailing list, see what needs to be done, and do it.
</p>
<p>
Welcome. :-)
</p>
<p>
<strong>Q: Where is the mailing list? How do I subscribe?</strong>
</p>
<p>
A: The mailing list is [EMAIL PROTECTED] You subscribe by sending e-mail to
<link href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</link>.
</p>
<p>
<strong>Q: Is there an archive?</strong>
</p>
<p>
A: <link
href="http://nagoya.apache.org/eyebrowse/SummarizeList?listId=140";>[Apache J2EE
Archives]</link>
</p>
<p>
<strong>Q: Can you mail me if you're interested in me helping.</strong>
</p>
<p>
A: That's not how open source communities generally work. To the people who
have asked to be contacted if Apache are interested, it's unlikely that this
will happen with all the huge interest that this has generated. Better to stay
in touch with the mailing list.
</p>
<p>
<strong>Q: Where is the Apache CVS module</strong>
</p>
<p>
A: incubator-geronimo <link
href="http://cvs.apache.org/viewcvs/incubator-geronimo";>[Browse CVS]</link>
</p>
<p>
<strong>Q: The CVS module is empty, is there an issue</strong>
</p>
<p>
A: No. The initial committers have not publicly released the base code. Be
patient.
</p>
<p>
<strong>Q: Will it involve JBoss code.</strong>
</p>
<p>
A: No.
</p>
<p>
This is a new Apache project, running under Apache guidelines. The Apache
Software Foundation accepts only voluntary contributions of material from
authors who possess the legal right to donate it.
</p>
<p>
<strong>Q: Will it <insert some technical phrase here>?</strong>
</p>
<p>
A: It's probably worth holding these questions off for the moment. This
project is bringing together members and contributions from many existing J2EE
communities, and is just starting to come together.
</p>
<p>
<strong>Q: What are the rules for Geronimo?</strong>
</p>
<p>
A: See the <link href="http://incubator.apache.org/";>[Apache
Incubator]</link> web site.
</p>
<p>
<strong>Q: What's the website?</strong>
</p>
<p>
A: <link href="http://incubator.apache.org/projects/geronimo.html";>[Apache
J2EE Project]</link>
</p>
<p>
<strong>Q: What tools do I need to learn?</strong>
</p>
<p>
A: CVS. patch. Using a mail list.
</p>
<p>
<strong>Q: Relationship to JBoss and in particular, the JBoss source
base.</strong>
</p>
<p>
A: Several (former) JBoss committers are Geronimo committers. The JBoss
codebase cannot, and will not, be used, at all (it is LGPL).
</p>
<p>
<strong>Q: Does Geronimo replace Tomcat, JSTL etc.</strong>
</p>
<p>
A: No. Geronimo includes other services like Tomcat or Jetty for the web
container, OpenJMS for the JMS, Tyrex for the transaction manager etc. So
Geroimo focusses on being the J2EE container allowing other services to drop in
via JMX.
</p>
<p>
<strong>Q: What other projects will Geronimo reuse?</strong>
</p>
<p>
A: We suspect in the grand scheme of things to reuse various existing open
source projects. Anything which has a suitable BSD / ASF licence is up for
grabs. e.g. the following is a likely list of the things well be using (though
in no way is this definitive)...
</p>
<p>
From the ASF licenced projects...
</p>
<ul>
<li> MX4J for JMX </li>
<li> Tomcat or Jetty for Web Container </li>
<li> Axis for Web Services Stack </li>
<li> James for email </li>
<li> OJB for JDO </li>
<li> commons-jndi for JNDI </li>
</ul>
<p>
As well as some non-ASF licenced stuff which is BSD licenced
</p>
<ul>
<li> OpenJms for JMS </li>
<li> Tyrex for Transaction Manager </li>
</ul>
<p>
As well as the usual infrastructure...
</p>
<ul>
<li> commons-logging / log4j for logging </li>
<li> Xerces for XML parsing </li>
<li> maybe more of JakartaCommons as needed </li>
<li> Maven for building the distributions & website </li>
<li>JUnit for unit testing </li>
</ul>
<p>
(1) There is currently a JNDI implementation in Tomcat's CVS. It might be
better to move this to Jakarta Commons so we can all work & extend it -
there are various features from Jetty and OpenEjb we'd like to add?
</p>
<p>
<strong> Q: Administration Overview such as an amalgamation of many projects
or one large project with subject areas.</strong>
</p>
<p>
<strong>Q: Timeline to 1.0 (what does it include).</strong>
</p>
<p>
<strong>Q: Will Geronimo be compliant with Sun's CTS.</strong>
</p>
<p>
<strong>Q: What is Geronimo's Architectural vision and what does the back
plane look like (i.e., is it JMX based?).</strong>
</p>
<p>
<strong>Q: What standards are targeted and which are under active
development?</strong>
</p>
</section>
</body>
</document>
1.1
incubator/src/documentation/content/xdocs/projects/geronimo/STATE.txt
Index: STATE.txt
===================================================================
From [EMAIL PROTECTED] Mon Sep 8 08:06:42 2003
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Reply-To: [email protected]
Delivered-To: mailing list [email protected]
Date: Sat, 6 Sep 2003 16:11:25 -0500
Subject: State of the Project
From: Dain Sundstrom <[EMAIL PROTECTED]>
To: [email protected]
Message-Id: <[EMAIL PROTECTED]>
The first month of our project has seen a deluge of volunteers, email
and code. Indeed, for the first few days we had so many volunteers
that it was almost impossible to keep up with the influx. Many of the
initial volunteers stuck around and are actively participating. The
email volume of the last month is shocking. We have had over three
thousand messages on the list, and for the first few days we were
getting hundreds of emails a day. The volume has settled down to a
much more manageable level, and the discussions have improved as a
result. It has been amazing to see the small code seed we started with
grow into a two and a half megabyte source bundle. Even with this
massive growth, the code base has remained stable (the build has only
been broken a few times).
Given these signs, we declare the state of the project to be healthy
and vibrant.
The momentum of the project is huge, and it appears we have reached the
critical mass required for a success. However, we have some challenges
to overcome. One of these is the nature of discussions on the mailing
list - we have had many bike shed type discussions thrashing minute
details to death but choking out larger topics. In some cases, this
has resulted in contributors collaborating offline and major changes
happening with little public discussion. This issue is gradually
working itself out, but we all need to be aware of this tendency and
work to keep discussions on the list more focused.
Another challenge facing us is how to grow the committer base. There
is some perception of a cathedral clique of insiders, whereas in
reality, many of the project management issues have arisen because the
current committers are not used to working together and are new to the
Apache Way. With the initial startup phase behind us, we will be
looking to expand the project rapidly over the next couple of months.
Geronimo is a complex project with many collaborating subsystems and
significant progress has been made in many areas.
BUILD SYSTEM
Our build system came together surprisingly quickly. We have support
for multiple modules and an amazing auto-generated web site from maven.
Jason Dillon is currently working out the structure of our final
build, and Dain Sundstrom and David Blevins will be setting up an
integration testing system next week.
SPECIFICATION APIs
Some of the least exciting but most critical work has been the
provision of unencumbered versions of the specification APIs. Credit
goes to Maas van den Berg and Aaron Mulder for much of this work, with
a special mention of Alex Blewitt for diligently building out the
JavaMail API which contains substantial concrete implementation.
SERVICE FOUNDATION
Using JMX as a kernel technology has facilitated the manageability of
the system. A GeronimoMBean has been added, intended to be the basis
for other services in Geronimo. This MBean provides support for
multiple managed objects and implements the managed object, state
manageable and event provider interfaces from the J2EE Management
specification. Dain Sundstrom will be adding persistence capability,
allowing the server configuration to be preserved between restarts.
CONSOLE
A console subsystem is in progress with web and command-line based
interfaces under development by N. Alex Rupp and Matt Kurjanowicz.
There are also plans for a GUI console once a common structure has been
determined.
DEPLOYMENT
A common deployment architecture has been defined, supporting local and
remote modules, dependencies between deployed components, and pluggable
deployment strategies. Currently deployment is provided for service
archives containing MBeans; support will be added soon for Web, EJB and
Connector modules. Scanners have been implemented for both local and
remote (WebDAV) filesystems.
REMOTING
Hiram Chirino has implemented a remoting framework for routing
invocation requests both within and between VMs, freeing containers
from the need to handle wire protocols and failover. The current code
supports both synchronous and asynchronous communication and is built
on NIO. Future work will add IIOP support using the simple RMI/IIOP
ORB, allowing us to meet the requirements of the J2EE specification.
METADATA
We have defined a format for Geronimo-specific deployment descriptors
and have added a basic object model for representing them in memory. A
simple loader is in place based on Xerces and DOM, and investigation is
proceeding into more effective XML binding based on the XMLBeans
project. Aaron Mulder has been responsible for much of the initial
implementation, and he is continuing work on J2EE Deployment (JSR 88)
and Validation.
CLIENT CONTAINER
Jeremy Boynes has implemented an Application Client Container as a
starting point for enterprise container functionality. This includes a
simple implementation of the java:comp Environment Naming Context with
support for env-entry and ejb-ref elements. Basic interoperability
with external J2EE servers has been tested and full support will come
with the introduction of IIOP remoting.
SECURITY
A start has been made on security by David Blevins and Alan Cabrera in
the form of a JACC (JSR 115) implementation which, combined with JAAS,
will provide a pluggable authentication and authorization framework.
With many of the basic services now in place, we expect to start work
soon on the EJB containers and hopefully will have Session and BMP
Entity support available within the next month.
In other areas, co-ordination has started with the OpenJMS and LDAPd
projects to facilitate the integration of technology, and discussion
has started with ObjectWeb to allow the sharing of technology between
the two projects.
This has been a phenomenal first month in which huge progress has been
made. Much of the technical groundwork has now been laid and we can
look forward to the challenges of the EJB and Connector subsystems.
The Geronimo Project
1.1
incubator/src/documentation/content/xdocs/projects/geronimo/STATUS.cwiki
Index: STATUS.cwiki
===================================================================
!Identify the project to be incubated
*Make sure that the requested project name does not already exist
and check www.nameprotect.com to be sure that the name is not
already trademarked for an existing software product.
*If request from an existing Apache project to adopt an external
package, then ask the Apache project for the cvs module and mail
address names.
*If request from outside Apache to enter an existing Apache project,
then post a message to that project for them to decide on acceptance.
*If request from anywhere to become a stand-alone PMC, then assess
the fit with the ASF, and create the lists and modules under the
incubator address/module names if accepted.
!Interim responsibility
*Who has been identified as the shepherd for the incubation?
*Are they tracking progress in the file
incubator/projects/{project_name}/STATUS
!Copyright
*Have the papers that transfer rights to the ASF been received?
It is only necessary to transfer rights for the package, the
core code, and any new code produced by the project.
*Have the files been updated to reflect the new ASF copyright?
Verify distribution rights:
*For all code included with the distribution that is not under the
Apache license, do we have the right to combine with Apache-licensed
code and redistribute?
*Is all source code distributed by the project covered by one or more
of the following approved licenses: Apache, BSD, Artistic, MIT/X,
MIT/W3C, MPL 1.1, or something with essentially the same terms?
!Establish a list of active committers
*Are all active committers in the STATUS file?
*Do they have accounts on cvs.apache.org?
*Have they submitted a contributors agreement?
!Infrastructure
*CVS modules created and committers added to avail file?
*Mailing lists set up and archived?
*Problem tracking system (Bugzilla)?
*Has the project migrated to our infrastructure?
!Collaborative Development
*Have all of the active long-term volunteers been identified
and acknowledged as committers on the project?
*Are there three or more independent committers?
[The legal definition of independent is long and boring, but basically
it means that there is no binding relationship between the individuals,
such as a shared employer, that is capable of overriding their free
will as individuals, directly or indirectly.]
*Are project decisions being made in public by the committers?
*Are the decision-making guidelines published and agreed to by
all of the committers?
!Organizational acceptance of responsibility for the project
*If graduating to an existing PMC, has the PMC voted to accept it?
*If graduating to a new PMC, has the board voted to accept it?
!Incubator sign-off
*Has the Incubator decided that the project has accomplished all
of the above tasks?
1.1
incubator/src/documentation/content/xdocs/projects/index.cwiki
Index: index.cwiki
===================================================================
!Projects Being Incubated
!!AltRMI
A transparent Remote Procedure Call bean.
Incubation
* [STATUS|altrmi/STATUS.html]
* sponsor: Incubator PMC
* mentor: Nicola Ken Barozzi
Resources
* website: [http://incubator.apache.org/projects/altrmi]
* CVS: incubator-altrmi
!!FtpServer
A complete FTP Server based on [Avalon|http://avalon.apache.org] principles.
Incubation
* [STATUS|ftpserver/STATUS.html]
* sponsor: Incubator PMC
* mentor: Nicola Ken Barozzi
Resources
* website: [http://incubator.apache.org/projects/ftpserver]
* CVS: incubator-ftpserver
!!WSRP4J
Implementation of OASIS Web Services for Remote Portlets (WSRP).
Incubation
* [STATUS|wsrp4j/STATUS.html]
* sponsor: Webservices PMC
* mentor: ?
Resources
* website: http://ws.apache.org/wsrp4j/
* CVS: ?
!!JaxMe
Implementation of JAXB, the specification for Java/XML binding.
Incubation
* [STATUS|wsrp4j/STATUS.html]
* sponsor: Webservices PMC
* mentor: ?
Resources
* website: http://ws.apache.org/jaxme/
* CVS: ?
!!Pluto
JSR 168 Reference Implementation.
Incubation
* [STATUS|pluto/STATUS.html]
* sponsor: ?
* mentor: ?
Resources
* website: http://ws.apache.org/jaxme/
* CVS: ?
!!Apache Geronimo
J2EE Container.
Incubation
* [STATUS|geronimo/STATUS.html]
* sponsor: Apache Board
* mentor: Greg Stein
Resources
* website: ?
* CVS: ?
!!XMLBeans
XML-Java binding tool that uses XML Schemas as a specification.
Incubation
* [STATUS|xmlbeans/STATUS.html]
* sponsor: Xml PMC
* mentor: ?
Resources
* website: [http://xml.apache.org/xmlbeans/]
* CVS: ?
!!Lenya
Open-Source Content Management and publishing system, based on open standards
such as XML and XSLT and incubated inside the [Cocoon|http://cocoon.apache.org]
project.
Incubation
* [STATUS|lenya/STATUS.html]
* sponsor: Cocoon PMC
* mentor: Nicola Ken Barozzi
Resources
* website: [http://cocoon.apache.org/lenya/]
* CVS: cocoon-lenya
!Projects peviously Incubated.
*[Tapestry|http://jakarta.apache.org/tapestry], a complete framework offering
an alternative to JSP & Velocity scripting environments
1.1
incubator/src/documentation/content/xdocs/projects/pluto/pluto.xml
Index: pluto.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN"
"document-v11.dtd">
<document>
<header>
<title>Apache Pluto</title>
<authors>
<person name="The Apache Incubator Project"
email="[email protected]" />
</authors>
<abstract>Apache Pluto - JSR 168 Reference Implementation</abstract>
</header>
<body>
<section>
<title>Overview</title>
<p>
Pluto is the Reference Implementation of the Java Portlet Specfication.
The current version of this specification is
<link href="http://jcp.org/en/jsr/detail?id=168";>JSR 168</link>.
Please read the
<link
href="http://nagoya.apache.org/wiki/apachewiki.cgi?PlutoProposal";>proposal</link>
that started the project in the incubator.
</p>
</section>
<section>
<title>Resources</title>
<ul>
<li><link
href="http://cvs.apache.org/viewcvs.cgi/jakarta-pluto/";>CVS</link></li>
<li><link href="http://jakarta.apache.org/pluto/";>WebSite</link></li>
<li><link href="http://jakarta.apache.org/site/mail2.html#Pluto";>Mailing
lists</link></li>
</ul>
</section>
<section>
<title>Status</title>
<p><strong>Entry:</strong></p>
<ol>
<li>A group external to the foundation (IBM) wants to donate an existing code
base to the Foundation. Additionally, an existing (sub)project
(Jakarta/Jetspeed) wants to incorporate his codebase and buid a community
around it.</li>
</ol>
<p><strong>Process:</strong></p>
<ol>
<li>All software in this codebase has had its copyright assigned to the ASF.
The secretary of the ASF has acknowledged receipt of his copyright
assignment.</li>
<li>All software in this codebase is now licensed under the Apache license.
This license is present in every source file in cvs.</li>
<li>All contributors have faxed in Contributor License Agreements. The
secretary has acknowledged receipt of these agreements.</li>
<li>The community has adopted the Apache voting rules and is otherwise
following the Apache guidelines</li>
<li>The community is incorporated within the existing jakarta and Jetspeed
'steering committees'.</li>
<li>The exit strategy for the podling has been defined as jakarta-pluto.</li>
<ul>
<li>The Jakarta PMC has voted to accept this conditional upon successful
incubation.</li>
<li>Time frame: TBD</li>
<li>Graduation requirements: TBD</li>
</ul>
</ol>
</section>
</body>
</document>
1.1
incubator/src/documentation/content/xdocs/projects/pluto/STATUS.cwiki
Index: STATUS.cwiki
===================================================================
!Identify the project to be incubated
*Make sure that the requested project name does not already exist
and check www.nameprotect.com to be sure that the name is not
already trademarked for an existing software product.
*If request from an existing Apache project to adopt an external
package, then ask the Apache project for the cvs module and mail
address names.
*If request from outside Apache to enter an existing Apache project,
then post a message to that project for them to decide on acceptance.
*If request from anywhere to become a stand-alone PMC, then assess
the fit with the ASF, and create the lists and modules under the
incubator address/module names if accepted.
!Interim responsibility
*Who has been identified as the shepherd for the incubation?
*Are they tracking progress in the file
incubator/projects/{project_name}/STATUS
!Copyright
*Have the papers that transfer rights to the ASF been received?
It is only necessary to transfer rights for the package, the
core code, and any new code produced by the project.
*Have the files been updated to reflect the new ASF copyright?
Verify distribution rights:
*For all code included with the distribution that is not under the
Apache license, do we have the right to combine with Apache-licensed
code and redistribute?
*Is all source code distributed by the project covered by one or more
of the following approved licenses: Apache, BSD, Artistic, MIT/X,
MIT/W3C, MPL 1.1, or something with essentially the same terms?
!Establish a list of active committers
*Are all active committers in the STATUS file?
*Do they have accounts on cvs.apache.org?
*Have they submitted a contributors agreement?
!Infrastructure
*CVS modules created and committers added to avail file?
*Mailing lists set up and archived?
*Problem tracking system (Bugzilla)?
*Has the project migrated to our infrastructure?
!Collaborative Development
*Have all of the active long-term volunteers been identified
and acknowledged as committers on the project?
*Are there three or more independent committers?
[The legal definition of independent is long and boring, but basically
it means that there is no binding relationship between the individuals,
such as a shared employer, that is capable of overriding their free
will as individuals, directly or indirectly.]
*Are project decisions being made in public by the committers?
*Are the decision-making guidelines published and agreed to by
all of the committers?
!Organizational acceptance of responsibility for the project
*If graduating to an existing PMC, has the PMC voted to accept it?
*If graduating to a new PMC, has the board voted to accept it?
!Incubator sign-off
*Has the Incubator decided that the project has accomplished all
of the above tasks?
1.1
incubator/src/documentation/content/xdocs/projects/tapestry/PROPOSAL.txt
Index: PROPOSAL.txt
===================================================================
[0] rationale
Tapestry, currently housed at the SourceForge? (http://tapestry.sf.net),
is a component-based web application framework. Tapestry falls
generally into the pull-MVC model of development.
Tapestry is designed specifically around the creation of completely
re-usable components. Components can easily be packaged into
libraries and distributed within Jar files, even when they contain
assets such as image files and stylesheets.
Tapestry is organized around an abstraction that isolates
application-specific logic from the details of the servlet API,
such as HttpSession?, request, response, URLs and query parameters.
Tapestry is highly pluggable, allowing any and all behavior to be
customized by subclassing appropriate base classes.
Tapestry is specifically not a JSP taglib. Tapestry uses its own
method for instrumenting HTML that is extremely non-obtrusive (it
still previews properly in a WYSIWYG editor). Tapestry has well
specified, separate roles for HTML producers and Java developers,
and allows them to work together without interfering with each
other.
The goal of Tapestry is to shift much of the burden of developing
web applications onto the framework, and free the developer to work
cleanly and effectively without concern for the many small details
of web application development. The primary function of Tapestry
is the automatic creation of URLs by the framework, facilitating
a fine-grained dispatch model. The bird's-eye view is that, in
Tapestry, actions (such as clicking a link, or submitting a form)
are associated with a particular component and, through a simple
delegation system, a particular bit of user code. There is no global
registry of actions, as in Struts, and it's easy to create reusable
components that define their own behaviors (in terms of links or
forms), independent of the containing page.
Tapestry applications can be extremely sophisticated with surprisingly
little code.
Tapestry includes a significant amount of documentation describing
its strengths and features in great detail, available at
http://tapestry.sf.net. Live demos, a great collection of user
quotes, extensive documentation (HTML and PDF) and a recent code
coverage report are all online.
Tapestry has been an open-source project on SourceForge? since June
2000. Milestone releases (such as 2.1 in July, or the just-released
2.2) result in 6K - 7K downloads (increasing by over 1K downloads
with each successive release). Tapestry has averaged over 3000
downloads a month during 2002, with peaks above 8K/month.
Tapestry has recently adopted Apache meritocracy rules to govern
the project. The license for Tapestry has been changed from LGPL
to Apache Software License.
[0.1] criteria
Meritocracy: Tapestry follows the Apache meritocracy rules, with
a core of committers.
Community: Tapestry has a modest, but very active community, centered
around a user's mailing list (approx. 200 members), a developer's
mailing list, and the Tapestry Wiki (http://tapestry.sf.net/wiki).
The mailing lists have an exceptionally good signal-to-noise ratio;
discussions typically revolve around planning new extensions to
the framework, creating new components and documentation, and
diagnosing developer issues. The developer's mailing list is used
primarily for voting, and for discussions about votes. A secondary
project, to provide a community component repository is now underway
(http://sf.net/projects/tacos).
Core Developers. Tapestry has an active and dedicated team of
committers. The project was founded by Howard Lewis Ship, who is
extremely dedicated to Tapestry and authored the majority of the
codebase. Richard Lewis-Shell and Mind Bridge are frequent contributors
of components and bug fixes as well as some significant extensions.
Neil Clayton and Malcolm Edgar provide code and significant amounts
of documentation. Geoff Longman has created an excellent plugin
for the Eclipse IDE (as a separate project) and provides code to
keep the two projects in sync. Several other developers contribute
bug fixes, components and documentation.
Alignment: Tapestry makes use of the ORO, commons-lang and
commons-logging packages internally.
Scope: Tapestry is entirely a server-side framework, well aligned
with the overall goals of the Jakarta project.
[0.2] warning signs
Orphaned products. Tapestry is far from orphaned, it was originally
conceived and executed specifically as an open-source project.
Inexperience: Howard Lewis Ship has been coding, documenting,
mentoring and managing this open source project for nearly three
years. Others on the team have been actively using, supporting and
extending Tapestry for over a year.
Homogeneous Developers: The current Tapestry committers include
representatives from Canada, England, Australia and New Zealand;
other, more occasional, contributors represent South America and
Asia. This is just the opposite of the "smoke filled room".
Reliance on Salaried Developers: Tapestry is largely developed
during free time. Many contributions are developed by consultants
to address specific needs of their clients, then modularized and
provided back to the community (for example, Geoff is developing
a workflow management subsystem for Tapestry that may be released
into the framework proper when completed). Increasingly, developers
are finishing projects with Tapestry and contributing components
created for those projects back into the project.
No ties to other Apache Products: As stated above, Tapestry makes
use of the ORO and commons packages and has numerous places where
greater integration with Jakarta could occur. It is servlet container
agnostic, working well with Tomcat, Jetty, Resin and others.
Fascination with Apache Brand: Tapestry has been, and always will
be an open-source project.
[0.3] overlap with Turbine
Turbine has a similar model to Tapestry, but the focus of the two
projects is somewhat divergent. Turbine is a service-oriented where
Tapestry is component-oriented. Turbine provides a larger toolkit
(in the form of services) for aspects of the application not related
directly to the presentation layer. Tapestry provides more flexibility
and power in the presentation layer but doesn't provide any other
services (such as scheduling, database access, security, etc.).
Many Tapestry users are employing Tapestry for the presentation
layer, but leverage the many Turbine services (especially Torque).
[1] scope of subproject
The project shall create and maintain packages written in the Java
programming language constituting the framework itself, a standard
library of additional components, documentation, a web site and
additional examples.
[2] identify the initial source from which the project is to be
populated
The project currently resides on the SourceForge? (http://tapestry.sf.net).
[3] identify the Jakarta resources to be created
[3.1] mailing lists(s)
tapestry-user tapestry-dev tapestry-cvs
[3.2] CVS repositories
jakarta-tapestry
[3.3] Bugzilla
framework - tapestry components - web site, contrib library,
documentation, examples
[3.4] Wiki
It is desired that a Wiki be setup. Use of the current Wiki
(http://tapestry.sf.net/wiki) has proven highly successful in
supporting distributed design, discussion and decision making, as
well as providing a home for temporary documentation until permanent
documentation changes occur. We would prefer MoinMoin?, a Python
Wiki implementation.
[4] identify the initial set of committers
Mind Bridge mindbridge [EMAIL PROTECTED]
Neil Clayton nclayton [EMAIL PROTECTED]
Malcolm Edgar medgar [EMAIL PROTECTED]
Richard Lewis-Shell rlewisshell [EMAIL PROTECTED]
Howard Lewis Ship hlship [EMAIL PROTECTED]
Geoff Longman glongman [EMAIL PROTECTED]
[5] identify apache sponsoring individual
Andrew C. Oliver
dIon Gillard
1.1
incubator/src/documentation/content/xdocs/projects/tapestry/STATUS.txt
Index: STATUS.txt
===================================================================
APACHE Tapestry INCUBATOR PROJECT STATUS: -*-indented-text-*-
Last modified at [$Date: 2003/10/08 13:58:39 $]
Background:
o See the PROPOSAL file for project details.
Current Project Page: http://jakarta.apache.org/proposals/tapestry
Current License: Apache Software License
Current Copyright Holder: ASF
Project Shepards:
o Andrew Oliver <[EMAIL PROTECTED]>
o dIon Gillard <[EMAIL PROTECTED]>
Project Volunteer Contributors:
Pending Issues:
o Distribution
- Create both .zip and .tar.gz distributions
- Sign distributions
- Distribute keys
- Mirroring
Resolved Issues:
o Infrastructure needed:
- CVS setup
- Mailing list setup
- Bugzilla setup
o Gump integration
o Code Audits
- Removed LPGL code and linkages
Project committers (as of 2003-04-25):
o hlship,dsolis,nclayton,rlewisshell,mindbridge,glongman
================
From: "Howard M. Lewis Ship" <[EMAIL PROTECTED]>
Date: Mon Mar 10, 2003 3:58:22 PM US/Pacific
To: <[email protected]>
Subject: [STATUS] Tapestry [LACK-OF] Progress
Reply-To: [email protected]
How, exactly, is Tapestry ever expected to exit the proposal stage?
Despite repeated attempts, Tapestry is NOT in BugZilla. We're still forced
to use SourceForge for bug tracking.
Tapestry's mailing lists are not getting archived any more (not since 2/21).
Nobody seems to know ANY of the procedures for getting things done. Nothing
is documented. Simple things like the correct way to distribute a release
(including signing and mirroring) are just "known" by the right people ...
and I don't even know who is in the know.
Andrew and Dion have been helpful, both before the move and after.
The only other accomplishment of the incubation process has been a code
audit that resulted in a shuffling of the libraries checked into CVS and
distributed with the framework.
Jakarta infrastructure is non-existent. Worse, the Jakarta culture
erroneously expects things to get done based on e-mails, rather than
something organized, like using BugZilla to track infrastructure requests.
The Incubator team has yet to provide a time table or a check list to
indicate what the exit criteria are. In terms of Tapestry's commitments to
the Incubator, it looks like we're more than there (based on
http://incubator.apache.org/process.html). In terms of Incubator's
commitments to Tapestry ... that is, to assist Tapestry in moving into
Jakarta, fitting in, and accessing infrastructure; very little has been
accomplished.
================
From: "Howard M. Lewis Ship" <[EMAIL PROTECTED]>
Date: Wed Mar 12, 2003 12:10:25 PM US/Pacific
To: <[email protected]>
Subject: Updated Tapestry code audit
Reply-To: [email protected]
I've redone the Tapestry code audit for March, along with notes about what
changed, and why, since February.
http://nagoya.apache.org/wiki/apachewiki.cgi?TapestryAudits/Mar2003
Although I was blindsided by the LPGL constraints that came out in the last
few days, I believe Tapestry is fully in compliance at this time. Does
anybody know what license DocBook and DocBook XSL is released under? I
couldn't find it.
1.1
incubator/src/documentation/content/xdocs/projects/jaxme/STATUS.cwiki
Index: STATUS.cwiki
===================================================================
!Identify the project to be incubated
*Make sure that the requested project name does not already exist
and check www.nameprotect.com to be sure that the name is not
already trademarked for an existing software product.
*If request from an existing Apache project to adopt an external
package, then ask the Apache project for the cvs module and mail
address names.
*If request from outside Apache to enter an existing Apache project,
then post a message to that project for them to decide on acceptance.
*If request from anywhere to become a stand-alone PMC, then assess
the fit with the ASF, and create the lists and modules under the
incubator address/module names if accepted.
!Interim responsibility
*Who has been identified as the shepherd for the incubation?
*Are they tracking progress in the file
incubator/projects/{project_name}/STATUS
!Copyright
*Have the papers that transfer rights to the ASF been received?
It is only necessary to transfer rights for the package, the
core code, and any new code produced by the project.
*Have the files been updated to reflect the new ASF copyright?
Verify distribution rights:
*For all code included with the distribution that is not under the
Apache license, do we have the right to combine with Apache-licensed
code and redistribute?
*Is all source code distributed by the project covered by one or more
of the following approved licenses: Apache, BSD, Artistic, MIT/X,
MIT/W3C, MPL 1.1, or something with essentially the same terms?
!Establish a list of active committers
*Are all active committers in the STATUS file?
*Do they have accounts on cvs.apache.org?
*Have they submitted a contributors agreement?
!Infrastructure
*CVS modules created and committers added to avail file?
*Mailing lists set up and archived?
*Problem tracking system (Bugzilla)?
*Has the project migrated to our infrastructure?
!Collaborative Development
*Have all of the active long-term volunteers been identified
and acknowledged as committers on the project?
*Are there three or more independent committers?
[The legal definition of independent is long and boring, but basically
it means that there is no binding relationship between the individuals,
such as a shared employer, that is capable of overriding their free
will as individuals, directly or indirectly.]
*Are project decisions being made in public by the committers?
*Are the decision-making guidelines published and agreed to by
all of the committers?
!Organizational acceptance of responsibility for the project
*If graduating to an existing PMC, has the PMC voted to accept it?
*If graduating to a new PMC, has the board voted to accept it?
!Incubator sign-off
*Has the Incubator decided that the project has accomplished all
of the above tasks?
1.1
incubator/src/documentation/content/xdocs/projects/juddi/STATUS.cwiki
Index: STATUS.cwiki
===================================================================
!Identify the project to be incubated
*Make sure that the requested project name does not already exist
and check www.nameprotect.com to be sure that the name is not
already trademarked for an existing software product.
*If request from an existing Apache project to adopt an external
package, then ask the Apache project for the cvs module and mail
address names.
*If request from outside Apache to enter an existing Apache project,
then post a message to that project for them to decide on acceptance.
*If request from anywhere to become a stand-alone PMC, then assess
the fit with the ASF, and create the lists and modules under the
incubator address/module names if accepted.
!Interim responsibility
*Who has been identified as the shepherd for the incubation?
*Are they tracking progress in the file
incubator/projects/{project_name}/STATUS
!Copyright
*Have the papers that transfer rights to the ASF been received?
It is only necessary to transfer rights for the package, the
core code, and any new code produced by the project.
*Have the files been updated to reflect the new ASF copyright?
Verify distribution rights:
*For all code included with the distribution that is not under the
Apache license, do we have the right to combine with Apache-licensed
code and redistribute?
*Is all source code distributed by the project covered by one or more
of the following approved licenses: Apache, BSD, Artistic, MIT/X,
MIT/W3C, MPL 1.1, or something with essentially the same terms?
!Establish a list of active committers
*Are all active committers in the STATUS file?
*Do they have accounts on cvs.apache.org?
*Have they submitted a contributors agreement?
!Infrastructure
*CVS modules created and committers added to avail file?
*Mailing lists set up and archived?
*Problem tracking system (Bugzilla)?
*Has the project migrated to our infrastructure?
!Collaborative Development
*Have all of the active long-term volunteers been identified
and acknowledged as committers on the project?
*Are there three or more independent committers?
[The legal definition of independent is long and boring, but basically
it means that there is no binding relationship between the individuals,
such as a shared employer, that is capable of overriding their free
will as individuals, directly or indirectly.]
*Are project decisions being made in public by the committers?
*Are the decision-making guidelines published and agreed to by
all of the committers?
!Organizational acceptance of responsibility for the project
*If graduating to an existing PMC, has the PMC voted to accept it?
*If graduating to a new PMC, has the board voted to accept it?
!Incubator sign-off
*Has the Incubator decided that the project has accomplished all
of the above tasks?
1.1
incubator/src/documentation/content/xdocs/projects/wsrp4j/STATUS.cwiki
Index: STATUS.cwiki
===================================================================
!Identify the project to be incubated
*Make sure that the requested project name does not already exist
and check www.nameprotect.com to be sure that the name is not
already trademarked for an existing software product.
*If request from an existing Apache project to adopt an external
package, then ask the Apache project for the cvs module and mail
address names.
*If request from outside Apache to enter an existing Apache project,
then post a message to that project for them to decide on acceptance.
*If request from anywhere to become a stand-alone PMC, then assess
the fit with the ASF, and create the lists and modules under the
incubator address/module names if accepted.
!Interim responsibility
*Who has been identified as the shepherd for the incubation?
*Are they tracking progress in the file
incubator/projects/{project_name}/STATUS
!Copyright
*Have the papers that transfer rights to the ASF been received?
It is only necessary to transfer rights for the package, the
core code, and any new code produced by the project.
*Have the files been updated to reflect the new ASF copyright?
Verify distribution rights:
*For all code included with the distribution that is not under the
Apache license, do we have the right to combine with Apache-licensed
code and redistribute?
*Is all source code distributed by the project covered by one or more
of the following approved licenses: Apache, BSD, Artistic, MIT/X,
MIT/W3C, MPL 1.1, or something with essentially the same terms?
!Establish a list of active committers
*Are all active committers in the STATUS file?
*Do they have accounts on cvs.apache.org?
*Have they submitted a contributors agreement?
!Infrastructure
*CVS modules created and committers added to avail file?
*Mailing lists set up and archived?
*Problem tracking system (Bugzilla)?
*Has the project migrated to our infrastructure?
!Collaborative Development
*Have all of the active long-term volunteers been identified
and acknowledged as committers on the project?
*Are there three or more independent committers?
[The legal definition of independent is long and boring, but basically
it means that there is no binding relationship between the individuals,
such as a shared employer, that is capable of overriding their free
will as individuals, directly or indirectly.]
*Are project decisions being made in public by the committers?
*Are the decision-making guidelines published and agreed to by
all of the committers?
!Organizational acceptance of responsibility for the project
*If graduating to an existing PMC, has the PMC voted to accept it?
*If graduating to a new PMC, has the board voted to accept it?
!Incubator sign-off
*Has the Incubator decided that the project has accomplished all
of the above tasks?
1.1
incubator/src/documentation/content/xdocs/projects/xmlbeans/STATUS.cwiki
Index: STATUS.cwiki
===================================================================
Tasks for XMLBeans incubation.
* Define incubation exit criteria
* configure build to match ASF style
* setup mirroring of builds
* set up to sign builds
** committer PGP keys
** committer keys signed by someone in ASF (probably twl)
* grant some comitters access to xml-site
* build xmlbeans website
----
Tasks completed:
* create STATUS file in incubator-cvs
* create mailing lists
* create xml-xmlbeans CVS
** configure viewcvs
** commit mails -> [EMAIL PROTECTED]
* setup xmlbeans bugzilla
* Complete License Grant agreement
* Have all committers sign CLA's
** Cezar Andrei ([EMAIL PROTECTED])
** David Bau ([EMAIL PROTECTED])
** Tim Hanson ([EMAIL PROTECTED])
** Ken Kress ([EMAIL PROTECTED])
** Laurence Moroney ([EMAIL PROTECTED])
** David Remy ([EMAIL PROTECTED])
** Cliff Schmidt ([EMAIL PROTECTED])
** Eric Vasilik ([EMAIL PROTECTED])
** Robert Wyrick ([EMAIL PROTECTED])
* Relicense XML beans files with ASL 1.1
** add ASF copyright to all files
** move all packages to org.apache.xml.xmlbeans or whatever
** eliminate all non ASL code and library dependencies
* mailing list tasks
** lists-archived:
*** mbox -> xml.apache.org/mail
*** Eyebrowse setup
* setup xmlbeans wiki area and refactor pages to there
----
Exit criteria (put an X next to item when it is complete):
Identify the project to be incubated: XMLBeans
-- Make sure that the requested project name does not already exist
and check www.nameprotect.com to be sure that the name is not
already trademarked for an existing software product.
X- If request from an existing Apache project to adopt an external
package, then ask the Apache project for the cvs module and mail
address names.
xml-xmlbeans
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
X- If request from outside Apache to enter an existing Apache project,
then post a message to that project for them to decide on acceptance.
X- If request from anywhere to become a stand-alone PMC, then assess
the fit with the ASF, and create the lists and modules under the
incubator address/module names if accepted.
Interim responsibility:
X- Who has been identified as the shepherd for the incubation?
Ted Leung <[EMAIL PROTECTED]>
X- Are they tracking progress in the file
incubator/projects/xmlbeans/STATUS
Copyright:
X- Have the papers that transfer rights to the ASF been received?
It is only necessary to transfer rights for the package, the
core code, and any new code produced by the project.
X- Have the files been updated to reflect the new ASF copyright?
Verify distribution rights:
X- For all code included with the distribution that is not under the
Apache license, do we have the right to combine with Apache-licensed
code and redistribute?
X- Is all source code distributed by the project covered by one or more
of the following approved licenses: Apache, BSD, Artistic, MIT/X,
MIT/W3C, MPL 1.1, or something with essentially the same terms?
Establish a list of active committers:
X- Are all active committers in the STATUS file?
X- Do they have accounts on cvs.apache.org?
X- Have they submitted a contributors agreement?
Infrastructure:
X- CVS modules created and committers added to avail file?
X- Mailing lists set up and archived?
X- Problem tracking system (Bugzilla)?
X- Has the project migrated to our infrastructure?
Collaborative Development:
X- Have all of the active long-term volunteers been identified
and acknowledged as committers on the project?
-- Are there three or more independent committers?
[The legal definition of independent is long and boring, but basically
it means that there is no binding relationship between the individuals,
such as a shared employer, that is capable of overriding their free
will as individuals, directly or indirectly.]
-- Are project decisions being made in public by the committers?
-- Are the decision-making guidelines published and agreed to by
all of the committers?
Organizational acceptance of responsibility for the project:
-- If graduating to an existing PMC, has the PMC voted to accept it?
-- If graduating to a new PMC, has the board voted to accept it?
Incubator sign-off:
-- Has the Incubator decided that the project has accomplished all
of the above tasks?
1.1
incubator/src/documentation/content/xdocs/projects/template/STATUS.cwiki
Index: STATUS.cwiki
===================================================================
!Identify the project to be incubated
*Make sure that the requested project name does not already exist
and check www.nameprotect.com to be sure that the name is not
already trademarked for an existing software product.
*If request from an existing Apache project to adopt an external
package, then ask the Apache project for the cvs module and mail
address names.
*If request from outside Apache to enter an existing Apache project,
then post a message to that project for them to decide on acceptance.
*If request from anywhere to become a stand-alone PMC, then assess
the fit with the ASF, and create the lists and modules under the
incubator address/module names if accepted.
!Interim responsibility
*Who has been identified as the shepherd for the incubation?
*Are they tracking progress in the file
incubator/projects/{project_name}/STATUS
!Copyright
*Have the papers that transfer rights to the ASF been received?
It is only necessary to transfer rights for the package, the
core code, and any new code produced by the project.
*Have the files been updated to reflect the new ASF copyright?
Verify distribution rights:
*For all code included with the distribution that is not under the
Apache license, do we have the right to combine with Apache-licensed
code and redistribute?
*Is all source code distributed by the project covered by one or more
of the following approved licenses: Apache, BSD, Artistic, MIT/X,
MIT/W3C, MPL 1.1, or something with essentially the same terms?
!Establish a list of active committers
*Are all active committers in the STATUS file?
*Do they have accounts on cvs.apache.org?
*Have they submitted a contributors agreement?
!Infrastructure
*CVS modules created and committers added to avail file?
*Mailing lists set up and archived?
*Problem tracking system (Bugzilla)?
*Has the project migrated to our infrastructure?
!Collaborative Development
*Have all of the active long-term volunteers been identified
and acknowledged as committers on the project?
*Are there three or more independent committers?
[The legal definition of independent is long and boring, but basically
it means that there is no binding relationship between the individuals,
such as a shared employer, that is capable of overriding their free
will as individuals, directly or indirectly.]
*Are project decisions being made in public by the committers?
*Are the decision-making guidelines published and agreed to by
all of the committers?
!Organizational acceptance of responsibility for the project
*If graduating to an existing PMC, has the PMC voted to accept it?
*If graduating to a new PMC, has the board voted to accept it?
!Incubator sign-off
*Has the Incubator decided that the project has accomplished all
of the above tasks?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
