RE: Vendors page
I'm not the one to answer this, but... I think I remember reading something about vendors submitting a patch to the vendor's page. That way, the vendor proves its technical competence, and it's less work for the maintainers. Perhaps you should try to submit a diff or a patch. -Mensaje original- De: Koschitzky Omry [mailto:[EMAIL PROTECTED] Enviado el: lunes 1 de diciembre de 2003 9:32 Para: [EMAIL PROTECTED] Asunto: Vendors page Hello, This is the second email I am sending to you, I didn't get any reply from Apache, if there is any problem in which I can help I will be happy. We are a company that develops a product named XpoLog. We use Apache projects in our solutions. We would like to have a link and description in your vendor's page. Our web site: http://www.xpolog.com Apache projects integration page at XpoLog: http://www.xpolog.com/resources/allies/apache.htm XpoLog / http://www.xpolog.com * XpoLog is a log viewer and analysis server with integration support to Apache projects like log4j and Tomcat. XpoLog provides a solution for both log analysis and support station. * Tel Aviv/ Israel * [EMAIL PROTECTED] Best regards, Koschitzky Omry [EMAIL PROTECTED] XpoLog
RE: mail2.html - mail.html
Hi Tetsuya, What is wrong with the pages as they are? There are thousands of people who have subscribed to the lists using the current method, and luckily there are not too many misdirected posts. Furthermore, a search for jakarta mailing lists http://www.google.com/search?q=jakarta+mail+archivessourceid=mozilla-search start=0start=0 takes you straight to mail2.html. I still fail to see the problem -- it is good to make future posters go through a little extra effort. There are many important issues to tackle, please don't waste your time with this one. (Where is Jon Stevens when you need him?) Un saludo, Alex.
RE: Sun Is Losing Its Way
Hi Aaron, -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Asunto: Re: Sun Is Losing Its Way Geir, I appreciate the intelligent response. I have a question though, what happens when you pour your heart and soul into building a product, and make it so user friendly that not many people need support? Now your product is open source and everyone is getting it for free so nobody is buying you 'commercial' version and you can't sell enough support to earn a living? If you have the ability to do such a feat, you will be worshipped. You will be able to earn a living just by giving lectures. Write a book about software development, and you will have enough royalties for the rest of your life. And with a little luck, Microsoft will make you an offer you can't refuse... Make a crippled port of their software to BSD! Un saludo, Alex.
RE: velocity lovers...
-Mensaje original- De: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Enviado el: jueves 5 de diciembre de 2002 1:38 Para: [EMAIL PROTECTED] Asunto: Re: velocity lovers... I'm completely amazed and disappointed that Sun is spending so much time, energy and money towards creating so much crap. ... again. Un saludo, Alex.
Jakarta on the news
FYI: Ground work laid for Open Source Java http://www.theregister.co.uk/content/4/28337.html (ComputerWire via The Register) Some highlights: Java Community Process (JCP) members have voted to alter the community's structure, officially supporting open source implementations of Java. Called JCP 2.5, changes were approved on October 29. The first instance of Java expected to be open sourced under these changes is the Java 2 Enterprise Edition (J2EE) 1.4 platform, which Santa Clara, California-based Sun said is due in the first quarter of 2003. Hardly big news, but worth a look (at least it mentions Jakarta). Un saludo, Alex Fernández.
AutoResponder 2000: fuera de la oficina
Este mensaje fue autogenerado por AutoResponder 2000 Fuera de la Oficina Hola, estoy de vacaciones y... no sé por qué añadir más cosas si la mayoría de la peña en Jakarta no sabe ni papa de español -- si eres de los pocos afortunados, que sepas que esto es una broma. Pero visita http://jakarta.apache.org/site/getinvolved.html Gracias por tu paciencia. Out of Office Hi, I am on holidays and... I cannot answer your message right now. If your mail is about helping the Jakarta community, please be patient -- a human operator will read it as soon as possible. Meanwhile, please visit http://jakarta.apache.org/site/getinvolved.html Thanks for your patience. Mensaje Original- De: mohammad nabil [mailto:[EMAIL PROTECTED]] Enviado el: viernes 4 de octubre de 2002 14:40 Para: [EMAIL PROTECTED] Asunto: Re: karma for jakarta-site2 hi, hope somehuman read any of my mails to jakarta community. i would like to help in any thing, but it seems that only mail machines read my email :s i hope to hear from any one alife at there :D -Mohammad Nabil From: Jeff Dever [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: karma for jakarta-site2 Date: Thu, 03 Oct 2002 20:28:04 -0400 I would like to add some info to the jakarta-site2 module. Could somone hit me with the karma? Jeff Dever HttpClient 2.0 release manager -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Send and receive Hotmail on your mobile device: http://mobile.msn.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: localhost:8080 vs localhost???
Hi Andrew, -Mensaje original- De: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Enviado el: viernes 19 de julio de 2002 0:10 Para: Jakarta General List Asunto: Re: localhost:8080 vs localhost??? Live in your happy little world, and if you're happy putting out that sludge go for it. When your skills progress and you'd like to create object oriented software (even in a web app) and cleanly seperate your logic and content in a web application that is maintainable under time, perhaps you'll look up a more advanced framework and grow to find the failings in JSP. That is condescending and paternal. I like it! ;) -Andy JSP = Java's Super PERL! :-) Your comment is right on target. You seem to be in the right object-oriented state of mind. When your skills progress, after you have helped create a couple of webapp frameworks, and bashed JSPs to death on every occasion: you will end up using PHP despite it being fugly because [...] you can get a lot more done with it in a short amount of time [...] Sheesh! Alex. James Mitchell Software Engineer\Struts Evangelist Struts-Atlanta, the Open Minded Developer Network http://www.open-tools.org/struts-atlanta -Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 18, 2002 4:10 PM To: Jakarta General List Subject: Re: localhost:8080 vs localhost??? But no one replied to my lovely email when I said that other than POI and HTTPD there was only actually one Apache project, all the others are the same project implemented different ways and that JSP had the structure of a dog turned inside out... I was so proud of that...how mean of you all not to respond :-( ;-) -Andy Leo Simons wrote: Is that site generated by maven ? ;)) Mvgr, Martin Anakia I hate to admit it here, but the output is .html files which are then processed through PHP. I'm going to be moving away from even using Anakia and just using PHP. PHP is terribly fugly and encourages the worst code design ever, but you can get a lot more done with it in a short amount of time and there is no way in hell I would ever lower myself to using JSP. =) yeah. And it's got a template language called Smarty which is *way* better than velocity!!! :P - Leo, who figured there was another flamefest when he saw all those e-mails and is now eagerly waiting for a picture of a crossdressing jon... -- 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] -- 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: localhost:8080 vs localhost???
Hi Andy! -Mensaje original- De: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Enviado el: viernes 19 de julio de 2002 13:28 Para: Jakarta General List Asunto: Re: localhost:8080 vs localhost??? Initial development costs are 1/3 of the overall cost of a project. Once you've been stuck maintaining a few of those nasty beasts you create in PHP you'll move on to want something else and be very appologetic to everyone you pumped that crud out for. I've full confidence that one day a smart guy like you will abandon the right is wrong principal. :-) ;-) What? And lose my 10-minute investment in learning PHP? No way! Besides, now I can have fun a whole weekend, just changing the name of a field in the database. My life would seem empty in comparison, if I got to use those pesky frameworks that do everything for you. (Never thought one day I would get to pull Jon's leg. Hey folks, it's a great sensation! I feel important!) :) Alex. -Andy
RE: Interesting quote....
Heh, that's funny. Thanks for pointing it out, I would never have imagined that. Un saludo, Alex. -Mensaje original- De: Les Hughes [mailto:[EMAIL PROTECTED]] Enviado el: martes 18 de junio de 2002 15:37 Para: 'Jakarta General List' Asunto: RE: Interesting quote 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. -Original Message- From: Fernandez Martinez, Alejandro [mailto:[EMAIL PROTECTED]] Sent: 18 June 2002 11:03 To: 'Jakarta General List' Subject: RE: Interesting quote +1 from a non-committer ;) Remember that Netscape originally competed against NCSA Mosaic, it was only later that Microsoft entered the game. Un saludo, Alex. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Interesting quote....
+1 from a non-committer ;) Remember that Netscape originally competed against NCSA Mosaic, it was only later that Microsoft entered the game. Un saludo, Alex. -Mensaje original- De: Martin van den Bemt [mailto:[EMAIL PROTECTED]] Enviado el: martes 18 de junio de 2002 11:30 Para: Jakarta General List Asunto: Re: Interesting quote Also +1 on this one. Competing isn't good, since your strategy is based on what another company does, and then you are doomed. Just define your own goals, and if that ends up in being competetion for Microsoft, it is not even your problem, but you just made something that is really good! Mvgr, Martin On Tue, 2002-06-18 at 09:39, Sam Ruby wrote: Doug Bateman wrote: Sorry, I just don't measure success in terms of defeating Microsoft. And I'd wager Gandi's goal wasn't to defeat Britian, but to free India. Hopefully, Apache feels the same way. Last I checked, beating Microsoft was never mentioned in the Apache mission statement. +1 - 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: Hi I am a new Joinee.
Hi Rajan, Feel free to submit your code as patches, if you find it useful and you think it might be useful to others. There is no recruitment around here that I know. Un saludo, Alex. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: martes 11 de junio de 2002 7:36 Para: [EMAIL PROTECTED] Asunto: Hi I am a new Joinee. Hi All, I am Rajan Kumar, working as Software Engineer in India. I am using few of Apache community Softwares. I really excited about Jakara-Apache community. Eventhough Open Source, good amount of standard and quality of work is there. Keep doing. My Best Wishes to you all. And as a Software Professional I feel, I should also join in the community to serve Open Source Softwares. So if anyone of you find me suitable please let me know. Thanks and Regards / Rajan Kumar -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PROPOSAL] Committer access and responsibilities...
Hi Andrew, -Mensaje original- De: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Enviado el: sábado 25 de mayo de 2002 18:39 Para: Jakarta General List Asunto: Re: [PROPOSAL] Committer access and responsibilities... From my understanding, in most European parliamentary democracies, generally you vote for more issue-oriented parties. Even if you loose you take a certain number of seats. So it makes sense to vote regardless of whether its going to be a landslide. In most European countries, voting is as irrelevant as it's in the States: http://www.billionairesforbushorgore.com/ In Spain we've seen socialists undercutting social benefits and privatizing public companies; and right-wing parties supporting abortion and promoting public function. (Not a bad thing, necessarily, just a sign of the times). I'm sure you can think of similar examples in your own countries. The true strength of the Apache community is, IMHO, not in its democratic values, but in the spirit of cooperation. Only when this fails, does the result suck (Apache Axis comes to mind). Un saludo, Alex.
RE: Maven is growing
Is it not ok to post strong language on this list? Are there kids around? Un saludo, Alex Fernández. -Mensaje original- De: Sale, Doug [mailto:[EMAIL PROTECTED]] Enviado el: viernes 3 de mayo de 2002 21:13 Para: 'Jakarta General List' Asunto: RE: Maven is growing agreed. the swearing (http://www.mail-archive.com/general@jakarta.apache.org/msg051 30.html), self-congratulating web page (http://jakarta.apache.org/site/jon.html), and general attitude is disheartening. most of us don't need others to step in and defend our 'nice-guy' status. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 1:18 PM To: Jakarta General List Subject: Re: Maven is growing On Fri, 3 May 2002, Jon Scott Stevens wrote: well, just yesterday we had: [daedalus] 10:56am ~ grep -c /maven/ 02 7546 Looks like the *entire* life of your project has been around 9500... OhhA My english vocabulary is too limited to express what I feel reading this... Maybe ashamed to be in the same 'community' with this kind of person. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: strange behaviour with servlets
Try in the tomcat-user list. Un saludo, Alex Fernández. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: martes 30 de abril de 2002 19:35 Para: [EMAIL PROTECTED] Asunto: strange behaviour with servlets Before i had some problems to make Tomcat understand my JSP pages and servlets, now Tomcat work fine with my JSP pages, but when i post a servlet IExplorer try to download my class file. Why this happen? PS.: I have a WinNT with Apache 1.3.2 and Tomcat 4.0.3 __ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: New Subproject proposal Config4J
Not any more. As of today, Google returns http://jakarta.apache.org/ as the first hit for Jakarta... That makes the capital of Indonesia the city named after the Jakarta project, at least on internet terms... Alex. -Mensaje original- De: Gunnar Rønning [mailto:[EMAIL PROTECTED]] Enviado el: lunes 29 de abril de 2002 17:00 Para: Jakarta General List Asunto: Re: New Subproject proposal Config4J * Endre Stølsvik [EMAIL PROTECTED] wrote: | | | Jakarta | Annoying.. Jakarta is a city on Java. The name makes perfect sense to me as Jakarta is a community developing software based on Java. -- Gunnar Rønning - [EMAIL PROTECTED] Senior Consultant, Polygnosis AS, http://www.polygnosis.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: RE: Subproject Proposal - crossdb
From an outsider's perspective, you probably need a new proposal. Un saludo, Alex. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: jueves 25 de abril de 2002 3:06 Para: Jakarta General List Asunto: RE: RE: Subproject Proposal - crossdb So, I'm kind of curious what the general consensus is regarding this. Seems to be in various directions. Travis Original Message From: Jeff Schnitzer [EMAIL PROTECTED] Sent: 2002-04-24 To: Jakarta General List [EMAIL PROTECTED] Subject: RE: Subproject Proposal - crossdb From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] on 4/22/02 12:19 AM, Leo Simons [EMAIL PROTECTED] wrote: While these may not be accurate summaries, I hope you now do see that CrossDB and Torque are not, in the majority of use cases, alternatives to one another. I'm sorry. I don't see that. Torque can do everything crossdb can do and more. Uhhh: Outer joins? Fetch data across multiple objects? Aggregation queries? Torque is an O/R mapping framework, with all of the inherent limitations of trying to make relational data look like objects. Crossdb is a database-independent abstraction of SQL (not JDBC, that's an important distinction!). These are not competitive facilities; in fact they should be highly complementary. At the moment, Torque's extremely limited Criteria object has a tough time with simple conditions like WHERE bob 5 and bob 10. Subqueries and joins are hopeless. Crossdb is what Torque desperately needs - a good database-independent way of specifying sophisticated conditions. The WhereClause in Crossdb could be substituted wholesale for Criteria. And for those of us that have to query our databases and obtain results which do not map 1-to-1 with a single object (such as anything that involves a group by or an outer join), we can bypass Torque and still have database independence. I think both Torque and Crossdb (if it has the community) are very much needed as top-level Jakarta projects. They are both bread-and-butter server development tools. Putting Crossdb under Torque makes about as much sense as putting Torque under Turbine. Oh, and Jon, the comparison with ECS is not very good. Web pages are a creative endeavor, whereas SQL statements are short and built by hard-core programmers. Also, simple HTML does not suffer from the problem of every web browser on the planet requiring a slightly different syntax for putting columns in a table... Velocity might be less useful if a separate template had to be written for every single web browser. Jeff Schnitzer [EMAIL PROTECTED] -- 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: Subproject Proposal - crossdb
Hi Kevin, Jon Scott Stevens [EMAIL PROTECTED] writes: If anything, crossdb is something that is a few generations behind Torque in terms of functionality and design. http://jakarta.apache.org/turbine/torque/ Yeah... I was going to point this out. Funny how all the rage recently seems to be creating these OR tools. snip/ It is a problem people can understand and is easy to become fascinated with. Similar to they way everyone in the world has created their own text editor. Kevin I can imagine why people do their OR tool: because existing ones do not fulfill their necessities. In fact, that's what happened to me recently. Torque is nice, but you have to specify the database first in the XML. Usually, I prefer to code Java instead of XML. If it was the other way around, it would have been our primary choice. No flames please: different use cases call for different tools. Torque would have been perfect for a set of tables which you can define completely from the beginning, and make a few changes along the way. In our case, the set of tables was meant to grow and be expandable. Besides, database layers are not so difficult to build. Un saludo, Alex Fernández.
RE: Subproject Proposal - crossdb
Hi Amarendran,
If you analyse the database, then you have to define it first using an SQL
script, or something. We felt the need for a tool that, taking a set of
classes, created the tables for us and filled them with the objects.
For example, if we have
public class Nested
{
private int a;
}
and
public class Container
{
private String primaryKey;
private int b;
private Nested nested;
}
the database layer should create two tables, add a foreign key to Nested,
and map any instances to database tables using the primaryKey field.
Un saludo,
Alex.
-Mensaje original-
De: Amarendran Subramanian [mailto:[EMAIL PROTECTED]]
Enviado el: miércoles 24 de abril de 2002 16:10
Para: 'Jakarta General List'
Asunto: AW: Subproject Proposal - crossdb
Torque is nice, but you have to specify the database first
in the XML.
Usually, I prefer to code Java instead of XML. If it was the
other way
i solved this by writing a little tools that analyzes the database
and generates the xml for me. but this is for my own tool not
for torque ;)
it also reads the foreign keys and creates the right
references in the
mapping xml. additional stuff is done in a seperate
manual.xml. works fine
!
--amar
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
[OT] RE: Subproject Proposal - crossdb
Thanks for the plug. Whenever I need a commercial product, I will certainly use Zodo JDO. For now, I will stick to free software. Un saludo, Alex. -Mensaje original- De: Bala Kamallakharan [mailto:[EMAIL PROTECTED]] Enviado el: miércoles 24 de abril de 2002 17:13 Para: Jakarta General List Asunto: RE: Subproject Proposal - crossdb Check out jdocentral.org, vendors implementing the Java Data Object (JSR-12 jcp.org) specification do that stuff. 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 __ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: License issue (the come back)
Hi Costin, Does not the DMCA expressly prohibit reverse-engineering? Or is it just legaleze, not applicable in the real world? Un saludo, Alex. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: miércoles 13 de marzo de 2002 17:04 Para: Jakarta General List Asunto: Re: License issue (the come back) [snip] AFAIK ( and again don't take my word for it, call your lawyer :-), clean room implementations based on a published spec are perfectly legal. Probably the name/logo is protected, but saying that your code implements/is based on jaxp/jmx/etc ( but is not 'certified' or 'compatible' ) should be ok. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: License issue (the come back)
That's good news. Thanks a lot, Alex. -Mensaje original- De: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Enviado el: miércoles 13 de marzo de 2002 18:52 Para: [EMAIL PROTECTED] Asunto: Re: License issue (the come back) on 3/13/02 9:31 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Implementing a published API/specification have nothing to do with reverse-engineering and I don't think it is prohibited. Nope. It isn't. I re-implemented a BEA specification (dbKona) based on their publicly available javadoc's. http://share.whichever.com/index.php?SCREEN=village -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] ASL vs. GPL page: is this okay?
Hi Ceki, -Mensaje original- De: Ceki Gülcü [mailto:[EMAIL PROTECTED]] Enviado el: miércoles 6 de marzo de 2002 23:39 Para: Jakarta General List [snip] Asunto: Re: [VOTE] ASL vs. GPL page: is this okay? The Working Without Copyleft article is remarkably good. The point about the FSF controlling the LGPL is another very significant point: On the contrary, I found this to be the weakest point of the article. The LGPL states that you can choose between the present license or any later version, so any malicious changes to it can be ignored. Below are the relevant sections of the article and the LGPL, so you can make your own judgement (or seek legal advice ;) The Free Software Foundation controls the license. They can release a new version of the license, which then will automatically apply to our software. Although we do not expect the Free Software Foundation of making changes that deviate from the spirit of the current versions, they could make clarifications that are contrary to our intentions. For example, they may clarify that the result of aspect-oriented weaving is subject to the terms of the LGPL, whereas we had intended that it is not. Another concern is who will be in charge of the Free Software Foundation 10 years from now, or what happens if the Free Software Foundation is discontinued? [LGPL, section 13] 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and any later version, you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. Un saludo, Alex.
RE: Jakarta Documentation
Hi Ted, I find the second outline (The Volunteer Guides) better organized and more focused. I would stick to that (the first one was just a proposal to start the ball rolling). Of course, a page commenting on the differences between the Apache license and other free licenses, and why the Apache Foundation chose the latter, would be nice to have. In fact, it should probably belong in www.apache.org. Un saludo, Alex. -Mensaje original- De: Ted Husted [mailto:[EMAIL PROTECTED]] Enviado el: miércoles 6 de marzo de 2002 0:39 Para: Jakarta General List Asunto: Jakarta Documentation Any comments on this? http://jakarta.apache.org/site/methodology.html Note that there are two proposed outlines on the page. + Following the Jakarta Way and + The Volunteer Guides In the latter, I'm trying to organize the material around the various roles people play around here, from a user to a committer to a sys admin, and have them build on each other. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/struts -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Apache Manual (was ApacheForge)
Title: RE: Apache Manual (was ApacheForge) Done. It might go in jakarta-site2/site. I added a short introduction, that should be replaced by someone more knowledgeable. Un saludo, Alex. -Mensaje original- De: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Enviado el: jueves 21 de febrero de 2002 20:28 Para: [EMAIL PROTECTED] Asunto: Re: Apache Manual (was ApacheForge) on 2/21/02 4:31 AM, Fernandez Martinez, Alejandro [EMAIL PROTECTED] wrote: Now, including the valuable contributions of Marc and Jon, the annotated Apache manual TOC would look like this. Now, format it as an xdoc .xml file @see http://jakarta.apache.org/site/jakarta-site2.html and lets run with that... :-) -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] methodology.xml Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Apache Manual (was ApacheForge)
Ok, thanks a lot, Marc and Jon. Included are some links from xml.apache.org, luckily they resemble Jakarta's documents a lot. I know nothing about other Apache projects; I started adding links from httpd.apache.org like crazy, but then realized that the TOC was losing focus exponentially. Probably, someone else should tackle this problem. Now, including the valuable contributions of Marc and Jon, the annotated Apache manual TOC would look like this. 1.- Introduction Who we are, why are we doing this. http://jakarta.apache.org/site/whoweare.html http://xml.apache.org/whoweare.html http://httpd.apache.org/ABOUT_APACHE.html 2.- Project proposal Proposal stage, committers needed, community. http://jakarta.apache.org/site/getinvolved.html http://jakarta.apache.org/site/newproject.html 3.- Apache rules Who gets to vote what. Voting rules, valid votes, +1/+0/0/-0/-1. http://jakarta.apache.org/site/roles.html http://jakarta.apache.org/site/decisions.html http://xml.apache.org/roles.html http://xml.apache.org/decisions.html http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt 4.- Code organization and repositories Naming of packages, repositories, what to find in them. Who touches what. http://jakarta.apache.org/site/dirlayout.html http://jakarta.apache.org/site/guidelines.html http://jakarta.apache.org/site/agreement.html 5.- Code quality Add copyright notice, add authors. Format your code but not others'. http://jakarta.apache.org/site/agreement.html http://xml.apache.org/source.html 6.- Testing Adding test cases. Solving bugs, errors, showstoppers. Security problems. http://httpd.apache.org/security_report.html 7.- Build system Use Ant, use Ant, use Ant. Use Gump. Use Scarab. Not done yet. 8.- Dependencies What jar's to use and what to avoid. http://jakarta.apache.org/site/jars.html 9.- Documentation Where to look for it. What to expect, what not to expect. Not done yet. 10.- Releases When to release, what to release. Release process. http://jakarta.apache.org/site/binindex.html 11.- Support Whom you should ask, what you should figure out yourself. http://jakarta.apache.org/site/mail.html http://xml.apache.org/mail.html 12.- Licensing and guarantee Why you should use Apache license, and what's wrong with other licenses. What you can do with Apache products. Giving credit. All that implied warranty things. http://www.apache.org/foundation/licence-FAQ.html http://xml.apache.org/dist/LICENSE.txt -Mensaje original- De: Marc Saegesser [mailto:[EMAIL PROTECTED]] Enviado el: miércoles 20 de febrero de 2002 20:19 Para: Jakarta General List Asunto: RE: Apache Manual (was ApacheForge) Alex, That's a really good start. My only comment right now is to point out that some of the topics in this list are Jakarta specific and Apache is much bigger than Jakarta. It would be cool if a manual such as this covered how other Apache projects handle similar tasks. I'd also include a chapter on Apache and Jakarta rules. For example, voting rules, what constitutes a valid vote, what are the voting types and when they apply, what are meanings of +1/+0/0/-0/-1 in the various voting types. A collection of release instructions for various projects might also be useful. When I was the release manager for Tomcat 3.2.x I got some initial help from Craig, but after that I had to invent most of the process myself (and I'll be the first admit that I didn't document that process :-( ). I'm sure I think of more after giving it some more thought. Good start, though. Marc Saegesser
RE: EJB = bad = MS.net
I personally think that a distributed remote system has great promise. I feel that the EJB implementation is messy, closed and propietary. Un saludo, Alex. -Mensaje original- De: Pete Chown [mailto:[EMAIL PROTECTED]] Enviado el: jueves 21 de febrero de 2002 14:09 Para: Jakarta General List Asunto: Re: EJB = bad = MS.net Vic Cekvenich wrote: Doing EJBs is bad on many levels and creates more problems. Do you feel that the idea of an EJB-like system is bad, or just that EJBs specifically were badly designed? I would be interested to hear your thoughts on a better alternative. I feel that web programming is currently not using programmers' time very efficiently -- you have to write a lot of repetitive, routine code. It would be nice to find a more powerful way of expressing the logic of a website, so making the process less tedious (and saving money). -- Pete -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Apache Manual (was ApacheForge)
Why not start it yourself and anyone can suggest changes. On the other hand, why not start it myself. Something like this: 1.- Introduction Who we are, why are we doing this. 2.- Project proposal Proposal stage, committers needed, community. 3.- Code organization and repositories Naming of packages, repositories, what to find in them. Who touches what. 4.- Code quality Add copyright notice, add authors. Format your code but not others'. 4.- Build system Use Ant, use Ant, use Ant. Use Gump. Use Scarab. 5.- Dependencies What jar's to use and what to avoid. 6.- Documentation Where to look for it. What to expect, what not to expect. 7.- Support Whom you should ask, what you should figure out yourself. 8.- Licensing and guarantee Why you should use Apache license, and what's wrong with other licenses. What you can do with Apache products. Giving credit. All that implied warranty things. Un saludo, Alex. -Mensaje original- De: Paul Hammant [mailto:[EMAIL PROTECTED]] Enviado el: miércoles 20 de febrero de 2002 18:51 Para: Jakarta General List Asunto: Apache Manual (was ApacheForge) Jon, Give us a TOC for what you think might be a good starting point. That said, I will do my best to support someone who wants to create a manual like that. If you hang around here and watch what happens and how people do things and start to document it. Then I promise to review it and comment on it. - Paul -- 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!
Hi Stefano, -Mensaje original- De: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] [...] 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. And you will be a tinkerer, able to create a non-commercial bare-bones application in two seconds. For more, you will have to pay Microsoft. This implementation is intended to meet the needs of academics, researchers, curious tinkerers, and those who wish to build independent versions of the proposed ECMA standards. Courtesy of Sam Ruby: http://www.microsoft.com/partner/products/microsoftnet/SharedSourceCsharpCLI FAQ.asp The Microsoft .NET Framework and its accompanying C# compiler are a commercial product, and have features not found in the ECMA working drafts. [...] The source code to the .NET Framework will be available under Microsoft's Shared Source Licensing Framework-see http://www.microsoft.com/sharedsource for more details. Is that acceptable for an Apache developer? Un saludo, Alex.
RE: Jakarta PMC Nomination - Rejection
Hola Santiago! -Mensaje original- De: Santiago Gala [mailto:[EMAIL PROTECTED]] P.S.: (This holds for any Apache Committer coming to Madrid. I feel quite isolated here). Hey, perhaps there are no Apache Committers in Madrid, but there are surely lots of Apache users! :) Un saludo, Alex.
RE: [OT] RE: J2EE considered harmful
Hi Tim! This is good news indeed: someone took the time to actually read a message and respond to it, instead of sending 100's of nonsensical one-liners ;) Answer inline. -Mensaje original- De: Tim Hyde [mailto:[EMAIL PROTECTED]] Hi Alex, You ask why I think it's important to distinguish between the characteristics of a remote call and a local one. One of the nicest things on this topic I found is a paper from Sun themselves - http://research.sun.com/technical-reports/1994/sml1_tr-94-29.pdf Having just browsed over the document, it seems a bit (quite logically) out of date. Nowadays, if you are running a web application, your users are used to big delays and latencies, and so putting up with a few more milliseconds will not bother them. From the date, I would think that Sun were in the initial stages of thinking about how to do remote calls in java, and RMI was probably in the gestation stage (anyone knowing the dates of all that better, please correct me !). And I imagine that this paper, which is about the characteristics of distributed computing, and which makes a case for *not* trying to make remote calls transparent, was on the losing side of the argument. My suspicion is that it was marketing thinking that actually pushed the remote model to where it is today. As a matter of fact, NeXT had been doing remote proxies for a few years: NeXT Computer, Inc. NeXTSTEP Object-Oriented Programming and the Objective C Language, Release 3. Reading, Mass: Addison-Wesley, 1993. The remote model was moving at full speed at the time. It's a while since I read the paper, and I remember feeling it didn't go quite far enough: my own thoughts are that when you ask a remote machine to do something, you don't necessarily want to suspend your thread till it completes, and when the remote machine responds, it doesn't necessarily want to have completed all the work involved in your request, nor does it want to be restricted to responding just once, or with only a single value. And it might want to queue your request up if it's busy. And if it doesn't have the resources it needs to do what you asked, it might want to tell you about different situations in different ways, without wanting to throw an Exception. Sort of subtler than a local call. Most of this can be done if you use asynchronous messaging wisely, and do synchronous calls only when necessary -- appropriate. You can either expect just one result or a number of them; and you may require an answer immediately or not. The mechanics of remote communication might be something like this: 1 immediate answer: sync 1 delayed answer: async n immediate answers: async n delayed answers: async Of course, asynchronous messaging introduces a host of new problems, but they should be easier to deal with than having to code remote calls by hand. If you wanted that kind of subtlety locally, you'd at least be able to widen the interface with some shared memory/shared object communication or even cheap additional calls. Remotely, every communication is expensive. My book says: first make it work, then make it easy, finally make it cheap. Having the ability for free-running intelligent applications to communicate by sending messages was always a simple and powerful technique in many of the inter-machine situations I've programmed (long before the WWW or CORBA or RMI was around), and RPC feels like a completely unjustified restriction. I take it that by RPC you mean the request-response thing? And I'd suspect the OMG as the hidden source of a lot of the twisted thinking that forced it on us ... a dream, that many bought into, that 'Objects' were the answer to everything, and a theory that the only thing you can do to an object is invoke it, and another theory that the object inside a program is the same as an object in another continent, and they should all look the same and etcetera etcetera. On the surface, they all look like reasonable ideas. Well, everything's an object, isn't it ? Kiss my object ! I seem to detect some hostility in this last part :) - Tim Un saludo, Alex.
RE: [OT] J2EE considered harmful
Excuse me, but Paul answered the exact opposite of what you meant. AltRMI is intended to make the whole remote call transparent, while you said: From Paulo Gaspar: Your app will always be more robust if you do NOT ignore the specific issues of a remote call. Not that it matters much; I just wanted to ask you why you think your app is more robust if you have to handle specific remote exceptions. The world seems to be spinning the other way (as in GLUE, AltRMI). Un saludo, Alex. -Mensaje original- De: Paulo Gaspar [mailto:[EMAIL PROTECTED]] Enviado el: viernes 1 de febrero de 2002 14:20 Para: Jakarta General List Asunto: RE: [OT] J2EE considered harmful Paul just answered to what I meant in a better way than I would be able to do. BTW Paul, you know JAspect and Dynamic Proxies don't you? Have fun, Paulo Gaspar -Original Message- From: Paul Hammant [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 12:44 PM To: Jakarta General List Subject: Re: [OT] J2EE considered harmful Alex, My experience is that people either immediately decide they like AltRMI or strongly dislike it. One of my strongest critics (in commons mail list) is coming round to it after much effort :-) For many it is inline with something they have felt for ages : Remote interface and RemoteException suck. Many other are quite happy with RMI as is and always have been. AltRMI is really about remote publishing an object via it's normal Java interfaces. It also has local publishing capabilities for complex classloader situations. I do not agree with that. More robust how? You can set retry policies. In the middle of a method invocation and unknown to the caller, the connection can be reestablished. It is a programmable API in that the developer can choose between the two extremes never retry, log fail imediately and retry eternally. If you want to signal that something can go wrong on the remote side, throw an exception; if you want to signal that the remote connection does not work, then delay the call and/or send a runtime exception. Or a derivative (AltrmiInvocationException). You can catch it or not. In the case of 'not' I'd hope the container/handler knows what to do with it . Otherwise, what is the purpose of AltRMI? I thought it was to avoid the cumbersomeness of throwing RemoteException all the time. It is. I've started a project Enterprise Object Broker at Sourceforge to try out the use of AltRMI. - http://eob.sourceforge.net/ It is Apache license, and if it is any good and has built a community, I think Jakarta would be its natural home. - Paul H -- 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: J2EE considered harmful
Hi Jeff, -Mensaje original- De: Jeff Schnitzer [mailto:[EMAIL PROTECTED]] [...] I've been giving a lot of thought to distributed object models lately. I've worked with DCOM, CORBA, RMI, and EJB, and for the most part it's a lot of the same. Since networks are getting so fast these days, I'm starting to really wonder what it would be like to have a model in which: * All objects are inherently remotable. * Objects transparently migrate for efficiency. Welcome to the wonderful world of Mobile Agents. They suck. In our experience, the security concerns far outweigh the advantages of mobility. Anyways, that migration is only efficient in conditions of: - limited processing power. Instead of making computations on a PDA, you shift the agent to your server, perform the computations and then return with the results. This sci-fi scenario is a bit absurd, since you can just call a service that performs the same computations. - limited bandwidth. You shift the agent to the machine that is nearer to e.g. the database, so as to minimize communications. A good design already takes care of this problem, and nowadays, bandwidth is much cheaper than it used to be. I can think of many interesting, fairly revolutionary consequences of such a system and I'd love to discuss them. Ultimately, if such a system ever made it out of research and into prototype, it could challenge both Java and .NET, and possibly stave off the coming hegemony of the Sun/Microsoft duopoly. (Yeah, yeah, there will always be people who enjoy working on nonvirtual machines, but they're crazy :-) You can just check out JADE, it's a nice LGPL platform for mobile agents that can be programmed in JESS or Java. IMHO, not worth the trouble. Does anyone think some variant of this idea to be worth pursuing? Or is everyone wedded to the idea of working on the proprietary Sun platform known as Java? It's not 'with me or against me'. We can dislike J2EE, but not necessarily be keen on building a J2EE replacement. Un saludo, Alex.
[OT] RE: J2EE considered harmful
Hi Tim. I agree with your point of view, we've been trying to avoid EJBs as much as possible. But there's one thing I don't understand. -Mensaje original- De: Tim Hyde [mailto:[EMAIL PROTECTED]] Yes, EJB is a complete bodge of a design, and RPC invocation techniques would only be acceptable if they were completely transparent, instead of requiring you to do so much plumbing yourself. But personally, I think RPC is entirely overrated, and it is a mistake to try to program as though a remote call had the same characteristics as a local one. Why is it a mistake? I think a remote proxy is a great way to make remote calls, shielding the developer from the complexity of it all. The recent discussion about AltRMI has shown that there's a lot of interest in using proxies, but it was Sun's implementation (the Remote* stuff) that was flawed. Un saludo, Alex.
RE: Another Comment for Apache.org
See what you got with your flame fest? Now Frans has started making jokes! I must agree with Jon, this mail does not make much sense. But then, who cares. Alex. -Mensaje original- De: Frans Thamura [mailto:[EMAIL PROTECTED]] Enviado el: miércoles 12 de diciembre de 2001 18:21 Para: Jakarta General List Asunto: Another Comment for Apache.org The best place to post a question like this is ..., where there are more people to help you. I like this,, very wise sentence... When we help each other, we will smarter, and life will be enjoyable.. I discussed this with my friend, if the and idiot (not a dummies, remember the for dummies book), can contribute a good code to a project..what happen in the future of this book.. Who will kick Bill's ass, you as a commiter or that idiot people..? Sorry this is only a joke.. I join the mailing list, in last 2 years, just for add friendship, and i think i like this.. but sorry for my brain, may be i am not talent like all of you Jons.. But, if you life in my country (a specialist cannot life here), as a technical, you will understand it..haha.. but life will go on my friends. Frans _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Database Persistence Layer new project - Azeitona
Hi Edson, Jakarta already has a persistence layer to use with databases, called Torque: http://jakarta.apache.org/turbine/torque/index.html While I personally haven't used it yet, and it's arguably not based on Design Partner, it seems to be fine enogh. If your friend wants to propose her project anyway, please direct her to http://jakarta.apache.org/site/newproject.html where she will learn the requisites. Un saludo, Alex Fernández -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: viernes 7 de diciembre de 2001 17:05 Para: [EMAIL PROTECTED] Asunto: Database Persistence Layer new project - Azeitona Hello folks, a friend my just created a persistence layer to use with databases and he´d like to add this library to Apache, are there people that woul like to improve this library, remember that he based on Design Partner. I known that this kind of products is very expensive and is very difficult to find a open source Persistence Layer. With best wishes, Edson Alves Pereira -- /// Better well done than well said. --//-- To follow the path: look to the master, follow the master, walk with the master, see through the master, become the master. Modern Zen poem /// __ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [OT] Microsoft Sets Tolls for .Net Developers
Title: RE: [OT] Microsoft Sets Tolls for .Net Developers I don't understand the business model behind .NET. The article mentions developers paying to develop and deploy services, but also users paying to use them. Paying for an online agenda? document storage? e-wallet? This looks like the e-commerce flop on steroids. Un saludo, Alex. -Mensaje original- De: Jon Stevens [mailto:[EMAIL PROTECTED]] Enviado el: miércoles 24 de octubre de 2001 23:41 Para: [EMAIL PROTECTED] Asunto: [OT] Microsoft Sets Tolls for .Net Developers Why am I not surprised? The funny thing is that even in this down economy and with all the free (better?) alternatives that are out there, people will actually still pay for this stuff! We should put a paypal link on the Jakarta homepage and donate the money to AIDS research or some other worthy cause. -jon -- Forwarded Message Link: http://slashdot.org/article.pl?sid=01/10/24/010249 Posted by: michael, on 2001-10-24 11:40:44 Topic: ms, 153 comments from the firstborn-son-comes-later dept. matsh writes: Today Microsoft [1]revealed the cost of signing up as a developer to .Net. Entry level is $1,000. Standard level $10,000. Custom support will cost even more. References 1. http://news.cnet.com/news/0-1003-200-7629784.html -- End of Forwarded Message - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ASPizer
Title: RE: ASPizer Hi Paul! -Mensaje original- De: Paul Ilechko [mailto:[EMAIL PROTECTED]] Enviado el: jueves 18 de octubre de 2001 0:43 Para: [EMAIL PROTECTED] Asunto: RE: ASPizer How can you commit to backing a project over the long term if your company can't get funding? When your company goes out of business, what interest will you have in developing this project over the long term? We have a viable consulting company, and we make money. The product development is something we have done when we see a need in the market, but we have no reliance on income from it. We had hoped to sell ASPizer through a partnership with a major software company, but that fell through. At this point, we don't feel that we can afford to hire a software sales staff and build a software company around it. As a result of this, we are interested in building a market through open source. We can afford to maintain a certain level of development on this product, and are willing to do so. I'm not sure how you expect us to prove that, though. IMHO, the commitment from your company is not enough. The company might go under, or shift strategy, or find the product no longer useful. That would leave the product effectively orphaned, in Jakarta land but with nobody willing to support it. However, a commitment from the developers of the project themselves might be much more reassuring. How come you haven't put the source code out there under an OSS license yet so that we can look at it before we decide to begin to even consider it? Sorry, but I'm pretty new to the whole open source approach. We can look into other options and see what the best way to do this is. We're not looking to dump something on anyone. Un saludo, Alex.
