Re: Newsletter - Request for content
On Wed, Jan 08, 2003 at 12:46:25PM -, Rob Oxspring wrote: As you can see the timetable has slipped a bit! However, there doesn't seem to be a lot to go in this issue (just an entry for lucene + whatever I write to summarise general@) and I was wondering whether it was worth bothering with. I realise this is to be expected with the Christmas / New Year but there has been a general decline in content volume over the months and I was wondering whether there was something that should be done to address this. A number of thoughts have been mentioned by various people and I'd be interested to hear opinions: Reduce the frequency - every 2 months has been suggested before. Format revamp - no idea how but ideas welcome - perhaps new blood is required? How about setting up an 'ApacheNewsletter' Wiki page, let content accumulate, and publish once critical mass is achieved? I'd imagine that writing a newsletter entry is no fun at all. Probably each project has only 2 or 3 people with a broad enough understanding of the issues to 'summarize' a month's communications, identifying the signal amongst the noise. It's also a rather subjective task, with a high risk of offending someone by omitting or misrepresenting points. Using a Wiki doesn't solve the hard problems, but does lower the barrier to entry, and makes plain that it's everyone's problem to create content, not just the dedicated few listed below. Widen the scope - ant and Avalon have grown up to be (at least partially) outside the jakarta scope, should we include xml.apache.org? and it's children? maybe just a simple *.apache.org? I know Forrest has a willing contributor :) and I'm sure with some arm-twisting, one could be found for Cocoon. --Jeff (with some appropriate rename) Maybe its fine as it is? Thanks, Rob - Original Message - From: Rob Oxspring [EMAIL PROTECTED] To: 'Jakarta General List' [EMAIL PROTECTED] Cc: 'James Strachan' [EMAIL PROTECTED]; 'Henri Yandell' [EMAIL PROTECTED]; 'Conor MacNeill' [EMAIL PROTECTED]; 'Stefan Bodewig' [EMAIL PROTECTED]; 'Otis Gospodnetic' [EMAIL PROTECTED]; 'David Sean Taylor' [EMAIL PROTECTED]; 'Martin Poeschl' [EMAIL PROTECTED] Sent: Sunday, December 29, 2002 2:30 PM Subject: Newsletter - Request for content ... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Developer wishes to donate project to Apache
On Sat, Oct 12, 2002 at 12:27:17PM -0400, Geir Magnusson Jr. wrote: ... Why not bring into Jmeter? Frank tried [1] and was met with the same silence that greeted his ealier general@jakarta email [2]. Anyone wanting to have a play, the url is: http://www.PushToTest.com/ptt Jon might even like it, as it uses a real scripting language (Jython) to script HTTP tests, rather than XML. All wrapped up in a Netbeans gui. Attached is an email I wrote to the author with my personal assessment of TestMaker's chances at Jakarta. I hope it doesn't discourage people from doing their own analysis, but apparently if these things aren't posted publicly, Jakarta gains a reputation of ignoring people's approaches. --Jeff plug co-author of a similar Ant-based testing framework, http://aft.sf.net /plug [1] http://marc.theaimsgroup.com/?l=jmeter-devm=103064442221903w=2 [2] http://marc.theaimsgroup.com/?l=jakarta-generalm=103064493222452w=2 ---BeginMessage--- On Tue, Sep 03, 2002 at 09:09:49AM -0700, Frank Cohen wrote: Hi Jeff: Thanks for your interest. TestMaker uses a lot of open-source libraries: NetBeans, Jython, Xerces, JDOM, Apache SOAP, etc. The download package on the Web site provides these all integrated and ready to use. The components we wrote from scratch are the Test Object Oriented Library (TOOL) and the NetBeans module and localization/branding file. I'm laid up in bed with a nasty head cold - have been for the past 4 days. Ugh. I'll send you a document that shows how to build TestMaker from all the parts shortly. That's okay, I downloaded the whole shebang yesterday, and don't reeeally need to build all from scratch ;) Great. How did the install go? Are you running Unix, Windows, ? Did you read the docs? It all went nicely after I fixed the file formats. Anyway, just random thoughts :) I fully agree that the .NET vs Java war is hotting up and that OSS's achilles heel is the lack of coordination and integration. Is there a process to getting TestMaker considered as a subproject? I read the Jakarta Web pages - which do a very good job a discouraging - but it doesn't really say how a subproject is started. :-) You did it right. There's a Project Management Committee (PMC) of seven people who decide if a project gets in or not, and they decide based on interest expressed on general@jakarta. There, 99.9% of people don't know or use your project, so they form opinions mainly on criteria like these: 1) Is it suitable as per http://jakarta.apache.org/site/newproject.html 2) Is it a winner, ie is it leading the pack in it's market niche. 3) Does it's goals overlap with any existing, more widely know projects. 4) Does it integrate well with existing Jakarta projects. I think TestMaker meets 1), and given the sad, fragmented state of open source functional testing generally, doesn't fail 2) either. TestMaker's functionality does seem to overlap with JMeter somewhat, which is what Andrew Oliver said. Lately, people have been very unforgiving of projects that may fulfil the goals of related, more widely-known projects (in this case, JMeter). People do realise that fragmentation is hurting Java, so they'd rather callously say go away and merge with X than accept any project that isn't clearly unique or market-leading. Also, TestMaker seems more an integration of existing technologies (jython, netbeans) than a more traditional straight-Java project. The TestMaker-specific code (TOOL) has already been implemented at Jakarta, in the form of the HTTPClient project: http://jakarta.apache.org/commons/httpclient/ At least, that is the impression a casual user gets from the TOOL description Tool is the object library that handles communication with HTTP, HTTPS, SOAP, .NET, JDBC and other protocols. There's absolutely nothing wrong with projects that meet a need by integrating existing projects (assuming netbeans + jython + http lib == TestMaker), but they don't really fit well in Jakarta. There's just so many permutations. If someone integrated Eclipse + jython + httplib, should that also live at Jakarta? Anyway, that's my brutally honest opinion :) Perhaps we should form a Open Source Functional Testing Tools Consortium to promote awareness of what's out there, and more collaboration amongst the various projects (Latka, Anteater, TestMaker, JMeter, WebTest.. any others?). --Jeff --Jeff [1] http://aft.sourceforge.net [2] http://jakarta.apache.org/commons/latka) [3] http://jakarta.apache.org/commons/sandbox/jelly -Frank -- Frank Cohen, CEO, PushToTest, www.pushtotest.com, phone: 408 374 7426 Come to PushToTest for free open-source Active Security solutions that test, monitor and automate Web Service systems for functionality, scalability and performance. From: Jeff Turner [EMAIL PROTECTED] Date: Sun, 1 Sep 2002 14:42:35 +1000 To: Frank Cohen [EMAIL PROTECTED] Subject: Re: TestMaker as subproject Hi
Re: [Poll result] Committers, who are we?
Carnegie Mellon did a survey of ~300 Apache developers (56 committers) a while ago, and posted interim results to respondents last month. With the permission of the researcher, here are some stats: On Thu, Oct 03, 2002 at 03:35:18PM +0100, Danny Angus wrote: Vincent Massol once wrote: I was curious to know who the other committers where, whether they shared the same beliefs I have, etc. This prompted me to wonder: 1/ are we.. a)male b)female 98.89% male 1.11% female 2/are we a) young b) 20-30 c) 30-40 d) 40-50 d) old 19 : 1.1% 20-29 : 50.55% 30-39 : 41.03% 40-49 : 6.59% 50 : 0.73% 3/about English a)its my native language b)its a second language, I live in an English speaking country c)I'm fluent but I live in a non-English speaking country d)other, tell me.. Strangely they didn't ask this. However, 90% of people come from what I hazily regard as English speaking countries (US, England, Aus, NZ). 4/do we have a)a full beard b)a goatee c)a moustache d)noneoftheabove 5/wear sandals a)never b)sometimes c)always Nor did they ask these, missing a golden opportunity to come up with an identikit-style portait of J Random Apache Hacker. The person running the survey is Jeff Roberts (jroberts at andrew.cmu.edu). --Jeff d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
On Sat, May 25, 2002 at 02:04:24PM +0100, Pier Fumagalli wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Sat, 25 May 2002, Pier Fumagalli wrote: If you are a commiter - you have the same rights with all other commiters. If you don't want to exercise some rights - it's your choice. Hola, you tend to forget a part I'm stressing out quite hardly... It's not only rights... It's also dues, right? Yes, the 'due' to spend weekends writing code or answering emails or reading flame wars. Give me a break with the big 'due' to vote or have a say over how the project you're involved with. And in fact, Costin, the big opposition you're going to get from me, will always be on the fact that you are totally and utterly irresponsible towards this community and the ASF... It's years that you're been told that, not only from me, but from an extended number of people (do we want to get back to the Tomcat 3.x/4.x flamewar? Read those comments)... Aren't we all happy that 3.3.x exists, and is better than 3.2.x? Aren't we all happy that we have a choice to 4.x? Aren't we all happy that Jon was 'mislead' into not -1'ing Struts (one of Jakarta's biggest successes)? Perhaps people should be less certain they know what is best for the community :P Anyway, nice talking to you (not). .. and thankful that people like Costin persevere in spite of rather vicious abuse. --Jeff (a happy 3.3.x and Struts user, whose sense of justice temporarily outweighs an aversion to general@ flamewars) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Advertisement using Apache lists
On Mon, May 13, 2002 at 09:54:48AM +0100, Alex McLintock wrote: At 09:02 13/05/2002, Nicola Ken Barozzi wrote: I would like to encourage information about commercial entities that support Apache software, but I really have no clue about how it should be done. I too am setting up an organisation in the UK to help support Apache and other OSS software. I suggest that the first (and simplest) thing to do would be to setup a top level apache mailing list where it is ok to advertise oneself, one's company, or to advertise that you need support. I doubt a separate list would work. We've got an announcements@ list and everyone still cc's announcements to general@. Perhaps we should just adopt a simple subject line convention, [ADV] for adverts, to go with [ANN] for announcements. --Jeff I'm not a committer on any projects so can anyone else try to get this going? It shouldn't be too hard. Alex -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Advertisement using Apache lists
On Mon, May 13, 2002 at 02:04:20PM +0200, Nicola Ken Barozzi wrote: .. Perhaps we should just adopt a simple subject line convention, [ADV] for adverts, to go with [ANN] for announcements. I've noticed too that the annoumcement list stuff gets CCd to other lists. How about having all content sent to that list be automatically CCd to general lists with [ANN]? To spell out this idea: any mail that gets sent to announcements@jakarta is forwarded to general@ with [ANN] prepended to it's subject (possibly stripping any existing [ANN] variants). Same with [EMAIL PROTECTED] That's kinda nice. In addition to munging the subject line, it could add an X-Jakarta-Announce: or X-Jakarta-Advert: header, which people could filter on. All assuming that people *want* Jakarta-related adverts and announcements on general@. I get the impression that some do, a few don't, and most don't care. --Jeff This way if one wants only announcements, he can subscribe to that list, while other users get the ANN topics automatically. This could be done also with an [EMAIL PROTECTED] list, and [ADV] as Jeff suggests. Another result of this is having separate mail history for these lists. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Advertisement using Apache lists
On Mon, May 13, 2002 at 01:20:24PM +0100, Alex McLintock wrote: At 13:13 13/05/2002, Jeff Turner wrote: On Mon, May 13, 2002 at 09:54:48AM +0100, Alex McLintock wrote: At 09:02 13/05/2002, Nicola Ken Barozzi wrote: I would like to encourage information about commercial entities that support Apache software, but I really have no clue about how it should be done. I too am setting up an organisation in the UK to help support Apache and other OSS software. I suggest that the first (and simplest) thing to do would be to setup a top level apache mailing list where it is ok to advertise oneself, one's company, or to advertise that you need support. I doubt a separate list would work. We've got an announcements@ list and everyone still cc's announcements to general@. Perhaps we should just adopt a simple subject line convention, [ADV] for adverts, to go with [ANN] for announcements. It isn't just about announcements - if it were then we would just use the announcements mailing lists. It is really about having a place where we can discuss these issues which are welcome no where else. Ah right. these issues being, commercial entities supporting Apache software, aka How to make a buck off Jakarta. Cool :) I'd subscribe. The Open Source vs. Paid Work conflict sucks. Maybe start an egroups list, or even just collect a list of people to Cc. Mail weekly summaries to general@ to maintain interest. Then if it's still around in 1 month, ping infrastructure@ and beg :) --Jeff Alex -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: subproject layout conventions
On Wed, Mar 27, 2002 at 03:23:35PM -0800, Jon Scott Stevens wrote: on 3/27/02 2:26 PM, Steven Noels [EMAIL PROTECTED] wrote: All this and more is being tackled (slowly but steadily) in Forrest - and having some Jakarta people involved for cross-pollination would be good. There's not much yet except for the foundation and build environment and some static site generation, but you could familiarize yourself using http://marc.theaimsgroup.com/?l=forrest-devr=1w=2 and http://cvs.apache.org/viewcvs.cgi/xml-forrest/ I think Maven will be the pants off forrest and is already further along. I agree (as much as I like Cocoon and the Centipede build system). Maven could be a revolution on the scale of Gump. --Jeff -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Krysalis, Centipede, Generating docs with Cocoon?
On Fri, Mar 22, 2002 at 12:10:13PM +1100, [EMAIL PROTECTED] wrote: I downloaded Krysalis and Centipede, hoping to find some easy way of building docs, but I was sorely disappointed. You have to know a ton of stuff about Cocoon, Cocoon's 'book' format (which isn't DocBook), and the other tools involved to even get your head around it. If you have to setup and run Cocoon to generate a few HTML files, what's the point? At least the process with site.vsl and site.xsl is documented and easy to set up, and requires no special knowledge, for most commons projects. export CVSROOT=:pserver:[EMAIL PROTECTED]:/cvsroot/krysalis cvs login cvs co krysalis-centipede cd krysalis-centipede chmod +x build.sh ./build.sh docs Works fine for me. If you had problems, ask on the krysalis-users list. The doc format is standard Apache document-v10.dtd. You only need to edit the sitemap if your site has special needs, eg merging XML files before processing, Docbook - stylebook, stylebook - PDF, svg - .png. I find that being able to manage the generated site's URI space in one file is very handy. --Jeff If it's just for LF, I'd much rather tweak the existing stylesheets. -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://www.multitask.com.au/developers -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Krysalis, Centipede, Generating docs with Cocoon?
Answered offlist. In the meanwhile, everyone pay homage to the jakarta-site2 docs: http://jakarta.apache.org/site/jakarta-site2.html and acknowledge that anything less ain't good enough for everyday Jakarta use. The DVSL-based system that Jason van Zyl mentioned sounds best: Yup, that's my fault. I will remedy the situation with PDFs. A very long time ago before Anakia we had PDFs being produced with stylebook. The Turbine and Velocity docs were actually available in PDF format. Anakia presented some problems that made it impossible to use the fop stuff we created but that is different now with DVSL. Long story short: you will have PDF docs for BCEL sooner rather than later. --Jeff On Fri, Mar 22, 2002 at 01:13:48PM +1100, [EMAIL PROTECTED] wrote: ... Works fine for me. If you had problems, ask on the krysalis-users list. It works for me too, but that just builds the existing stuff. If I want to customise it -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
News, RSS, blogs, Cocoon (Re: news@jakarta list?)
On Fri, Mar 08, 2002 at 12:00:11PM +0100, Santiago Gala wrote: ... Then could we perhaps have a news@jakarta list for this sort of thing? A lot of people find announcements like this relevant and interesting. On a related (technological) note: We Jetspeed people (actually Raphael Lutta) put one year ago RSS channels, for our own purposes of showing them in the demo Jetspeed setup: http://jakarta.apache.org/jetspeed/channels/apache.ocs is an Open Content Syndication feed http://jakarta.apache.org/jetspeed/channels/jetspeed.rss is a channel for Jetspeed http://jakarta.apache.org/jetspeed/channels/turbine.rss is a channel for turbine The RSS mechanism could be easily used for news and content syndication @apache. Channels can be added, generated, etc. for different projects or activities, and used for dynamic linking to apache news from outside the web site. Sounds nice. Is this demo Jetspeed setup actually live somewhere? Adding some weblogs as newsfeeds would be good too. Weblogs are wonderful things. Have a look at http://www.need-a-cake.com/ Any JAMES people lurking here? Would it be possible to rig up a mailet that wraps incoming posts in XML and makes them available as an RSS feed? That way we could have an easy-to-use news submission process. FYI (for those who weren't aware), there's a new xml-forrest project project at xml.apache.org, specifically for things like this. Another FYI for Jetspeed people: Cocoon is very much encroaching on your portal turf ;) See http://www.need-a-cake.com/stories/2002/02/14/cocoonPortalFirstLook.html --Jeff (idling.. friday evening..) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
news@jakarta list? (Re: Introducing Enterprise Object Broker)
On Thu, Mar 07, 2002 at 06:03:21PM +, Pier Fumagalli wrote: Paul Hammant [EMAIL PROTECTED] wrote: Folks, Enterprise Object Broker (EOB) is an application server that tries to a be a simpler EJB container. It is not complete yet, but we have many demos showing local, remote, and webapp usage. Ok. Will we all stop using general@jakarta for advertisement of things which are NOT ASF related? Thankyou... Then could we perhaps have a news@jakarta list for this sort of thing? A lot of people find announcements like this relevant and interesting. How is it different from freshmeat? It's that 'community' thing Stefano goes on about. People have established webs of trust here. EOB is by Apache people, using Apache code, and that makes it *relevant*. --Jeff Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[VOTE] ASL vs. GPL page: is this okay?
Hi, As promised, I've written up an ASL vs. GPL page, for possible inclusion on jakarta-site2. I've more tried to capture the spirit of the thing from the Apache POV, than duplicate the detailed arguments in the O'Reilly article referenced at the end. Please vote on whether you think the reasons outlined here are sufficiently representative. Constructive criticism and change suggestions welcome. If sufficiently approved of, I'll XMLify it and submit a patch. --Jeff Why prefer the ASL to a copyleft license (eg GPL)? -- This is an slightly distasteful topic for most Apache developers. The license is simply not a central part of the Apache philosophy. Apache is about creating communities that create great software. The ASL is a minimum legal necessity that allows us to do this, nothing more. It promotes no political axe-grinding, and has no great philosophy that needs defending. The ASL, in fact, presents such a small conversational target that any licensing debate inevitably becomes what is wrong with license X. That inevitably leads to misunderstandings, holy wars and bad feeling, It's not productive, and not fun, and why we find licensing debates distasteful. In particular, it's not fun rubbishing the GPL. The reader is encouraged to read the GNU's philosophy pages (http://www.gnu.org/philosophy/). It is wonderful, high-minded stuff that most programmers instantly resonate with. Opposing RMS's vision of Free Software at first seems to be like kicking a puppy. But let's kick it anyway. It turns out that the puppy soon grows up to be a bulldog, biting and tenaciously hanging on to any code it can. Due to the GPL's extensive scope and 'viral' linking rules, GPL'ed code cannot be incorporated into proprietary software. It must all be copylefted, or none of it can be. In many cases, we at Apache find the GPL's virality a hindrance in *our* goal: creating communities that create code. This is because large parts of our community are selling custom solutions, not shrink-wrapped products sold in volume for general consumption. Essentially, selling software-based services, not software. When you're selling a service, releasing the code makes no sense to *anyone*. The code is mostly customer- or sector-specific, so is not reusable, and of little interest to fellow developers. The customer *certainly* doesn't want you publicising their code, breaking confidentiality agreements and potentially exposing security flaws to the world. Thus, to adopt a copyleft license like the GPL would alienate the service-oriented portion of our community. We want the widest possible audience, not for market share, but because the diverse input results in software with hybrid vigour, wide applicability and the kind of tough-as-nails quality we strive for. Thus, we encourage users to adopt non-copyleft licenses like the ASL for everyday code, as it increases the chances of code sharing and cooperation, ultimately leading to better software. For further information, please refer to the well-researched and well-written O'Reilly article entitled Working Without Copyleft, at http://www.oreillynet.com/pub/a/policy/2001/12/12/transition.html A good general reference of open source licenses is Bruce Perens' book Open Sources: Voices from the Open Source Revolution at http://www.oreilly.com/catalog/opensources/book/perens.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] ASL vs. GPL page: is this okay?
On Thu, Mar 07, 2002 at 08:46:51AM +1100, Jeff Turner wrote: Hi, As promised, I've written up an ASL vs. GPL page, for possible inclusion on jakarta-site2. ... Please vote on whether you think the reasons outlined here are sufficiently representative. Constructive criticism and change suggestions welcome. On second thoughts... I'm sure most of us are sick of the whole issue, and are NOT looking forward to another barrage of email on the subject :-) So preferably, keep replies to a simple vote and one-line explanation. Constructive criticism and change suggestions are still welcome, but let's keep that off-list as much as possible. --Jeff --Jeff Why prefer the ASL to a copyleft license (eg GPL)? -- ... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] ASL vs. GPL page: is this okay?
On Wed, Mar 06, 2002 at 11:38:42PM +0100, Ceki Gülcü wrote: Jeff, Kudos for having the courage to proceed with this. Comments inline. :) It's not easy or fun. At 08:46 07.03.2002 +1100, Jeff Turner wrote: ... Why prefer the ASL to a copyleft license (eg GPL)? -- This is an slightly distasteful topic for most Apache developers. The license is simply not a central part of the Apache philosophy. Apache is about creating communities that create great software. The ASL is a minimum legal necessity that allows us to do this, nothing more. It promotes no political axe-grinding, and has no great philosophy that needs defending. The ASL, in fact, presents such a small conversational target that any licensing debate inevitably becomes what is wrong with license X. That inevitably leads to misunderstandings, holy wars and bad feeling, It's not productive, and not fun, and why we find licensing debates distasteful. The license is very much part of the Apache philosophy. It may even embody the essence of the philosophy. The license says, basically, do what you wan't, but don't sue us, don't abuse our name, and give credit where credit is due. That isn't much of a philosophy ;) It hints at the underlying importance we attach to the Apache name, but that's all. No need to be apologetic about discussing licensing. Not apologetic, just reflecting a general lack of keenness for licensing debates, because they usually end up in unproductive GNU-bashing. A good license is more valuable than a million lines of code. I maybe exaggerating but only a little. In particular, it's not fun rubbishing the GPL. The reader is encouraged to read the GNU's philosophy pages (http://www.gnu.org/philosophy/). It is wonderful, high-minded stuff that most programmers instantly resonate with. Opposing RMS's vision of Free Software at first seems to be like kicking a puppy. But let's kick it anyway. It turns out that the puppy soon grows up to be a bulldog, biting and tenaciously hanging on to any code it can. Due to the GPL's extensive scope and 'viral' linking rules, GPL'ed code cannot be incorporated into proprietary software. It must all be copylefted, or none of it can be. A bulldog? :-) Something with teeth :) But yes, bad analogy; will be removed. In many cases, we at Apache find the GPL's virality a hindrance in *our* goal: to (not in) *our* goal? agreed creating communities that create code. This is because large parts of our that write code? okay community are selling custom solutions, not shrink-wrapped products sold in volume for general consumption. Essentially, selling software-based services, not software. When you're selling a service, releasing the code makes no sense to *anyone*. The code is mostly customer- or sector-specific, so is not reusable, and of little interest to fellow developers. The customer *certainly* doesn't want you publicising their code, breaking confidentiality agreements and potentially exposing security flaws to the world. Hmm, are you sure we are only selling services? I dunno. I claimed that large parts of our community are selling services, not software. I don't know how true that is. I *suspect* it's true; that there are more consultants here than people banging out commercial code. I could be completely wrong. That's why it's so hard and dangerous to claim to speak for anyone but oneself. Exposing security flaws to the world is very debatable. Most cryptographers consider security-by-obscurity as bad practice. I would drop the exposition argument. Yes that was very much in my mind :) The detractors of security through obscurity are usually talking about large commercial software. When you have custom code written in a hurry on a tight budget, security holes inevitably arise, and security through obscurity is better than nothing. Though your first impression is how most people will see it, so I agree it should be removed. I found the ethics argument in the Reese-Stenberg article to be very powerful. The original author has no *absolute* right on extensions and improvements. The fact that I wrote 100 initial lines of code gives me no right, moral, ethical or otherwise to impose a license on the 10'000 lines that you subsequently write. I certainly have no rights on 10'000 lines of *unrelated* code! Indeed! But arguments of morality are even more treacherous than arguments of pure pragmatism. GNU proponents would surely argue that the means justifies the end. The goal of Software Freedom warrants a bit of arm-twisting. Thus, to adopt a copyleft license like the GPL would alienate the service-oriented portion of our community. We want the widest possible audience, not for market share, but because the diverse input results in software with hybrid vigour, wide applicability and the kind of tough-as-nails quality we strive for. The service orientation
Re: [VOTE] ASL vs. GPL page: is this okay?
On Wed, Mar 06, 2002 at 07:47:49PM -0500, Andrew C. Oliver wrote: My opinion is you've come across just about as objective as Richard Stallman would be in the Microsoft Beta testing program. :- Pretending to be objective is not my strong point. No offense but this is EXACTLY the opposite of what is needed. Way too inflamatory, partisan and counter-productive to the target of just explaining to the confused as to what the differences are. My aim was not to give an exhaustive comparison. The O'Reilly and Perens pages do it much better than I could. I wanted to give an Apache-flavoured introduction to the debate, by introducing the main issue (GPL virality) and showing how that conflicted with Apache's community-orientedness. And then link to the real thing. I kinda think the link off of the Apache Manual was fine... +1 --Jeff -Andy On Wed, 2002-03-06 at 16:46, Jeff Turner wrote: Hi, As promised, I've written up an ASL vs. GPL page, for possible inclusion on jakarta-site2. ... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
ASL vs. GPL page?
Hi, Is there a page somewhere at apache.org, explaining why anyone would want to switch from GPL to ASL? The GNU.org site paints a very inspiring picture of a world of Free Software. It would be nice if there was an Apache equivalent somewhere explaining the Apache philosophy. This could be used as ammunition by people trying to convert useful GPL'ed projects. I'm sure many Jakarta members have found themselves in this situation. Personal perspective: I know I was quite shocked when I first heard someone here say GPL sucks (back in fighting-with-webmacro days:). I didn't know how to take it. What kind of philistine wouldn't want RMS's vision of Free Software to come true? It took me a long time (as a university student) to understand why the GPL truly does suck as a license for business use. So, a) is there anything out there already, and b) if not, anyone want to volunteer? :) I'm not very qualified, but could certainly provide something for a testimonial section. Here's a starting resource: http://www.oreillynet.com/lpt/a//policy/2001/12/12/transition.html Working Without Copyleft It's possible to be an ardent supporter of open source development and not be a fan of copyleft and the General Public License. In this article the authors -- software developers -- relate how they came to embrace copyleft, became disillusioned with its limitations, and consequently turned away from it. --Jeff -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: contributing to Jakarta
On Tue, Feb 26, 2002 at 10:53:08AM -0800, Joe Labbe wrote: Hello Everyone - I am working on a project porting one of the oldest dynamic content servers to the Java platform. The WebDish Presentation Server was originally released in 93, and in 95 was named as the platform of choice by Charles Schwab for their transition to the web. Since then, the marketplace has been flooded with other solutions, and I'm trying to see if I can inject new life into WebDish by integrating it with Java technology. I have discussed with my employers the benefits of developing a project as an open source product. As their interest was in the original version in C, I am confident I can convince them to release rights to the Java version. What I want to know is: would there be any interest from the Jakarta program in including WebDish as one of their subprojects? How about starting off at Sourceforge first? WebDish sounds like an interesting, ahead-of-it's-time product. It seems that because of it's pioneering nature, it has it's own alternatives to the now-prevalent standards (servitons instead of servlets, .jpn instead of JSP). In principle, I think most people here would stick with the industry standards implemented by many app servers (notably Tomcat), rather than those concocted only for WebDish. The Servlet API is also one of the nicest to come from Sun, so a proprietary alternative would have to be *very* good to capture any developer mindshare. I'd say, abandon WebDish and instead apply the lessons learned to build something equivalent on top of Tomcat+Turbine/Cocoon. The result may not be as architecturally coherent, but it is much likelier to attract developer mindshare, and ultimately be profitable for your company. It's also more fun working in teams than soldiering on on your own, as a lone cathedral-builder, ignoring the world and in turn being ignored. Developers of your caliber are very very welcome at Jakarta ;) --Jeff (whose opinions are highly uninformed when it comes to WebDish, and apologises if they're based on misunderstandings) Joe Labbe [EMAIL PROTECTED] -- 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: crushed
On Mon, Jan 07, 2002 at 03:44:50PM -0500, Andrew C. Oliver wrote: Guys, This whole experience has become a bit disheartening. Craig McClanahan who is like an idol of mine said this: We will continue to do what we've done in the past -- reject projects that only want the name recognition value of being under Apache, and don't have a development community compatible with Apache's style. That's much more important than whether it's server-side versus client-side, or in one repository versus another. Seemingly directed at POI. I don't see what the problem is. Read it carefully.. for that statement to apply, POI would have to: - _only_ want the name recognition. - have a development community incompatible with Apache's style Do either of those statements apply to POI? Incidentally, the other statement Craig made in that email sums it all up for me: The point from Jon that I *do* dismiss is his feeling that there should be one and only one implementation of any particular functionality -- one size fits all is a very rare phenomenon in my experience, and having some choice is helpful. I have _never_ seen a user complain about having too many choices. Not even between notorious duplications like Tomcat 3/4 and Crimson/Xerces. I _have_ seen users want comparisons, and better docs to help them make the choice. Choice is good. Documented choice is infinitely better :) I would encourage people (esp. Jon, Ceki, Peter) to read Linus' emails on design: The problem with singlemindedness and strict control (or design) is that it sure gets you from point A to point B in a much straighter line, and with less expenditure of energy, but how the HELL are you going to consistently know where you actually want to end up? It's not like we know that B is our final destination. -- http://kerneltrap.org/article.php?sid=398 --Jeff -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: crushed
On Mon, Jan 07, 2002 at 03:44:50PM -0500, Andrew C. Oliver wrote: Guys, This whole experience has become a bit disheartening. Craig McClanahan who is like an idol of mine said this: We will continue to do what we've done in the past -- reject projects that only want the name recognition value of being under Apache, and don't have a development community compatible with Apache's style. That's much more important than whether it's server-side versus client-side, or in one repository versus another. Seemingly directed at POI. I don't see what the problem is. Read it carefully.. for that statement to apply, POI would have to: - _only_ want the name recognition. - have a development community incompatible with Apache's style Do either of those statements apply to POI? Incidentally, the other statement Craig made in that email sums it all up for me: The point from Jon that I *do* dismiss is his feeling that there should be one and only one implementation of any particular functionality -- one size fits all is a very rare phenomenon in my experience, and having some choice is helpful. I have _never_ seen a user complain about having too many choices. Not even between notorious duplications like Tomcat 3/4 and Crimson/Xerces. I _have_ seen users want comparisons, and better docs to help them make the choice. Choice is good. Documented choice is infinitely better :) I would encourage people (esp. Jon, Ceki, Peter) to read Linus' emails on design: The problem with singlemindedness and strict control (or design) is that it sure gets you from point A to point B in a much straighter line, and with less expenditure of energy, but how the HELL are you going to consistently know where you actually want to end up? It's not like we know that B is our final destination. -- http://kerneltrap.org/article.php?sid=398 --Jeff -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Jakarta code search engine? (Re: crushed)
On Mon, Jan 07, 2002 at 05:59:51PM -0800, Jon Scott Stevens wrote: on 1/7/02 5:10 PM, Paulo Gaspar [EMAIL PROTECTED] wrote: I see you crying a lot over this but no POSITIVE initiative. That is because I don't see a way to fix the problems and I'm not sure I have the energy to actually go through with it anymore. I haven't seen you give any positive initiative's either. The idea of a Jakarta code search engine has arisen a few times. Any lucene or alexandria developers care to comment? Cocoon docs are already searchable apparently, though this functionality isn't online. Alternatively, a simple link to Google (restricted by site:jakarta.apache.org) from the front page might help. --Jeff -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Proposal: Component survey
This idea was (is) part of the Commons charter: (1.5.2) the directory The subproject will also catalog packages and other resources available to the public related to other Jakarta subprojects and ASF projects. This will be a dynamic catalog, like Bugzilla and Jyve, similar in functionality to download.com, cpan.org, or SourceForge.net. New entries may be added by Jakarta committers, developers, and users. Entries by developers and users will be approved by a committer before being made public. -- http://jakarta.apache.org/commons/charter.html So if you want to do this, Commons is the place to do it. I volunteer to do the Avalon bits (Berin outlined the reusable stuff recently). --Jeff On Tue, Jan 08, 2002 at 05:19:48AM +0200, Kief Morris wrote: I've been meaning to trawl through the jakarta subprojects looking for components that could be suitable for using in a project of mine. It occurs to me that having an inventory of components could be a useful thing for Jakarta, both for general developers who may be overwhelmed by what's there, and to make Jakarta subproject developers more aware of what's available so they can avoid duplication. ... Kief -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[ANN] DoctypeChanger: pre-parse DOCTYPE manipulation
Howdy, I've written up a Java utility, called DoctypeChanger, that I hope could be useful to many people who exchange XML documents. I've mentioned it on jakarta-commons and briefly on general@xml, but I thought I should introduce it properly: Probably the first XML interoperability issue that many users encounter is when they are on the receiving end of XML with a DOCTYPE declaration. Assuming one wants to validate, there are a number of situations in which your parser will barf: - You are offline, or otherwise cannot retrieve the specified DTD. - The DOCTYPE declaration's SYSTEM id may be relative to someone else's system (./dtds/foo.dtd). - The DOCTYPE declaration's PUBLIC or SYSTEM id might be just plain wrong. - If the incoming XML doesn't have a DOCTYPE declaration, there is no way to force the parser to validate against a local DTD [1]. In short, the categories are incorrect, inaccessible, non-existent and correct. By writing a custom EntityHandler or using an entity catalog, one can deal with incorrect and inaccessible. The remaining case, non-existent, is AFAIK, unsolvable with mainstream techniques. Simon St.Laurent wrote a Java stream filter to solve this, which replaces or adds DOCTYPE declarations on the fly [1]. I have since generalized and extended it, so that one can now add, modify, replace and conditionally replace it (based on the old value). The documentation (including background, rationale, examples) is available at: http://opensource.socialchange.net.au/doctypechanger/latest/apidocs/ And the code can be downloaded here: http://opensource.socialchange.net.au/doctypechanger/ It's under the Mozilla Public License 1.1, for historical reasons (it's APL-compatible, right?). I hope people find this useful :) Feedback very welcome. --Jeff [1] http://www.simonstl.com/projects/doctypes/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Business-Oriented XML
On Fri, Nov 16, 2001 at 08:58:06PM -0800, Dave Jarvis wrote: Hello, again. Neeme Praks wrote: Have you ever had a look at Apache Cocoon project? That achieves all the Yes. benefits you outlined in your paper plus more. Here are a few items BOX addresses that Cocoon does not (as far as I can discern; please correct my errors): o doesn't provide an inherent state-based architecture (it's an aside, not focus) Nope, they threw out the reactor (state machine) pattern as being too hard to manage. o doesn't automatically apply a different view of logic based on the domain Certainly can :) Have a look at Cocoon 2's class org.apache.cocoon.selection.HostSelector. o extremely complex; it mixes multiple languages and odd syntax (e.g., connectDatabase) That's just your particular XSP, which uses an XML entity connectDatabase; to pull in other XSP. If you put your logic in logicsheets as intended, then your XSP pages are pure XML. o makes it easy to couple presentation and logic (see below) Actually, XSP makes it easy to mix *content* and logic (presentation is in XSLs). o lacks an integrated expression parser o doesn't expose a consistent syntax for doing tasks such as: - file I/O - sending XML to remote servers Have a look at Cocoon 2's xscript SOAP demo (xscript being an XSP equivalent of James Strachan's xtags taglib). - calling native code (Java, C, Perl, etc.) - SQL statements o cookies, FORM parameters, and URL encoded variables are not treated uniformly o doesn't use plain XML (i.e., embeds other language source directly) Anyway, if you've got time, hop on cocoon-dev.. I'm sure there's much mutual learning to be had (it's a fun place to lurk anyway). Cocoon 2 has a very generic architecture, and I've no doubt that your code could be integrated as an XSP alternative. --Jeff -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Using contents of Jakarta CVSROOT?
Cool :) Attached is some documentation on what all the scripts do, and step by step instructions for installing the whole system on a new CVS repository. --Jeff On Sun, 4 Feb 2001, Jon Stevens wrote: on 2/4/01 12:03 AM, "Jeff Turner" [EMAIL PROTECTED] wrote: Hi, I'd like to use the Jakarta CVS access control and commit emailing for a company CVS server. This is the stuff get get if you run 'cvs checkout CVSROOT'. There isn't any indication that the files are under the APL (or any license), so can I assume it's in the public domain and usable by anyone? I'll post installation instructions if that's the case. --Jeff Yep, it is in the public domain. Have fun. -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ | http://java.apache.org/turbine/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jeff Turner [EMAIL PROTECTED] Written 4 Feb 2001 $Revision: 1.2 $ $Date: 2001/02/04 10:26:42 $ Introduction This file documents the Apache projects' CVS setup, namely the contents of the CVSROOT directory, and how to install the Apache CVS system on a new system. All comments and improvements welcome. Access Control Lists The Apache access control system is very flexible and very simple (much better than the OS username technique described in the CVS book). The ACLs (access control lists) determine whether a user has *write* access. Who has read access is still determined by the 'readers', 'writers' and 'passwd' files. The Apache ACLs work in addition to the standard CVS mechanism, not replacing it. Here is a list of new files implementing the ACL, and what they do: avail The access control lists for determining write access. See the description in cvs_acls.pl cvs_acls.pl Program that parses 'avail' and decides whether a user has commit access commit_prep.pl Once a user has been authenticated against the ACL, this script creates a list of the files modified in this commit. This data is stored for later use by the logging script log_accum.pl. In this way, log_accum.pl can combine changes in multiple directories, and mail a single message. commitcheck Program invoked from commitinfo (the standard CVS hook into the commit process), which in turn invokes cvs_acls.pl and commit_prep.pl. Commit message Mailing System = By default with CVS, if files README and src/Foo.java are modified, two separate commit messages will be emailed to the committers. This is because CVS has a very file-centric model, and has little idea of project-wide differences, and thus doesn't associate the changes in README and src/Foo.java. The Apache script 'log_accum.pl' works in tandem with the commit checking script 'commit_prep.pl' to accumulate all changes made in one commit, and the mailing *one* message to the list. 'log_accum.pl' by default mails an Apache list, and thus needs minor modification. See below for details. Getting ACLs working on a new system Here are the steps I performed to use the Apache CVSROOT system on a new CVS repository: 1) Download the Apache CVSROOT directory as follows: [~/jakarta]$ cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login password: anoncvs [~/jakarta]$ cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic checkout CVSROOT 2) Download the new server CVSROOT directory: [~/server]$ cvs -d :ext:jeff@localhost:/usr/local/src/CVS [~/server]$ cvs checkout CVSROOT 3) Tag the current version of new server's CVSROOT from a CVSROOT sandbox: [~/server/CVSROOT]$ cvs tag before_apache 4) Copy the following files from the checked-out jakarta CVSROOT to the checked-out server CVSROOT: [~/server/CVSROOT]$ cp ~/jakarta/CVSROOT/commitcheck . [~/server/CVSROOT]$ cp ~/jakarta/CVSROOT/cvs_acls.pl . [~/server/CVSROOT]$ cp ~/jakarta/CVSROOT/commit_prep.pl . [~/server/CVSROOT]$ cp ~/jakarta/CVSROOT/avail . 5) Add these new files to the 'checkoutlist' file, so they'll be checked out on the server CVSROOT: [~/server/CVSROOT]$ cat checkoutlist commitcheck cvs_acls.pl commit_prep.pl avail [$/server/CVSROOT]$ 6) Add the new files to CVS, and do a 'cvs update': [~/server/CVSROOT]$ cvs add cvs_acls.pl commit_prep.pl commitcheck avail [~/server/CVSROOT]$ cvs up A avail M checkoutlist A commit_prep.pl A commitcheck M commitinfo A cvs_acls.pl 7) Edit the ACL to allow everyone to edit everything (or customise it now): [~/server/CVSROOT]$ cat avail avail [~/serv
