Re: I feel so vindicated.
Jon Scott Stevens wrote: http://www.freeroller.net/page/ara_e/20021214 I think we are going to see more and more of this over the coming year as the economy gets worse and worse and people are expected to produce real working applications. People are going to start to clue in to the fact that EJB sucks. JSP sucks. JCP sucks. Struts sucks. JSTL sucks. People are going to start to look for real solutions to their problems. Not just marketing hype and bullshit business practices. The page you refer speaks about .Net and COM+ from m$, m$ is known for its marketing. I feel so vindicated. How many years have I been saying the same thing over and over again? =) -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs checkout on cvs.apache.org doesn't work ...?
Hi, When I try to loging on the jakarta's anoncvs, i get this message : C:\maven2 cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login (Logging in to [EMAIL PROTECTED]) CVS password: Unknown host cvs.apache.org. Do you have an idea ? Could my proxy cause this ? I hope i didn't bother you with such a futile question, and if I wrote to the wrong mailing list, please forgive me. Thanks for your advices. Manuel Olivera This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs checkout on cvs.apache.org doesn't work ...?
Seems to be ok from my end... Logging in to :pserver:[EMAIL PROTECTED]:2401/home/cvspublic CVS password: cvs server: Updating jakarta-turbine-maven U jakarta-turbine-maven/.cvsignore U jakarta-turbine-maven/LICENSE.txt ... make sure you can ping cvs.apache.org You are aware that cvs doesn't work through an http proxy? [EMAIL PROTECTED] wrote: Hi, When I try to loging on the jakarta's anoncvs, i get this message : C:\maven2 cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login (Logging in to [EMAIL PROTECTED]) CVS password: Unknown host cvs.apache.org. Do you have an idea ? Could my proxy cause this ? I hope i didn't bother you with such a futile question, and if I wrote to the wrong mailing list, please forgive me. Thanks for your advices. Manuel Olivera This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. - 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 PROTECTED]
Réf. : Re: cvs checkout on cvs.apache.orgdoesn't work ...?
I can't ping cvs.apache.org. Actually, I have to deal with an http proxy ( and I was'nt aware that cvs doesn't work with ) Is it possible to configure cvs to work with it ? Thanx a lot. Manuel Extranet [EMAIL PROTECTED] - 30/01/2003 14:01 Veuillez répondre à [EMAIL PROTECTED] Pour : general cc : Objet : Re: cvs checkout on cvs.apache.org doesn't work ...? Seems to be ok from my end... Logging in to :pserver:[EMAIL PROTECTED]:2401/home/cvspublic CVS password: cvs server: Updating jakarta-turbine-maven U jakarta-turbine-maven/.cvsignore U jakarta-turbine-maven/LICENSE.txt ... make sure you can ping cvs.apache.org You are aware that cvs doesn't work through an http proxy? [EMAIL PROTECTED] wrote: Hi, When I try to loging on the jakarta's anoncvs, i get this message : C:\maven2 cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login (Logging in to [EMAIL PROTECTED]) CVS password: Unknown host cvs.apache.org. Do you have an idea ? Could my proxy cause this ? I hope i didn't bother you with such a futile question, and if I wrote to the wrong mailing list, please forgive me. Thanks for your advices. Manuel Olivera This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. - 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 PROTECTED] This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Réf. : Re: cvs checkout on cvs.apache.org doesn't work ...?
[EMAIL PROTECTED] wrote: I can't ping cvs.apache.org. Actually, I have to deal with an http proxy ( and I was'nt aware that cvs doesn't work with ) Is it possible to configure cvs to work with it ? have a look at http://cvsgrab.sourceforge.net/ /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JCP Process [Was nice ;-)]
Geir Magnusson Jr. wrote: (...) It's the compromise we/I willingly make to be able to work inside the process to help shape it the way we/I think it should be shaped. The only alternative is to try to start another standards body, but I think you will find that, like the other standards bodies, that NDA's will be a part of the process if you want serious players to participate. One of the big issues surrounding standards is the inclusion/discussion of proprietary information offered by participating entities (companies). Whether or not you like the existence of commercial entities in the process, they are there. OK, I'll buy the previous paragraph. But that the participants do sign a NDA does not mean that the group is silent throughout the process, as it often happens with current JSRs. While I can understand that some of the discussions should remain secret, I think that partial agreements (or blocked areas), roadmaps, current work, etc. could and should be communicated, and also feedback asked more frequently. At a bare minimum, a JSR should publish something (be it a status report, demo, API proposal, open issue list, recount of activity,...) at least every three months, and use this information to gather feedback from the outside via a public discussion list. I think the spirit is something along these lines, with the public draft phase, etc., but I think the process can be (and sometimes is) seriously abused. I also think that the temporal granularity of the process was meant to be much smaller than it is becoming, so the concerns I express do apply more and more. Another *constructive* suggestion could be having a different role, people that would not be forced to sign a NDA, and thus could only be exposed to public domain information, but who could be involved in the process restricted to this. This would enforce even more the need of regular unrestricted feed back. These people could act as hubs between public lists and the EG. The whole process reminds me of the bullshit that the European Esprit Program became some time ago, where any company could refrain from having to justify public money by just saying that the work was a commercial trade. I've played in this field already, and in both sides. ;-) Regards, (I'm trying to be as much constructive as I can, being in bed with a flu and my back aching, pending a NMR test to see if it is damaged or not ...) Santiago geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JCP Process [Was nice ;-)]
On Thursday, January 30, 2003, at 10:30 AM, Santiago Gala wrote: Geir Magnusson Jr. wrote: (...) It's the compromise we/I willingly make to be able to work inside the process to help shape it the way we/I think it should be shaped. The only alternative is to try to start another standards body, but I think you will find that, like the other standards bodies, that NDA's will be a part of the process if you want serious players to participate. One of the big issues surrounding standards is the inclusion/discussion of proprietary information offered by participating entities (companies). Whether or not you like the existence of commercial entities in the process, they are there. OK, I'll buy the previous paragraph. But that the participants do sign a NDA does not mean that the group is silent throughout the process, as it often happens with current JSRs. While I can understand that some of the discussions should remain secret, I think that partial agreements (or blocked areas), roadmaps, current work, etc. could and should be communicated, and also feedback asked more frequently. At a bare minimum, a JSR should publish something (be it a status report, demo, API proposal, open issue list, recount of activity,...) at least every three months, and use this information to gather feedback from the outside via a public discussion list. Agreed, good supporting feedback, and this is something that is a current topic of interest in the JCP EC. We (the members of the EC, the ASF being a member) are interested in encouraging openness in the process from the start via support for open mail lists, etc, as well as more public reviews. However, it's still up to the JSR leads. I guess one thing I can do as the EC rep is ensure that for every new JSR that comes up for a vote for acceptance to continue, I lobby the spec lead / EG to make it as open as possible. I think the spirit is something along these lines, with the public draft phase, etc., but I think the process can be (and sometimes is) seriously abused. I also think that the temporal granularity of the process was meant to be much smaller than it is becoming, so the concerns I express do apply more and more. Yes - you are right. Another *constructive* suggestion could be having a different role, people that would not be forced to sign a NDA, and thus could only be exposed to public domain information, but who could be involved in the process restricted to this. This would enforce even more the need of regular unrestricted feed back. These people could act as hubs between public lists and the EG. Yes - indeed. The idea is to have more public participation (vote early and often, as they say in Chicago :) in the process w/o the EG having to expand to include only the mildly interested, and w/o having constraints like an NDA placed on the mildly interested participants. One things I'll say in their defense of general spec lead behavior is that a JSR is a *lot* of work - I have garnered great respect in general for those leading JSR's to successful conclusions, so it's hard to want to dictate a project management style... geir -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JCP Process [Was nice ;-)]
On Thu, 30 Jan 2003, Geir Magnusson Jr. wrote: On Thursday, January 30, 2003, at 10:30 AM, Santiago Gala wrote: Agreed, good supporting feedback, and this is something that is a current topic of interest in the JCP EC. We (the members of the EC, the ASF being a member) are interested in encouraging openness in the process from the start via support for open mail lists, etc, as well as more public reviews. However, it's still up to the JSR leads. I guess one thing I can do as the EC rep is ensure that for every new JSR that comes up for a vote for acceptance to continue, I lobby the spec lead / EG to make it as open as possible. Make the open JSR's open. ie) Give me a list of the JSRs which do have open mail lists and public reviews etc. Especially public reviews in which the public discuss, not just write-only emails. Cultivating an image that the ASF, and yourself on behalf of the ASF, are doing their best to open-up the JCP seems like a good thing. Another *constructive* suggestion could be having a different role, people that would not be forced to sign a NDA, and thus could only be exposed to public domain information, but who could be involved in the process restricted to this. This would enforce even more the need of regular unrestricted feed back. These people could act as hubs between public lists and the EG. Yes - indeed. The idea is to have more public participation (vote early and often, as they say in Chicago :) in the process w/o the EG having to expand to include only the mildly interested, and w/o having constraints like an NDA placed on the mildly interested participants. One things I'll say in their defense of general spec lead behavior is that a JSR is a *lot* of work - I have garnered great respect in general for those leading JSR's to successful conclusions, so it's hard to want to dictate a project management style... Good point. Open-ness does lead to mayhem. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Réf. : Re: Réf. : Re: cvs checkout on cvs.apache.org doesn't work ...?
It works ! Thanks a lot ! Extranet [EMAIL PROTECTED] - 30/01/2003 14:11 Veuillez répondre à [EMAIL PROTECTED] Pour : general cc : Objet : Re: Réf. : Re: cvs checkout on cvs.apache.org doesn't work ...? [EMAIL PROTECTED] wrote: I can't ping cvs.apache.org. Actually, I have to deal with an http proxy ( and I was'nt aware that cvs doesn't work with ) Is it possible to configure cvs to work with it ? have a look at http://cvsgrab.sourceforge.net/ /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JCP Process [Was nice ;-)]
Geir Magnusson Jr. wrote: (...) agreed Yes - indeed. The idea is to have more public participation (vote early and often, as they say in Chicago :) in the process w/o the EG having to expand to include only the mildly interested, and w/o having constraints like an NDA placed on the mildly interested participants. It would bring global health to the process, I would say, even if the public participation was restricted to voice and lobbying from the outside, with no vote in the process. One things I'll say in their defense of general spec lead behavior is that a JSR is a *lot* of work - I have garnered great respect in general for those leading JSR's to successful conclusions, so it's hard to want to dictate a project management style... I agree, and it is precisely the kind of work that I'm very bad at doing (except maybe for detecting incoherent documents, or things like this), so I would not take this role eagerly. I also respect them a lot. But a lot of the work is political, making minimum agreements, unblocking issues, etc. Judicious use of open lists to help promote general approaches to problems, to test the water, or to try to get feedback or pressure to pass political blockings could *ease* it, rather than the opposite. (I'm quite sure that Stefano, for instance, would know how to manage a JSR this way :-) Regards, Santiago geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I feel so vindicated.
However wrong or right you are or were, Jon, the place you site is clearly written by a box of rocks. At 11:58 PM 1/29/03 -0800, you wrote: http://www.freeroller.net/page/ara_e/20021214 I think we are going to see more and more of this over the coming year as the economy gets worse and worse and people are expected to produce real working applications. People are going to start to clue in to the fact that EJB sucks. JSP sucks. JCP sucks. Struts sucks. JSTL sucks. People are going to start to look for real solutions to their problems. Not just marketing hype and bullshit business practices. I feel so vindicated. How many years have I been saying the same thing over and over again? =) -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] LEGAL NOTICE This electronic mail transmission and any accompanying documents contain information belonging to the sender which may be confidential and legally privileged. This information is intended only for the use of the individual or entity to whom this electronic mail transmission was sent as indicated above. If you are not the intended recipient, any disclosure, copying, distribution, or action taken in reliance on the contents of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please delete the message. Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LGPL beans imported into code at Apache....
On 30/1/03 7:58 Paul Hammant [EMAIL PROTECTED] wrote: different subject/ I am not sure of Steffano's assertion that a Cocoon block can be GPL from the last of that thread.. If it does an import of org.apache.anything it is in trouble from my understanding of RMS's typed GPL wisdoms (pasted below from http://www.fsf.org/licenses/license-list.html#GPLIncompatibleLicenses ) : That is RMS's vision, Roy's quite different, and I and Stefano ( with ONE f) both agree with him. And as I pointed out in my emails to cocoon-dev, this should be really a discussion targeted to community@ or licensing@ ... God bless the power to say off topic :-) :-) Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nice
On 30/1/03 13:26 Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Wednesday, January 29, 2003, at 10:03 AM, [EMAIL PROTECTED] wrote: Yeah, for instance, I was once interviewed for a contract to hire gig at Microsoft. (This was circa '97 prior to my involvment in Java). Had I sold my soul, would I still be able to be a member of Apache? In my brief association with the ASF, I have never heard of a person being discriminated against because of their employer. Let's not forget that our CHAIRMAN (Greg Stein) worked for quite an extensive period at Microsoft... And he's one of the nicest guys I've met in my entire life: From http://www.lyra.org/greg/: Between 1996 and 1998, Mr. Stein worked at Microsoft as a Development Manager, in the Commerce Server and Site Server groups. He was also a co-founder and the Corporate Technologist of eShop, one of the first electronic commerce software companies, before its acquisition by Microsoft in 1996. Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LGPL beans imported into code at Apache....
Mr RMS then needs to publish something about using LGPL/GPL with Java. Personally I agree with the need for LGPL for library applications, however LGPL's wording is phrased in C terminology and I have never seen anyone offering good legal advice on whether LGPL is usable with Java properly. So that means using BSD. Afaik, Apache and BSD licenses are pretty much the same, except that Apache license is 1) copyright owned by ASF and 2) Useable only by the ASF. I wish his page would list what the few requirements are that render it incompatible with GNU GPL, or whether it is a lack of requirements. Hen On Thu, 30 Jan 2003, Pier Fumagalli wrote: On 30/1/03 7:58 Paul Hammant [EMAIL PROTECTED] wrote: different subject/ I am not sure of Steffano's assertion that a Cocoon block can be GPL from the last of that thread.. If it does an import of org.apache.anything it is in trouble from my understanding of RMS's typed GPL wisdoms (pasted below from http://www.fsf.org/licenses/license-list.html#GPLIncompatibleLicenses ) : That is RMS's vision, Roy's quite different, and I and Stefano ( with ONE f) both agree with him. And as I pointed out in my emails to cocoon-dev, this should be really a discussion targeted to community@ or licensing@ ... God bless the power to say off topic :-) :-) Pier - 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 PROTECTED]
Re: nice
Right but he's not AFAIK working there now and potentially exposed to NDA-tainted individuals :-) -Andy - Original Message - From: Pier Fumagalli [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Geir Magnusson Jr. [EMAIL PROTECTED] Sent: Thursday, January 30, 2003 4:31 PM Subject: Re: nice On 30/1/03 13:26 Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Wednesday, January 29, 2003, at 10:03 AM, [EMAIL PROTECTED] wrote: Yeah, for instance, I was once interviewed for a contract to hire gig at Microsoft. (This was circa '97 prior to my involvment in Java). Had I sold my soul, would I still be able to be a member of Apache? In my brief association with the ASF, I have never heard of a person being discriminated against because of their employer. Let's not forget that our CHAIRMAN (Greg Stein) worked for quite an extensive period at Microsoft... And he's one of the nicest guys I've met in my entire life: From http://www.lyra.org/greg/: Between 1996 and 1998, Mr. Stein worked at Microsoft as a Development Manager, in the Commerce Server and Site Server groups. He was also a co-founder and the Corporate Technologist of eShop, one of the first electronic commerce software companies, before its acquisition by Microsoft in 1996. Pier - 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 PROTECTED]
Re: [Discussion] (Fake)Forrest for Jakarta!
Hi. I think this is important and I would love to see some unification of skins on Apache. While we may choose to use different tools to build our sites but I think we should push to make the look of the project consistent. The current mess of different skins makes the site look sloppy. Agree/disagree? Lets hear your opinion. Regards, Glen Stampoultzis At 08:42 AM 30/01/2003 +0100, you wrote: Hi all! I saw the Tapestry discussion, and this remindet me, that I wanted to carry FakeForrest to Jakarta! So what is it? Simple: It's a set of 2 Velocity/Anakia template-files and some images. The Velocity templates are build upon the Jakarta-ones and follow the Jakarta-Anakia-DTD! What does it? It renders Anakia-build websites with the (current - with some small modifications - see below) Forrest skin. Where can I find it? We currently use this to build the http://ant.apache.org website so you can preview the result there and the sources are in the Ant-cvs http://cvs.apache.org/viewcvs/jakarta-ant/xdocs/stylesheets/. Why should we use it? IMHO it is the FASTEST way to provide a nice, functional and consistent look of the entire xxx.apache.org website! Are there any limitations? Yes: Currently there are no multiple tabs for menues on the left side, but this can easyly be solved by allowing multiple menu-sections in the proect.xml Additionally: We (Conor ;)) recently fixed some incompatibilities with the HTML 4.01 standard so it now generates validatable HTML 4.01 code! It's proved, it works, it's nice ;). Remark: I do not see Fake-Forrest as the final solution, but its a nice and fast way in moving to a nice new, consisten etc. look of the Apache website, as I said before! Thoughts? Christoph - 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 PROTECTED]
Re: [Discussion] (Fake)Forrest for Jakarta!
Content of the site is far more important to me than the skin. I'd much rather we had all projects/sites listing a common, agreed upon set of information that is useful. For example, the set of reports maven produces under the heading Project Info (see http://jakarta.apache.org/turbine/maven/project-info.html ), along with source cross reference and javadocs, cvs activity reporting, unit test and 'style conformance'. Skins are secondary for me. If we could get consistent content across Jakarta, having a consistent look and feel would be the next step. But having everything look pretty but be incomplete is not much of a step up. So, how about getting some consistency in our navigation and content as part of the process? -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au Glen Stampoultzis [EMAIL PROTECTED] wrote on 31/01/2003 12:44:53 PM: Hi. I think this is important and I would love to see some unification of skins on Apache. While we may choose to use different tools to build our sites but I think we should push to make the look of the project consistent. The current mess of different skins makes the site look sloppy. Agree/disagree? Lets hear your opinion. Regards, Glen Stampoultzis At 08:42 AM 30/01/2003 +0100, you wrote: Hi all! I saw the Tapestry discussion, and this remindet me, that I wanted to carry FakeForrest to Jakarta! So what is it? Simple: It's a set of 2 Velocity/Anakia template-files and some images. The Velocity templates are build upon the Jakarta-ones and follow the Jakarta-Anakia-DTD! What does it? It renders Anakia-build websites with the (current - with some small modifications - see below) Forrest skin. Where can I find it? We currently use this to build the http://ant.apache.org website so you can preview the result there and the sources are in the Ant-cvs http://cvs.apache.org/viewcvs/jakarta-ant/xdocs/stylesheets/. Why should we use it? IMHO it is the FASTEST way to provide a nice, functional and consistent look of the entire xxx.apache.org website! Are there any limitations? Yes: Currently there are no multiple tabs for menues on the left side, but this can easyly be solved by allowing multiple menu-sections in the proect.xml Additionally: We (Conor ;)) recently fixed some incompatibilities with the HTML 4.01 standard so it now generates validatable HTML 4.01 code! It's proved, it works, it's nice ;). Remark: I do not see Fake-Forrest as the final solution, but its a nice and fast way in moving to a nice new, consisten etc. look of the Apache website, as I said before! Thoughts? Christoph - 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 PROTECTED] ForwardSourceID:NT000AB40A - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Jakarta Site Was: [Discussion] (Fake)Forrest for Jakarta!
Henri Yandell [EMAIL PROTECTED] wrote on 31/01/2003 02:28:59 PM: [snip] However, a consistent skin might actually be the best way to get a consistently labelled and functional site together. Now I get to disagree with Dion :) His list of important things, the ones Maven produce, are by and large not important. The important things are the ones the user cares about: They're important to me as a developer. As a user, yeah it's a different list. How about we give these items some names: 1) Where do I download? Downloads 2) Has their been a release? Release Notes 3) Where are the tutorials/documentation? Documentation 4) How do I complain about a bug? Bugs 5) Where do I ask a question? Mailing Lists and then more minor questions like: 6) So who is behind Project X? Team Members 7) What Apache community does Project X belong to? What's an Apache community? Do you mean 'top-level project'? [snippage] Those who can't do, complain. But I'm happy to be a member of both sets. I believe the first step is to actually try to cross-manage the site. Tbh, I What's cross-management? Once a site-wide contract for labelling and minimum functionality is ironed out, each particular look and feel, project and generational tool are free to enhance it as much as they want, as long as they: eg) Provide a link called 'Download nightly build' or whatever. Cool. Let's take a stab at it then. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Jakarta Site Was: [Discussion] (Fake)Forrest for Jakarta!
On Fri, 31 Jan 2003 [EMAIL PROTECTED] wrote: Henri Yandell [EMAIL PROTECTED] wrote on 31/01/2003 02:28:59 PM: How about we give these items some names: Sounds good. 1) Where do I download? Downloads 2) Has their been a release? Release Notes Possibly this should be 'Status' as projects may not have had a release. I'm thinking that this section is more: Status: We are working on version 3.0. It's aimed to contain blah blah, world peace, profitable websites and no arguments. 3) Where are the tutorials/documentation? Documentation 4) How do I complain about a bug? Bugs 5) Where do I ask a question? Mailing Lists and then more minor questions like: 6) So who is behind Project X? Team Members 7) What Apache community does Project X belong to? What's an Apache community? Do you mean 'top-level project'? Nope. Like, Jakarta should point to the Apache front page somewhere, Ant should too. BSF should point to Jakarta. ie) Apache projects are a hierarchy. If the idea of a project being in multiple communities occurs, then it would list these. [snippage] Those who can't do, complain. But I'm happy to be a member of both sets. I believe the first step is to actually try to cross-manage the site. Tbh, I What's cross-management? Management's obviously a bad word, but I'm thinking of some form of structure that Apache sites have to fit into. Like saying that every subsite has to show the Apache logo etc. Basically trying to create a site-contract that sub-projects agree to, hopefully helping to make the site more usable to users without forcing anything too painful on projects. Once a site-wide contract for labelling and minimum functionality is ironed out, each particular look and feel, project and generational tool are free to enhance it as much as they want, as long as they: eg) Provide a link called 'Download nightly build' or whatever. Cool. Let's take a stab at it then. Okay. I'd like to start a document, I guess Wiki would be a good choice for this, and evolve the document. Wiki, Mailing list, jakarta-site2 cvs? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: The Jakarta Site Was: [Discussion] (Fake)Forrest for Jakarta!
Hi! Sorry! Just picking one point, but :)! 7) What Apache community does Project X belong to? What's an Apache community? Do you mean 'top-level project'? Nope. Like, Jakarta should point to the Apache front page somewhere, Ant should too. BSF should point to Jakarta. Agrreed 100% - and this is what the forrest skin does in the header line (http://ant.apache.org, http://xml.apache.org/forrest) Of course this feature is part of FakeForrest :) ie) Apache projects are a hierarchy. If the idea of a project being in multiple communities occurs, then it would list these. If you mean Ant for example: As you might have missed, Ant was promoted from a Jakarta to a toplevel Apache project, so the link on Jakarta is just there to redirekt to the correct page, because hundreds for websites, programs, manuals etc. point to the jakarta website talking about Ant! Probably the link can be removed from project.xml but the redirecting page has to remain :)! Additionally: I think it's pretty important to know how old some information is. For this reason (Fake)Forrest generates the deploy/generation date in the footer row... Just my 2 cents :) Cheers, Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: The Jakarta Site Was: [Discussion] (Fake)Forrest for Jakarta!
On Fri, 31 Jan 2003, Christoph Wilhelms wrote: Sorry! Just picking one point, but :)! Slice it all apart, one point at a time :) 7) What Apache community does Project X belong to? What's an Apache community? Do you mean 'top-level project'? Nope. Like, Jakarta should point to the Apache front page somewhere, Ant should too. BSF should point to Jakarta. Agrreed 100% - and this is what the forrest skin does in the header line (http://ant.apache.org, http://xml.apache.org/forrest) Of course this feature is part of FakeForrest :) Good. Hopefully all technologies used to fuel the sites will be able to do the same. :) ie) Apache projects are a hierarchy. If the idea of a project being in multiple communities occurs, then it would list these. If you mean Ant for example: As you might have missed, Ant was promoted from a Jakarta to a toplevel Apache project, so the link on Jakarta is just there to redirekt to the correct page, because hundreds for websites, programs, manuals etc. point to the jakarta website talking about Ant! Probably the link can be removed from project.xml but the redirecting page has to remain :)! Not necessarily. Even though Ant, James etc have left Jakarta, ASF discussions a while back [started off by Brian Behlendorf's email on having categories/communities] suggest that Ant and James may still belong to the Jakarta community, as well as being top-level projects. I think this entire concept is still quite in the air. Additionally: I think it's pretty important to know how old some information is. For this reason (Fake)Forrest generates the deploy/generation date in the footer row... Ah, definitely good. I'll add it to the 'contract'. Am writing up a first one now. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
