RE: Forum Software.
On Wed, 22 Jan 2003, Costin Manolache wrote: > James Mitchell wrote: > > > >> So the suggestion is: > >> > >> All Users lists become forums. > >> Developer lists stay. > >> > > > > I will fight to my dying breath to make sure this DOESN'T happen (with > > what little persuation I can muster). I have come to rely deeply on > > these lists. > > +1 +1 Omigosh! I just agreed with Costin! > > > > > I spend my offline hours (daily commute, boring meetings, vacations, > > etc) going over the list discussions. I have accumulated a large amount > > of data that I transform into documentation just from this single source > > of knowledge transfer. > > > > PLEASE PLEASE PLEASE DON'T DO THIS! > > Same here. +1 Twice in one message! What's the world coming to? ;-) -- Martin Cooper > > Costin > > > > > > >> > >> Only problem I see there is that Developers won't check the > >> forums as much > >> as they should, unless the Users forum has a mail list interface. > >> > >> > >> Hen > >> > >> On Wed, 22 Jan 2003, Robert Simmons wrote: > >> > >> > Well, once again I would like to bring up the concept of forum > >> > software for Jakarta. The reason I am bringing it up again is that > >> > mailing lists are intrusive and spammy. Daily I get flooded > >> with a ton > >> > of email that I have absolutely no interest in reading. However if I > >> > unsubscribe to the lists than when there is something that I would > >> > like to know about or answer, I will miss it. In addition, if I > >> > unsubscribe I'm not able to post my own issues. With a mailing list, > >> > the communication mechanism is just too intrusive. On a forum I can > >> > pick and choose what I want to read and reply to. > >> > > >> > As for them being used, its a simple matter of retiring > >> mailing lists > >> > for forum software. > >> > > >> > When we consider that at least 90% of Jakarta users are not Jakarta > >> > developers but will often have a question or an important insight, > >> > than the folly of communicating only in mailing lists becomes clear. > >> > > >> > -- Robert Simmons > >> > > > > -- > > James Mitchell > > Software Engineer/Struts Evangelist > > http://www.open-tools.org/ > > > > "The man who does not read good books has no advantage over the man who > > cannot read them." > > - Mark Twain (1835-1910) > > > > -- > 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, Stephen Haberman wrote: > Eyebrowse has made a great start of being a better mail archive > interface, e.g. with thread support, searching, and the like, but it > is not nor tries to be a forum-like interface. > > Given their existing functionality of reading in mbox or what not > email, if you really feel passionately about this web-forum thing > (which you must to bring up the topic again), either join the > Eyebrowse community or start your own extension to it that > implements a convential forum interface. +1 My sentiments exactly. -- Martin Cooper > > - 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: [PMC VOTE] PMC Nominations
On Tue, 21 Jan 2003, Sam Ruby wrote: > > On Thu, 16 Jan 2003, Andrew C. Oliver <[EMAIL PROTECTED]> wrote: > > > >>I propose to nominate Glen Stampoultzis > > > > On 16 Jan 2003, Martin van den Bemt <[EMAIL PROTECTED]> wrote: > > > >>Also want ask you to also nominate Robert Burrel Donkin. > > +1 to both. > > It is my intent to declare this vote closed immediately prior to > tomorrow's ASF board meeting, and notify the board of the new PMC > members at that time. Just curious - Greg's board meeting summary didn't mention this, so I'm wondering what the status is. -- Martin Cooper > > PMC members who have not voted and wish to do so, speak now or forever > hold your peace. ;-) > > - Sam Ruby > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Apache/Jakarta @ JavaOne?
On Sat, 31 May 2003, Mark Womack - Apache wrote: > Are there any official or unofficial Jakarta/Apache activities planned around the > JavaOne conference in SF? There's a Struts gathering after the conference finishes on Friday, but other than that, I'm not aware of any. Last year, we had a Jakarta get-together in a bar one evening, at which I enjoyed chatting and putting faces to names, and I'd certainly be up for something similar this year. I'm afraid I don't have cycles to help set it up this time around, but if someone else does, I'll most likely show up. ;-) -- Martin Cooper > > -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mail2.html -> mail.html
On Sun, 20 Jul 2003, Michael Davey wrote: > Tetsuya Kitahata wrote: > > >No, my original intention was derived from just this simple question: > >"Why doesn't each subprojects' left-side navi point to the *appropriate* > >section in mail2.html?" > > > > > I was dead against this when Tetsuya first raised the issue, but I think Like Danny, I still am. > I am coming round to Tetsuya's way of thinking. Perhaps ezmlm could be > changed so that the confirm subscription and welcome email messages > start with some text similar to that used on the mail.html page. I'm sure it could. But people would completely ignore that text. That's exactly the point of having mail and mail2 separated as they are. > Additionally, the -dev lists could warn that -user should be used for > questions including developer questions, where appropriate. Some Apache > lists already do one or both of these, but many don't do either. You mean the lists themselves, or the people on them? The struts-dev list gets a fair number of messages that should have been sent to struts-user instead, and it's really pretty annoying. The more we can do to get people to use the right list in the first place, the better. > > Hopefully few novices will be inclined to post to a list without first > subscribing They may subscribe, but they are also likely to ignore any instructions they are given, even if those instructions are repeated at the end of every message to the list. How many times have you seen "unsubscribe" messages on lists whose message footers include the instructions? > (I know that many here do post to lists to which they aren't > subscribed, which is fine as they aren't new to the community, so they > know what to do and what not to do). > In any case, I don't think we can > protect ourselves completely from fools ;) Sad but true. ;-( -- Martin Cooper > > -- > Michael > > > > - > 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] HiveMind Service Framework
Accepting this proposal as currently written would also involve the acceptance of five new individuals as Apache committers. Based on where the HiveMind repo currently is/was, that implies giving five unknowns (to me, anyway) access to Jakarta Commons as a whole. I'm not so sure I'd be willing to sign up for that. -- Martin Cooper On Tue, 11 Nov 2003, Nayak, Prashant wrote: > > Proposal for the HiveMind Project > > (0) Rationale > > HiveMind is a simple framework for creating pluggable, configurable, > reusable services. > > Simple: HiveMind is a way to create a network of services in terms of > Java interfaces and classes; it cherry picks the most useful ideas from > Service Oriented Architectures such as J2EE, JMX and SOAP, but removes > the aspects that are typically overkill for most applications, such as > service remoteability and language neutrality. HiveMind creates a > natural network of related services and configuration data, all > operating within a single JVM. > > Pluggable: HiveMind enforces a complete separation of service definition > and implementation. This is manifested by a division of services into an > interface definition and a service implementation as well as a split > between defining a service (as part of a HiveMind module) and providing > the implementation of that service (potentially, in a different module). > > Configurable: HiveMind integrates a service oriented architecture to a > sophisticated configuration architecture; the configuration architecture > is adapted from the Eclipse plug-in model, wherein modules may define > configuration extension points and multiple modules may provide > contributions to those extension points. > > Reusable: HiveMind is a framework and container, but not an application. > The HiveMind framework and the services it provides may be easily > combined with application-specific services and configurations for use > in disparate applications. > > The API for HiveMind allows thread-safe, easy access to services and > configurations with a minimal amount of code. The value-add for HiveMind > is not just runtime flexibility: it is overall developer productivity. > HiveMind systems will entail less code; key functionality that is > frequently an after-thought, such as parsing of XML configuration files, > logging of method invocations, and lazy creation of services, is handled > by the HiveMind framework in a consistent, robust, and well-documented > manner. > > HiveMind fits into an area that partially overlaps the Apache Avalon > project, with significant differences. HiveMind's concept of a > distributed configuration is unique among the available service > microkernel's (Avalon, Keel, Spring, Picocontainer, etc.). Avalon is > firmly rooted in a type-1 inversion of control pattern (whereby services > must explicitly, in code, resolve dependencies between each other using > a lookup pattern similar to JNDI). HiveMind uses a mix of type-2 and > type-3 IoC, whereby the framework (acting as container) creates > connections between services by setting properties of the services > (type-2) or making use of particular constructors for the services > (type-3). > > HiveMind represents a generous donation of code to the ASF by WebCT > (http://www.webct.com). HiveMind originated from internal requirements > for a flexible, loosely-coupled configuration management and services > framework for WebCT's industry-leading flagship enterprise e-learning > product, Vista. Several individuals in WebCT's research and development > team in addition to Mr. Howard Lewis Ship contributed to the > requirements and concepts behind HiveMind's current set of functionality > including Martin Bayly, Diane Bennett, Bill Bilic, Michael Kerr, > Prashant Nayak, Bill Richard and Ajay Sharda. HiveMind is already in use > as a significant part of Vista. > > (1) Scope of the package > > The package shall entail a core framework JAR (containing essential > classes and services), a standard library JAR (containing generically > useful services), along with ancillary artifacts such as Maven plug-ins > and, of course, documentation, all distributed under the Apache Software > License. > > (1.1) Interaction with other packages > > HiveMind has dependencies on several standard commons packages, > including: commons-lang, commons-beanutils, commons-collections and > commons-logging. > > HiveMind makes use of the Javassist bytecode generation library, which > is available under the MPL (Mozilla public license). > > (2) Identify the initial source for the package > > The initial code base has been developed by Howard M. Lewis Ship within > the Jakarta Commons incubator. > > http://jakarta
Re: [NOTICE] to all jakarta committers
On Thu, 13 Nov 2003, robert burrell donkin wrote: > will all jakarta committers please ensure that there apache.org email > account is set up so that it forwards mail to an account that they > read. Or, if not forwarded, please ensure that you read mail to your Apache account. For example, you can ssh to minotaur and read it using pine. -- Martin Cooper > this is very easy to configure - just log on to cvs.apache.org > using ssh and then edit the .forward file. (one way to do this is to > use vi. > > type > > > vi .forward > > type i then your normal email address next press ESC :x ENTER.) > > official mail from the ASF is directed to your apache.org email > account. you need to be able to read it. > > - robert > > > - > 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: [NOTICE] to all jakarta committers
On Thu, 14 Nov 2003, Stefan Bodewig wrote: > On Thu, 13 Nov 2003, Martin Cooper <[EMAIL PROTECTED]> wrote: > > > Or, if not forwarded, please ensure that you read mail to your > > Apache account. For example, you can ssh to minotaur and read it > > using pine. > > Which you'll be unable to do if your account has to be locked because > of a security incident. And the mail that explained that to you would > be in your @apache.org mbox. Happenend two and a half years ago.[1] Good point. The reason I do read my mail on minotaur directly is so that I have one place I can go, from home, work or elsewhere, to read it and, more particularly, store it. POP doesn't help me, web clients suck, and I'm too cheap to pay for access to an IMAP server or whatever. ;-) -- Martin Cooper > > I'd recommend forwarding. > > Stefan > > Footnotes: > [1] http://www.apache.org/info/20010519-hack.html > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New project proposal -- Html4Java
On Mon, 17 Nov 2003, Mike Goudie wrote: > None of those is what I had in mind. I was thinking of something more like this: > http://www.sapdesignguild.org/resources/htmlb_guidance/index.html > > -->1. Introduction > -->* What is HTMLB? That sounds almost exactly like JSF to me (except that JSF doesn't prevent you from using JavaScript to manipulate controls), so I must be missing something fundamental. Could you elaborate, please? -- Martin Cooper > > > > > Original Message --- > > Also there's JSF, which also seems to be leaning into attempts to make web > creation like gui creation: > > http://java.sun.com/j2ee/javaserverfaces/ > > Hen > > On Mon, 17 Nov 2003, Danny Angus wrote: > > > > > > > > > > > > Sounds interesting, but have you seen ECS? > > > http://jakarta.apache.org/ecs/index.html > > > > And for something more weighty in the realm of component architecture for > > web-pages there's Tapestry > > http://jakarta.apache.org/tapestry > > > > > > > > *** > > The information in this e-mail is confidential and for use by the addressee(s) > > only. If you are not the intended recipient (or responsible for delivery of the > > message to the intended recipient) please notify us immediately on 0141 306 2050 > > and delete the message from your computer. You may not copy or forward it or use > > or disclose its contents to any other person. As Internet communications are > > capable of data corruption Student Loans Company Limited does not accept any > > responsibility for changes made to this message after it was sent. For this reason > > it may be inappropriate to rely on advice or opinions contained in an e-mail > > without obtaining written confirmation of it. Neither Student Loans Company > > Limited or the sender accepts any liability or responsibility for viruses as it is > > your responsibility to scan attachments (if any). Opinions and views expressed in > > this e-mail are those of the sender and may not reflect the opinions and views of > > The Student Loans Company Lim > ited. > > > > This footnote also confirms that this email message has been swept for the > > presence of computer viruses. > > > > ** > > > > > > - > > 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] > > > - > 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: [website][patch] Add instructions for setting up mail to newbie.xml
Isn't this something that should go somewhere off of here: http://www.apache.org/dev/ rather than under Jakarta? -- Martin Cooper On Sat, 22 Nov 2003, Phil Steitz wrote: > Attached is a patch to jakarta-site2/xdocs/newbie.xml that adds > instructions on how to set up .forward and also ssh tunnelling to > send/receive from apache accounts. > > Phil > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
On Mon, 1 Dec 2003, Henning Schmiedehausen wrote: > [I like "Turbineers". :-) ] > > I am one of them, and I did some discussion about JCS @ ApacheCon with > Martin Poeschl (who seems to do the odd fix to JCS because he uses it in > Torque), another Turbineer. We basically were came to the same > conclusion as robert: > > - JCS is cute and should have a larger exposure > - JCS isn't related at all to Turbine. At most it is related to Torque > - JCS could be moved to db.apache.org but it is not really database > specific > - There is (almost) no resistance to move this project out of Turbine. > > So my vote is > > > -->8 > > > > (comments here, please) > > > > -->8 > > [ ] leave it within turbine > > [ ] move it to apache commons > > [X] move it to jakarta commons > > [ ] move it to incubator > > [ ] something else (please specify)... > > > > If JCS really catches on, we can still move it back to Jakarta as > "Jakarta JCS". This all makes sense to me, and coming from a Turbineer, it's something I would support. It might even provide a path to resolution for what we do with Commons Cache, which is currently in a coma (at best)... -- Martin Cooper > > Regards > Henning > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PMC membership : "I fear additional responsibility"
On Sat, 20 Dec 2003, Geir Magnusson Jr wrote: > I want to share a conversation that I hope sheds some light on what it > means to be on the PMC. > > I was talking to a friend yesterday who said > > "I fear additional responsibility". > > I told him that he should have nothing to fear, as what's being asked > for is that the committers simply continue to pay attention. His > response was > > "paying attention is a _big_ responsibility" > > "That's true", I thought. So I told him > > "but if you are interested in the project you are going to do that > anyway. IOW, most committers are paying attention to what's coming in" > > "jakarta is just so big though" > > Aha! > > Being on the PMC doesn't mean you have to watch *every* commit in > *every* project. The requirement of the PMC is that it, as a committee > delegated oversight authority by the board, is responsible as a *group* > for that oversight. If we can organize ourselves so that there is > coverage that to an outside observer would be deemed reasonable and > effective, then we satisfy the needs of the ASF. (The board could void > this interpretation, but so far has indicated that it wouldn't). If a PMC member doesn't watch every commit in every project - as surely few, if any, do - s/he needs to at least have trust in enough other PMC members to cover the projects s/he is not involved with. Because, as a PMC member, s/he is still responsible for decisions made by the PMC. That's a good deal of trust to place in others s/he might not encounter anywhere other than on the [EMAIL PROTECTED] list. -- Martin Cooper > > So this person, who participates in and some components of > Jakarta Commons, would just continue to do what he normally does - > participate as he does already. > > The only difference is that we would do our job and ensure that he > understands the rules about contributions, CLAs, and what code > contributions require the Incubator for IP accountability. ( Incubator > => Largish contributions from outside of the ASF. Largish is loosely > defined : Small patch- and file-sized commits and contributions don't > need Incubator, an entire database project from Oracle does. The line > is somewhere in the middle :) > > Anyway, I hope this example helps. It certainly gave me insight into > what this individual was struggling with, and I assume that he isn't > the only one... > > geir > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
On Tue, 30 Dec 2003, Ted Husted wrote: > - Original message > > From: "Geir Magnusson Jr." <[EMAIL PROTECTED]> > To: Jakarta General List <[EMAIL PROTECTED]> > Received: Sun, 28 Dec 2003 16:05:11 -0500 > Subject: Re: [PROPOSAL] Proactively encourage TLP status > > > > >I never understand why you keep doing this. There is no 'schism' > >between the PMC and the community, and no one is proposing it. > > >I hate to "appeal to authority" because the ASF charter does provide a > >healthy bit of freedom for any given PMC, but for example, if we want > >to follow the model of the httpd project, from which the ASF bylaws > >were fashioned, and I know you are a vocal proponent of the 'ASF Way', > >it is my understanding they invite committers onto the PMC after some > >time after receiving committership when it's clear that is appropriate > >for that person. Committing != oversight. > > >There are people who are committers that may not wish to participate on > >the PMC. We want everyone to, but if they aren't *interested* in doing > >it, putting them on the PMC achieves nothing, and actually, IMO, > >weakens the PMC. There are all sorts of valid reasons to not want to > >be on the PMC, I suppose, and we should never stop inviting that > >person. > > >100% should be the goal, not the requirement. > > > > The "schism" is that the PMC did not elect our committers. In the normal > course, the body that elects the committers also decides which > committers (or other interested parties) merit inclusion in the PMC. > > However, Jakarta has not done things in the normal course. The PMC did > not select most of the committers: the subproject communities did. And > when our community selected the committers they expected that these > individuals would be the ones actively managing the codebase. The > community expected these individuals to have the rights and > responsibilities we now abscribe only to the PMC. This doesn't seem quite right to me. I agree that when we have voted in a new committer, both the existing committers and the new committer have had the same expectations with respect to their rights and responsibilities *within the sub-project*. While those rights and responsibilities may be the same ones that apply to members of the PMC, the domain over which they apply is very different. I don't think it would be right to turn around now, and tell a committer on sub-project X "oh, by the way, you're now part of the PMC and that means that you are (collectively) responsible for all of Jakarta". That doesn't meet the expectations *I* originally had at all, when I first became a Jakarta committer myself. Foisting additional responsibility on committers doesn't seem like the right way to go, to me. Allowing - even encouraging - them to take on the additional responibilities of a PMC member would fit much better with *my* original expectations, at least. -- Martin Cooper > > I believe from the ASF perspective > >committing==voting > > and > >committing==oversight > > Every time a committer commits, they vote for the code they commit. Most > often, it a vote subject to lazy consensus, and in rare cases it might > not be binding. But, it is vote nonetheless. > > Every time a committer commits, they either donate code to the ASF or > facilitate a donation, and they incur the obligation to ensure, to the > best of their ability, that this is IP that can be donated to the ASF. > > If we have a committer that does not accept these obligations, then a > misunderstanding has occurred, and such committers should step down. The > ASF does not grant write-access lightly. I think people understand that. > > In the normal course, virtually all ASF committers are PMC members, > because its the committers make the decisions and do the work. > > It is true that on occasion an ASF committer will not yet be member of > the project PMC. Their votes may not be binding, and their commits will > be scrutinized by PMC members (which is to say other members of the > development team). But, in due course, the PMC that made them a > committer also makes them a member. > > When our community elected all of our committers, it was with the > understanding that they were the ones with binding votes, that they were > the decision makers, that the Jakarta Committers were, in practice, the > Jakarta PMC. > > In my humble opinion, it is the duty of the PMC to now ratify the > decisions our community has already made. Since we now know that the PMC > is *not* a steering committee and is
Re: [VOTE] HiveMind as a Jakarta sub-project
On Wed, 3 Mar 2004, Geir Magnusson Jr wrote: > [X] +1 I support this proposal > [ ] -1 I don't support this proposal > [ ] 0 I abstain from voting for or against this proposal -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Tapestry 3.0 rc1 released
On Wed, 17 Mar 2004, Erik Hatcher wrote: > Yes, on the tapestry-dev list at the top of the Votes section here: > > http://jakarta.apache.org/tapestry/changes.html > > Are we supposed to get releases approved by the PMC? Well, technically, it is only PMC members who can vote. ;-) However, the working model we are using allows the sub-project committers to make the decision, but the PMC needs to be notified of the vote result, preferably including a link to the vote thread on the project's -dev list. -- Martin Cooper > > On Mar 17, 2004, at 6:47 PM, [EMAIL PROTECTED] wrote: > > > Was there a vote for it? > > -- > > dIon Gillard, Multitask Consulting > > > > > > > > Harish Krishnaswamy <[EMAIL PROTECTED]> wrote on 17/03/2004 > > 11:55:38 PM: > > > >> Tapestry 3.0 Release Candidate 1 has been released. > >> > >> -Harish > >> > >> > >> - > >> 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to place LICENSE file in a jar?
I recall reading somewhere that the desired location is such that they would show up at the top of a listing. That suggests that they should be in the root directory. On the other hand, META-INF seems more logical, IMHO. -- Martin Cooper On Tue, 16 Mar 2004, Martin Holz wrote: > > Hello, > > if I put the LICENSE and NOTICE file into a jar archive, > where should it go? To META-INF or into the root directory? > > Regards >Martin > > > > > - > 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]
Apache XML federation
This is something we at Jakarta should probably keep our eyes on: http://article.gmane.org/gmane.comp.apache.incubator.general/3103 It's going to be interesting to watch this process, I think, and see how well it works. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts mailing lists
On Thu, 1 Apr 2004, Shapira, Yoav wrote: > > Hi, > > >I assume the website is about to be updated with this information? I > tried > >to email [EMAIL PROTECTED], but typically, heh, the > recipients > >mail server was down or unreachable ([EMAIL PROTECTED]). > > Send a note to the struts-dev list, they're responsible for updating > their own website. Don't rely on the webmaster@ address ;) The web site will be updated, and a message will also be sent to the lists. I've been waiting for the wiki to be fully set up, so that one set of changes and one announcement are all that's necessary, rather than one for each set of changes. The problem is that nobody with the appropriate privileges seems to have any time to move over some pages from the old wiki to the new one. I've been waiting patiently since March 24th. (INFRA-51 on Jira, for anyone with privs and a few minutes! ;) -- Martin Cooper > > Yoav Shapira > > > > This e-mail, including any attachments, is a confidential business communication, > and may contain information that is confidential, proprietary and/or privileged. > This e-mail is intended only for the individual(s) to whom it is addressed, and may > not be saved, copied, printed, disclosed or used by anyone else. If you are not > the(an) intended recipient, please immediately delete this e-mail from your computer > system and notify the sender. Thank you. > > > - > 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: Struts mailing lists
> -Original Message- > From: Noel J. Bergman [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 01, 2004 11:02 PM > To: Jakarta General List > Subject: RE: Struts mailing lists > > > > I've been waiting for the wiki to be fully set up > > > The problem is that nobody with the appropriate privileges seems to have > > any time to move over some pages from the old wiki to the new one. > > If all that is missing is karma, write a shell script with a list of mv > commands, and put it in your home directory. Then add it as a request. Sure. Just as soon as I figure out how to write *nix shell scripts... > It is easier, and faster, to review a list of mv commands for > pages than to > hunt up the data. OK, so the list of 'mv' commands consists of: http://nagoya.apache.org/jira/browse/INFRA-51 -- Martin Cooper > --- Noel > > > - > 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: Struts mailing lists
On Thu, 1 Apr 2004, Martin Cooper wrote: > > > > -Original Message- > > From: Noel J. Bergman [mailto:[EMAIL PROTECTED] > > Sent: Thursday, April 01, 2004 11:02 PM > > To: Jakarta General List > > Subject: RE: Struts mailing lists > > > > > > > I've been waiting for the wiki to be fully set up > > > > > The problem is that nobody with the appropriate privileges seems to have > > > any time to move over some pages from the old wiki to the new one. > > > > If all that is missing is karma, write a shell script with a list of mv > > commands, and put it in your home directory. Then add it as a request. > > Sure. Just as soon as I figure out how to write *nix shell scripts... > > > It is easier, and faster, to review a list of mv commands for > > pages than to > > hunt up the data. > > OK, so the list of 'mv' commands consists of: > > http://nagoya.apache.org/jira/browse/INFRA-51 I can't believe I actually sent that! What a major cut-and-paste-o! Anyway, it's been pointed out to me (thanks, sebb!) that the perms on the directory have changed from when I first tried this, and now I can do it myself, so I have. :-) -- Martin Cooper > > -- > Martin Cooper > > > > --- Noel > > > > > > - > > 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [site] thinking about adding a couple of links from resources
> -Original Message- > From: robert burrell donkin > [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 06, 2004 2:03 PM > To: Jakarta General List > Subject: [site] thinking about adding a couple of links from resources > > > in the light of the recent debate over on licensing about the inability > for java folks to take their jakarta fix in the usual packaged/ported > *nix fashion For the benefit of those of us not on licensing@, could you, or someone else, summarise that debate briefly, please? That list doesn't appear to be in public archives. (I'm on license@, which is publicly archived - I didn't realise there were two separate lists.) TIA. -- Martin Cooper > , i thought i might add links to a couple of well-known > downstream distributors of packages and ports to the resources > (unofficial) section: > > http://www.jpackage.org/ > http://www.freebsd.org/ports/java.html > > comments anyone? > > - robert > > > - > 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: Why wiki logs to [EMAIL PROTECTED] -- site-cvs@ might be better
On Thu, 8 Jul 2004, Tetsuya Kitahata wrote: Hi, Why wiki log (diff) messages would have occupied [EMAIL PROTECTED] It seems appropriate to me, since these messages are notifications of changes to the general (sic) Jakarta wiki. The folks on general@ seem like the right crowd to watch what's going on there, and spot any inappropriate changes. -- [EMAIL PROTECTED] might be better and I could suggest, I think. I'm not sure I see why site-cvs@ would be better. Can you elaborate? I'm also not sure who is on that list, since it doesn't seem to come with site2 karma. I think we'd want the changes to go to a wider group in any case. -- Martin Cooper What would you think? Thanks, - Tetsuya Kitahata -- Terra-International (Independent) E-mail: [EMAIL PROTECTED] http://www.terra-intl.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: Why wiki logs to [EMAIL PROTECTED] -- site-cvs@ might be better
On Thu, 8 Jul 2004, Tetsuya Kitahata wrote: Hi, Martin Cooper wrote: -- [EMAIL PROTECTED] might be better and I could suggest, I think. I'm not sure I see why site-cvs@ would be better. Can you elaborate? I'm also not sure who is on that list, since it doesn't seem to come with site2 karma. I think we'd want the changes to go to a wider group in any case. Yes, very simple reason. Compare to ws.apache.org (I mean, webservices @ apache). In ws.apache.org, every cvs commit logs go to [EMAIL PROTECTED] (see the logs @ eyebrowse / nagoya.apache) On the other hand, in jakarta.apache.org, they had not been. They have gone to [EMAIL PROTECTED] (I am not sure why, but I believe it that there WERE very reason for it) Then, I could not understand (then) why "wiki commit logs" -- similar to cvs commit -- could come to [EMAIL PROTECTED] What i meant is - site-cvs would be rather "for the guys who have much concerns in the changes of the websites of jakarta.apache and related" -- and "who can supervise". I think you are arguing against yourself here. ;-) If the people who can make changes should be the same people doing the monitoring, which seems to be what you are saying, then it makes perfect sense for general@ to review wiki changes, since anyone on that list can make changes to the wiki. Similarly, if site2 karma and site-cvs were tied (but see below), it would make sense for site-cvs folks to be reviewing site2 changes. By the way, it would be needed to join to [EMAIL PROTECTED] list to obtain site2 karma No, it doesn't work that way. I have site2 karma, but am not (and have never been) subscribed to site-cvs. -- Martin Cooper -- Only you should subscribe for posting a message to [EMAIL PROTECTED], if i remember correctly. (I mean, no need to obtain site2 karma) There are about 100 people watching. Sincerely, - Tetsuya Kitahata -- Terra-International (Independent) E-mail: [EMAIL PROTECTED] http://www.terra-intl.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: Adding project version to bugzilla
On Wed, 21 Jul 2004, Shapira, Yoav wrote: Hi, Please remind me what I need to do / whom I need to ask that a new version (e.g. 5.0.26 and 5.0.27 for tomcat) be added to the list in Bugzilla's "Version" field? Asking here is fine. I've added 5.0.26 and 5.0.27 for Tomcat 5. -- Martin Cooper Thanks, Yoav Shapira Millennium Research Informatics - 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: Adding project version to bugzilla
> -Original Message- > From: Henri Yandell [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 22, 2004 6:00 AM > To: Jakarta General List > Subject: Re: Adding project version to bugzilla > > > > Any idea who the people with access to do this are Martin? Within Jakarta > anyway? Apart from the folks who've chimed in, the only other person I know for sure has the right perms is Craig. -- Martin Cooper > > Hen > > On Wed, 21 Jul 2004, Martin Cooper wrote: > > > > > > > On Wed, 21 Jul 2004, Shapira, Yoav wrote: > > > > > Hi, > > > Please remind me what I need to do / whom I need to ask that a new > > > version (e.g. 5.0.26 and 5.0.27 for tomcat) be added to the list in > > > Bugzilla's "Version" field? > > > > Asking here is fine. I've added 5.0.26 and 5.0.27 for Tomcat 5. > > > > -- > > Martin Cooper > > > > > > > Thanks, > > > > > > Yoav Shapira > > > Millennium Research Informatics > > > > > > > > > > > > - > > > 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] > > > > > - > 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: md5 checksum formats on BSD
Do you happen to know which flavour Ant creates? For Struts releases, the Ant build file generates the MD5 files using the task. That seems like a pretty obvious way to generate them for any project that uses Ant, but the task doesn't appear to have any switch for determining flavour (and the docs don't appear to say anything about different flavours of MD5). -- Martin Cooper On Wed, 11 Aug 2004 13:06:00 -0400, Mark R. Diggory <[EMAIL PROTECTED]> wrote: > A subject came up on the Tomcat developers list which we thought should > be shared with the whole community. > > Specifically, it was found that BSD's default md5 format is not parsable > by some external programs that clients are using to verify the integrity > of our downloads. > > While we thought this not "mission critical", we did think it wise that > we should begin making the following recommendation when creating md5 > signatures for files. > > We discovered there is a "-r" option which makes BSD md5 generate md5 > signature format that is the same as that of GNU's md5sum, a more > prevalent tool for generating checksums of files. > > We also found that on BSD, "cksum" is comparable to to GNU's "md5sum > --check" functionality and that it works on both the BSD and GNU file > format. > > Our recommendation is that Apache should be signing with the more > prevalent GNU formated output so that other file integrity software > available on platforms other than BSD can verify the file integrity more > easily. This is simply accomplished by adding the -r option > > For Example: > %md5 -r foo.bar > foo.bar.md5 > > We should remember that md5 signatures are for the public to verify the > integrity of our software package distributions. Making sure that > "everyone" can verify our file integrity is probably more important than > maintaining a platform specific format because it is the default for the > OS these were generated on. > > -Mark Diggory > > Mark R. Diggory wrote: > > For example here are the outputs of the various signing tools we use at > > this time: > > > > BSD md5: > > > > > md5 commons-collections-3.1.jar > > MD5 (commons-collections-3.1.jar) = d1dcb0fbee884bb855bb327b8190af36 > > > > while the GNU md5 script generates the following: > > > > [EMAIL PROTECTED] jars]$ md5sum commons-collections-3.1.jar > > d1dcb0fbee884bb855bb327b8190af36 commons-collections-3.1.jar > > > > And maven just generates and uses: > > d1dcb0fbee884bb855bb327b8190af36 > > > > Yes, the nice thing about BSD md5 is that the -r can be used to make it > > look like the GNU md5sum output, it would probably be good if we started > > to use this as it will be more prevalent and possibly is the closest one > > can get to a standard: > > > > > md5 -r commons-collections-3.1.jar > > d1dcb0fbee884bb855bb327b8190af36 commons-collections-3.1.jar > > > > > > Mark R. Diggory wrote: > > > >> This is the md5 output generated by BSD md5 and not necessarily a > >> "standard", GNU md5sum generates a different format that is not > >> "standard" as well. For maven, just the checksum portion of the > >> content is stored in the file. > >> > >> It would be nice if there was a standard in this area, but I have yet > >> to see one in the internet community. We have the same problem with > >> generating md5 checksums for the maven repository at the moment. > >> > >> -Mark > >> > >> Shapira, Yoav wrote: > >> > >>> Hi, > >>> The format I use for MD5 sums is the standard one. Every other project > >>> I know uses this format, so I think if anything this user needs to > >>> adjust his preferences ;) However, if there's a standard or spec > >>> somewhere that mandates we use md5 -r (reverse output format), then > >>> sure, someone point me to it and I'll follow that spec when signing > >>> releases. > >>> > >>> Yoav Shapira > >>> Millennium Research Informatics > >>> > >>> > >>> > >>>> -Original Message- > >>>> From: jean-frederic clere [mailto:[EMAIL PROTECTED] > >>>> Sent: Tuesday, August 10, 2004 5:26 AM > >>>> To: Tomcat Developers List > >>>> Subject: Re: Fwd: md5 sums for jakarta downloads > >>>> > >>>> Pier Fumagalli wrote: > >>>> > >>>>> > >>>>> Begin fo
Re: FYI: Author tags
On Mon, 13 Sep 2004, Henri Yandell wrote: Many will remember the discussion on whether the ASF should discourage, ban or allow @author tags. I'm not sure that the end result was reported out to the whole community, so going ahead and doing so now. Apologies if a repeat. The boards statement (via Sam) is that: Sam: "The choice of @authors or not is a PMC level decision. " For the benefit of those who were not around at the time, I think it's only fair to include the following official statement that was made by the board: - author tags are officially discouraged. these create difficulties in establishing the proper ownership and the protection of our committers. there are other social issues dealing with collaborative development, but the Board is concerned about the legal ramifications around the use of author tags -- Martin Cooper Many do think that @author tags are not useful, but we're free to do what we want. My opinion: If we ever get subprojects where things are getting childish over @author tags and recognition for fixing newlines or removing unused imports (made up examples), then we should just take the easy way out on that subproject and remove the @author tags. Otherwise, we continue as normal. Hen - 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: CVS->SVN Was: SVN of ECS
On Sat, 25 Sep 2004 21:25:37 +0100, robert burrell donkin <[EMAIL PROTECTED]> wrote: > On 24 Sep 2004, at 19:55, Henri Yandell wrote: > > > Sounds good to me. ORO's the first to goto SVN then. > > cool > > > Noel (or any other local to Jakarta infra people), before I go ahead > > and just make a request, is there a particular process you'd like us > > to adhere to? > > given jakarta's large and diverse, i'd say that we need some kind of > documented procedure. otherwise, it could get really messy and create a > lot of trouble for infrastructure. There is this to start with: http://www.apache.org/dev/cvs2svn.html -- Martin Cooper > > - robert > > > > > - > 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: Can I use Hibernate in an Apache project without compromising the Apache License?
On Mon, 27 Sep 2004 18:06:09 +0200, Oliver Zeigermann <[EMAIL PROTECTED]> wrote: > OK, I understand I can not check in the jar. But what about having it > included in a Maven like build with dynamically downloading it. Theoretically, I suspect you could write such a build target, but you would not be able to distribute the results of such a build. -- Martin Cooper > I was > wondering if the dynamic linking thing hasn't be explitictely clarified > in this: > > http://www.hibernate.org/196.html > > Or is the above still not satisfying? > > Just wondering... > > Oliver > > > > Henri Yandell wrote: > > > > > Correct. We can't check in LGPL, and I don't believe you can check in > > code that depends on LGPL. The reason for this is that their > > interpretation of dynamic linking is debatable and the ASF takes the > > other side in that debate. > > > > The options appear to be to either have a plugin module which depends on > > the LGPL library and is a java.net or SF project etc, or to find a BSD > > dependency. > > > > Hen > > > > On Mon, 27 Sep 2004, Tim O'Brien wrote: > > > >> AFAIK IANAL, no. Checking in LGPL binaries is not something we can do > >> here. > >> > >> Tim > >> > >> > >> > >> > >>> -Original Message- > >>> From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > >>> Sent: Monday, September 27, 2004 2:38 AM > >>> To: Jakarta General List > >>> Subject: Can I use Hibernate in an Apache project without > >>> compromising the Apache License? > >>> > >>> Folks, > >>> > >>> I was considering to use Hibernate for persistence in the > >>> Slide project. > >>> Now, Hibernate is LGPL, but in > >>> http://www.hibernate.org/196.html the authors explain their > >>> idea of dynamic linking as mentioned in the LGPL text. This > >>> looks just fine to me. Additionally, I understand I can even > >>> put the jars into the Slide CVS if I include a reference to > >>> the license, right? > >>> > >>> Thanks for any comments in advance, > >>> > >>> Oliver > >>> > >>> - > >>> 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] > >> > >> > > > > - > > 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS->SVN Was: SVN of ECS
On Tue, 28 Sep 2004 10:32:06 -0400 (EDT), Henri Yandell <[EMAIL PROTECTED]> wrote: > > > On Tue, 28 Sep 2004, Henning Schmiedehausen wrote: > > > Hi, > > > > ok. So this means, once we get e.g. /jakarta/turbine, we could > > set the repository structure below it just as we see it fit? > > > > We (Turbine) currently have (for history reasons) a lot of CVS > > repositories and consolidating them is a real pet peeve for me. ;-) > > Yep. My suggestion would be to go with a: > > /jakarta/turbine//tags|branches|trunk|site > > but that may not fit every subproject. I have a definite Commons view of > the world where every component is equal. I'm not sure how commons-sandbox > should be handled though. We've been discussing the same subject over at Struts, and one excellent point that Craig brought up is consideration of ease of refactoring / moving code across units of source control. I think this might be an important consideration for Commons as well, in determining whether separation occurs above or below the 'trunk' point in the tree. -- Martin Cooper > > Hen > > > > - > 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: Axion / Derby status?
You'd likely get better answers on these if you ask the folks in the incubator, since that is the path into the ASF for both of the projects you're asking about. See: http://incubator.apache.org/ My understanding is that the Axion folks wanted to wait until they're done with their 1.0 release at Tigris before moving the code over. I don't know about Derby. -- Martin Cooper On Thu, 30 Sep 2004 13:11:48 +1000, Mark Livingstone <[EMAIL PROTECTED]> wrote: > Hi Guys, > > Could someone in the know :-) please tell me what the hold up seems to > be with Axion moving into the incubator from it's current Tigris site? > From an outsiders perspective nothing seems to be happening. > > Likewise (as appropriate) for Derby? > > TIA > > MarkL > > - > 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: Exception handling Was: Future JDK features 2 items
On Fri, 19 Nov 2004 23:31:11 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On Fri, 19 Nov 2004 23:21:02 -0800, Daniel Rall <[EMAIL PROTECTED]> wrote:
>
>
> > On Fri, 2004-10-29 at 13:35 -0400, Henri Yandell wrote:
> > ...
> > > How about just being able to do multiple Exceptions in one block?
> > >
> > > try {
> > >
> > > } catch(JMSException, RemoteException, SQLException e) {
> > > }
> > >
> > > or possibly even:
> > >
> > > try {
> > >
> > > } catch( (JMSException | RemoteException | SQLException) e) {
> > > }
> >
> > Something like this would be truly excellent. I'm so sick of having to
> > write 30 lines of exception handling code.
>
> How about two lines, which you can already do today?
That might catch all the exceptions I am expecting, but it will also
catch any exceptions that I am not expecting. Thus the behaviour I
code into the catch clause here might be totally inappropriate for
some of the exceptions it ends up catching.
Also, the compiler will not help me discover that the methods that I
am calling have changed the exceptions that they throw, meaning that
the catch clause is even more likely to become inappropriate over
time.
Finally, I have now lost the self-documenting characteristics of
explicitly naming the exception types I am catching.
At my current company, and at my last company, we have coding
guidelines that explicitly ban the use of what you suggest, for the
reasons above.
Having had the ability to do (the first of) what Henri suggests in
other programming languages in the past, I would be very much +1 on
that inclusion in Java. :-)
--
Martin Cooper
>
> try {
> ...
> } catch (Exception e) {
> ...
> }
>
> If you really want to treat different types of exceptions differently,
> you can special case by putting specialized catch blocks for the
> special cases in front of this. The predominant use case, though,
> seems to be a standarized "log it and exit" or "log it and rethrow it
> in a wrapper exception" strategy, which you can deal with quite
> easily.
>
> Sheesh, hasn't anyone ever heard of inheritance around here? :-)
>
> 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: Mail list page
On Wed, 1 Dec 2004 10:05:11 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: > > Couple of questions > > When are we going to remove projects which have been promoted from > Jakarta, from the mail list page? Anyone mind if I do it now? Feel free to remove Struts. -- Martin Cooper > The watchdog-dev mail list appears to be gone (which makes sense). Is > there a list left for Watchdog, should its entry direct people to > [EMAIL PROTECTED] > > Hen > > - > 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: new sandbox projects
On Wed, 15 Dec 2004, Torsten Curdt wrote: Hey, folks! Hey Torsten, Over at cocoon we have some code that might be worth sharing on jakarta commons. So I was wondering if the sandbox is open to any committer or only to jakarta committers? (which I am not) I heard different stories... Any Apache committer can have sandbox karma just for the asking. I factored out our javaflow (java continuations) implementation and a java compiler interface (jci) featuring a compiling classloader. Any opinions on hosting that at jakarta commons? Or should we keep that stuff under our umbrella? These sound good to me. I would be +1 for having these in the Commons sandbox. -- Martin Cooper cheers -- Torsten - 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: new sandbox projects
On Wed, 15 Dec 2004, Torsten Curdt wrote: Any Apache committer can have sandbox karma just for the asking. The only complication is that the committer will need to get the jakarta unix group, so it'll take us a little bit longer to add karma. Any voting needed for the sandbox components? To get in to the Sanbox, no. To get out again, to Commons Proper, yes. ;-) Otherwise it would be great if I could get access to the sandbox so I can move the stuff over. I'll make a request to have you added to the jakarta group. -- Martin Cooper cheers -- Torsten - 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: Converting Jakarta site and site2 to SVN
+1 to all of the proposals below. -- Martin Cooper On Sat, 18 Dec 2004 13:41:59 -0500, Tim O'Brien <[EMAIL PROTECTED]> wrote: > I'm looking for comments on the following proposal to move jakarta's > site module to Subversion. > > jakarta-site2 CVS > > will be moved to > > /jakarta/ > /site/ (jakarta-site2 HEAD) > > I don't think we need "trunk", "tags", and "branches" for this module. > Anyone disagree? > > Also, does anyone have any objections to not migrating the jakarta-site > module? I believe this module has been unused for 3 years. > > - > 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] moving jakarta-site2 to subversion
On Sat, 18 Dec 2004 22:39:24 -0500, Tim O'Brien <[EMAIL PROTECTED]> wrote: > This is the simplest SVN migration in Jakarta. The migration > instructions follow for review: > > http://wiki.apache.org/jakarta/Site2_20Conversion_20Instructions > > 72 hours for this vote - classify this as a public release vote requires > majority (at least 3 +1s and more +1s than -1s ) > > [X] +1, migrate jakarta-site2 CVS to /jakarta/site SVN > [ ] +0 > [ ] -0 > [ ] -1, No -- Martin Cooper > - > 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: new sandbox projects
On Tue, 14 Dec 2004 21:52:57 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: > > > On Tue, 14 Dec 2004, Martin Cooper wrote: > > > > > On Wed, 15 Dec 2004, Torsten Curdt wrote: > > > >> Over at cocoon we have some code that might be worth > >> sharing on jakarta commons. So I was wondering > >> if the sandbox is open to any committer or only to > >> jakarta committers? (which I am not) I heard > >> different stories... > > > > Any Apache committer can have sandbox karma just for the asking. > > The only complication is that the committer will need to get the jakarta > unix group, so it'll take us a little bit longer to add karma. Torsten (tcurdt) is now in the 'jakarta' Unix group. Can someone with karma karma please give him access to the Commons Sandbox? Thanks! -- Martin Cooper > Hen > > - > 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: Jakarta CVS modules
On Sun, 26 Dec 2004 12:11:36 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: > > Partly to do with CVS->SVN and partly to do with figuring out just what > we're sitting on top of, here's a review of our CVS structure. The phrase > 'needs migration' may just mean that it's already been migrated and needs > deletion. > > jakarta-* > = > > jakarta-jetspeed + jakarta-jetspeed-2 need migration to portals. > jakarta-log4j + jakarta-log4j-sandbox need migration to logging. > jakarta-ecs2 looks dead. > jakarta-ojb needs migration to db. > jakarta-pluto needs migration to portals. > jakarta-site is dead. > jakarta-tools looks dead. Wow, I'd never even heard of -tools before. The only reference I can find to it (or at least to moo) is from watchdog, so we should be able to archive it along with that. Note that Gump is still building this, so we'll need to remove those references first. > Additionally, we know we need to archive: > > jakarta-watchdog > jakarta-watchdog-4 > jakarta-alexandria > > On our CVS page, we claim to be looking after the following java-* > repositories, but they are no longer in the main cvs.apache.org location: > > * java-framework > * java-icalendar > * java-jserv > * java-jukebox > * java-jyve (dead) > * java-jyve2 (dead) > * java-mod_java > * java-picoserver > * java-site > * java-spfc > * java-ssi > * java-utils > * java-whiteboard Where did these all go? Have they all been archived already? We should definitely remove all the broken links. -- Martin Cooper > Ideally they would be in our archive too. > > Comments? > > Hen > > - > 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: download pages in j.a.o.
On Tue, 28 Dec 2004, Tetsuya Kitahata wrote: Just I've tried to improve the usability of Download Pages in jakarta.a.o. (by Adding "Table Of Contents" in "Release Source Drops" section) The problem I have with this change is that it pretty much guarantees that people will completely skip reading anything about the fact that they are downloading from a mirror site, and especially the fact that they need to verify the signature of what they download. If we could put that info before the links, I would be much happier. ;-) -- Martin Cooper http://jakarta.apache.org/site/binindex.cgi http://jakarta.apache.org/site/sourceindex.cgi The migration of CVS repository (jakarta-site2) into SVN had slipped my mind -- very sorry. -- BTW: Perhaps, commons-*** lines can be separated, by creating /commons/binindex.cgi plus commons/sourceindex.cgi and by adding these lines below to .htaccess in jakarta-site2 module (migrated into SVN?). | RedirectMatch ^/site/binindex.cgi#commons-(.*) http://jakarta.apache.org/commons/binindex.cgi#$1 | RedirectMatch ^/site/sourceindex.cgi#commons-(.*) http://jakarta.apache.org/commons/sourceindex.cgi#$1 (... not sure. I am not familiar with RedirectMatch.) Sincerely, - Tetsuya Kitahata -- Terra-International, Inc. E-mail: [EMAIL PROTECTED] http://www.terra-intl.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: Cleaning up Site2
On Tue, 28 Dec 2004 00:35:08 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: > > The jakarta-site2 module is horrendously old, overpowered and creaky. > There's support in there for using xml/xsl->html instead of anakia, and > support for printable pages. > > I'm not sure the use of Anakia is even justified given the limited amount > that is being done. > > In increasing order of effort level: > > 1) Running ant doc_print, I can't say I'm too excited by the printable > page version. I'd like to scrap it. Fine with me. I had no idea it was there. ;-) > 2) There's an XSL variant of the site generation which may be used instead > of Anakia. It's not used afaik and I think it should be ditched; except > that: > > 3) Are we really using Anakia enough to make it worth it? It seems to me > that it could easily be replaced with CSS and a single Java class to kick > off a simple XML/XSL conversion of each xdoc to a doc. Even that might be > overkill as I suspect we could just have regexp search and replace to > achieve the same goal. I would be +0 for just using Ant's (a.k.a.
Re: Jakarta download pages Was: download pages in j.a.o.
On Mon, 27 Dec 2004 23:27:51 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: > > I spent a fair while walking circles in the basement (carrying the unhappy > baby) and thinking on the download pages. > > My first thoughts were on what they exist for. From an info-arch point of > view, they are a search system in addition to the project pages > themselves. The fact that the project pages link back to them is a mistake > on the usability side (though does make our lives fractionally easier). > > My next thought is, why are there separate pages for mailing lists, source > code, cvs repositories, binaries? A lot of information is repeated in > attempting to provide navigation to get to the part desired. One reason > for the separate pages is so that separate information may be obtained, > but I believe there is a different solution to that one. > > So as a general direction, I think we should have a single project summary > page that provides the links to all the relevant resources. This does give > us a problem with how to handle the context sensitive message of how to > use the resource. I think that closer.cgi has the solution there: > > For example: > > http://www.apache.org/dyn/closer.cgi/maven/binaries/maven-1.0.2.exe > > It has problems. Mainly in that it doesn't really provide much a context > sensitive message. It should be mentioning signatures, keys, md5s etc. It > also loses the navigation of the project it's on and dumps you into a > global Apache navigation. However, I think it's the right solution > architectually. A dynamic page that contains a standard message and is > filled with dynamic info. I actually think that page is horrible. Almost the entire page is filled with stuff the user doesn't care a whit about - a big list of mirror sites. The vast majority of users don't care about mirror sites, they just want to download what they want. The list of mirror sites should be stashed away in a drop-down list, as we have it now. I think, if we had a standard "template" for download pages, each subproject could have its own download page, something like we have for Struts: http://struts.apache.org/download.cgi this would be a more workable approach. I don't see a need to have one page with all of the available downloads (with the possible exception of Commons, but I'm not sure we need that either). > So I see the same thing existing for cvs/svn (context message is how to > use cvs/svn etc), mail lists (usual message about politeness etc), > downloads, jars (ibiblio links?), javadocs etc. > > Now, circling the basement is not conducive to coherence, or correct > spelling I suspect, so I'm going to ramble a bit here in vague > justification. Jakarta is different to other TLP's in that it's an > umbrella. One of the reasons I like the approach above is that it is > playing to Jakarta's role as an umbrella. Each project will link directly > to the dynamic resource page, ie) closer.cgi for downloads. Jakarta then > provides an umbrella navigation system for when people want to see all > this information from a single location and not click on each sub-project. > > --- > > Baby's feed is near an end I suspect, so I need to wrap things up a bit. > Direct comments on the current binindex page (with srcindex inheriting > most of these flaws): > > 1) Demo Builds, Milestone Builds: Do we even use these terms regularly? We > have 1 demo build, and I thought we did RC's rather than Milestones. I'm > not sure we even need to push the nightlies at this level; the project > pages themselves should be fine as anyone looking for a nightly is > probably deeply involved with that project as a user. I'd be fine with getting rid of separate sections for these, and simply putting RCs in the main section, but that presupposes that we want to mirror RCs... > 2) I'm not sure we need to advertise the Apache blog or Jakarta news here. > It's on the front page, why use up valuable space. Yep. > 3) Why advertise related projects? They're in the navbar about an inch > away. I think the original purpose of this section was to provide links to projects that had moved out of Jakarta to TLPs. It would help people who were not yet aware that a project had "gone TLP". Now, however, that section seems to have a lot more in it, making it somewhat less meaningful. It might make sense to reinstate the original purpose, listing only "graduated" projects and renaming the section to reflect that. > 4) Same complaint as Martin has. Why have the download information if we > let people click right past it. The table at the top is a noble effort, > but I think we need a lot more to solve the problem. Yep. >
Re: Jakarta download pages Was: download pages in j.a.o.
On Tue, 28 Dec 2004 18:23:37 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: > > > On Tue, 28 Dec 2004, Martin Cooper wrote: > > > On Mon, 27 Dec 2004 23:27:51 -0500 (EST), Henri Yandell > > <[EMAIL PROTECTED]> wrote: > >> > >> 1) Demo Builds, Milestone Builds: Do we even use these terms regularly? We > >> have 1 demo build, and I thought we did RC's rather than Milestones. I'm > >> not sure we even need to push the nightlies at this level; the project > >> pages themselves should be fine as anyone looking for a nightly is > >> probably deeply involved with that project as a user. > > > > I'd be fine with getting rid of separate sections for these, and > > simply putting RCs in the main section, but that presupposes that we > > want to mirror RCs... > > Should RC's even be on this page? The reality is that currently we list > about 3% of all the RC's made. It would make sense for subprojects whose RCs would cause significant bandwidth consumption. However, I think the only subproject that would likely cause such volumes today is Tomcat, but they don't have RCs. (Struts used to put RCs on this page when we were in Jakarta, to take the load off the ASF servers.) So you may be right - maybe this section should go. > > I'm going to kill the Demo Build section as the only link (Velocity demo) > fails. > > >> 3) Why advertise related projects? They're in the navbar about an inch > >> away. > > > > I think the original purpose of this section was to provide links to > > projects that had moved out of Jakarta to TLPs. It would help people > > who were not yet aware that a project had "gone TLP". Now, however, > > that section seems to have a lot more in it, making it somewhat less > > meaningful. It might make sense to reinstate the original purpose, > > listing only "graduated" projects and renaming the section to reflect > > that. > > Switching to Graduated. > > I've removed DB, Geronimo, Gump, HTTP Server, Incubator, Web Services and > XML as ones I don't think came from Jakarta. Hard to say with Gump, DB, > Web Services. I'm not sure if bits didn't exist in Jakarta. Gump originated at Jakarta, certainly. -- Martin Cooper > (at least, I'm doing this. Should be live relatively soon) > > Hen > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 3-column jakarta.apache.org?
On Wed, 29 Dec 2004 14:01:27 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: > > Here's my mockup proposal: > > http://www.apache.org/~bayard/mock-jakarta-frontpage.html > > Changes: > 3 column > Strikethrough of links/pages I'd like to kill. > Less news. > Removal of Related section (aim is to make this a new page). > Rewrite of the welcome message to hopefully say the same main thing, >but use a lot less space. This looks OK. The one thing I would change, though, is to get rid of the indentation under the headings (which would probably necessitate a slightly larger gap between the columns). As it is now, with the indent, the center text - and especially the table - becomes a rather tall, skinny column in a default-sized browser window. > The aim would also be to switch entirely over to the XSL build version > which seems to work fine and dump Anakia creation. +1 -- Martin Cooper > Hen > > On Wed, 29 Dec 2004, Henri Yandell wrote: > > > > > I'm a fan of the www.apache.org look and how it gives us a lot more > > usability > > in terms of available column space. I'd like to change Jakarta to the > > 3-columns (though not the l&f or anything). > > > > Switching to 3-columns means less space in the center for content, however I > > also want to simplify the content so I think it will look fine. > > > > Any views? > > > > Hen > > > > - > > 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mess in jakarta.apache.org/
I zapped the 'userGuide' file. I don't see any point in keeping old sites that are being redirected away from anyway. Unless I'm mistaken, nobody will ever see them. However, it would be good to check with the projects that have moved away from Jakarta, to make sure, since they may not be monitoring this list, and they just might care. ;-) Anything obviously broken or dead should go. Not sure what's left after that. -- Martin Cooper On Wed, 29 Dec 2004 00:52:45 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: > > Worringly, this is just the flotsam lying around at the top level :) > > What on this list cannot be rm -r'd? There's usually one or two important > ones in the pile of junk, so I'll be relatively careful. > > BUGS/ >Copy of a CVS/. Odd. > bcel.org/ >Old copy of BCEL site. > broken/ >A maven repo by the looks of it. > builds/ >Old build system. Seems somewhat empty and broken. How long to maintain? > buildsite.sh >Something to do with TAC. Dead way to build site. > cjan/ >Dead java-repo for pre-cursor to Maven. > commons-mavenized/ >Old test Commons site. > cvsweb/ >Broken symlink. > gump/ >Entire site, though htaccess is redirecting. How long to maintain this? > index-new.html >Dead copy of index.html > jakarta-gnats.tar.gz >Dead bug tracking system. > jjar/ >Dead java-repo for pre-cursor to Maven. > jmeter201/ >Copy of JMeter site. Bizarrely seems to be kept up to date. > log4j/ >Entire site, though htaccess is redirecting. How long to maintain this? > main.template >Old dead file. > ojb/ >A simple redirect. How long to maintain this? > oldsite.tar.gz >Dead old file. > pluto/ >Entire site, though htaccess is redirecting. How long to maintain this? > phoenix/ >Broken symlink. > resources >A struts file. Odd. > struts/ >Entire site. Redirecting so not viewable. How long to maintain this? > tac.jar >Something to do with TAC. Dead way to build site. > tomcat-4.0/ >Bizarre. An installation of Tomcat 4. > tomcat-old/ >Old copy of Tomcat site. > turbine.old/ >Old copy of Turbine site. > userGuide >A struts file. Odd. > > Hen > > - > 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: 3-column jakarta.apache.org?
On Wed, 29 Dec 2004 21:41:00 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: > > > On Wed, 29 Dec 2004, James Mason wrote: > > > Henri, > > > > Looks good. Big improvement, I think :). I especially like how the third > > column brings more information "above the status bar". A few comments: > > Thanks :) > > > 1) The first paragraph sounds more like it's describing the ASF than > > describing Jakarta. A suggestion: > > > > - > > The Jakarta Project offers a diverse set of open source Java solutions > > and is a part of [The Apache Software Foundation] (ASF). Like all ASF > > [projects] Jakarta encourages a collaborative, consensus-based > > development process under an [open software license]. > > - > > It actually is meant to be describing the ASF :) To cut down on text, I > threw away 'jakarta, like all ASF, encourages...' to the simpler 'ASF > encourages'. It's just as true and uses less space. I'd like to dump 'for > all its projects' to be honest, but didn't want to lose the link to the > ASF Project page. > > It's tempting to chop the last 4 words and add a ASF link on the right, > together with the other ASF ones, under a new heading of About Apache or > something. > > > 2) The first sentence of the second paragraph seems awkward to me. It's > > not immediately apparent why that information is useful. If I don't know > > what a TLP is it doesn't really help me, and if I'm looking for a TLP > > that used to be part of Jakarta it doesn't tell me how to find it. > > Unfortunately I haven't been able to come up with a better wording. > > Hopefully someone else is feeling inspired :). > > Two big parts I'm looking for in this paragraph. > > 1) Jakarta = umbrella project. I don't want to say umbrella as that's an > odd metaphor to the uninitiated. > > 2) Definition of graduating, attempt at an explanation of why projects are > no longer to be found in Jakarta (a common user confusion I think). The > TLP acronym isn't highly important (at first I thought it was good to get > it accross, but it's too much info). Linking to the bit above, I could > dump the TLP acronym and make this the link to the ASF project page. > > > 3) "Graduated" on the left needs to be in the context of a noun. Maybe > > swapping the left and right columns (leaving "About" on the left) and > > making the right column "Projects" with subheadings of "Subprojects" and > > "Graduated"? That might take up too much space, though. > > Gah! Much as I want to scoff at the suggestion for the pain it causes, I > think you're right, to be correct it should be a noun. > > Putting the projects on the right was an option, but I think that > consumers will mostly want to click through to a subproject, rather than > any other link there and the LHS is the prime navigation spot. > > It also matches the www.apache.org approach, which is nice for the > symmetry of a user clicking through and not having to adjust their > navigation flow. > > Possibly I could change Graduated to Graduated Subprojects? Seems a bit > long. 'Graduates' seems wrong. Looking for a good label here :) Alumni? -- Martin Cooper > > 4) Removing the margin from the that makes up the news would help > > spread that section out a bit. > > Yep. I'm going to hassle a few web designers I know on spacing issues once > I've updated the XSL build to output this site. All their suggestions will > involve CSS, so I'll need to have a CSS sheet by then I suspect. > > Thoughts? > > Hen > > - > 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: 3-column jakarta.apache.org?
On Fri, 31 Dec 2004 00:26:15 -, Stephen Colebourne <[EMAIL PROTECTED]> wrote: > > What I was thinking of for projects is something like: > > > > ++ > > |=Projects===| > > +--Subprojects---+ > > | * Alexandia| > > | * etc... | > > +--Graduated-+ > > | * Ant | > > | * etc... | > > ++ > > > > I have two concerns with this: It takes up more space and nothing else > > uses subheadings. It does put Graduated into context with a noun, > > though. > > My concern is that most users don't care about TLP vs Jakarta owned. So, > does the terminology 'graduated' help? Why does the user care that some > projects started at Jakarta, while other Java projects didn't? Because resource information for projects that have moved away are no longer found on the Jakarta site. For example, going to the Jakarta mailing lists page is not going to help you find information on the Struts mailing lists. I believe the distinction is important to helping users find what they're looking for. > Unless and until Jakarta can become a Java portal @ Apache we have to deal > with this though. It would seem to me that 'Related' was a looser word for > these projects, and allows us to include other projects that didn't start at > Jakarta. We (meaning Hen ;) just got done cleaning up a bunch of "related" links that didn't seem particularly coherent, so I'd be against putting it right back again. ;-) > Also, I don't see any need to use a noun/subheadings here. For me, 'Related' > on its own would be a sufficient defintion. I suggested "Alumni" but I don't think I got any takers. It seemed like the logical noun to replace "Graduated" to me. IMO, "Related" is too broad, and it was being misused before. -- Martin Cooper > Stephen > > > - > 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: jakarta-site2 now live on xslt
On Mon, 3 Jan 2005 09:02:23 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: > > > On Mon, 3 Jan 2005, sebb wrote: > > > On Sun, 2 Jan 2005 19:15:59 -0500 (EST), Henri Yandell > > <[EMAIL PROTECTED]> wrote: > >> > >> > >> On Sun, 2 Jan 2005, sebb wrote: > >> > >>> Looks like a *lot* of other projects use the Anakia jars and/or > >>> stylesheets from jakarta-site2 - not just jakarta-tomcat-site...so > >>> perhaps those need to be restored. > >> > >> Sites with the older l&f: > >> > >> Taglibs, Velocity, BSF, ECS, JMeter, Lucene, ORO, Regexp, Slide, Tomcat, > >> Watchdog. > >> > >> However, the following all appear to be self contained/non-users: > >> > >> Taglibs, Velocity, BSF, Watchdog, Slide. > >> > >>> Sorry, should have remembered that, as it used to apply to jmeter... > >> > >> + JMeter. > >> > >> So the broken ones look like they are Tomcat, Regexp, ORO, Lucene, ECS. > >> > > > > I did a search for the string "jakarta-site2" in the build.xml,v files > > in CVS, and that produced quite a lot of hits (see > > http://www.apache.org/~sebb/js2.txt - note that the matched text is > > *followed* by the file name). > > > > Some of the matches relate to history items, but some are in the HEAD > > versions of the files, for example: > > > > http://cvs.apache.org/viewcvs.cgi/ant/proposal/ant-site/anakia/build.xml?only_with_tag=HEAD&view=markup > > > > http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/build.xml?only_with_tag=HEAD&view=markup > > > > Of course we don't know if the build targets are actually still used, > > but it suggests that these files are rather more generally used. > > Both HttpClient and Ant appear to use Maven or Forrest for their sites > though, so I'd think it's a pretty low chance that they still use things. > > I think all of Commons is Mavenised, and I checked all of Jakarta in this > way to find old style l&f and then examined those by hand. Looking at the > graduated projects, Struts and James still look old style; so they've got > a good chance of still using site2. > > Looking at them, both Struts and James appear to be on XSLT variants, but > no use of the site2 jars or stylesheets. WRT Struts, it does not depend on site2. Its site generation is self-contained. -- Martin Cooper > Still, not to say that others in your list don't use it, such as jyve or > various proposals in James etc, just nothing 'big' I think. > > Hen > > - > 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: Last call for comments Was: [site] next step - 3-tier + welcome
On Thu, 6 Jan 2005 00:19:37 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: > > http://www.apache.org/~bayard/jakarta-3tier.html > > Rolled back to remove the table->div header change for the moment. I'd > like to go ahead and make the change to a 3 column on Friday. Looks OK to me. I'd say go for it. There are a couple of tweaky things - like the font seems a little bigger than it needs to be, and the section headers are different from the main ASF site - but they really are tweaky things that we can talk about and fiddle with later. -- Martin Cooper > Any nay-sayers before then, let me know. > > Hen > > - > 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: [site] clean up
On Thu, 6 Jan 2005 17:57:38 +, robert burrell donkin <[EMAIL PROTECTED]> wrote: > On 6 Jan 2005, at 09:09, Danny Angus wrote: > > > Robert, > > > >> and is any planning needed so that no toes are stepped on? > > > > An advance heads-up would warn other projects which might link to those > > pages. Though as a redirect wouldn't break the links I guess its not > > that > > important, James has been bitten by Jakarta changes before, though I > > hasten > > to add it is James' own fault for not moving quick enough, and anyway I > > don't think this would affect James. > > it's hard to know which projects links to jakarta and where would be > the right place to post any advance warning. so, though i definitely > take your point, i'm not sure that there's much that can be done. I wonder if there's a link checker doodad that we could run on *.a.o, perhaps as a cron job, and have it send out Gump-like nag messages when something breaks? -- Martin Cooper > i do try to ensure that any changes i make do not break links. the > redirects should ensure that this doesn't happen. > > what i will try to do is to collect and collate the changes (once > there's a reasonable number) and post an email to community detailing > the new pages and together with the redirected pages from jakarta. this > should allow projects which may be linking to redirects to update their > links. > > - robert > > > - > 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: [site] Removing things
On Fri, 7 Jan 2005 20:50:28 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: > > Next up is to clean up various bits on the large front page. Here's the > list of changes. For each one, if I don't hear a -1 by Tuesday I'll go > ahead and make the change. > > 1) Rewrite of the welcome message to the welcome message at > http://www.apache.org/~bayard/mock-jakarta-frontpage.html. Including > additions to the products table as shown in the mock. > > 2) Removal of the elsewhere news section. Point redirects to > news/index.html. > > 3) Remove License renewal and news blog from Headlines section. Rename > Headlines to News. > > 4) Removal of Graduated from the left navbar. I haven't kept up with all of the discussion in the last few days - why are we removing this? IMHO, it's still valuable for the less frequent visitor to our site. > 5) Removal of Related table at the bottom of the index. > > 6) Move Legal link to the bottom of the page (with the copyright), as > shown in mock. > > 7) Removal of Our Mission. Redirect to front page. This seems to me like an important thing to have stated up front. If what we have now isn't what we think we're about, we should fix it rather than removing it. If we don't think we can fix it, then we have a serious problem. ;-) -- Martin Cooper > 8) Removal of links to Japanese/Korean translations. > > Hen > > - > 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: [site] Removing things
On Sat, 8 Jan 2005 17:28:34 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: > > > On Sat, 8 Jan 2005, Martin Cooper wrote: > > > On Fri, 7 Jan 2005 20:50:28 -0500 (EST), Henri Yandell > > <[EMAIL PROTECTED]> wrote: > >> > >> Next up is to clean up various bits on the large front page. Here's the > >> list of changes. For each one, if I don't hear a -1 by Tuesday I'll go > >> ahead and make the change. > >> > >> 4) Removal of Graduated from the left navbar. > > > > I haven't kept up with all of the discussion in the last few days - > > why are we removing this? IMHO, it's still valuable for the less > > frequent visitor to our site. > > Graduated is a confusing concept that we then have to somehow explain. Then let's just call it Ex-Jakarta. > Additionally, how long would we maintain links to said projects etc? 6 months to a year. Let me ask the reverse question: How long would you keep the link to a subproject once it leaves? Would you remove it as soon as the project leaves, or keep it around for a while? If the latter, why wouldn't you move it to an Ex-Jakarta section instead? > I think Graduated is best replaced by: > > News item on graduation that stays prominent for a few months. Some kind > of larger [EMAIL PROTECTED] page. It's not clear to me that people will go and read the News section if they can't find the link to the subproject. After all, if there's no link, then it can't be a Jakarta subproject, so why would there be Jakarta news about it? -- Martin Cooper > >> 7) Removal of Our Mission. Redirect to front page. > > > > This seems to me like an important thing to have stated up front. If > > what we have now isn't what we think we're about, we should fix it > > rather than removing it. If we don't think we can fix it, then we have > > a serious problem. ;-) > > It's a pointless page. The Welcome + Navbars contains all the information > it has, so it just adds to the general clutter. > > Hen > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] Removing things
On Sat, 8 Jan 2005 19:38:17 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: > > > On Sat, 8 Jan 2005, Martin Cooper wrote: > > > On Sat, 8 Jan 2005 17:28:34 -0500 (EST), Henri Yandell > > <[EMAIL PROTECTED]> wrote: > >> > >> > >> On Sat, 8 Jan 2005, Martin Cooper wrote: > >> > >>> On Fri, 7 Jan 2005 20:50:28 -0500 (EST), Henri Yandell > >>> <[EMAIL PROTECTED]> wrote: > >>>> > >>>> Next up is to clean up various bits on the large front page. Here's the > >>>> list of changes. For each one, if I don't hear a -1 by Tuesday I'll go > >>>> ahead and make the change. > >>>> > >>>> 4) Removal of Graduated from the left navbar. > >>> > >>> I haven't kept up with all of the discussion in the last few days - > >>> why are we removing this? IMHO, it's still valuable for the less > >>> frequent visitor to our site. > >> > >> Graduated is a confusing concept that we then have to somehow explain. > > > > Then let's just call it Ex-Jakarta. > > Seems okay :) I'll promote this suggestion to a new thread, see if anyone > disagrees. > > >> Additionally, how long would we maintain links to said projects etc? > > > > 6 months to a year. > > > > Let me ask the reverse question: How long would you keep the link to a > > subproject once it leaves? Would you remove it as soon as the project > > leaves, or keep it around for a while? If the latter, why wouldn't you > > move it to an Ex-Jakarta section instead? > > Spent an hour pondering it, and I'm swayed by your arguments. > > I'm happy too keep the links to old Jakarta sites. The only real problem > it causes us is when things get closed (Avalon), but those projects should > have sites kept up anyway. And hopefully what happened with Avalon won't happen very often... > By News section, I'd meant the front page. Given the tighter mock, an item > in the news section of the front page is pretty prominent, but it's > probably more valueable spacewise than the bottom left of the navbar, so > maintaining links to ex-jakarta is much better. > > >>>> 7) Removal of Our Mission. Redirect to front page. > >>> > >>> This seems to me like an important thing to have stated up front. If > >>> what we have now isn't what we think we're about, we should fix it > >>> rather than removing it. If we don't think we can fix it, then we have > >>> a serious problem. ;-) > >> > >> It's a pointless page. The Welcome + Navbars contains all the information > >> it has, so it just adds to the general clutter. > > Any comment on this? Can 'Our Mission' go? I guess so. It just feels like something we should have, but, as you mentioned, we don't really have much of anything to say at the moment. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] Odd Ant question
I haven't tried it, but how about this: * Use with 'genericantfile' (referencing the same build file) and a for the directories you want. * In the target invoked by , use to determine whether or not the HTML file exists, and invoke another target that only runs 'if' the property is set. That second target would do the copy. * Use to generate the name of the CGI file based on the name of the HTML file. -- Martin Cooper On Sun, 13 Feb 2005 21:38:32 -0500, Henri Yandell <[EMAIL PROTECTED]> wrote: > Before I lug myself off to the Ant lists, thought I'd ask here. > > I'm trying to come up with a way to make the cgi work for the > downloads pages. One way would be to rewrite the cgi, have it take > arguments and be more dynamic. Another easier way would be to simply > copy the cgi file lots of times (as it's already been copied many > times already). > > To do this copying, I basically want to do the equivalent of: > > --- > For each downloads_*.html file > copy downloads.cgi downloads_*.cgi > > > Any idea how I do that in Ant? Mappers seem like they'd want to be > copying the html file to the cgi file; ie) wildcard in to and from. > There's no for loop, so not sure how I'd do such a thing. > > Maybe one way would be to call a target on each file in a list of files. > > Any ideas? > > Hen > > - > 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: FW: PMC & contact for Wiki Admin
On Thu, 17 Feb 2005 14:35:59 -0800, Tim Colson (tcolson) <[EMAIL PROTECTED]> wrote: > Hello Most Reverent and Kind Jakarta Gentlefolk :-) > > I have a suggestion/request and it seems this might (or might not) be > the place to suggest/request it. :-) > > As per below... I'd like to request the MoinMoin wiki be upgraded to > 1.3.x. You'd need to take this up with the infrastructure team ([EMAIL PROTECTED]). There has been some discussion of upgrading MoinMoin, and the most likely target at this point seems to be 1.2.4. IIRC, there was some resistance to go to 1.3.x, I think because there were bigger implications. But infrastructure@ is the place to get the real scoop. -- Martin Cooper > > Personally I'd love to see Confluence replace the Python Moin Moin, > since Confluence is written in Java, shows off Jakarta through the use > of many Jakarta packages, and shows support open source projects by > being FREE for them. > > But barring that... I'd really like to see the upgrade to MoinMoin > happen because the wiki is becoming a huge benefit for collaboration on > the Velocity and Velocity Tools projects. > > I realize Apache is a volunteer org and we all know this is stuff we all > do in our "not so copious free time" -- but I'd really like to know > how/where/who admins the MoinMoin install and offer to help in any way I > can. > > Cheers, > Tim Colson, Geek > > P.S. If you suggest something it is a "suggestion", but if you request > something, why isn't it a "requestion"? > > > -Original Message- > > From: Will Glass-Husain [mailto:[EMAIL PROTECTED] > > Sent: Thursday, February 17, 2005 10:43 AM > > To: Velocity Developers List > > Subject: Re: PMC & contact for Wiki Admin > > > > Velocity doesn't have a PMC since it's not a top level > > project. Our PMC is > > the Jakarta PMC. Many of the committers (but not me) are > > members of the > > PMC. > > > > I can't seem to find the address for the pmc mailing list. > > You might use > > general@jakarta.apache.org as a substitute (although it's a > > public list). > > That might be a good place to advocate for this anyway. > > > > WILL > > > > - Original Message - > > From: "Tim Colson (tcolson)" <[EMAIL PROTECTED]> > > To: "Velocity Developers List" > > Sent: Thursday, February 17, 2005 9:28 AM > > Subject: PMC & contact for Wiki Admin > > > > > > So I'm not in the Know on this one... i.e. WHO is the admin for the > > MoinMoin stuff? > > > > I searched to try and figure it out, also tried to figur out > > how to make > > requests for MoinMoin other than "create a new site"... > > > > Seems the only way will be to send an email to the > > infrastructure alias > > at apache ...and cc the PMC (who IS that for Velocity these > > days? Will?) > > > > http://wiki.apache.org/general/HowToMakeWikiAdminRequests > > > > What I want to request: upgrade MoinMoin to 1.3.x ...while > > not as spiffy > > as Confluence, at least it's a HELLUVALOT better than the current > > version 1.1.x. > > > > Lots of detailed observations on what's improved here: > > http://confluence.atlassian.com/display/DISC/Comparison+Matrix > > > > Cheers, > > Timo > > > > - > > 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] > > > > - > 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] [site] New download pages
Looks good to me, apart from the not-working-ness. ;-) +1 -- Martin Cooper On Thu, 17 Feb 2005 19:47:37 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: > > I'd like to go ahead and move to my suggested new download pages: > > http://jakarta.apache.org/~bayard/jakarta/site/downloads/downloads.html > > [ ] +1 > [ ] -1 > > or alternatively: > > [ ] +1, but fix this first: [ ] > > Currently the filenames match the names on the binindex.cgi page, I'm > trying to stay as close as possible to the current site before making any > other changes. It's easy enough to then do things like change 1.0.zip to > hivemind-1.0.zip as Howard suggested. > > Post change, I'll focus on improving the Taglibs page to match the Commons > one in style. > > 72 hour consensus vote. ie) a single -1 is a veto. > > Hen > > - > 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: Problems under 1.5 Was: [site] New Jakarta download pages
On Tue, 22 Feb 2005 14:09:48 -0500, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > I think we should not be checking in derived files. One of the reasons for that is so that anyone on the infrastructure team can quickly replace the site if it is corrupted or vandalised somehow. They should not have to go through a build process before they can do that. -- Martin Cooper > I think the process should be: > 1) Build and test locally > 2) SVN checkin > 3) Log into jakarta > 4) SVN checkout > 5) Build to staging area; test stage > 6) Build to production; test production > > The build.xml needs to have targets: > build -- local build (to target/site) > build-stage -- to /www/jakarta-stage.apache.org ? > build-prod - to /www/jakarta.apache.org > > The build scripts can be smart about setting file permissions & etc. > > On Tue, 22 Feb 2005 12:42:45 -0500 (EST), Henri Yandell > <[EMAIL PROTECTED]> wrote: > > > > > > On Tue, 22 Feb 2005, Stefan Bodewig wrote: > > > > > While it was using XSLTC, which is the TraX processor shipping with > > > JDK 1.5. We now switched to Xalan-J's CVS HEAD. > > > > I give up :) > > > > How would I force it to be dependent on a particular version of Xalan? > > > > Along with the problems with .cgi files and xhtml, xsltc appears to sort > > the attributes of a html tag differently so if we have 1 person using 1.4 > > and 1 using 1.5, our diffs are going to be spammed by attributes rotating > > back and forth. > > > > Throw in possible worries that the http:// url was causing problems under > > 1.4 and it seems to not be worth the trouble. > > > > Hen > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- > Howard M. Lewis Ship > Independent J2EE / Open-Source Java Consultant > Creator, Jakarta Tapestry > Creator, Jakarta HiveMind > > Professional Tapestry training, mentoring, support > and project work. http://howardlewisship.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: [site] bug update
On Wed, 23 Feb 2005 00:41:38 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: > > After grumbling out loud, my wife pointed out I was being an idiot. So a > quick bit of scripting hackery and a very one-off link checker is off and > running. > > Jakarta downloads at about 560Meg by the way :) > > A bunch more fixes made. From svn: > > "Configuration had a typo 'commons-commons'. Daemon doesn't have commons- > at the front. DBCP had typo of version number, I did 2.1.1 instead of > 1.2.1. JEXL doesn't have binaries/source directories. Modeler doesn't have > commons- at front. Transaction uses .tgz. ECS had -src in wrong place. > JMeter uses _src. Lucene had -src in wrong place. ORO doesn't have a -src > at all in its src download. Slide had duplicated extra bad lines and the > jca link was typo'd." > > "md5/pgp turned off for cli. md5 turned off for jexl. nightly link fixed > for transaction. md5 turned off for tomcat 3. Fix to turbine nightly > build." > > Known problems: > > * Chain, IO, Transaction, Validator use .MD5 instead of .md5 I think this is an Ant vs. Maven issue, although I don't recall which way around. > * ORO uses .sig instead of .asc This might be a PGP vs. GPG issue. I use PGP, but rename the generated files from .sig to .asc. -- Martin Cooper > * JEXL has no KEYS file > * Turbine is quite fubar'd (was in binindex too). Out of date. Missing >lots of entries. > * ECS .asc files are fubar'd, they appear to be binary. > > Hen > > On Tue, 22 Feb 2005, Henri Yandell wrote: > > > > > While I futz my way along fixing things, thought I'd disclose which bugs > > have > > existed today. > > > > Couple of hours between 7 and 9am EST we had problems due to JDK 1.5 and > > unpredictability of building on other people's environments. Solution will > > be > > to hardwire a Xalan dependency. > > > > All Commons -src downloads were screwed. I c+p'd the -src into the wrong > > place in the filename. > > > > Bug in group of group md5/pgp's meant those links failed for 5 download > > pages. HttpClient, Collections, Tomcat 5, Hivemind and Tomcat-Connectors > > were > > affected. > > > > Wrong information on the original binindex page for mod jk 1.2. Fixed now. > > > > HttpClient binary download was broken due to difference in url from other > > Commons projects (binary rather than binaries). > > > > - > > > > I'm slowly checking all the links to make sure they're ok. > > > > Hen > > > > - > > 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javadoc management
On Wed, 16 Mar 2005 00:49:08 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: > > Interested in finding out if anyone else thinks this would be a good idea. > > Rather than have each subproject managing their release javadocs > separately, I think it would be good if we treated the javadoc more like > the releases. Located in a central location, perhaps mirrored, all > versions available and perhaps with additional tools like ashkelon or > multidoc to bring them together. Sounds good to me (assuming you mean all *released* versions available). On download pages, we could have binaries, sources and javadocs, with options for javadocs being download or view online (a bit like Sun's download pages). We might not need to mirror right away - we could wait to see how much this gets used. I'm not familiar with ashkelon or multidoc. What would they bring to the party? -- Martin Cooper > Subprojects would still be hosting their latest cvs head javadocs > internally, but they would deploy a versioned javadoc as a part of > releasing, and we wouldn't end up with the issue where users cannot view > the latest released javadoc due to a site rebuild etc. > > Javadoc seems less important for some projects, Taglibs and Tomcat leap to > mind, so it may not apply for all (though seeing a tag doc in javadoc > style would rock). > > Anyway. Looking for community interest. If there, I'd make it my 2005 Q2 > task, probably along with trying to hassle on LGPL stuff again. > > As it's my current weapon of choice, I'd probably end up with an xml/xslt > solution much like the download stuff, so feel free to point out that that > wasy crap. > > Hen > > - > 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: [site] build.xml includes force=true
On Thu, 24 Mar 2005 17:19:49 +, sebb <[EMAIL PROTECTED]> wrote: > On Thu, 24 Mar 2005 09:06:33 -0500 (EST), Henri Yandell > <[EMAIL PROTECTED]> wrote: > > > > Sorry, meant to replyt on this stuff last night but it turned into a > > mildly late one at work, followed by the usual household chores. > > No problem. > > > I think the problem was that it was not noticing when the navigation was > > being changed, so somebody added a force. > > OK, I see. > > > Although it causes it to build everything, SVN's seems to handle it and > > notices the 1 or 2 files that have actually changed. Under 1.5 it builds > > so quickly (10-ish seconds on my P3 1Ghz) that it's not seemed a big deal. > > Yes, it builds quickly enough. > > I must admit I did not dare try committing all the files to SVN, as I > did not want to generate huge diff listings... > > Ideally the files would not be recreated, as there must be quite a bit > of overhead in sending the files back to SVN for it to ignore them, > but unless the overlooked dependency can be fixed, I guess it all > needs to be rebuilt. Actually, I would not expect those files to be sent to the SVN server at all, since diff is a local operation. (One of the big advantages of SVN. ;) -- Martin Cooper > > Hen > > > > On Thu, 24 Mar 2005, sebb wrote: > > > > > build.xml was updated in r128387 to add force=true to all the > > > transformations. > > > > > > Is this needed? > > > [The log does not say why it was added]. > > > > > > It causes files to be always out of date with respect to the SVN copies. > > > > > > Seems to me it should either be removed - or at least be made a property? > > > > > > S. > > > > > > - > > > 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] > > > > > > - > 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: future for maven generated websites?
I believe you're really talking about deployment, rather than generation. I doubt that any changes will be needed in generation itself. The current hand-wavy answer on updating web sites when shell accounts go away is "WebDAV". I'm not sure if anyone has thought this through yet, though - when I asked for more detail, the answer was essentially "dunno yet". So I guess we'll have to wait and see, although if you have suggestions / want to keep up to date, infrastructure@ is the place to be. -- Martin Cooper On Sun, 27 Mar 2005 11:29:28 +0100, robert burrell donkin <[EMAIL PROTECTED]> wrote: > does anyone have a plan to cope with rebuilding maven based websites > when shell access is switched off to the machine serving the website? > > will we be able to run regular maven site regeneration on a > jakarta.apache.org partition? > > - robert > > - > 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: Tomcat -> TLP
[ X] +1 Vote in support [ ] 0 Abstain [ ] -1 Vote against -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of "InterWiki" by ManikSurtani
What's happened is that the wiki change notifications seem to be sent to a separate list now ([EMAIL PROTECTED]) instead of where they were sent before ([EMAIL PROTECTED]). This has also happened for some (all?) of the other wikis. I'm assuming this change happened as part of the upgrade to the newer wiki version. I've already put in a request to the infrastructure folks to change this back to the way it was. -- Martin Cooper On Wed, 30 Mar 2005 23:48:13 +0100, Kevin Jones <[EMAIL PROTECTED]> wrote: > I hate to do this as I know this is not an admin list but in the last few > days I've started receiving these notifications that the wiki has changed. I > haven't subscribed to this list so I'm assuming I was added 'accidentally', > how do I get off the list? > > Kevin Jones > http://public.xdi.org/=kevin.jones > skype (www.skype.com): kevinrjones > > > -Original Message- > > From: Apache Wiki [mailto:[EMAIL PROTECTED] > > Sent: 30 March 2005 23:32 > > To: Apache Wiki > > Subject: [Jakarta Wiki] Update of "InterWiki" by ManikSurtani > > > > Dear Wiki user, > > > > You have subscribed to a wiki page or wiki category on > > "Jakarta Wiki" for change notification. > > > > The following page has been changed by ManikSurtani: > > http://wiki.apache.org/jakarta/InterWiki > > > > -- > > > > List of valid InterWiki names this wiki knows of: > > [[InterWiki]] > > > > - Subprojects under Jakarta that have wiki pages: > > + Subprojects under Jakarta that do not have wiki sites of > > their own (under http://wiki.apache.org) but have a few wiki > > pages under this wiki: > > JakartaRegexp > > > > MoinMoin marks the InterWiki links in a way that works for > > the MeatBall:ColourBlind and also is MeatBall:LynxFriendly by > > using a little icon with an ALT attribute. If you hover above > > the icon in a graphical browser, you'll see to which Wiki it > > refers. If the icon has a border, that indicates that you > > used an illegal or unknown BadBadBad:InterWiki name (see the > > list above for valid ones). BTW, the reasoning behind the > > icon used is based on the idea that a Wiki:WikiWikiWeb is > > created by a team effort of several people. > > > > - > 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] subproject that's a home for bricks reusable in java web applications
Can we please separate the two different topics being discussed here? The original purpose of this discussion was to see if there is general concensus that a Webapp Commons (or whatever name we end up with) is a good idea. If we think it is, then we need to develop a charter, come up with a name, and officially make the proposal to the PMC. We also need to discuss other aspects, such as whether or not we want to follow the Jakarta Commons model, with separate Proper and Sandbox components. Once we've got to that point, we can have discussions about the various sources from which code might be contributed. Some of those will be from inside of Jakarta, or other ASF projects, and some might be from external sources. IMHO, the discussion of potential external sources and potential new ASF committers is premature at this point. I think we need to get off the ground first. Finally, I'll point out that any substantive contributions would need to come in through the incubator. That being the case, we're not in any position to make judgements or promises, here and now, about what can be brought in and / or who may or may not become committers on the new subproject. (Frank, I am *not* trying to shut you out. I'm simply trying to get the new subproject off the ground without complicating things by discussing external elements prematurely.) -- Martin Cooper On Wed, 22 Jun 2005, Frank W. Zammetti wrote: robert burrell donkin wrote: that's understandable but is likely to cause wrinkles in the approval process. a subproject needs a name and a charter before it can be approved. no guarantees could be offered since accepting new committers is something that sould be delegated to the new community. I definitely see the conundrum. You touched on something too that I hadn't even brought up directly... If I'm going to give up the name, and end my project and contribute all the code I've written, I don't think it is unreasonable to ask to be a committer on the new Jakarta project. I may be mistaken, but I thought part of the approval process is a list of initial committers? I thought I had seen that at one point on the new project proposal paperwork. If so, I'd say that could take care of this part of things because I could be named a committer initially, then everything else as far as names and initial code goes falls in to place pretty easily. anyone have any opinions about this? If the above isn't true, one possible suggestion is to proceed with a contingent name... The contingency being the community accepting me as a committer. There would still be a name in reserve if that should not happen. I hope I'm not coming across like an a**hole here trying to worm my way in... I believe what I'm saying is reasonable, if anyone disagrees please feel free to tell me so. if you could leave it a little while before changing the name of your project to WP4J, that might give us some time to prepare the documents in... I actually didn't mean I would change my project name... In my mind, there are three possible paths here... One is that the Jakarta project takes my name, and my projects ends and all the code is contributed. Two is that the Jakarta project takes a completely different name and I still end my project and contribute all the code. Third is that my project continues as-is and the Jakarta project takes a completely different name. There is the fourth option of me changing my proejects' name and keeping in separate, but that presents problems for me at this point so I wouldn't be especially inclined to do that. I suppose I wouldn't rule it completely out, but it would definitely be last on my list. Frank - 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: [ANNOUNCEMENT] Proposal For Jakarta Sub Project For Web Application Components
On Wed, 22 Jun 2005, robert burrell donkin wrote: i considered posting this to one or more of the announcement lists in an attempt to widen the audience but i didn't feel confident that it would be appropriate or wise. opinions? IMO, it doesn't need to go to announcements lists at this point. People who are only on those lists are likely interested only in things that have become "real". When (if) the subproject is created, it might be more appropriate, but I don't feel a proposal is right for [EMAIL PROTECTED] I did, however, forward the message to taglibs-dev and taglibs-user, since they may end up with a vested interest in this. -- Martin Cooper - robert On Wed, 2005-06-22 at 22:48 +0100, robert burrell donkin wrote: There has been considerable interest over the last few weeks and months concerning the possibility of a new Jakarta sub project similar to the Jakarta Commons but aimed at independent reusable web application components. There are a number of matters which need to be discussed and ideas developed. Anyone who is interested is invited to subscribe to the general list at Jakarta (http://jakarta.apache.org/site/mail.html). A start has been made at documenting some of these: http://wiki.apache.org/jakarta/CreatingCommonsForWebComponents. - robert - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On 6/25/05, Stephen Colebourne <[EMAIL PROTECTED]> wrote: > Rahul Akolkar wrote: > >>is boils down to the question: does this subproject need it's own > >>sandbox or will neophyte components start in the jakarta commons > >>sandbox? > > > > +1 for sandbox (non-binding) > > > > Its slightly hard to imagine anything otherwise, but maybe I'm just > > used to seeing how commons and taglibs work. If Taglibs join, we have > > a bunch of Taglibs in sandbox, they will need to be housed somewhere, > > and I don't see them migrating to commons sandbox ;-) Right? > > Yes, +1 to a sandbox. Although it can create issues, I think has more > benefits than downsides. +1 -- Martin Cooper > Stephen > > - > 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: [POLL] drop point 12 [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On 6/25/05, Stephen Colebourne <[EMAIL PROTECTED]> wrote: > robert burrell donkin wrote: > > this has proved impractical in the jakarta commons. i propose we drop > > point 12. > > "12. The subproject will also provide a single JAR of all stable package > releases. It may also provide a second JAR with a subset of only JDK 1.1 > compatible releases. A gump of nightly builds will also be provided." > > > > > --8<--- > > [X] +1 Get rid! > > [ ] -1 Keep it (please give a reason...) > > -- > > One jar didn't work for commons, no reason to expect it will here. +1. Let's ditch it. -- Martin Cooper > Stephen > > - > 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: mailing lists for components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On 6/23/05, robert burrell donkin <[EMAIL PROTECTED]> wrote: > On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: > > > 4.1 in the guidelines repeats the error that I thought was fixed in the > > j-c guidelines saying that each package has its own mailing list. If > > that is intentional, I think that is a *bad* idea, especially to start. > > it was intentional in as much as it was a copy of the jakarta commons > charter :) > > > Don't like the many little lists implied by 11 -- dev + user works fine > > in j-c (I know some disagree, but I personally view this as the key to > > the health of j-c) > > i agree. just dev and user lists. > > in jakarta commons, the common mailing lists hold together the single > community. i'd like to see just one mailing list with components using > prefixing (as per jakarta commons). i'd like to see changes to the draft > so that it's clear that this will be the arrangement. > > opinions? +1 to just one dev and one user list, shared for all components, a la Jakarta Commons. -- Martin Cooper > - robert > > > - > 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: new components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On 6/23/05, robert burrell donkin <[EMAIL PROTECTED]> wrote: > On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: > > > > > Interpreted literally, 17 goes against standard practice in jakarta (or > > apache, to my knowledge, other than in the incubator). I would > > recommend that new packages require existing committers to support them. > > I would at least recommend changing "Anyone" to "Any apache committer." > > If an individual has already contributed enough to be voted in as a > > committer, then that should be done in a separate VOTE. > > this certainly doesn't reflect the current practise in the jakarta > commons. though anyone can propose a new component, they really won't > have any chance of winning a VOTE unless they have the support of > existing committers. > > there is also the issue of the incubator: any new component bringing > code from outside apache would need to be incubated. We have a few different scenarios here, I believe. 1) A new component is proposed, with no existing code to back it up. I'm not sure that this has ever happened in Jakarta Commons, or is likely to happen in the new subproject, so frankly I don't much care about how that would work. ;-) 2) A new component is proposed by an existing Apache committer. This will almost certainly be backed up by code in the sandbox. Historically, in Jakarta Commons, there hasn't so much been a proposal, but rather a new project materialises in the sandbox. This has, in part, been responsible for dregs that lie around forever. This could be handled through the "after 6 months" vote that has been mentioned in another thread. 3) A new component is proposed by a non-committer. Code to back up such a proposal would necessarily be coming from somewhere else. This is a situation in which the component should, I believe, come in through the incubator. The incubation process would resolve the questions of committers, etc., before the component lands in the new subproject. (I want to emphasise here, for the folks that might be concerned about this, that incubation need not be an onerous process, and can happen rather quickly, if conditions are right.) I would suggest that we come up with wording in the charter to reflect these scenarios, rather than trying to crib from the Jakarta Commons charter in this instance. > is 19 needed in addition to 15? This seems to be a different topic entirely, but my vote would be yes, because 15 relates only to the proposal, while 19 relates to the component as it exists, and is developed, within the subproject. -- Martin Cooper > - robert > > > - > 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: [POLL] drop 8
+1 -- Martin Cooper On 7/3/05, Phil Steitz <[EMAIL PROTECTED]> wrote: > +1 to drop this > > Phil > > robert burrell donkin wrote: > >>8. Packages are encouraged to either use JavaBeans as core objects, a > >>JavaBean-style API, or to provide an optional JavaBean wrapper. > > > > > > doesn't seem very relevant. i think that it'd be simpler just to drop > > it. > > > > here's my +1 > > > > - robert > > > > --8<--- > > [ ] +1 Get rid! > > [ ] -1 Keep it (please give a reason...) > > -- > > > > > > > > - > > 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Brian Stansberry as jakarta-commons-logging committer
On Mon, 11 Jul 2005, Simon Kitching wrote: Hi, Brian sent his CLA in by post about 12 days ago. How can I check whether it has been received/processed? I just checked, and it has not yet been recorded. I'll keep an eye out for it, though. -- Martin Cooper Thanks, Simon On Sat, 2005-06-25 at 22:50 +1200, Simon Kitching wrote: The votes to elect Brian Stansberry as a committer for jakarta-commons-logging are as follows: +1 Dion Gillard +1 Phil Steitz +1 Robert Donkin +1 Yoav Shapira +1 Emmanuel Bourg +1 Henri Yandell +1 Simon Kitching Brian is therefore elected (Brian has indicated privately that he is willing to accept). Brian, the first thing you need to do is complete a Contributor License Agreement and send it in by mail or fax. Details are here: http://www.apache.org/dev/new-committers-guide.html Once this is completed we can create a user account for you and arrange the necessary access rights. Note that processing of CLAs can sometimes take a week or two. Your contributions to jakarta commons so far are very appreciated and we all hope you'll enjoy being part of the commons community. Regards, Simon - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Brian Stansberry as jakarta-commons-logging committer
On Wed, 27 Jul 2005, Simon Kitching wrote: Hi, Any sign of Brian's CLA having been received?? Nope, not yet. Jim added in a bunch of received iCLAs on 7/14, and Brian's was not amongst them. You might want to ask him to fax it again, in case it got lost somehow. -- Martin Cooper Thanks, Simon On Mon, 2005-07-11 at 16:50 +1200, Simon Kitching wrote: Hi, Brian sent his CLA in by post about 12 days ago. How can I check whether it has been received/processed? Thanks, Simon On Sat, 2005-06-25 at 22:50 +1200, Simon Kitching wrote: The votes to elect Brian Stansberry as a committer for jakarta-commons-logging are as follows: +1 Dion Gillard +1 Phil Steitz +1 Robert Donkin +1 Yoav Shapira +1 Emmanuel Bourg +1 Henri Yandell +1 Simon Kitching Brian is therefore elected (Brian has indicated privately that he is willing to accept). Brian, the first thing you need to do is complete a Contributor License Agreement and send it in by mail or fax. Details are here: http://www.apache.org/dev/new-committers-guide.html Once this is completed we can create a user account for you and arrange the necessary access rights. Note that processing of CLAs can sometimes take a week or two. Your contributions to jakarta commons so far are very appreciated and we all hope you'll enjoy being part of the commons community. Regards, Simon - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Brian Stansberry as jakarta-commons-logging committer
On Wed, 27 Jul 2005, Simon Kitching wrote: On Tue, 2005-07-26 at 19:49 -0700, Martin Cooper wrote: On Wed, 27 Jul 2005, Simon Kitching wrote: Hi, Any sign of Brian's CLA having been received?? Nope, not yet. Jim added in a bunch of received iCLAs on 7/14, and Brian's was not amongst them. You might want to ask him to fax it again, in case it got lost somehow. It was posted, rather than faxed. I don't believe the US post is that slow is it?? Not usually. ;-) You might want to e-mail Jim. All I can tell you is that Brian's name isn't in the iCLAs file, and it didn't get added and then accidentally removed. Beyond that, I have no clue. For all I know, Jim might not have picked up from the PO box for a while, the CLA could be lying on his desk, or it could have fallen into a black hole. Sorry. -- Martin Cooper On Mon, 2005-07-11 at 16:50 +1200, Simon Kitching wrote: Hi, Brian sent his CLA in by post about 12 days ago. How can I check whether it has been received/processed? Thanks, Simon On Sat, 2005-06-25 at 22:50 +1200, Simon Kitching wrote: The votes to elect Brian Stansberry as a committer for jakarta-commons-logging are as follows: +1 Dion Gillard +1 Phil Steitz +1 Robert Donkin +1 Yoav Shapira +1 Emmanuel Bourg +1 Henri Yandell +1 Simon Kitching Brian is therefore elected (Brian has indicated privately that he is willing to accept). Brian, the first thing you need to do is complete a Contributor License Agreement and send it in by mail or fax. Details are here: http://www.apache.org/dev/new-committers-guide.html Once this is completed we can create a user account for you and arrange the necessary access rights. Note that processing of CLAs can sometimes take a week or two. Your contributions to jakarta commons so far are very appreciated and we all hope you'll enjoy being part of the commons community. Regards, Simon - 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: Tracking commons component liveliness
On Wed, 27 Jul 2005, Simon Kitching wrote: Hi All, There have recently been some discussions about handling dormant/dead commons projects. And I've been wondering about the activity levels of some projects recently (whether they are dead or not). It's hard to track activity by email volumes, and subversion commit counts can be misleading for two reasons: * some commits are done to fix widespread issues such as copyright dates, while not actually indicating activity on a project * some projects are perfectly stable, and so have low activity counts though they are by no means dead and still have maintainers around. I've got a suggestion to make about tracking this. We could put up a page on the wiki (or maybe directly on the jakarta-commons main page) listing all the projects (main and sandbox). Next to each project would be listed the currently active developers and a date. I have a big problem with putting people's names beside projects and components on a public web page. Besides being yet another thing that needs to be kept up to date, it will only encourage people to contact the developers directly, instead of using the mailing lists. From my own perspective, this is a huge problem already, and I'd be -1 to anything that's going to further exacerbate it. -- Martin Cooper People would be expected to regularly (as often as they like but at least every 3 months) go to the page and update the date next to their name for projects they still are actively involved in, and remove their name against any projects they no longer do anything on. By "actively involved" I mean that they respond to bug reports or patches submitted for the project, not just that they are currently coding on it. Periodically (eg before the board report is due) the Jakarta PMC chair can post a few mails reminding people to update their details. And then names where the dates get too old can be removed as they clearly aren't responding to those prompter emails. A quick look at this page by users or apache people would show the stability of projects: zero, one or multiple maintainers. It doesn't seem an unfair burden; I'm happy to update 3 or 4 lines on a wiki page once every 3 months. Anyway, it's just a thought for the PMC, Henri, etc. to follow up on if you think it's worth doing for us or the users. Regards, Simon - 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: Web Components/Common project
On 8/9/05, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > On 8/8/05, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > On 8/8/05, robert burrell donkin <[EMAIL PROTECTED]> wrote: > > > > > IMO the proposal can be finished off pretty quickly but i'm unsure about > > > the best way to handle the name issue. didn't seem to be any sort of a > > > consensus. opinions? > > > > Is there any interest in resolving the name issue as mentioned below? > I think everyone's perception of the methodology used is key to a > swift resolution, so it'd be nice to flesh out what the method should > be. Yes. We need to pick a name ASAP so that we can get the new subproject off the ground with its own mailing lists, SVN repo, etc. The problem is that the list of candidate names, as it is now, is rather long, which could make for a somewhat messy vote. Therefore, I'd like to propose removing some of those candidate names prior to a vote: * Remove anything that has "potential conflict". Let's just not go there. * Remove League, Confederation and Bloc. I honestly don't think those are serious names. * I would also recommend removing Weblets, since this suggests a uniformity of structure that simply won't be there. That would still leave us with quite a few options to choose among. -- Martin Cooper > -Rahul > > > While it > > would be nice, I doubt this is going to be unanimous. Unless there are > > other suggestions, or someone else beats me to it, I will call a vote > > in 24 hours. I plan to keep it simple, mark X before the name that > > appeals most to you. > > > - > 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: WebXxxx Naming Was: Web Components/Common project
On 8/9/05, Henri Yandell <[EMAIL PROTECTED]> wrote: > > Prior to calling a vote tomorrow, am I missing any potential names. This > is all I dredged out of the previous mail thread. 'webapp' was mentioned > instead of 'web'; but didn't seem to get any traction. > > > web bricks > web components > web parts (NOTE-1) > web commons (NOTE-2) > Some other names were added to the wiki page: http://wiki.apache.org/jakarta/CreatingCommonsForWebComponents That would probably add: - web libs - web tools to your list above. (I'm not sure how appropriate 'web libs' would be though, since I'm not sure I'd refer to, say, a compression filter as a 'library'.) -- Martin Cooper > All would be describable (assuming no clashes) as: > > Apache Jakarta Web Components > Apache Web Components > > There's the option of doing W*4J or something, but we can discuss that > later I think as it's just an altered presentation of the chosen name. > > NOTE-1 > == > Web parts would clash with javawebparts.sf.net name-wise and while the > owner of this loose trademark is interested in being involved, we wouldn't > really know until the code was looked at etc. > > Also Web parts appears to be a Microsoft term (google for it); which will > definitely cause problems if our definition of Web Parts is different to > theirs. > > NOTE-2 > == > Despite the suitability of this name, we are hesitant to duplicate the > Commons brand and confuse the user. > > > Hen > > - > 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] Naming for new Jakarta subproject
On Tue, 16 Aug 2005, Henri Yandell wrote: Sorry for the 5 day instead of 1 day delay. Decided it was time to sell the house so have spent much time tidying up :) Please vote from the following shortlist of names. Please ignore the Web vs Web App vs Webapp issue for the moment. [X]Apache Silk [ ]Apache Web Bricks [ ]Apache Web Commons (branding issue with Commons) [ ]Apache Web Components [ ]Apache Web Parts (conflict with Microsoft and an sf.net project) -- Martin Cooper Assuming it doesn't degenerate into confusion, I'll end the vote on Sunday midday EST. 3 votes needed, simple majority wins. (On Silk: Old name of JScheme back in the 90s. Unsure why they renamed. One of the potential names for Java: http://www.javaworld.com/javaworld/jw-10-1996/jw-10-javaname.html ) -- Veto'd, either by lack of anyone pushing them forward when I listed options, or by what seemed to be good reasons: Web Artifacts - artifacts too vague Web Modules - modules too overloaded Web League- implications on community structure Web Confederation - implications on community structure Web Bloc - ditto; Webbies - website awards Weblets - implies inheritable framework Arctic, Telsa - Too obscure Web Tools - Clash with Eclipse, seems like it would be too close Jakartlets- Jakarta shouldn't be in the name Web Libs - Hard to say quickly :) - 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: Site privs
On Tue, 16 Aug 2005, Vadim Gritsenko wrote: Hi All, For some reason after svn migration I lost privs to jakarta-site... Can somebody (Henri! :-)) fix it? Thanks... Done. -- Martin Cooper Vadim - 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: GMANE
On Thu, 1 Sep 2005, David Smiley wrote: Hello all. I love using GMANE ( http://www.gmane.org ) to access mailing lists because: 1. one stop mailing-list shopping -- a consistent experience 2. NNTP access 3. easiest path to posting a question to a list that you're not a member of, examining the responses, and then leaving. IMHO, this is actually a reason to *not* provide a link to Gmane on our site, since it's anti-community, and community is what we are about. One other point to bear in mind is that Gmane isn't the only service of its kind. I believe Roomity aspires to be another Gmane, and there are probably others. I'm not sure we want to be keeping pointers to all of them, and we shouldn't be picking favourites. ;-) -- Martin Cooper 4. emails for lists don't go into my mailbox; I don't want them there (I prefer NNTP) I think a mention of GMANE on Jakarta would be helpful for the community. This page could use it: http://jakarta.apache.org/site/mail.html (by the "Archives" section) And perhaps elsewhere; I don't know. Thanks for listening. ~ David Smiley - 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: [Request for Comment] Http Components proposal
On 9/24/05, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > Prior to calling a PMC vote here in a week or two, I'd like to ask if > anybody has any comments on the following proposal for Commons > HttpClient to become a Jakarta subproject focusing on Http components. > > Hen > > * > > (The following charter for Jakarta Http Components project is pending > approval of the Jakarta Project Management Committee (PMC). ) > > Rationale: > = > > The original Jakarta Commons HttpClient API has a number limitations that > cannot be resolved without a significant architectural redesign. Moreover, > Jakarta Commons HttpClient has been increasingly used in applications and > environments it has not been specifically designed for. The existing > monolithic design no longer adequately reflects the use patterns of > HttpClient. > > HttpClient needs to be refactored into a toolset of simple, low level HTTP > components suitable for building more specialized HTTP services. > > Project scope: > = > > * Jakarta Http Components develops a toolset of low level components > focused exclusively at the transport aspects of HTTP protocol. > > * Jakarta Http Components MUST be content agnostic. The project DOES NOT > develop components intended to produce or consume content of HTTP > messages. While I understand what you're trying to say here, this wording appears to preclude some of what is in HttpClient today, namely multipart content handling. * Jakarta Http Components continues the development of Jakarta > HttpClient (formerly Jakarta Commons HttpClient) based on the toolset of > HTTP components. This tool focuses strictly on the client side of HTTP. > > * Jakarta Http Components MAY develop non-client components (such as an > HTTP connector, a lightweight server component, proxy components) as > reference material to demonstrate the capabilities of the toolset. The > said artifacts ARE NOT meant for production use and are not released as > official Apache Jakarta products. > > * Jakarta Http Components collaborates with other projects to develop > specialized HTTP services for production use based on the toolset of HTTP > components. > > * Jakarta Http Components DOES NOT define a server side API on top of the > low level transport API. Again, I understand what you want to say. However, I think it would be better said in terms that make it clear that it is intended for use on the client side _of the protocol_, since many people are using HttpClient on the server side today, but as a client to other servers. -- Martin Cooper Targeted specifications and standards: > = > * RFC1945 Hypertext Transfer Protocol -- HTTP/1.0 > * RFC2616 Hypertext Transfer Protocol -- HTTP/1.1 > * RFC2617 HTTP Authentication: Basic and Digest Access Authentication > * RFC2109 HTTP State Management Mechanism -- Cookies > * RFC2965 HTTP State Management Mechanism -- Cookie2 > * A standard for robot exclusion - robots.txt parser (contribution > requiring Software Grant - http://www.osjava.org/norbert/) > > Initial set of committers: > == > Project Lead > Michael Becke > > Project Committers > Adrian Sutton > Ortwin Glueck > Oleg Kalnichevski > Henri Yandell > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Standard Implementation-Vendor-Id
On 12/14/05, Daniel F. Savarese <[EMAIL PROTECTED]> wrote: > > > Someone submitted a Bugzilla request for an Implementation-Vendor-Id > value to be added to the oro jars (without explaining why they needed > it given that Implementation-Vendor is defined). I don't think we've > ever specified a standard Implementation-Vendor-Id for Jakarta jar files. > Will the following do: > Implementation-Vendor-Id: org.apache > > Should I add that to: > http://jakarta.apache.org/site/packageversioning-manifest.template > > Or do we just not care about Implementation-Vendor-Id, in which case > I'll close the issue report as WONTFIX? Not sure about Implementation-Vendor-Id, but Commons components include something like the following: Implementation-Title: org.apache.commons.fileupload Implementation-Vendor: The Apache Software Foundation Implementation-Version: 1.1-RC1 -- Martin Cooper daniel > > > -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#- > s a v a r e s e # In distant lands, I hear the call of my home. >software research # Yet my work is not done. My journey's just > begun. > http://www.savarese.com/ # -- http://www.sleepandthetraveller.com/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: download page is down
On 12/16/05, Will Glass-Husain <[EMAIL PROTECTED]> wrote: > > Hi, > > The Velocity download page has an error (although others are > working). I'm > not sure where to start digging into this. Any suggestions? There seem to be a couple of things wrong. For starters: 1) The links on the Velocity home page are incorrect. They include a 'binaries' directory that doesn't exist in the path being used. That may be because the path being used is not using the mirrors, which is bad. Instead, the home directory should just link to the same page as the Downloads link. 2) The .cgi file isn't working. This is probably because either the line ends are not Unix line ends, or the file is not executable (or both). Actually, I checked just now, and it's the former. Fixing those should fix most, if not all, of the link issues. -- Martin Cooper Best, > WILL > > - Original Message - > From: "Charles Harvey III" <[EMAIL PROTECTED]> > To: "Velocity Users List" > Sent: Friday, December 16, 2005 11:00 AM > Subject: Velocity Download page is down > > > > Hello there. > > Does anybody know why this page is not coming up? > > > > http://jakarta.apache.org/site/downloads/downloads_velocity.cgi > > > > I found that by going to the Jakarta Downloads page and then clicking > > on Velocity. But, from the Velocity page it links to here: > > > > http://jakarta.apache.org/site/downloads/downloads_velocity.html > > > > And, well, that page shouldn't exist, because its garbage. None > > of the links to downloads actually work. And trying to change the > > "http" to "ftp" or "backup" just fails. > > > > Is there a mirror setup somewhere? I was trying to download the latest > > (1.2) version of Velocity Tools. > > > > Thanks. > > > > > > Charlie > > > > > > - > > 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] > >
[site] Missing source files
I just went to add the Commons FileUpload 1.1 release to the Jakarta site, and discovered that at least two files are missing from the source repo. The news files for Q3 and Q4 of this year are present in the repo only as HTML files; the corresponding XML source files are missing. This is not good, to say the least. Does anyone have any insight as to how this happened? Does anyone have the source files that they could add back? I'm not about to start hacking the HTML files to add the FileUpload release... -- Martin Cooper
Re: [site] Missing source files
Thanks, guys. I was confused because Q1 and Q2 files are still there. BTW, after building 'site', svn seemed to think that downloads_velocity.cgi needed to be committed, but a diff showed no changes. That seems a little odd. (I didn't commit it.) -- Martin Cooper On 12/23/05, Phil Steitz <[EMAIL PROTECTED]> wrote: > > Yes, and (thanks to Rahul), Step 12 of the commons release instructions > <http://jakarta.apache.org/commons/releases/release.html> > has been updated to reflect the change. > > One more note that I am about to add is that the Ant build now used to > gen the Jakarta site requires JDK 1.5, so make sure that ant is using a > 1.5 JDK and check html diffs locally before committing. > > -Phil > > Rahul Akolkar wrote: > > On 12/23/05, Martin Cooper <[EMAIL PROTECTED]> wrote: > > > >>I just went to add the Commons FileUpload 1.1 release to the Jakarta > site, > >>and discovered that at least two files are missing from the source repo. > The > >>news files for Q3 and Q4 of this year are present in the repo only as > HTML > >>files; the corresponding XML source files are missing. This is not good, > to > >>say the least. Does anyone have any insight as to how this happened? > Does > >>anyone have the source files that they could add back? I'm not about to > >>start hacking the HTML files to add the FileUpload release... > >> > > > > > > > > Martin, > > > > IIUC, the site build has changed a bit in that regard. The news items > > now go into the news.xml file in the top level site directory, and the > > build will generate the Q3/Q4 HTML files out of there. Ofcourse, > > downloads.xml needs to be updated as before. > > > > -Rahul > > > > > > > >>-- > >>Martin Cooper > >> > >> > > > > > > - > > 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: multipart/form-java
I would recommend that you use something like Commons HttpClient to
construct and make the request, instead of trying to do so manually, as you
are now. See:
http://jakarta.apache.org/commons/httpclient/
You might also want to use Commons FileUpload to parse the request, instead
of the O'Reilly package, so that you don't get tangled up in the strange
licensing conditions of the O'Reilly package. See:
http://jakarta.apache.org/commons/fileupload/
--
Martin Cooper
On 12/27/05, Lamberto Altieri <[EMAIL PROTECTED]> wrote:
>
> Hi there,
> I have a problem!
> I must send a post multipart/form-data message from an applet to a
> servlet,
> I wrote this piece of code:
>
> try{
>// Create a socket to the host
>String hostname="localhost";
>int port=8080;
>InetAddress addr=InetAddress.getByName(hostname);
>Socket socket=new Socket(hostname,port);
>// Construct data
>String dataA="--AaB03x\r\n",
> dataB="Content-Disposition: form-data; name=\"submitter\"\r\n",
> dataC="\r\n",
> dataD="Larry\r\n",
> dataE="--AaB03x\r\n",
> dataF="Content-Disposition: form-data; name=\"files\";
> filename=\"file1.txt\"\r\n",
> dataG="Content-Type: text/plain\r\n",
> dataH="\r\n",
> dataI="... contents of file1.txt ...\r\n",
> dataL="--AaB03x--\r\n";
>int len=dataA.length()+
>dataB.length()+
>dataC.length()+
>dataD.length()+
>dataE.length()+
>dataF.length()+
>dataG.length()+
>dataH.length()+
>dataI.length()+
>dataL.length();
>
>// Send header
>String path="/upload/requestupload";
>BufferedWriter wr=new BufferedWriter(new OutputStreamWriter(
> socket.getOutputStream()));
>wr.write("POST "+path+" HTTP/1.0\r\n");
>wr.write("Content-Length: "+len+"\r\n");
>wr.write("Content-Type: multipart/form-data;
> boundary=--AaB03x\r\n");
>wr.write("\r\n");
>// Send data
>wr.write(dataA);
>wr.write(dataB);
>wr.write(dataC);
>wr.write(dataD);
>wr.write(dataE);
>wr.write(dataF);
>wr.write(dataG);
>wr.write(dataH);
>wr.write(dataI);
>wr.write(dataL);
>wr.flush();
>
>// Get response
>BufferedReader rd=new BufferedReader(new InputStreamReader(
> socket.getInputStream()));
>String line;
>while((line=rd.readLine())!=null)
>System.out.println(line);
>wr.close();
>rd.close();
>socket.close();
> }
> catch(Exception e) {e.printStackTrace();}
>
> but this kind of error is thrown by tomcat 5.5:
>
> 24-dic-2005 1.45.27 org.apache.catalina.core.ApplicationContext log
> GRAVE: error reading or saving file
> java.io.IOException: Corrupt form data: premature ending
> at com.oreilly.servlet.multipart.MultipartParser.(
> MultipartParser.java:205)
> at com.oreilly.servlet.MultipartRequest.(MultipartRequest.java
> :222)
> at DemoRequestUploadServlet.doPost(DemoRequestUploadServlet.java:80)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> ApplicationFilterChain.java:252)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(
> ApplicationFilterChain.java:173)
> at org.apache.catalina.core.StandardWrapperValve.invoke(
> StandardWrapperValve.java:213)
> at org.apache.catalina.core.StandardContextValve.invoke(
> StandardContextValve.java:178)
> at org.apache.catalina.core.StandardHostValve.invoke(
> StandardHostValve.java:126)
> at org.apache.catalina.valves.ErrorReportValve.invoke(
> ErrorReportValve.java:105)
> at org.apache.catalina.core.StandardEngineValve.invoke(
> StandardEngineValve.java:107)
> at org.apache.catalina.connector.CoyoteAdapter.service(
> CoyoteAdapter.java:148)
> at org.apache.coyote.http11.Http11Processor.process(
> Http11Processor.java:856)
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection
> (Http11Protocol.java:744)
> at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(
> PoolTcpEndpoint.java:527)
> at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(
> LeaderFollowerWorkerThread.java:80)
> at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
> ThreadPool.java:684)
> at java.lang.Thread.run(Unknown Source)
>
>
> I use cos.jar crated by o'reilly for reading the multipart/form-data
> message.
> Is this an encoding problem? Can you help me?
> If you need further info.
>
> Thanks
> Yours,
> Lamberto Altieri
>
>
Re: Notice of intent.... #2
On 1/10/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > As a second email in the Notice of intent series; here's what I think > being a Jakarta component will be like in the future. > > * Jakarta is a collection of components. Hopefully all sitting at the same > level. ie) a big bag of things. > > * Groups exist. These are categorically not subprojects, but a way to > allow for slicing of the website etc. Some groups may have their own mail > list; thus the importance of making sure they don't become subprojects. An > important rule will probably be that they must do votes on the main list. I prefer the term "groupings" (which, interestingly, you switch to below ;) over "groups". I also think we should allow the component:grouping relationship to be 1:N, since not all components will fit tidily into a single grouping. As a corollary, I don't believe groupings should have their own mailing lists. Hopefully we can keep it at a point where the groups are really just there > to refine the flow of mail, not to separate it. HttpComponents is an > example of this (though not a good one as most of its components came from > HttpClient). WebComponents (formerly hoped to be known as Silk) is another > example. > > Commons would be groupalized out. Hopefully. Groupings are not vague names > - HttpComponents good, Silk bad. CoreComponents good, Turbine bad. The > idea with that being that boring grouping names are intentionally dull, no > subcommunity identification. > > * No svn authentication beyond being in the jakarta group. Velocity coders > have rw access to POI. > > * Improved Committer->PMC process. Chair's responsibility (I've failed at > this so far) is to turn around the new committer process. A new committer > of 6 months is effectively voted against going to the PMC, not for. Might > not be able to make it exactly that way, but the idea being that joining > the PMC is the exception, not the norm. Personally I'd like to see > committership be removed if people repeatedly are not allowed onto the > PMC. Well, except that the process is that the PMC has to vote in a new committer to the PMC and then notify the board of that vote. I'm definitely not in favour of magic notifications to the board when the six months are up, without an associated vote. * Application of Commons thinking. Not entirely sure on this one as I > think we've overcomplicated things in Commons a bit; but things like a > common build system, common site system etc. > > * Sandbox becomes a Jakarta resource, not a Commons resource. Much of the > same rules as it has currently. Probably a separate mailing list. A separate mailing list for the sandbox would be a double-edged sword.Yes, it would keep the noise out of other mailing lists, but it also, at least, partially condemns sandbox components to death, by limiting their exposure much more than now. And if everyone has to subscribe to the sandbox list anyway, to know what's happening, then a separate list is of limited utility. -- Martin Cooper - > > Shout, scream, yell :) > > Hen > > On Mon, 12 Dec 2005, Henri Yandell wrote: > > > dum de dum de dum. > > > > Just to be public so that it doesn't look like I'm sneaking around > > trying to manipulate things. > > > > -- > > > > I'm starting to open the question of TLP on many of the Jakarta dev > > mailing lists. It's with a general plan where we would see another > > half a dozen subprojects move to TLP and then really leave Commons as > > the main entity inside Jakarta along with some commons-like components > > that are currently subprojects. > > > > I've been talking unofficially with lots of people at ApacheCon, so > > I've had a fair bit of feedback on various bits. The important part is > > that the loose plan above finds a way to coalesce the Jakarta > > community into a much tighter, more TLP e like project. > > > > I've talked with a couple of board members to feel out things would > > be. One question being, is it a problem if we're pushing a TLP with > > just a few committers. The answer I had was that Excalibur is the > > example TLP, it's rather dormant and it's not a problem. > > > > I was also advised to be a bit more active in pushing forward. I think > > this makes sense, a lot of our cross-community activity is gone > > because people with high activity tend to move to TLP, so we need a > > bit more drive to get things done. Thus the change of tack that I'll > > be trying to pull off without getting hung :) >
Re: Jakarta stats
On 1/12/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > > On Thu, 12 Jan 2006, Danny Angus wrote: > > > > > > > I'm one of the "1) Inactive PMC members : 39" > > > > For historical reasons I made it onto this PMC just as the project I was > > really involved with (James) got promoted to TLP. > > I hung around to try to help make sure that Jakarta didn't die as a > result > > of all the reorganisation, and wasn't killed off because we failed to > > provide adequate oversight while we carried out the controlled expansion > of > > the PMC. > > On the one hand I think it may be time for me to move on, on the other > hand > > I think that Jakarta PMC might benefit from the continuity provided by > > letting the interest of me and the others like me fade away as Jakarta > > continues to evolve. > > > > Whatever I think, I would happily relinquish my PMC vote if the active > PMC > > members think it would help in any way. > > Personally, I think that as long as we don't have to have any form of > quorom, and as long as the inactive PMC member is on the mailing list > (which really means they're not completely inactive), then it's not a > problem. > > We do need quorom on one issue: "The Chairman or any member may be removed > from the PMC by a 3/4 vote of the PMC." > > Of course, we only have 60% active right now, so presuming only committers > to the current Jakarta voted, that line of the charter would be > impossible. What, you think we're going to let you off the hook as PMC Chair any time soon? Ha ha ha! ;-) -- Martin Cooper Not a biggy I think, I think the chair can sidestep the charter if the > community allowed it and removing the chair is more about the PMC sending > a vote of no confidence to the board regardless of %, the board's > interpretation of that vote would be subjective. > > ie) I doubt a chair could be removed for doing what the board said had to > be done. 75% or no 75%. :) > > It's one of the places where Jakarta modelled itself on the ASF, but isn't > the same as the ASF. > > -=-=-=-= > > Mostly I'm worried about: > > PMC members who are not on pmc@ (there's a handful) > PMC members who are not on general@ (never looked. I will soon) > Inactive committers who are not on the PMC (200+) > > Hen > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: jakarta struts binary
On 2/8/06, John Armstrong <[EMAIL PROTECTED]> wrote: > > > I'm trying to learn java struts and an old Jakarta Struts book is telling > me to go to jakarta.apache.org for the jakarta struts binary. When I go > there there's no mention of such under downloads. There's just "Struts" > under Ex-Jakarta, and when I go there, there's numerous downloads besides > Jakarta Struts Binary. > > How can I get the Jakarta Struts binary for Windows? Struts is no longer part of Jakarta, so it's now Apache Struts. If you're just starting to learn Struts, you'll probably want to start with our most recent GA release, which is Struts 1.2.8. You can find that on the Struts downloads page, here: http://struts.apache.org/downloads.html For documentation, you'll want the corresponding release web site, here: http://struts.apache.org//struts-doc-1.2.8/index.html Hope that helps. -- Martin Cooper - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: New Commons SubProject Proposal
Given its database-centric nature, and the fact that it's a framework, this
would appear to be more appropriate for the Apache DB Project:
http://db.apache.org/
--
Martin Cooper
On 2/15/06, Karthik Kumar <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I'm Karthik. I've been working with Jakarta libraries and tools for quite
> some time (including ex. Jakarta projects such as Tomcat, Ant and Struts).
> I've also used commons HTTPClient, logging and DBCP.
>
> Coming to the idea, as a person who uses JDBC, I found it very difficult
> to
> handle the reconfiguration of database connectivity for applications
> without
> having to recompile them. (JNDI configuration was probably the only other
> way to go!) Hence, I decided to work out a set of configuration and
> instancing classes that load and configure connectivity through a
> generalized, extensible framework.
>
> I've currently started off, and have a working sample framework for doing
> this. I've felt that it would be a great idea, if I could work on this
> more,
> and contribute it to the Jakarta project, as a small and useful component.
>
> I'm indicating the intended usage of connectivity here:
>
> Configurator mConfig=new PropertyConfigurator();
> //or: Configurator mConfig=new XMLConfigurator();
>
> mConfig.configure(ConnectionManager.getInstance());
>
> mCon=ConnectionManager.getInstance().getDefaultConnection();
> mCon1=ConnectionManager.getInstance().getConnection("MySQLDBCP");
> mCon2=ConnectionManager.getInstance().getConnection("Oracle");
> mCon3=ConnectionManager.getInstance().getConnection("OracleJNDI");
>
>
> Currently, I've put up fully functional (although WIP) components (source
> and binary), which allow you a common configuration to connect through
> JDBC,
> JNDI DataSources and DBCP BasicDataSources.
>
> http://guilt.bafsoft.net/downloads/wip/
>
> I was working on Eclipse, and I'm moving the project build process to
> maven.
>
>
> Please let me know about this idea. I'm be willing to contribute my best,
> given a chance.
>
> --
> Karthik
>
Re: Subproject Charters
On 3/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > I notice that Commons and HTTP Components both have charters. Other > subprojects may have them and I've just missed in my very quick look. > > Do these serve any purpose? Are they a legacy of the days when we tried to > create an ASF-like structure within Jakarta to organize things? They were originally created to define the (sub)projects we were creating, and they still serve that purpose. If you get rid of the charter, where would you propose that we define the purpose and scope of these projects? And what would you call that if it isn't a charter? Any reason not to go ahead and kill these subproject charters? Yes. See above. There needs to be some place where we state the "official" purpose and scope, and that isn't just some words that someone happened to use as a description on some page that's part of the site. Say some Prolog constraint framework decided it wanted to be part of Commons. Where would you point them to explain that that's not what Commons is about? -- Martin Cooper Hen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [PROPOSAL] Two community proposals
On 3/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > I started to write a long email on the problems in Jakarta, on umbrellas, > on the lack of a Jakarta community and existence only of subcommunities > and on how it should be "there is no Jakarta Xxxx, you are members of > Jakarta - not a subproject"; but you've heard it all before. > > So, proposal: > > - > Given that we are one project and that we should be acting as one > community - I propose that we: > > 1) Remove SVN restrictions, all Jakarta committers can commit anywhere in > Jakarta, with the exception of the Commons-Sandbox as it allows Apache > committers in general to commit. What problem is this solving? I just don't see the need. 2) All vote threads to occur on the general@ mailing list; or the pmc@ > mailing list if deemed private. I agree with Sandy on this one. The votes should stay on the relevant developer list. -- Martin Cooper - > > Comments? > > The only negative I have for 1) is that I like to use the commit lists to > see who is on which subproject (for 3 PMC member oversight checking), but > that is a flawed idea anyway. The real way is to see who is voting on > issues (especially releases) for that project. If it's an inactive > project, the real way is to ask the -dev mailing list for 3 PMC replies > else the subproject gets mothballed. > > Hen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Representing project inactivity on the site
On 3/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > I really shouldn't be sending multiple emails at the same time - you'll > all jsut end up replying to one of them. However, itching while the itch > is present. > > Alexandria is dead. We need to represent it as so on the site. Why? You're trying to save one mouse click? It's clear as day that it's dead as soon as you click on the link. ECS, ORO, Regexp are inactive development-wise - represent - site. > Slide, POI, Turbine, JCS seem pretty inactive - should we represent such? Why do we need to do this on the front page? Each site can say whatever it needs to, since, as you indicated in a subsequent message, there are many different "flavours of done-ness". I think about the only person that needs such a summary on one page is you, Hen. ;-) And it's just one more thing to maintain that means updating the Jakarta site instead of the subproject site, which is backwards to me. -- Martin Cooper What labels should we use? > > I suggest: > > * Delete Alexandria. It's at the same level as the java-* CVS stuff, > ancient history to be forgotten. > > * ECS, ORO, Regexp to be moved to a label of Inactive. > > * Others to be raised as questions separately and voted on. > > Hen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Subproject Charters
On 3/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > > On Sun, 5 Mar 2006, Martin Cooper wrote: > > > On 3/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > >> > >> > >> I notice that Commons and HTTP Components both have charters. Other > >> subprojects may have them and I've just missed in my very quick look. > >> > >> Do these serve any purpose? Are they a legacy of the days when we tried > to > >> create an ASF-like structure within Jakarta to organize things? > > > > > > They were originally created to define the (sub)projects we were > creating, > > and they still serve that purpose. If you get rid of the charter, where > > would you propose that we define the purpose and scope of these > projects? > > And what would you call that if it isn't a charter? > > > >> Any reason not to go ahead and kill these subproject charters? > > > > > > Yes. See above. There needs to be some place where we state the > "official" > > purpose and scope, and that isn't just some words that someone happened > to > > use as a description on some page that's part of the site. > > Why restrict a project? One of your big things right now - order and organisation. ;-) I missed the alternative on this email (it spun out of a Commons email) > which is why don't we require these of all subprojects? I can't answer the question, but that would be fine with me. > Say some Prolog constraint framework decided it wanted to be part of > > Commons. Where would you point them to explain that that's not what > Commons > > is about? > > The Jakarta charter where it says Java (which in fact it doesn't say - > might be a bit of an ommission). OK, then what about a Java constraint framework? Here's the Commons Charter: > > *** > 0) rationale > > > A Jakarta subproject to solely create and maintain > independent packages is proposed to accelerate and guide this process. > > (1) scope of the subproject > > The subproject shall create and maintain packages written in the Java > language, intended for use in server-related development, and designed to > be used independently of any larger product or framework. Each package > will be managed in the same manner as a larger Jakarta product. > > > > (2) identify the initial set of committers > > > ** > > If anything, that's a better Jakarta charter than the Jakarta charter and > should be merged in - but there's very little to restrict the scope of > Commons. Well, I see: * Written in Java. * Independent packages. * Intended for server-side. * Not frameworks. Those don't all apply to Jakarta as a whole, but they do all apply to Commons, and I, for one, do not want to lose those statements of scope and purpose. It's a charter, whether or not you want to call it one. -- Martin Cooper Hen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [PROPOSAL] Two community proposals
On 3/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > > On Sun, 5 Mar 2006, Will Glass-Husain wrote: > > > I'm mildly positive on "all votes on general". A corollary of this > would be > > to encourage everyone to sign up for general. Maybe put this in big > letters > > on the Jakarta home page. It seems a good way to try out the "one > > community" idea, see if it fits. > > To stir things a bit more :) > > We could go further and say that all non-technical discussions are on > [EMAIL PROTECTED] All navel-gazing, all infrastructure style, all license > questions etc. -dev lists would remain to discuss the actual code, > bugfixes etc and would promote non-code issues up to the general mailing > list. Great idea! Then I can unsub from general@ and avoid all the navel-gazing! :-) -- Martin Cooper Hen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Representing project inactivity on the site
On 3/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > On Sun, 5 Mar 2006, Martin Cooper wrote: > > > On 3/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > >> > >> > >> I really shouldn't be sending multiple emails at the same time - you'll > >> all jsut end up replying to one of them. However, itching while the > itch > >> is present. > >> > >> Alexandria is dead. We need to represent it as so on the site. > > > > > > Why? You're trying to save one mouse click? It's clear as day that it's > dead > > as soon as you click on the link. > > > > ECS, ORO, Regexp are inactive development-wise - represent - site. > >> Slide, POI, Turbine, JCS seem pretty inactive - should we represent > such? > > > > > > Why do we need to do this on the front page? Each site can say whatever > it > > needs to, since, as you indicated in a subsequent message, there are > many > > different "flavours of done-ness". I think about the only person that > needs > > such a summary on one page is you, Hen. ;-) And it's just one more thing > to > > maintain that means updating the Jakarta site instead of the subproject > > site, which is backwards to me. > > I'm suggesting: > > Active Subprojects > > * Alexandria > * BCEL > * BSF > * Commons > * HiveMind > * JMeter > * Tapestry > * Velocity > > Inactive Subprojects > > * Cactus > * ECS > * JCS > * ORO > * POI > * Regexp > * Slide > * Taglibs > * Turbine But why? If I'm a user looking for something to help me out in my development, I don't really care that much if it's active or not. What I care about is if it does the job. If there are problems with it, then I might care about whether it's active or not - or maybe I don't, since it's open source and I could fix the problems myself, if I chose to. The people who care about active versus inactive are those on the PMC, and those are not the people we should be designing the Jakarta front page for. Though it's also obvious that I want all of the Commons components, > Turbine components, Velocity components, Taglibs components and any other > hidden away sub-sub-projects to be at the same level. Alexandria itself > would just go into a trash-can - same place JServ went. > > -- > > All (90%?) of the navel gazing comes down to one binary question. Should > Jakarta be a community, or a community of communities. Are we Jakarta > committers, or ORO committers. It should be what it is. As I just wrote in another message (on commons-dev, I think), you can't make a community into something other than what it has grown into organically. I'm not tied to any of the things I'm suggesting - except the strong > belief that Jakarta as a community of communities cannot work. So I'm > definitely in favour of more shared site and less individual site - I'm in > favour of a flat Jakarta, both in terms of SVN acces and not allowing > subprojects of subprojects (ie: Jakarta Velocity-DVSL, not Jakarta > Velocity DVSL); I'm in favour of sharing the decisions - rather than > having a slice of the PMC informing the main PMC of their decision. > > Agreed - most/all of this will seem backwards if someone takes the view of > community of communities as opposed to single community. And there you have the nub of my objections to all this manipulation of communities. -- Martin Cooper Hen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Subproject Charters
On 3/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > > On Sun, 5 Mar 2006, Martin Cooper wrote: > > > On 3/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > >> > >> Why restrict a project? > > > > > > One of your big things right now - order and organisation. ;-) > > Guess I don't see this as one that needs constraining - how a > component/subproject does something - sure. What it's allowed to do - > nope. Not as long as it falls within the larger Jakarta charter. It's not so much what it's "allowed" to do, as much as to define its purpose. Perhaps you see Velocity as a viable Commons component, but I don't. Nor do I think it would make sense for Digester to be part of Cactus, or Taglibs to be part of Slide. A well-defined scope is a good thing, and helps people understand what they're looking at. >> I missed the alternative on this email (it spun out of a Commons email) > >> which is why don't we require these of all subprojects? > > > > > > I can't answer the question, but that would be fine with me. > > Seems like unnecessary bureaucracy. It's not bureaucracy. See above. >>> Say some Prolog constraint framework decided it wanted to be part of > >>> Commons. Where would you point them to explain that that's not what > >> Commons > >>> is about? > >> > >> The Jakarta charter where it says Java (which in fact it doesn't say - > >> might be a bit of an ommission). > > > > > > OK, then what about a Java constraint framework? > > If it's large: -1 to Commons, -1 to Jakarta. If it's tiny +0 to Commons, > +1 to Jakarta, but they're converging to both be a +1 if not too framework > like. I specifically chose a framework for my example because we have long stated that frameworks should not live in Commons, and that is stated in our charter. Are you saying you want to change that now, to allow frameworks as Commons components? I so, -1 from me. -- Martin Cooper > Here's the Commons Charter: > >> > >> *** > >> 0) rationale > >> > >> > >> A Jakarta subproject to solely create and maintain > >> independent packages is proposed to accelerate and guide this process. > >> > >> (1) scope of the subproject > >> > >> The subproject shall create and maintain packages written in the Java > >> language, intended for use in server-related development, and designed > to > >> be used independently of any larger product or framework. Each package > >> will be managed in the same manner as a larger Jakarta product. > >> > >> > >> > >> (2) identify the initial set of committers > >> > >> > >> ** > >> > >> If anything, that's a better Jakarta charter than the Jakarta charter > and > >> should be merged in - but there's very little to restrict the scope of > >> Commons. > > > > > > Well, I see: > > > > * Written in Java. > > +1 to this in the Jakarta charter - though I'd probably say 'Written for > Java'. Commons Daemon has C parts, but exists for the purposes of Java. > > > * Independent packages. > > Common sense - assuming it means other people wouldn't use their packages, > but fine to add to the Jakarta charter. If it means no dependencies, well > we break this one a lot. > > > * Intended for server-side. > > +1 to this in the Jakarta charter. We've always had this as a loose > constraint. We don't interpret this as server-side though, rather we > interpret it as not client-side. > > > * Not frameworks. > > +1 to this in the Jakarta charter - we're heading that way. > > > Those don't all apply to Jakarta as a whole, but they do all apply to > > Commons, and I, for one, do not want to lose those statements of scope > and > > purpose. It's a charter, whether or not you want to call it one. > > So my disagreement is that I think it should apply to Jakarta as a whole - > and is pretty close to doing so. > > Hen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Representing project inactivity on the site
On 3/5/06, Yoav Shapira <[EMAIL PROTECTED]> wrote: > > Hola, > Martin, I agree with almost everything you've said, except this: > > > But why? If I'm a user looking for something to help me out in my > > development, I don't really care that much if it's active or not. What I > > I do care, a lot, as a user. Active means bugs are getting fixed, the > mailing lists are a reasonable source for help, and if new standards > become relevant or new features are requested by numerous, there's a > good chance the product will evolve to comply with them. As a user > who doesn't have Apache commit privilges and who doesn't want to fork > a product just to use it, activity versus dormancy is a HUGE factor in > choosing a product. You snipped out the part that explains what you quoted. ;-) "What I care about is if it does the job. If there are problems with it, then I might care about whether it's active or not" If you are saying that you wouldn't even try out a component that's marked as 'inactive', to see if it does what you need, then I think it would be a *huge* disservice to flag components as inactive right on the front page, because then people might not even look at them, even if they're "done" and would completely fit their needs. Marking a component as 'inactive' would then be the final nail in its coffin. -- Martin Cooper Yoav > > -- > Yoav Shapira > Senior Architect > Nimalex LLC > 1 Mifflin Place, Suite 310 > Cambridge, MA, USA > [EMAIL PROTECTED] / www.yoavshapira.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Representing project inactivity on the site
On 3/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > > On Sun, 5 Mar 2006, Martin Cooper wrote: > > > On 3/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > >> > >> All (90%?) of the navel gazing comes down to one binary question. > Should > >> Jakarta be a community, or a community of communities. Are we Jakarta > >> committers, or ORO committers. > > > > > > It should be what it is. As I just wrote in another message (on > commons-dev, > > I think), you can't make a community into something other than what it > has > > grown into organically. > > Agreed - that's why I'm not JFDI as one piece of advice I've received > suggests. I'm also trying to avoid it being manipulation - I could have > pushed each item one at a time in most-likely-to-be-accepted order. That > would have been a lot easier, but too machiavellian. > > Least I'm trying to not be doing that :) Thus emails about long term ideas > etc. More confusing to the community, but less manipulative. > > >> I'm not tied to any of the things I'm suggesting - except the strong > >> belief that Jakarta as a community of communities cannot work. So I'm > >> definitely in favour of more shared site and less individual site - I'm > in > >> favour of a flat Jakarta, both in terms of SVN acces and not allowing > >> subprojects of subprojects (ie: Jakarta Velocity-DVSL, not Jakarta > >> Velocity DVSL); I'm in favour of sharing the decisions - rather than > >> having a slice of the PMC informing the main PMC of their decision. > >> > >> Agreed - most/all of this will seem backwards if someone takes the view > of > >> community of communities as opposed to single community. > > > > > > And there you have the nub of my objections to all this manipulation of > > communities. > > Stepping further back than the community question - do you think the > current Jakarta community of communities is healthy? Not completely, no. I don't follow all the pieces as closely as I believe you do, but gangrene has definitely set in in places. Taglibs is the example I'm most familiar with, but I believe that can be resolved by amputating the truly dead limbs and revitalising the remainder as part of the (eventually, I hope) forthcoming Jakarta Web Components subproject. (On the other hand, I suspect that part of the reason for the demise of Taglibs is because a lot fewer people are using JSP tags these days, having moved on to AJAX or JSF.) With many Jakarta subprojects having been around for some time, some of them are just more or less "done", which leads to quiet spots in the community. I think that's fine - we need to recognise that most software projects don't go on forever (even if it can seem otherwise, sometimes ;), and most developers don't work on the same projects all of their lives. When the conversation slows or comes to an end on subproject X, we shouldn't assume the community is then unhealthy. Maybe it's just "done", or people have moved on to a different technology, or whatever. Putting an old race horse out to pasture is a lot different than killing it. ;-) Do you think there > are ways that an umbrella (in the negative sense of the word) can continue > to grow (in health rather than size) within the ASF? In health, yes, and I think we're on that path. Shrinking in size and bringing the scale of subprojects closer together both help, and much of that has happened, with the big subprojects moving out to TLPs. Getting Web Components off the ground will also help. And in that same vein of collecting like components into Commons-ish sets, I believe that Stephen Colebourne's proposal for Jakarta Language Components would also help. Despite some pitfalls along the way, I believe the Commons model has worked well, and seeing that spread into Web Components and Language Components is great. -- Martin Cooper It's possible it's just me wanting to make the chair role a non-fulltime > job. > > Hen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: One community or many
On 3/5/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote: > > Henri Yandell wrote: > > I'm not tied to any of the things I'm suggesting - except the strong > > belief that Jakarta as a community of communities cannot work. So I'm > > definitely in favour of more shared site and less individual site - I'm > > in favour of a flat Jakarta, both in terms of SVN acces and not allowing > > subprojects of subprojects (ie: Jakarta Velocity-DVSL, not Jakarta > > Velocity DVSL); I'm in favour of sharing the decisions - rather than > > having a slice of the PMC informing the main PMC of their decision. > > It just seem to me to be impossible to imagine a commons-betwixt > developer caring about velocity-tools, or a taglibs-foo developer caring > about bcel. There is no community in common. > > In commons we care about a broad range of different projects. But the > degree to which we care about components other than our own has reduced > over time (roughly inverse proportional to the number of components). > > So yes, in the past I was gung-ho about commons taking over the whole of > Jakarta. Now I recognise commons can barely manage itself, let alone any > more projects. Size matters. Yes, it does, and I think it's really important that we recognise that. Those of us who've been around since the inception of Commons, in particular, will hear the ring of truth in Stephen's words. Jakarta Commons was a much more cohesive and vibrant community in the early days, and there were indeed more committers per component, on average, than we have today. Now, while Commons has been growing like topsy, Jakarta as a whole has been shrinking, with several subprojects graduating into their own TLPs. That has been good for Jakarta, and for those subprojects. There's not much left that could logically go TLP, so we need to deal with what's left. I agree with Stephen's comments above that forcing everything that's left into a single group doesn't make sense. They really are different, and we should recognise that. (In fact, commons often behaves as multiple communities already. Its > natural and organic. I'm embracing it by proposing Jakarta Language > Components.) And I believe that is the way forward, especially for Commons. HttpClient blazed a path, and now we have Jakarta HTTP Components. We're about to create Jakarta Web Components, which will acquire pieces from Commons and Taglibs. So it makes perfect sense to take the group of components related to extending the Java language and form Jakarta Language Components out of that. The end result will be smaller, more cohesive, more vibrant communities than we have today. It's hard to imagine why that would be a bad thing! -- Martin Cooper At some point a recognition needs to occur that hierarchy is not evil. > We are all developers. We group things into hierarchies naturally. If > you flattened all the turbine components on the home page of jakarta all > you'd be doing is forcing the reader to group them. The turbine > components will always 'belong to' Turbine. > > > In summary, I believe we are many communities, not one. What unites us > is our size, in that each individual community is too small to stand > alone as a TLP. There is the *potential* to build a cross-Jakarta > community in *addition* to our smaller communities, but it requires care > and nurturing. Perhaps a single jakarta-user ML, or a forum are the > places to start. > > Stephen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Jakarta Web Components
On 3/6/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > On 3/6/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > > (feel free to keep discussing names etc, but for the moment I'm going to > > go ahead with the one above) > > > > > But do it within a reasonable time frame (atleast post any objections > to JWC in a week -- I think thats reasonable, unless anyone wants more > time?). I have been meaning to add some initial components to JWC and > begin work there, and while I agree that the name is important, this > name game is now getting old ;-) > > Recap - We had 3 votes for JWC in the initial vote thread, and there > seems to have been more added informally on parallel conversations on > commons-dev. Seems the J*C "trend" is catching on (see Stephen talk > about JLC in another thread). > > > > Would anyone like to start putting together a list of constituent parts > > for JWC? Please include a proposal for what will happen to any > subprojects > > left dead by the creation of JWC (ie: Taglibs). > > > > > Allow me to informally assemble the beginnings of a roster, hopefully > others can add/remove. > > From Commons: > > * EL (dormant?) > > * FileUpload (active, martinc should confirm interest in moving to JWC) I'm not so sure about this. FileUpload has already cloned some code from HttpClient, and could undoubtedly make use of more. Its purpose is to parse HTTP requests. So I'm actually more inclined to move this to Jakarta HTTP Components, assuming that HttpClient eventually morphs into that. (I thought it had already, but I can't seem to find a JHC anywhere.) * Latka (dormant) > > * FeedParser (possibly? dormant) > > From Taglibs: > > * Reusable Dialog Components (RDC) (JSP 2.0, active) > > * Others per interest (I have little interest in JSP 1.1/1.2 taglibs, > been on 2.0 for a while now) I used to work on the Mailer taglib, but abandoned it when someone else decided to reinvent that as a Mailer2 taglib. That now appears to have been abandoned as well, and never made it out of the Taglibs sandbox. So I'm not sure which, if either, would go to JWC. -- Martin Cooper Then there is the question of sandbox. There has been talk about a > Jakarta sandbox, that probably deserves its own thread. > > -Rahul > > > > Hen > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
