Re: Commons Validator Packaging/Content
On Tue, 8 Jan 2002 03:03, Jon Scott Stevens wrote: In this email, all I hear you doing is pointing fingers. It has nothing to do with that. I keep hearing you and other people say jakarta is broken. However as far as I can tell it is just talk whenever someone steps on your toes. You don't really care when other peoples toes get stepped on or when you do th stepping. So how can really expect anyone to care about your issues? As for me fixing Jakarta...I'm not sure I have enough people interested in helping fixing Jakarta. For example, Sam (our current leader) and others see nothing wrong with the current process. I'm also not certain I have enough energy to fight anymore...especially now that we have so many people willing to give their $0.00 opinion and not back that up with action. Honestly, I'm considering leaving entirely...or at least doing what I see everyone else doing...putting their head in a hole and just doing whatever the fuck they want to do. Not helpful, but like all of you, I don't have time either. The failure of Jakarta will be in the reality that no one has the time or energy to keep it running. It really doesn't take much energy or effort. It takes a few minor compromises by people like yourself. Re: build.xml format again - it was your insistence that your way is right and screw everyone else who conflicted with you that led me to not bother pursuig it. If jakarta is failing it is because of people like you who are unwilling to compromise. When I see you change your attitude to match your words then I will be interested, till then I just see you whining when someone does to you, what you do to other projects. Anyways personally I have watched this change occur. I would prefer that Jakarta conformed to your vision but I don't think it will. So instead of seeing it as a failure I prefer to see it a sa different version of success ;) -- Cheers, Pete --- Murphy's law - Anything that can go wrong, will. (Actually, this is Finagle's law, which in itself shows that Finagle was right.) --- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons Validator Packaging/Content
On Tue, 8 Jan 2002 12:36, Ceki Gülcü wrote: The JBoss guys are very smart. Scott Stark is extremely high caliber. Mark is no idiot either. Jboss is successful because it is so fucking good. From where I stand, the other appservers are just copying JBoss. Where do you think the MBean architecture in Weblogic 6.x came from? What a laff! JBoss and Weblogics MBean use is completely and utterly different - JBoss uses JMX as a services architecture while Weblogic uses JMX as a management interface (you know - what it was designed for). The only way that BEA could possibly decide to use the standard management interface to manage its server is to see JMX used in a completely different manner - I am not sure how I missed that. It really is innovative how BEA decided to use the standard management API when it built its management interface. They had no idea that JMX was going to be integrated into J2EE at that stage - how could they. The problem with JBoss is that while they innovate BEA and IBM make all the dough. Such is the nature of opensource. Bloody fucking hell! gotta love experts. -- Cheers, Pete --- Therefore it can be said that victorious warriors win first, and then go to battle, while defeated warriors go to battle first, and then seek to win. - Sun Tzu, the Art Of War --- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons Validator Packaging/Content
On Tue, 8 Jan 2002 01:40, Sam Ruby wrote: Peter Donald wrote: So are you proposing to become a log4j committer? Would there be a point to that? It depends on whether and how you want to contribute. There still is a lot of work to do. Ceki And theres the rub. These one (or two) line answers don't do much to illuminate the issues. Let me try to rectify this: actually thats not the point I was trying to get across (but an interesting one none the less). The point I was trying to get across was about Cekis attitude is precisely why Jakarta is the way it is and why it is going to only get worse. He has no problem with me working for Log4j but the idea of actual collaboration is foreign. Now wouldn't it have been more interesting if he had said lets get together and collaborate on Log4j v2 as you suggest or even just sharing the common infrstructure. However he didn't. He wants me to work on his project. I wonder if Jon asked Craig to work on turbine whether he would accept? hm I wonder. Ceki, fundamental to Avalon is a design pattern that is referred to as Inversion of Control. This is fairly concisely described at the following web page: http://jakarta.apache.org/avalon/framework/inversion-of-control.html , including an example which maps this concept into exactly this domain. IOC is not really the stop gap - Log4j could easily layered over the top of LogKit with very few issues. Can you conceive of any possibility where you and Peter could work together on a log4j v2.0 which conforms to what amounts to a set of restrictions on what a component can do? Your answer above indicates that you have preconceived notions as to how you would limit Peter's freedom to participate. Care to elaborate? This is what I initially proposed to Ceki after it became obvious he was not willing to enable what we needed. This was a few months before he even came to Apache IIRC and I sent him at least 3 different proposals on how to integrate our work - though I believe he claims he only received 2. However at no stage did he even bother to acknowledge the proposals. I would be very surprised if Ceki was willing to work with anyone else though I could be surprised .. I suspect the answer is no though ;) Peter, as you are well aware, I'm not overly thrilled with the way that Avalon has participated in commons either. I weren't aware we were participating ? ;) I have been unable to locate an adequate archive to point to, but recently I felt compelled recently (2001-12-26) to write the following words: There are quite a few projects under the Apache umbrella that I see as simultaneously unwilling to depend on others, and puzzled that more people are not willing to depend on them. And if you recall I agreed with you in a reply ... or at least I seem to recall doing so ;) To drive this point home, the subject line of this thread identifies exactly one such set of duplication - between Turbine and Struts. My nagging lead Berin to propose moving the Avalon collections code into commons, to which you responded, and I quote, +/- 0. I was hoping Jeff would do it as he seemed to be involved over there ;) I have no time atm and no real motiviation to do it. Last time I was on the list I watched 3 things be proposed to commons - nobody even voted !!! There was no response whatsoever. Apparently Jeff has similar comments when he offered some of the avalon bits over there. I m not willing to do the work for some simple reasons * I don't like the management style (see below) * I am lazy and don't like creating more work for myself (bet you knew that already though) * I no longer care about duplication and wheel reinvention (it will happen anyway) You can say all you want that you predicted how commons would turn out - but lack of participation by people such as yourself have made such predictions self fulfilling prophesies. Heres what sucks about commons; 1. People who are not associated with codebase nor ever contributed to it get voting rights over codebase (who needs meritocracy anyways) 2. Stable packages still have to go via sandbox and go through that whole painful voting process (yet more non-contributors getting votes over codebase) 3. Im not a committer Change (1) and I will migrate the majority of excaalibur across in time (and bitch and moan till (2)/(3) is changed). Change (1), (2) and (3) and I will move stuff across tomorrow (though still take time to actually do releases). -- Cheers, Pete --- Remember, your body is a temple; however, it's also your dancehall and bowling alley -- Dharma Montgomery --- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Commons Validator Packaging/Content
Paulo Gaspar wrote: I do what I can at the pace I am able. Which is quite impressive. Especially considering that you probably have other duties and a live. Thanks. And I do have both. http://www.activestate.com/Corporate/People/Tech_Board.html#sam http://www.zend.com/zend/hof/sam.php - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Commons Validator Packaging/Content
Turbine and Avalon serve very distinct purposes, uses and users. They just have a load of components trying to do the same thing. Those could be shared and unified by placing them in the commons. Have fun, Paulo Gaspar -Original Message- From: Peter Donald [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 08, 2002 12:13 PM On Tue, 8 Jan 2002 03:04, Jon Scott Stevens wrote: on 1/7/02 2:45 AM, Peter Donald [EMAIL PROTECTED] wrote: On Mon, 7 Jan 2002 21:33, Ceki Gulcu wrote: Peter, So are you proposing to become a log4j committer? Would there be a point to that? sarcasm Exactly. Collaboration on a single logging tool would be a terrible idea. /sarcasm so would collaboration on a web framework -- Cheers, Pete - Clarke's Third Law: Any technology distinguishable from magic is insufficiently advanced. - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Avalon, Commons, once again (Re: Commons Validator Packaging/Content)
Ted Husted wrote: As it stands, both are simply subprojects, and so a Commons committer is a Commons committer. Ditto for Taglibs. It is also fair to point out that an Avalon committer is a committer to the framework itself as well as to testlet, logkit, phoenix, cornerstone, excalibur, and site. So, one could draw a conclusion that anybody who choses not to participate in Commons due to this structure would also chose to withdraw from Avalon until this is corrected. In a way, the Commons and Taglibs subproject represent the other approach to Jakarta that people sometimes advocate, but so far a strong leader has not stepped up to fulfill the other half of that model. I have quietly stated several times that I would prefer that a Jakarta committer is a Jakarta committer. Gaging by the response I got each time, I figured that then was not the time to push the issue. - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons Validator Packaging/Content
on 1/8/02 3:13 AM, Peter Donald [EMAIL PROTECTED] wrote: so would collaboration on a web framework Pete This happened a long time ago (May 2000) on the PMC list: When Craig originally proposed Struts, I -1'd it. He assured me that he would be willing to collaborate together on Turbine and Struts (see the Third point below), so I changed to a +1 based on that point alone (there is another message where I made that clear). Needless to say, Craig lied. So, don't give me anymore shit Peter. I'm tired of it. -jon -- Forwarded Message From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Tue, 30 May 2000 12:45:17 -0700 To: [EMAIL PROTECTED] Subject: Re: [PROPOSAL/VOTE] New Jakarta Subproject - Struts Jon Stevens wrote: on 5/30/2000 11:19 AM, Craig R. McClanahan at [EMAIL PROTECTED] wrote: Adding JSP-related stuff into Turbine is also a good idea; it's just not on my list of interesting things to work on. Craig Why not just add Struts into Turbine? In my mind, there are several issues: First, (somewhat paradoxically), is the fact that Turbine does so much for you. It's comprehensive nature, like any good framework, makes it correspondingingly tough to get your hands around. Struts focuses on the MVC architecture (slightly different approach than Action Events but the same basic idea) plus the use of some JSP custom tags that interact with the action classes in synergistic ways. One of the ways to view Turbine is this is what you graduate to, once you understand what an MVC-architectured web application looks like. Second, some of the functionality supported by Turbine is done in ways that differ from the emerging J2EE standards (for example, connection pools). Granted, you got there first -- but some of the people who want to build MVC-based web applications will be doing so with a J2EE server as the target platform, so they will need to utilize the J2EE approach to things like this where such an approach exists. This is a philosophy issue for Turbine in general -- do you want to blaze your own trail in how services are provided, or do you want to become more J2EE-like? (I don't have the personal energy or passion needed to productively participate in this discussion -- that's for the people who really care about Turbine to decide.) Third, it is a little early to think that anyone (including myself) has a clear handle on what the optimum integration of JSP into a full-featured application framework like Turbine should look like. One of the ways to view Struts is an incubator for exploring how to do Model 2 apps, using JSPs and custom tags, in an optimum way. Once the pattern is clear, it will be lots easier to integrate the final result into Turbine, rather than doing the integration over and over again as the patterns get refined. Fourth, over the last year or so on JSP-INTEREST a considerable amount of discussion has taken place about how to do Model-2 based app designs, using the fundamental patterns that are implemented in Struts (similar but different to corresponding things in Turbine). Large numbers of people have asked for a working example because they are new to the whole concept of writing web apps (to say nothing of the implications of writing code that works in a multithreaded server environment :-) -- I wish to meet that need without making them have to learn too much at once. Finally, longer term, I would not be at all surprised to see the two approaches merged. That just doesn't help meet a short term need to publish code so that I can stop describing the pattern over and over again in words on the mailing lists. A hyperlink to a download is much more concise and easier to type :-). -jon Craig -- End of Forwarded Message -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Avalon, Commons, once again (Re: Commons Validator Packaging/Content)
On Tue, Jan 08, 2002 at 09:29:18PM +1100, Peter Donald wrote: ... To drive this point home, the subject line of this thread identifies exactly one such set of duplication - between Turbine and Struts. My nagging lead Berin to propose moving the Avalon collections code into commons, to which you responded, and I quote, +/- 0. I was hoping Jeff would do it as he seemed to be involved over there ;) I saw the +/- 0, and that Berin hadn't voted, and then thought of how this would look to Commons people: as a code dump; abandoned by it's authors, singlehandedly maintained by someone who might disappear at any moment (from their POV; I'm not going anywhere;). Quite a big ask. Though if you're okay with it (forking is a bit.. impolite:), I'll make an attempt sometime late Feb (after holidays.. wheee). I have no time atm and no real motiviation to do it. Last time I was on the list I watched 3 things be proposed to commons - nobody even voted !!! There was no response whatsoever. Apparently Jeff has similar comments when he offered some of the avalon bits over there. 'twasn't Avalon code, but yes.. it pains me to think of all those XML doctype decls flying around, unchanged.. ;) The lack of project-wide sense of responsibility is the biggest problem for Commons (and jakarta-taglibs, incidentally). It's something I aim to help solve the old-fashioned way. * I no longer care about duplication and wheel reinvention (it will happen anyway) Yep, to a degree. Though without a simultaneous commitment to document the resulting forks/duplications and preferably cull the old code, then Jon's worst predictions will come true and we can kiss Jakarta goodbye now. You can say all you want that you predicted how commons would turn out - but lack of participation by people such as yourself have made such predictions self fulfilling prophesies. Heres what sucks about commons; 1. People who are not associated with codebase nor ever contributed to it get voting rights over codebase (who needs meritocracy anyways) Has that turned out to be a problem in practice? Say if you think so, and we can propose a modification to the charter: The votes of those who haven't committed to a project are non-binding. 2. Stable packages still have to go via sandbox and go through that whole painful voting process (yet more non-contributors getting votes over codebase) 3. Im not a committer You are. 'donaldp' listed for jakarta-commons and jakarta-commons-sandbox. --Jeff Change (1) and I will migrate the majority of excaalibur across in time (and bitch and moan till (2)/(3) is changed). Change (1), (2) and (3) and I will move stuff across tomorrow (though still take time to actually do releases). -- Cheers, Pete --- Remember, your body is a temple; however, it's also your dancehall and bowling alley -- Dharma Montgomery --- -- 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: Commons Validator Packaging/Content
On Tue, Jan 08, 2002 at 10:48:42AM -, Danny Angus wrote: Jon wrote: My opinion is that there are to many peers in the process and that is what is breaking Jakarta. This wasn't a problem until now. We are starting to explode under our own ever growing weight. I've been involved in other organisations that tried, from best intentions, to have a non hierarchical structure. ... This is a meritocracy. In some projects, the 'merit slope' is so steep you could ski down it :) Don't let the lack of obvious hierarchy blind you to the very strong internal hierarchy. Even if people are cheeky to Jon, they know where on the slope he sits ;) --Jeff d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons Validator Packaging/Content
Sam, You are right stop creating new projects does not solve the Validator problem. However, stopping the creation of new projects might have long term effects. The effect might be increased collaboration or alternatively everyone leaving. It is a dangerous/stupid/daring (pick your choice) rule indeed. Regards, Ceki --- Sam Ruby [EMAIL PROTECTED] wrote: Ceki Gülcü wrote: Jon, I share precisely the same concerns. Thank you for standing up on this issue. What do you suggest we do? I mean concretely. My first suggestion would be to stop creating new projects, starting *today*. If someone wants to contribute code, they do that within the framework of an *existing* project. If that is not possible, then they do it somewhere else. Regards, Ceki Come again? Recap: David Winterfeldt innocently began moving code from an existing subproject that he is a committer to (struts) to the commons (another existing subproject), unaware that Intake existed inside Turbine (a subproject that he is not a committer to). Validator has been a part of Struts for over a year, and has been independent of Struts for six months. David became an Apache committer in September. How does your proposed solution, i.e., stop creating new projects solve this problem? - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons Validator Packaging/Content
On Mon, 7 Jan 2002 09:15, Jon Scott Stevens wrote: Of course it is easier to start from scratch to invent yet another validation framework. This is where I see another failure of Jakarta. People only go with the easiest route without any concern about the long term mess they are making. Thats because thats what the PMC encourages (you included). If you recall at one stage LogKit was proposed as a jakarta project - before Log4j was present but the PMC decided to bring Log4j to jakarta instead. When commons was started it was because Avalon did not have the right advertising. Both of these things were a vote by the PMC to reinvent rather than reuse. The best way to describe it was something I think Craig said, something like - it doesn't much matter if there is an existing project with same aims, what matters is what committers are willing to commit to. It is much more sexier to rewrite something from scratch than it is to work with other peoples code. Why is struts a project? Wouldn't it have been more productive to the Apache community overall to live side-by-side with turbine (same mailing lists and project etc). Essentially struts would have been a complete revolution - having them together would have ensured a much higher level of cross pollination. Why is Log4j at jakarta? Wouldn't be better if it and LogKit were merged? What about the regex engines? I feel like Jakarta is just going down this path of having a bazillion different implementations and versions of the same thing and it is only getting worse. It is going to get far far far worse - everyone encourages it from the PMC down. Reinvent rather than reuse or so the chant goes. Commons was supposed to help clean that up by providing a central location, however all I see is it making it worse because people are just re-inventing what already exists in other projects instead of using existing projects as the basis. Correct. Commons is also fun because people not involved with the code have voting rights over it. However I do recall you +1'ed it even when I said it would end up like this ;) I'm starting to realize that Jakarta has grown to becoming a place where people only scratch their own itches and I agree that that is the basis for open source. However, we have no overall direction. We all have our own opinions and spend days and days discussing them and when it comes down to putting code into CVS, people do whatever they want anyway because there is no set of checks and balances to put some sort of higher level control over things. Thats because people don't want it. More than half the people at jakarta are egomaniacs. Not that this is a bad thing - it can be very productive but very few people want to work together because they can get more glory doing it themselves. People keep saying that Jakarta isn't broken. Well, if it isn't broken, then how come we have so many people doing their own thing and not working together? Jakarta is supposed to be a group collective, however it is becoming nothing more than another Sourceforge. If thats what you consider broken then it is broken and it is going to get much more broken. The only way to change this is to to vote it. Next time someone raises a vote to duplicate an existing project don't +1 it. And don't just complain when someone duplicates a part of turbine. I would to love to see more working together but I can't see it happening. People are not willing to work together - even for basic things. When I asked you to change turbines build system to not conflict with patterns in other projects your response was something along the lines. We used ant first, this is how you should do it, you are wrong - and thats basically when I stopped trying to get people to have standard build file format. You say you want to fix jakarta then prove it - lets start working together to get even the basic infrastructure common where they interface with other projects. So the ball is in your court now ;) BTW turbine is/has uploaded components to commons that are duplicates of Avalon functionality. ie the exact same thing that happened with validators except that turbine is the purp rather than the victim - so should I wail at you now ? ;) -- Cheers, Pete -- Science is like sex: sometimes something useful comes out, but that is not the reason we are doing it -- Richard Feynman -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons Validator Packaging/Content
Peter, So are you proposing to become a log4j committer? Regards, Ceki --- Peter Donald [EMAIL PROTECTED] wrote: On Mon, 7 Jan 2002 09:15, Jon Scott Stevens wrote: Of course it is easier to start from scratch to invent yet another validation framework. This is where I see another failure of Jakarta. People only go with the easiest route without any concern about the long term mess they are making. Thats because thats what the PMC encourages (you included). If you recall at one stage LogKit was proposed as a jakarta project - before Log4j was present but the PMC decided to bring Log4j to jakarta instead. When commons was started it was because Avalon did not have the right advertising. Both of these things were a vote by the PMC to reinvent rather than reuse. The best way to describe it was something I think Craig said, something like - it doesn't much matter if there is an existing project with same aims, what matters is what committers are willing to commit to. It is much more sexier to rewrite something from scratch than it is to work with other peoples code. Why is struts a project? Wouldn't it have been more productive to the Apache community overall to live side-by-side with turbine (same mailing lists and project etc). Essentially struts would have been a complete revolution - having them together would have ensured a much higher level of cross pollination. Why is Log4j at jakarta? Wouldn't be better if it and LogKit were merged? What about the regex engines? I feel like Jakarta is just going down this path of having a bazillion different implementations and versions of the same thing and it is only getting worse. It is going to get far far far worse - everyone encourages it from the PMC down. Reinvent rather than reuse or so the chant goes. Commons was supposed to help clean that up by providing a central location, however all I see is it making it worse because people are just re-inventing what already exists in other projects instead of using existing projects as the basis. Correct. Commons is also fun because people not involved with the code have voting rights over it. However I do recall you +1'ed it even when I said it would end up like this ;) I'm starting to realize that Jakarta has grown to becoming a place where people only scratch their own itches and I agree that that is the basis for open source. However, we have no overall direction. We all have our own opinions and spend days and days discussing them and when it comes down to putting code into CVS, people do whatever they want anyway because there is no set of checks and balances to put some sort of higher level control over things. Thats because people don't want it. More than half the people at jakarta are egomaniacs. Not that this is a bad thing - it can be very productive but very few people want to work together because they can get more glory doing it themselves. People keep saying that Jakarta isn't broken. Well, if it isn't broken, then how come we have so many people doing their own thing and not working together? Jakarta is supposed to be a group collective, however it is becoming nothing more than another Sourceforge. If thats what you consider broken then it is broken and it is going to get much more broken. The only way to change this is to to vote it. Next time someone raises a vote to duplicate an existing project don't +1 it. And don't just complain when someone duplicates a part of turbine. I would to love to see more working together but I can't see it happening. People are not willing to work together - even for basic things. When I asked you to change turbines build system to not conflict with patterns in other projects your response was something along the lines. We used ant first, this is how you should do it, you are wrong - and thats basically when I stopped trying to get people to have standard build file format. You say you want to fix jakarta then prove it - lets start working together to get even the basic infrastructure common where they interface with other projects. So the ball is in your court now ;) BTW turbine is/has uploaded components to commons that are duplicates of Avalon functionality. ie the exact same thing that happened with validators except that turbine is the purp rather than the victim - so should I wail at you now ? ;) -- Cheers, Pete -- Science is like sex: sometimes something useful comes out, but that is not the reason we are doing it -- Richard Feynman -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] = - Ceki - http://qos.ch
RE: Commons Validator Packaging/Content
I would still prefer having both around. There are users and committers for each that are not willing to move to the other. IMO, community rules. Have fun, Paulo Gaspar -Original Message- From: Peter Donald [mailto:[EMAIL PROTECTED]] Sent: Monday, January 07, 2002 11:45 AM To: Jakarta General List Subject: Re: Commons Validator Packaging/Content On Mon, 7 Jan 2002 21:33, Ceki Gulcu wrote: Peter, So are you proposing to become a log4j committer? Would there be a point to that? -- Cheers, Pete --- To fight and conquer in all your battles is not supreme excellence; supreme excellence consists in breaking the enemy's resistance without fighting. - Sun Tzu, 300 B.C. --- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons Validator Packaging/Content
On Mon, 7 Jan 2002 22:02, Ceki Gulcu wrote: --- Peter Donald [EMAIL PROTECTED] wrote: On Mon, 7 Jan 2002 21:33, Ceki Gulcu wrote: Peter, So are you proposing to become a log4j committer? Would there be a point to that? It depends on whether and how you want to contribute. There still is a lot of work to do. Ceki And theres the rub. -- Cheers, Pete --- Be nice to your friends. If it weren't for them, you'd be a complete stranger. --- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons Validator Packaging/Content
Peter Donald wrote: So are you proposing to become a log4j committer? Would there be a point to that? It depends on whether and how you want to contribute. There still is a lot of work to do. Ceki And theres the rub. These one (or two) line answers don't do much to illuminate the issues. Let me try to rectify this: Ceki, fundamental to Avalon is a design pattern that is referred to as Inversion of Control. This is fairly concisely described at the following web page: http://jakarta.apache.org/avalon/framework/inversion-of-control.html , including an example which maps this concept into exactly this domain. Can you conceive of any possibility where you and Peter could work together on a log4j v2.0 which conforms to what amounts to a set of restrictions on what a component can do? Your answer above indicates that you have preconceived notions as to how you would limit Peter's freedom to participate. Care to elaborate? Peter, as you are well aware, I'm not overly thrilled with the way that Avalon has participated in commons either. I have been unable to locate an adequate archive to point to, but recently I felt compelled recently (2001-12-26) to write the following words: There are quite a few projects under the Apache umbrella that I see as simultaneously unwilling to depend on others, and puzzled that more people are not willing to depend on them. Do I want to increase the Avalon community? Definitely! I don't see how moving Avalon code outside of Avalon increases *Avalon's* community. I can see how it increases *Commons* community. Sigh. Turbine and Struts are generally polar opposites, but at least they can share a set of collections classes. To drive this point home, the subject line of this thread identifies exactly one such set of duplication - between Turbine and Struts. My nagging lead Berin to propose moving the Avalon collections code into commons, to which you responded, and I quote, +/- 0. You can say all you want that you predicted how commons would turn out - but lack of participation by people such as yourself have made such predictions self fulfilling prophesies. - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons Validator Packaging/Content
on 1/7/02 2:45 AM, Peter Donald [EMAIL PROTECTED] wrote: On Mon, 7 Jan 2002 21:33, Ceki Gulcu wrote: Peter, So are you proposing to become a log4j committer? Would there be a point to that? sarcasm Exactly. Collaboration on a single logging tool would be a terrible idea. /sarcasm -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons Validator Packaging/Content
Jon Stevens wrote: As for me fixing Jakarta...I'm not sure I have enough people interested in helping fixing Jakarta. For example, Sam (our current leader) and others see nothing wrong with the current process. I'm also not certain I have enough energy to fight anymore...especially now that we have so many people willing to give their $0.00 opinion and not back that up with action. I certainly see things wrong with the current process, but apparently since I don't see the same issues that you do as critical, I therefore see nothing wrong. In my, admittedly biased, perspective, I see significant improvement in terms of community over the course of the past eleven months or so. For starters, the following results would have been inconceivable at the time: http://jakarta.apache.org/builds/gump/2002-01-07/ I also see an initiative by Ted and others to build a commons are which promotes reuse. Conscientious objectors notwithstanding, they plow relentlessly ahead, continuing to make incremental and enduring progress. Meanwhile, I will repeat something I said on this list three days ago: Be forewarned that the Apache tradition is to allow people with enough fire in their belly to tackle a particular problem that is important to them the freedom to do so. If the problems you see are something that you feel need tackling and the only effective way in which this can be accomplished is for you to become the Jakarta PMC chair, then I could certainly arrange for an election to take place. I can't guarantee the results of the election or the success of your quest, but I can do my part to enable you to pursue your goals. Think about this for a while, and let me know if this is a path you wish to pursue. - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons Validator Packaging/Content
on 1/7/02 8:55 AM, Sam Ruby [EMAIL PROTECTED] wrote: Be forewarned that the Apache tradition is to allow people with enough fire in their belly to tackle a particular problem that is important to them the freedom to do so. If the problems you see are something that you feel need tackling and the only effective way in which this can be accomplished is for you to become the Jakarta PMC chair, then I could certainly arrange for an election to take place. I can't guarantee the results of the election or the success of your quest, but I can do my part to enable you to pursue your goals. Think about this for a while, and let me know if this is a path you wish to pursue. - Sam Ruby Being PMC chair isn't going to help solve any problems because of our system of checks and balances. In other words, I don't see PMC chair being any more important or special or enabled than simply being a member of the PMC, which I already am. As I already said, I also don't think I have enough backing to: #1. Get voted into being the PMC chair. #2. Make enough of a change to help turn Jakarta around from a slow spiraling death. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Commons Validator Packaging/Content
Jon wrote: There is no community. There is projects which have people who follow them blindly. I do not believe that. What I am seeing are the same signs Sam sees: Sam wrote: In my, admittedly biased, perspective, I see significant improvement in terms of community over the course of the past eleven months or so. For starters, the following results would have been inconceivable at the time: http://jakarta.apache.org/builds/gump/2002-01-07/ I also see an initiative by Ted and others to build a commons are which promotes reuse. Conscientious objectors notwithstanding, they plow relentlessly ahead, continuing to make incremental and enduring progress. Have fun, Paulo Gaspar -Original Message- From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Sent: Monday, January 07, 2002 5:05 PM on 1/7/02 3:14 AM, Paulo Gaspar [EMAIL PROTECTED] wrote: I would still prefer having both around. There are users and committers for each that are not willing to move to the other. IMO, community rules. There is no community. There is projects which have people who follow them blindly. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Commons Validator Packaging/Content
Being PMC chair isn't going to help solve any problems because of our system of checks and balances. I just love checks and balances. It is the least perfect system except for all the others already tried. Have fun, Paulo Gaspar -Original Message- From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Sent: Monday, January 07, 2002 6:04 PM on 1/7/02 8:55 AM, Sam Ruby [EMAIL PROTECTED] wrote: Be forewarned that the Apache tradition is to allow people with enough fire in their belly to tackle a particular problem that is important to them the freedom to do so. If the problems you see are something that you feel need tackling and the only effective way in which this can be accomplished is for you to become the Jakarta PMC chair, then I could certainly arrange for an election to take place. I can't guarantee the results of the election or the success of your quest, but I can do my part to enable you to pursue your goals. Think about this for a while, and let me know if this is a path you wish to pursue. - Sam Ruby Being PMC chair isn't going to help solve any problems because of our system of checks and balances. In other words, I don't see PMC chair being any more important or special or enabled than simply being a member of the PMC, which I already am. As I already said, I also don't think I have enough backing to: #1. Get voted into being the PMC chair. #2. Make enough of a change to help turn Jakarta around from a slow spiraling death. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons Validator Packaging/Content
on 1/7/02 10:00 AM, Paulo Gaspar [EMAIL PROTECTED] wrote: What I am seeing are the same signs Sam sees: Sam wrote: In my, admittedly biased, perspective, I see significant improvement in terms of community over the course of the past eleven months or so. For starters, the following results would have been inconceivable at the time: http://jakarta.apache.org/builds/gump/2002-01-07/ I also see an initiative by Ted and others to build a commons are which promotes reuse. Conscientious objectors notwithstanding, they plow relentlessly ahead, continuing to make incremental and enduring progress. As far as I'm concerned, all Gump shows us is that projects have managed to quit breaking each others interfaces. Gump shows us that documents such as this: http://jakarta.apache.org/turbine/common/deprecation.html ...have had an effect on people's mentalities. Those are not my issues with Jakarta at this point. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons Validator Packaging/Content
Jon Stevens wrote: Being PMC chair isn't going to help solve any problems because of our system of checks and balances. In other words, I don't see PMC chair being any more important or special or enabled than simply being a member of the PMC, which I already am. Take a moment to review the second paragraph of Section 6.3 of http://www.apache.org/foundation/bylaws.html. Others in this position may choose to interpret this more liberally than I do. As I already said, I also don't think I have enough backing to: #1. Get voted into being the PMC chair. That is something that you could certainly work to change. #2. Make enough of a change to help turn Jakarta around from a slow spiraling death. I continue to see the last 11 months as a period of progress. - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons Validator Packaging/Content
On Mon, 7 Jan 2002, Sam Ruby wrote: I continue to see the last 11 months as a period of progress. +1 - Sam Ruby Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons Validator Packaging/Content
on 1/7/02 10:51 AM, Sam Ruby [EMAIL PROTECTED] wrote: Jon Scott Stevens wrote: As far as I'm concerned, all Gump shows us is that projects have managed to quit breaking each others interfaces. Gump shows us that documents such as this: http://jakarta.apache.org/turbine/common/deprecation.html ...have had an effect on people's mentalities. Those are not my issues with Jakarta at this point. My perception is the other way around. Documents like that were routinely ignored (sound familiar?) until somebody(*) took initiative to find an effective way to bring these issues to everybody's attention. I do have all of the published logs archived, and can provide copious examples to back up my belief. There were no documents like that before I wrote it. Just like there was no nag.pl before I came up with the idea to implement it. If anything, you initially resisted nag.pl. One way I know this is because as the PMC Chair, you refused make it a requirement of projects to have it enabled. Instead, you relied on social pressures to work their magic. This actually extended the amount of time it took for people to adopt Gump and raise its awareness. It also caused quite a bit of pain (as you say below) as projects had votes against it. I also see this as the path to resolving a number of related issues. For example, find or create a style checker tool. I'll gladly run it nightly against all Jakarta code bases and publish the results. And one by one convince each project that it is their best interest for me to nag them on it. Not everybody realizes it, but getting people to accept nagging on cross project dependency failures was an uphill battle. At least one subproject even had a vote on it. Exactly. I feel that this lack of semblance of control from the top has actually hurt us. Looking at the success of other projects which have more control at the top makes me realize this. Jakarta to me is now a complete anarchy where people can do whatever they want without having to worry about consequences over the long term. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons Validator Packaging/Content
Jon Stevens wrote: There were no documents like that before I wrote it. Forgive me, but I still hold to my belief that that at the time it was written, that document wasn't worth the paper it was written on. Just like there was no nag.pl before I came up with the idea to implement it. You can believe what you want. It was part of my master plan. If anything, you initially resisted nag.pl. One way I know this is because as the PMC Chair, you refused make it a requirement of projects to have it enabled. Instead, you relied on social pressures to work their magic. This actually extended the amount of time it took for people to adopt Gump and raise its awareness. It also caused quite a bit of pain (as you say below) as projects had votes against it. IIRC, your plan was to send nags on succcesses as well as failures. Re: mass conversion - I still believe that there would have been mass revolt instead. I do not have enough arms and legs to be everywhere at all times. I have deliberatedly paced the rate at which I have incorporated new codebases based on how many battles I felt that I could concurrently fight. There are quite a few code bases that took a number of iterations before the either saw the light or resigned themselves to the fact that I wasn't going to relent. Exactly. I feel that this lack of semblance of control from the top has actually hurt us. Looking at the success of other projects which have more control at the top makes me realize this. Jakarta to me is now a complete anarchy where people can do whatever they want without having to worry about consequences over the long term. I do what I can at the pace I am able. - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Commons Validator Packaging/Content
Which projects are those? Can you really compare them - and their community - with Jakarta? I just want to know more. Have fun, Paulo Gaspar -Original Message- From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Sent: Monday, January 07, 2002 8:16 PM ... Exactly. I feel that this lack of semblance of control from the top has actually hurt us. Looking at the success of other projects which have more control at the top makes me realize this. Jakarta to me is now a complete anarchy where people can do whatever they want without having to worry about consequences over the long term. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Commons Validator Packaging/Content
I do what I can at the pace I am able. Which is quite impressive. Especially considering that you probably have other duties and a live. I agree 100% with the rest (especially with the mass revolt bit). Checking mechanisms (automatic or manual) and systematic nagging look much more constructive and efficient to me than occasional bursts of flames. Have fun, Paulo Gaspar -Original Message- From: Sam Ruby [mailto:[EMAIL PROTECTED]] Sent: Monday, January 07, 2002 9:17 PM Jon Stevens wrote: There were no documents like that before I wrote it. Forgive me, but I still hold to my belief that that at the time it was written, that document wasn't worth the paper it was written on. Just like there was no nag.pl before I came up with the idea to implement it. You can believe what you want. It was part of my master plan. If anything, you initially resisted nag.pl. One way I know this is because as the PMC Chair, you refused make it a requirement of projects to have it enabled. Instead, you relied on social pressures to work their magic. This actually extended the amount of time it took for people to adopt Gump and raise its awareness. It also caused quite a bit of pain (as you say below) as projects had votes against it. IIRC, your plan was to send nags on succcesses as well as failures. Re: mass conversion - I still believe that there would have been mass revolt instead. I do not have enough arms and legs to be everywhere at all times. I have deliberatedly paced the rate at which I have incorporated new codebases based on how many battles I felt that I could concurrently fight. There are quite a few code bases that took a number of iterations before the either saw the light or resigned themselves to the fact that I wasn't going to relent. Exactly. I feel that this lack of semblance of control from the top has actually hurt us. Looking at the success of other projects which have more control at the top makes me realize this. Jakarta to me is now a complete anarchy where people can do whatever they want without having to worry about consequences over the long term. I do what I can at the pace I am able. - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons Validator Packaging/Content
on 1/7/02 4:23 PM, Paulo Gaspar [EMAIL PROTECTED] wrote: if the peers agree with this process. My opinion is that there are to many peers in the process and that is what is breaking Jakarta. This wasn't a problem until now. We are starting to explode under our own ever growing weight. Jakarta is like a beached whale. http://www.perp.com/whale/video.html -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons Validator Packaging/Content
on 1/7/02 4:26 PM, Paulo Gaspar [EMAIL PROTECTED] wrote: Which projects are those? Can you really compare them - and their community - with Jakarta? Jboss's success seems to be one project. I'm actually glad they went to sourceforge...they would have struggled to survive here... -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Commons Validator Packaging/Content
Jboss's success seems to be one project. I'm actually glad they went to sourceforge...they would have struggled to survive here... How can you know? I have studied their code and their documentation some months ago, I have also followed some of their mailling lists for sometime and that is not that obvious to me. I do NOT prefer what they call community. I do not find their code that good. I do not like their documentation that much. JBoss success has a lot to do with the lack of credible alternative for something with a lot of demand, unlike Jakarta products like Tomcat or Velocity. Give me a better case and/or concrete reasons, please. Have fun, Paulo Gaspar -Original Message- From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 08, 2002 1:25 AM on 1/7/02 4:26 PM, Paulo Gaspar [EMAIL PROTECTED] wrote: Which projects are those? Can you really compare them - and their community - with Jakarta? Jboss's success seems to be one project. I'm actually glad they went to sourceforge...they would have struggled to survive here... -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Commons Validator Packaging/Content
Answer inline, -Original Message- From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 08, 2002 2:18 AM on 1/7/02 5:18 PM, Paulo Gaspar [EMAIL PROTECTED] wrote: Jboss's success seems to be one project. I'm actually glad they went to sourceforge...they would have struggled to survive here... How can you know? I hosted their project on my servers for the first couple of years they were alive and have had a boat load of conversations with Marc. You sure seem to be well informed. =;o) I have studied their code and their documentation some months ago, I have also followed some of their mailling lists for sometime and that is not that obvious to me. I do NOT prefer what they call community. I do not find their code that good. I do not like their documentation that much. JBoss success has a lot to do with the lack of credible alternative for something with a lot of demand I think it is more than that though...they have worked to develop a community and a LOT of interest. At least that is what their website suggests. It could be a result of what you say, but Jakarta's success isn't necessarily because of our projects or our community...it is because of the Apache name behind it. I think you overvalue Apache's name on that and undervalue the quality of what is done here. I moved here less than 2 years ago and I believe my POV is more impartial about that, since I was not immersed on Jakarta since day one as you did. If you want a detail account of how a newbie arrives and stays at Apache: The fact that Apache made the famous Apache Web server did not motivate me to get an immediate adept of its Java stuff at all. I thought: So, they have Java. Having people that know how to make a Web server does not mean they know how to do anything else. Probably it is not even the same people. But since I had found Apache's Java page by accident, I decided to take a look. New to web development, JServ did not impress me at all. I wanted to use Java since Servlets and JSPs looked much better designed and easier to use than ISAPI Extensions and ASPs (yes... coming from the MS platform). Servlets looked even simpler and more powerful than using Delphi for the ISAPI extensions (I did not even consider using VC++). Since JServ looked so basic, I went on trying JRun (argh! it sure was buggy) and Sun's Java Web Server (argh! buggy and heavy and slooowww!!!). I took a look at a load of other Servlet engines. Some were way too expensive for what they were worth... or it was just not sure at all they were worth something at all. Others were too basic or fragile. Then I found out many people saying that JServ was very robust, found about Tomcat, tried both and started using JServ (and started getting into flame wars with Jon about TC 3.3 (o;= ). So I did not come here because of the Apache name, but because JServ had its own reputation for robustness and because Tomcat was almost there. (And I tested and played with Tomcat much more than with JServ to be sure of that.) It was the same with all other Java software and source code I am using. I tried to find alternatives everywhere, used Google, spent hours digging on Java publications and on source code. In the end most of what I use is Apache again. I once had a list of around 10 projects/project-families which Docs and Source I considered worth checking with some detail after a lot of pre-selection work (which already included taking a look at bits of code and reading a lot of docs). Among these project families were big monsters like JBoss, Exolab, Locomotive, etc. I even subscribed most JBoss lists and some from Exolab. In terms of the source code I adapted, everything I ended up using was Apache. Only recently did I integrate a couple of other classes. Only one non-Apache project taught me something really meaningful that I really used. (I learned a lot other stuff, of course. But I am not using it - most of it is JNDI and otherwise J2EE related.) In terms of libraries, lets take a look at my lib directory... Sun Java APIs, JDBC drivers, a couple of scripting engines (I recommend Pnuts - damn fast) and Apache stuff again! A Search Engine and a Logging API used in my company ended up coming to Apache - Log4J and Lucene. btw-ot-remark I currently use LogKit in my stuff, wrapped by (an adapted) Avalon's common logging interface. One size does not fit all and, unless one of them changes a lot, I would rather have both. /btw-ot-remark That I ended up with Apache for almost everything as nothing to do with the Apache brand. It just has to do with: 1 - The quality of the product; 2 - This crazy and brilliant community. And yes, my eyes are not closed to the world outside Apache and I keep checking other tools and libraries. But I end up learning more about good outside Apache tools form Apache related sources than from all other sources together - which means that many others at
RE: Commons Validator Packaging/Content
Ceki, I believe all you say. However that does not mean that JBoss does better elsewhere than it would do here. Jon stated that some non-Apache projects show that there are better ways of doing Open Source and gave JBoss as an example. But we just do not know how it would be if they were her. IMHO, JBoss is much cleaner of nonsense and much easier to get working than all the other Open Source app servers. That's it - no competition. It would probably also have no competition at Apache just by having the same core developers and core orientations (or just most of them). I just think they always had the best direction by a long way and that it would be like that anyway. Orion, although cheap and good, is payware... and I think I would choose JBoss even if Orion was Open Source (but I am not even 80% sure, much because Orion isn't OS). Me thinks Jon must come up with a better example to prove his POV. Me also thinks it will not be easy since Apache is quite good. And I am not a Jakarta founder. I took a look around with impartiality. I think Jon is undervaluing Jakarta because he helped creating it and he is comparing what it is with what he dreamed it would be. Things tend not to work according to our high expectations. I am comparing it with what I see elsewhere. Have fun, Paulo Gaspar -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 08, 2002 2:36 AM The JBoss guys are very smart. Scott Stark is extremely high caliber. Mark is no idiot either. Jboss is successful because it is so fucking good. From where I stand, the other appservers are just copying JBoss. Where do you think the MBean architecture in Weblogic 6.x came from? The problem with JBoss is that while they innovate BEA and IBM make all the dough. Such is the nature of opensource. Bloody fucking hell! (From what I hear Orion is pretty good too.) At 02:18 08.01.2002 +0100, you wrote: Jboss's success seems to be one project. I'm actually glad they went to sourceforge...they would have struggled to survive here... How can you know? I have studied their code and their documentation some months ago, I have also followed some of their mailling lists for sometime and that is not that obvious to me. I do NOT prefer what they call community. I do not find their code that good. I do not like their documentation that much. JBoss success has a lot to do with the lack of credible alternative for something with a lot of demand, unlike Jakarta products like Tomcat or Velocity. Give me a better case and/or concrete reasons, please. Have fun, Paulo Gaspar -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons Validator Packaging/Content
on 1/7/02 7:30 PM, Paulo Gaspar [EMAIL PROTECTED] wrote: I think Jon is undervaluing Jakarta because he helped creating it and he is comparing what it is with what he dreamed it would be. Things tend not to work according to our high expectations. I'm sure that is very true. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons Validator Packaging/Content
on 1/6/02 1:45 PM, Sam Ruby [EMAIL PROTECTED] wrote: Jon, I presume that you are talking about the subject, and not the text you are quoting. In any case, a framework independent validator seems to me to be valuable a reusable component. If one or both can't be restructed to be framework independent, then that would seem to be a reasonable explanation for the duplication. If both can, then merging of the best of both here in commons would seem to be the wisest path. I don't see why the basis isn't Intake. Why not work to move Intake to commons and then work towards a framework independent implementation in Commons? Of course it is easier to start from scratch to invent yet another validation framework. This is where I see another failure of Jakarta. People only go with the easiest route without any concern about the long term mess they are making. I feel like Jakarta is just going down this path of having a bazillion different implementations and versions of the same thing and it is only getting worse. Commons was supposed to help clean that up by providing a central location, however all I see is it making it worse because people are just re-inventing what already exists in other projects instead of using existing projects as the basis. A perfect example of this recently was the discussion about Torque. Hey, Torque exists, but it is *easier* to re-invent it rather than simply spend the time to figure it out, understand it and move it to commons (or a top level project). I'm starting to realize that Jakarta has grown to becoming a place where people only scratch their own itches and I agree that that is the basis for open source. However, we have no overall direction. We all have our own opinions and spend days and days discussing them and when it comes down to putting code into CVS, people do whatever they want anyway because there is no set of checks and balances to put some sort of higher level control over things. In Java Apache, these issues never came up because there were only a few projects and a few people expressing their opinions. Now, Jakarta has grown into literally hundreds of people expressing their opinions and doing what they want. Commons has become an area where people have a free CVS commit tree to put whatever they want into it, which is fine, however these people doing the commits haven't spent the time to do things as simple as figuring out what the proper way to format code according to the Jakarta rules. People keep saying that Jakarta isn't broken. Well, if it isn't broken, then how come we have so many people doing their own thing and not working together? Jakarta is supposed to be a group collective, however it is becoming nothing more than another Sourceforge. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons Validator Packaging/Content
Jon Scott Stevens wrote: Jon, I presume that you are talking about the subject, and not the text you are quoting. In any case, a framework independent validator seems to me to be valuable a reusable component. If one or both can't be restructed to be framework independent, then that would seem to be a reasonable explanation for the duplication. If both can, then merging of the best of both here in commons would seem to be the wisest path. I don't see why the basis isn't Intake. Why not work to move Intake to commons and then work towards a framework independent implementation in Commons? Do it in the other way around (make it framework independent, then move it into commons) and I think you may have a winner. Meanwhile, it is probably fair to assume that OTHERS will assume burying gems deep into the fabric of your component is done for a reason. In particular, the assumption will likely be that the code is so intricately interwoven into the fabric of your component that it would be difficult to break out. I know that there are examples of pre-gump days when attempts were made to break things out that weren't successful; but then again, that was before there was a tool that helped people monitor the stability of the interfaces. Of course it is easier to start from scratch to invent yet another validation framework. This is where I see another failure of Jakarta. People only go with the easiest route without any concern about the long term mess they are making. It is also easier to add a code directly to a subproject then to invest the extra effort in making the code a standalone, reusable component. snip People keep saying that Jakarta isn't broken. Well, if it isn't broken, then how come we have so many people doing their own thing and not working together? Jakarta is supposed to be a group collective, however it is becoming nothing more than another Sourceforge. Oh, there are definately a few things that need fixing around here. Spend a few minutes looking at http://jakarta.apache.org/builds/gump/latest/xref.html . Tell me what patterns you see. I see definate cleaving lines, and they are not along any of the functional or scoping boundaries that we have been discussing lately. The good news is that these lines are getting harder to see every day. My current favorite example of a recent closing of one of the fissures: jakarta-velocity-tools/struts. Another favorite of mine is jakarta-commons/collections, followed by jakarta-commons/beanutils. - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Commons Validator Packaging/Content
You need a search engine for these little things maybe off the main page. With something catchy under it like High your software has already been written for you...find it here. This would ecourage useful javadoc comments as well. So if I type tree I should see all the tree classes in the collections stuff under commons for instance. Its useless to say reuse when reuse implies finding it which implies knowing where to look for it. You're expecting people to go through each and every project and say 'humm is there a TreeMap that does key-value and value-key here ...nope let me search through the rest of all the projects'... I here there is a java indexing package on sourceforge that could be used for this :-D (j/k) -Andy Hi Jon, I think there is reason for the concern you are raising. I see a lot of other work repeated in other sub-projects too. Commons seems to be the only place where such smaller simple use components are visible. Most people just search there before and most think that Turbine and Avalon are big blocks of indivisible code. Maybe the way to go is just to move such components to the Commons. Why not moving Intake now? Maybe this issue needs regulation, but this kind of think tends to work better if you use the carrot before applying the whip. =;o) Have fun, Paulo Gaspar -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
