Re: [VOTE] HiveMind as a Jakarta sub-project
[X] +1 I support this proposal [ ] -1 I don't support this proposal [ ] 0 I abstain from voting for or against this proposal Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: questions license for site documents
Quoting Christopher Lenz [EMAIL PROTECTED]: You're not saying that the boilerplate text should appear as comment in every generated HTML document, are you? Yes, I am. For the same reason that it's in every Java file. Cheers, Chris Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: boilerplate LICENSE text in different formats
Quoting Tetsuya Kitahata [EMAIL PROTECTED]: On Tue, 2 Mar 2004 13:37:48 -0500 Shapira, Yoav wrote: I have started a wiki page at http://wiki.apache.org/incubator/LicenseFormats for boilerplate text in different formats. Cool and useful -- thanks ;) Ditto. :-) I'll try it out. Looks good. I just added a tweak that the XML format also works for HTML as well. -- Tetsuya. ([EMAIL PROTECTED]) Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: questions license for site documents
Quoting Tetsuya Kitahata [EMAIL PROTECTED]: On Mon, 1 Mar 2004 22:24:02 + robert burrell donkin wrote: i've had a quick google and i'm not sure that there's a consensus out there on this. i like the idea of modifying the .vsl file and i'd be inclined to add both formulations. maybe this would be a good question to raise on community... Go ahead. I suspect it that we should modify site.vsl in either case. :-) If we decide to modify all the xml files in /xdocs/, appending link rel=license href=http://jakarta.apache.org/LICENSE/ line would be more practical ... under /document/properties/ element. (generated htmls should have meta tag, link tag or something equivalent) The instructions at the very end of http://www.apache.org/licenses/LICENSE-2.0.html describe *exactly* what to do to documentation files, and adding a link in the manner you described is the wrong answer. Instead, you should enclose the same boilerplate text at the top of each such document that is included at the top of Java sources, enclosed in the appropriate comment characters for your format (i.e. for XML, surround by !--. and --, for properties files, prefix by #, and so on). -- Tetsuya. ([EMAIL PROTECTED]) Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jakarta-site karma?
Quoting Erik Hatcher [EMAIL PROTECTED]: In order to finally make an official mirrored release of Lucene 1.3, I need jakarta-site karma so that I can update binindex and sourceindex. Would the powers that be please grant me this? Thanks, Erik Done. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Differences
Quoting Vadim Gritsenko [EMAIL PROTECTED]: Ted Husted wrote: Perhaps once most of the Committers are on the PMC list, we can move the administrative nonsense there again, and let the General list be the General list again :) Looking forward to it. Do not remember when good flame worth reading last happened on this list. The last really good (by some people's definition, I guess) flame war happened a couple of years ago ... and caused the subscription count on this list to drop from 4000 to 1500 in less than a month. It is currently 718. Vadim Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [License] for jars in CVS
Quoting Danny Angus [EMAIL PROTECTED]: I see what you are saying, but why is this an issue only with OGNL? Is it because of license incompatibilities? 'Cause there are other jars in CVS both Apache and non-Apache. Harish, It isn't only an issue with OGNL, it is a general issue which has been bubbling away for months. In principle it is not good to have Jars in CVS. In practice it makes life much easier for many people. It also makes it more difficult for many other people -- especially those that need to integrate lots of open source projects (with overlapping dependencies) together. The goal here is to ensure that all the modules you want to create are built with (and tested with) the *same* versions of the common dependencies, not the ones whose jars happen to be checked in to CVS for that particular module. You still need mechanisms to allow the developer to override the default decisions checked in to the build scripts. For nearly all of the I've checked in jars for the convenience of developers packages I've evaluated for use fail to allow such overrides, and hard code their build classpaths to point at the checked in JARs only. There are moves afoot to produce some kind of jar download site which would provide the convenience of automated downloads with Ant or Maven, and comply with licence issues, and not require jars to be in CVS, cvs is not great at handling binaries. d. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] ORO 2.0.8 maintenance release
Quoting Daniel F. Savarese [EMAIL PROTECTED]: I know now may not be the best time to have a vote, but I would ask the PMC to vote on approving the release of jakarta-oro 2.0.8. The current code base contains important bug fixes and has gone too long without a public release. [X] +1 I approve the release of jakarta-oro version 2.0.8. [ ] -1 I do not approve the release of jakarta-oro version 2.0.8. Craig McClanahan (as Jakarta PMC member) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] ORO 2.0.8 maintenance release
Quoting Gary Gregory [EMAIL PROTECTED]: -Original Message- From: Daniel F. Savarese [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 23, 2003 17:40 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [VOTE] ORO 2.0.8 maintenance release [X] +1 I approve the release of jakarta-oro version 2.0.8. [ ] -1 I do not approve the release of jakarta-oro version 2.0.8. Gary Gregory (in a pending state, awaiting adding to the committee file) Do you mean you're awaiting commit karma on the jakarta-oro repository? If so, cnan you (or anyone) point me to a vote thread electing Gary as a committer? With that I can add you immediately. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
Quoting Harish Krishnaswamy [EMAIL PROTECTED]: Thanks Craig, this is elaborate, informative and puts the issue in my perspective. May be this should be put on the website too somewhere. Here are my inferences so far... inferences ASF is a group of projects administered by the Apache board members. The board delegates certain responsibilities over to the PMCs of the individual projects while still maintaining the authority and management responsibilities. The PMC is responsible for a wholesome code and community of the project it oversees but does not have the authority to recognize new projects. Jakarta started out as a single project for a web container and has grown into a foundation of projects in itself without sufficient administration/organization. /inferences Waiting for the bureacracy to be created first is kind of antithetical to the way most open source developers think :-). Here are my thoughts distilled from a lot others'... * I think the projects at ASF should be classified in some way (preferably by technology like we have now for xml, db etc.) into umbrella projects. All projects piled together at the top level would not convey very well. This is where Jakarta would need redefinition. Seems like the inital motivation, server side web development, is a good fit. And that would mean some reshuffling. The problem with graph shaped (single inheritance) hierarchies is that sometimes a single project fits more than one place. For example, where do you put Cocoon? It's clearly a thing that fits into an XML Technologies sort of place. It's also a thing that clearly fits into a server site technologies sort of place. The answer that Cocoon chose (the right one, IMHO) was to be a separate TLP that is *linked* to both of those technology's web sites. But, the more fundamental principle is that the legal organization of the ASF need not have anything at all to do with how websites are organized and how projects are made visible. * I think each umbrella project or each project within could have a PMC and each project should maintain a PMC membership of atleast 51% of its committers to sustain. That's pretty much the way that Jakarta works now (we've focused on expanding the PMC membership over the last year to ensure coverage from all the subprojects). But, as a Jakarta PMC member, it's still a daunting thought to be held responsible for oversight of all the code, and all the releases, across all of Jakarta. It's hard enough for me, for example, just to stay current on the three projects I watch and try to participate in (Commons, Struts, Tomcat). I'm pretty clueless about what the Tapestry folks are doing, yet *I* need to approve releases? Having Tapestry committers on the PMC helps, but isn't sufficient. * I think the website should match the organizational structure to avoid confusion. I don't agree. The website(s) should be focused around making it easy for users to find out what Apache projects might have products that are relevant to their needs. The internal project organization is an implementation detail. * I think the board should classify the newly adopted projects. Projects that churn out of existing projects should be brought back to the board for classification at the time of creating new CVS repositories. * Each umbrella could have a commons and a sandbox to share and play. * There could be a top level commons to house cross-umbrella components. It seems like what we now have is pretty much in good shape and only means that the following actions take place... * Reorganize Jakarta (and may be others??) The interesting question is what Jakarta becomes after the subprojects that want to become TLPs do so. I suspect that keeping it as a brand is likely to be helpful, but the brand has been pretty muddled too (is it Apache Struts or Jakarta Struts? Depends on which book title you read :-), and the earlier perceptions that Jakarta had for high quality server side Java code is starting to slip. * Enforce project level PMC membership IMHO, it's just not good enough to satisfy the oversight requirements delegated to the PMCs by the ASF Board. Just my thoughts. Regards, Harish Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Confused with PMCs, TLPs, ASF and Power?
Quoting Stephen Colebourne [EMAIL PROTECTED]: Then try this: http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges It aims to be a starter course on why discssions about PMCs, TLPs, Jakarta and the ASF appear, and possibly how they affect you. Be aware of the disclaimer at the top, however trying to distill any controversial topic to one page always ends up annoying someone. Stephen Stephen, Thanks for taking the time to attempt condensing an incredible amount of email (on an incredible number of mailing lists) down to a single page that highlights the key issues. I wanted to let you know that I just committed a small patch to the Wiki page -- where you said Note also that Struts committers have no rights to vote I added the parenthetical statement (unless they are also members of the Jakarta PMC) which is true for several of us. Indeed, the Jakarta PMC has been growing lately in a deliberate attempt to encompass committer representation from more Jakarta subprojects. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
Quoting Harish Krishnaswamy [EMAIL PROTECTED]: Could someone please explain the motivation behind the creation of Jakarta and how it got to where it is today? May be that would help answer some of the questions we have? -Harish These comments are going to be (like anyone's would be) colored by my own personal experiences during the development of Jakarta -- including my ignorance of a lot of the details in subprojects that I'm not an active participant. But it should give you a little feel for the history of the place. The gist of the creation of Jakarta was around three facts: * Apache wasn't an incorporated entity (this is about four years ago now), but wanted to be -- and was formally becoming the Apache Software Foundation. * Apache had a project to build a servlet container (Apache JServ) at a website called java.apache.org which created a trademark-use issue around java. (I was a committer on Apache JServ, which is how I originally got involved in open source software.) * Sun wanted to contribute, and Apache wanted to accept, the source code for the servlet and JSP implementation called the Java Servlet Development Kit, and later published by Apache as Tomcat 3.0. Just as an item of slight historical interest, Jakarta was the name of the conference room at Sun where a lot of the early discussions took place. An organizational framework to focus on developing open source server side Java stuff was created to host these initiatives, and other related subprojects got proposed and added to the mix. As the number of Jakarta committers scaled from the original 10 or so to where we are today (hundreds), the original charter has become, umm, somewhat stretched. Ironically, it didn't take long at all for the scope of that original charter to get exceeded, because one of the little nuggets of code that was included in the original Tomcat contribution was a pure-Java build tool (to replace make) called Ant ... As more and more subprojects were added, there were some inevitable cases of overlapping scope, and overlapping implementations of the same ideas. One of the best things we've done (IMHO) was purposely creating a subproject (jakarta-commons) focused on making small, focused, reusable packages, and encouraging the larger projects to use them. Not only has this been successful within Jakarta -- there's been quite a lot of cross-fertilization among the web app frameworks, for example -- it's also created a fairly rich library of funcational packages that are widely used elsewhere. But one could really argue whether something like Commons Digester (originally designed as an easy-to-use tool to parse XML configuration files) really fit the Jakarta charter. Over time, there have been more than a few, err, voluminous discussions about how to scale up Jakarta from an organizational perspective, and whether the fundamental organizing principle was still the correct one. Does a focus on server side stuff exclude what could be some really interesting open source projects? Does a focus on Java make sense when just across the website there are things like xml.apache.org that are focused on a technology, not on an implementation language? Does it make sense to have community type projects that host individual software package projects at all? Coupled with these increasing concerns (at the ASF board level) about the ability of any oversight group (a responsibility delegated to PMCs in the ASF organizational structure), several original Jakarta subprojects (or even sub-sub-projects in some cases) like Ant, Maven, and James decided to become top level projects (TLPs) of their own -- this takes making a formal proposal to the ASF Board that gets accepted, and the formation of a PMC for that project. Those sorts of discussions continue to this day. Somewhat separately, but overlapping in time, it became clear that there needed to be a way to incorporate new developer communities (and in some cases existing codebases that were being contributed) into Apache. The developers (if they weren't Apache committers already) needed to learn the Apache way to do things. The code (if any) needed to be vetted for appropriate contributor agreements to protect both the ASF and those that rely on our code. Thus, the incubator project was created as a place for these things to happen. It is also actively evolving. personal-view To a large extent, the stresses that are felt as the ASF grows are actually a result of our success, and should not be looked at as signs of failure. I remember a statement from a consultant that one of my employers brought in along the way to deal with some important decisions when we had no consensus at all: The absence of stress is death. So, here's to having some more stress! :-) /personal-view Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
RE: Why you *want* to be on the PMC
Quoting Noel J. Bergman [EMAIL PROTECTED]: Henri Yandell wrote: If all the PMC's share the same website, who is responsible for the website as a global concept. For example, the need to do mirrors. If a Jakarta-Site PMC exists, all other PMCs [jakarta sub-project based] are accepting the Jakarta Site PMC's oversight over their websites. How do you think the Jakarta site works already? The site2 module is just the core Jakarta site. All of the projects already have their own sites in their own CVS, which are then checked out under the /www/jakarta.apache.org/$project. And all of those $project sites are under oversight of the Jakarta PMC. There is no such thing as a jakarta sub-project based PMC. Nothing would have to change, unless a project *wanted* a new domain, from what I can see. Am I missing your point? I'm just not seeing the problem. Although I'm sympathetic to the idea that Jakarta sub-projects who then become TLPs might want to maintain their jakarta.apache.org/$project web site for brand identification purposes, I'm concerned about the potential for external confusion over who's in charge here. The reality would be that the Jakarta PMC would (correctly) *not* think they had management over that subdirectory of the site, but the legal distinction would be very likely missed by anyone who is visiting. If/when Struts becomes a TLP, I'm going to recommend that we do exactly what Ant, James, and Maven (for example) did: * Maintain a link on the Jakarta home page under Related * Install a webserver redirect from http://jakarta.apache.org/struts to http://struts.apache.org. --- Noel Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] HiveMind Service Framework
Quoting [EMAIL PROTECTED]: Part of the proposal indicates the jakarta-commons is not the right home for HiveMind, as it does not fit in with the charter of the commons (too many dependencies, etc.). Even if it were proposed that Hivemind stay in jakarta-commons, I do not share Martin's concern. There have been several cases where a number of new-to-Jakarta committers have joined, and (because of the technical limitations of our permissions infrastructure) have been granted jakarta-commons karma to work on the package they are interested in. In practice, this has not caused any problems. If we are still concerned that it might, we've got a jakarta-commons infrastructure issue to deal with, not a concern about any particular package and its associated committers. -- [EMAIL PROTECTED] Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changes to the jakarta-site
On Thu, 4 Sep 2003, Henning Schmiedehausen wrote: Date: 04 Sep 2003 10:49:50 +0200 From: Henning Schmiedehausen [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General Mailinglist [EMAIL PROTECTED] Subject: Changes to the jakarta-site Hi, I'd like to put some update about the Turbine project and also yours truly into the jakarta-site. Unfortunately, I lack the necessary karma. What can I do / whom must I contact to change this? I've granted karma on the jakarta-site repositories for you. I've attached two patches that I'd like to see applied. :-) Regards Henning Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
Snipping to an issue I have with one particular comment. On Thu, 3 Jul 2003, Andrew C. Oliver wrote: In summary the most serious issues to this proposal are: 1. diversity of committership. I'd personally like to see 51% of the ACTIVE committership from a different company. So long as a decision in one company can MAKE the vote, you don't have an Apache project, you have a corporate subproject at Apache. Andy, I agree with you that diversity is important, but your proposed standard (more than half the committers from elsewhere) has some distrubing implications that are worth exploring. * There is an implied assumption that the proposed committers will behave the way that their employer wants, not the way that they want. Although it is too simplistic to say that this never happens (our individual actions are public record, so of course you take into consideration what your employer might think), developers that are solely corporate mouthpiece players should never have been elected as committers in the first place. * There is an implied assumption that all the committers from the same company will vote the same way. I can tell you from lots of experience over the last few years (some of it pretty painful and personal) that this is not likely to be a problem. If it is, then we screwed up on accepting the original committers in the first place. * There is an implied assumption that a person's employer (and therefore their corporate email address) should have anything to do with whether or not that person is individually a good choice for being an Apache committer. THAT should be the overriding concern -- after all, they will be able to stay a committer even if they move to a different job (within the same company or elsewhere). * What happens to your diversity statistics if a committer that was originally outside the originating company is then hired by that company to continue working on the project? One of the company's goals might well be to support open source by allowing that person to work on the project on company time; yet your proposed standard would view the change of employment as a negative and not a positive. Apache is about individuals, not about companies. Apache is about attracting high quality software projects, not about conspiracy theories (go back in the archives a couple years before you joined, and you'll see LOTS of discussion along these lines :-). Diversity is important -- a proposal that ONLY has committers from one company needs to be analyzied. But a proposal that includes a software contribution from a company, but WITHOUT any committers from that company willing to continue working on the software (the throw it over the wall scenario) would also be problematic. Simplistic standards like 51% of the ACTIVE committership from a different company might work for making simplistic decisions. They are not appropriate for a decision to accept a new project into Apache, which should be based on the quality of the proposed code and the proposed initial committers, not on the email addresses of the proposed initial committers. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal: Jakarta should protect community email addresses
On Fri, 27 Jun 2003, Andrew C. Oliver wrote: Date: Fri, 27 Jun 2003 11:26:04 -0400 From: Andrew C. Oliver [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Proposal: Jakarta should protect community email addresses I'd be all of this if it would make a difference, unfortunately you're barking up the wrong tree. I'm getting that virus/attachment to every email address I have just about. I think it looks locally (user address book, etc). That is exactly what happens with this particular worm. If your address is in the address book of someone who gets infected, not only do *you* start to receive the messages, messages with forged from headers with your name on them also go out. Then, the volume of messages is made worse by all of those helpful spam filters that catch the fact that the virus is included, and return a notification to the (forged) sender. Obscuring email addresses in the archives would have zero impact on this particular problem. Craig (just cleaned out about 300 of these from this morning's mail) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adminitrivia: Assigning new bugs to the list
On Fri, 4 Apr 2003, Howard M. Lewis Ship wrote: Date: Fri, 4 Apr 2003 10:44:26 -0500 From: Howard M. Lewis Ship [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Adminitrivia: Assigning new bugs to the list Currently, new Tapestry bugs are all assigned to me, personally. I would prefer that new bugs be assigned to the Tapestry developer list. Is there a way to do this cleanly in BugZilla, or do I create a fake user ([EMAIL PROTECTED])? The latter is how we've done it for several other projects, and seems to work fine. You'll probably want to disable the fake user's login after it's created, so that nobody accidentally uses that account. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] promoted sub-projects
On Wed, 19 Mar 2003, Danny Angus wrote: Date: Wed, 19 Mar 2003 10:11:17 - From: Danny Angus [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: [PATCH] promoted sub-projects Although I've got karma I thought I should get some kind of opinion.. This patch moves ANT, AVALON and JAMES links from the sub-projects into a new menu section promoted. Should I apply this, or just remove James and Avalon (ant is already gone), or do nothing, or do something different? Personally, I'd vote for Promoted -- even though my head knows better, my fingers still go to jakarta.apache.org first for Ant updates :-). d. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On Tue, 11 Mar 2003, Andrew C. Oliver wrote: Date: Tue, 11 Mar 2003 22:09:14 -0500 From: Andrew C. Oliver [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Jakarta: too many similar projects? Thanks Pier. Thats a great perpective. Lets have some more. Anyone have a remarkably positive Gee the JCP listens to everyone and I can disclose everything to my fellow committers and its been great for our community? Andy seems to believe that *implementing* a specification (as opposed to creating one) is not a valid itch to be scratched if he doesn't like the mechanism by which the specification is created. It's perfectly reasonable for Andy to decide that for the projects he gets personally involved in, but it seems awfully arrogant to argue that no one at Apache should involve themselves in such an implementation project on that basis. As it turns out, there is substantial room for innovation and debate in the implementation of API specs like servlet and JSP (see the history of Tomcat development, and the recent innovation going on there for an example), just like there is lots of room to be creative in implementing something like HTTP, which has been done, and continues to be done, in a very large number of implementations in a very large number of languages -- despite the fact that the W3C standards process, like many others, includes periods of time when only the privileged few are allowed to be involved. -Andy Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Karma request jakarta-site2
On Thu, 27 Feb 2003, Howard M. Lewis Ship wrote: Date: Thu, 27 Feb 2003 14:33:13 -0500 From: Howard M. Lewis Ship [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: 'Jakarta General List' [EMAIL PROTECTED] Subject: RE: Karma request jakarta-site2 I'd like to join the bandwagon. I would like karma and permission to advertise major Tapestry releases on the Jakarta main page. Also done. Howard, the procedures to update the Jakarta web site are documented at: http://jakarta.apache.org/site/site2.html which is (recursively :-) generated from file xdocs/site/jakarta-site2.xml in the jakarta-site2 repository. You won't be able to do the Modifications of the Website step, which actually updates the web server's HTML pages, without a login account on daedalus -- contact [EMAIL PROTECTED] for that -- but any changes you make and check in to jakarta-site2 will be reflected when the next person who can performs that last step. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Karma request jakarta-site2
On Wed, 26 Feb 2003, O'brien, Tim wrote: Date: Wed, 26 Feb 2003 19:12:51 -0600 From: O'brien, Tim [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: 'Jakarta General List' [EMAIL PROTECTED] Subject: Karma request jakarta-site2 Was trying to add my name to the whoweare.xml list. Could I get some karma? Done. Tim O'Brien Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing again.
On Mon, 10 Feb 2003, Timothy Halloran wrote: Date: 10 Feb 2003 13:43:24 -0500 From: Timothy Halloran [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Licensing again. Does this mean the ASF has taken away the ability for others to do derived works (including derived works that make the code commercial or GPL -- with a simple name change)? That would mean the license is no longer open source (by OSD anyway)? People who *use* Apache code are free to use it in any way they want (subject, of course, to the Apache license requirements). That means that they can incorporate GPL/LGPL code on their own -- no problems. The user of Apache software can even redistribute Apache+GPL code in a package if they want -- nothing has changed there. The issue at hand for Apache is what are the license terms that cover the code that Apache *itself* distributes? Users of Apache code, quite naturally, will assume that the Apache Software License covers *all* the code in that distribution. That assumption is violated when a GPL/LGPL package is included, and this matters a *lot* to organizations that, for whatever policy reasons, choose not to utilize GPL/LGPL code. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing again.
On Sun, 9 Feb 2003, Ellis Teer wrote: Date: Sun, 09 Feb 2003 18:41:54 -0800 From: Ellis Teer [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Licensing again. Ditto plus some, Seeing the license issues discussed is also of interest to end users who are under that license. And for list members are faced with similar issues in other projects. It should be noted that Apache Software Foundation members are the legal *owners* of the software that is available under the Apache Software License. Indeed, that is one of the key benefits to becoming an ASF member, as opposed to just a committer on one or more projects. It seems perfectly reasonable that decisions on the license under which that software is licensed should be made by the people that own it. Craig McClanahan PS: Yes, I am an ASF member, and therefore one of those owners. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Maven as a top-level apache project]
On Fri, 7 Feb 2003, Dan Diephouse wrote: 4. Can ASF Projects use Sun BCL licensed products? Yes, but ASF can't distribute them. Each product you download from Sun's java.sun.com web site has a license that you have to agree to in order to download that JAR. In the case of several commonly useful packages (including, for example, JavaMail, JAF, and the JDBC 2.0 optional package (jdbc20ext.jar)), the license terms allow you to redistribute the JAR under a set of conditions that you need to agree to by accepting the license agreement -- the fundamental issue that affects this discussion is that you cannot distribute it *separately*. (See the individual licenses for other requirements.) Including such JARs in a product, like Tomcat or James (for example) do, is fine. Checking them in to an Apache CVS repository is not fine (because it is then available individually to anyone with CVS access; given that Apache repositories offer anonymous CVS access to anyone who follows the instructions, that is clearly a problem). Note that it is perfectly acceptable for *you* (as someone who wants to build a package that includes the Sun JARs whose license allows redistribution) to download your own copy of these packages (after agreeing to the license terms), and include them in the distributions of your own package. If you are using an automated build tool, you should configure it to utilize repositories where you are satisfied that *your* compliance with license requirements is appropriately dealt with. If you have any questions on the terms of the Sun BCL license for a particular package, and how they apply to you, go to the appropriate download page, such as: http://java.sun.com/products/javamail/ and click the download link. Then *read* the terms and conditions of the license agreement that is displayed, rather than just blindly accepting it, or believing what anyone else says about it. We are all responsible for our own behavior, and ignorance of the requirements is not a legally defensible excuse. Dan Diephouse Craig McClanahan PS: You should note that Apache Software Foundation downloads are subject to a license, just like downloads from most software providers. In the case of Apache-originated packages, the license is the Apache Software License, Version 1.1 -- a copy of which can be found at: http://www.apache.org/LICENSE Just because the terms of this license give you lots of latitude in how you use the software you download does *not* absolve you from meeting the requirements that are outlined there. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No reply from root
On Fri, 24 Jan 2003, Jeffrey Dever wrote: Date: Fri, 24 Jan 2003 12:22:01 -0500 From: Jeffrey Dever [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: No reply from root I am the release prime for the commons-httpclient component. I have made several attempts to have a user added as a committer, but there is no response from multiple requests to [EMAIL PROTECTED] [EMAIL PROTECTED] is several people, all of whom are pretty busy, and supporting the Apache infrastructure is done at the expense of their sleep hours :-). Sometimes it takes a couple of days. I will forward the new account request again to make sure it doesn't fall through the cracks, and then set up the CVS commit karma correctly when the account is set up. Craig Can someone please: 1) determine if someone is actually reading the mail sent to root. 2) create a committer account for this very deserving contributor. New committer: Oleg Kalnichevski [EMAIL PROTECTED] Project: Jakarta Commons HttpClient Userid: oleg Voting results: +1 Jeff Dever [EMAIL PROTECTED] +1 Dion Gillard [EMAIL PROTECTED] +1 Ortwin Gluck [EMAIL PROTECTED] Thanks, -jsd -- 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: Forum Software.
On Wed, 22 Jan 2003, Robert Simmons wrote: Date: Wed, 22 Jan 2003 18:52:12 +0100 From: Robert Simmons [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Forum Software. Then how do you answer the following issues: 1) The vast majority of Jakarta users will not want to be inundated with email on a daily basis. They either wont bother to read it or will unsubscribe. This will ultimately cost us hundreds of potential developers that might have wanted to work on a part of a project but didn't know about the issue. If users can't be bothered to figure out how to use folders and filter rules, they are perfectly free to use the various mail archive sites to search through the messages for previously posted information. An alternative to folders+filters for folks who have crippled mail readers is to subscribe in digest mode instead - that way you only get one message per day per list. A third alternative, as others have pointed out, is to use sites that mirror the mailing lists as newsgroups. 2) The emails are intrusive and disruptive. Its as bad as getting advertising. You care for a while but then after a couple days of deleting conversations not relevant to you. Subsequently you stop answering questions and then you just unsubscribe. This means other users don't have the benefit of your expertise. Forums are totally useless to me, becuase it forces me to go *ask* to participate. Mailing lists get fed to my machine (nicely filtered into a folder for each list, with the default sort sequence set to threading) in the background, and I can go scan a few messages from interesting lists whenever I feel like it. No mailing list message is *ever* sitting in my INBOX, so they don't bother my normal flow. To say nothing of the fact that, since I operate quite often from a laptop, I can read and answer mailing list messages when I'm offline and then send them later when I reconnect. 3) The lack of a complex search engine makes looking for information a hit and miss gesture at best. The archive search engines just aren't sufficient. Search engines for forums can't do any better when the keywords you are looking for are not present in the underlying messages. 4) Mailing lists exclude non-developer casual users of the software from being able t ask questions. If they do subscribe to one, especially for a popular product, they get blasted with hundreds of emails they don't care about. After they get their specific question answered, than they unsubscribe to the list. This robs the list of other qualified people to answer questions. Say, for example, I was an advanced Ant user and subscribed t the list to ask a question about writing my own tasks. Once I'm answered, if ever, I unsubscribe to the list. Now all the knowledge in my head that I could have given to another user asking a question is out of the community. On the other hand, if there was a forum, I could pick and choose what to reply and not be intrusively bothered with questions that I don't care about. I've been a heavy participant in STRUTS-USER (2616 subscribers) and TOMCAT-USER (2410 subscribers), the two largest user lists at Jakarta, for many years, and have not had your experience. Proper configuration of your mail reader can give you the organization and sorting capabilities that you like about forum based software, without eliminating the advantages for people like me. All of this boils down to the best communication strategy for an online project. That would be Bugzilla + forum software. Well, the mailing list volume would certainly go down by the number of questions *I* would not be answering any more if the user lists switched to forums. -- Robert Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
On Tue, 21 Jan 2003, Costin Manolache wrote: Date: Tue, 21 Jan 2003 11:31:32 -0800 From: Costin Manolache [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: New Jakarta proposal: Pluto Alex McLintock wrote: At 17:41 21/01/03, you wrote: One more question: why not doing this as a subproject of JetSpeed ? It is an existing jakarta project, the scope matches - why creating a separate jakarta community instead of joining the existing one ? I assume that it would be a tool which could be used by the Cocoon portal system, and a Struts portal system as well as Jetspeed which is essentially a Turbine portal system. People may want to use this component without using Jetspeed. Of course I haven't read the JSR yet. My understanding was that Jetspeed goal is to implement a portal - with Java and XML. I would rather see all portal systems sharing a single community and implementing similar behavior/standards - rather than have one portal for each technology ( struts, cocoon, turbine, tapestry, plain JSP, plain servlet, whatever else toolset ). One thing to remember is that JSR-168 is only standardizing the interface between a portal server and the portlets it calls (just as the servlet spec only defines the interface between a servlet container and the servlets). The architecture of the portal server itself (or the servlet container itself) is not being mandated. Therefore, it's entirely reasonable to have a single portal server implementation (created with whatever server-side technologies the developers of the portal server choose). But it's also reasonable to have different portal servers with different feature sets, aimed at different markets, if that is what folks want to do. But, as Costin says, that should *not* be driven by the technology used to implement the portal server itself. Where the frameworks need to get on board, IMHO, is making it easy to create standard *portlets* using that framework's technology -- that way, someone who wants to deploy a portal is not constrained to only using web components implemented on a single particular framework. And portlet-based Struts applications (for example) could be plugged into anybody's portal server as long as it supports the standard portlet API. Costin Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [discussion] jakarta-gump as community property
On Thu, 19 Dec 2002, Sam Ruby wrote: Date: Thu, 19 Dec 2002 12:21:03 -0500 From: Sam Ruby [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [discussion] jakarta-gump as community property Gump is now two years old. It has had contributions from over a dozen people, about a half-dozen this month alone. There seems to be a renewed interest in gump (some in response to a little nudging grin). Considering all of this, what I would like to propose is that the contents of jakarta-alexandria/proposal/gump get moved to jakarta-gump, all committers to any jakarta code base be given karma and voting rights on the full contents (descriptors, code, and stylesheets alike) and that a single [EMAIL PROTECTED] mailing be created (we are all devs here, right?) Thoughts? I like the idea of Gump becoming community property, but should it really be only for Jakarta committers? I'm thinking in particular about groups like Ant and Avalon (recently graduated into full fledged Apache projects), as well as the XML packages that Gump also watches over. - Sam Ruby Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Short Apache licence for source files
On Thu, 5 Dec 2002, Tim Vernum wrote: Date: Thu, 5 Dec 2002 10:12:37 +1100 From: Tim Vernum [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: 'Jakarta General List' [EMAIL PROTECTED] Subject: RE: Short Apache licence for source files From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] OK, I think I understand slightly better but our license refers to this software not to any specific file. IANAL, IAN-Roy, IAN-ASF, but... The license does not give any indication of what this software is. i.e. It doesn't define the scope of the piece of work to which it applies. Thus when Roy said: 'The problem with the 1.1 license is that it lacked a way to define the scope of what was covered beyond this file.' It means just that - the 1.1 license doesn't define what it applies to. It refers vaguely to THIS SOFTWARE, but that's all. The concern is that if it is not directly included within the source files then the scope of THIS SOFTWARE is unclear. Does it include all the source? What about the included jars? What if those jars are not under the ASF license? This not the case in the GPL (http://www.gnu.org/licenses/gpl.txt) because Term 0 of the GPL defines (ot attempts to define) the scope of the work. My understanding is that License 2.0 will include a similar item (but I'm basing that on guesswork). Current drafts of the 2.0 license include a solution to this issue, plus a whole bunch of other niceties. Discussions of the new license are happening on a mailing list dedicated to that purpose. In the mean time, I believe all Apache projects should treat the Board member comments quoted above and elsewhere in this thread (and taken out of much larger discussions) as authoritative direction to ASF committers that we should use the long form of the ASF 1.1 license in every source file checked in to Apache CV repositories. It doesn't matter whether it's legally required (to get around the this software interpretation) or not. It matters that the ASF Board (representing the foudnation, which is the owner of all this code) told us to do it that way. That's all the reason any of us should need. While it should be clear to normal people what this software means, lawyers have a nasty habit of not seeing the obvious :) Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [xdocs] Bug report (fwd)
On Mon, 25 Nov 2002, Henri Yandell wrote: Date: Mon, 25 Nov 2002 18:17:09 -0500 (EST) From: Henri Yandell [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: [xdocs] Bug report (fwd) I originally mentioned this on the Commons list, but as xdocs are used pretty heavily across Jakarta, I thought I'd try here too. I have a bug with the site generation. Either that or user-stupidity. I want a url in the xdoc file which has 's in. What's worked for me is to just use the XML entity (amp;) instead of the ampersand in cases like this. Give it a try. If I just do it the html way, xdocs aren't handled as the parser complains about them and doesn't do an output file. If I do them the xml way and make them amp;, then the generator doesn't properly turn them into 's again for the html. Is there a solution? The url in question is the evil: http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=RESOLVEDbug_status=VERIFIEDbug_status=CLOSEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Commonscomponent=Langshort_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitnewqueryname=order=Reuse+same+sort+as+last+time Hen Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: karma for jakarta-site2
On Fri, 4 Oct 2002, mohammad nabil wrote: Date: Fri, 04 Oct 2002 14:39:51 +0200 From: mohammad nabil [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: karma for jakarta-site2 hi, hope somehuman read any of my mails to jakarta community. i would like to help in any thing, but it seems that only mail machines read my email :s i hope to hear from any one alife at there :D Mohammed, The best way to get involved at Jakarta is to find one or more projects you are really interested in, sign up for the developer mailing lists, and start submitting patches and enhancements. The general procedures are outlined on the Jakarta web site, starting at: http://jakarta.apache.org/site/getinvolved.html Welcome! Craig -Mohammad Nabil From: Jeff Dever [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: karma for jakarta-site2 Date: Thu, 03 Oct 2002 20:28:04 -0400 I would like to add some info to the jakarta-site2 module. Could somone hit me with the karma? Jeff Dever HttpClient 2.0 release manager -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Send and receive Hotmail on your mobile device: http://mobile.msn.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Poll result] Committers, who are we?
On Sat, 5 Oct 2002, Pier Fumagalli wrote: Date: Sat, 05 Oct 2002 02:44:19 +0100 From: Pier Fumagalli [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: [Poll result] Committers, who are we? On 4/10/02 14:49, Andrew C. Oliver [EMAIL PROTECTED] wrote: I'd be more interested to hear statistics on how many people are California-based versus non-California based. (It would help me with my research into Apache cultures and cliches ;-) for a paper I'm writing ) More than being in CA, I would say, how many of us have been there and did the Silicon Valley thing... I'm saying that because I spent 2 years in CA, and feel strongly related to that environment... Only thing is now I live in London (UK)... I appreciate the willingness of Pier (and others) to work there. All I can say is that *not* moving to the Bay Area was a condition of me accepting my job at Sun ... :-) Pier Craig McClanahan (happily working from Portland, Oregon) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: You guys are so funny.
On Thu, 2 May 2002 [EMAIL PROTECTED] wrote: Date: Thu, 02 May 2002 14:24:58 -0700 From: [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: You guys are so funny. Berin Loritsch says: There are other dirty underhanded things that M$ did to get where it is today. Don't try to compare us to M$. We're not M$. Whenever someone tells me how much MSFT has done for technology, I can't help but think of how far we might have gotten if MSFT hadn't been so in the way all these years! For all the nasty things Microsoft has done over the years, they have also been pretty good at one particular thing -- asking their customers (and potential customers) what they want, and listening to the answer. It seems to me that authors of a build environment that they want everyone to use would think about going and asking the potential users (i.e. committers on various other projects) what their requirements are, before any attempt (by those authors, or by anyone else as was the case that started this particular flamefest) to shove it down everyone's throats. This is a characteristic of pretty much every company that gains long term and/or mainstream acceptance for their products. Too bad some open source developers haven't learned that the same principles can apply here. Jeff Sexton Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: You guys are so funny.
On Fri, 3 May 2002 [EMAIL PROTECTED] wrote: I think I've been saying this long enough. . MERGE MERGE MERGE! smiling I can't help sitting here thinking about how the committers on projects being told to MERGE MERGE MERGE must feel like two young adults whose parents want them to get married (and have kids), but they don't even know if they like each other yet ... /smiling Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: You guys are so funny.
On Fri, 3 May 2002 [EMAIL PROTECTED] wrote: [snip] As for people shoving Maven down other people's throats, I'd like to know where the Maven developers have been doing that. From what I can see the Maven developers have been fairly balanced. As I tried to point out in my parenthetical remark -- it wasn't the Maven committers who started this whole thing ... it was our favorite iconoclast himself (Jon), who seems to believe that anything that makes him happy should make everybody happy, and anyone with contrary opinions is just not with it enough to be worthy of being listened to. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [New Subproject Proposal] ObjectBridge
On 29 Apr 2002, Jason van Zyl wrote: Date: 29 Apr 2002 14:41:20 -0400 From: Jason van Zyl [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [New Subproject Proposal] ObjectBridge Hi, I would like to propose ObjectRelationalBridge (http://objectbridge.sourceforge.net/) as a top level subproject of Jakarta. +1 Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jakarta subproject scope (was Re: Quick! convert all your projectsto maven!)
On Wed, 1 May 2002, Geir Magnusson Jr. wrote: Date: Wed, 01 May 2002 00:41:23 -0400 From: Geir Magnusson Jr. [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: jakarta subproject scope (was Re: Quick! convert all your projects to maven!) On 5/1/02 12:28 AM, John McNally [EMAIL PROTECTED] wrote: On Tue, 2002-04-30 at 20:38, Geir Magnusson Jr. wrote: On 4/30/02 11:31 PM, John McNally [EMAIL PROTECTED] wrote: I do not know where to locate Turbine's original charter and I think it is a good idea to try to follow it. Are these published somewhere or should Turbine maintain it in its own documentation? However the scope of a subproject is likely to grow/evolve over time. Velocity does provide at least one servlet that allows it to be used to develop a webapp independent of any other framework. I think that's stretching 'webapp' I guess tomcat does the same thing as it supplies servlets... :) Well I would not be bothered if tomcat had developed a build system that it packaged as an independent entity with the idea that it might be more generally useful. Tomcat is a large project and they certainly could have had the itch. And if they promoted it occasionally what's the big deal. joke If you have ever built tomcat from source, you might wish they had a build system... /joke That used to be true - I don't know if it is anymore. Actually, Tomcat *does* include a nice little build system for web apps -- in the Application Developer's Guide. Among other things, it sets up your compile class path to include everything Tomcat has in its shared repositories (common/lib and so on) for you. In the HEAD branch, and in the 4.1.0 test release, it even includes custom Ant tasks that interact with the Manager webapp to install, reload, and uninstall apps dynamically. The difference is that we don't badger people into using it -- their choice. :-) Struts is adding support for Velocity even though one of its primary reasons for being proposed with Turbine already existing was to limit the view to jsp exclusively. I think you are mistaken - we are building a toolkit to use Velocity as the view layer in Struts Struts isn't adding any support AFAIK. Okay, I guess I could argue that developing a taglib (or something more elaborate) is outside the scope of a project around a template engine. We have one of those too. :) Lets you do wacky things like jsp:useBean id=mybean class=GeirBean / body vel:velocity strictaccess=true #set($mybean = $scopetool.getPageScope(mybean)) #if(true) this is true! #end br $mybean.string br #foreach($item in $mybean.array) $item br #end /vel:velocity /body /html Hey Geir, I though there weren't any scriptlets in Velocity? :-) Except that I am arguing against such strict definition of scope. And from what I saw I thought it was pretty cool. But I understand the point. What we are hoping to do is to make tools/support so you can use Velocity templates as a view layer in Struts, so you have a choice about the view layer, like you do in Turbine. :) For us, it's all about making it easier to use Velocity as it isn't An Official Standard. This concludes the Velocity/Turbine/Struts plug-fest. :) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting POC lives! Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Java is dead... but it could still be saved!
On Sun, 24 Feb 2002, Stefano Mazzocchi wrote: Gosh, I think I'll have to write my own programming platform one day to avoid all this. I thought you already did ... you mean I *cannot* write device drivers and run them on Cocoon? Rats ... :-) Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: PMC Nomination - Craig McClanahan
On Fri, 1 Feb 2002, Morgan Delagrange wrote: Date: Fri, 1 Feb 2002 16:16:55 -0600 From: Morgan Delagrange [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED], Morgan Delagrange [EMAIL PROTECTED] To: General Jakarta [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: PMC Nomination - Craig McClanahan I would like to nominate Craig McClanahan for re-election to the PMC. I accept nomination for re-election to the PMC. You can find out more about me on the Struts Who We Are page: http://jakarta.apache.org/struts/userGuide/volunteers.html At Apache, I got involved in the Apache JServ project before there was a Jakarta (along with other long timers like Jon, Pier, and Stefano), and at the ApacheCon just after the Tomcat source code was finally handed over to Apache, told James Duncan Davidson in front of several hundred people that the Sun code sucked ;-). (Want proof? Just go back to the sources for Tomcat 3.0, but don't do this on a full stomach ;-). Over the last couple of years, I've been a big-time contributor on Tomcat (Catalina's architecture is basically what Apache JServ 2.0 was going to be), Struts (I'm the primary architect), and Commons. Along the way, I've been somewhat less involved with Taglibs and Watchdog. I'm also a pretty good chunk of Apache's user support on the TOMCAT-USER list. I believe in Apache's goals w.r.t. open sourcing Java. I don't have a lot of patience for diatribes and mailing list flame fests -- they tend to be counterproductive to these goals. Therefore, you'll see more CVS commits than discussion participation from me when the topic strays in those directions. (Interestingly, the overall level of CVS commits seems to be inversely proportional to the vitriol in the current discussions ...) One last note -- as most of you are probably aware, I work for Sun. If that fact, by itself, affects your vote, then you need to think about how much you really believe in Apache's credo that contributors should be judged on what they do, not who they work for. (I'm sure you can find plenty of other reasons not to vote for me, if that's what you want ;-). - Morgan Delagrange Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: possibly bug with tomcat 4 vs oracle 8.1.7 ??
On Tue, 29 Jan 2002, Giovanni Zorzan wrote: Date: Tue, 29 Jan 2002 17:17:00 +0100 From: Giovanni Zorzan [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: possibly bug with tomcat 4 vs oracle 8.1.7 ?? we try to use JDBCStore against a Oracle 8i database. the connection works (and tomcat insert some rows into table session), but in the log we have seen this: This is a posting that should be directed to the TOMCAT-USER list, not here -- subscription information, as well as documentation on what each mailing list is for, can be found at: http://jakarta.apache.org/site/mail.html Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: BCEL project bug databas
Stephen, I can help you get this set up. Please send me offline what you'd like for: * Description of BCEL * Identifier and description of each component (so people can submit bug reports against that component * Version numbers to list in the bug database. Craig McClanahan On Thu, 24 Jan 2002, Stephen Cheng wrote: Date: Thu, 24 Jan 2002 17:22:44 + From: Stephen Cheng [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: BCEL project bug database Hello comrades, Is there a bug database for BCEL? I have found a bug in BCEL but unfortunately the project had not been added yet to http://nagoya.apache.org/bugzilla/. Thanks, Stephen -- 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: [PROPOSAL] POI @ Jakarta
+1 Craig On 17 Jan 2002, Andrew C. Oliver wrote: Date: 17 Jan 2002 14:45:26 -0500 From: Andrew C. Oliver [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: general at jakarta [EMAIL PROTECTED] Cc: POI Development [EMAIL PROTECTED] Subject: [PROPOSAL] POI @ Jakarta Proposal for POI - A Jakarta Subproject version 1.0 - 17 Jan 2002 (0) rationale The POI project seeks to provide pure Java APIs for reading, creating and manipulating files written in formats based on Microsoft OLE 2 Compound Document Format. The POI project has already successfully created a Pure Java OLE 2 Compound Document Format library (POIFS) and a port of the Microsoft Excel '97(-2002) file format (aka XLS, BIFF8) and tools for serializing XML in these formats (which will be hosted as part of Cocoon 2). The POI project user community is growing leaps and bounds in usage as evidenced by its position as one of the most active projects on SourceForge and the 2,290 people who have downloaded it so far this month. The POI project currently has two active developers. The development community might be small but is fanatically committed (and growing rather quickly). It is likely that the upcoming port of the Microsoft Word 97 File format will increase the size of the development community, not to mention the user community. The documentation is comprehensive and includes full documentation on the previously undocumented (or at least incompletely documented) Microsoft OLE 2 Compound Document Format. There are also HOW-TO documents that illustrate use cases and examples. Lastly, The project founders have agreed to collaborate with a developer at the OpenOffice.org project on the Excel File Format Documentation. Many Jakarta projects could potentially take advantage of POI and its use in Jakarta will likely further seed the POI developer community. POI is a unique project in the Java world. Up until now there have been no successful free attempts to provide read/write access to OLE 2 CDF or MS Excel (97+) file formats. POI coupled with other Jakarta technologies could produce some highly useful offspring. A few specific examples might be Office Document indexing for Lucene, Velocity generating Excel and Word document presentations, Office document management capabilities for Slide as well as content delivery and editing in Turbine. POI would make it possible to use Jakarta and XML-Apache projects in many cases where currently a proprietary solution is currently required. (1) scope of the subproject The subproject shall create and maintain packages written in the Java language, intended for use in generating and reading files in formats based on the OLE 2 Compound Document Format. (2) identify the initial source from which the subproject is to be populated The initial packages would be based on existing POI codebase currently located at SourceForge: http://poi.sourceforge.net (3) identify the Jakarta resources to be created (3.1) mailing list(s) poi-user poi-dev (3.2) CVS repositories jakarta-poi (3.3) Bugzilla program - poi components - Web site, POIFS, HSSF, HDF (3.4) Jyve FAQ (when available) poi-general poi-poifs poi-hssf poi-hdf (4) identify the initial set of committers Andrew Oliver Marcus Johnson (5) identify apache sponsoring individual Stefano Mazzocchi -- 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]
Re: [PROPOSAL] Jakarta PMC bylaws change
On Wed, 16 Jan 2002, Sam Ruby wrote: Date: Wed, 16 Jan 2002 14:27:54 -0500 From: Sam Ruby [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [PROPOSAL] Jakarta PMC bylaws change The number of PMC seats will be set at seven. Annually, all seven seats will be up for renewal. The ASF board will be asked to provide a person or persons to administer the nominations and a subsequent ballot. The administrator(s) will determine the mechanics of the voting procedures. Any committer to any Jakarta code base will be eligible to vote. Once the new PMC is in place, the first order of business will be to determine a chairperson from amongst their ranks. Once ratified, this proposal would be effective immediately, and an election would be initiated. +1 - Sam Ruby Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: commit mails not send
Gerhard, They went to the moderator queue, and I just OK'd them. We'll fix the mail permissions to let these go directly shortly. Craig On Sat, 12 Jan 2002, Gerhard Froehlich wrote: Date: Sat, 12 Jan 2002 18:02:02 +0100 From: Gerhard Froehlich [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: commit mails not send Hi (Sam), when I commit things into jakarta-commons-sandbox no commit mails are send. Could [EMAIL PROTECTED] please check this? TIA Gerhard - Never share a foxhole with anyone braver than you are. - -- 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: Groupware Website Recommendations
On Fri, 11 Jan 2002, Edson Alves Pereira wrote: Date: Fri, 11 Jan 2002 13:21:55 -0500 From: Edson Alves Pereira [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: RE: Groupware Website Recommendations Sourceforge.net is free and it has mailing list, cvs, ftp, webhost. CollabNet (employers of several familiar faces around here :-) is pretty good at hosting this sort of thing too (NetBeans, OpenOffice, ...). Craig Ted Husted [EMAIL PROTECTED] wrote: I'm working on an (unrelated) projects with some people, and wouldn't mind setting up an Apache-style collaborative environment. Just wondering if anyone has any personal recommendations for + A free groupware host, with calendar, mail-list/BBS, file upload that sort of thing. I know there are several but wondered if someone was using one they liked. + A private, fee-based sourceforge, where someone could collaborate on a private software project (I guess sourceforge may go fee-based, but I was wondering about someone who was already doing it). Of course, any place where you could setup some mailing lists and a CVS might work for the second. Just wondered if anyone was already doing that successfully for a reasonable price. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- /// Better well done than well said. --//-- To follow the path: look to the master, follow the master, walk with the master, see through the master, become the master. Modern Zen poem /// __ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
On 9 Jan 2002, Andrew C. Oliver wrote:
Date: 09 Jan 2002 00:07:00 -0500
From: Andrew C. Oliver [EMAIL PROTECTED]
Reply-To: Jakarta General List [EMAIL PROTECTED]
To: general at jakarta [EMAIL PROTECTED]
Subject: Re: Code conventions
It's only two little lines extra to include the {}'s,
Yeah, but those two lines will make my code run slower.
Don't you know?
The less space your source code takes, the less space
your class file will take.
And smaller classes run faster.
It must be true - 90% of people I've worked with seem
to live by that principle.
Add to that the fact that if it was hard to write, it should be hard to
read...
:)
Someone told me if you use a really small font like courier 6pt then
you don't even need an optimizing compiler.
Thanks to this conversation, I finally did think of a good reason to use
braces on a separate line (which I detest, but that's just me) -- if your
manager judges you on how many lines of code you write, you get two free
lines for every if statement.
:-)
-Andy
Craig
--
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: proposal for the jakarta startpage
On Mon, 7 Jan 2002, Peter Donald wrote: Watchdog is TC specific - didn't know that ? Is it servlet/jsp specific or tomcat specific? Could it be reimplemented over the top of Cactus or is it tied to a specific infrastructure? Watchdog is not Tomcat-specific - the validity tests should work on any container that implements the appropriate servlet and JSP specifications. It's based on the same tests that are in the J2EE compliance test suite (CTS). Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: crushed
On 7 Jan 2002, Andrew C. Oliver wrote: 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 know it's hard to tell from the convoluted way this thread have gone back and forth, but the comment above was not intended to have *anything* to do with POI specifically, or the proposal to move POI to Apache. It was a response to Ceki's concern about how to keep Jakarta from being just a SourceForge-type code repository. I'm trying to digest the discussions about POI, but they keep getting buried in the discussions about Jakarta's future ... I haven't made up my mind yet on this specific proposal. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Status [was Code conventions]
On Fri, 4 Jan 2002, Ceki Gülcü wrote: - Sam Ruby P.S. Food for thought: wouldn't it be nice if we could somehow merge xml and Jakarta? Then discussions as to where POI should go would be moot. Gump doesn't care about these arbitrary distinctions, why should we? +1 on the principle of merging Jakarta and XML. Agreed that it's definitely worth looking at. However, you realize there are technical considerations such as the look and fell of the merged web-site. Sheesh ... just when I was starting to think that *nothing* could top the rancor of arguing about coding conventions ... :-) Ceki Gülcü - http://qos.ch Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: More abuse of coding styles...
On Fri, 4 Jan 2002, Erik Hatcher wrote: Date: Fri, 4 Jan 2002 19:27:52 -0500 From: Erik Hatcher [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: More abuse of coding styles... Rule #1 from The Elements of Java Style is: Adhere to the style of the original IIRC, we actually had this rule explicitly in the JServ code conventions ... looks like it didn't make the transition into the Jakarta docs though. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
On Tue, 1 Jan 2002, Ted Husted wrote: Date: Tue, 01 Jan 2002 14:54:30 -0500 From: Ted Husted [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Just the JARs Geir Magnusson Jr. wrote: Putting aside *all* the stuff we are talking about for a moement, and looking at the simple notion of just having release jars available w/o docs, source, etc I don't think this is a bad idea :) However Any license issues? Wouldn't we want to package the jar w/ a license ? This simple notion -- and my putting together a Jakarta release HOWTO -- is why I opened this particular thread. The license issue is well taken. I think it would be a good practice for us to include a license in all of our JARs. Even when we don't distribute them seperately ourselves, they are intended to be distributed seperately by our licensees. Point noted. How about including a copy of the LICENSE file in the META-INF subdirectory of each JAR file produced by an Apache project? -Ted. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Coding style addition
On 15 Dec 2001, Kevin A. Burton - burtonator wrote: Perhaps. It might be a good idea to have a default recommendation or a global standard. ... anyway... The most entertaining flamewars I've ever seen are atempts to gain consensus on whether to use tabs or not, and then how many characters an indent is :-). Kevin Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comment for Apache.org
On Tue, 11 Dec 2001, robert burrell donkin wrote: if you want things to change, then you need to do something about it (am i sounding like jon? ;) if you were to answer newbie questions - to the best of your ability - then jon wouldn't have to make time to answer them. there's something in it for you too, since you'll learn far more by answering questions than you will by lurking. everybody would be a little happier. This version of this same old thread isn't going to accomplish anything. However, as a person who has been around Apache for a long time (including working with Jon directly on Apache JServ), as a person who contributes a lot of code also, and as a person who *does* take the time to do what Robert suggests and answers user questions (striving to do so in a manner that is polite and respectful, and *usually* succeeding at that), I'm going to add one and only one comment. I vastly respect Jon's contributions to Apache -- but I'm disappointed that he doesn't seem to care that his approach to email makes the overall community smaller than it otherwise would be (due to people not being willing to deal with his style). Now, I'm going to go back and start writing some more code (and answering some more user questions). I suggest we all do the same. - robert Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Cross site scripting
On Wed, 21 Nov 2001, Danny Angus wrote: Date: Wed, 21 Nov 2001 07:51:55 - From: Danny Angus [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: RE: Cross site scripting Craig wrote: That seems like a lot of extra work, and is unnecessary if all the dynamic output is processed appropriately. out of curiosity why do you say that, the unnecessary part? IF 100% of the dynamic output (i.e. the part that an attacker might be able to exploit) is generated by JSP custom tags (or equivalent, for other technologies) that properly filter for dangerous characters, AND if your static output is already immune to exploit (because the app developer already checked it for vulnerabilities), THEN any effort exerted by the container to filter *all* occurrences of et. al., followed by reconverting the safe occurrences, is wasted. IMHO, this is much more an application issue than a container issue. However, Jon is asking for container-based solutions -- I guess that requiring the use of Strut tags for all your output qualifies. :-) Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Cross site scripting
The code that Struts uses (which is probably closest to your proposed
getEscapedHtml() method) is the filter() method in
org.apache.struts.util.ResponseUtils. But the mechanics (change any
occurrence of '', '', '', or '' to the corresponding escape sequence)
is the easy part of the problem. The harder part is making sure that all
your webapps practice safe sex and use CSSCondom. :-)
I don't know of any generic solutions to the getStrippedHtml() or
removeScriptTag() methods you propose - but are they still necesary if you
do the getEscapedHtml() processing on everything?
Craig
On Wed, 21 Nov 2001, Jon Stevens wrote:
Date: Wed, 21 Nov 2001 00:49:36 -0800
From: Jon Stevens [EMAIL PROTECTED]
Reply-To: Jakarta General List [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Subject: Re: Cross site scripting
on 11/20/01 11:54 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote:
However, Jon is asking for container-based solutions -- I guess that
requiring the use of Strut tags for all your output qualifies. :-)
Craig
Sigh. I am *not* asking for a container based solution.
Because something got lost in your translation of what I'm saying, just to
be clear, I'm asking for a library that takes a String as input and returns
a String as output and provides the various encoding scheme's for preventing
CSS attacks (it seems like none of them are a magic bullet, but combined,
they do the job depending on the level of protection you need).
Something like:
public class CSSCondom
{
public String getEscapedHtml(String input);
public String getStrippedHtml(String input);
public String removeScriptTags(String input);
}
Velocity has a cool feature where you can attach what are called
EventCartridges to items in the Context so that when they are rendered in a
template, code is executed. This is similar to having a taglib bean return
data that has been 'protected'.
http://jakarta.apache.org/velocity/developer-guide.html#EventCartridge%20an
d%20Event%20Handlers
In this case, I'm developing a ReferenceInsertionEventHandler that would
rely on this general CSSCondom library to help protect me from unwanted
outcomes.
Thanks.
-jon
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Using bzip2 for tarball
On Tue, 20 Nov 2001, Tim Vernum wrote: Date: Tue, 20 Nov 2001 10:30:47 +1100 From: Tim Vernum [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: 'Jakarta General List' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Using bzip2 for tarball From: Daniel Rall [mailto:[EMAIL PROTECTED]] GOMEZ Henri [EMAIL PROTECTED] writes: What about using the bzip2 format for tarball along with gzip and zip format ? You have my +1, though I would instead recommend using bzip2 instead of gzip. +1 on adding bzip2 -1 or removing gzip I'm +0 on bzip2, but also -1 on removing gzip. Many (most?) non-linux users don't have bzip2 binaries, and forcing people to download the (somewhat larger) .zip files would most likely result in a net increase in traffic. Beyond the size difference, zip files do not faithfully maintain Unix file and directory permissions, leading to all sorts of niggly problems such as unpacking things with executable shell scripts. Craig -- The information contained in this email is confidential. If you are not the intended recipient, you may not disclose or use the information in this email in any way. Macquarie Bank does not guarantee the integrity of any emails or attached files. -- 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: Integration
On Sat, 3 Nov 2001, Frans Thamura wrote: Date: Sat, 3 Nov 2001 01:16:01 +0700 From: Frans Thamura [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Integration Dear All, I see there is a lot of API in Apache... Jakarta and XML who resposible for integration, or is there a project for integrating of it.. I think we need that. esp, the documentation.. there is several issue said this.. you must post this to this mailing list.. and bla..bla..bla.. Take a look at Alexandria http://jakarta.apache.org/alexandria. This deals with the consolidated documentation problem, but you are still going to be directed to the project-specific user lists for project-specific questions. Frans Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Distributing the JSSE
On Fri, 2 Nov 2001, Guillaume Rousse wrote: Date: Fri, 2 Nov 2001 15:30:56 +0100 From: Guillaume Rousse [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Distributing the JSSE Ainsi parlait Kasper Nielsen : so this is an US export law issue and not a Sun License issue? I think so. It would be possible to distribute it but it would take a lot of work to get all paper work done and I think there was other conditions (ie must be us citizen, must get the connections from embargoed countries blocked etc) thats strange on http://java.sun.com/products/jsse/index-102.html they have a link to Download JSSE 1.0.2 global software and documentation with support for strong encryption. and a Download JSSE 1.0.2 domestic (US/Canada) software and documentation with support for strong encryption Don't know what the difference is, but I would imagine its legal to distribute something that is allready allowed to be globally distributed? Sofar no one answered this mail... Does US crytopgraphy export restrictions apply to both version of JSSE, or only to domestic version ? And do these restictions apply everywhere, or only for US-based download location ? Said otherwise, can jpackage project (jpackage.sourceforge.net) provide JSSE global version packages, as any other Sun java API packages, eventually only on non-US mirrors, or is it a special case ? Crypto is different because of US export laws. The Sun redistribution licenses for JSSE have the same basic terms as the redistribution licenses for the other Java APIs (see the license you had to click through to download it for details.) -- Guillaume Rousse [EMAIL PROTECTED] GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Distributing the JSSE
On Fri, 26 Oct 2001, Peter Donald wrote: Date: Fri, 26 Oct 2001 16:21:46 +1000 From: Peter Donald [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Distributing the JSSE On Fri, 26 Oct 2001 02:16, Kasper Nielsen wrote: Because the amount of paperwork needed to legally distribute it is hge. The US export laws do allow non-profits and indviduals to distribute crypto things but they have to jump through a few hoops and make sure they fill out oodles of stuff. Avalon was going to distribute it until Craig dropped a note on commons or ant list regarding this and gave a link. I followed it and it was much too much work to get it done legally so we dropped it. Craig do you still have that link ? I cannot find the original link that I forwarded, but got it off the JSSE web site. It had to do with the still-existing registration requirements for people who want to export crypto software. so this is an US export law issue and not a Sun License issue? I think so. It would be possible to distribute it but it would take a lot of work to get all paper work done and I think there was other conditions (ie must be us citizen, must get the connections from embargoed countries blocked etc) Yep. -- Cheers, Pete Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BCEL @ Jakarta
+1 Craig On Mon, 8 Oct 2001, Jason van Zyl wrote: Date: Mon, 08 Oct 2001 11:37:25 -0400 From: Jason van Zyl [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: BCEL @ Jakarta Hi, Markus has just informed me that he has removed the GNU regexp dependency from the BCEL and is using the Jakarta Regexp package. I think it was generally agreed that the package is complete, highly useful and many people expressed an interested in having it be a Jakarta project. Markus has already made a first pass at organizing the source in a Jakarta like format and I have offered to help with the rest of work if we agree to accept the package into Jakarta. So, for the movement of BCEL to apache I would like to vote +1 -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Making Commons-Cactus a top level projet
I've set up the new top-level entry. Let me know what components and versions you would like set up, and I will do those as well. Craig On Sat, 15 Sep 2001, Vincent Massol wrote: Date: Sat, 15 Sep 2001 14:15:36 +0100 From: Vincent Massol [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED], Vincent Massol [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [VOTE] Making Commons-Cactus a top level projet Can someone add Cactus to the Apache Bug Database (as a top level project) and remove its entry from Commons (as a sub component) ? Or tell me how to do it ... Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Making Commons-Cactus a top level projet
On Thu, 13 Sep 2001, Vincent Massol wrote: Date: Thu, 13 Sep 2001 17:37:54 +0100 From: Vincent Massol [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED], Vincent Massol [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [VOTE] Making Commons-Cactus a top level projet +1 Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] Tomcat 4.0 Release Candidate 1 Available
The first Release Candidate for Tomcat 4.0 is now available. Only serious problems will be fixed between now and final release of Tomcat 4.0, which is currently scheduled for September 17, 2001. A second release candidate, if necessary, will be distributed on Thursday, September 13. Please download this version and run your existing web applications against it, to help us ensure a final release that is as trouble free as possible. The release is available at: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-rc1/ and bug reports should be submitted to: http://nagoya.apache.org/bugzilla/ under product category Tomcat 4. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possible bug in web.xml
Thanks for the report - I just checked in patches that will be reflected in tonight's nightly build (and shortly on the web site as well). For project-specific documentation like this, it would be helpful to submit bug reports against the documentation for that project. Craig McClanahan On Mon, 6 Aug 2001, Wooyoung Kim wrote: Hi, I don't know if someone else already reported the bug... There are couple of typos in the example web.xml given in the documentation. http://jakarta.apache.org/tomcat/tomcat-4.0-doc/appdev/web.xml.txt In line 78 and 82, /paramName should be /param-name regards, -wooyoung _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Enhancement to jakarta-site2 -- XSLT stylesheet equivalent tosite.vsl
On Fri, 27 Jul 2001, Jon Stevens wrote: on 7/27/01 12:08 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: Please help me debug this stylesheet, and improve its compatibility with site.vsl, by checking out the jakarta-site2 module and running the xslt target. NOTE: you will need to make sure that your Ant install includes the appropriate optional.jar file, and has access to either JAXP/1.1 (crimson.jar, jaxp.jar, and xalan.jar) or Xerces+Xalan. Craig McClanahan For the life of me, I can't get the .jar file foo correct... Empty classpath, right? -jon [204][ ~/checkout/jakarta-site2 ]% ant xslt Buildfile: build.xml xslt: [style] Transforming into /Users/jon/checkout/jakarta-site2/xslt [style] Loading stylesheet /Users/jon/checkout/jakarta-site2/xdocs/stylesheets/site.xsl [style] Failed to read stylesheet stylesheets/site.xsl BUILD FAILED /Users/jon/checkout/jakarta-site2/build.xml:103: javax.xml.transform.TransformerConfigurationException: Namespace not supported by SAXParser --- Nested Exception --- Total time: 2 seconds [205][ ~/checkout/jakarta-site2 ]% dir $ANT_HOME/lib/ total 1584 Ant 1.3, right? 0 drwxrwxr-x 9 jon staff 262 Jul 27 13:49 ./ 0 drwxrwxr-x 9 jon staff 262 Mar 11 13:40 ../ 4 -rw-r--r-- 1 jon staff 153 Mar 2 04:46 README 292 -rw-r--r-- 1 jon staff 295934 Mar 2 04:46 ant.jar 184 -rw-rw-r-- 1 jon staff 187246 Mar 23 17:23 crimson.jar 244 -rw-rw-r-- 1 jon staff 247802 Mar 14 07:09 jakarta-ant-1.3-optional.jar 8 -rw-r--r-- 1 jon staff5537 Mar 2 04:46 jaxp.jar 136 -rw-r--r-- 1 jon staff 136198 Mar 2 04:46 parser.jar 716 -rw-r--r-- 1 jon staff 732330 May 23 05:45 xalan.jar In my JAXP/1.1 release (and my $ANT_HOME/lib directory), file sizes are: 187162 crimson.jar 28404 jaxp.jar 801714 xalan.jar [206][ ~/checkout/jakarta-site2 ]% dir lib total 1668 0 drwxrwxr-x 9 jon staff 262 Jul 27 13:47 ./ 0 drwxrwxr-x 18 jon staff 568 Jul 27 13:43 ../ 0 drwxrwxr-x 6 jon staff 264 Jul 16 16:08 CVS/ 292 -rw-rw-r-- 1 jon staff 295934 Mar 11 13:48 ant-1.3.jar 184 -rw-rw-r-- 1 jon staff 187246 Mar 23 17:23 crimson.jar 28 -rw-rw-r-- 1 jon staff 28404 Mar 4 05:35 jaxp.jar 80 -rw-r--r-- 1 jon staff 78541 Feb 14 11:56 jdom-b6.jar 368 -rw-rw-r-- 1 jon staff 373565 Apr 30 13:24 velocity-1.0.1.jar 716 -rw-r--r-- 1 jon staff 732330 May 23 05:45 xalan.jar This stuff shouldn't matter when you execute the ant script directly, instead of through build.sh/build.bat. The key issue is that ant resolves to $ANT_HOME/bin/ant for the $ANT_HOME library directory you listed above. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts install - error in SilverStream install doc (fwd)
Forwarding to STRUTS-DEV, where this kind of a report belongs. GENERAL is for discussion of Jakarta-wide project issues, not project-specific things like this. Craig McClanahan -- Forwarded message -- Date: Thu, 19 Jul 2001 19:25:49 -0700 (PDT) From: Armen Papshev [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Struts install - error in SilverStream install doc Hi, I found small discrepancy at http://jakarta.apache.org/struts/installation-sas.html contents for struts-example-depl-plan.xml should be as attached below. - cut here - ?xml version=1.0 encoding=UTF-8? !DOCTYPE warJarOptions PUBLIC -//SilverStream Software, Inc.//DTD J2EE WAR Deployment Plan//EN deploy_war.dtd warJarOptions warJar warJarNamestruts-documentation.war/warJarName isEnabledtrue/isEnabled urlselstruts-example/el/urls /warJar /warJarOptions - cut here - urlselstruts-documentation/el/urls should be changed to urlselstruts-example/el/urls This way if struts-example.war and struts-documentation.war deployed to the same server servlet urls would not conflict since struts-documentation.war is listening on struts-documentation url. Thank you Armen __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Three Commons Packages Released
The Jakarta Commons package is pleased to announce the availability of Version 1.0 releases of three packages: * Beanutils - Generic manipulation of JavaBeans wrapped around the Java reflection APIs, including the ability to get and set nested and indexed properties. * Collections - A wide variety of classes that conform to the API contracts of the Java2 Collections APIs. * Digester - Rules-based processor for XML input streams, providing a much simpler interface than the standard SAX APIs. The fact that these packages have been released means that they are considered to be of production quality (and therefore worthy of being relied on by other projects), and that -- consistent with the charter of the Commons project -- backwards API compatibility will be maintained to the largest possible degree to protect dependent projects from arbitrary API changes. The source and binary distributions of these packages can be found at: http://jakarta.apache.org/builds/jakarta-commons/release/ beanutils/v1.0/ collections/v1.0/ digester/v1.0/ Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal to make BSF an ASF project
On Fri, 22 Jun 2001, Bill Stoddard wrote: The common criteria that we use for any new project is to ask what the existing developer and user community is like. I know that there is a large user community, but what is the developer community like? BSF does not have a large developer community; Victor, Chuck and perhaps 3 other folks from IBM and a handful of occasional submitters. This is definitely not a high volume project. Bill +1 for BSF as a Jakarta project. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT] Struts 1.0 (Final) Released
As promised at JavaOne, the Struts project team is proud to announce the availability of Version 1.0 (final release) of the Struts Framework. The binary distribution is available at: http://jakarta.apache.org/builds/jakarta-struts/release/v1.0/ and the source distribution is available at: http://jakarta.apache.org/builds/jakarta-struts/release/v1.0/src/ Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: doinking around with a logo
On Thu, 14 Jun 2001, bill parducci wrote: Pier P. Fumagalli wrote: bill parducci at [EMAIL PROTECTED] wrote: The little thinghie over the latter a is Copyright by Sun... it is LIKE it, but not the same. so i would disagree. I wouldn't want to even _raise_ the question with Sun... :) Pier well, yeah, there is that. then again, who knows with those guys? you might find them monitoring the list ready to make you put '(r)' every time you use java in an e-mail! :o) You should see what the Sun lawyers made us do on our JavaOne session slides ;-). b Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lucene acceptance in Jakarta
+1 (back at home recovering from J1). Craig On Fri, 8 Jun 2001, Ted Husted wrote: Was there a post with a [VOTE] header? +1 I think Craig and Geir are tied up with Java One this week. Jon Stevens wrote: Re: Lucene being added as a Jakarta Project. 5 of 10 (not counting Duncan) of the PMC members voted +1. The rest haven't voted (shame on you). Can I please get the rest of the people to cast a vote? thanks, -jon +1 Daniel F. Savarese [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] Ceki Gülcü [EMAIL PROTECTED] Peter Donald [EMAIL PROTECTED] Jon S. Stevens [EMAIL PROTECTED] No vote: Pierpaolo Fumagalli Ted Husted Geir Magnusson Jr. Craig McClanahan Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Theft of authorship
On Thu, 7 Jun 2001, Ceki Gülcü wrote: Hi Jon, I am referring to otherwise honest people who choose to contribute their enhancements back to the project. They create new classes but in the process remove the names of previous authors. They do this in good-faith as otherwise they would not have contributed their code. I think it is a question of culture/custom. It could be as innocent as someone not understanding that multiple @author tags are legal. But you don't know until you ask to the individuals involved why this happened, and encourage them to behave differently. I do not think we have a document outlining authorship rules. Does anyone know one? Regards, Ceki I think this is really a significant question. How significant a patch does it take for someone to legitimately be considered an additional author of a particular source file? Attribution in a CVS commit should always be there -- but is that really enough. Unfortunately, I don't have time at the moment to come up with ideas for a document describing reasonable policies for making such a decision -- but it would be useful to have such a thing (i.e. I vote +0 :-). Craig At 11:51 07.06.2001 -0700, you wrote: on 6/7/01 11:42 AM, Ceki Gülcü [EMAIL PROTECTED] wrote: This comes up from time to time and usually has me jump through the roof. Good willing contributors, take a piece of existing log4j code, modify or enhance it, but remove the previous author's names. They then post their code as if it was their own. Regardless of how much they modified the code, by removing the previous author's names they are committing theft. I find this very disturbing. What do others think? What can we do to combat this phenomenon? Regards, Ceki There is a difference between doing this accidentally and doing it on purpose. If it is determined that it is done on purpose and the people who did it refuse to follow the license, then the Jakarta PMC should be notified and we can sick the ASF Legal team on the problem. Note, this seems like it would be a last resort type of situation. The best is to try to at least discuss with the villains (jokingly said) first and make sure that it was not intentional. -jon -- Open source is not available to commercial companies. -Steve Balmer, CEO Microsoft http://www.suntimes.com/output/tech/cst-fin-micro01.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ceki Gülcü - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat as webserver
Your best bet would be to ask Tomcat-specific questions like this on the TOMCAT-USER mailing list (send an empty message to [EMAIL PROTECTED] to subscribe). You'll find thousands of people there who use Tomcat in a large variety of ways, including as a stand alone server. Craig McClanahan On Fri, 18 May 2001, Edson Alves Pereira wrote: Hello dudes! I wondering about is secure use Tomcat only as web server insteed Apache? With best wishes, Edson Alves Pereira __ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Jakarta Deprecation Policy
On Tue, 15 May 2001, Jon Stevens wrote: Well, there haven't been many flame wars around here recently, so let me start one. I seem to be good at that. :-) What I propose is that we take this document (or one similar to it) and migrate it up to the overall Jakarta Project instead of just being a Turbine policy and get all the projects to sign their name on it. http://jakarta.apache.org/turbine/deprecation.html I think it would go a long way towards raising awareness of the need to deprecate things (thanks to Sam starting this with Gump) as well as make the corporate types feel more comfortable with regards to depending on that Open Source Software stuff... Comments? I'm generally +1 with the concept of having a deprecation policy guideline, but have some suggested clarifications: * It would seem that a deprecation policy like this should be enforced only after a version 1.0 release. Prior to that time, you're still experimenting and defining architectures and interrelationships, so you don't really want to commit to anything until 1.0. * Carrying on with that, a typical major release (2.0, 3.0, ...) will often be substantially different internally than the one before. It seems reasonable to say that the overall compatibility guarantee lasts only within a major version series -- although you would not want to arbirarily change APIs at the next major version without a good reason. * It's sort of implicit in your policy, but there are no guarantees in nightly builds -- only releases -- right? Otherwise, you will risk slowing down development progress more than is necessary. * If your definitions of product version numbers matches the typcial (major.minor.maintenance), I think it's way way way too fast to deprecate something in 2.1 and remove it in 2.1.1, no matter what the time interval is. It would seem to me you would want to keep the deprecated calls through the next minor version (2.2 in the case at hand). Of course, if it were up to me, I'd say that API changes should be disallowed in x.y.z maintenance releases, except perhaps to fix serious bugs. On a more philosophical note, a deprecation policy like this can cause a little conflict when you sit it next to the release early release often mantra we like to quote. People using this policy will want to think a little longer than the might otherwise about what newly added features should look like before creating a release containing them. Once you've done that, the toothpaste is out of the tube, and you're stuck with the original APIs for longer than you might otherwise want to be. -jon Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed dirlayout document
On Tue, 8 May 2001, Ceki [iso-8859-1] Gülcü wrote: Agreed. Mandating that the docs contained in the distribution and the docs available on the jakarta web server match exactly is too restrictive. +1 -- it should be up to the project. I've got projects that do it both ways. However, allowing the user to browse the documentation locally from the files contained within the distribution is a nice feature. Wouldn't you agree? Also +1. One approach is to include a webapp of static HTML files that the user can drop into their container (if they have one), or use as a static directory of files (if they don't). Ceki's description of log4j's doc dance works, but makes altering www docs post-release tricky. I think docs are likely to be a bit behind the curve, particularly for smaller projects. True. So, the current system of checking out www docs from cvs makes sense - it allows doc amends for last release to be tracked. I think no one is contesting that tracking source files using CVS is a good idea. However, the CVS update operation is one way of copying the latest version of doc files to the jakarta web server. It is certainly not the only way. Reading your comments below, I think that we are actually in total agreement. I'm not a fan of the way jakarta-site2 makes you check in the generated HTML either. I'd rather see the cycle work like this: Local machine: - Edit XML (or whatever) sources - Generate and test - Check in XML sources Daedalus: - Check out XML sources - Generate in place Formerly, we didn't have a useful Java2 environment on the server (locus). Now we do -- let's use it :-) Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed dirlayout document
On Mon, 7 May 2001, Ceki [iso-8859-1] Gülcü wrote: At 10:02 07.05.2001 -0700, you wrote: On Mon, 7 May 2001, Ceki [iso-8859-1] Gülcü wrote: I have asked this before but is there a need for an intermediary directory? For example, to take an example I am familiar with, Tomcat 4.x, a damn good project I might add, has a build/ directory and a dist/ directory where dist/ is a copy of build/. I do not know why Tomcat is doing this but it is. Other projects are doing similar things. I am obviously missing something... The two targets are *not* identical. Tomcat developers want to do the minimum amount of work necessary to create a runnable version of Tomcat -- thus, they execute the default build.xml target (deploy-main) that creates an executable Tomcat 4.0 in the build directory. To speed things up, this dispenses with Javadoc creation, JARing things up, and stuff like that. When you're ready to cut a release (or a nightly build), the dist target is used, which creates a complete binary distribution. Obviously, large parts of this can be copied from the build output (it would not make sense to recompile everything, and so on) -- but there are also additional steps. But this target is not used for daily development work. Bottom line -- having an intermediate build directory substantially improves the turnaround time for me as a Tomcat developer. Hi Craig, Thanks for taking the time to clarify the Tomcat build process. If I understand you correctly, the reason behind having two target directories is to speed up the creation of a work version of Tomcat. Would it not be possible to have a build target that just creates compiled classes, a jar target to create jar files, a javadoc target to create javadocs and a dist target to create a complete distro? (The dist target would depend on jar and javadoc targets. The jar target would depend on build.) Thus, it would be possible to have a working version by invoking the build target? Regards, Ceki Inside the scripts, that is essentially what happens. To create a runnable (for development) version of Tomcat 4.0 in a freshly checked out repository, simply execute ./build.sh in the top level directory. Then, set CATALINA_HOME to the build directory path (for me, that means /home/craigmcc/Jakarta/jakarta-tomcat-4.0/build), and start it up by saying $CATALINA_HOME/bin/startup.sh (or the equivalent if you're using Windows). The default target creates a work version in the build directory, without going to any efforts that are not yet necessary. The dist target assumes that the default target has been completed already (with a depends rule) and does some extra stuff to create the binary distribution -- which my nightly job does every night, and I do when I create a release. Otherwise, I never run the dist target. Tomcat is not just a JAR file when you get done with it -- you need a series of files in a series of directories to create the executable product. Therefore, in real life, the Tomcat build process is more complex than this in its details, because there are independent build.xml scripts for the major components (catalina, jasper, webapps) -- but they all follow the same basic philosophy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta-Turbine-Jyve
On Sat, 5 May 2001, Jon Stevens wrote: on 5/5/01 9:54 AM, Ted Husted [EMAIL PROTECTED] wrote: I think this is an important question, since the natural outcome of our providing open source frameworks is that people will eventually provide open source applications based on those frameworks. For example, I'm launching an online auction application Sunday for a public broadcasting station. My contract includes distributing the code as open source. I'd love to make that source available through Jakarta. If that happened, should it be jakarta-struts-gavel? Yes. We also have people working on Struts shopping cart application which could also go this route. So, I guess my only question is that if we have three or four application projects in the works now, do we want to think about a jakarta-app group? I don't actually care myself, but I thought I should ask the question. Na. I'm happy keeping them organized with their respective code bases. Also, that would bring up the question of re-organizing the Jetspeed project which has already been grand fathered in as a top level project. Turbine and Struts both need as many sample applications as they can get. Might as well organize them closely together so that their progress can be carefully monitored. That seems like a pretty reasonable incubator strategy for applications. The application developers will have direct access to the community that is familiar with the framework (and can positively impact the future development of the framework). The frameworks can use the apps as best practices examples of how they should be employed. Apps that resonate with the user community, and attract their own communities, can graduate to being full-fledged projects. After all, the original reason for Ant's existence was just to build Tomcat ... -jon Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binaries in CVS
On Fri, 13 Apr 2001, Geir Magnusson Jr. wrote: Sam Ruby wrote: Peter Donald wrote: The fact of the matter is you would contribute to it even if you had to pass the 12 heculean tests of power, jump tall buildings at lunch and beat deep blue on your breaks ... why ? It's your job. For the record, it is Craig's job because he did all the things you said, not the other way around. http://conferences.oreilly.com/java/sessions/bios.html Hey - Craig's picture :) And they list him as doing bizdev for 'DAT Services' Hmmm. I updated the bio information before the conference (DAT was my employer prior to Sun). They must be using a VB app or something -- the update never got committed :-). I'll try again. -- Geir Magnusson Jr. [EMAIL PROTECTED] Developing for the web? See http://jakarta.apache.org/velocity/ Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binaries in CVS
On Fri, 13 Apr 2001, Ceki [iso-8859-1] Gülcü wrote: * How are you measuring "activity"? I would guess from your statement that you are talking about developers doing commits -- but what about they users who just want to USE your project in their own work and could give a rip about how the thing is built. By that measure, I would submit that Tomcat is far and away the most active Jakarta project, followed by Ant, followed by Struts, followed by everything else. (Check download counts and -USER list subscriptions and activity for corroborating evidence). Tomcat 3.x and Struts contains no checked in JARs, Tomcat 4 only has patched versions of the stupid JAXP sealed jars until the next version of JAXP fixes that for us. Are the stats available? If so, I would appreciate a pointer. For download counts, you have to go analyze the log files (and, of course, we're only counting downloads from daedalus -- not from mirrors). Tomcat runs in the 50k-100k downloads per month range -- having up to date stats would be quite nice. For mailing lists, the following are subscription counts as of this morning to the Jakarta-based mailing lists: alexandria -dev 65-user 57 announcements 4183 ant-dev 517-user 860 avalon -dev 104-user 22 ecs-dev 53-user 96 general 1165 jakarta-commons 72 james -dev 102-user 128 jetspeed -dev 153-user 202 jmeter -dev 45-user 71 log4j -dev 157-user 335 oro-dev 74-user 135 regexp -dev 97-user 156 slide -dev 193-user 283 struts -dev 610-user 1189 taglibs-dev 348-user 510 tomcat -dev 1082-user 2176 turbine-dev 190-user 304 velocity -dev 152-user 304 Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next PMC meeting times?
On Thu, 12 Apr 2001, Ceki [iso-8859-1] Gülcü wrote: At 11:42 12.04.2001 -0400, Sam Ruby wrote: At the last PMC meeting we scheduled the next PMC meeting for Monday, 16 April 2001 at 1900 GMT. Now that daylight savings time has swapped hemispheres, it might make sense to revisit this. The two somewhat workable times are 1200 GMT and 2000 GMT. I'd like to hear opinions on the following two options: A: 8AM California 11AMNY 1200GMT 1400Zurich 2200Melbourne +1 B: 4PM California 7PM NY 2000GMT 2200Zurich 0600Melbourne (Tuesday) 0K but A: is preferred. Either time is fine with me. = = = = = = = = Proposed Venue: irc: cvs.working-dogs.com:6667, #jakarta Proposed Agenda: 1. Old Business: 1.1 Ted: reformat the rules for revolutionaries document from an email to a bylaw 1.2 Ted: revise bylaws 1.3 Ceki: proposal for cvs layout build procedures As far as I know, no work has been done on the ANT build procedures yet. I'll have a shot at it unless someone else does it first. Ceki There's some discussion of this topic going on in jakarta-commons at the moment. For now it's same-old same-old, but who knows ... we might agree to agree someday, instead of agreeing to disagree. -- Ceki Gülcü Web: http://qos.ch email: [EMAIL PROTECTED] or [EMAIL PROTECTED] Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binaries in CVS
On Thu, 12 Apr 2001, Ceki [iso-8859-1] Gülcü wrote: Hi Craig, At 11:25 12.04.2001 -0700, Craig R. McClanahan wrote: Whether or not there is a nice, easy, "all in one" download with everything you need has absolutely nothing to do with whether binaries are checked into CVS. True. There is an important distinction indeed. Call it conventional thinking on my part. Nevertheless, it is quite natural to add binaries into CVS if they are part of the distribution. Quite natural to those who like it, quite unnatural to those who don't :-) So if I understand you correctly, then having binaries (e.g. jar files) in the distribution is OK but it less so to put the same binaries into CVS. Do I understand you correctly? Yep. That is why Tomcat binary distributions have everything you need to run Tomcat (except a JDK and the JSSE classes if you're using SSL). Why do you think that it is wrong to have binaries in CVS? All the disadvantages you listed. All the disadvantages Sam listed. The irrationality (IMHO) of checking generated artifacts into a source repository (same goes for HTML that's generated from XML in some projects, but we won't go there right now ;-) The fact that, once in a while, you have to do maintenance on a dialup connection instead of a nice fast DSL line. Case in point -- I had to update jakarta-site2 while at O'Reilly Enterprise Java over a modem connection, just after all the checked-in JAR files were updated to recent versions. It took 45 f*cking minutes to do the CVS update. Suffice it to say that the web site can go hang the next time I'm in that position. I haven't heard anyone dispute the former -- only the latter. Why are you linking the two issues? Granted, they are separate but related issues. Ceki Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binaries in CVS
On Thu, 12 Apr 2001, Ceki [iso-8859-1] Gülcü wrote: At 12:55 12.04.2001 -0700, Craig R. McClanahan wrote: [removed text] Why do you think that it is wrong to have binaries in CVS? All the disadvantages you listed. All the disadvantages Sam listed. Sam objects to early binding. In other words to packages assuming a certain version of a dependency project where different versions of the dependency package behave differently. Is that correct? I fail to see how this is *directly* related to putting binary files in CVS. Gump works regardless of what people put in their CVS modules. Right? Gump does that by overriding properties (same as a build.properties file does in the proposed approach). Given that you can make it work without JARs in CVS, let's turn the question around - what does it buy you to have them there? Yes, it's nice to newbies to have the defaults set up to minimize the effort of trying things. But that can be accomplished in other ways, without the disadvantages. The irrationality (IMHO) of checking generated artifacts into a source repository (same goes for HTML that's generated from XML in some projects, but we won't go there right now ;-) :-) That is a different issue. The fact that, once in a while, you have to do maintenance on a dialup connection instead of a nice fast DSL line. Case in point -- I had to update jakarta-site2 while at O'Reilly Enterprise Java over a modem connection, just after all the checked-in JAR files were updated to recent versions. It took 45 f*cking minutes to do the CVS update. Suffice it to say that the web site can go hang the next time I'm in that position. I certainly empathize with that. One question that needs to be asked is whether placing the updated binaries in CVS is the culprit. The "jakarta-site2" repository has the following JARs checked in: Ant 1.3 (296k) Jdom "b6" (78k) Velocity 1.0 (370k) Xerces 1.3 (1605k) All four had been updated. I just compared downloading ant.jar (295'948 bytes) using CVS update, scp and http. The results were roughly the same. A 512Kbit/sec link was used to perform the tests. Results may vary depending on server load. Assuming performance scales up or down linearly with bandwidth, then the logical conclusion is that the problem lies with the automatic and recursive updating done by "cvs update" and not the cvs/ssh channel per se. Probably, what you really wanted was to update the files under xdocs/ but not the jar files under lib/. I could certainly do that, but what if someone updated a doc and needs one of the new features? Doing this (re)creates a version incompatibility, which would defeat the whole point of having the JARs in CVS in the first place. So the automatic update done by CVS eases the distribution of binaries but also increases the communication/networking overhead. The overhead is particularly irritating if the changes in the binary are minor. In other words, putting binary files under CVS decreases the need for developer to developer communication but increases computer to computer communication. Cheers, Ceki Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binaries in CVS
On Fri, 13 Apr 2001, Peter Donald wrote: At 08:16 12/4/01 -0400, Sam Ruby wrote: If you accept that you are in a world where interfaces that you are depending on change frequently, then the problem to solve is optimizing the communication paths. I don't accept that reality. I bet that 98% of the servlets out there would compile just fine against a version of servlet.jar that was built two years ago. I bet that 98% of these servlets will compile just fine against the version of servlet.jar that will be built two years from now. The same can not be said for applications which depend on avalon or turbine. Not two years, not one year, not six months, not three months. Heck, I doubt that 98% of the applications which depend on turbine would compile against the version of turbine that WAS BUILT LAST NIGHT. Welcome to opensource! Standards are not done here - we can implement them but we don't build them - for those please go elsewhere (IETF/W3C/JCP/Other). One of the advantages of opensource is people are free to adapt them to their own environments. Hence they do. If you want static versions go buy something from a major vendor. Even those generally do complete changes every major version (see MS and their DX1-8 or MFC versions). In a backhanded way, I agree with this sentiment -- open source is demonstrably good at creating great implementations, and not so good at creating specifications. I suspect this is partly/mostly because many open source developers rebel against the very disciplines that a "standard" implies. (If you want a fight, let's talk about where the curly braces should go on an "if" statement :-). But this also raises an issue of who are the "users" we are trying to make life easier for. More on this below. Gump doesn't solve these problems. Peter Donald has outsmarted it. I haven't outsmarted it. I solved the problem that was presented. You have failed to pose any other problem that would make me adjust my position - I want low cost of entry. Have a look at all the projects under apache umbrella. Now rate the activity of each project excluding people who get paid to directly work on products. Now correlate this with cost of entry (of which jars in CVS is a factor). Excluding ant for the moment what do you see? ... Which ones have more community behind them? Which ones store binaries in CVS? Coincidence?? ;) This paragraph begs for multiple responses, from different viewpoints (not necessarily building on each other): * How are you measuring "activity"? I would guess from your statement that you are talking about developers doing commits -- but what about they users who just want to USE your project in their own work and could give a rip about how the thing is built. By that measure, I would submit that Tomcat is far and away the most active Jakarta project, followed by Ant, followed by Struts, followed by everything else. (Check download counts and -USER list subscriptions and activity for corroborating evidence). Tomcat 3.x and Struts contains no checked in JARs, Tomcat 4 only has patched versions of the stupid JAXP sealed jars until the next version of JAXP fixes that for us. * The number of binary distro downloads of most Jakarta projects is orders of magnitude more than the number of people who download source distros or update via CVS. Note that the popular packages for USERS include convenient "all in one" binary distributions, despite the fact that they don't use CVS to store JAR files. (Ant is sorta an exception - they offer two downloads (Ant and optional.jar) but you have to go grab everything else yourself). * There seems to be a theory that only people who build from source can contribute patches and enhancements. That is not borne out by experience on the projects I'm involved in, because the source code is there for examination anyway -- very large percentages of patches come from people who are just looking at the "src" directory included with the binary distributions. * Your exclusion of "people who get paid to directly work on products" in measuring activity doesn't sit well with me. Is my contribution to Tomcat *illegitimate* because I'm paid to do it? I guess we'd also need to throw out the contributions of lots of other people whose companies use Tomcat and who contribute to it on company time, but it's not their full time job. This kind of attitude denigrates the substantial contributions of lots of people; you might want to rethink it. * Finally, to show that I can be just as elitist :-), I'd say that being able to build something like Tomcat from sources (by following the directions included in the README) is a pretty good first level filter for people worthy of being committers in the future :-). The exception of course is Ant - it only stores the absolute minimum jars in CVS. It is still popular to developers though partially out of
Tomcat 4.0-beta-3 Released (SECURITY VULNERABILITY)
Tomcat 4.0-beta-3 is an update to the Tomcat 4.0-beta-2 distribution that was released on 30 March 2001. It fixes a further security vulnerability related to potentially exposing JSP source that was only partially corrected in beta 2. Anyone using versions of Tomcat 4.0 earlier than the beta 3 release (or the nightly build dated 20010403 or later) is strongly encouraged to immediately update to the beta 3 release. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Tomcat 4.0 Beta 2
On Sat, 31 Mar 2001, Kief Morris wrote: Craig R. McClanahan typed the following on 11:26 PM 3/30/2001 -0800 I'm pleased to announce the availability of the Beta 2 release of the next generation of the Tomcat servlet container, Rockin'! So can we consider the code unfrozen, or do we want to wait until the sealing problems are fixed and cut another release before making major changes? Go for it :-) IMHO, the current workaround to the sealing violation problem, plus the fact that you can now use Xerces 1.3.1 as your XML parser for Jasper, means we don't have to wait any longer to do the next round of feature additions. What I'd ask, though, is that we discuss any refactoring of the core interfaces (org.apache.catalina.Xxx) on TOMCAT-DEV first. These changes will affect people who embed Tomcat 4.0 in other environments, so we want to consider minimizing the disrputions this can cause. Kief Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Tomcat 4.0 Beta 2
On Sat, 31 Mar 2001, Willie Wheeler wrote: On Sat, 31 Mar 2001, Kief Morris wrote: Craig R. McClanahan typed the following on 11:26 PM 3/30/2001 -0800 I'm pleased to announce the availability of the Beta 2 release of the next generation of the Tomcat servlet container, Rockin'! So can we consider the code unfrozen, or do we want to wait until the sealing problems are fixed and cut another release before making major changes? I thought that the JSP classloader fix *is* the sealing problem fix, no? Sealing violations related to Tomcat's XML parser prevented the use of, say, JDOM as a parser for webapps, and prevented Cocoon from running in Tomcat 4.0. This was all from months ago so I forget exactly what the issues were. But Craig, if I understood your announcement correctly, this is what's now fixed... There are changes to the way Jasper loads its XML parser that apparently solved all of the sealing violation issues under JDK 1.2, but did not fix them all under 1.3. However, Tomcat 4.0 beta 2 includes a workaround to this problem by virtue of the fact that it includes unsealed versions of the jaxp.jar and crimson.jar files (pending discussions with the Crimson group on unsealing their next release). In addition, it was recently verified that Xerces 1.3.1 includes the JAXP/1.1 functionality that Jasper requires, so you can now use Xerces instead of Crimson if you wish. See the release notes (RELEASE-NOTES-4.0-B2.txt in the top level directory) for more details. Willie Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sun Article On Velocity
On Fri, 30 Mar 2001, Jon Stevens wrote: Velocity 1.0 will be released on Monday 4-2-01 (the article was published early). http://dcb.sun.com/practices/profiles/velocity.jsp :-) Congrats on your upcoming release! And it's refreshing to see Jon type a smiley after typing the ".jsp" in the above URL. :-) -jon Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] Tomcat 4.0 Beta 2
I'm pleased to announce the availability of the Beta 2 release of the next generation of the Tomcat servlet container, at: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b2/ Tomcat 4.0 beta 2 has many new features, including: * Tomcat 4.0 can now run web applications out of an unpacked directory or directly from a WAR file. * Web applications are now run under the control of a Java SecurityManager that can support fine-grained control over each web-app's access to system resources. * You can now specify a DefaultContext element in the server configuration file (server.xml) that defines default configuration information for contexts that are automatically configured. * An example Filter implementation that supports on-the-fly GZIP compression for clients that support it. * A servlet that implements all of the NCSA documented functionality for server side includes (*.shtml) except for the "exec" capability. * Standard resource factories for JavaMail related resources accessible via a JNDI InitialContext, compatible with J2EE Specification requirements. * Reflects the most up-to-date changes in the Servlet 2.3 and JSP 1.2 APIs that have been approved by the JSR-053 expert group, and will appear in the next published version of the corresponding specifications. In addition, the following major bug fixes are included: * Fixes for two reported security vulnerabilities (a "cross site scripting vulnerability" plus a "URL decoding vulnerability") * The JSP servlet (Jasper) that compiles and executes JSP pages now uses its own classloader its associated XML parser, which avoids potential conflicts with parsers included with a web application. * Bug fix updates for directory listings, the WebDAV support, binding to a single IP address (if requested), incorrectly named access log files, URL decoding improvements, form-based authentication, HTTP/1.1 chunking, isUserInRole(), JSP page parsing problems, and many other patches. See the Tomcat 4.0 Beta 2 Release Notes (RELEASE-NOTES-4.0-B2.txt) that are included in the top-level directory of the release for more detailed information. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] J2EEUnit donation to ASF
Catching up on this thread quite late, but ... On Tue, 27 Mar 2001, Vincent Massol wrote: It's a pity if I have to change the name ... I would of course very much prefer to keep it. But I can see your point. Let's wait for others to comment on that. The formal way to check Sun's position on this would be to send mail to "[EMAIL PROTECTED]" -- but I've already seen indications that "J2EEUnit" would be problematic because Sun asserts a trademark on "J2EE". The folks at the [EMAIL PROTECTED] address might have some suggestions on what would be found acceptable; I suggest you write them and ask about it. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts, velocity, turbine, jetspeed, lions, tigers and bears...oh my
On Fri, 23 Mar 2001, Kuster, Egon wrote: Thanks for the welcome. now it is time to start learning how to use turbine. Fun. Turbine + Jetspeed is a great combination if your application needs the kinds of features they offer. But if the best argument for Turbine is that "JSP sucks balls", I'd keep looking for some rational reasoning if I were you. :-) Seriously, every framework has sweet spots and areas they do not focus on. You owe it to yourself to evaluate your own needs against those capabilities. The best way to do that is prototype based on your own needs. Oh, by the way, don't forget to decide how the frameworks you look at are going to scale as your needs increase. For example, Jon (primary developer of Turbine) doesn't think much of EJBs either, so plan on having to deal with those kinds of complexities yourself if you need that type of functionality. Egon Kuster Craig McClanahan (primary developer of Struts) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Subprojects
On Thu, 22 Mar 2001, Jon Stevens wrote: on 3/22/01 7:23 PM, "Peter Donald" [EMAIL PROTECTED] wrote: No it couldn't from what I understand. Commons won't allow imports directly from turbine/avalon and to try to do such a complex system generic from start may be a bit of a PITA at this stage. Especially when both turbine/avalon already offer a lot of support. Woah. I didn't know that about the commons. So, we can't start with existing code already housed on our servers? If that is the case, I see no future for the Commons. In fact, looking at it... http://jakarta.apache.org/cvsweb/index.cgi/jakarta-commons/ There still isn't any code in there. All discussion and no code makes the Commons a dull boy. Guess I will just keep plugging away with the perfectly working Turbine Connection Pool and Scheduler Services :-) So, are you planning to propose these as reusable components after jumping up and down about sharing? tick ... tick ... tick ... (showing about as much patience as Jon ever does) ... yawn ... Nah, I didn't think so. :-) -jon Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session question
On Fri, 16 Mar 2001, [iso-8859-9] Altuð Altýntaþ (Koç.Net) wrote: Hi , i have got two contexts , one of them is VARDIYA and other one is CIS. Two of these contexts are implemented by using session object . You will do much better asking Tomcat-related questions on the TOMCAT-USER list. This list is for general discussions about the Jakarta project as a whole. i put username and password in my sessions( for VARDIYA and CIS context ) . What i want is , if i logon from VARDIYA context , then i dont want to logon CIS either . i mean using a same session but i can't do this .. my server.xml part is here : Context path="/CIS" docBase="webapps/CIS" crossContext="true" debug="0" reloadable="false" /Context Context path="/VARDIYA" docBase="webapps/VARDIYA" crossContext="true" debug="0" reloadable="true" /Context i have got tomcat 3.2.1 and soloris 5.7 . any idea ? Sessions cannot be shared across web applications. That is part of the servlet specification. However, it is possible (in Tomcat 4.0) to share user identity across web applications so your user only has to sign on once (he or she will have a session in each app). See the configuration documentation on the "Single Sign On" facility: http://jakarta.apache.org/tomcat/jakarta-tomcat-4.0/catalina/docs/ thanks Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PMC meeting agenda
On Tue, 13 Mar 2001, Sam Ruby wrote: Can we make this month's meeting on Friday? (Sorry Peter). Via IRC as Jon has suggested... Friday is fine for me (still 20:00 GMT?) -- please send the contact details privately. - Sam Ruby Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOTICE] + [PROPOSAL] nightly builds + nightly source checkouts
On Tue, 13 Mar 2001, Jon Stevens wrote: Hey all, [NOTICE] Brian asked me to remind you to clean up the nightly builds so that we don't have tons of old stuff eating up disk space. Example: /x2/www/jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly jakarta-tomcat-4.0/nightly du -sk 424790 . 424790 megs seems like a lot to me. Will be restarting my "clean out" job shortly. There are files all the way back to 20010216 which seems a bit excessive. Also excessive seems to be the .Z and .gz versions. I think it is safe to assume in this day and age that everyone can install gunzip on their server. [PROPOSAL] I would like to finagle this email into another discussion as well which is coming up with a more centralized system for doing nightly builds as well as nightly source checkouts. +1, but see further discussion below on the details Right now, we have cronjobs run by a number of different people putting files in a number of different locations. It would be nice to try to centralize this down to just one primary script and one configuration file that handles this the majority of this stuff. So, in the builds directory, I would like to propose setting something up that looks like this: /www/jakarta.apache.org builds/ scripts/ build-all.sh (or .pl or .py) cleanup-all.sh (or .pl or .py) build.conf projects/ velocity-source.sh (or .pl or .py) velocity-build.sh (or .pl or .py) tomcat-4.0-source.sh (or .pl or .py) tomcat-4.0-build.sh (or .pl or .py) ... ... build.conf: baseDirectory=/www/jakarta.apache.org/builds projectsDirectory=$baseDirectory/projects daysToKeep=7 We could then have the build-all script run through the projects directory looking for scripts to execute. It would first attempt to execute all of the "*source*" scripts it finds and then attempt to execute all of the "*build*" scripts it finds. What this would allow is for projects to have their own scripts to be run in order to do any source/build specific things for their projects. It would also allow for individual testing. Adding a new project is as simple as adding another set of scripts. We will want each subproject to maintain their own versions (e.g. tomcat-4.0-source.sh and tomcat-4.0-build.sh) according to the standard conventions, so that no one person would need to stay up to date on all the subproject build procedures. We will also want a few things like stable releases of Ant, XML parsers, etc. installed in "well known" places for build processes that require access to them. The individual scripts could set what their "output" directory is based on the projectsDirectory + projectName. projectsDirectory would be passed in to the source/build scripts on ARGV[0]. The cleanup-all.sh script would be a global cleanup script that would run at the end of the build-all.sh script to prune the files in the directories, keeping the "daysToKeep" number of files. I know that I have most of the framework already done for the "project-build.sh" scripts and the "cleanup-all.sh" scripts, but I don't have the frameworks for the build scripts, however, I know that some projects already have that. Maybe we could consolidate those into this system? Notes: In order to put a system like this into place, we will also need to have everyone shut off their existing cronjobs. :-) +1 for me (who does Servletapi, Tomcat 4.0, Struts, Watchdog), as soon as it is ready. Sam, I'm sure that this probably fits into Gump somewhere as well, however, I'm not sure I want to or feel the need to go that far and come up with the "perfect" solution at this point. What do you feel about that? IMHO Gump serves a different, also valid, purpose as a tinderbox detector of incompatibilities. The goal of nightly builds is different -- it is to create something that ought to be marginally usable. For that reason, a nightly build would use a stable Ant (for example), instead of hot-off-the-CVS code that Gump uses. That being said, it might well be possible to tweak the Gump scripts so that they operate in a different mode for nightly builds. Sam? Comments? -jon Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
"Geir Magnusson Jr." wrote: [EMAIL PROTECTED] wrote: If someone chooses to duplicate a piece of code, maybe the problem is with the way the code is written and shared. I think in some cases, its bacause people aren't aware that the stuff exists. Go through the Jakarta project sites, and find the number of places that offer a separate, clean FOO tool that supports BAR. (Choose your tool and it's expected functionality). One small proto-model of "shared code" code components already exists within the Jakarta community, and might serve as a starting point for discussions -- the Jakarta Taglibs project, which is focused on creating reuseable JSP custom tag libraries. The encouraged sharing is in this case at the end developer's application level, rather than within the Jakarta community itself, but some practices we created there might be useful models to look at. Basically, developers on Taglibs agree to the following conventions and policies: * No particular concern about overlaps of functionality - different applications care about different features and might appreciate alternative approaches. * Committers essentially take ownership of the pieces they care about, and agree to offer at least some level of ongoing support. * Organize their tag library directories according to standard conventions (source, example app, documentation) and package naming hierarchies that quickly become familiar to library users. * Construct semi-autonomous releases of individual tag libraries, plus a convenient way to go grab them all. Formal versioning hasn't been an issue yet because the whole thing is pretty new, but that will need to be addressed. * Make information (essentially, the documenation associated with each tag library) available online and accessible. Having one or more FOO modules in a shared library doesn't help any more than the current situation, if I don't know about them or cannot find anything out about them. It would seem reasonable to adopt some set of conventions like this for the sorts of code modules we're discussing here. That way, people whose itch is creating shareable modules have a place to showcase their wares, and people who would rather reuse than write have a place to "shop". As long as you avoid a rule that there will be only one kind of FOO in the library, that should avoid most of the potential conflict issues. In order to make this work, someone(s) needs to step up and organize the basic infrastructure, but after that it can be fairly self-sustaining. (And maybe Sam can extend Gump to see which individual modules are being used in which projects -- having your shared code selected by some other project is a pretty good vote on it's quality, plus an indication of who you should talk to before changing APIs ;-). geir Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
Peter Donald wrote: I would also like to hear from the struts bean utils. I haven't looked at them but I presume they would be general enough (or could be made so) so Ant2.x could use it (ie remove converter/introspector elemenets from Ant2.0 codebase). They are -- and they have dependencies only on JDK classes for the following org.apache.struts.util classes: BeanUtils, ConvertUtils, and PropertyUtils. Javadocs are online at http://jakarta.apache.org/struts/api/index.html I haven't voted yet in this thread because I haven't seen anyone else say "let's figure out the process issues first." I guess it's not as interesting as writing code :-), but it is very much as important to a shared resource like this. I will coordinate contributing any or all of the code listed at the bottom of my "Code Sharing Concepts" message, but I'm definitely not interested in making any project I'm a part of dependent on an ad hoc collection of code with no rules about who can change what. I've been bitten way too many times in that scenario. Cheers, Pete Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
Ted Husted wrote: There are many packages which would make good candidates for the library. To find a starting set, I simply looked for packages where there was already overlap. But, if no one disagrees, let's hereby amend the POLL to include -- [Struts] Bean Introspection support - BeanUtils, PropertyUtils, and ConvertUtils classes have generic support for managing JavaBean property setting and getting through the use of the Java Reflection APIs, including support for nested and indexed property expressions. -- If you or Pete or anyone else would like to commit to this proposed codebase, please reply with your +1. As I stated in words rather than votes, and on this code base or any of the others in the polll that came from my original list: Before process management issues are worked out: -0 After process management issues are worked out: +1 I don't have any time to waste on anarchy-based shared code repositories. I have lots of time to spend, and useful code to contribute, to a shared repository that I know I can confidently use in my projects, based on process management rules that include protection from arbitrary API changes. -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
"Geir Magnusson Jr." wrote: Sam Ruby wrote: Geir Magnusson Jr. wrote: Call it 'Rupert'. Be careful, that name might stick. ;-) That would be fine - forward progress! I guess the logo would be next... :) I mean, with Tomcat 4, nothing really guarantees that you won't abandon Servlet 2.3 for the Wiggly Green Spec from Planet Mongo, but I trust that you will stick to your 'mission'... :) The are *SOME* things that the PMC are ready, willing, and able to enforce immediately. You just happened to pick one of them. Really? How's that? If all the developers decided to switch to the WGSfromPM, what could the PMC do? I am not trying to be argumentative - I just thought that the PMC was well described as 'general oversight' with project-specific issues pushed down to the project participants. IMHO, the PMC would certainly behave as Sam indicated, but they probably wouldn't have to -- the ASF Board would undoubtedly say such a thing would be so far out of scope that it wouldn't be "Tomcat" any more. If the tomcat developers, arguably some of the top-tier servlet infrastructure developers in the world, decided that the WGSfromPM was superior to Servlet 2.3 ? Granted, Craig would be looking for a new employer, I think... :) Yah, especially if WGSfromPM == .NET's APIs or something like that :-) Not to mention the fact that the likehood of a majority of Tomcat developers would be predisposed to consider such a thing is basically nil. And back to the issue, that is kinda my point : if you have a group of developers committed to producing a top quality db connection pool for general use, it's not clear that there is much one could do to enforce API stability in an external way that makes sense. At some point, you have to trust someone involved with the project... My personal preferences in this regard are fairly simple -- publish APIs (or use existing ones where there are reasonable standards) that you promise reasonably stable contracts for, and innovate on the implementation(s) inside those APIs. When changes ultimately do occur, they should be designed to minimize the pain of adapting (through techniques like providing convenience base classes that most alternative implementations would have started from). For a connection pool in particular, the relavant API (for my needs, at least) is javax.sql.DataSource -- I want to be able to plug in *any* connection pool that conforms to that interface and use it. Turbine's pool (still) does not do this -- and that makes perfect sense, because it existed before the DataSource API was standardized. Changing Turbine's pool to conform to this would break the contracts for all existing Turbine apps that use it, which would not be a Good Thing. But in the mean time, without a wrapper around it -- I'm about 75% done with this, but unfortunately the wrapper will have to be bigger than the entire code for the Struts connection pool :-( -- the Turbine connection pool is not useful to me. Whether it is in a shared repository or not makes no difference. geir - Sam Ruby Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
