Re: Missing PGP keys
El lun, 06-03-2006 a las 03:07 -0500, Henri Yandell escribió: I am now back in business on the signing of PGP keys etc. So I get to irritate by pointing out that we have 26 unsigned files in our distribution: http://people.apache.org/~henkp/checker/sig.html#unsig-jakarta felipeal taylor (jetspeed - need to kick this out of our dist(?)) jetspeed-1.5 is the last release kept under jakarta. There is a 1.6 under portals. David, can Hen delete it or should we just move it over to portals? or even you sign it in place? Regards Santiago rwaldhoff dirkv ggregory sanders glens Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- VP and Chair, Apache Portals (http://portals.apache.org) Apache Software Foundation signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: List moderation
El mié, 10-08-2005 a las 11:27 +0200, Torsten Curdt escribió: Hi, I've been a moderator for the bcel-dev@jakarta.apache.org and bcel-user@jakarta.apache.org for a few months now. In that time there have been 2 valid emails from people who weren't subscribed, and a few thousand spam mails. I'm rather tired of being a human spam filter for the mailing list. As the ratio of bad to good emails is so high, I suggest that all mails from unsubscribed users simply be discarded making moderation unnecessary. What's the general opinion about this? The question is why do we use moderation at all? I can see only the reason of cross-posting which is discouraged anyway ...and still could be done by people who are subscribed to both lists. ...so I am with you on this with some scripting magics, we could add to the allow list of all maining lists all apache.org addresses and aliases set up in some files (iclas.txt and other ones), which would also kill the main use case for moderation. Even allowing all email addresses subscribed to any apache.org list to post to the rest of the public onesm though this would be less safe. This would leave open for moderation only a few broad lists (for instance [EMAIL PROTECTED], which I have the pleasure to moderate :-( ), killing a lot of wasted hours. Also, FYI, joes2 is doing some info gathering on moderation request to aid us in filtering incoming moderation spam. See irc://irc.freenode.net/#asfinfra for more info. Regards Santiago cheers -- Torsten -- VP and Chair, Apache Portals (http://portals.apache.org) Apache Software Foundation signature.asc Description: This is a digitally signed message part
Re: Need help on groups in jetspeed
El miércoles, 28 ener, 2004, a las 11:15 Europe/Madrid, Naveen escribió: Hi any idea about groups/roles are assigned.i cannot understand how the concept of groups in jetspeed. Read the message you quoted: This is not the place, try [EMAIL PROTECTED] for this kind of questions. With regards Naveen Thanks in advance Santiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problems with mail Was: [test] ignore
El miércoles, 28 ener, 2004, a las 14:42 Europe/Madrid, Henri Yandell escribió: all apache mail has stopped getting into my inbox for the last day. bizarre. My mail *to* apache is getting slow, but I'm not seeing more than a couple hours delays. My mail *from* apache is arriving well. Brian acknowledged, at infrastructure@, problems dealing with the storm of viruses and rejection notices coming back from forged From addresses. he had to throttle qmail, which can cause delays and failed connections: I've limited incoming SMTP connections (...), and since we're effectively under DDoS attack that means there may be a delay before a valid message makes it into daedalus. I bet your problem is more your provider completely overwhelmed locally. Regards, Santiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PGP Key signing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El miércoles, 21 ener, 2004, a las 01:26 Europe/Madrid, Mark R. Diggory escribió: I'm finishing up writing a PGP plugin for maven to generate public/private keypairs, sign artifacts, verify artifacts and do encryption/decryption. This should eventually make publishing to the maven repository very smooth and easy to accomplish. I would like to gather together the following into some PGP/MD5 FAQ documentation for the Apache site: 1.) Proper procedures for generating and publishing PGP keys for use at Apache. Answer simple questions like; where to place your public keys. where not to place your private keys. 2.) How to go about key signing to build up the web of trust at Apache. When I was browsing Henk's page I noticed the web of trust stuff: http://www.apache.org/~henkp/trust/apache.html http://apache.org/~erikabele/wot/wot.html http://www.apache.org/~henkp/md5/doc.html http://www.apache.org/~henkp/sig/ There was a keysigning event during the last ApacheCON, and I hope this will be ongoing for future ones. It was very nice, I really enjoyed it. In [EMAIL PROTECTED] there have been interesting discussion on how to sign other Apache people keys, etc. Also, I see no links to the wiki, where there is another bunch of resources already: http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases 3.) As much other interesting errata as possible concerning PGP signatures and MD5 checksums. If you have any more interesting links, important documentation, etc, or come across anything. I'd like to start building them up into a canonical source on this stuff. I was looking for pages on the key signing event, but I couldn't found them. I cc: community, where the action took place last time. thanks, Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQFADjo2ZAeG2a2/nhoRAucvAKDnE4uRqxpUCLs2jcdjv/Cjs+C43gCeOvba 14hbeByUB4otofAO/2jl2W4= =K+BP -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] POI 2.0 final release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El miércoles, 21 ener, 2004, a las 11:46 Europe/Madrid, Avik Sengupta escribió: Dear Jakarta PMC The POI community has voted to release POI 2.0 final, including 5 committer yea's and no nay's. The dev list thread with the vote (and details of the release) is accessible here: http://nagoya.apache.org/eyebrowse/BrowseList?listName=poi- [EMAIL PROTECTED]by=threadfrom=621794 We request to the PMC to ratify this release. [ ] +1 [ ] 0 [ ] -1 Herewith, my +1 +1 signed with my apache identity :-) Thanks - Avik (on behalf of the POI team) PS.Sorry for the cross-posting (wasn't sure) but I imagine its best to keep replies and votes to [EMAIL PROTECTED] PPS. With many elected but pending members on the PMC, someone please help me count the votes! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQFADntuZAeG2a2/nhoRAtN7AJ0TMGkze2SIaGpYrRkHSfOi6zvqvQCeJxAR kt3UmhbxX7/UAEbsuUUfM9g= =VPSd -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El martes, 20 ener, 2004, a las 13:44 Europe/Madrid, Francisco Javier Fabra Caro escribió: Hi all! I'm trying to install the mod_jk with Apache 1.3.27 and Tomcat 4.1.29. I Don't do that unless it is a vendor version properly patched. 1.3.27 has security problems. have installed Apache and Tomcat sucessfully, but I'm not able to compile and/or install the mod_jk connector. Someone has been able to install the module with this versions of Apache+Tomcat? Some guidelines? I have done it quite a few times under linux, Solaris, and whatever *ix runs in the Compaq alphas. Basically I follow strictly the HOWTO. OTOH, if you use a linux distro, you can look around for binary packages for mod_jk. regards, Santiago -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQFADWX2ZAeG2a2/nhoRAiBOAJ97p71MNaf+XEaz+kKLpd9sGpPVsQCeJ5Ky b9Vhz5MyLgKQmCw2oqQ0z+c= =nafH -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT][VOTE] ORO 2.0.8 maintenance release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El domingo, 28 dici, 2003, a las 23:21 Europe/Madrid, Daniel F. Savarese escribió: The resolution to approve a 2.0.8 maintenance release of jakarta-oro has passed with 4 binding +1 votes from Jakarta PMC members and no -1 votes. Many thanks to all who voted. I will now proceed to package and upload a release for distribution, update appropriate Web pages, and email an announcement after 24 hours to give sufficient time for mirrors to pick up the release. A summary of the voting results follows: Binding +1 Votes: Geir Magnusson Jr geir.4quarters.com Craig McClanahan cragmcc.apache.org Scott Sanders scott.dotnot.org Daniel Savaresedfs.savarese.org My (binding) vote was emitted on 24, between Daniel's and Scott's. Now I see it went just to general pmc, because I was following on the informative re-broadcast, so this is the reason why it has not been counted. I think (I seem to recall it used to be done) that VOTEs should specify where they should happen. No problem for this one, as it does not change the result at all. Non-Binding +1 Votes: Gary Gregory ggregory.seagullsw.com (PMC membership pending paperwork) Mark F. Murphy markm.tyrell.com (oro user and code contributor) Takashi Okamototoraneko.kun.ne.jp (oro user and code contributor) Regards, Santiago -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/8NPRZAeG2a2/nhoRAhTjAJsF74t3Phiq7GXpaXwcr7sww4XVOACeOWd2 ztOTe/qYHKhFVsvQ/7YqYgw= =WXW/ -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Scalability and oversight (Was: Just in case you're curious)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El lunes, 22 dici, 2003, a las 16:32 Europe/Madrid, Geir Magnusson Jr. escribió: You are free to do what you want. Is this then about personal google hitcount? To the risk of re-starting a extinguishing discussion, I think google (or any outsider looking) plays an important role here, but not in the personal hitcount sense. I think openness of product *and* process is the only thing that makes us scalable and fault-tolerant, when comparing Apache with more traditional organizations. Scalable because big groups of people can coordinate, even if they don't give specific input or they were not there while the decision was taken. Fault tolerant because the public audit trail left in CVS and mailing lists makes it easy for third party observers (or interested parties) to spot any error in oversight. If we go to the cathedral versus bazaar metaphor, nothing beyond a small group conversation remains private in the bazaar. So, if some merchant down there is selling cheaper, notice propagates fast. Same if some merchandise is faulted. Regards, Santiago -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/7dHTZAeG2a2/nhoRAi7eAJ9pUnQq+8hmLuEKD73x6lvObEifpgCcCdLb fdLDLa/g0yUhMi6fbZeGDmM= =m7pb -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ontology-based portals - RDF, LDAP, Xindice (was: java@apache)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El viernes, 26 dici, 2003, a las 07:06 Europe/Madrid, Noel J. Bergman escribió: J.Pietschmann wrote: Noel J. Bergman wrote: This could be interesting, Henri. If we had an formal description of a project, providing its name, resource (www, scm, wiki, etc.) locations, ontological classifications, etc., I imagine that could be useful in producing a portal. Sounds awfully close to a Maven project.xml. As you note, sounds close to a lot of different things. There should not any dependence on Maven, although Maven could populate the system for projects that are using it. However, the key thing above, and seemingly missing from Maven's Project descriptor, is ontology, so I am curious to see Henri's approach. Ontology is a useful, but damned dangerous word :-) The name of Sam Ruby's blog, as well as a lot of its content, says it all about the meta-data vs data discussions. I was involved in couple of Esprit project about knowledge acquisition and domain ontologies some time ago, and my personal conclusions on the efforts, much like Sam's is that It's just data ( http://intertwingly.net/ ) I liked a lot Stefano's comment on semanticsheets ( http://www.betaversion.org/~stefano/linotype/news/26/ ), in which he used the Library of Babel story that the web always evokes on me. Two weeks later, Jon Udell quotes him ( http://weblog.infoworld.com/udell/2003/08/08.html#a773 a RSS/RDF epiphany ): The mental model that XML promotes is basically a tree of couples. The mental model that RDF promotes is basically a collection of triples. Sounds familiar doesn't it? The Hierarchical vs. Relational war over again 30 years later? Danny Ayers says here ( http://dannyayers.com/archives/001693.html ) in response to the previous entry: structural things* * searching for a word that's not overloaded - something that would mean elements in the non-XML sense or entities and relationships I think a RDF vs LDAP vs XIndice discusion would be again a part of the same old war. Regards Santiago We would want some nice means for aggregating and dynamically managing the data, but fortunately we have a ready standard for dealing with the content: LDAP. The nice thing about standards is that there are so many to choose from. There are also RDF/RSS/DC and a variety of other XML based metadata languages (Topic Maps would fit almost as well as LDAP). Yes. However, although there are certainly plenty of XML formats from which to draw, or even to support, few might be considered a standard, and there are even fewer such standards when it comes to a data-access interface for dealing with hierarchical, attributed data. LDAP is one; an XPath/XQuery-based XML DB server would be another route. RDF (http://www.w3.org/RDF/) is a W3C specification for the ontology aspect of the Semantic Web. The RDF syntax (http://www.w3.org/TR/REC-rdf-syntax/) has a decent mapping to LDAP. This is not a new idea, you can see from: http://lists.w3.org/Archives/Public/www-rdf-interest/2000Jan/0048.html http://rdf-ldap.ucpel.tche.br/ http://www.openldap.org/lists/openldap-software/29/msg00571.html http://lists.oasis-open.org/archives/dsml/29/msg00021.html An alternative to LDAP could be Xindice (http://xml.apache.org/xindice/). At least one of the Xindice developers is subscribed to this list. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/7A+qZAeG2a2/nhoRAqnfAJ9Qay6h3Jw0gBBY9SvjthOsO+1wEgCfS140 iIvPNIhTOWxnFJ6nl7r4e9Q= =XHOW -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java@apache
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El viernes, 26 dici, 2003, a las 01:32 Europe/Madrid, Henri Yandell escribió: On Thu, 25 Dec 2003, J.Pietschmann wrote: Noel J. Bergman wrote: This could be interesting, Henri. If we had an formal description of a project, providing its name, resource (www, scm, wiki, etc.) locations, ontological classifications, etc., I imagine that could be useful in producing a portal. Sounds awfully close to a Maven project.xml. This is what I've spent some moments today playing with. Building a portal.xml and a set of ontology xml's around maven project.xmls. Then a series of xsl things to make a static site. Having different views of the projects and project components looks an interesting idea (not just for java). This stroke me of Noel's proposal of keeping jakarta as a meta project, instead of an umbrella project. I.E., having jakarta as a coordinating and marketing place, where different java project would crosspollinate and coordinate together, but free of oversight concerns, which would be addressed separately by each project. While I'm not sure something like this would work, neither how would it work, I think exploring the possibility is worthwhile. Regards, Santiago Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/7BBIZAeG2a2/nhoRAiUXAJ0WirUiI69vjzyjtNfnC/SJpm1OtQCguC03 aeFthNOmtzfPPYKA9Cs3+5k= =X3xg -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] ORO 2.0.8 maintenance release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El miércoles, 24 dici, 2003, a las 02:39 Europe/Madrid, Daniel F. Savarese escribió: [X] +1 I approve the release of jakarta-oro version 2.0.8. [ ] -1 I do not approve the release of jakarta-oro version 2.0.8. +1 From here. Just another binding +1 missing. Regards, Santiago -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD4DBQE/6VWGZAeG2a2/nhoRAnvwAKCHwrXZAo4jBCdjO8ExFFbv1fiNIQCY3DEF qm4zHx0lyMLKeCZmoJZ2nA== =MvOg -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Just in case you're curious
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El domingo, 21 dici, 2003, a las 02:35 Europe/Madrid, Henri Yandell escribió: On Sat, 20 Dec 2003, Santiago Gala wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El jueves, 18 dici, 2003, a las 15:52 Europe/Madrid, Henri Yandell escribió: http://jakarta.apache.org/site/whoweare.html lists the PMC members up until the previous addition of 20 or so. That list has to go to the board etc and I plan to add them to the list as soon as I see them appear on the board's list [in the committers/ cvs module]. I have just discovered I'm listed as PMC member in the web page. When was I appointed? is there no notification to elected people? Ack. Sorry. Completely my mistake. I added you along with three others, thinking you'd been part of a batch vote with them. Instead your vote was separate one. This is the kind of problems that happen with private lists. I received a copy of my nomination from Andrew, back in October. But, as I saw no resolution about the election here, I thought there had been no vote. I have subscribed board@ in December, because Greg encouraged all members doing so. I previously thought I could read the archives but not subscribe to it. Had I done it earlier I would have seen the message to the board confirming the elections in Nov 19. (I did a grep in the archives yesterday, this is how I know now that I have actually been elected, somewhere in november). Regards, Santiago -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/5V8RZAeG2a2/nhoRAgjHAJ4iF0klknShwnKVXA/nLZ9im0dcGgCdEq92 7KWBgEm6Q15f6uEjm4rbE5Q= =geuj -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Just in case you're curious
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El jueves, 18 dici, 2003, a las 15:52 Europe/Madrid, Henri Yandell escribió: http://jakarta.apache.org/site/whoweare.html lists the PMC members up until the previous addition of 20 or so. That list has to go to the board etc and I plan to add them to the list as soon as I see them appear on the board's list [in the committers/ cvs module]. I have just discovered I'm listed as PMC member in the web page. When was I appointed? is there no notification to elected people? Regards, Santiago -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/5AbBZAeG2a2/nhoRAsL9AJ41+50TCiBen+5weXJpDwW5H71A8wCfYc5R rPzeRQpFq9dNypbNXXDYIy8= =/byG -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
El sábado, 20 dici, 2003, a las 14:00 Europe/Madrid, Geir Magnusson Jr. escribió: On Dec 19, 2003, at 2:27 PM, Ted Husted wrote: (...) A very subtle concept is that the ASF doesn't actually own the codebase. The codebase belongs to its community, and under the Apache License, that community can always vote with its feet. Since it is the community that gives the software its value (by using and maintaining it), there is an Apache belief that the community is the true owner of the codebase. The ASF just owns the brand and yesterday's copyright. I believe that this isn't right - the ASF does own the codebase via the copyright, and the codebase is licensed at no cost to any entity that is willing to agree to the terms of the license. That entity, community or otherwise, cannot remove that license or change it unilaterally. I think the point Ted makes, summarized as: The ASF just owns the brand and yesterday's copyright. is, actually, subtle: Because of the Apache License, anybody wishing so can carry the code and keep the development outside of the ASF, with their own rules and licenses. This has only the brand and attribution restriction, as per our license. So, even if nominally, as you say, the code is the ASF property, anybody can re-license under different terms, provided that the ASF license conditions, the brand, essentially, are met. In the hypothetical event that the ASF would close our License (which, BTW, would be against the ASF charter), the commmunity could just stop contributing the same day (hence the yesterday's copyright), and keep the development elsewhere, with just a notice, a copy of the Apache License and a disclaimer (hence the brand). This implies that those having easier ability or will to maintain the product are the effective owners of it. as in a rapidly changing environment, software rot takes care of static code bases. Regards, Santiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Promotion of sub projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El miércoles, 10 dici, 2003, a las 09:37 Europe/Madrid, David Sean Taylor escribió: I agree with David's evaluation of Jetspeed situation. Yesterday I was looking at the committer list of (jakarta-) jetspeed, jetspeed-2 and pluto, and I found: Project committers members jakarta-jetspeed 19 5 (jetspeed 1 and 2 have the same set) jakarta-pluto 22 6 ws-wsrp4j 27 20 (amazing ratio) This is much more than I expected. Of course, a big part of this people is inactive, though it shows that the projects have been alive and evolving for a while. Recently Roy T. Fielding posted that on average projects have only 20% of their committer base active at any given moment. This seems to be true here, also. Also, people missing CLA: - -bash-2.05b$ sh ../scripts/check-project-clas.sh jakarta-jetspeed akempf aurelien ggolden jon jvanzyl paulsp prickett rubys shesmer taylor (same for jetspeed-2 and pluto) - -bash-2.05b$ sh ../scripts/check-project-clas.sh ws-wsrp4j jstrachan rubys taylor I wrote some small oneliners/shell scripts to do the task (project-committers.sh, project-members.sh, asf-members.sh, check-project-clas.sh) The latest committer Jung Yan does not (yet) appear. Regards, Santiago (amazed that I'm actually doing administrative work) 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] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/2Zv0ZAeG2a2/nhoRAmKoAKDT2fPPWB/g1t04rYST7KbeTeCjfQCeI1Ca wvh9BlCugGGZk29OY3kkWI4= =jgSo -END PGP SIGNATURE-
Re: [i18n] Internationalization subproject sponsor?
Robert Simpson escribió: Santiago Gala, As far a document and resource translation, I'm not sure if you are referring to machine translation, or human translation. My focus has been on human translation, mainly because machine translation is still pretty far from perfect. There could be APIs for interfaces to various machine translation tools, such as Systransoft, but I think that should be a later, secondary priority. Even if there was support for machine translation, I would prefer that it could be augmented by human proofreading and revision. So it's probably just as easy to let the language translator use whatever machine translation tool s/he prefers. David Taylor has already anwered WRT code. I was thinking mostly about having a pool of people who can translate and are more or less cross project. For instance, I can translate English to Spanish, and I'm a committer in Jetspeed, but I could also translate, say, parts of the tomcat documents that I'm reading, or some XML stuff I'm interested into. Or even docs for Apache modules. The good part is that it would help the whole community, both WRT translation efforts and WRT crosspollination, as these kind of people will see beyond their small project(s). Also, it oculd bring new kinds of developers (Today I heard in the radio, coming home, that 72% od people in Spain cannot speak *any* foreign language. We are a bad sample but in most of Europe, less than 50% people speaks English.) The problem is that I can't see clearly how to implement such a crosscutting service/project, in ways that would not be difficult to impossible to manage. Specially since we should keep source control on both the original doc and the translations in sync. Any ideas? Regards -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
Nicola Ken Barozzi escribió: Greg Stein wrote, On 04/07/2003 1.24: On Thu, Jul 03, 2003 at 04:22:10PM -0400, Andrew C. Oliver wrote: (...) The division of XML vs Jakarta predates me for certain, but I think the main issues surrounding that are rusty. The problem is Jakarta itself. Centering a PMC around a *language* rather than functionality is the inherent problem. These questions will continue to arise over and over. This can be paraphrased as Centering a PMC around *the new ASCII spec* rather than functionality is the inherent problem. In a lot of senses, XML has permeated the whole playing field. Pure XML projects will either be XML-functionality-toolkit projects or architectural slices of other projects. All classification attempts are doomed to failure ( http://www.crockford.com/wrrrld/wilkins.html ) unless we take them with a grain of salt. At that time it made sense. Java is not only a language, and is so separated from other environments, that it was IMHO the only way of aggregating enough resources to launch something out of it. But things that go well one time (and Jakarta has been a major success), don't necessarily go well the second. Things are not static. In the late 80's/early 90's I worked for a company where a Technology department for LA Networking existed. As LAN technology was more and more widespread and standard, the need for such a dept. disappeared. Today it would not make sense, but companies do have WiFi Technology Depts. which will vanish in a couple of years... When Grisha Trubetskoy wanted to contribute mod_python to the ASF, a good number of people called for creating a 'python' TLP. I'd do it when they'll donate Python itself ;-) Does wishful thinking work? ... To that extent, I'd say it is an XML project. There is another more simple rule. Who has shown that they want the project most? Apache.XML. Then let them have it. This is a good heuristic, I think. However, I think it is mostly up to the XMLBeans community to ask for one or the other. If that PMC says okay, then everything is fine. (and no... PMCs are not allowed to meet at sundown to duel for an arriving project :-) No? ;-P Don't forget that sundown occurs continuously in a slice of the world, and that the probability of an Apache committer seeing a sundown is high at any given moment ( http://cvs.apache.org/~sgala/nightmap.html ) Regards -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
Craig R. McClanahan escribió: Snipping to an issue I have with one particular comment. I snip the whole thing, just to add. Read Craig's mail if you haven't :-) The Apache voting rules, where one -1 vetoes (and at the same time it is required to give substantial arguments about the veto) is, I think, precisely designed to enhance dialog and consensus over pure majority. I think this fact does a lot towards avoiding this kind of control traps and hidden agendas. This and the public discussions on the rationale of decisions. Regards -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The vendors page
Andrew C. Oliver escribió: The original intent of the vendors.xml page was: 1. Because I got sick of hearing people say Jakarta projects are not supported and wanted a page to send people to during presentations. 2. So a certain unnamed committer would not feel the need to spam the lists (because I though if he got away with it, others would start doing it and then I'd get lists full of consultancy spam). Now that Open Source is no longer a commercial cussword and I doubt even an economic turnaround will kill the momentum, I think that the policy for that page ought to be just have one of the committers you employ on the Jakarta projects you support make the change. Thus tightening it from people who support Jakarta projects to people who support Jakarta projects. Thoughts/Objections? +1 It is a simple test of reasonable support, not just lurking. I would not say you employ, but just convince one jakarta commiter to make the change. This would ensure at least some level of communication (like sending it to the project -dev list and discussing it there, etc.) It the spirit of Open Source, if a Company is not able to have a fluid relation with at least one committer of one of the projects they support, I can't see how they can claim support of the projects. Note I'm saying less than Andy. Not employing a committer, but channelling the change through one committer. The company maybe contributed some patches or docs, or just good answers in the -user list, but the project committers should be aware of them existing and supporting the project. -Andy Regards -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal: Jakarta should protect community email addresses
Andrew C. Oliver escribió: I'd be all of this if it would make a difference, unfortunately you're barking up the wrong tree. I'm getting that virus/attachment to every email address I have just about. I think it looks locally (user address book, etc). Thus I'm against this on the principal that its a big waste of time. Spammers will get publicly posted email addresses elsewhere and viruses get them from outlook. (and I mean OUTLOOK. You want to stop mail viruses??? STOP USING M$ OUTLOOK AND EXCHANGE. Write your sysadmin, explain to him that he's an idiot for installing that security hole with email features). +1 I blogged that governments and corporations should sue Microsoft about Outlook security flaws. (Spanish: http://memojo.com/memojowiki/Wiki.jsp?page=SantiagoGalaBlog_blogentry_110603_2 ) Governments and Corporations are loosing tons of money because of this. Today I received 5 viruses this way. A short questin: what would happen if your brand new Ford or Toyota would unlock the doors automatically every time a person passing by clapped hands? Microsoft has been selling a product with this feature for years. I don't get it. Except Microsoft has too much power for a government or a company suing on this. -Andy On 6/27/03 10:32 AM, Andrus Adamchik [EMAIL PROTECTED] wrote: -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump and Unicode
Sam Ruby escribió: Santiago Gala wrote: Conor MacNeill escribió: (...) Just to be clear this is not a Gump issue - I think the problem would appear whenever you try to compile on any platform with a different default encoding. Yes. For this reason, I'm encouraging people to start using utf-8 as default encoding in any server platform. This brings a whole new set of issues :-( but at least you can represent all Unicode characters, and ASCII maps transparently. This is specially important fot multilingual portals, for instance. Pardon my ignorance, but can you tell me how to do this? The primary Gump machine is Redhat linux, many of the others are Solaris. Under redhat, /etc/sysconfig/i18n contains definitions for the locale variables, sourced during system initialization. AFAIK, LC_CTYPE is the one involving numeric/alpha mappings, lower to upper mappings, and byte/character conversion, and LC_COLLATE the one involving character sort order. export LC_ALL=en_US.UTF-8 in /etc/.profile (or .bash_profile... depending on shell) of the user under which the processes run should map all the variables to the used locale. locale -a should give a list of the available locales, which come in packages called locales-xx-version, or locales-version for the base one. If there are processes spawned by, say, an ant task, they will take whatever is in the environment at the moment. I'm not Solaris Expert, so I can't comment on this. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump and Unicode
Tim O'Brien escribió: commons-codec fails to compile in Gump because it contains an Ntilde among other characters used in languages other than English. Any ideas? I seem to recall that java source code is supposed to be written in unicode, but I could be wrong. The '\u' convention is ASCII and should be safe, instead of using 8/16 bit characters in code. If the original files are right, but gump's version is not, something bad is happening in the cvs commit/checkout encoding/decoding or gump processing pipes. Difficult to track, and potentially nasty problems ensured. Regards, and good luck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump and Unicode
Santiago Gala escribió: Tim O'Brien escribió: commons-codec fails to compile in Gump because it contains an Ntilde among other characters used in languages other than English. Any ideas? I seem to recall that java source code is supposed to be written in unicode, but I could be wrong. The '\u' convention is ASCII and should be safe, instead of using 8/16 bit characters in code. http://mail.python.org/pipermail/string-sig/1999-January/001117.html gives some light. -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump and Unicode
Conor MacNeill escribió: (...) Just to be clear this is not a Gump issue - I think the problem would appear whenever you try to compile on any platform with a different default encoding. Yes. For this reason, I'm encouraging people to start using utf-8 as default encoding in any server platform. This brings a whole new set of issues :-( but at least you can represent all Unicode characters, and ASCII maps transparently. This is specially important fot multilingual portals, for instance. Conor -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sun copies Jakarta?
Steven Noels escribió: On 10/06/2003 9:48 Nicola Ken Barozzi wrote: or MS (http://www.gotdotnet.com/community/workspaces/directory.aspx)? Or Sourceforge? Savannah? Diversity is what keeps Darwin's sledgehammer away, IMHO. Darwin will take care of most such initiatives. But it looks like new marketing trends are being set up. Now, how does this affect our ecosystem? /Steven -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Footprints to the mail (Re: [PATCH] index.xml/elsewhere.xml/binidex.xml/source.xml/project.xml)
Danny Angus escribió: By the time you see: Mailing the commit message... cvs has done the important thing, any problems after that are 99% likely to be with the mail system. d. When I did a sorted and cleaned imports patch in Jetspeed a while away, I committed it as a whole (just cosmetic changes, no need for granularity), and the mail was returned because it exceeded some list limit. This ca happen if the diff are more than 100K, I seem to recall. -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: website (was RE: [PATCH] promoted sub-projects)
Scott Eade wrote: On 21/03/2003 2:31 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: - maybe DB as well. OJB should probably be replaced in the Related list by DB which includes Torque (formerly part of Turbine) in addition to OJB. Which reminds me that some pieces are particularly hard to find. For instance torque, which used to be hidden in turbine, or velocity. I mean, I have had to use Google to find pages in Apache. This is improving now, as the divisions are more rational, but a page listing alphabetically all projects/modules (as in things that projects can depend on) could be interesting, although difficult to maintain. (I've used gump listing as an index into java-apache projects quite a few times). I wonder if gump could generate such a listing daily/weekly/monthly, to be imported by the site module. Regards, Santiago Cheers, Scott -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Link to Avalon on WebSite
Carsten Ziegeler wrote: Hi, the link to Avalon on the main jakarta website still points to http://jakarta.apache.org/avalon/index.html. Even if I'm not Jon, I have been exposed to him long enough to say: send a patch! (I have karma in jakarta-site-2, I can commit it). :-) Carsten Carsten Ziegeler Open Source Group, SN AG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: broken links
Pier Fumagalli wrote: Not acked ACK + commit (I think the site takes care periodically of cvs update itself, elsewhere it will be seen when somebody cvs updates it). -- Forwarded Message From: Erik Price [EMAIL PROTECTED] Date: Thu, 20 Mar 2003 11:28:48 -0500 To: [EMAIL PROTECTED] Subject: broken links There are two sort-of broken links on this page: http://jakarta.apache.org/site/library.html They are the references to The Cathedral and the Bazaar and Homesteading the Noosphere. Eric Raymond's site is no longer served from www.tuxedo.org/~esr , I have heard that this may be temporary but the content is currently available at http://catb.org/~esr/ . Erik -- End of Forwarded Message - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] promoted sub-projects
robert burrell donkin wrote: maybe we could change 'SubProjects' (which is more to do with internal organization at apache) to something more positive like 'Jakarta Is'. that would make it easier for projects who want to retain an association with jakarta to keep their listing. +1 Otherwise, we are exposing implementation details :-) Most people don't care too much about internal structure @apache, and it is confusing to find broken links. As time passes, people will get used to james.apache.org or ant.apache.org. But, as Craig said, I still go to jakarta looking for james, ant, etc. - robert -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Pier Fumagalli wrote: On 18/3/03 11:33 Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sunday, March 16, 2003, at 10:02 PM, Pier Fumagalli wrote: On 17/3/03 1:24 Hans Bergsten [EMAIL PROTECTED] wrote: I agree that there's been problem with the Servlet EG this time around, but what I'm saying is that there are avenues that we _could_ have used to voice our concerns, but we didn't for some reason. There are a number of mailing lists and online forums where developers interested in the fate of the spec hangs out. We could have started discussions there, and urged people to send feedback to Sun. This is why I feel that my work as the official representative to that EG has been a failure :-( _MY_ failure... Well - it's always easy to look back and see what you could have done differently. Is it too late? Yes... Certain new features are in... Not much we can do now... This is a long term run. And *you* should know that a Release always has some bugs left. ;-) Something we can learn for next time? Pier -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: so many jars
Danny Angus wrote: (...) The solution M$ have delivered appears to simply be a global registry (the Global Assembly Cache), but it is well thought out in respect to M$ probelm and is capable of maintaining multiple versions of the same Assemblies (think jars) and using the correct one, either the newest or a specified version. I haven't investigated it too deeply but I have a feeling that where two bits of the same application depend on different versions of the same assembly this is taken care of properly too. From what I can see it relies heavily on code signing to deliver secure name spaces and version identification, and prevent unintentional namespace conflicts. Thus anyone can download and install multiple versions (or your application installer can do it) where necessary, and you only need to install each required Assembly-version once per machine. I think per machine things belong to the configuration management and system administration concerns, and should be handled at this level. IMO, the approach of jpackage.org, making java rpms for linux and setting a repository of libraries(jars) under /usr/share/java, with a judicious use of symbolic links (much in the same way that .so files are managed under linux) offers a clean way to avoid duplication , while leaving decision power on what gets installed where, how and when to the sysadmin. Again IMO, any automated solution should not intrude into the ability of the sysadmin to control what is in her machine. Microsoft has always handled this problem in the wrong way ,assuming that an automated installer knows better than the system administrator and doing things without logging or asking first. Please, (generic broadcasted plea, not pointing to anyone in particular) make sure that any java solution to this problem respects the needs of systema administrators WRT configuration management and global auditing of changes in their (suposedly) managed systems. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Previously: Andrew C. Oliver wrote: Lets talk about what a great thing the portlet specification committee has done for the Jetspeed project. Geir Magnusson Jr. wrote: Yes, lets do that. (That's 1 out of 200 or so, so while there may be a problem with that specific JSR, we might have to look at a few more before generalizing.) 1 out of 200 is misleading. I think you mean that Andrew had just 1 example out of 200 JSR. A more adequate comparison would be the other way round: . How many Apache projects are turned into JSR from the outside, not by the developers? I mean from people *not* in the team. (jserv/tomcat, the logging stuff, jetspeed) I bet that's it, please correct me. From the previous Pier email, it looks that we are close to 1.5 out of 3 than to 1 out of 200 (Just twisting as I see fit, following the previous example ;-) BTW, it looks like an excelent metrics for innovation in Open Source that the industry wants to standardize on OS projects. And later Geir Magnusson Jr. wrote: (...) One way we can do this is for ourselves to do be spec leads for JSR's. Then we can set the rules for the group, and the license. Jetspeed has been around for a while - it was only recently that IBM (and ?) proposed the JSR. We could have done it long before that. It depends on your semantics for recently. A historical account: People from IBM Germany approached the team (Raphael Luta, myself) in autumn 2000 (In the ApacheCON Europe) with a proposal. They were working in what became Websphere Portal Server and it looks like they would base it (partially, I'm sure) on the Jetspeed work. Kevin Burton, the original leader, misteriously disappeared from the project by then. This is how I became the speaker in this ApacheCON. A proposal was sent by the team to the list, and got heavily discussed (IRC, mail list, CVS repository). This (http://www.mail-archive.com/[EMAIL PROTECTED]/msg05121.html) excellent summary by Raphael Luta, who took most of the formalization effort gives an idea of the situation by Feb 2001. This (http://www.mail-archive.com/[EMAIL PROTECTED]/msg05089.html) post by Ingo Schuster (IBM voice in the list) gives idea to the level of discussion. After this, two things happened: * For the developers the priority was to stabilize the code base and have a release, *before* jumping to a heavy refactoring. * The IBM team (Ingo was the most visible part) disappeared completely from the public list. I have not been able to find anything in Google from those times, it seems they don't index mbox.gz archives (Please, Ovidiu, make them do it), so historicians will have to resort to http://jakarta.apache.org/mail/jetspeed-dev/ the .gz monthly archives :-) Everybody having more than enough work to do, and nobody really pushing the proposal (DOocrazy) it languished. In Dec 2001, a proposal was presented JSR 162 (Portlet API, Stefan Hepper, IBM http://www.jcp.org/en/jsr/detail?id=162). 6 days later JSR 167 (Java(TM) Portlet Specification, Alejandro Abdelnur, Sun Microsystems s/162/167/ in URL above) was presented. 20 Jan 2002 both were withdrawn, and 168 (with both leads s/167/168/ if you folloed the previous regexp). So, the industry jumped in. From then on, only David, Alejandro, Stefan, people in BEA, HP, etc. can tell what is going on. The proposal is not even in the Community Review stage one year later, as far as http://www.jcp.org/en/jsr/detail?id=168 says. In fact, it does not appear in the List JCP by stage page, which means it is still in fuzzyland. My recent community weather reports (http://blogs.cocoondev.org/stevenn/archives/000760.html) suggest that it is about to go into Community Review, or at least that there is movement inside. I could ellaborate on my prognosis techniques on demand. [EMAIL PROTECTED] busts of traffic seem good for predicting political stress. :-) No conclusions expected, Santiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JCP NDA (was: too many similar projects?)
Rich Persaud wrote: Pier wrote: | Most of the times, in my experience, it all comes down to how receptive | the spec lead is in regards to new ideas coming from outside, and how much | weight he has in his company (the JSR sponsoring company)... | | But my experience is too little to say what happens more often. Are there any metrics on the performance of spec leads, besides: http://jcp.org/aboutJava/communityprocess/withdrawn.html http://jcp.org/aboutJava/communityprocess/rejected.html Apache has tools that provide quantitative feedback on the development process. Can any of these be adapted to provide quantitative feedback on the post-public spec development process, using historical (public) data? Not that I'm aware of. I pointed (in a very positive tone post) to some possible improvements (non NDA experts having staged access, more public drafts, having shorter cycles) that could improve the process. http://www.mail-archive.com/[EMAIL PROTECTED]/msg06951.html I was thinking specifically in JSR168, a more than one year blackout. Spec leads need to be JCP members and there's a $5K threshold for commercial companies. That's a large gap between Tier $0 (Apache and fully open) and Tier $5K (JCP and open/closed per above cited agreements). You can go as individual (Not Apache, not Company) and this is 0 Is there a subset of Apache members who represent smaller commercial companies, who won't/can't incur the JCP overhead, but who wish to give their customers the benefits of inter-vendor portability and test compliance? This third question is really two: * The spec is public once public-drafted * compliance comes *after* there is a standard to test against. I'm not sure on how difficult/expensive it would be for a non-Apache product. Rich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Andrew C. Oliver wrote: What if later we want to do a .NET portlet or a (whatever comes along that is against Sun's interest) portlet spec? I think Sun's NDA is not that bad (but I don't want to re-read it to check). Once the JSR gets public, there is no provision against free use of what they call Residual knowledge polluting your brain. I can't remember what happens if you depart in the middle of the process. Or about extra time (6 months? 1 year? I really don't remember). You just grant a non-exclusive, transferrable license, to your knowledge, and you agree ND in aspects related to the JSR. For me, the crucial issue WRT the JCP process is enforcing release early, release often at regular steps, with all the caveats that might apply. Also, having a intermediate figure of free experts, which could answer in public questions, clarify or ask the community about controversial issues, without NDA. People in Apache would excel in this hub role. I think this is in the best interest of Apache, Sun, and possibly other participants in the community process. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Danny Angus wrote: Why create something in official Java APIs/Products when there is allready a good OSS alternative. To standardise it. Why is OSS any different? Exactly! So why bother standardizing it via Sun. If there is a ubiquitous Apache standard already, then there is NO need for a Sun standard. Personally I think the danger is, as Andy pointed out, that Sun including a lot of functionality in the core distribution of Java JSE or in JEE limits the ability of third parties to develop solutions, in a way very similar to M$'s inclusion of extended functionality in the basic Windows OS installation. *and* bloats Java. I have a JAXP and TRAX implementation in Sun's JRE, that I need to override, because it does not work with most projects, for instance. I have the whole Swing, even if I don't use it in my tomcat VMs or with ant/maven... Those could be pluggable (as JAXP or TRAX, or JAAS, or even parts of JDBC, used to be). Standards should not be taken to mean product most widely used or the product officially supported they are something else. IMO standards are, and should be, benchmarks against which people can compare their work and say either it does or it does not support standard x,y or z. Standards compliance can be a goal of any software project. Standards compliance as a goal of un-related projects results in the kind of interoperability that is fundamental to the character of the internet. Open Source has standards as a cornerstone because it allows loosely coordinated groups to produce interoperable systems simply by supporting common, published, contracts. A wholehearted +1. Sun's use of JSR's to add core functionality, as far as I can see, goes way beyond the standardization of contracts to include implementations, and these implementations are often bundled with Java in one form or another. The result is that if you are interested in the contract you don't need to go elsewhere to find software implementing it, its right there already, and its free, so why bother? As far as I can see Apache's position in the JSR review defends the right of third parties to be allowed to implement contracts approved by JSR and adopted by Sun on an equal footing with the JSR's participants and cash rich commercial organisations. While Apache is taking advantage of this with Tomcat and other projects, I'm not sure it is a good thing. and then Andrew C. Oliver wrote: Therefore, supporting JSRs where there are already good dominant Apache projects is against Apache's interest. You either get sidestepped like the JSP vs Velocity thing or you move the decision making process into Sun which is apt to happen with Jetspeed. I don't think the Original proposal for the Portlet API is bad (I don't know yet the outcome of the process). It was a light weight API, modelled after the Servlet API, and offered possibilities for use. But the whole discussion has been held behind doors. And the process has frozen possible evolutions of the project in the wait (this is possibly a tactical mistake on our part, coupled with one of the main developers being forced to a very difficult position under NDA). Also, like Danny wrote, the fact that the JSR comes with a RI coming from the outside and for free, brings a danger to kill possible alternative designs. All of this kills cyberdiversity. I imagine that it has helped a lot to promote java as a programming platform and make it feature complete, but the times are coming where it is no longer a good policy. Just Random Thoughts Santiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RANT: Licensing, Business models and success metrics (was Re: answerto Howard or State of the POI )
Andrew C. Oliver wrote: This is going to be another one of my long answers to a short question... Good! (I crosspost to community. I think it really belongs there ;-) Some context: Howard M. Lewis Ship asked about Tapestry/POI usage: People keep asking me how many people are using Tapestry ... and I honestly have no idea. Insufficient feedback. Do you have a way of determining the user base of POI? Any guidelines based on downloads? Andy answers: I don't really attempt to measure this. It would be trivial to measure the number of downloads from the access logs; however, I prefer to mesure it subjectively. Note that its documented on the Jakarta site that Opensource is not about units shipped. I'd look up the page but I'm sure that if I don't someone will do it for me so why bother. Specifically in server side applications. For instance, as Andy hints in my next quote, a single download from a intranet server in a big corporation can lead to tens of thousands of (unsuspecting) users. (...big snip, not that I don't like it, but please read it in the archives) First, POI attacts mail from some of the largest banks in the word, financial institutions, governments, millitary institutions, nuclear power plants, etc. There is even a large Apache backer flirting with the idea of using it (while its irrelevant to me whether they do or not, it is relevant that they are considering it). Next, I measure the success of it by two other things: Microsoft's flirting with open file formats (I'm sure it will be open in that Microsoft sort of way) and the final crux will be the day this http://www.tidestone.com/index.jsp goes out of business. The first clue to eventual success is that Tidestone has re-emerged as a seperate business entity instead of just a redirect to a page on Actuate's site. The second is that they have lowered the price from 15k per processor to 5,000k per server (I'm sure there is a big astericks) http://www.tidestone.com/pricing/index.jsp. This is after an extensive advertising campaign including full page adds in Dr. Dobbs. This is despite some functionality that we do not yet have. I don't agree that it is a good metrics, since it's a crisis situation and a lot of other factors could be involved into pricing (product life cycle, etc.). Also, we are not trying to make anybody unhappy, that would be (at most) a side effect of our approach being successful. But the post goes on: My final measure is how much money I'm making and how many other POI developers I'm able to cut in on it. Thus far (this year) I'm able to derive 35% of my income from opensource efforts (a percentage which is up about 800% from last year). I suppose all of those are directly or indirectly related to POI. I'll undoubtably be flamed for this unique viewpoint, but its a measure which I find important. I've managed to pass on some of this work to two other POI committers thus far. (no one bother writing me offering to do this work, I only pass this work on to contributers to the project) So to me how many people are using POI and not contributing to the project in any way is totally irrelevant. I measure it in actual benefit to myself and the other contributers. To me any other mesure is trivial. This is the point I think merits further exposure/discussion. I'm not going to flame Andy on this, since I fully agree with it. If we cannot extract actual benefits from our involvement in Apache projects, the projects will not work/scale well. Each and everyone involved in Apache projects should benefit in terms of: * better career opportunities * being better known in the industry * having better tools in our daily work toolset * higher productivity in integration * knowing where technology is moving * __fill more here__ The Apache licensing model is oriented towards consultancy/system integration rather than product sales. This is in opposition to other licensing schemes like GNU: * If you hold the copyright of a GNU licensed stuff, you can re-license it as closed source (a lot of GNU-licensed projects are doing this, see Aladdin or Transvirtual with ghostscript and kaffe) * If you hold the copyright of an Apache, BSD or Artistic licensed stuff, it is far more difficult to do this, because everybody is free to do the same. This introduces an asymmetry I don't like WRT GNU licensed projects: the person transferring copyright looses rights WRT the person holding it. I don't critizise this approach with the FSF proper, but I don't like, for instance, kaffe benefiting from my patch and I being unable to benefit in the same way. Thus, I find that people doing system integration and consultancy, both in big and small companies will naturally prefer Apache-like licenses: * you don't need to care about your customer wanting closed modifications, as they can do them -- less overhead * you don't need to care if your customer wants to redistribute the
Re: Current roster of the Jakarta PMC
Sam Ruby wrote: (...) OUCH! I stand corrected. Thanks Pete. When updating the official list (in the committers repository, directory board/committee-info.txt), it occurred to me that a three column format might be easier to read, so I wrote a little script. Unfortunately, a roundoff error made *two* people not appear on the list as 35 is not evenly divisible by three). We can blame Pier Paolo Fumagalli for this one. 36 would not have raised such a politically incorrect bug. ;-) Regards, Santiago (walking on thin ice, WRT jokes) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Project
Federico wrote: Fyi, http://Noodle.tigris.org/ would serve as a great framework to build such a proxy. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ Maybe you don't understand me. We have already finished the proxy's heart I cannot compute finished + software together. software is like a live creature, more so a project. You are really starting, now that you are planning to have true users and go out to the real world ;-) Regards, Santiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Project
Federico wrote: I cannot compute finished + software together. software is like a live creature, more so a project. You are really starting, now that you are planning to have true users and go out to the real world ;-) Regards, Santiago Sorry for my english but probably in my language I can tell you better about this project, that is already in the world not real but academic because this started from a project for an exam. I was thinking that just programming is not at all the difficult part of a software project. I have written thousands of lines of code that where never used, because the project died by lack of funding and I was not able to carry the code to other projects, because the company wanted for me to pay the whole cost of something that was essentially useles, as it was much cheaper to rewrite it. This, by the way, was the revelation, that convinced me to the Open Source Ways, a bit in the same way of the printer driver story that I've heard RMS tell. A project requires: * A Vision * A need fulfilled (the itch) * Users that will like the way how it works (for one reason or the other, be it simplicity of design, economy of resources, stability, cost, or even features ;-) + Management to keep it evolving and avoid it falling into pieces in the contrast between the needs of the users and the needs of the design * Some brand that makes it easy for people to remember it exists * Documentation * A evolving developer team to fix bugs, document and re-structure code on a continuous base * ... and a bit of code You seem to have the itch ( a caching proxy in java), and a name Puff (I like it a lot). You seem to be a group. This is what you have. Do you have the rest of the things? Is it competitive in design, ideas, simpliticy, etc? You should look for similar projects and study their status and design. For instance, a proxy need a http client implementation (as well as an http server implementation). You could look at how tomcat implements its server-to-client connections, and look at http://jakarta.apache.org/commons/httpclient/index.html for an http client. When you have a clear idea of where your project stands (better, lacking, a good part but..., cleaner design, etc.) you can go back to these communities, or here, and argue for your position. If the people in httpclient or in other projects (tomcat looks too big as a starting point, but...) gets convinced that your code is good, then you have a starting point. If they don't, and you still think you have something good, keep on trying. Now, I got serious. Sorry for the previous joke Regards, Santiago P.S.) If you have problems with the english to express you, but you believe that the project is worth it, you can try sending mail to some Italian commiters or members (look at the people.html page in Apache) in Italian, or even to me (I'm Spanish, but I think I'll understand it). Federico - 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: PMC Nomination
Pier Fumagalli wrote: On 19/2/03 23:10 Leo Simons [EMAIL PROTECTED] wrote: I don't think anyone expects that upon becoming a PMC member one would immediately need to gain and maintain intimate knowledge of all corners of the jakarta codebases. It is just about humanly impossible. So it is probably a good move to ensure the PMC is of a size where there are one or more people who do have that intimate knowledge for each particular corner. If I talk to someone on the HTTPd PMC, he _knows_all_. I don't see why it should be different for Jakarta. And if the problem is size, well, break up the bloody thing, it was never designed to be this huge. If I understand correctly the political trends here, promoting people to the Jakarta PMC is trying to get people involved, and knowing each other and the whole of Jakarta, so that the process of promotion of more and more projects to top-level does not balkanize the communities any more. Also, to promote wider awareness of the big community as a whole. It does not look like bad for me. So, the move is in the right direction, something like making jakarta community grow to later split (re-organize?) it with less trauma (sp?) My 2 pennies. When will you, half europeans ;-) enter the euro stuff so that you can pay me a beer in Madrid with less transaction cost? ;-) Two euro cents in exchange. Santiago 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: MS vs Open Source link
Henri Yandell wrote: (...) As for the article itself, I think it's more the open atmosphere to bug-reporting that means opensource is less buggy, and the frequent releases, than the code itself being open. So there's no reason why closed source shouldn't be the same, except that they're unable to replicate the culture that popular open source projects have. Culture is already a big enough answer. Being impatient as I am, I find increasingly that culture in closed source groups, no matter how big, is much less cosmopolitan than, say, Apache or Debian people. One of the reasons is because they cannot discuss freely (with lines of code) the technical problems except in a reduced population, and they tend to have narrow thinking. Also, I think a key answer is about shame and pride. I have already felt ashamed committing very hacky code in public repositories due to the need of having it working, quick fixing, etc. In a closed source culture thee is no compelling reason to revisit this code, and the probability of somebody else fixing or refactoring it is quite small. ;-) You have both a positive reason (being proud of your own code) and a negative pressure (being ashamed by other people looking at it) to ensure highr quality of initial Open Source contributions. On top of this, you have a feed back process to fix problems. So, I won't be marvelled if the results are (asymptotically) perfect. Regards, Santiago - 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 ;-)]
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: nice
Jon Scott Stevens wrote: (...) Real life business shouldn't be bullshit. I'm not going to buy into that. It is people like you who opt into the flawed choices instead of speaking up that allow the flawed choices to continue on longer than they should. IMO, the closeness of the JCP process brings most of the bullshitness of it. Even having open (to read, not to post) lists for the different groups would change a lot of the JCP procedures and results, by making obvious dark political moves attackable from the outside. Regards, Santiago -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nice
Geir Magnusson Jr. wrote: (...) What else would you like to know? What are your specific problems? is there a specific technology/spec that you are interested in participating in? have you ever interacted with the expert group of a JSR via their interest list or during a public, community review? I started my participation by just sending comments to the servlet EG, and I found them extremely responsive, far more responsive that I would have expected for a random comment from the ether. Of course, this differs from EG to EG, just like different communities differ on OSS projects. How did you get a base for your comments? I imagine you were commenting on, let's say, Servlet2.2 when they were working on Servlet2.3, or something similar, maybe a public draft. But when a group gets formed in Jan-2002 (http://www.jcp.org/en/jsr/detail?id=168), and there is no single line of output from it till (http://nagoya.apache.org/wiki/apachewiki.cgi?PlutoProposal), Jan 2003, I don't see a way to send a meaningful comment.Comment on what? When a Draft is published, I expect a response like It's too late to make major changes now, we'll consider for release 2 to any serious comment. You can see what I meant with my previous post about closeness of the process. (...) geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Open ThunderGraph in Jakarta ?
Martin van den Bemt wrote: Love to see a gui framework / tools thingy on apache.. Working on that stuff a lot lately (of course has a Apache Style License) Jesktop (http://jesktop.sourceforge.net/) is written by Apache commiters, Avalon based and could be a good foundation for a GUI project ;-) Regards, Santiago Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator home page (was Tapestry)
Nicola Ken Barozzi wrote: [EMAIL PROTECTED] wrote: This is one of my least favourite features of this forrest skin. Look at this version, which is a modified forrest skin, if it's better: http://www.krysalis.org/centipede/ I took all the suggestions from users like this one and made that skin from the Forrest one. We will evaluate what users prefer from this one for the next CSS-only Forrest skin version coming out soon. It would be great if the abbreviated items had an alt tag with the full name, to be shown as tooltip. Take it as Just one more user suggestion ;-) Regards, Santiago (...) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: (PHP interperated via Java) [Fwd: RE: [JBoss-dev] PHP]
Henri Gomez wrote: Andrew C. Oliver wrote: I thought this might be interesting to some folks... They're porting PHP to Java... -Andy Original Message Subject: RE: [JBoss-dev] PHP Date: Thu, 9 Jan 2003 19:13:23 -0500 From: marc fleury [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Yeah that was my first impulse, to have a PHP interpreter in JBoss so that we could leverage all the PHP thingies out there. clearly the problem with PHP is that the guys who do the front end modules and app DONT KNOW THE FIRST THING ABOUT COMPONENTS and the benefits it brings in caching (see whole argument on EJB in BLUE). Putting EJB behind the whole mess would be great. PHP can talk java but it is out of process so that you go back to serialization and LOSE the benefit of caching. Period. So clearly having the PHP code interpreted in java would be great as you access the db data in cache. The problem is that the libraries used need to be ported too and that becomes a pain. I am really serious with the porting as Julien will be payed for this. That's excellent for site which have allready tons of PHP code and need to switch slowly from PHP to JSP/Servlets. Also for sites having PHP on some boxes but didn't have PHP binaries on the target machine (ie iSeries) Very late, but... I think the right approach would be to change the PHP templates to ensure that they produce proper XML (be it XHTML or whatever language suits you) and the use it in a Cocoon Reader, or XSLT-it, or whatever, from as far away from the original box as you can stay. If the original apps are cleanly written (i.e. with themes, etc.) it should be simple Instead of importing PHP nightmares into java, you would have to deal with (more or less) clean data interfaces. Don't ever allow anybody to lead you to think that fixing legacy apps is your problem ;-) This meta-knowledge has worked a lot for me. It you absolutely must, just multiply your wages times 10 and pray ;-) Regards, Santiago -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Forum Software.
Jon Scott Stevens wrote: on 2003/1/22 12:28 PM, Santiago Gala [EMAIL PROTECTED] wrote: 1. Install spamassassin and server-side filtering (with procmail, for instance). ;-) (It saves me between 5 and 10 spam messages a day, quite an effort just to download and delete). You should be so lucky to only get 5-10 a day. I get around 400. Yes, but you are a ASF member, and your address is much bettern known than mine: http://www.google.com/search?q=jon%40latchkey.comie=UTF-8oe=UTF-8hl=esbtnG=B%C3%BAsqueda+en+Googlelr= returns approx 2930 hits, while http://www.google.com/search?hl=esie=UTF-8oe=UTF-8q=sgala%40hisitech.combtnG=B%C3%BAsqueda+en+Googlelr= return approx 258 hits. This says it all ;-) (I don't even count apache.org addresses, etc.) -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
Steven Noels wrote: Conor MacNeill wrote: Steven, I think these are exactly the sort of questions incubator is designed to answer. Tapestry was about seeing how an existing project can come into Apache. Perhaps Pluto is an opportunity to understand how a new project can be created and encouraged at Apache. They are both interesting challenges for the incubator. I volunteered for being on the Pluto project team, if only for discussion and documentation. That way, I hope to be able to take care about my reservations, by making sure I'm right in the middle of it. It's good to see Carsten and Andy, too. That makes 3 of us who will make sure Pluto integrates with Cocoon. /Steven I will try to join both Pluto and Charon, also, time and health permitting. Even if I am not very active lately, I'm still tracking Cocoon and Jetspeed as much as I can. I'm better at bug fixing, critisizing and generic hacking than a true programmer, but I think debuggers are always needed. I would like to see what comes out of this, after a couple of years involved into this stuff ;-) Regards, Santiago -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Forum Software.
Robert Simmons wrote: Well, once again I would like to bring up the concept of forum software for Jakarta. The reason I am bringing it up again is that mailing lists are intrusive and spammy. Daily I get flooded with a ton of email that I have absolutely no interest in reading. However if I unsubscribe to the lists than when there is something that I would like to know about or answer, I will miss it. In addition, if I unsubscribe I'm not able to post my own issues. With a mailing list, the communication mechanism is just too intrusive. On a forum I can pick and choose what I want to read and reply to. As for them being used, its a simple matter of retiring mailing lists for forum software. When we consider that at least 90% of Jakarta users are not Jakarta developers but will often have a question or an important insight, than the folly of communicating only in mailing lists becomes clear. -- Robert Simmons One suggestion and one idea: 1. Install spamassassin and server-side filtering (with procmail, for instance). ;-) (It saves me between 5 and 10 spam messages a day, quite an effort just to download and delete). 2. During the ApacheCon I had an interesting discussion with Cocoon and Subversion people (I'm too bad to remember names, but i *do* remember the faces, OK? ) about a dream: A MTA that would show threads folded into a kind of diffs, where each mail in a thread would be coloured in a different way, could be ignored, collapsed etc. Quoted parts should be collapsed together. I don't know if you see it, but I like it! This would save a lot of effort I need to extract the relevant portions of, for instance, mee too posts, side jokes, etc in a long thread. It would be similar to a LXR listing (http://lxr.linux.no/) or cvs view, There is, in fact, whre I got the idea. BTW, a LXR would also be handy to have for our repositories, to enable view of temporal evolution of code, etc. Regards, Santiago -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
Alex McLintock wrote: At 17:41 21/01/03, you wrote: One more question: why not doing this as a subproject of JetSpeed ? It is an existing jakarta project, the scope matches - why creating a separate jakarta community instead of joining the existing one ? I assume that it would be a tool which could be used by the Cocoon portal system, and a Struts portal system as well as Jetspeed which is essentially a Turbine portal system. People may want to use this component without using Jetspeed. Of course I haven't read the JSR yet. A portlet is an object, similar to a servlet, but which generates only a page fragment. A portlet container would be in charge of providing them with a suitable Request, and combining the portlet response to compose the page that the browser will get. (And many more things...) Thus, it is not that simple. You will need a portlet container (which is what essentially is Jetspeed, a portlet container on top of Turbine). During the discussions about the Portlet API proposal in the Jetspeed list, a couple of years ago, I positioned myself (I was not the only one), in a field that considered that we should have two kind of portlets: - Stream based portlets (the original IBM proposal) which would use the response stream to write their content (a la JSP) - SAX portlets, which would use a SAX pipeline to render the content. I remember Raphael Luta was very concerned that any portlet should be a full XML document, because he also was very interested in XML transformations. See a pointer to part of the discussions, for those wanting some info. http://www.mail-archive.com/jetspeed@list.working-dogs.com/msg05070.html http://www.mail-archive.com/jetspeed@list.working-dogs.com/msg05026.html (joke on the saxlet word, that I still claim to have invented, not the concept, though :-( I was rejected as a member of the JSP team, thus I don't know what they are doing in there. On a side note, by exactly the same reason I can speak freely about it. The discussion But I'm quite sure that the only scalable way to have portlets that can be used from Cocoon (or any other XML based framework) will be those using SAX streams or plain XML (let's say DOM) to reder their content. The reason is that portlets that generate a bytestream will need to be re-parsed by any XML-based portlet container, to transform them or serialize again at the end of the page rendering. So, even if portlets are designed to be reusable from different frameworks (Struts, Turbine, Cocoon, etc.), Cocoon would have a nightmare re-parsing and re-serializing portlets if the SAXPortlet is not in the API. Both Turbine and Struts could, of course, use VelocityPortlets, JSPPortlets, and the like. I'm currently interested in javax.portlet.sax.SAXPortlet ;-) (call them saxlets if you like it). Regards, Santiago Alex Mc -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
Sam Ruby wrote: Steven Noels wrote: I was trying not to post the obvious, but yes: this seems largely premature. Deja vu. Check back next week for the inevitable complaint that Pluto is too mature. No code, a restricted community, too much committers coming from one company, I've seen better proposals being fought over lately. Code is forthcoming. I would like to see either the code, or the specification, or both, before being asked to vote for a project, or even to have to decide Jetspeed related issues WRT those new proposals. Multiple existing Apache committers. Multiple distinct corporate contributors. In support of a standard (I'll leave that term undefined). Strongly related to an existing Jakarta subproject. What concerns me is largely the absence of any public discussion around the API proposal. Mostly because of the XML support level. From the origins of the stuff, I remember that the JCP proponents were not suppporting XML stuff at all. Things could have changed a lot, since the world has changed a whole lot in the last two years ;-) I have talked to the person who submitted this proposal, both via notes and on the phone. I gave explicit guidance as to what questions to have answered in the original proposal, where to send it (general AND incubator, if you notice). To post the text on the web AND include it verbatim in the note. Etc. I also gave warning that there is likely to be extended and lengthy discussion as to where this code should land instead of on the merits of the project itself... Also, possible future integration 'ideas' with some related projects would be comforting (Jetspeed, Tomcat, Struts/Tiles, and the Cocoon portal framework for a starter). I can't resist a Jon'ism here: Thanks for volunteering! - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
Stefan Hepper wrote: Hi, here some answers to questions asked in this thread: - Apache was one of the first memebers in the JSR 168 Expert Group and IBM asked Apache explicitly for their support before submitting this JSR. Currently the Apache resprentative in the Expert Group is David Sean Taylor from the JetSpeed group. - The submitteed JSR states that the RI is planned to do at Apache, so no surprise - There is already code, but as some of you noted at the moment the spec and API is still confidential and therefore nothing is public available. As the proposal states the Expert Group plans to make a spec draft and API draft available around March. As soon as this is done we can check in the code. Do you mean the PortletAPI branch in the Jetspeed code base? Or is there other code around? - Everyone that wants to help is more than welcome to join Regards, Stefan Regards, Santiago -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: PMC members, can u help me??
Eduardo Andrés Alfonso Sierra wrote: Hi again, I wrote this message a few days ago... Hi I'm an undergraduate student of Computer Science and I'm interested in how a group of developers that are geographically separated works. You are exactly that kind of group. I wanna know what specific tools do you use, or what kind of tools do you use to use, to develop the software. Can you help me?? or where can I write to get help with this ?? Thanks!!! I've been reading the how to get involved jakarta page and I red about the Project Management Committee (PMC) and its monthly meetings. The tools that PMC use to accomplish their meetings are which I'm interested in. I want to know what tools do you use to organize yourself, to discuss the project direction or design issues and to take decisions about it. Well then, I'm interested in those kind of tools that can help you get your work organized. At the jakarta page reads These meetings may take place online, via teleconference, or via other means deemed effective by the PMC, I'm interested in those other means. So, I would be very very thankful if any PMC member or anyone who knows how PMC works, could help me. I'm not in the PMC, but I have been involved in a project, and actively tracking other ones (by reading the lists, speaking with people, etc.) If you are looking forthe holy grial, I would say: WRT decission taking the key is the meta-law that says that decissions should be taken that keep the process mostly reversible (I mean, try to take small, incremental, practical decissions). As the aim here is usually not to maximize resources, but to ensure that the process evolves in a general good direction, decisions that prune the search tree are generally much more dangerous than decissions that fork a new branch. This has to be balanced with the amount of resources that can be gathered (selt-appointed) to do any given task, and with the confusion that arises when (as an example) you have three different connector code bases to connect Apache with Tomcat. WRT to coordination (a heavy issue in hierarchical organizations) the meta-law is to work in the open and document everything. Coordination failures do happen every day, but, paraphrasing Linus Torvalds, with a big nuber of eyeballs, knowledge will eventually consolidate. If you have ever seen an ant hill working, you will understand what I speak about. Every ant is possibly confused and doubtfull at times, but the anthill as a whole succeeds. Hope this helps, and does not bring more confusion ;-) Regards, Santiago Thanks in advance, and bye ciao Eduardo Andrés -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Bug handling survey - 80:20 rule
Craig R. McClanahan wrote: On Fri, 4 Oct 2002, Danny Angus wrote: Date: Fri, 4 Oct 2002 17:45:48 +0100 From: Danny Angus [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: RE: Bug handling survey - 80:20 rule So, how come the commercial software can still compete with open source products. You're assuming, of course, that you can't have commercial software that *is* open source :-). Such models do exist -- so I'm assuming you are primarily talking about closed source commercial software. This is a very meaningful distinctions. IMO, the fundamental distinction here is that of Open vs Closed, not beer-free vs Commercial, where Open means Free-freedom (I don't want to go GPL vs BSD here) IMHO its because on the whole OpenSource contributors are not doing it to compete with commercial software, in fact many of us do this to provide an alternative to the daily pressures, restrictive working practices and profit driven project management of commercial IT. Having been (and still am) sitting on both sides of this fence, there is quite a bit of truth to this observation. We're either much less interested in producing a competitor for a commercial product than producing an intelligent, elegant and efficient solution to a particular problem, or we're here to collaborate on a product to use in our own commercial interests, not in competing in the market place. Commenting on Danny's sentence, you need to make a difference between We as in each one of us, and We as in the community. Even when each individual developer is interested in producing an intelligent, elegant and efficient solution to a particular problem, the community can still produce a competitor for a commercial product :-) There are a lot of colective behaviours going on here, enabled by the efficient communication means we are using, which completely make the difference. Knowing how to ride this wave is definitely part of the fun. I don't think you can generalize to *all* open source projects not being interested in competing with commercial packages, but this attitude is certainly common. IMHO, there are at least three major factors that means commercial software isn't going to go away any time soon, no matter what happens in the open source community: * SCHEDULE - we all know the standard (and usually pretty sarcastic) response that we open source developers give to the when's the next version going to be released. But this is a very very important issue for people who are planning projects that depend on that next release being completed. Yes, commercial software vendors sometimes miss their dates too, but at least they generally try to meet a predicatable schedule that can be communicated to customers. In my view, this means that succesful OS Product Manager will have lo learn to predict fairly accurately the response rate of the community for a given situation, and deliver the right expectations to customers. * CUSTOMER FOCUS - like any product, commercial software must meet the needs of customers in order to be viable. While there are certainly open source projects that try to do this, I'd bet that commercial software vendors are perceived as being more responsive in this regard generally -- it's their whole livelihood at stake, versus an open source project that is being done for fun or to collaborate on something interesting. In my view, this means that succesful OS Product Managers will have to learn to influence (with brute force money, persuasion or other means) the community to guide efforts in the required direction. * SERVICE/SUPPORT - While it is a myth that you can't get support for widely popular open source projects (check out the Resources pages for something as small as Struts, for example), it is *definitely* true for less popular projects, or projects where the developer community is fairly limited. In my view, this means that succesful OS Product Managers will have to learn to organize support networks for their products in different ways as in CS Product Companies. Individual open source projects can clearly choose to deal with the objective realities in each of these three areas, and the ones that do have no problem competing with commercial closed source software. But the general perceptions in these areas about the open source community, as a whole, are fairly accurate IMHO. On the other hand, the real world is also getting more complex in this regard, with companies choosing to build commercial products that are partially or (almost) completely constructed with open source software -- licenses like the Apache Software Foundation license make this trivially simple. I have some experience regarding this area, and I think this is an area with a lot of future. Most software integration effort will go this way in the next years. We have
Re: Interesting quote....
Fernandez Martinez, Alejandro wrote: Heh, that's funny. Thanks for pointing it out, I would never have imagined that. It has been there since the very beginning. I remember seeing it back in Netscape 2/3 times, when Explorer was barely used at all (95/96, I can't remember). (...) Erm, IE 5.5 - Help - About Based on NCSA Mosaic. NCSA Mosaic(TM); was developed at the National Center for Supercomputing Applications at the University of Illinois at Urbana-Champaign. Now that's irony for you. Regards, Santiago Gala -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ANN] in-house mail archive...
Pier Fumagalli wrote: It's internet explorer not sending the correct locale... Daniel's aware of that, and a fix is shortcoming... Use mozilla! :) Tis is mozilla: org.apache.velocity.exception.MethodInvocationException: Invocation of method 'get(PageTitle)' in class org.tigris.eyebrowse.util.LocalizationTool threw exception class java.util.MissingResourceException org.apache.velocity.exception.MethodInvocationException: Invocation of method 'get(PageTitle)' in class org.tigris.eyebrowse.util.LocalizationTool threw exception class java.util.MissingResourceException at org.apache.velocity.runtime.parser.node.GetExecutor.execute(GetExecutor.java:116) at org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:226) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:207) at org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:250) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:271) at org.apache.velocity.runtime.directive.Parse.render(Parse.java:232) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:153) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:271) at org.apache.velocity.Template.merge(Template.java:296) at org.apache.velocity.servlet.VelocityServlet.mergeTemplate(VelocityServlet.java:448) at org.apache.velocity.servlet.VelocityServlet.doRequest(VelocityServlet.java:387) at org.apache.velocity.servlet.VelocityServlet.doGet(VelocityServlet.java:333) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:201) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2344) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:163) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1011) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1106) at java.lang.Thread.run(Thread.java:484) with my standard settings: Ejemplo de Cabecera de Request Host hisitech.com:8080 Accept text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1 User-Agent Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020425 Keep-Alive 300 Accept-Language es-es, en-us;q=0.80, es;q=0.60, en;q=0.40, ja;q=0.20 Accept-Encoding gzip, deflate, compress;q=0.9 Accept-Charset ISO-8859-1, utf-8;q=0.66, *;q=0.66 Referer http://hisitech.com:8080/examples/servlets/index.html Connection keep-alive taken from tomcat request headers. P.S.) I don't speak japanese, but I have it there to test Jetspeed i18n -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: You make the decision (was Re: Quick! convert all your projectsto maven!)
Leo Simons wrote: (...) Andrew, consider using the CSS from the Tigris Style project http://style.tigris.org/. It's a new project, but already in use in several major OSS code bases, including Maven, Scarab, and Eyebrowse. I looked at these and they're a major pain in the *** to modify - you have to modify code in 3 places in 3 files or something for every change you wish to make; css classes are used more widely than their naming implies, etc. *shrug* Someone will soon come for a proposal for namespacing class names in CSS. I think it's time to think about retiring myself from programming... :-) Santiago (A little burned, but slowly coming back to life) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: You guys are so funny.
Jon Scott Stevens wrote: Sure, the developers are working together on *some* stuff, but the core products they are not and my original Tomcat arguments were that it was lame to have two different containers. I got proven wrong from the point of view that enough people wanted T3 to survive. I got proven right that T3 distracted a limited set of resources (ie: people) from T4. Open Source does not care about optimizing resources, but about creating, maintaining and supporting communities. This is an argument I have had enough time with project managers who think that Open Source is inefficient: IT IS! It is about enabling more ants to thrive in the anthill, not about exploiting the ants to pick more food _per capita_. It is really a way to tackle more complexity, not about being more efficient at it. The proof is that all of us are here losing our time instead of picking a quick winner and going back to work. So, if the split of tomcat enabled more production sites using tomcat 3 while tomcat 4 was ready, or more programmers coming to tomcat 4 to test cool new features, it was actually good... because they did not parted away, and shared their relative successes together. The same could happen here. If XML-centric people think about cool things (like finding a clean way to drop beans as context for document transformations... Peter Donald had a cool idea on this some time ago (DOM on the fly)), while template-centric people develop even cooler things (like having a properly recursive way to specify transforms without having the horrible syntax that XSLT shows ), I would be really delighted, and my employers even more. (Actually I would like to have both things, to use them effectively in content aggregation). The point I have been trying to make is that the important thing is to avoid losing the connection between both efforts, and to coordinate together the efforts. Some people pointed to reasonable approaches (Costin one of them). Isn't there a way to find common grounds? Santiago PS) As a proper spanish quixote, I can't avoid to jump here: I hope another jakarta commiter will join me and second my -1. I second! until I feel a situation in which there is no one of us that feels defeated, maybe all of us just a little bit deceived. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: webapp invoker doesn´t work
Edson Alves Pereira wrote: I´m using Tomcat 4.0.3 and Apache 1.3.2 and the Tomcat´s invoker doesn´t call my servlets. I think that i´ve already done everything, where i can get a good howto about? You happened to jump into the fire of a project join/split discussion. I'd strongly recommend that you keep your errand going on at the tomcat-users list. TIA -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: You guys are so funny.
Berin Loritsch wrote: Michael McCallum wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I do that because I believe standards are essential - even if 'simpler' pet-solutions exist. Standards are the only way to get people to work togheter - and DocBook, HTML, XSLT are the standards. Microsoft did not get where it was by using standards. It created things which were easy for people to use and they became the de facto standards. Grmble grmble grmble. Microsoft got where it is based on the shear might of its marketing prowess. It made it easier than Mac to develop, so more developers created solutions for it. I've seen Java tools beat out M$ tools for the same job. In a sense, it could have been a case of the Rise of Worse is better (in Richard Gabriel's sense: http://www.jwz.org/doc/worse-is-better.html). I'm not claiming that Microsoft designed from New Jersey, :-) but that while IBM was making the perfect OS/2 and all the UNIX community was caring about CORBA and complex code repositories they delivered a Windows, and later Visual Basic, which was a horrible hack, but a hack that enabled companies to start making client server. Take this together with the exponential expansion on the number of PCs, and the need of programmers to feed them, and it makes sense. While they were a busy monopoly thinking about New Technology, on the other side, Mozilla (and A Patchy Server, and later a flock of penguins and devils) left them out of a new game. This could be again a case of Worse is better. Even the Velocity vs XSLT could be a case for Worse is better :-) (Seriously, I have been thinking along these lines for the last days) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: You guys are so funny.
Geir Magnusson Jr. wrote: On 5/2/02 5:45 PM, Santiago Gala [EMAIL PROTECTED] wrote: Even the Velocity vs XSLT could be a case for Worse is better :-) (Seriously, I have been thinking along these lines for the last days) That's DVSL vs XSLT. I was slightly off-focus. I was thinking about using the Anakia task vs XSLT to transform XML for web pages. This IMO was a case of worse is better, since the complexity of doing it right in XSLT leads to all sort of implementation complexities, and doing it right in XML to awful syntax. On the other hand Anakia is too simple for complex use cases. But it delivers simple transformations, and does them fast. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: You make the decision (was Re: Quick! convert all your projectsto maven!)
Andrew C. Oliver wrote: Nope. Perhaps your font settings differ from mine or perhaps Redhat or Ximan package different fonts? And I'm at 1600x1200 so well... dunno what the story is. Is anyone else having trouble with this? http://jakarta.apache.org/poi/javadocs/ Not with this one (Mandrake 8.2, mozilla RC1 or a nightly more recent than this one, I can't remember). But the upper frame in http://jakarta.apache.org/poi/javadocs/javasrc/ looks blank for me. P.S. Please everybody, don't let the fury make you forget to snip when you answer :-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[OT] OR mapping tools as a commodity
Jon Scott Stevens wrote: on 4/24/02 8:13 AM, Bala Kamallakharan [EMAIL PROTECTED] wrote: I personally like Zodo JDO (http://www.solarmetric.com/). It is pretty slick, it does exactly what you want to do. Given a class that you build in Java it can generate tables and make the classes Persistence Capable. Thanks, Bala http://www.solarmetric.com/Software/Kodo_JDO/pricing.php Only $3000 to deploy it! Bah. This stuff should be free. When reading this thread, I couldn't avoid remembering having read a few days ago, in the context of MS auditing schools in Oregon?, that Office automation software and OSes do not longer deserve paying the premium of brands (read MS Office), as it is becoming a generic drug (a commodity, in other terms, read OpenOffice, kOffice, abiword/gnumeric, you name it). I think OR mapping tools (most development tools, in fact) are reaching the same status. This is a sign of maturity in software engineering. One of the few I've seen lately. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: So, Google uses Tomcat and Apache SOAP...
Paulo Gaspar wrote: http://www.beblogging.com/blog/20020417-221452 Have fun, Paulo Gaspar This is all your spamming? I see better and much longer every day :-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] http://jakarta.apache.org/site/mail2.html broken url
Daniel F. Savarese wrote: In message [EMAIL PROTECTED], Santiago Gala writes: Santiago Gala wrote: I have enough karma for xml/html committing, but not for ssh to the web machine. So, could anybody with enough karma update the site? I just did a cvs update mail2.html, but it doesn't look like there was any change committed. I tried doing an update and rebuild of my jakarta-site2 checkout, but there ws no difference in mail2.html. Funny, because I patched mail2.xml: [sgala@patusan jakarta-site2]$ cvs log xdocs/site/mail2.xml RCS file: /home/cvs/jakarta-site2/xdocs/site/mail2.xml,v Working file: xdocs/site/mail2.xml head: 1.43 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 43;selected revisions: 43 description: revision 1.43 date: 2002/04/07 22:05:50; author: sgala; state: Exp; lines: +1 -1 Patch sent by [EMAIL PROTECTED] Thanks. ... I don't have the email with the original patch, so I'll pass the buck to someone else. I had committed just changes in mail2.xml, thinking that the build was done elsewhere. Now I have committed also mail2.html. Sorry for the half cooked thing. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] http://jakarta.apache.org/site/mail2.html broken url
Santiago Gala wrote: robert burrell donkin wrote: http://jakarta.apache.org/site/mail2.html has a broken url (to a tomcat user list archive). attached is a patch. - robert I have committed this one, while I was at this. Is there something else needed for the website to get updated? partial ACK, should be ACK+SYN? ;? I have enough karma for xml/html committing, but not for ssh to the web machine. So, could anybody with enough karma update the site? (SYN after timeout of previous ACK+SYN ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] http://jakarta.apache.org/site/mail2.html broken url
robert burrell donkin wrote: http://jakarta.apache.org/site/mail2.html has a broken url (to a tomcat user list archive). attached is a patch. - robert I have committed this one, while I was at this. Is there something else needed for the website to get updated? partial ACK, should be ACK+SYN? ;? Index: xdocs/site/mail2.xml === RCS file: /home/cvs/jakarta-site2/xdocs/site/mail2.xml,v retrieving revision 1.42 diff -u -r1.42 mail2.xml --- xdocs/site/mail2.xml 6 Mar 2002 16:47:53 - 1.42 +++ xdocs/site/mail2.xml 5 Apr 2002 15:37:14 - @@ -28,7 +28,7 @@ lia href=http://geocrawler.com/;Geocrawler/a/li lia href=http://marc.theaimsgroup.com/;Mailing list Archives/a/li lia href=http://www.metronet.com/~wjm/tomcat/;Tomcat-Dev Archives/a/li -lia href=http://mikal.org/interests/java/tomcat/index.html;Tomcat-User Archives/a/li +lia href=http://mikal.org/interests/java/tomcat/;Tomcat-User Archives/a/li lia href=http://www.mail-archive.com/struts-user@jakarta.apache.org/; Struts-User Archives/a/li lia href=http://www.servlets.com/archive/;Servlets.com servlet and JSP list archives/a/li -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Switching development to C#
Marc Johnson wrote: From: Paulo Gaspar [EMAIL PROTECTED] Do you have anything against Fortran or Cobol? Cobol, yes. Fortran, no. There will be .Net implementations for those, you know? And we could leverage the power of all those legacy academic and enterprise programmers. Nh ... I heard someone (Sam?) say something about implementing APL! (slogan: write once, read never) If I can ask, I would like to have some LISP (prefearable Scheme) .NET also You know: (let ((write once) (eval forever)) #t) (I know April's fool its over, but in any case we don't celebrate it in Spain until December 28) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: news@jakarta list? (Re: Introducing Enterprise Object Broker)
Jeff Turner wrote: On Thu, Mar 07, 2002 at 06:03:21PM +, Pier Fumagalli wrote: Paul Hammant [EMAIL PROTECTED] wrote: Folks, Enterprise Object Broker (EOB) is an application server that tries to a be a simpler EJB container. It is not complete yet, but we have many demos showing local, remote, and webapp usage. Ok. Will we all stop using general@jakarta for advertisement of things which are NOT ASF related? Thankyou... Then could we perhaps have a news@jakarta list for this sort of thing? A lot of people find announcements like this relevant and interesting. On a related (technological) note: We Jetspeed people (actually Raphael Lutta) put one year ago RSS channels, for our own purposes of showing them in the demo Jetspeed setup: http://jakarta.apache.org/jetspeed/channels/apache.ocs is an Open Content Syndication feed http://jakarta.apache.org/jetspeed/channels/jetspeed.rss is a channel for Jetspeed http://jakarta.apache.org/jetspeed/channels/turbine.rss is a channel for turbine The RSS mechanism could be easily used for news and content syndication @apache. Channels can be added, generated, etc. for different projects or activities, and used for dynamic linking to apache news from outside the web site. How is it different from freshmeat? It's that 'community' thing Stefano goes on about. People have established webs of trust here. EOB is by Apache people, using Apache code, and that makes it *relevant*. --Jeff Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: News, RSS, blogs, Cocoon (Re: news@jakarta list?)
Jeff Turner wrote: On Fri, Mar 08, 2002 at 12:00:11PM +0100, Santiago Gala wrote: ... Then could we perhaps have a news@jakarta list for this sort of thing? A lot of people find announcements like this relevant and interesting. On a related (technological) note: We Jetspeed people (actually Raphael Lutta) put one year ago RSS channels, for our own purposes of showing them in the demo Jetspeed setup: http://jakarta.apache.org/jetspeed/channels/apache.ocs is an Open Content Syndication feed http://jakarta.apache.org/jetspeed/channels/jetspeed.rss is a channel for Jetspeed http://jakarta.apache.org/jetspeed/channels/turbine.rss is a channel for turbine The RSS mechanism could be easily used for news and content syndication @apache. Channels can be added, generated, etc. for different projects or activities, and used for dynamic linking to apache news from outside the web site. Sounds nice. Is this demo Jetspeed setup actually live somewhere? I have a copy running at http://hisitech.com/jetspeed/ (rather out of date, and messed up by hundreds of people customizing layout). David Taylor uses to have one around http://bluesunrise.com/jetspeed There are portals using Jetspeed around (see http://jakarta.apache.org/jetspeed/site/usejetspeed.html), but most use their own feeds. Adding some weblogs as newsfeeds would be good too. Weblogs are wonderful things. Have a look at http://www.need-a-cake.com/ Any JAMES people lurking here? Would it be possible to rig up a mailet that wraps incoming posts in XML and makes them available as an RSS feed? That way we could have an easy-to-use news submission process. FYI (for those who weren't aware), there's a new xml-forrest project project at xml.apache.org, specifically for things like this. I knew this one. Another FYI for Jetspeed people: Cocoon is very much encroaching on your portal turf ;) See http://www.need-a-cake.com/stories/2002/02/14/cocoonPortalFirstLook.html I know. Further, cocoon and Jetspeed people should team together to ensure that Sun's JSR#168 standardizes around a reasonable Portlet API specification, specially WRT SAX stream portlets, so that Cocoon can implement a portlet container respecting the standard and using Cocoons streaming capabilities at the same time. Jetspeed will be conformant to the ByteStream or SAX stream API rather easily, and at due time, using jsp and/or Velocity. --Jeff (idling.. friday evening..) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Nominations, +1s, ...
Dirk-Willem van Gulik wrote: On Wed, 6 Feb 2002, Santiago Gala wrote: I'm ready to give +1 to people nominated which are missing them, but I could not find any posting telling if +1 are required, or are just to be considered a form of moral support. Could anybody clarify? Personally: I do not care much for seconding - just that the person accepts - simple voting is the true test in my personal opinion. And in a crowd as vocal as this I trust that issues are raised in time to make sure that seconding is non essential filtering mechanism. But that is a personal opinion - not the nessesarily shared by the voting volunteers opinion of that of the board or pmc. So for next time 2003 - you have some options. 1- No seconding needed - just acceptance. I would support 1. My concern was because I had seen people with no +1, and I wanted every nominee having the opportunity to get voted. I felt like I was spoiling my +1 by not using them. :) I don't think veto is right. Vetoes should be handled in the ballot. I mean, I can argue someone is not the right person, but this should not automatically discard them. The nomination mechanism is already giving a filter on who will be proposed. The ability to veto could become a problem if/when there are fighting fractions in the nominating group. 2- One seconding needed - and acceptance counts as such too. 3- More than one needed. 4- None needed - except to override a veto.. 5. Dw. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Java is dead... but it could still be saved!
Andrew C. Oliver wrote: On Tue, 2002-02-05 at 11:24, Stefano Mazzocchi wrote: Jon Scott Stevens wrote: on 2/4/02 1:58 PM, Kevin A. Burton [EMAIL PROTECTED] wrote: (snip) They dropped the ball for java on the desktop: sun management decided that it will never happen: there will be no Java version of StarOffice. So they want to earn money on the other two sides: big - enterprise (J2EE) possible. They're going about it the wrong way (still). small - embedded (J2ME) pipe dream. If embedded resources grow substantially (to where embedded means a system about as capable as my desktop), Bill G. and the gang win. No. Bytecodes + built-in security (sandboxes, etc.) make java a substantial win for Telephone operators. C# is not yet prepared for taking this market. Solutions like ActiveX are a mess to deploy and suffer from logistic (deploy for a hundred hardware variants), reliability (crashes in user C/C++ code) and big security problems (bad security model). The telephones that we will see in the next couple of years will use java. And this is a substantial market (in the thousands of millions units) where Sun wants to take their license for every telephone sold, and sell at the same time their java hardware and expertise (read J2EE) in the server side to the operators and service providers. If it stays small, Palm and KR win. Sun has to bet on something in between or start making Java native chips again.. Its a pipe dream of a business plan. I think it is actually working well for Sun, from what I see in their relation with big mobile operators and handset makers. Whether Sun will survive to a mature multiplatform C# solution with the ability to run java applets (midlets...) is another thing. Don't forget that Microsoft are better when they arrive second to the market (see IBM MS-DOS, Digital Research solution vs Windows, Lotus/Excel, WordPerfect/Word, dBase/SQL Server,...) why? simple: these are the things that pay off and these are the things that go along better with Sun core business: which is hardware (both big fat machines and silicon chips). don't forget that they have a good sales channel to big corporations like banks, phone operators, utility companies,... Quite often better than the one MS has. Now: is Sun going to change this because Mr. Burtonator cries on his own mail list? yeah, sure. Unless he has a few 10 billion dollars to invest in Sun to open up java. Sun can't start selling JDK's, otherwise people will switch to .NET (or OSS clones of it, see Ximian MONO), but it sure can stop improve on it (after 1.4 is out) and give away for free *normal* java implementations and sell better/faster/more-scalable JVMs (which is what M$ will be doing with .NET) You can be sure Sun has a lot to learn from M$ on the marketing-software side of things. Yep, people, Java is turning into legacy for most corporations: they'd rather spend some thousand dollars in new software (which will run on sparc only, of course) than spend millions in retraining people, porting software to .NET and blah blah blah. perhaps. I feel like I'm legacy myself. I feel lazy about switching to C# stuff. I feel older every day that passes ;) Where does OSS stand? We have been *used* to mak e java solid. probably (Sun = Corporation, Corporations operate in their own interests and not for the public good -- OSS served and possibly serves Sun's interests, if that changes so does Sun). I agree that we have been used. We are used every day. But I feel happy overall with my java experience. Programming in java is funny (like it was in the Smalltalk days, even with some lisps). Programming against current MS APIs is *not* fun. I don't feel abused by the Sun people WRT java. From the beginning I saw Sun as I see them now. Even if I regret that they do not Open Source java, the market will never be the same after their (wise) move back then. Now things are changed: they think they don't need us anymore because Java is a commercial reality. That's the truth and you'd better learn it fast. My position: give me a solid (possibly GPL-ed) CLI implementation, a Java2C# porting tool, a BSD-licensed library of .NET classes and java-cloning classes and I say let's kiss java good bye. Think long and hard before you jump on this bandwagon my friend. If maintaining cross-platform compatibility with the .NET version is an objective for Mono then it will fail. The 3000 lb gorilla will never loose control of its illegitimate child. Regarding C#. I still think I'd rather learn D www.digitalmars.com/d I've seen they still have pointers. I will not go there until they drop them. ;) WRT crossplatform stuff, time is coming when we will impose *our* laws. With linux becoming a major player in the OS level (and I bet it will be a player in the desktop market real soon), crossplatform is beginning to be their problem, rather than ours. As OpenSource works in public, with no hidden
Re: J2EE considered harmful (was [Fwd: cvs commit: jakarta-site2/xdocs index.xml])
Andrew C. Oliver wrote: To be fair, WebSphere is probably more troublesome then the other containers (at least thats been my experience with it). I do think there is a time and place for RPC. I however think better support for location independence is required. (snip) I would suggest gaining experience with other containers (BEA and jBoss for starters, you can download a trial of the former and the latter is opensource) so that you can discriminate the problems that are exist in WebSphere from those in EJBs as a whole. Not because you want to just do not-ejb but so that you don't repeat the same mistakes. I have implemented a system using Container Managed EntityBeans that worked fairly well. I used Jonas (it was some time ago). It was smaller than the original poster example (about 20 entity classes, tens of thousands of instances). I spent a lot of time getting the entity design right. From the original description, it looks like the problems in the quoted project came from bad system design, more than from EJB technology as such. Comments on my experience: - The location and engine independence was a true marvel. I was developing with postgres/linux and deploying under MSSQLServer/NT with the same source code. Only small diffs in configuration needed. - Performance was not good, but scalability was. - Leaving transaction and persistence management to the container proved good at the end. - My main issue in the development were related with using JSP for the interface (JSP sucks (c) Jon :) ) So, while I agree with political/licensing issues being of concern, I would not disqualify EJB as a whole from a technological point of view. YMMV. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
calendar splitting (was Re: ECS?? _TOP_ level project of Jakarta??)
Jeff Prickett wrote: Scott Sanders wrote: Calendar is much more apropos in JAMES IMHO. I think that JAMES could become an Exchange killer :) Good point, I would accept that place as a home for the back end objects. Possibly split iCalendar between JAMES and Jetspeed or make it its own module that plugs in to either. Front end - Jetspeed, Back end JAMES. I would like to see Apache create an Exchange killer, but that talk is premature :). Maybe too late to jump in here, but I see it today :( I think the best thing to do would be to have a standalone calendar backend, communicating with James as transport, and with Jetspeed (and also beans for Velocity and even JSP), for server side front end. An applet could do a client side processor if this is wanted/needed. Jetspeed can do with a calendaring portlet (which is not written, BTW), that could take calendar objects using whichever transport It makes more sense to home the calendar project in James, IMO, than in Jetspeed, specially now that standard wars will begin ;) But I think Jetspeed people will not opose to have you there either. I will present myself also. I'm Santiago Gala, working in Jetspeed. I decided that I was too misinformed about apache stuff and I have decided to subscribe (not read in archives) to force myself to read general apache related lists. Being the typical bottom-up person, I start with jakarta-general. :) Hi to all, Santiago -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Subprojects
At 08:33 23/3/01 -0500, Geir Magnusson Jr. wrote:
However, this is a really good point and a discussion we should have in
Commons-land. Please come and join if interested.
yes and after that you really should standardize on logging. Oh and then
standardize on lifecycle because thats important too.
Not really sure a bean utility library/component will need lifecycle and
logging, nor configuration for that matter
I am not even sure how to answer this? I am not sure if you are serious or
not.
A Database Connection Pool is another story, but we can look a the
17,000 or so implementations already in Jakarta and find the best
practice, and then punt and use log4j :)
Adopt log4j, block avalon/james/cocoon from using component and presumably
taglib/struts when they adopt the J2EE standard. Way to achieve sharing !
! How long do you think before my final prediction bears true? If already
you are talking about "standardisation" when that was explicitly one of the
non-goals then ...
With this kind of FUD, you should have been in software marketing :)
Whats the FUD about it? One of the non-goals was to not devolve into a
framework. For any semi-complex problem domain you need some support
(unless you invent your own for that component). And if you have 50
components with 50 different sets of internal frameworks then...
I'm not getting into this formative discussion. I just want to point
something that came to mind while reading it:
The iCalendar module, that originally was a part of jetspeed code base,
is currently orphan. While it is a reasonable size component, it looks
like a good part of commons, if I understood correctly the discussion:
- most of it is a collection of classes implementing the different vCal
entities.
- I don't know from memory if it is designed a bean, but it could be
made into one easily.
- No control, no log: just new ICal(), new VToDo, ...
- marshal will write a VCALENDAR into a writer
- There is a mechanism for db persistence, though
You can contact with Jeff Pricket about it, if you are interested in
helping finishing it.
I'm lobbying for this project because, even if I don't have currently
the time to get involved, I feel that such a set of objects and
underlying webapp will be crucial for jetspeed, and possibly turbine and
cocoon, to survive in a corporate environment (is this our goal? :) )
Think something like ASP portal, or intranet collaborative tasks. I'm
not aware of any Open vCalendar implementation.
Disclaimer: I'm just plugging my lines. I will not go into discussion
on which is the better strategy to deal with modules, etc. I see valid
points in both (7?) sides of the discussion. :)
Hope the input is useful.
Regards,
Santiago Gala
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: WARNING. You sent a potential virus or unauthorised code
I've just received this. I comment down. [EMAIL PROTECTED] wrote: The MessageLabs Virus Control Centre discovered a possible virus or unauthorised code (such as a joke program or trojan) in an email sent by you. Please read this whole email carefully. It explains what has happened to your email, which suspected virus has been caught, and what to do if you need help. Some details about the infected message To help identify the email: The message sender was [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] (if this is not your email address, the message sender possibly belongs to a mailing list to which you both subscribe.) The message was titled 'cvs commit: jakarta-jetspeed/docs/site administration.html application-development.html branches.html code-standards.html content-syndication.html contributors.html customizer.html developer-notes.html diskcache.html faq.html features.html index.html install.html license.html psml.html resources.html todo.html uml.html usejetspeed.html wap.html' The message date was 23 Mar 2001 14:02:05 - The message identifier was [EMAIL PROTECTED] The message recipients were [EMAIL PROTECTED] To help identify the virus: Scanner 1 (Skeptic) reported the following: Skeptic searching for 26 viruses Possible Virus 'Subject-exploit' found in '588686A_0.txt'. Heuristics score: 1 The message was diverted into the virus holding pen on mail server server-48.tower-1.london-2.starlabs.net (id 588686_985357952) and will be held for 30 days before being destroyed. It seems to be related with the length of the subject line, that could crash some mail agents overflowing a buffer. I'm sending copy to [EMAIL PROTECTED], to see if there is a simple solution to trim the Subject of cvs generated mails to a given maximum length. If not, I would suggest messagelabs.com to unsubscribe all of their people from the jakarta.apache.org lists, to avoid us their spam. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patch for site docs
Jon Stevens wrote: on 3/13/01 9:55 AM, "Santiago Gala" [EMAIL PROTECTED] wrote: I have prepared a patch for site docs, explaining an issue we found when trying to use authenticated cvs with Windows. I tried to commit, but I don't have enough Karma. I don't know if I'm suppossed to have karma on the site docs, so here I send the patch. Feel free to throw it away :) The right place to have sent the patch is to the general@jakarta list as documented here: http://jakarta.apache.org/site/jakarta-site2.html "People who have accounts on apache.org can check in their changes to the jakarta-site2 module directly. If you get an error such as "Access denied: Insufficient Karma", then please send email to the [EMAIL PROTECTED] mailing list and we will grant you the appropriate access. If you do not have an account, then please feel free to send patches to the [EMAIL PROTECTED] mailing list." Sorry about this one. But still the answer is not clear to me. Am I supposed to commit myself or will somebody else consider the patch? Also, you need to send a patch against the .xml file which is used to build the .html files. See the above URL for more information on working with the Jakarta Site2 module. The patch is BOTH to the .html file AND to the .xml file, as I think in this way the changes will be visible without building in apache.org The patch to .html is after I built locally. thanks, -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
