You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Danny Angus <da...@apache.org> on 2002/10/30 17:09:53 UTC
FW: [important proposal] Cocoon as official Apache project
If this mail gets through.. (its going via a server being load tested!)
I thought those not on the community/reorg lists might like to read this because Stefano outlines quite well at least one view of the top-level-project issues.
d.
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: 30 October 2002 13:29
> To: Apache Cocoon
> Cc: community@apache.org
> Subject: [important proposal] Cocoon as official Apache project
>
>
> Ladies and gentlemen,
>
> it is with *great* pleasure that I'm finally feel confident enough to
> ask you about something that is been in the back of my mind for more
> than a year now.
>
> The proposal of making cocoon an official top-level Apache project.
>
> - o -
>
> Before I state the proposal and its implications, allow me to introduce
> the context.
>
> Currently, Cocoon is not officially considered a 'project' under the ASF
> bylaws. Cocoon is, in fact, part of the Apache XML Project just like
> Xalan Xerces Fop Batik and the others.
>
> The ASF was designed round the concept of having one big legal umbrella
> (the foundation) and several focused development communities (the
> projects).
>
> The original idea was, in fact, modeled after how the Apache Group
> managed the Apache HTTPD project.
>
> Unfortunately, the ASF members thought that the same model could well
> apply to projects which did not release software directly (unlike HTTPD
> did) and decided to use the same model for jakarta and xml (which don't
> release software directly, but add another level of indirection with
> subprojects).
>
> The concept and the term "subproject" was, in fact, invented to separate
> the development community from the container.
>
> Over the years, it became clear that project containment yields several
> drawbacks:
>
> 1) container PMCs don't do anything since they are too detached from
> the actual code (it's impossible they know all about all the code hosted
> by the single containers!)
>
> 2) the subproject committers never have a way to interact directly
> with the foundation, thus they perceive it as a distant and bureaucratic
> thing
>
> 3) the ASF doesn't have proper legal oversight on the code contained
> in all sub-projects
>
> 4) the trend of sub-projecting created sub-containers (avalon and
> turbine, for example), thus making all this even worse.
>
> 5) the creation of sub-brands and the confusion this created. Example:
> is Apache Tomcat? or Jakarta Tomcat? or Apache Jakarta Tomcat?
>
> Over the last 18 months, several members tried to convince the ASF board
> that this situation was potentially very dangerous since, in fact, the
> container projects started to behave more and more as sub-foundations,
> but without the proper legal understanding. This situation was
> potentially inflammable in the case of a legal action against a
> committer since the foundation might not have been able to properly
> legally shield that committer since it operated outside the bylaws and
> without proper PMC oversight.
>
> Over the same period, several very influential members and board
> officials were against this notion, stating that it was just a human
> problem with the people elected on the PMC and *not* a problem in the
> design of the foundation.
>
> After a few new PMC elections, and after finally having a jakarta/xml
> member elected on the board (Sam Ruby), things are finally starting to
> change.
>
> The ASF board agrees on an open policy on the creation of new top-level
> Apache projects in the spirit of HTTPD: that is 'one PMC one codebase'.
>
> So, in the light of this, I would like to hear your comments on the idea
> of moving out of xml.apache.org into our own project.
>
> - o -
>
> Before you start asking a bunch of questions, let me answer a few of
> them that I might consider FAQs.
>
> 1) what are the contract changes that the proposal implies? [note, all
> these are not carved in stone, but just here to give you an idea]
>
> Cocoon will be moved on cocoon.apache.org, all pages on xml.apache.org
> redirected.
>
> The cocoon-*@xml.apache.org mail lists will be moved to
> {1}@cocoon.apache.org.
>
> The xml-cocoon2 module will be renamed 'cocoon'. The xml-cocoon1 module
> moved into hybernation state and stored for historical reasons only.
>
> NOTE: cocoon namespaces all start with http://apache.org/cocoon/ so no
> need to change anything there. [I planned this in advance at least two
> years ago, so that's why the namespace was already clean]
>
> 2) what does it mean for the developers?
>
> An official Cocoon project will have an official PMC which is what is
> legally reponsible for the code and reports directly to the board. The
> PMC officer becomes a vice-president of the ASF.
>
> In order to avoid stupid PMC elections, I'll be in favor of having the
> PMC composed by *all* committers that ask to be part of it. This to
> imply that committers and legal protector share the same duties and
> priviledges.
>
> In short, it means that if any of us screws legally, the foundation will
> protect us. Today, this is not the case.
>
> 3) what does it mean for Cocoon?
>
> Being a project allows us to host several different incubation-stage
> efforts underneath. Cocoblog, wyona, forrest, cocoon-related IDE plugins
> could be possible additions. Of course, with the idea of promoting them
> as top-level projects when they are successful from a community
> perspective.
>
> Also, it means that we could have our own machine running the entire
> cocoon.apache.org web site (that means: finally having Cocoon serving
> its own pages!)
>
> Last but not least, it will give much more visibility to Cocoon since it
> will be visible directly from www.apache.org
>
> 4) what are the drawbacks?
>
> moving stuff around is always annoying, but I think this is the only
> major drawback.
>
> 5) isn't this unfair against the other sub-projects that remain
> contained, therefore with less visibility?
>
> I don't know. Here I'm just stating the intention to move Cocoon to
> top-level and I know the ASF board is very open to projects willing to
> move out of their containers.
>
> But the ASF will *NOT* force projects to take this action. If other
> communities feel they should deserve top-level projects, they should
> make a proposal like this and ask the board instead of complaining with
> us that we do it.
>
> 6) isn't a cocoon-related project too specific? wouldn't it be better to
> have something like 'publishing.apache.org' and host all
> publishing-related stuff there?
>
> No, it would be a smaller container, but still a container where the PMC
> and the committers are not the same entity.
>
> HTTPD is a project about a modular HTTP server written in C, it's not a
> container for all HTTP-related server technology, nor it would be of any
> help if it became one.
>
> I think the ASF should stop forcing project to remain in containers but
> simply allow them to choose to step up.
>
> Cocoon.apache.org will be the community of people around Cocoon and will
> host, develop and distribute cocoon and cocoon-related software. And the
> PMC will be directly supervising because it will be composed by all
> committers of all cvs modules it will host.
>
> Also, stuff like Cocoon is very hard to make it fit into a single
> category.
>
>
> 7) how do we move this further?
>
> First thing to do is to have a formal votation. All committers should
> express their vote on this, right here:
>
> [ ] +1 I think it's a good idea
> [ ] 0 I really don't care.
> [ ] -1, I don't think it's a good idea.
>
> Please, vote clearly so that it's easy to make good summaries. If you
> vote -1, please state your reasoning and propose a creative solution for
> the problems this proposal tries to address.
>
> After the votation we'll see what to do.
>
> Thanks.
>
> --
> Stefano Mazzocchi <st...@apache.org>
> --------------------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: FW: [important proposal] Cocoon as official Apache project
Posted by "Noel J. Bergman" <no...@devtech.com>.
> we've got the server, the mailet API, and a collection
> of mailets all as possible subprojects. Or maybe
> multiple mailet packages... some standard ones, then
> others that are more like stand-alone apps.
James would be a fine top level project. And it is really very independent
of anything else, except for the hidden dependence upon Avalon.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] James as an official Apache project
Posted by Serge Knystautas <se...@lokitech.com>.
Danny Angus wrote:
> Should we prepare a proposal for submission to the board, that James be elevated to a top level project?
>
> [ ] +1 I think it's a good idea
> [ ] +0 I'll accept the majority decision, stop bothering me
> [ ] -0 I have reservations
> [ ] -1, I don't think its a good idea
+1. Let me know if you need any help, if the community thinks it's a
good idea.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] James as an official Apache project
Posted by David Jenkins <da...@mdcreate.com>.
+1 Here
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] James as an official Apache project
Posted by Stephen McConnell <mc...@apache.org>.
Danny Angus wrote:
>All,
>
>Now that we've had a chance to digest whats meant by a top level project, I'll subject you to my opinion, which I've held back so far.
>
>Basically I'm in favour of proposing james as an apache top level project (tlp), I'm prepared to take the lead on our proposal, and here's why:
>
> James has a small yet mature community, we seldom seek recourse to the jakarta PMC, and equally seldom are we scrutinised by them. We are not the most active project, and I feel that this sometimes causes James to be disregarded. Likewise, apart from Avalon, we have few direct ties with other jakarta projects, and little in common apart from the language/platform and culture (but the culture is Apache)
>
>The tlp issue is more about management than web-site and mail addresses, I don't believe that james.apache.org will bring many benefits, but I do think that normalising our managerial relationship with Jakarta by becoming a sibling rather than a child, and taking official control of all the issues we currently inherit and "interpret" from Jakarta would benefit James. The James PMC would be responsible to The Board.
>
>I do believe that Jakarta is becoming too big to function as a single project, that community and culture become diluted as you descend the heirarchy and that one solution is for mature projects leave the nest. Of course other projects are free to make their own choices but as James consists primarily of the server which is an end-user product I feel that top level project status, emphasisng its purpose rather then its technology, would suit it well.
>
>The proposals being discussed on reorg & community include the notion of federated projects, James, with the approval of the Jakarta PMC, could continue to be associated with Jakarta, I would like to think that we wouldn't be leaving Jakarta, just growing up. I also know that James would continue to rely on Jakarta for code, insight and cool thinking, but we don't need to be a Jakarta sub-project for that.
>
>It would also give us the opportunity, as Serge mentioned, to better promote our sub-projects, theres Mailet, and mailets, and there are the beginings of full blown mailet applications.
>
>So.. we've had time to examine the issues, lets vote..
>
>Should we prepare a proposal for submission to the board, that James be elevated to a top level project?
>
> [ ] +1 I think it's a good idea
> [ ] +0 I'll accept the majority decision, stop bothering me
> [ ] -0 I have reservations
> [ ] -1, I don't think its a good idea
>
>
+1
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] James as an official Apache project
Posted by Leo Simons <le...@apache.org>.
On Wed, 2002-10-30 at 18:46, Danny Angus wrote:
> Should we prepare a proposal for submission to the board, that James be elevated to a top level project?
>
> [X] +1 I think it's a good idea
> [ ] +0 I'll accept the majority decision, stop bothering me
> [ ] -0 I have reservations
> [ ] -1, I don't think its a good idea
non-binding :)
cheers,
Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: JDBC MAIL and SPOOL
Posted by "Noel J. Bergman" <no...@devtech.com>.
I'll do some testing, but since the listmessages query is keyed solely by
repository_name, I'd +1.
--- Noel
-----Original Message-----
From: Danny Angus [mailto:danny@apache.org]
Sent: Friday, November 01, 2002 6:44
To: James Developers List
Subject: JDBC MAIL and SPOOL
Hi,
messing around with performance I think that mail tables should be indexed
on repository_name, as well as having (repository_name,message_name) as the
PK.
anyone wanting to test this theory should run..
mysql> alter table [TABLENAME] add key repo (repository_name);
against your existing tables.
the patch for sql resources is:
C:\d\cvsdir\jakarta-james\src\conf>cvs -z9 diff -u sqlResources.xml
Index: sqlResources.xml
===================================================================
RCS file: /home/cvs/jakarta-james/src/conf/sqlResources.xml,v
retrieving revision 1.14
diff -u -r1.14 sqlResources.xml
--- sqlResources.xml 26 Aug 2002 18:53:17 -0000 1.14
+++ sqlResources.xml 1 Nov 2002 11:34:05 -0000
@@ -133,7 +133,8 @@
remote_addr varchar (20) NOT NULL ,
message_body longblob NOT NULL ,
last_updated datetime NOT NULL,
- PRIMARY KEY (message_name, repository_name)
+ PRIMARY KEY (message_name, repository_name),
+ KEY repo (repository_name)
)
</sql>
<sql name="createTable" db="hypersonic">
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
JDBC MAIL and SPOOL
Posted by Danny Angus <da...@apache.org>.
Hi,
messing around with performance I think that mail tables should be indexed on repository_name, as well as having (repository_name,message_name) as the PK.
anyone wanting to test this theory should run..
mysql> alter table [TABLENAME] add key repo (repository_name);
against your existing tables.
the patch for sql resources is:
C:\d\cvsdir\jakarta-james\src\conf>cvs -z9 diff -u sqlResources.xml
Index: sqlResources.xml
===================================================================
RCS file: /home/cvs/jakarta-james/src/conf/sqlResources.xml,v
retrieving revision 1.14
diff -u -r1.14 sqlResources.xml
--- sqlResources.xml 26 Aug 2002 18:53:17 -0000 1.14
+++ sqlResources.xml 1 Nov 2002 11:34:05 -0000
@@ -133,7 +133,8 @@
remote_addr varchar (20) NOT NULL ,
message_body longblob NOT NULL ,
last_updated datetime NOT NULL,
- PRIMARY KEY (message_name, repository_name)
+ PRIMARY KEY (message_name, repository_name),
+ KEY repo (repository_name)
)
</sql>
<sql name="createTable" db="hypersonic">
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] James as an official Apache project
Posted by Charles Benett <ch...@apache.org>.
+1
I suggest (like Noel) that the inital PMC is all committers.
Charles
Danny Angus wrote:
>All,
>
>Now that we've had a chance to digest whats meant by a top level project, I'll subject you to my opinion, which I've held back so far.
>
>Basically I'm in favour of proposing james as an apache top level project (tlp), I'm prepared to take the lead on our proposal, and here's why:
>
> James has a small yet mature community, we seldom seek recourse to the jakarta PMC, and equally seldom are we scrutinised by them. We are not the most active project, and I feel that this sometimes causes James to be disregarded. Likewise, apart from Avalon, we have few direct ties with other jakarta projects, and little in common apart from the language/platform and culture (but the culture is Apache)
>
>The tlp issue is more about management than web-site and mail addresses, I don't believe that james.apache.org will bring many benefits, but I do think that normalising our managerial relationship with Jakarta by becoming a sibling rather than a child, and taking official control of all the issues we currently inherit and "interpret" from Jakarta would benefit James. The James PMC would be responsible to The Board.
>
>I do believe that Jakarta is becoming too big to function as a single project, that community and culture become diluted as you descend the heirarchy and that one solution is for mature projects leave the nest. Of course other projects are free to make their own choices but as James consists primarily of the server which is an end-user product I feel that top level project status, emphasisng its purpose rather then its technology, would suit it well.
>
>The proposals being discussed on reorg & community include the notion of federated projects, James, with the approval of the Jakarta PMC, could continue to be associated with Jakarta, I would like to think that we wouldn't be leaving Jakarta, just growing up. I also know that James would continue to rely on Jakarta for code, insight and cool thinking, but we don't need to be a Jakarta sub-project for that.
>
>It would also give us the opportunity, as Serge mentioned, to better promote our sub-projects, theres Mailet, and mailets, and there are the beginings of full blown mailet applications.
>
>So.. we've had time to examine the issues, lets vote..
>
>Should we prepare a proposal for submission to the board, that James be elevated to a top level project?
>
> [ ] +1 I think it's a good idea
> [ ] +0 I'll accept the majority decision, stop bothering me
> [ ] -0 I have reservations
> [ ] -1, I don't think its a good idea
>
>
>d.
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: JavaMail mime header parsing
Posted by Danny Angus <da...@apache.org>.
pls submit this to bugzilla, its been on my radar for a while, but keeps slipping my mind.
> -----Original Message-----
> From: Jason Webb [mailto:jw@inovem.com]
> Sent: 01 November 2002 09:10
> To: 'James Developers List'
> Subject: RE: JavaMail mime header parsing
>
>
> We use Javamail 1.3 instead of 1.2. It's got a LOT of bug fixes in the
> Mime code and just seems to be more stable. I just changed the build.xml
> file and everything just works.
>
> So a thumbs up from me.
>
> -- Jason
>
> > -----Original Message-----
> > From: Serge Sozonoff [mailto:serge@globalbeach.com]
> > Sent: 31 October 2002 21:14
> > To: James Developers List
> > Subject: JavaMail mime header parsing
> >
> >
> > Hi All,
> >
> > Sorry for this slightly off topic subject, hoping someone has
> > a simple answer.
> >
> > My understanding of RFC2045 section 3. MIME Header Fields
> > leaves me to beleive that both of the following
> > representations are correct:
> >
> > Content-Type: multipart/related;
> > boundary=mmsc-mgw-unique-boundary-1;type="application/smil";st
> > art="<89168876
> > 9>"
> > Content-Type: multipart/related;
> > boundary=mmsc-mgw-unique-boundary-1;type=application/smil;star
> > t=<891688769>
> >
> > Note that one has some double quotes and one does not.
> >
> > However when I run the non-quoted version through JavaMail
> > 1.2 and 1.3 I get a ParseException or MessagingException
> > depending on the operation I am doing. Is there a but in
> > JavaMail or is my understanding of the RFC wrong?
> >
> > Any thoughts on upgrading the JavaMail extension in James, I
> > beleive we are still using 1.2 (I have found no specific
> > reason for suggesting this, but there were some bug fixes and
> > it might benefit those using JavaMail for their mailets.
> >
> > Thanks, Serge
> >
> > Example code to see this in action
> >
> > import javax.mail.internet.*;
> >
> > class test {
> > public static void main(String[] args) {
> > try {
> > String header = "multipart/related;
> > boundary=mmsc-mgw-unique-boundary-1;type=application/smil;star
> > t=<891688769>"
> > ;
> > ContentType cType = new ContentType(header);
> > System.out.println(cType.toString());
> > } catch(ParseException pe) {
> > System.out.println("Parse error");
> > pe.getMessage();
> > }
> > }
> > }
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:james-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands,
> > e-mail: <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: JavaMail mime header parsing
Posted by Jason Webb <jw...@inovem.com>.
We use Javamail 1.3 instead of 1.2. It's got a LOT of bug fixes in the
Mime code and just seems to be more stable. I just changed the build.xml
file and everything just works.
So a thumbs up from me.
-- Jason
> -----Original Message-----
> From: Serge Sozonoff [mailto:serge@globalbeach.com]
> Sent: 31 October 2002 21:14
> To: James Developers List
> Subject: JavaMail mime header parsing
>
>
> Hi All,
>
> Sorry for this slightly off topic subject, hoping someone has
> a simple answer.
>
> My understanding of RFC2045 section 3. MIME Header Fields
> leaves me to beleive that both of the following
> representations are correct:
>
> Content-Type: multipart/related;
> boundary=mmsc-mgw-unique-boundary-1;type="application/smil";st
> art="<89168876
> 9>"
> Content-Type: multipart/related;
> boundary=mmsc-mgw-unique-boundary-1;type=application/smil;star
> t=<891688769>
>
> Note that one has some double quotes and one does not.
>
> However when I run the non-quoted version through JavaMail
> 1.2 and 1.3 I get a ParseException or MessagingException
> depending on the operation I am doing. Is there a but in
> JavaMail or is my understanding of the RFC wrong?
>
> Any thoughts on upgrading the JavaMail extension in James, I
> beleive we are still using 1.2 (I have found no specific
> reason for suggesting this, but there were some bug fixes and
> it might benefit those using JavaMail for their mailets.
>
> Thanks, Serge
>
> Example code to see this in action
>
> import javax.mail.internet.*;
>
> class test {
> public static void main(String[] args) {
> try {
> String header = "multipart/related;
> boundary=mmsc-mgw-unique-boundary-1;type=application/smil;star
> t=<891688769>"
> ;
> ContentType cType = new ContentType(header);
> System.out.println(cType.toString());
> } catch(ParseException pe) {
> System.out.println("Parse error");
> pe.getMessage();
> }
> }
> }
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:james-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: JavaMail mime header parsing
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Serge,
I'm not sure that's the relevant RFC. The type name/parameter pair is
not addressed in RFC 2045, since it's a parameter specific to the
multipart/related Content-Type.
That said, RFC 2387 which defines the Multipart/Related type, seems to
indicate that it's actually the unquoted version which is correct.
Check out section 3.4 of this RFC. Although it also seems to say that,
in general, parameters will be quoted.
--Peter
> -----Original Message-----
> From: Serge Sozonoff [mailto:serge@globalbeach.com]
> Sent: Thursday, October 31, 2002 1:14 PM
> To: James Developers List
> Subject: JavaMail mime header parsing
>
> Hi All,
>
> Sorry for this slightly off topic subject, hoping someone has a simple
> answer.
>
> My understanding of RFC2045 section 3. MIME Header Fields leaves me
to
> beleive that both of the following representations are correct:
>
> Content-Type: multipart/related;
> boundary=mmsc-mgw-unique-boundary-
> 1;type="application/smil";start="<89168876
> 9>"
> Content-Type: multipart/related;
> boundary=mmsc-mgw-unique-boundary-
> 1;type=application/smil;start=<891688769>
>
> Note that one has some double quotes and one does not.
>
> However when I run the non-quoted version through JavaMail 1.2 and 1.3
I
> get
> a ParseException or MessagingException depending on the operation I am
> doing.
> Is there a but in JavaMail or is my understanding of the RFC wrong?
>
> Any thoughts on upgrading the JavaMail extension in James, I beleive
we
> are
> still using 1.2 (I have found no specific reason for suggesting this,
but
> there were some bug fixes and it might benefit those using JavaMail
for
> their mailets.
>
> Thanks, Serge
>
> Example code to see this in action
>
> import javax.mail.internet.*;
>
> class test {
> public static void main(String[] args) {
> try {
> String header = "multipart/related;
> boundary=mmsc-mgw-unique-boundary-
> 1;type=application/smil;start=<891688769>"
> ;
> ContentType cType = new ContentType(header);
> System.out.println(cType.toString());
> } catch(ParseException pe) {
> System.out.println("Parse error");
> pe.getMessage();
> }
> }
> }
>
>
>
> --
> To unsubscribe, e-mail: <mailto:james-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:james-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
JavaMail mime header parsing
Posted by Serge Sozonoff <se...@globalbeach.com>.
Hi All,
Sorry for this slightly off topic subject, hoping someone has a simple
answer.
My understanding of RFC2045 section 3. MIME Header Fields leaves me to
beleive that both of the following representations are correct:
Content-Type: multipart/related;
boundary=mmsc-mgw-unique-boundary-1;type="application/smil";start="<89168876
9>"
Content-Type: multipart/related;
boundary=mmsc-mgw-unique-boundary-1;type=application/smil;start=<891688769>
Note that one has some double quotes and one does not.
However when I run the non-quoted version through JavaMail 1.2 and 1.3 I get
a ParseException or MessagingException depending on the operation I am
doing.
Is there a but in JavaMail or is my understanding of the RFC wrong?
Any thoughts on upgrading the JavaMail extension in James, I beleive we are
still using 1.2 (I have found no specific reason for suggesting this, but
there were some bug fixes and it might benefit those using JavaMail for
their mailets.
Thanks, Serge
Example code to see this in action
import javax.mail.internet.*;
class test {
public static void main(String[] args) {
try {
String header = "multipart/related;
boundary=mmsc-mgw-unique-boundary-1;type=application/smil;start=<891688769>"
;
ContentType cType = new ContentType(header);
System.out.println(cType.toString());
} catch(ParseException pe) {
System.out.println("Parse error");
pe.getMessage();
}
}
}
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] James as an official Apache project
Posted by Serge Sozonoff <se...@globalbeach.com>.
Hi All,
+1
Serge
----- Original Message -----
From: "Danny Angus" <da...@apache.org>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Wednesday, October 30, 2002 6:55 PM
Subject: RE: [VOTE] James as an official Apache project
PS...
Theres a tradition of people voting who's vote may not count, do that please
because I'd really like to hear from the whole community, not just the
commiters.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] James as an official Apache project
Posted by Danny Angus <da...@apache.org>.
PS...
Theres a tradition of people voting who's vote may not count, do that please because I'd really like to hear from the whole community, not just the commiters.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] James as an official Apache project
Posted by Darrell DeBoer <da...@apache.org>.
On Thu, 21 Nov 2002 19:52, Danny Angus wrote:
> Hi,
>
> I haven't forgotten this, but have been sidetracked by real-life issues(!)
>
> So, to summarise, the results of the voting were in favour of the proposal
> "That we should prepare a proposal for submission to the board, that James
> be elevated to a top level Apache project." as follows:
My very late +1
>
> Binding votes:
> +1
> Serge Knystautas
> Danny Angus
> Peter Goldstein
> Noel Bergman
> Charles Bennet
Darrell DeBoer
>
> +0 None
> -0 None
> -1 None
>
> Commiters who did not vote, or are inactive:
> Harmeet Bedi
> Darrell De Boer
> Peter Donald
> Paul Hammant
> Brendan Burns
> James Duncan Davidson
> Jon Scott Stevens
>
> Votes of support from the community:
>
> +1
> Stephen McConnell
> Brad Walker
> Scott Sanders
> Steve Short
> Alan Gerhard
> Leo Simons
> David Jenkins
> Jason Webb
> Dave Richardson
> Serge Sozonoff
> Chris Means
--
ciao,
Daz
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] James as an official Apache project
Posted by Danny Angus <da...@apache.org>.
I suggest we now prepare a proposal for submission,
to which end I suggest that I commit a draft, mainly just headings, and we can work on that.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] James as an official Apache project
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> I propose Serge to have the honor of being the initial PMC Chairman, and all
> Committers as the initial PMC, unless they wish to demure.
Thank you very much for the nomination. I would be extremely honored.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] James as an official Apache project
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
>
> I propose Serge to have the honor of being the initial PMC Chairman.
+1.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] James as an official Apache project
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
All,
> I propose Serge to have the honor of being the initial PMC Chairman,
and
> all
> Committers as the initial PMC, unless they wish to demure.
+1
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] James as an official Apache project
Posted by "Noel J. Bergman" <no...@devtech.com>.
Danny,
No worries. Thinking about it the other day, I figured that we'd get onto
this in December after we shipped v2.1. It is nice of Stephen McConnell to
offer his assistance, having just participated in Avalon's successful
promotion.
I propose Serge to have the honor of being the initial PMC Chairman, and all
Committers as the initial PMC, unless they wish to demure.
Please note: next week is Thanksgiving in the USA. It is most likely that a
number of us will probably be off-line for extended periods.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] James as an official Apache project
Posted by Danny Angus <da...@apache.org>.
Hi,
I haven't forgotten this, but have been sidetracked by real-life issues(!)
So, to summarise, the results of the voting were in favour of the proposal
"That we should prepare a proposal for submission to the board, that James be elevated to a top level Apache project."
as follows:
Binding votes:
+1
Serge Knystautas
Danny Angus
Peter Goldstein
Noel Bergman
Charles Bennet
+0 None
-0 None
-1 None
Commiters who did not vote, or are inactive:
Harmeet Bedi
Darrell De Boer
Peter Donald
Paul Hammant
Brendan Burns
James Duncan Davidson
Jon Scott Stevens
Votes of support from the community:
+1
Stephen McConnell
Brad Walker
Scott Sanders
Steve Short
Alan Gerhard
Leo Simons
David Jenkins
Jason Webb
Dave Richardson
Serge Sozonoff
Chris Means
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Phoenix 4.0.1
Posted by Danny Angus <da...@apache.org>.
> There is an observed issue with Red Hat Linux 6.2, Sun's 1.3.0 JVM, and
> this revision of Phoenix. This has been confirmed to be a JVM issue,
> and can be resolved by switching to either IBM's 1.3.1 JVM or Sun's 1.4
> JVM. Other than this issue there are no known platform/JVM
> incompatibilities.
Patch the JVM recommendations in the xdocs, before we forget.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Phoenix 4.0.1
Posted by "Noel J. Bergman" <no...@devtech.com>.
It runs with J2SDK 1.4.1_01 for linux and IBM JVM 1.3.1 for linux. I can't
speak to any other release, so hopefully others will test and reply.
--- Noel
-----Original Message-----
From: Danny Angus [mailto:danny@apache.org]
Sent: Thursday, October 31, 2002 12:25
To: James Developers List
Subject: RE: Phoenix 4.0.1
does this version of phoenix run with the -server option on sun j2sdk1.4.0 ?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Phoenix 4.0.1
Posted by Danny Angus <da...@apache.org>.
does this version of phoenix run with the -server option on sun j2sdk1.4.0 ?
> -----Original Message-----
> From: Peter M. Goldstein [mailto:peter_m_goldstein@yahoo.com]
> Sent: 30 October 2002 21:18
> To: 'James Developers List'
> Subject: Phoenix 4.0.1
>
>
>
> All,
>
> I've just checked in the Phoenix 4.0.1 version. It resolves the logging
> bug (all log entries go to a single file) that was introduced in the
> Phoenix 4.0 release version.
>
> I've been building and running with this version successfully on a
> Windows 2k box for over a week now. Noel has tested it on Linux, and
> found that it runs successfully there.
>
> I have also changed the build.xml so that deprecation warnings are
> turned off. With this upgrade the number of Component related
> deprecation warnings goes up to 200+. IMHO that's just really annoying.
> So I flipped them off until we do the upgrade to
> Serviceable/ServiceManager in the next rev.
>
> There is an observed issue with Red Hat Linux 6.2, Sun's 1.3.0 JVM, and
> this revision of Phoenix. This has been confirmed to be a JVM issue,
> and can be resolved by switching to either IBM's 1.3.1 JVM or Sun's 1.4
> JVM. Other than this issue there are no known platform/JVM
> incompatibilities.
>
> Please let me know immediately if you encounter any issues, as I'd like
> to make this upgrade as smooth as possible. Please make sure that you
> upgrade both your phoenix-bin directory and your build.xml. Thanks.
>
> --Peter
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Phoenix 4.0.1
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
All,
I've just checked in the Phoenix 4.0.1 version. It resolves the logging
bug (all log entries go to a single file) that was introduced in the
Phoenix 4.0 release version.
I've been building and running with this version successfully on a
Windows 2k box for over a week now. Noel has tested it on Linux, and
found that it runs successfully there.
I have also changed the build.xml so that deprecation warnings are
turned off. With this upgrade the number of Component related
deprecation warnings goes up to 200+. IMHO that's just really annoying.
So I flipped them off until we do the upgrade to
Serviceable/ServiceManager in the next rev.
There is an observed issue with Red Hat Linux 6.2, Sun's 1.3.0 JVM, and
this revision of Phoenix. This has been confirmed to be a JVM issue,
and can be resolved by switching to either IBM's 1.3.1 JVM or Sun's 1.4
JVM. Other than this issue there are no known platform/JVM
incompatibilities.
Please let me know immediately if you encounter any issues, as I'd like
to make this upgrade as smooth as possible. Please make sure that you
upgrade both your phoenix-bin directory and your build.xml. Thanks.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] James as an official Apache project
Posted by Danny Angus <da...@apache.org>.
I have no other thoughts, all that can be decided as part of our proposal, if we decide to formulate one..
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 30 October 2002 19:06
> To: James Developers List
> Subject: RE: [VOTE] James as an official Apache project
>
>
> Danny,
>
> Do you want to adopt the Cocoon project's proposal that the
> (initial) PMC be
> made from all Committers who want on, or do you have other thoughts?
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] James as an official Apache project
Posted by Danny Angus <da...@apache.org>.
> I don't
> think there are any other jakarta (or XML) sub-projects that would make as
> good top-level projects as James.
With the exception possibly of Tomcat??
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] James as an official Apache project
Posted by Dave Richardson <da...@aifarms.com>.
>I would feel most confident about going ahead with this if we can get a
full turnout and no -1's
Well then!
+1
For what it's worth, I think James makes a good top-level project because
it's a server that's an application unto itself, like HTTPD. But I like
having all the java infrastructure and utility projects grouped together
under one roof. That way, you have a programmer's tool chest where all the
tools are easy to find, and the project can (ideally) show how the tools
work together and encourage development integration between them. I don't
think there are any other jakarta (or XML) sub-projects that would make as
good top-level projects as James.
(former lurker),
-dave
----- Original Message -----
From: "Danny Angus" <da...@apache.org>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Thursday, October 31, 2002 5:38 AM
Subject: RE: [VOTE] James as an official Apache project
Jason,
No not too late, I'll give this one a week, and possibly prod some of the
commiters who are innactive in James but active elsewhere in Jakarta.
A "yes" vote now, while not being a vote to actually submit a proposal, (we
should probably have a lazy vote on the proposal before we submit it)
represents the biggest shift in James PM since I-dont-know-when, its
adoption by java.apache or the inception of Jakarta probably.
We really don't want people to misunderstand our motives, or misconstrue our
opinions about Jakarta, and I would feel most confident about going ahead
with this if we can get a full turnout and no -1's
Even then there's no guarantee we'd be accepted.
d.
> -----Original Message-----
> From: Jason Webb [mailto:jw@inovem.com]
> Sent: 31 October 2002 09:39
> To: 'James Developers List'
> Subject: RE: [VOTE] James as an official Apache project
>
>
> +1 (if I'm not too late)
>
> -- Jason
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] James as an official Apache project
Posted by Danny Angus <da...@apache.org>.
Jason,
No not too late, I'll give this one a week, and possibly prod some of the commiters who are innactive in James but active elsewhere in Jakarta.
A "yes" vote now, while not being a vote to actually submit a proposal, (we should probably have a lazy vote on the proposal before we submit it) represents the biggest shift in James PM since I-dont-know-when, its adoption by java.apache or the inception of Jakarta probably.
We really don't want people to misunderstand our motives, or misconstrue our opinions about Jakarta, and I would feel most confident about going ahead with this if we can get a full turnout and no -1's
Even then there's no guarantee we'd be accepted.
d.
> -----Original Message-----
> From: Jason Webb [mailto:jw@inovem.com]
> Sent: 31 October 2002 09:39
> To: 'James Developers List'
> Subject: RE: [VOTE] James as an official Apache project
>
>
> +1 (if I'm not too late)
>
> -- Jason
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] James as an official Apache project
Posted by Jason Webb <jw...@inovem.com>.
+1 (if I'm not too late)
-- Jason
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] James as an official Apache project
Posted by "Noel J. Bergman" <no...@devtech.com>.
Danny,
Do you want to adopt the Cocoon project's proposal that the (initial) PMC be
made from all Committers who want on, or do you have other thoughts?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] James as an official Apache project
Posted by "Noel J. Bergman" <no...@devtech.com>.
+1
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] James as an official Apache project
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
+1.
> -----Original Message-----
> From: Danny Angus [mailto:danny@apache.org]
> Sent: Wednesday, October 30, 2002 9:47 AM
> To: James Developers List
> Subject: [VOTE] James as an official Apache project
>
> All,
>
> Now that we've had a chance to digest whats meant by a top level
project,
> I'll subject you to my opinion, which I've held back so far.
>
> Basically I'm in favour of proposing james as an apache top level
project
> (tlp), I'm prepared to take the lead on our proposal, and here's why:
>
> James has a small yet mature community, we seldom seek recourse to
the
> jakarta PMC, and equally seldom are we scrutinised by them. We are not
the
> most active project, and I feel that this sometimes causes James to be
> disregarded. Likewise, apart from Avalon, we have few direct ties with
> other jakarta projects, and little in common apart from the
> language/platform and culture (but the culture is Apache)
>
> The tlp issue is more about management than web-site and mail
addresses, I
> don't believe that james.apache.org will bring many benefits, but I do
> think that normalising our managerial relationship with Jakarta by
> becoming a sibling rather than a child, and taking official control of
all
> the issues we currently inherit and "interpret" from Jakarta would
benefit
> James. The James PMC would be responsible to The Board.
>
> I do believe that Jakarta is becoming too big to function as a single
> project, that community and culture become diluted as you descend the
> heirarchy and that one solution is for mature projects leave the nest.
Of
> course other projects are free to make their own choices but as James
> consists primarily of the server which is an end-user product I feel
that
> top level project status, emphasisng its purpose rather then its
> technology, would suit it well.
>
> The proposals being discussed on reorg & community include the notion
of
> federated projects, James, with the approval of the Jakarta PMC, could
> continue to be associated with Jakarta, I would like to think that we
> wouldn't be leaving Jakarta, just growing up. I also know that James
would
> continue to rely on Jakarta for code, insight and cool thinking, but
we
> don't need to be a Jakarta sub-project for that.
>
> It would also give us the opportunity, as Serge mentioned, to better
> promote our sub-projects, theres Mailet, and mailets, and there are
the
> beginings of full blown mailet applications.
>
> So.. we've had time to examine the issues, lets vote..
>
> Should we prepare a proposal for submission to the board, that James
be
> elevated to a top level project?
>
> [ ] +1 I think it's a good idea
> [ ] +0 I'll accept the majority decision, stop bothering me
> [ ] -0 I have reservations
> [ ] -1, I don't think its a good idea
>
>
> d.
>
>
> --
> To unsubscribe, e-mail: <mailto:james-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:james-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[VOTE] James as an official Apache project
Posted by Danny Angus <da...@apache.org>.
All,
Now that we've had a chance to digest whats meant by a top level project, I'll subject you to my opinion, which I've held back so far.
Basically I'm in favour of proposing james as an apache top level project (tlp), I'm prepared to take the lead on our proposal, and here's why:
James has a small yet mature community, we seldom seek recourse to the jakarta PMC, and equally seldom are we scrutinised by them. We are not the most active project, and I feel that this sometimes causes James to be disregarded. Likewise, apart from Avalon, we have few direct ties with other jakarta projects, and little in common apart from the language/platform and culture (but the culture is Apache)
The tlp issue is more about management than web-site and mail addresses, I don't believe that james.apache.org will bring many benefits, but I do think that normalising our managerial relationship with Jakarta by becoming a sibling rather than a child, and taking official control of all the issues we currently inherit and "interpret" from Jakarta would benefit James. The James PMC would be responsible to The Board.
I do believe that Jakarta is becoming too big to function as a single project, that community and culture become diluted as you descend the heirarchy and that one solution is for mature projects leave the nest. Of course other projects are free to make their own choices but as James consists primarily of the server which is an end-user product I feel that top level project status, emphasisng its purpose rather then its technology, would suit it well.
The proposals being discussed on reorg & community include the notion of federated projects, James, with the approval of the Jakarta PMC, could continue to be associated with Jakarta, I would like to think that we wouldn't be leaving Jakarta, just growing up. I also know that James would continue to rely on Jakarta for code, insight and cool thinking, but we don't need to be a Jakarta sub-project for that.
It would also give us the opportunity, as Serge mentioned, to better promote our sub-projects, theres Mailet, and mailets, and there are the beginings of full blown mailet applications.
So.. we've had time to examine the issues, lets vote..
Should we prepare a proposal for submission to the board, that James be elevated to a top level project?
[ ] +1 I think it's a good idea
[ ] +0 I'll accept the majority decision, stop bothering me
[ ] -0 I have reservations
[ ] -1, I don't think its a good idea
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: FW: [important proposal] Cocoon as official Apache project
Posted by Serge Knystautas <se...@lokitech.com>.
Yeah, I saw this and thought about James... we've got the server, the
mailet API, and a collection of mailets all as possible subprojects. Or
maybe multiple mailet packages... some standard ones, then others that
are more like stand-alone apps.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
Danny Angus wrote:
> If this mail gets through.. (its going via a server being load tested!)
>
> I thought those not on the community/reorg lists might like to read this because Stefano outlines quite well at least one view of the top-level-project issues.
>
> d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [important proposal] Cocoon as official Apache project
Posted by "Noel J. Bergman" <no...@devtech.com>.
Serge,
Avalon and Turbine demonstrate that projects can create sub-projects in
their portion of the web site without the "proper" legal status of TLP, or a
dedicated sub-domain.
In any event, we agree that the shift to promote suitable independent
projects to top level projects with their own PMC may encourage a shift in
web site strategy, but the Apache web site strategy really should be
undertaken as a separate coordinated project, not a chaotic consequence.
--- Noel
-----Original Message-----
From: Serge Knystautas [mailto:sergek@lokitech.com]
Sent: Wednesday, October 30, 2002 12:12
To: James Developers List
Subject: Re: [important proposal] Cocoon as official Apache project
Noel,
I agree, and I'll pass along your comments along with some of my own.
To me the difference is between legal and branding issues... really the
driving factor (that I can see) is legal protection, and making sure a
committer (like us) doesn't create a mailet subproject and make
ourselves liable. Even as this promotion happens though, everyone would
be best served by having James link to other projects under jakarta or
the-projects-formerly-known-under jakarta. I actually think jakarta and
xml projects should link more together. In fact, Tomcat should probably
link to the httpd project since that's often put in front of Tomcat
(although maybe they don't want to appear biased, but I would guess it's
just not something people think about... who knows?)
I wouldn't say it's completely orthogonal though because this legal move
would open the doors to projects like ours to create subprojects, thus
requiring us to restructure the site some.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
Noel J. Bergman wrote:
> Danny,
>
> Stefano Mazzocchi is a bright guy, and most of what he says makes sense,
> except for the restructuring of the web site. For reasons I've stated
> earlier, I think that it is a terrible idea to simply move each project to
> its own sub-domain, making it increasingly more difficult for people to
> locate related information. From what Roy Fielding indicated, everything
> that can be done about making Cocoon a top level project can be done
> independently of a web site reorganization. I'd propose that the legal
> structure and web site structure be considered orthogonal issues.
>
> I'm not saying that the web sites can't, or even shouldn't, be
restructured,
> just that the two issues should be dealt with separately, each on its
> merits. In the case of Cocoon, there is a good argument for it to host
its
> own pages. But regardless of whether the Apache web becomes a directory
of
> sub-domains, each running its own technology; a frontend portal serving up
> (and showcasing) information from multiple technologies; or what-have-you;
> the Apache web ought to be a product of careful design to allow easy
access
> to relevant information, and not be a reflection of each project's legal
> status.
>
> Since you are on that list, you might care to pass along these thoughts.
>
> --- Noel
>
> -----Original Message-----
> From: Danny Angus [mailto:danny@apache.org]
> Sent: Wednesday, October 30, 2002 11:10
> To: James Developer List
> Subject: FW: [important proposal] Cocoon as official Apache project
>
>
> If this mail gets through.. (its going via a server being load tested!)
>
> I thought those not on the community/reorg lists might like to read this
> because Stefano outlines quite well at least one view of the
> top-level-project issues.
>
> d.
>
>
>
>>-----Original Message-----
>>From: Stefano Mazzocchi [mailto:stefano@apache.org]
>>Sent: 30 October 2002 13:29
>>To: Apache Cocoon
>>Cc: community@apache.org
>>Subject: [important proposal] Cocoon as official Apache project
>>
>>
>>Ladies and gentlemen,
>>
>>it is with *great* pleasure that I'm finally feel confident enough to
>>ask you about something that is been in the back of my mind for more
>>than a year now.
>>
>>The proposal of making cocoon an official top-level Apache project.
>>
>> - o -
>>
>>Before I state the proposal and its implications, allow me to introduce
>>the context.
>>
>>Currently, Cocoon is not officially considered a 'project' under the ASF
>>bylaws. Cocoon is, in fact, part of the Apache XML Project just like
>>Xalan Xerces Fop Batik and the others.
>>
>>The ASF was designed round the concept of having one big legal umbrella
>>(the foundation) and several focused development communities (the
>>projects).
>>
>>The original idea was, in fact, modeled after how the Apache Group
>>managed the Apache HTTPD project.
>>
>>Unfortunately, the ASF members thought that the same model could well
>>apply to projects which did not release software directly (unlike HTTPD
>>did) and decided to use the same model for jakarta and xml (which don't
>>release software directly, but add another level of indirection with
>>subprojects).
>>
>>The concept and the term "subproject" was, in fact, invented to separate
>>the development community from the container.
>>
>>Over the years, it became clear that project containment yields several
>>drawbacks:
>>
>> 1) container PMCs don't do anything since they are too detached from
>>the actual code (it's impossible they know all about all the code hosted
>>by the single containers!)
>>
>> 2) the subproject committers never have a way to interact directly
>>with the foundation, thus they perceive it as a distant and bureaucratic
>>thing
>>
>> 3) the ASF doesn't have proper legal oversight on the code contained
>>in all sub-projects
>>
>> 4) the trend of sub-projecting created sub-containers (avalon and
>>turbine, for example), thus making all this even worse.
>>
>> 5) the creation of sub-brands and the confusion this created. Example:
>>is Apache Tomcat? or Jakarta Tomcat? or Apache Jakarta Tomcat?
>>
>>Over the last 18 months, several members tried to convince the ASF board
>>that this situation was potentially very dangerous since, in fact, the
>>container projects started to behave more and more as sub-foundations,
>>but without the proper legal understanding. This situation was
>>potentially inflammable in the case of a legal action against a
>>committer since the foundation might not have been able to properly
>>legally shield that committer since it operated outside the bylaws and
>>without proper PMC oversight.
>>
>>Over the same period, several very influential members and board
>>officials were against this notion, stating that it was just a human
>>problem with the people elected on the PMC and *not* a problem in the
>>design of the foundation.
>>
>>After a few new PMC elections, and after finally having a jakarta/xml
>>member elected on the board (Sam Ruby), things are finally starting to
>>change.
>>
>>The ASF board agrees on an open policy on the creation of new top-level
>>Apache projects in the spirit of HTTPD: that is 'one PMC one codebase'.
>>
>>So, in the light of this, I would like to hear your comments on the idea
>>of moving out of xml.apache.org into our own project.
>>
>> - o -
>>
>>Before you start asking a bunch of questions, let me answer a few of
>>them that I might consider FAQs.
>>
>>1) what are the contract changes that the proposal implies? [note, all
>>these are not carved in stone, but just here to give you an idea]
>>
>>Cocoon will be moved on cocoon.apache.org, all pages on xml.apache.org
>>redirected.
>>
>>The cocoon-*@xml.apache.org mail lists will be moved to
>>{1}@cocoon.apache.org.
>>
>>The xml-cocoon2 module will be renamed 'cocoon'. The xml-cocoon1 module
>>moved into hybernation state and stored for historical reasons only.
>>
>>NOTE: cocoon namespaces all start with http://apache.org/cocoon/ so no
>>need to change anything there. [I planned this in advance at least two
>>years ago, so that's why the namespace was already clean]
>>
>>2) what does it mean for the developers?
>>
>>An official Cocoon project will have an official PMC which is what is
>>legally reponsible for the code and reports directly to the board. The
>>PMC officer becomes a vice-president of the ASF.
>>
>>In order to avoid stupid PMC elections, I'll be in favor of having the
>>PMC composed by *all* committers that ask to be part of it. This to
>>imply that committers and legal protector share the same duties and
>>priviledges.
>>
>>In short, it means that if any of us screws legally, the foundation will
>>protect us. Today, this is not the case.
>>
>>3) what does it mean for Cocoon?
>>
>>Being a project allows us to host several different incubation-stage
>>efforts underneath. Cocoblog, wyona, forrest, cocoon-related IDE plugins
>>could be possible additions. Of course, with the idea of promoting them
>>as top-level projects when they are successful from a community
>>perspective.
>>
>>Also, it means that we could have our own machine running the entire
>>cocoon.apache.org web site (that means: finally having Cocoon serving
>>its own pages!)
>>
>>Last but not least, it will give much more visibility to Cocoon since it
>>will be visible directly from www.apache.org
>>
>>4) what are the drawbacks?
>>
>>moving stuff around is always annoying, but I think this is the only
>>major drawback.
>>
>>5) isn't this unfair against the other sub-projects that remain
>>contained, therefore with less visibility?
>>
>>I don't know. Here I'm just stating the intention to move Cocoon to
>>top-level and I know the ASF board is very open to projects willing to
>>move out of their containers.
>>
>>But the ASF will *NOT* force projects to take this action. If other
>>communities feel they should deserve top-level projects, they should
>>make a proposal like this and ask the board instead of complaining with
>>us that we do it.
>>
>>6) isn't a cocoon-related project too specific? wouldn't it be better to
>>have something like 'publishing.apache.org' and host all
>>publishing-related stuff there?
>>
>>No, it would be a smaller container, but still a container where the PMC
>>and the committers are not the same entity.
>>
>>HTTPD is a project about a modular HTTP server written in C, it's not a
>>container for all HTTP-related server technology, nor it would be of any
>>help if it became one.
>>
>>I think the ASF should stop forcing project to remain in containers but
>>simply allow them to choose to step up.
>>
>>Cocoon.apache.org will be the community of people around Cocoon and will
>>host, develop and distribute cocoon and cocoon-related software. And the
>>PMC will be directly supervising because it will be composed by all
>>committers of all cvs modules it will host.
>>
>>Also, stuff like Cocoon is very hard to make it fit into a single
>>category.
>>
>>
>>7) how do we move this further?
>>
>>First thing to do is to have a formal votation. All committers should
>>express their vote on this, right here:
>>
>> [ ] +1 I think it's a good idea
>> [ ] 0 I really don't care.
>> [ ] -1, I don't think it's a good idea.
>>
>>Please, vote clearly so that it's easy to make good summaries. If you
>>vote -1, please state your reasoning and propose a creative solution for
>>the problems this proposal tries to address.
>>
>>After the votation we'll see what to do.
>>
>>Thanks.
>>
>>--
>>Stefano Mazzocchi <st...@apache.org>
>>--------------------------------------------------------------------
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [important proposal] Cocoon as official Apache project
Posted by Serge Knystautas <se...@lokitech.com>.
Noel,
I agree, and I'll pass along your comments along with some of my own.
To me the difference is between legal and branding issues... really the
driving factor (that I can see) is legal protection, and making sure a
committer (like us) doesn't create a mailet subproject and make
ourselves liable. Even as this promotion happens though, everyone would
be best served by having James link to other projects under jakarta or
the-projects-formerly-known-under jakarta. I actually think jakarta and
xml projects should link more together. In fact, Tomcat should probably
link to the httpd project since that's often put in front of Tomcat
(although maybe they don't want to appear biased, but I would guess it's
just not something people think about... who knows?)
I wouldn't say it's completely orthogonal though because this legal move
would open the doors to projects like ours to create subprojects, thus
requiring us to restructure the site some.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
Noel J. Bergman wrote:
> Danny,
>
> Stefano Mazzocchi is a bright guy, and most of what he says makes sense,
> except for the restructuring of the web site. For reasons I've stated
> earlier, I think that it is a terrible idea to simply move each project to
> its own sub-domain, making it increasingly more difficult for people to
> locate related information. From what Roy Fielding indicated, everything
> that can be done about making Cocoon a top level project can be done
> independently of a web site reorganization. I'd propose that the legal
> structure and web site structure be considered orthogonal issues.
>
> I'm not saying that the web sites can't, or even shouldn't, be restructured,
> just that the two issues should be dealt with separately, each on its
> merits. In the case of Cocoon, there is a good argument for it to host its
> own pages. But regardless of whether the Apache web becomes a directory of
> sub-domains, each running its own technology; a frontend portal serving up
> (and showcasing) information from multiple technologies; or what-have-you;
> the Apache web ought to be a product of careful design to allow easy access
> to relevant information, and not be a reflection of each project's legal
> status.
>
> Since you are on that list, you might care to pass along these thoughts.
>
> --- Noel
>
> -----Original Message-----
> From: Danny Angus [mailto:danny@apache.org]
> Sent: Wednesday, October 30, 2002 11:10
> To: James Developer List
> Subject: FW: [important proposal] Cocoon as official Apache project
>
>
> If this mail gets through.. (its going via a server being load tested!)
>
> I thought those not on the community/reorg lists might like to read this
> because Stefano outlines quite well at least one view of the
> top-level-project issues.
>
> d.
>
>
>
>>-----Original Message-----
>>From: Stefano Mazzocchi [mailto:stefano@apache.org]
>>Sent: 30 October 2002 13:29
>>To: Apache Cocoon
>>Cc: community@apache.org
>>Subject: [important proposal] Cocoon as official Apache project
>>
>>
>>Ladies and gentlemen,
>>
>>it is with *great* pleasure that I'm finally feel confident enough to
>>ask you about something that is been in the back of my mind for more
>>than a year now.
>>
>>The proposal of making cocoon an official top-level Apache project.
>>
>> - o -
>>
>>Before I state the proposal and its implications, allow me to introduce
>>the context.
>>
>>Currently, Cocoon is not officially considered a 'project' under the ASF
>>bylaws. Cocoon is, in fact, part of the Apache XML Project just like
>>Xalan Xerces Fop Batik and the others.
>>
>>The ASF was designed round the concept of having one big legal umbrella
>>(the foundation) and several focused development communities (the
>>projects).
>>
>>The original idea was, in fact, modeled after how the Apache Group
>>managed the Apache HTTPD project.
>>
>>Unfortunately, the ASF members thought that the same model could well
>>apply to projects which did not release software directly (unlike HTTPD
>>did) and decided to use the same model for jakarta and xml (which don't
>>release software directly, but add another level of indirection with
>>subprojects).
>>
>>The concept and the term "subproject" was, in fact, invented to separate
>>the development community from the container.
>>
>>Over the years, it became clear that project containment yields several
>>drawbacks:
>>
>> 1) container PMCs don't do anything since they are too detached from
>>the actual code (it's impossible they know all about all the code hosted
>>by the single containers!)
>>
>> 2) the subproject committers never have a way to interact directly
>>with the foundation, thus they perceive it as a distant and bureaucratic
>>thing
>>
>> 3) the ASF doesn't have proper legal oversight on the code contained
>>in all sub-projects
>>
>> 4) the trend of sub-projecting created sub-containers (avalon and
>>turbine, for example), thus making all this even worse.
>>
>> 5) the creation of sub-brands and the confusion this created. Example:
>>is Apache Tomcat? or Jakarta Tomcat? or Apache Jakarta Tomcat?
>>
>>Over the last 18 months, several members tried to convince the ASF board
>>that this situation was potentially very dangerous since, in fact, the
>>container projects started to behave more and more as sub-foundations,
>>but without the proper legal understanding. This situation was
>>potentially inflammable in the case of a legal action against a
>>committer since the foundation might not have been able to properly
>>legally shield that committer since it operated outside the bylaws and
>>without proper PMC oversight.
>>
>>Over the same period, several very influential members and board
>>officials were against this notion, stating that it was just a human
>>problem with the people elected on the PMC and *not* a problem in the
>>design of the foundation.
>>
>>After a few new PMC elections, and after finally having a jakarta/xml
>>member elected on the board (Sam Ruby), things are finally starting to
>>change.
>>
>>The ASF board agrees on an open policy on the creation of new top-level
>>Apache projects in the spirit of HTTPD: that is 'one PMC one codebase'.
>>
>>So, in the light of this, I would like to hear your comments on the idea
>>of moving out of xml.apache.org into our own project.
>>
>> - o -
>>
>>Before you start asking a bunch of questions, let me answer a few of
>>them that I might consider FAQs.
>>
>>1) what are the contract changes that the proposal implies? [note, all
>>these are not carved in stone, but just here to give you an idea]
>>
>>Cocoon will be moved on cocoon.apache.org, all pages on xml.apache.org
>>redirected.
>>
>>The cocoon-*@xml.apache.org mail lists will be moved to
>>{1}@cocoon.apache.org.
>>
>>The xml-cocoon2 module will be renamed 'cocoon'. The xml-cocoon1 module
>>moved into hybernation state and stored for historical reasons only.
>>
>>NOTE: cocoon namespaces all start with http://apache.org/cocoon/ so no
>>need to change anything there. [I planned this in advance at least two
>>years ago, so that's why the namespace was already clean]
>>
>>2) what does it mean for the developers?
>>
>>An official Cocoon project will have an official PMC which is what is
>>legally reponsible for the code and reports directly to the board. The
>>PMC officer becomes a vice-president of the ASF.
>>
>>In order to avoid stupid PMC elections, I'll be in favor of having the
>>PMC composed by *all* committers that ask to be part of it. This to
>>imply that committers and legal protector share the same duties and
>>priviledges.
>>
>>In short, it means that if any of us screws legally, the foundation will
>>protect us. Today, this is not the case.
>>
>>3) what does it mean for Cocoon?
>>
>>Being a project allows us to host several different incubation-stage
>>efforts underneath. Cocoblog, wyona, forrest, cocoon-related IDE plugins
>>could be possible additions. Of course, with the idea of promoting them
>>as top-level projects when they are successful from a community
>>perspective.
>>
>>Also, it means that we could have our own machine running the entire
>>cocoon.apache.org web site (that means: finally having Cocoon serving
>>its own pages!)
>>
>>Last but not least, it will give much more visibility to Cocoon since it
>>will be visible directly from www.apache.org
>>
>>4) what are the drawbacks?
>>
>>moving stuff around is always annoying, but I think this is the only
>>major drawback.
>>
>>5) isn't this unfair against the other sub-projects that remain
>>contained, therefore with less visibility?
>>
>>I don't know. Here I'm just stating the intention to move Cocoon to
>>top-level and I know the ASF board is very open to projects willing to
>>move out of their containers.
>>
>>But the ASF will *NOT* force projects to take this action. If other
>>communities feel they should deserve top-level projects, they should
>>make a proposal like this and ask the board instead of complaining with
>>us that we do it.
>>
>>6) isn't a cocoon-related project too specific? wouldn't it be better to
>>have something like 'publishing.apache.org' and host all
>>publishing-related stuff there?
>>
>>No, it would be a smaller container, but still a container where the PMC
>>and the committers are not the same entity.
>>
>>HTTPD is a project about a modular HTTP server written in C, it's not a
>>container for all HTTP-related server technology, nor it would be of any
>>help if it became one.
>>
>>I think the ASF should stop forcing project to remain in containers but
>>simply allow them to choose to step up.
>>
>>Cocoon.apache.org will be the community of people around Cocoon and will
>>host, develop and distribute cocoon and cocoon-related software. And the
>>PMC will be directly supervising because it will be composed by all
>>committers of all cvs modules it will host.
>>
>>Also, stuff like Cocoon is very hard to make it fit into a single
>>category.
>>
>>
>>7) how do we move this further?
>>
>>First thing to do is to have a formal votation. All committers should
>>express their vote on this, right here:
>>
>> [ ] +1 I think it's a good idea
>> [ ] 0 I really don't care.
>> [ ] -1, I don't think it's a good idea.
>>
>>Please, vote clearly so that it's easy to make good summaries. If you
>>vote -1, please state your reasoning and propose a creative solution for
>>the problems this proposal tries to address.
>>
>>After the votation we'll see what to do.
>>
>>Thanks.
>>
>>--
>>Stefano Mazzocchi <st...@apache.org>
>>--------------------------------------------------------------------
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [important proposal] Cocoon as official Apache project
Posted by Danny Angus <da...@apache.org>.
if you have your apache mail address yet you can subscribe too.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 30 October 2002 17:03
> To: James Developers List
> Subject: RE: [important proposal] Cocoon as official Apache project
>
>
> Danny,
>
> Stefano Mazzocchi is a bright guy, and most of what he says makes sense,
> except for the restructuring of the web site. For reasons I've stated
> earlier, I think that it is a terrible idea to simply move each project to
> its own sub-domain, making it increasingly more difficult for people to
> locate related information. From what Roy Fielding indicated, everything
> that can be done about making Cocoon a top level project can be done
> independently of a web site reorganization. I'd propose that the legal
> structure and web site structure be considered orthogonal issues.
>
> I'm not saying that the web sites can't, or even shouldn't, be
> restructured,
> just that the two issues should be dealt with separately, each on its
> merits. In the case of Cocoon, there is a good argument for it
> to host its
> own pages. But regardless of whether the Apache web becomes a
> directory of
> sub-domains, each running its own technology; a frontend portal serving up
> (and showcasing) information from multiple technologies; or what-have-you;
> the Apache web ought to be a product of careful design to allow
> easy access
> to relevant information, and not be a reflection of each project's legal
> status.
>
> Since you are on that list, you might care to pass along these thoughts.
>
> --- Noel
>
> -----Original Message-----
> From: Danny Angus [mailto:danny@apache.org]
> Sent: Wednesday, October 30, 2002 11:10
> To: James Developer List
> Subject: FW: [important proposal] Cocoon as official Apache project
>
>
> If this mail gets through.. (its going via a server being load tested!)
>
> I thought those not on the community/reorg lists might like to read this
> because Stefano outlines quite well at least one view of the
> top-level-project issues.
>
> d.
>
>
> > -----Original Message-----
> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> > Sent: 30 October 2002 13:29
> > To: Apache Cocoon
> > Cc: community@apache.org
> > Subject: [important proposal] Cocoon as official Apache project
> >
> >
> > Ladies and gentlemen,
> >
> > it is with *great* pleasure that I'm finally feel confident enough to
> > ask you about something that is been in the back of my mind for more
> > than a year now.
> >
> > The proposal of making cocoon an official top-level Apache project.
> >
> > - o -
> >
> > Before I state the proposal and its implications, allow me to introduce
> > the context.
> >
> > Currently, Cocoon is not officially considered a 'project' under the ASF
> > bylaws. Cocoon is, in fact, part of the Apache XML Project just like
> > Xalan Xerces Fop Batik and the others.
> >
> > The ASF was designed round the concept of having one big legal umbrella
> > (the foundation) and several focused development communities (the
> > projects).
> >
> > The original idea was, in fact, modeled after how the Apache Group
> > managed the Apache HTTPD project.
> >
> > Unfortunately, the ASF members thought that the same model could well
> > apply to projects which did not release software directly (unlike HTTPD
> > did) and decided to use the same model for jakarta and xml (which don't
> > release software directly, but add another level of indirection with
> > subprojects).
> >
> > The concept and the term "subproject" was, in fact, invented to separate
> > the development community from the container.
> >
> > Over the years, it became clear that project containment yields several
> > drawbacks:
> >
> > 1) container PMCs don't do anything since they are too detached from
> > the actual code (it's impossible they know all about all the code hosted
> > by the single containers!)
> >
> > 2) the subproject committers never have a way to interact directly
> > with the foundation, thus they perceive it as a distant and bureaucratic
> > thing
> >
> > 3) the ASF doesn't have proper legal oversight on the code contained
> > in all sub-projects
> >
> > 4) the trend of sub-projecting created sub-containers (avalon and
> > turbine, for example), thus making all this even worse.
> >
> > 5) the creation of sub-brands and the confusion this created. Example:
> > is Apache Tomcat? or Jakarta Tomcat? or Apache Jakarta Tomcat?
> >
> > Over the last 18 months, several members tried to convince the ASF board
> > that this situation was potentially very dangerous since, in fact, the
> > container projects started to behave more and more as sub-foundations,
> > but without the proper legal understanding. This situation was
> > potentially inflammable in the case of a legal action against a
> > committer since the foundation might not have been able to properly
> > legally shield that committer since it operated outside the bylaws and
> > without proper PMC oversight.
> >
> > Over the same period, several very influential members and board
> > officials were against this notion, stating that it was just a human
> > problem with the people elected on the PMC and *not* a problem in the
> > design of the foundation.
> >
> > After a few new PMC elections, and after finally having a jakarta/xml
> > member elected on the board (Sam Ruby), things are finally starting to
> > change.
> >
> > The ASF board agrees on an open policy on the creation of new top-level
> > Apache projects in the spirit of HTTPD: that is 'one PMC one codebase'.
> >
> > So, in the light of this, I would like to hear your comments on the idea
> > of moving out of xml.apache.org into our own project.
> >
> > - o -
> >
> > Before you start asking a bunch of questions, let me answer a few of
> > them that I might consider FAQs.
> >
> > 1) what are the contract changes that the proposal implies? [note, all
> > these are not carved in stone, but just here to give you an idea]
> >
> > Cocoon will be moved on cocoon.apache.org, all pages on xml.apache.org
> > redirected.
> >
> > The cocoon-*@xml.apache.org mail lists will be moved to
> > {1}@cocoon.apache.org.
> >
> > The xml-cocoon2 module will be renamed 'cocoon'. The xml-cocoon1 module
> > moved into hybernation state and stored for historical reasons only.
> >
> > NOTE: cocoon namespaces all start with http://apache.org/cocoon/ so no
> > need to change anything there. [I planned this in advance at least two
> > years ago, so that's why the namespace was already clean]
> >
> > 2) what does it mean for the developers?
> >
> > An official Cocoon project will have an official PMC which is what is
> > legally reponsible for the code and reports directly to the board. The
> > PMC officer becomes a vice-president of the ASF.
> >
> > In order to avoid stupid PMC elections, I'll be in favor of having the
> > PMC composed by *all* committers that ask to be part of it. This to
> > imply that committers and legal protector share the same duties and
> > priviledges.
> >
> > In short, it means that if any of us screws legally, the foundation will
> > protect us. Today, this is not the case.
> >
> > 3) what does it mean for Cocoon?
> >
> > Being a project allows us to host several different incubation-stage
> > efforts underneath. Cocoblog, wyona, forrest, cocoon-related IDE plugins
> > could be possible additions. Of course, with the idea of promoting them
> > as top-level projects when they are successful from a community
> > perspective.
> >
> > Also, it means that we could have our own machine running the entire
> > cocoon.apache.org web site (that means: finally having Cocoon serving
> > its own pages!)
> >
> > Last but not least, it will give much more visibility to Cocoon since it
> > will be visible directly from www.apache.org
> >
> > 4) what are the drawbacks?
> >
> > moving stuff around is always annoying, but I think this is the only
> > major drawback.
> >
> > 5) isn't this unfair against the other sub-projects that remain
> > contained, therefore with less visibility?
> >
> > I don't know. Here I'm just stating the intention to move Cocoon to
> > top-level and I know the ASF board is very open to projects willing to
> > move out of their containers.
> >
> > But the ASF will *NOT* force projects to take this action. If other
> > communities feel they should deserve top-level projects, they should
> > make a proposal like this and ask the board instead of complaining with
> > us that we do it.
> >
> > 6) isn't a cocoon-related project too specific? wouldn't it be better to
> > have something like 'publishing.apache.org' and host all
> > publishing-related stuff there?
> >
> > No, it would be a smaller container, but still a container where the PMC
> > and the committers are not the same entity.
> >
> > HTTPD is a project about a modular HTTP server written in C, it's not a
> > container for all HTTP-related server technology, nor it would be of any
> > help if it became one.
> >
> > I think the ASF should stop forcing project to remain in containers but
> > simply allow them to choose to step up.
> >
> > Cocoon.apache.org will be the community of people around Cocoon and will
> > host, develop and distribute cocoon and cocoon-related software. And the
> > PMC will be directly supervising because it will be composed by all
> > committers of all cvs modules it will host.
> >
> > Also, stuff like Cocoon is very hard to make it fit into a single
> > category.
> >
> >
> > 7) how do we move this further?
> >
> > First thing to do is to have a formal votation. All committers should
> > express their vote on this, right here:
> >
> > [ ] +1 I think it's a good idea
> > [ ] 0 I really don't care.
> > [ ] -1, I don't think it's a good idea.
> >
> > Please, vote clearly so that it's easy to make good summaries. If you
> > vote -1, please state your reasoning and propose a creative solution for
> > the problems this proposal tries to address.
> >
> > After the votation we'll see what to do.
> >
> > Thanks.
> >
> > --
> > Stefano Mazzocchi <st...@apache.org>
> > --------------------------------------------------------------------
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [important proposal] Cocoon as official Apache project
Posted by "Noel J. Bergman" <no...@devtech.com>.
Danny,
Stefano Mazzocchi is a bright guy, and most of what he says makes sense,
except for the restructuring of the web site. For reasons I've stated
earlier, I think that it is a terrible idea to simply move each project to
its own sub-domain, making it increasingly more difficult for people to
locate related information. From what Roy Fielding indicated, everything
that can be done about making Cocoon a top level project can be done
independently of a web site reorganization. I'd propose that the legal
structure and web site structure be considered orthogonal issues.
I'm not saying that the web sites can't, or even shouldn't, be restructured,
just that the two issues should be dealt with separately, each on its
merits. In the case of Cocoon, there is a good argument for it to host its
own pages. But regardless of whether the Apache web becomes a directory of
sub-domains, each running its own technology; a frontend portal serving up
(and showcasing) information from multiple technologies; or what-have-you;
the Apache web ought to be a product of careful design to allow easy access
to relevant information, and not be a reflection of each project's legal
status.
Since you are on that list, you might care to pass along these thoughts.
--- Noel
-----Original Message-----
From: Danny Angus [mailto:danny@apache.org]
Sent: Wednesday, October 30, 2002 11:10
To: James Developer List
Subject: FW: [important proposal] Cocoon as official Apache project
If this mail gets through.. (its going via a server being load tested!)
I thought those not on the community/reorg lists might like to read this
because Stefano outlines quite well at least one view of the
top-level-project issues.
d.
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: 30 October 2002 13:29
> To: Apache Cocoon
> Cc: community@apache.org
> Subject: [important proposal] Cocoon as official Apache project
>
>
> Ladies and gentlemen,
>
> it is with *great* pleasure that I'm finally feel confident enough to
> ask you about something that is been in the back of my mind for more
> than a year now.
>
> The proposal of making cocoon an official top-level Apache project.
>
> - o -
>
> Before I state the proposal and its implications, allow me to introduce
> the context.
>
> Currently, Cocoon is not officially considered a 'project' under the ASF
> bylaws. Cocoon is, in fact, part of the Apache XML Project just like
> Xalan Xerces Fop Batik and the others.
>
> The ASF was designed round the concept of having one big legal umbrella
> (the foundation) and several focused development communities (the
> projects).
>
> The original idea was, in fact, modeled after how the Apache Group
> managed the Apache HTTPD project.
>
> Unfortunately, the ASF members thought that the same model could well
> apply to projects which did not release software directly (unlike HTTPD
> did) and decided to use the same model for jakarta and xml (which don't
> release software directly, but add another level of indirection with
> subprojects).
>
> The concept and the term "subproject" was, in fact, invented to separate
> the development community from the container.
>
> Over the years, it became clear that project containment yields several
> drawbacks:
>
> 1) container PMCs don't do anything since they are too detached from
> the actual code (it's impossible they know all about all the code hosted
> by the single containers!)
>
> 2) the subproject committers never have a way to interact directly
> with the foundation, thus they perceive it as a distant and bureaucratic
> thing
>
> 3) the ASF doesn't have proper legal oversight on the code contained
> in all sub-projects
>
> 4) the trend of sub-projecting created sub-containers (avalon and
> turbine, for example), thus making all this even worse.
>
> 5) the creation of sub-brands and the confusion this created. Example:
> is Apache Tomcat? or Jakarta Tomcat? or Apache Jakarta Tomcat?
>
> Over the last 18 months, several members tried to convince the ASF board
> that this situation was potentially very dangerous since, in fact, the
> container projects started to behave more and more as sub-foundations,
> but without the proper legal understanding. This situation was
> potentially inflammable in the case of a legal action against a
> committer since the foundation might not have been able to properly
> legally shield that committer since it operated outside the bylaws and
> without proper PMC oversight.
>
> Over the same period, several very influential members and board
> officials were against this notion, stating that it was just a human
> problem with the people elected on the PMC and *not* a problem in the
> design of the foundation.
>
> After a few new PMC elections, and after finally having a jakarta/xml
> member elected on the board (Sam Ruby), things are finally starting to
> change.
>
> The ASF board agrees on an open policy on the creation of new top-level
> Apache projects in the spirit of HTTPD: that is 'one PMC one codebase'.
>
> So, in the light of this, I would like to hear your comments on the idea
> of moving out of xml.apache.org into our own project.
>
> - o -
>
> Before you start asking a bunch of questions, let me answer a few of
> them that I might consider FAQs.
>
> 1) what are the contract changes that the proposal implies? [note, all
> these are not carved in stone, but just here to give you an idea]
>
> Cocoon will be moved on cocoon.apache.org, all pages on xml.apache.org
> redirected.
>
> The cocoon-*@xml.apache.org mail lists will be moved to
> {1}@cocoon.apache.org.
>
> The xml-cocoon2 module will be renamed 'cocoon'. The xml-cocoon1 module
> moved into hybernation state and stored for historical reasons only.
>
> NOTE: cocoon namespaces all start with http://apache.org/cocoon/ so no
> need to change anything there. [I planned this in advance at least two
> years ago, so that's why the namespace was already clean]
>
> 2) what does it mean for the developers?
>
> An official Cocoon project will have an official PMC which is what is
> legally reponsible for the code and reports directly to the board. The
> PMC officer becomes a vice-president of the ASF.
>
> In order to avoid stupid PMC elections, I'll be in favor of having the
> PMC composed by *all* committers that ask to be part of it. This to
> imply that committers and legal protector share the same duties and
> priviledges.
>
> In short, it means that if any of us screws legally, the foundation will
> protect us. Today, this is not the case.
>
> 3) what does it mean for Cocoon?
>
> Being a project allows us to host several different incubation-stage
> efforts underneath. Cocoblog, wyona, forrest, cocoon-related IDE plugins
> could be possible additions. Of course, with the idea of promoting them
> as top-level projects when they are successful from a community
> perspective.
>
> Also, it means that we could have our own machine running the entire
> cocoon.apache.org web site (that means: finally having Cocoon serving
> its own pages!)
>
> Last but not least, it will give much more visibility to Cocoon since it
> will be visible directly from www.apache.org
>
> 4) what are the drawbacks?
>
> moving stuff around is always annoying, but I think this is the only
> major drawback.
>
> 5) isn't this unfair against the other sub-projects that remain
> contained, therefore with less visibility?
>
> I don't know. Here I'm just stating the intention to move Cocoon to
> top-level and I know the ASF board is very open to projects willing to
> move out of their containers.
>
> But the ASF will *NOT* force projects to take this action. If other
> communities feel they should deserve top-level projects, they should
> make a proposal like this and ask the board instead of complaining with
> us that we do it.
>
> 6) isn't a cocoon-related project too specific? wouldn't it be better to
> have something like 'publishing.apache.org' and host all
> publishing-related stuff there?
>
> No, it would be a smaller container, but still a container where the PMC
> and the committers are not the same entity.
>
> HTTPD is a project about a modular HTTP server written in C, it's not a
> container for all HTTP-related server technology, nor it would be of any
> help if it became one.
>
> I think the ASF should stop forcing project to remain in containers but
> simply allow them to choose to step up.
>
> Cocoon.apache.org will be the community of people around Cocoon and will
> host, develop and distribute cocoon and cocoon-related software. And the
> PMC will be directly supervising because it will be composed by all
> committers of all cvs modules it will host.
>
> Also, stuff like Cocoon is very hard to make it fit into a single
> category.
>
>
> 7) how do we move this further?
>
> First thing to do is to have a formal votation. All committers should
> express their vote on this, right here:
>
> [ ] +1 I think it's a good idea
> [ ] 0 I really don't care.
> [ ] -1, I don't think it's a good idea.
>
> Please, vote clearly so that it's easy to make good summaries. If you
> vote -1, please state your reasoning and propose a creative solution for
> the problems this proposal tries to address.
>
> After the votation we'll see what to do.
>
> Thanks.
>
> --
> Stefano Mazzocchi <st...@apache.org>
> --------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>