Re: Promotion of sub projects
On Tuesday, December 9, 2003, at 07:13 AM, Danny Angus wrote: Just for fun I thought I'd fill this out for the Jetspeed and Pluto projects (WSRP4J is another possibility). We would like to start a TLP named 'portal.apache.org' including Jetspeed-1, Jetspeed-2 and Pluto, and other portal apps as they are developed. 1/ Community dynamic, a) Is your community self sustaining and largely independant of other parts of Jakarta? yes Not the individuals, the community. Is it, for instance, so heavily influenced by the direction of some other sub-project that membership of both is virtually a pre-requisite for understanding. b) Are many of your commiters also commiters of some other sub-project for this, or similar, reasons? no 2/ Project Management, a) Does your sub-project need or get much direction from the Jakarta PMC (or is it mostly handled by the comitters with lip service paid to the PMC)? no, lip service 3/ Community health, a) Is your community highly dependant on one or two key people, or is there a real mix of talent working as a team? we are a small group. Jetspeed-2 is currently dependent on 3 people but we are getting more people active We have a lot more active Jetspeed-1 people, but development has tapered off b) Is there generally an amicable, if hotly debated, concensus? yes i think so 4/ Infrastructure resources, a) Does your sub-project have aspirations to own its own top-level resources (cvs, mailing lists, wiki, web-site)? yes 5/ Product seperation, a) Is your product tightly bound to other Jakarta sub-projects (excluding commons) or does it only supply a need or consume deliverables in the usual way? Jetspeed-1 is tied to Turbine Pluto isn't tied to anything Jetspeed-2 is dependent on OJB and we are seriously considering Merlin now b) Does your sub-project contribute a lot of code to another, or receive a lot of contributions from another Jakarta sub-project? J2 and Pluto are closely tied, but Pluto is not dependent on J2 6/ Scope, a) Has your sub-project outgrown it's original scope? I think so. New standards have appeared (Java Portlet Standard, WSRP) and the portlet dev model has changed to a standardized portlet application model with a clear delineation between portal, container and application b) Does your sub-project have a need or desire to maintain it's own sub-projects, incubate new ideas, or accept incubated projects from the incubator? yes we do, see project list above 7/ a) Are there any compeling arguments which can be raised to support remaining within Jakarta? Our list isn't very active compared to others, at least this is my perception, I could be wrong Score 1 for each of the following answers: 1a yes 1b no 2a not much 3a real mix 3b generally amicable 4a yes 5a normal supply/consume relationship 5b not much direct contribution to or by other sub-projects 6a yes 6b yes 7a not really Total 1-3 You probably belong here, consider staying. Total 4-6 You might need to address some issues before you go. Total 7-9 Promotion could be your path to further growth and maturity. Total 10-11 You treat this place like a hotel, its time to think about what you really want. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Promotion of sub projects
On Tue, 2003-12-09 at 23:00, Stephen Colebourne wrote: The question is whether some projects are willing to make the step to TLP. These seem like possible candidates: Tomcat, Lucene, Struts, Velocity Turbine. SCNR Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire Außerdem können in Deutschland alle Englisch. [...] so entfällt die Notwendigkeit [...] Deutsch zu lernen. -- Johan Micoud auf die Frage warum er kein Deutsch spricht. (http://www.spiegel.de/spiegel/0,1518,273205,00.html) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
I'd do it, but I'm not personally involved in JCS. IMHO Martin Poeschl (who is a Turbineer _and_ works with JCS) would be perfect but I know that he will be on holidays for a longer time (either already is or will be soon. Martin?). Martin did the Turbine 2.2 release and most of the Torque releases in the past and I did the 2.3 release of Turbine, so this might count as release management experience. ;-) Regards Henning On Tue, 2003-12-09 at 13:13, robert burrell donkin wrote: in this case, i'd say we'll need sufficient volunteers from the jakarta pmc to ensure oversight during this period. it'd probably be good if they were turbineers and if at least one had recent experience of release management. anyone willing to step up? - robert On 8 Dec 2003, at 15:28, Aaron Smuts wrote: Sounds good. Less disruption on the way to a release would be best. Aaron -Original Message- From: Henning Schmiedehausen [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 3:22 AM To: Jakarta General List Subject: Re: [POLL] Future Of Turbine-JCS IMHO too complex. If there is already a JCS list (is there? As you can see, I'm a Turbine committer but I have zero overlap with JCS. In fact I didn't even know that this is a turbine sub-sub project for quite some time ;-) ), let's keep it. We want to build community? Let's _not_ fold it into the commons list where a completely different culture exists compared to a normal project list. I'm pretty sure that this will scare JCS users away. I'm thinking that making it a direct Jakarta sub project starts to make more and more sense. I'd propose that we move JCS in this direction, if the JCS developers push for a 1.0 release inside turbine-jcs and we make the transition into a Jakarta project with this 1.0 release (which would IMHO a fine reason to do so). Regards Henning On Sun, 2003-12-07 at 17:16, robert burrell donkin wrote: On 5 Dec 2003, at 09:10, Henning Schmiedehausen wrote: On Thu, 2003-12-04 at 20:43, Daniel Rall wrote: Given Robert's description of his experience with the Incubator, I'm for the Jakarta Commons to gather some community (direct drop rather than sandbox route), with the goal of an eventual promotion to a full sub-project. +1 but direct drop only if the move to the commons is accompanied by a release (1.0 or 0.something, I don't care). the way that i'd like to see a potential drop working is by folding the jcs user and development lists into the commons lists first. this would allow the rest of the commons to provide oversight. next, the JCS team should push towards some kind of release for the core engine (even if it's a 0.1 version). once this is ready, we'd update the commons website and officially add JCS to the commons. hopefully this would provide enough momentum to bootstrap a community and to create releases for all the various JCS bits and pieces. once the community exists, then JCS could apply for promotion out of the commons. Else it would not be fair to many other sub-projects currently in the sandbox which have been kept there because there is no release (commons-configuration e.g.). (just to set the record straight on commons-configuration) sandbox components are not allowed to have releases. one major factor when promotion (to the commons proper) is being consider is that a component is ready for a release (even if it's a 0.1 one). i now think that every component in commons proper needs a proper release of some kind so that other projects have the chance to depend on a released version. i'm not sure why eric hasn't started to push towards promotion for commons-configuration but it's possible that there's addition work that needs doing before commons-configuration is ready. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire Außerdem können in Deutschland alle Englisch. [...] so entfällt die Notwendigkeit [...] Deutsch zu lernen. -- Johan Micoud auf die Frage warum er kein Deutsch spricht. (http://www.spiegel.de/spiegel/0,1518,273205,00.html) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
Re: Promotion of sub projects
David Sean Taylor wrote, Just for fun I thought I'd fill this out for the Jetspeed and Pluto projects (WSRP4J is another possibility). We would like to start a TLP named 'portal.apache.org' including Jetspeed-1, Jetspeed-2 and Pluto, and other portal apps as they are developed. Good, well I suggest that your answers (ruthlessly snipped) tell you that its worth pursuing. I'd suggest a good first step would be to start a discussion on the relevant dev list(s) to see if there is broadly support or opposition to the idea. It might be a good idea to provide and overview of what the hell promotion means and enumerate the benefits and drawbacks it brings. I'd be happy to prime you from my own experience, or subscribe and join in, as I'm sure will others who've been through (or oppose) this. If you garner a general consensus the next step would be to draw up a proposal for the commiters to vote upon, including the makeup of the initial PMC, project scope and inaugural PMC chair, and possibly (kind of bootstrappingly) the conditions which have to be met for the vote to be sucessful. If your vote suceeds you then make a formally worded proposal to the board, James included a short covering letter outlining our reasoning. The board then vote and either reject it with recommendations (such as to modify the scope) or accept it and you're faced with the infrastructure tasks. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Promotion of sub projects
Just a reminder, but there need not be a 1:1 mapping of PMC and web domain, so there is no need to breakup the Jakarta web site unless people *want* to do so. Quite so, there's no obligation on a promoted sub-project to abandon its place in the jakarta infrastructure. In fact the idea of Jakarta being a less formal grouping of TLP's with a shared mission and audience has been proposed before and IMO is not a bad idea. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [POLL] Future Of Turbine-JCS
I'll be available in January to get started. Let me know what is involved in a release. -Original Message- From: Henning Schmiedehausen [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 10, 2003 2:51 AM To: Jakarta General List Subject: Re: [POLL] Future Of Turbine-JCS I'd do it, but I'm not personally involved in JCS. IMHO Martin Poeschl (who is a Turbineer _and_ works with JCS) would be perfect but I know that he will be on holidays for a longer time (either already is or will be soon. Martin?). Martin did the Turbine 2.2 release and most of the Torque releases in the past and I did the 2.3 release of Turbine, so this might count as release management experience. ;-) Regards Henning On Tue, 2003-12-09 at 13:13, robert burrell donkin wrote: in this case, i'd say we'll need sufficient volunteers from the jakarta pmc to ensure oversight during this period. it'd probably be good if they were turbineers and if at least one had recent experience of release management. anyone willing to step up? - robert On 8 Dec 2003, at 15:28, Aaron Smuts wrote: Sounds good. Less disruption on the way to a release would be best. Aaron -Original Message- From: Henning Schmiedehausen [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 3:22 AM To: Jakarta General List Subject: Re: [POLL] Future Of Turbine-JCS IMHO too complex. If there is already a JCS list (is there? As you can see, I'm a Turbine committer but I have zero overlap with JCS. In fact I didn't even know that this is a turbine sub-sub project for quite some time ;-) ), let's keep it. We want to build community? Let's _not_ fold it into the commons list where a completely different culture exists compared to a normal project list. I'm pretty sure that this will scare JCS users away. I'm thinking that making it a direct Jakarta sub project starts to make more and more sense. I'd propose that we move JCS in this direction, if the JCS developers push for a 1.0 release inside turbine-jcs and we make the transition into a Jakarta project with this 1.0 release (which would IMHO a fine reason to do so). Regards Henning On Sun, 2003-12-07 at 17:16, robert burrell donkin wrote: On 5 Dec 2003, at 09:10, Henning Schmiedehausen wrote: On Thu, 2003-12-04 at 20:43, Daniel Rall wrote: Given Robert's description of his experience with the Incubator, I'm for the Jakarta Commons to gather some community (direct drop rather than sandbox route), with the goal of an eventual promotion to a full sub-project. +1 but direct drop only if the move to the commons is accompanied by a release (1.0 or 0.something, I don't care). the way that i'd like to see a potential drop working is by folding the jcs user and development lists into the commons lists first. this would allow the rest of the commons to provide oversight. next, the JCS team should push towards some kind of release for the core engine (even if it's a 0.1 version). once this is ready, we'd update the commons website and officially add JCS to the commons. hopefully this would provide enough momentum to bootstrap a community and to create releases for all the various JCS bits and pieces. once the community exists, then JCS could apply for promotion out of the commons. Else it would not be fair to many other sub-projects currently in the sandbox which have been kept there because there is no release (commons-configuration e.g.). (just to set the record straight on commons-configuration) sandbox components are not allowed to have releases. one major factor when promotion (to the commons proper) is being consider is that a component is ready for a release (even if it's a 0.1 one). i now think that every component in commons proper needs a proper release of some kind so that other projects have the chance to depend on a released version. i'm not sure why eric hasn't started to push towards promotion for commons-configuration but it's possible that there's addition work that needs doing before commons-configuration is ready. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire Außerdem können in Deutschland alle Englisch. [...] so entfällt die Notwendigkeit [...] Deutsch zu lernen. -- Johan Micoud auf die Frage warum er kein Deutsch spricht.
Client authentication
Hi all ... My name is Joseph, from the Technical Univerisity of Catalonia (UPC). This is my first messege here ... I'm developing a web application under Apache 1.3.27, with client authentication under a certain path, /htdocs/client_aut ... that is, if a client requires a resource placed under /htdocs/client_aut, he will need to show his or her digital certificate. I have implemented this idea as follows (httpd.conf): Location /usr/local/apache/htdocs/client_aut SSLVerifyClient require SSLVerifiDepth 1 /Location I have a created these certificates: * a CA self-signet certificate, named certificatCA.crt (placed at /conf/ssl.crt) * a server certificate, signed by CA, named certificatSERV.crt (placed at /conf/ssl.crt) * a client certificate, singned by CA, named clientSERV.crt, installed at the client web browser. And I have configured SSL connection as follows: SSLCertificateFile path/to/certificatSERV.crt SSLCertificateKeyfile path/to/clausSERV.key SSLCACertificateFile path/to/certificatCA.crt But it does not work ... when I try to acces to the web server from my brownser, server autenthication is OK, but when I choose clientSERV.crt in order to authenticate me, it does not work. Any tip? Thanks all Josep
Re: Client authentication
On Thu, 11 Dec 2003 03:20 am, Josep Riudavets wrote: Any tip? Thanks all Josep Josep, This list is for the management of the Apache Jakarta project. Questions regarding httpd should be directed to the httpd project. Find the appropriate list here http://httpd.apache.org/lists.html Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
