Re: Cactus Eclipse Plugin page on website
But it *is* available. At least, I managed to find it in a couple of minutes. The source code is here: http://svn.apache.org/repos/asf/jakarta/cactus/trunk/integration/eclipse/ and there are binaries available in the Maven central repo. I don't doubt that it is not actively developed, though, and I can't say which versions of Eclipse the binaries were built for. Since the source is available, though, you should be able to easily build it yourself if need be. -- Martin Cooper (Disclaimer - I have no affiliation with Cactus in any shape or form.) On Wed, Jul 29, 2009 at 5:38 PM, Clifford Alan Jones wrote: > Apparently the Cactus Eclipse Plugin is not in development and is > unavailable. Unfortunately, I could not tell that from browsing the Cactus > website. Removing the a link to download the now unavailable plugin, > causing people to search the page and the website in vain, is not sufficient > . > > It's confusing and wastes peoples time. > > Somewhere on the page for the Eclipse Cactus Plugin, it should say clearly, > boldly and obviously near the top of the page that the plugin in not > available and not being actively developed. Perhaps there could even be a > plea for interested volunteers to take up the task. > > I don't know if this mailing list is the appropriate forum, but could > someone please update the Eclipse Cactus Plugin page. Countless hours of > people's time is being wasted. > > thanks > > - > To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org > For additional commands, e-mail: general-h...@jakarta.apache.org > >
Re: Suggestion to use OpenGrok to index all Jakarta source code
On 9/3/07, Henri Yandell <[EMAIL PROTECTED]> wrote: > > Personally I'd ask the reverse question of the Fisheye users. Can > OpenGrok serve the same purpose? > > If so, then we should stop using the commercial app and move to the open > app. Other things being equal, I would probably agree with you. However, with FishEye, Cenqua (now Atlassian) takes care of hardware, installation, upgrades, maintenance, etc. so that we don't have to. The proposal in this thread is that the ASF take all of this on in order to run OpenGrok as part of the ASF infrastructure. I'm much more inclined to leave things as they are, with Cenqua doing the work, than I am to have us take on all the work just because we'd prefer the open source project. -- Martin Cooper On 9/3/07, Ted Husted <[EMAIL PROTECTED]> wrote: > > Would FishEye serve the same purpose? > > > > * http://fisheye6.cenqua.com/ > > > > There is already a procedure for using FishEye with an ASF project. > > First, ask on infra@ for permission to have cenqua.com setup a FishEye > > instance for your project. Then, contact [EMAIL PROTECTED] > > and ask them to add your project, and include a copy of the post from > > [EMAIL PROTECTED] > > > > ATM, the only concern seems to be that the initial indexing occur over > > the weekend. The administration is handled on the cenqua.com side, and > > so our group is not directly involved. > > > > Meanwhile, Atlassian has acquired Cenqua Products, and we're told that > > Atlassian is working on integration components with JIRA and other > > Atlassian products. The integration products are expected to be open > > source, and so we will be able to use them here as soon as they are > > available. > > > > -Ted. > > > > On 9/1/07, Alf Høgemark <[EMAIL PROTECTED]> wrote: > > > I have a number of times missed an an easy to use web interface for > > > searching through all Jakarta source code and subversion change logs, > > > and to also being > > > able to see line number and subversion change log history for a > > > particular file. > > > > > > The OpenGrok tool ( http://www.opensolaris.org/os/project/opengrok/ ) > > > seems to me to be very useful in that respect. > > > So I would like to suggest that OpenGrok is set up to search and index > > > the Subversion repository at http://svn.apache.org/repos/asf/ > > > OpenGrok seems to be a lot more useful than what is currently > available > > > using a web browser to point to http://svn.apache.org/repos/asf/ > > > > - > > 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] Commons moving to TLP
On 5/8/07, Henri Yandell <[EMAIL PROTECTED]> wrote: [X] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... -- Martin Cooper
Moderators needed
I need to step down from being a moderator of some of the Jakarta mailing lists. Before I do, though, I want to make sure that we have adequate coverage, which in my mind means at least two moderators for each list. With myself excluded, here's what we would have for the lists for which I am currently a moderator: announcements - craigmcc bayard mvdb taglibs-dev - husted taglibs-user - husted The announcements list looks fine, but we'd want to have at least one more moderator for each of the taglibs lists. Any volunteers? I believe any committer can be a moderator of these lists. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
On 3/19/07, Vadim Gritsenko <[EMAIL PROTECTED]> wrote: Martin Cooper wrote: > On 3/19/07, Vadim Gritsenko <[EMAIL PROTECTED]> wrote: >> Martin Cooper wrote: >> > Those sites provide infrastructure, but absolutely no legal protection. >> >> Who says there is no way to combine legal protection and non-absurd >> procedures? > > Not me. We don't have absurd procedures, so we're already there. I consider tag before vote as absurd. Yeah, well I consider voting on something that doesn't exist yet to be absurd. So there we are. By the way, if you really want to change any of this, burying the discussion in a vote thread on this list isn't the best way to go about it. -- Martin Cooper For example: community votes for a release, RM tags a release (and prepares >> files), pmc rubber-stamps it with 'ACK' within 72 hours (a-la PMC >> composition change process), done. > > PMCs are not about rubber-stamping anything. They are about project > oversight and responsibility. Oversight and responsibility is happening before you tag. They are part of day to day work. Mechanical checks for NOTICE and LICENSE files preceding approval for distribution stamp happen after. >> And the big one. The main goal ASF exists for is fostering software >> development >> communities. With second goal being software released in the process. And >> the legal part here is an *evil necessity*, it is *not* a goal. > > Interesting perspective. Thanks. Vadim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
On 3/19/07, Vadim Gritsenko <[EMAIL PROTECTED]> wrote: Martin Cooper wrote: > Those sites provide infrastructure, but absolutely no legal protection. Who says there is no way to combine legal protection and non-absurd procedures? Not me. We don't have absurd procedures, so we're already there. For example: community votes for a release, RM tags a release (and prepares files), pmc rubber-stamps it with 'ACK' within 72 hours (a-la PMC composition change process), done. PMCs are not about rubber-stamping anything. They are about project oversight and responsibility. And the big one. The main goal ASF exists for is fostering software development communities. With second goal being software released in the process. And the legal part here is an *evil necessity*, it is *not* a goal. Interesting perspective. But my reading of the first couple of sentences of this page suggests otherwise: http://www.apache.org/foundation/ -- Martin Cooper Vadim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
On 3/19/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: Something being a good idea and being "required ASF policy" are really very different things. The suffering is in the implication that I'm not already being careful. So you've never made a mistake in your life? And you're willing to bet a law suit on continuing to never make a mistake? That we're not all supposed to be slightly better than average developers with the apache branding and all. The fact that it's ok to send me emails telling me I'm part of a "problem project" because I haven't followed some new guidelines put in place because of other peoples mistakes - mistakes I haven't even made is really just insulting and annoying. I wonder how often these kinds of emails come out on the google code or sourceforge lists? :/ Those sites provide infrastructure, but absolutely no legal protection. -- Martin Cooper On 3/19/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: > There are all sorts of things that can go wrong when cutting a release > - an example the other day - Tomcat 5.5.23 had/has a problem because > the RM didn't have a jar in his local environment - its not a > guarantee I know (Tomcat produce artifacts to vote on before release!) > - but the more pairs of eyes checking out the distro before it goes > out has got to be a good thing. Its not about incompetance, just > catching mistakes before rather than after. I also don't get your > "suffering" point - most projects can produce a RC quickly - Tag & > Build - doesn't take long - so where is the suffering in doing that > before calling a vote? > > Niall -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bugzilla administration
I've taken care of this. -- Martin Cooper On 3/10/07, Torsten Curdt <[EMAIL PROTECTED]> wrote: http://issues.apache.org/bugzilla/show_bug.cgi?id=40577 How can I add new version to bugzilla? Who has admin rights on bugzilla? cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should "not-yet-commons-ssl" go?
On 2/24/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote: >> >> Let's keep this statement your personal opinion on the fact that it is >> not >> relevant. I still like to >> know the opinion of others. > > > If you want opinions, don't use a vote to collect them. This is a vote > thread, not an opinion thread. Votes within the ASF are for decision > making, > not opinion polls. Jakarta is well known, in a negative way, for being > overly vote-happy, so we should be doing our best to confine our use of > voting to things that really need to be voted on. That includes neither > opinion polls or consensus building. > > My statement was that the final destination of a project is not relevant > for > a vote on whether or not it should be accepted into the incubator. I > consider that to be a simple fact about the way the incubator works, not an > opinion. > The difference of opinion here is that you see this as a vote about incubating ssl, which is simply not our call. Not true. There are two basic requirements for entry into incubation: a Champion and a Sponsor. Once both are found, the project is accepted. That's it. So by stepping up and being a Sponsor, the Jakarta PMC could play a pivotal role in the incubation of this SSL project, because without a Sponsor, incubation is not going to happen, and once it has one, and a Champion, entry into incubation is a done deal. We can vote however on accepting ssl into Jakarta, which has the consequence that Jakarta is going to be actively involved as a champion / sponsor role to have the Incubator accept ssl. Those things are not quite as connected as you make them out to be. Yes, we could decide that Jakarta would be happy to have the SSL project land here after incubation. But that does not imply any particular involvement in the incubation process, and in the absence of a decision to be the project's Sponsor, it is meaningless. So the real decision to be made is whether or not the Jakarta PMC is willing to step up and be the Sponsor for the SSL project. That basically means two things: 1) Do we believe that this project would make a worthy addition to the ASF? This is regardless of where it might land after incubation. 2) Would we be willing to accept the project as part of Jakarta once incubation is completed successfully? Note that #2 says that we are _willing_ to accept it, and makes no statement about whether the project will, in fact, end up as part of Jakarta, or go somewhere else. So let's restart the vote (again - sorry) and make it very clear that we are voting to be the Sponsor of the SSL project, and thus voting on whether it should enter into incubation or not. Say if the target is commons, we probably should have commons-ssl end up in the website of commons, have Julius participate on the commons website, instead of having separate lists, separate website and a separate PPMC and learning the commons way is pretty hard when you are actually not integrated into the commons community to begin with. We are talking about around 20 classes here and 1 new committer (afaik). What makes this case special compared to eg webwork (came across this while wading through the incubator archives to find similar scenario's) ? Maybe it's just a different definition of the meaning of full incubation. Things I want see solved during incubation here is (assuming commons is the target) : - IP clearance (paperwork is done by the way) - It contains crypto, so we probably need some legal advice on this (currently a discussion on legal btw) - Making sure Julius is here to stay (so preventing a new dead commons project) - Getting enough support in commons, so it's not a one man project Commons is not the issue here. Building a community around the code, within the ASF, is the issue. Without that, incubation will fail. This is, IMHO, the single most important criterion for any ASF project. - Everything takes place on the commons mailinglists (user and dev) - Release votes needs to be the same as any other commons component, with the addition of an extra incubator vote. - Reuse of commons infrastructure, probably with the exception of svn (eg incubator svn and have separate permissions, with the whole of jakarta being able to work there) Agreed on these last three, with the proviso that they apply to whatever environment the project might land in after successful incubation, be it Jakarta or elsewhere. -- Martin Cooper Thoughts welcome... Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should "not-yet-commons-ssl" go?
On 2/23/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote: Martin Cooper wrote: > On 2/23/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote: >> >> I prefer this vote to see where it should end up in Jakarta and based on >> that result the path full >> incubation / legal incubation is decided. >> >> So in my view the vote should be : >> >> [ ] Jakarta should sponsor (which effectively states we like to see the >> code end up here) > > > +1 > > [ ] Jakarta shouldn't sponsor (which effectively means it will end up TLP) > > > No, it means that it still needs to find a Sponsor before it can be > accepted > into incubation. It says nothing about where it will end up after > incubation > or even if it will start incubation. > > if accepted in Jakarta, it should end up in : > > > This is not relevant. The final location of a project is not decided until > it is ready to _exit_ incubation, so it's more than a little premature > to be discussing this here. Let's keep this statement your personal opinion on the fact that it is not relevant. I still like to know the opinion of others. If you want opinions, don't use a vote to collect them. This is a vote thread, not an opinion thread. Votes within the ASF are for decision making, not opinion polls. Jakarta is well known, in a negative way, for being overly vote-happy, so we should be doing our best to confine our use of voting to things that really need to be voted on. That includes neither opinion polls or consensus building. My statement was that the final destination of a project is not relevant for a vote on whether or not it should be accepted into the incubator. I consider that to be a simple fact about the way the incubator works, not an opinion. -- Martin Cooper Main reason : it is very interesting to see to figure out what the exit criteria should be for a small component like ssl (besides the IP stuff). Would be nice to get Robert's view on this (I will start a discussion after the vote, so the vote doesn't get too polluted). Could be that I am the only one seeing the difference during incubation depending on the target within Jakarta, so if that's the case it's probably best for SSL that other people step up as mentors and champions. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should "not-yet-commons-ssl" go?
On 2/23/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote: I prefer this vote to see where it should end up in Jakarta and based on that result the path full incubation / legal incubation is decided. So in my view the vote should be : [ ] Jakarta should sponsor (which effectively states we like to see the code end up here) +1 [ ] Jakarta shouldn't sponsor (which effectively means it will end up TLP) No, it means that it still needs to find a Sponsor before it can be accepted into incubation. It says nothing about where it will end up after incubation or even if it will start incubation. if accepted in Jakarta, it should end up in : This is not relevant. The final location of a project is not decided until it is ready to _exit_ incubation, so it's more than a little premature to be discussing this here. [ ] commons as a component [ ] httpcomponents as a component [ ] subproject directly under Jakarta [ ] integrate / merge code into project xxx (please replace x) (so not a subcomponent of a project!) And [ ] I am willing to mentor (you need to be on the Incubator PMC / Member of the ASF) [ ] I want to get involved in coding [X] No interest in getting involved. -- Martin Cooper Reasoning : 1) the first decides if Jakarta wants to sponsor this 2) we need to know the place it should end up in Jakarta (at least have some kind of direction) 3) if no one is interested in getting involved or being a mentor (preferably 3 mentors!), we can easily see if option 1 and 2 are viable at all. The problem with the current vote is that I have to start yet another vote to let us sponsor and where it should end up, best to do it in one go in my opninion... So Martin and Ortwin could you please revote ? (Sorry for the inconvenience) Mvgr, Martin
Re: [Vote] Where should "not-yet-commons-ssl" go?
On 2/23/07, Julius Davies <[EMAIL PROTECTED]> wrote: Hi, Jakarta-General, Let's vote on where to put this code! Here's the code right now: http://juliusdavies.ca/commons-ssl/ Forgive my newbieness; I hope these are the right options: [] Sub-module in Httpcomponents. IMO it would have to pass through incubation before this could happen anyway. [] Sandbox. The sandbox is open only to ASF committers. IIRC, you're not (yet) a committer. [+1] Full Incubator. +1. IMO this is the correct and appropriate path. -- Martin Cooper [-1] "not-yet-commons-ssl" is not a good project for Apache because... I'm fine with majority rules, assuming there are no "-1" votes. Some background: http://wiki.apache.org/jakarta/JakartaBoardReport-February2007 "The code grant for the not yet commons SSL (formerly named commons-ssl), has been completed, so we can progress to having a vote where SSL should end up on general and based on that result take the correct incubator path (legal / full incubation)." Let's just get this vote out of the way, and then we can move on to other issues in the appropriate venue (HttpComponents, or Sandbox, or Incubator). My original proposal to "jakarta-general" about the project is here: http://www.mail-archive.com/general@jakarta.apache.org/msg12790.html Yesterday I released "not-yet-commons-ssl-0.3.7". Changes described at the bottom of this email. My intention is for 0.3.7 to be the last release outside of Apache. By the way, there's one undocumented feature of common-ssl that's been quite fun: http://juliusdavies.ca/commons-ssl/javadocs/org/apache/commons/ssl/OpenSSL.html :-) yours, Julius ps. My vote is: [+0] - Abstaining because I'm too much of a newb to really understand what I'm voting for.
Re: List moderator cleanup..
On 2/18/07, Henri Yandell <[EMAIL PROTECTED]> wrote: Heh. Whereas I go through the spam every now and then and delete the spam and reply with -allow to the good ones (except for announce@ where I always do -accept) and while I reply to -owner I can't do much for people as a moderator any more because gmail.com doesn't seem to work with the list moderation commands. Check out the thread with subject "List Moderator Help please" on infra@ from late January - sebb found ways to do this. -- Martin Cooper * * Hen On 2/18/07, Andrew C. Oliver <[EMAIL PROTECTED]> wrote: > I think people have a different way to moderate them. I lack > time/motivation to explicitly read > every spam that comes through as a moderation request and only respond > directly to -owner requests (provided the request is reasonable and > stated politely) > > -andy > > Martin van den Bemt wrote: > > Hi everyone, > > > > Since I had reason to believe that not all lists are moderated (some mails are just not coming > > through), I thought I do an "audit" on what lists are moderated by who. > > I will mail all the moderators individually to ask if they are still active, in the mean while I > > asked to be added as a moderator for the jcs lists, which don't seem to be covered atm (there is a > > moderator, but unlikely to be active). > > > > Mvgr, > > 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]
Re: PROPOSAL: commons-ssl -> commons-sslutils?
On 12/1/06, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: On Fri, 2006-12-01 at 15:20 -0500, Vadim Gritsenko wrote: > Julius Davies wrote: > ... > > I had to explain that Commons-SSL just sits on top of the JSSE and JCE > > to try and make working with SSL and Java easier. Your point about > > the name is a good one. > > The counterpoint to name argument. Just single example, I'm sure there are many > more: commons-logging sits on top of log4j/java logger/logkit/... and tries to > make working with all them seamless. > > commons-ssl may be not the best name but it isn't terribly bad either. > > Vadim > Folks, What about Commons-SSLUtils? This name seems consistent with already existent Commons projects (DBUtils) Calling it Commons-anything presupposes where it would land up after incubation. That's not something that we should be doing, as the final resting place of an incubated project is not determined until incubation has successfully completed. On the other hand, I think SSLUtils would be a fine name to run with. -- Martin Cooper Julius, Since "what-some-day-might-become-commons-ssl" is partially based on some little bits of code I wrote, you can safely add me to the initial list of committers. I will not be able to do a lot in terms of coding, given my HttpComponents commitments, but I could help by doing some code reviews once in a while and participating in design decisions. Cheers, Oleg > ... > > > On 12/1/06, Roland Weber <[EMAIL PROTECTED]> wrote: > >> > >> The working title "Commons-SSL" does not really reflect this. Do you > >> plan to implement the SSL protocol as part of the project? Probably > >> not, so the title is misleading. An all-encompassing name might also > >> be offensive to people working on other SSL-related projects. I think > >> you should spend the time and define not only a motto, but a very clear > >> scope of the project. Both in terms of what's in scope as well as what's > >> out of scope. From there on, we can work on finding a name and home. > >> > >> Please do not underestimate the importance of this step. Finding a > >> name may seem like a minor detail, but the problem of defining the > >> scope is very real. Only a few months ago, there was a long discussion > >> on this list about a proposal for "testing.apache.org". I haven't read > >> anything about it anymore after the supporters realized that a scope of > >> "everything that has to do with testing" was overly broad. We don't > >> want to see that happen to your proposal. > > > - > 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: commons-fileupload: Streaming mode
On 11/2/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: In the mean time, can you publish a SNAPSHOT? Also, is anyone looking at releasing this stuff? Am I on the wrong mailing list (I couldn't find one for commons-fileupload)? The mailing lists for FileUpload are the usual Commons ones, viz [EMAIL PROTECTED] and [EMAIL PROTECTED] -- Martin Cooper Thanks, -dain On Nov 2, 2006, at 12:38 AM, Henri Yandell wrote: > Our (Commons) nightly build machine (vmbuild.apache.org) was on a > vmware zone that hasn't come back after the machine migration. It took > care of both the nightly dist build and the m1 snapshot repo > deployments. > > I'll pester for info again on it tomorrow; last I heard was that we > don't have vmware expertise and so it's a case of finding nudging > those who were involved with infra back when it was down to look into > it. > > It's all in SVN, so if nothing's forthcoming I'll look into setting > something up (unless someone else volunteers - always appreciated :) > ). > > Sad that we pestered Craig to get it off of his workstation, and we've > not managed to achieve his quality of service. > > Hen > > On 10/29/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: >> Has this code been Released yet? The latest version I see is 1.1.1 >> and it doesn't seem to contain the FileItemIterator class. Also >> there don't seem to be any nightly snapshots available. >> >> In the mean time I can build this by hand, but I'd prefer a Release >> or SNAPSHOT in a maven repo. >> >> Thanks for any help, >> >> -dain >> >> On May 23, 2006, at 5:10 PM, Dain Sundstrom wrote: >> >> > Wow. >> > >> > I can't wait to get my hands on this code. >> > >> > -dain >> > >> > On May 23, 2006, at 4:24 AM, Yoav Shapira wrote: >> > >> >> Hola, >> >> +1 to you getting commons-fileupload karma and doing it >> yourself ;) >> >> >> >> Yoav >> >> >> >> On 5/23/06, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: >> >>> >> >>> Hi, >> >>> >> >>> I have developed a modified version of the commons-fileupload, >> which >> >>> allow a true streaming mode. In other words, there's no need for >> >>> internal byte arrays or temporary disk files, you simply iterate >> >>> through >> >>> the items, get an InputStream on the items, read and process the >> >>> InputStream (for example, run an XML parser on it) and that's it. >> >>> The >> >>> API remains unchanged and the modifications are strictly >> internally. >> >>> >> >>> For obvious reasons, the patches are non-trivial. So far I have >> >>> splitted >> >>> some changes into three patches, which I have posted in Jira >> issues. >> >>> However, to get this patches in, one after the other, I see as my >> >>> only >> >>> chances, if an existing developer would express interest on the >> >>> changes, >> >>> review and guide my work and accept patches step by step. Is >> there >> >>> anyone who volunteers doing the job? Perhaps, being an active ws >> >>> committer, I might after some time as well receive Karma for >> >>> commons-fileupload and finish the work, if I have earned some >> trust. >> >>> >> >>> Regards, >> >>> >> >>> Jochen >> >>> >> >>> >> >>> >> >> >>> - >> >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >>> For additional commands, e-mail: [EMAIL PROTECTED] >> >>> >> >>> >> >> >> >> >> >> -- >> >> Yoav Shapira >> >> 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] >> >> >> > >> > >> > >> - >> > 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: [RESULT] Move Velocity to TLP
On 9/23/06, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote: Hi, I'm completely with Nathan here. A Velocity TLP will not be "another Jakarta" (though I do fail to see why everyone seems to believe that Jakata is always considered a bad example). On the opposite. The Velocity TLP is intended to help reducing the number of projects that Jakarta has. Which is a push that was started by Henri last year. The fact that Velocity already has a number of projects (VelocityTools, which doesn't make any sense without Velocity and same goes for DVSL; two projects that are heavily entwined with Velocity) will not go away whether it is located under Jakarta or its own TLP. I know that we will be reluctant in accepting new projects into Velocity and I hope that you will be one of the watchguards of that policy on the new Velocity PMC. But personally, I consider "Clustering" a good thing. Having a small group of related projects available through a single point of access (like e.g. the Lucene related stuff) is a good thing. I tend to agree with you. Unfortunately, I don't think Lucene is the best example to point to, though, since it demonstrates how projects can drift. What I mean is that something like Hadoop should not be part of Lucene, just as MINA should not be part of Directory. (I think) I understand how both of these happened, but still, it's something that a Velocity TLP would do well to bear in mind. -- Martin Cooper Just pushing everything top-level IMHO is not. Especially if projects are too small to go TLP. And putting e.g. VelocityTools under Jakarta would IMHO not be correct because it would be somehow "lost" there. A project like that would always look towards Velocity even if it is located somewhere else. For upcoming stuff: there currently is talk with Click (click.sf.net), and the relation of Click to Velocity is similar (IMHO) the the relation of Velocity to VelocityTools. They will have to go through incubation (surely) if they decide to join, but the communities of Velocity and Click seem to be an even match. So, in a nutshell: Don't worry. Velocity will not become another Jakarta. It might become another Lucene or MyFaces with a small number of clearly defined, Velocity related projects, though. Which is a good thing IMHO. Best regards Henning On Fri, 2006-09-22 at 21:18 -0700, Nathan Bubna wrote: > On 9/22/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > This vote closed sooner than expected. I was traveling and there was no > > stated deadline. > > Aw, c'mon. It's been in discussion on velocity-dev for over a month, > and i gave the vote a full week! > > Still, further votes and discussion are fine with me... :) > > > I'm +1 and -1. > > > > I'm +1 as I do think that Velocity as a TLP is not unreasonable. Not > > necessary, but not unreasonable. > > > > I'm -1 because I'm worried that this is a new kind of umbrella that's > > planned. Making it a catchall for things that are and use Velocity is > > going the wrong direction. > > Nothing new about it. Velocity became just such an umbrella under > your leading, or am i mistaken about your part in forming DVSL and > VelocityTools? :) > > And the idea is not that all Velocity using projects are welcome, but > that we are free to invite projects that are explicitly built upon or > for Velocity. There are big differences between being free to invite > projects and being a "catchall" and between being a project that uses > or supports Velocity and one that is explicitly built for or upon > Velocity. > > > If there are projects that aren't template engines that want to come to > > Apache, the door is open and they are welcome. > > And template engines are welcome too, right? The question is whether > being here would be just about them having the foundation and > infrastructure support or if there is a community aspect too. If > community matters, then it matters where they fit in Apache > organizationally. So rather than a blanket statement that any > Velocity-related projects are welcome or not welcome, i prefer having > the freedom to individually vet the merits and fit of project > interested in joining the Velocity TLP. And you, as a Velocity PMC > member, would be very, very welcome to join in those discussions and > decisions. > > > But putting anything that uses Velocity into a TLP is like using things > > that use log4j into the same TLP (which would re-create Jakarta... :) > > Yep, good thing that's not the plan! :) > > > geir > > > > > > Nathan Bubna wrote: > > > Looks like the Velocity community is ready to head out on its own... > > > &
Re: [PATCH]: site/vendors.xml/html
Hmm, are we OK with having companies naming themselves after ASF projects? -- Martin Cooper On 9/6/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote: Hello, Would it be possible to add Lucene Consulting to the Specialized Solution providers section on http://jakarta.apache.org/site/vendors.html ? The patch is attached. If the attachment doesn't make it through the ML, it is also here: http://lucene-consulting.com/vendors.patch And here is the info inlined: Lucene Consulting / http://www.lucene-consulting.com/ - We provide services around Lucene, Solr, and Nutch. Our services include providing best practices, code reviews, scaling, performance tuning, etc. advice, as well as custom development. Our experience includes working with Java web apps (Jetty, Resin, and Tomcat, Struts), PostgreSQL, MySQL, Oracle, and Hibernate, document indexing/searching (e.g. PDF, RTF, XML, HTML...), web crawling, etc. - USA and Croatia - info at lucene-consulting dot com Thanks, Otis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Opening up the PMC
On 8/8/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: +1 If they are good enough to change/commit code then they should be able to vote. Isn't code the core of what the foundation provides anyways? (er something like that...) Actually, the community is the core. The code flows from the community. -- Martin Cooper On 8/8/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > Being on a PMC means two actionable things. Firstly, you get a binding > vote; and secondly, you can subscribe to [EMAIL PROTECTED] - a list which > should be pretty quiet (mostly it's just vote results now - would be nice > to move those to this list). > > The purpose of the binding vote is that that allows you to perform > oversight on behalf of the foundation - it's not me making a release, it's > the foundation. > > That's all there is. It's nothing special, just that we can yay or nay > something. There's not even any paperwork beyond the board ack email. > Given that - why do we have committers and pmc members? Why do we have > people in our community who have been accepted as committers and are > happily churning code, but are not allowed a binding vote? It's definitely > not because we have an enormously low bar of entry to being a committer. > > My view is that we shouldn't keep wasting our time on such a separation. > There is no danger at all (given our size) to having a new committer > immediately join the PMC, and there are notable benefits in that we don't > have to keep remembering to add people to the pmc (which we really suck at > doing) and we'll have a more open environment (which we all like right?). > Also we won't have second class citizens who have to yet again sit and > wait while their elders remember to nominate them as an elder. > > What do people think to the following: > > 1) Every existing committer not on the pmc receives an email asking if > they would like to join the pmc. Once that email is sent they are marked > in a file as having had the email sent and we can wash our hands until a > reply comes in. > > 2) Every new committer automatically gets added to the pmc. > > --- > > I bring it up because the concept has cropped up elsewhere at the ASF and > given our large non-pmc to pmc ratio I think we'll have a lot of strong > views on the subject. > > Hen > > (Yeah, I recognize that the above is flamebait if we have any strong > opinions out there. Hopefully it'll stay constructive :) ) > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: Opening up the PMC
On 8/14/06, Danny Angus <[EMAIL PROTECTED]> wrote: > 1) Every existing committer not on the pmc receives an email asking if > they would like to join the pmc. Once that email is sent they are marked > in a file as having had the email sent and we can wash our hands until a > reply comes in. I know that this is something that we had as the "end-game" when all the re-org changes started. > > 2) Every new committer automatically gets added to the pmc. I would recommend a probation period, JAMES tends to let people find their feet as commiters then propose them for the PMC. I agree with the probation period as well. In Struts, we look at PMC membership 6 months after someone becomes a committer. As long as they've stuck around and participated during that 6 months, we'll generally invite them to join the PMC. If they've faded away in that timeframe, then we'll let them go. This helps keep the PMC membership aligned with the people who are active on the project. (Active people do fade away as well, over time, so we'll periodically "prune" by moving people to emeritus status.) As a retrofitting measure, I also kinda like Phil's idea of allowing self-nominations. In conjunction with a probation period, this would help us "remember" who should be invited to join the PMC. -- Martin Cooper Sometimes its weeks sometimes months, but recently it is everyone and having people eased in seems to work well. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient please 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 Limited. 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]
Re: unable to subsribe to [EMAIL PROTECTED]
On 6/9/06, Ido M. Tamir <[EMAIL PROTECTED]> wrote: Hi, since 24hrs I was not able to subscribe with the link given here: http://jakarta.apache.org/site/mail2.html#Tapestry This is what I get: Hi. This is the qmail-send program at apache.org. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. <[EMAIL PROTECTED]>: If you check out the link here: http://tapestry.apache.org/mail-lists.html you will see that (a) it's 'users' rather than 'user', and (b) it's tapestry.apache.org instead of 'jakarta.apache.org' now. -- Martin Cooper Sorry, no mailbox here by that name. (#5.1.1) --- Below this line is a copy of the message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Commit access
On 6/6/06, Thomas Vandahl <[EMAIL PROTECTED]> wrote: Hi folks, how is the common svn commit access supposed to work? I was trying to commit something to Fulcrum but got "403 Forbidden". I have commit access to Torque, however. Any hint is welcome. Torque is part of the Apache DB project. Fulcrum is part of the Apache Jakarta project. They are entirely separate, with entirely separate SVN access control. From what I can see, you are a committer to the Torque sub-project, but you are not a Jakarta committer. -- Martin Cooper Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] Copyright dates
On 6/1/06, Henri Yandell <[EMAIL PROTECTED]> wrote: On Thu, 1 Jun 2006, sebb wrote: > At present, all the pages contain the footer: > > Copyright (c) 1999-2005, The Apache Software Foundation. _Legal information_ > > where _Legal information_ is a link to the legal page (which > definitely needs updating to 2006!) > > IIUC, the new footer would just be: > > _Legal information_ > > Is that correct? > > Or would it be better to have: > > Copyright (c) The Apache Software Foundation. _Legal information_ > > i.e. remove just the dates from all footers. That sounds good - I'm pretty sure it's not going to be bad to do that and change it later. Not having the first part will seem quite out of context. I think it would be worth asking whether or not a "copyright" notice without specified years is actually meaningful. My expectation is that it would not - i.e. that it would not imbue the pages with copyright protection at all. I guess the first question is: Do we care about our pages being copyrighted? I would expect that we do, in which case I believe we should make people aware of that. If we take the attitude that the copyright applies to the site and not to the individual pages, then I guess we could go back to what sebb was talking about in the first place, and use a boilerplate copyright on each page. -- Martin Cooper Once it's changed, I'll ping Cliff for confirmation. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] Copyright dates
On 5/31/06, sebb <[EMAIL PROTECTED]> wrote: I updated the stylesheet to change the Copyright statement from 1999-2005 to 1999-2006 a week or so ago. Of course this changes all the generated HTML pages. I've not yet updated them, as I wanted to double-check if this was needed or not (the stylesheet could be changed back). OR: would it be better to just change the copyright in files that have been updated this year? s/better/required/g. In other words, the copyright years in a file must include only the years in which that file was modified. -- Martin Cooper Not sure if it is possible to do this automatically... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Taglibs] svn messages not sent to taglibs-dev
On 5/21/06, Kris Schneider <[EMAIL PROTECTED]> wrote: I made a few commits to the Cache taglib last week but never saw the resulting email notifications on taglibs-dev. Are those going to a different list or is something just not configured properly? Thanks for any insight... I've been tied up with conferences, and backed up on my moderation duties. I just went through the taglibs queue, and moderated through the only commit I saw from you. Not sure what happened to any other ones. -- Martin Cooper -- Kris Schneider <mailto:[EMAIL PROTECTED]> D.O.Tech <http://www.dotech.com/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Tiles as the seed for Jakarta Web Components
On 4/25/06, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > This sounds great, Martin. But if i may be forgiven a little > semantic nitpicking, my understanding of previous discussions is that > JWC would be a "grouping" rather than a "sub-project". So Tiles would > be directly a Jakarta sub-project, rather than a sub-sub-project (i.e. > becoming "Jakarta Tiles", not "Jakarta Web Components Tiles"). Yes, you are correct, Tiles would be a Jakarta sub-project within the JWC grouping. I guess I was trying to simplify the proposal for those who haven't paid as much attention to the whole grouping thing, but in retrospect, that probably wasn't such a great idea. ;-) I do also like Andrew's term "sub-community" as that describes the > true intent of having these "groupings". > > As far as a formal scope to be attached to the Jakarta Web Components > group goes, i would propose that members of the JWC should be java > components developed primarily for use in the development of web > applications. That's a good start. I'm not sure it's enough, but we could start from there. -- Martin Cooper On 4/24/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > > There has been considerable discussion, on this list and others, about > the > > creation of a Jakarta Web Components sub-project (also previously known > as > > Jakarta Silk). I believe the concensus has been in favour of creating > it. > > However, we seemed to get bogged down, several times, in discussions of > the > > name, or of exactly which pieces of Jakarta Commons, Jakarta Taglibs, > etc., > > should move to the new sub-project. > > > > Meanwhile, over at Struts, we have had a number of discussions about the > > future of Tiles[1], currently a Struts sub-project. We have been working > > hard to make Tiles independent of Struts, and are close to achieving > that > > goal. With Tiles no longer depending on Struts, it makes little sense > for it > > to remain a part of the Struts project. In fact, it is much more likely > to > > flourish outside of Struts. > > > > The proposal, then, is to create the Jakarta Web Components sub-project, > and > > make Tiles the first citizen of that sub-project. This simultaneously > > achieves several objectives: > > > > 1) We actually get started with the Jakarta Web Components sub-project. > > 2) We can defer discussion of which other parts of Jakarta move there. > > 3) We create a logical home for the now-Struts-independent Tiles. > > > > While Tiles is a powerful templating framework, it is actually a fairly > > small code base, making it a good candidate for an independent web > > component. It is still being developed, so we would not be seeding > Jakarta > > Web Components with a dormant component. Several of the Struts > committers > > (many of whom are already Jakarta committers) would come here to > continue > > working on Tiles, and to help build the Jakarta Web Components > sub-project. > > > > Once Jakarta Web Components is up and running, it would, of course, be > up to > > the various communities surrounding Commons and Taglibs components, and > > potentially other Jakarta sub-projects, as to whether or not they choose > to > > join the new sub-project. The goal of this proposal is simply to seed > the > > sub-project and get the ball rolling. > > > > Comments? > > > > -- > > Martin Cooper > > > > [1] http://struts.apache.org/struts-action/struts-tiles/ > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [PROPOSAL] Tiles as the seed for Jakarta Web Components
On 4/25/06, Andrew C. Oliver <[EMAIL PROTECTED]> wrote: > > I'd be against another commons style sub-community. Unless you can show > me > a defined scope, "web components" means nothing, then expect my objection. Understood. A formal scope does need to be written down and agreed upon. However, I believe that concensus on the gist of such a scope has already happened, between the lines, in the numerous previous threads on JWC on various lists. -- Martin Cooper -Andy > > James Mitchell wrote: > > I believe that this would be a great way to bootstrap this new > community. > > > > If this were a formal vote, then I, as both a Struts PMC and a Jakarta > > PMC member, would throw a binding +1 your way. > > > > -- > > James Mitchell > > > > > > > > > > On Apr 24, 2006, at 11:56 PM, Martin Cooper wrote: > > > >> There has been considerable discussion, on this list and others, about > >> the > >> creation of a Jakarta Web Components sub-project (also previously > >> known as > >> Jakarta Silk). I believe the concensus has been in favour of creating > it. > >> However, we seemed to get bogged down, several times, in discussions > >> of the > >> name, or of exactly which pieces of Jakarta Commons, Jakarta Taglibs, > >> etc., > >> should move to the new sub-project. > >> > >> Meanwhile, over at Struts, we have had a number of discussions about > the > >> future of Tiles[1], currently a Struts sub-project. We have been > working > >> hard to make Tiles independent of Struts, and are close to achieving > that > >> goal. With Tiles no longer depending on Struts, it makes little sense > >> for it > >> to remain a part of the Struts project. In fact, it is much more > >> likely to > >> flourish outside of Struts. > >> > >> The proposal, then, is to create the Jakarta Web Components > >> sub-project, and > >> make Tiles the first citizen of that sub-project. This simultaneously > >> achieves several objectives: > >> > >> 1) We actually get started with the Jakarta Web Components sub-project. > >> 2) We can defer discussion of which other parts of Jakarta move there. > >> 3) We create a logical home for the now-Struts-independent Tiles. > >> > >> While Tiles is a powerful templating framework, it is actually a fairly > >> small code base, making it a good candidate for an independent web > >> component. It is still being developed, so we would not be seeding > >> Jakarta > >> Web Components with a dormant component. Several of the Struts > committers > >> (many of whom are already Jakarta committers) would come here to > continue > >> working on Tiles, and to help build the Jakarta Web Components > >> sub-project. > >> > >> Once Jakarta Web Components is up and running, it would, of course, be > >> up to > >> the various communities surrounding Commons and Taglibs components, and > >> potentially other Jakarta sub-projects, as to whether or not they > >> choose to > >> join the new sub-project. The goal of this proposal is simply to seed > the > >> sub-project and get the ball rolling. > >> > >> Comments? > > > > > > - > > 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] > >
[PROPOSAL] Tiles as the seed for Jakarta Web Components
There has been considerable discussion, on this list and others, about the creation of a Jakarta Web Components sub-project (also previously known as Jakarta Silk). I believe the concensus has been in favour of creating it. However, we seemed to get bogged down, several times, in discussions of the name, or of exactly which pieces of Jakarta Commons, Jakarta Taglibs, etc., should move to the new sub-project. Meanwhile, over at Struts, we have had a number of discussions about the future of Tiles[1], currently a Struts sub-project. We have been working hard to make Tiles independent of Struts, and are close to achieving that goal. With Tiles no longer depending on Struts, it makes little sense for it to remain a part of the Struts project. In fact, it is much more likely to flourish outside of Struts. The proposal, then, is to create the Jakarta Web Components sub-project, and make Tiles the first citizen of that sub-project. This simultaneously achieves several objectives: 1) We actually get started with the Jakarta Web Components sub-project. 2) We can defer discussion of which other parts of Jakarta move there. 3) We create a logical home for the now-Struts-independent Tiles. While Tiles is a powerful templating framework, it is actually a fairly small code base, making it a good candidate for an independent web component. It is still being developed, so we would not be seeding Jakarta Web Components with a dormant component. Several of the Struts committers (many of whom are already Jakarta committers) would come here to continue working on Tiles, and to help build the Jakarta Web Components sub-project. Once Jakarta Web Components is up and running, it would, of course, be up to the various communities surrounding Commons and Taglibs components, and potentially other Jakarta sub-projects, as to whether or not they choose to join the new sub-project. The goal of this proposal is simply to seed the sub-project and get the ball rolling. Comments? -- Martin Cooper [1] http://struts.apache.org/struts-action/struts-tiles/
Re: [VOTE] Jakarta Sandbox
On 4/10/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > > On Mon, 10 Apr 2006, Martin Cooper wrote: > > > On 4/10/06, robert burrell donkin <[EMAIL PROTECTED]> > > wrote: > >> > >> On Sun, 2006-04-09 at 22:31 -0400, Andrew C. Oliver wrote: > >>> Yes. A lot of things predate the incubator. I'm not opposed to say > an > >>> HTTPD-sandbox for experimental HTTPD related stuff. > >>> I'm not opposed to a POI-sandbox (indeed we have one but call it > >>> scratchpad) for POI-related stuff. However Jakarta-sandbox is > >>> SCOPELESS. Go have a scopeless sandbox on sourceforge IMO. If you > want > >>> to start a whole NEW project then do that in the incubator IMO. > >> > >> the sandbox already exists. the management and supervision were > >> entrusted to the commons sub-project. sub-projects have no formal > >> existence. the scope of the sandbox is the same as the scope for > >> jakarta. > >> > >> anything that is in scope for jakarta is in scope for sub-projects. > code > >> in other languages is pretty much out but nearly any subject is in > >> scope. the only limits are imposed by the community itself. > > > > > > When something graduates from this "Jakarta Sandbox", where does it go? > > Being a _Jakarta_ sandbox, one might assume that it becomes a Jakarta > > subproject. But Hen has claimed to want to morph Jakarta into a > > non-umbrella, and graduating to a new Jakarta subproject would be > counter to > > that goal. On the other hand, if it graduates to somewhere outside of > > Jakarta, why is the sandbox inside of Jakarta? > > In my incoherent mind it's: > > Jakarta is > Components > Sandbox > > Things move from sandbox to components. Once there, they are arranged into > groupings to smooth communication. That would be fine if there was a well-defined scope for the sandbox. As Andy and others have pointed out, there is no scope right now. That means that someone could start, say, a new servlet container, or an OSGi framework, or whatever, that would have no reasonable place as a Jakarta Component. -- Martin Cooper Hen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [VOTE] Jakarta Sandbox
On 4/10/06, robert burrell donkin <[EMAIL PROTECTED]> wrote: > > On Sun, 2006-04-09 at 22:31 -0400, Andrew C. Oliver wrote: > > Yes. A lot of things predate the incubator. I'm not opposed to say an > > HTTPD-sandbox for experimental HTTPD related stuff. > > I'm not opposed to a POI-sandbox (indeed we have one but call it > > scratchpad) for POI-related stuff. However Jakarta-sandbox is > > SCOPELESS. Go have a scopeless sandbox on sourceforge IMO. If you want > > to start a whole NEW project then do that in the incubator IMO. > > the sandbox already exists. the management and supervision were > entrusted to the commons sub-project. sub-projects have no formal > existence. the scope of the sandbox is the same as the scope for > jakarta. > > anything that is in scope for jakarta is in scope for sub-projects. code > in other languages is pretty much out but nearly any subject is in > scope. the only limits are imposed by the community itself. When something graduates from this "Jakarta Sandbox", where does it go? Being a _Jakarta_ sandbox, one might assume that it becomes a Jakarta subproject. But Hen has claimed to want to morph Jakarta into a non-umbrella, and graduating to a new Jakarta subproject would be counter to that goal. On the other hand, if it graduates to somewhere outside of Jakarta, why is the sandbox inside of Jakarta? -- Martin Cooper jakarta's scope is the problem but it's hard to fix for both historic > and community reasons > > - robert > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [VOTE] Jakarta Sandbox
On 4/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > Calling a vote to create a Jakarta Sandbox; which entails: > > * Move Jakarta Commons Sandbox to Jakarta Sandbox > * Migrate Jakarta Taglibs Sandbox into Jakarta Sandbox > * Create development mailing list ([EMAIL PROTECTED]) > * Create wiki (and migrate wiki bits from j-c-s/j-t-s) > * Jakarta Sandbox to initially use the Commons sandbox processes. What would be the constraints on what could go in there? Anything, as long as it's written in or for Java? [ ] +1 > [X] -1 This just seems like too big of a can of worms to me. -- Martin Cooper Vote to last no shorter than a week. > > Hen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: party@ for users?
On 3/28/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > > Hi! > > I would like to know if it is allowed for users to subscribe to > [EMAIL PROTECTED] AFAIK that list is open to ASF committers only. -- Martin Cooper (So that I can stop from posting to the user lists ;-) ) > > Ciao, > Mario > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: OneCommunityProposals - thoughts?
On 3/22/06, Yoav Shapira <[EMAIL PROTECTED]> wrote: > > Hola, > > > So anymore thoughts? Shall we vote on the wiki page as a whole, rather > > than individual items? > > Definitely individual items: Stefano (Mazzocchi) had a really nice > message once on another list about pursuing a policy of small > reversible steps instead of huge ones. So ours (something becoming a > TLP) may not be easily reversible, but I'd like to keep them small and > gradual where possible, especially given no additional benefit from > doing things at once. +1. I read Stefano's post too, and agree wholeheartedly. -- Martin Cooper > Shall we refine it the wiki page? > > Yeah, let's keep refining it until some date by which we want it to be > done. Your call on the date... > > Yoav > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [PROPOSAL] Cleanup pmc members
On 3/16/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > > On Thu, 16 Mar 2006, Roland Weber wrote: > > > Hi Hen, > > > >> My proposal is that we create a file in SVN in which PMC members can > >> list themselves as being active. After 1 month, failure to appear in > >> that list will result in removal from the PMC. If it goes well we could > >> consider doing it periodically, or just when it feels like the numbers > >> are getting out of sync again. > >> > >> Thoughts? > > > > Make sure there is an easy way for the removed people to get back > > on the list. Somebody might just be taking a longer vacation, or > > have a big backlog of things to do after a shorter vacation. > > 3 +1s from PMC members would be the most that would be needed - though I > think we could also do it without even needing that vote. Someone just > asks to be back on the PMC and after 72 hours they'd get added back on. The catch with this, though, is that someone coming back from a long vacation loses their binding vote on any vote that closes within that 72 hour period. -- Martin Cooper Hen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [PROPOSAL] Cleanup pmc members
On 3/16/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > Previously I'd suggested that we should be cleaning up inactive committers > and inactive PMC members - because I'm a bit of a tidy-addict sometimes > and I enjoy deleting :) > > A thread on [EMAIL PROTECTED] convinced me that this was half wrong though > - we shouldn't be worrying about cleaning up the large list of inactive > committers, they might come back and that would be great. > > However I do still think we should be cleaning up the inactive PMC > members. The PMC represents the active committers entrusted with oversight > - so to have inactive committers on there is a detriment to its ability to > get the job done. I think I know what you mean, but if I'm right, you didn't say what you mean. ;-) The PMC represents those people entrusted with oversight of the project. The manner in which we elect PMC members means that those people are committers. A PMC member may be active or inactive with respect to committership, and may be active or inactive with respect to oversight of the project. Those two are not necessarily tied at any given time. For example, someone might be actively working to ensure oversight of the project, but may not have committed anything for a long time. All that is a long-winded way of saying that it's not "inactive committers" that are the concern, but rather inactive overseers. Those people are harder to identify. Your SVN file proposal might help, although it's not a complete solution. (I'm not sure that there is one, though.) -- Martin Cooper My proposal is that we create a file in SVN in which PMC members can list > themselves as being active. After 1 month, failure to appear in that list > will result in removal from the PMC. If it goes well we could consider > doing it periodically, or just when it feels like the numbers are getting > out of sync again. > > Thoughts? > > Hen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: adding a link from commons.apache.org to Jakarta Commons?
On 3/13/06, Sandy McArthur <[EMAIL PROTECTED]> wrote: > > I know Jakarta Commons isn't a TLP but considering the > commons.apache.org space is vacant how about addins a blurb about the > Jakarta Commons. You'd have to sell this idea across the ASF, not just at Jakarta, and you'll likely get more than a little push back. That space was also the realm of Apache Commons when it existed. -- Martin Cooper It's the convention that you use your domain as your package. The > Jakarta Commons code is in the package org.apache.commons, not > org.apache.jakarta.commons. Also a number of times I've seen s stack > trace and simply reveresed the package name parts and pasted it into a > browser in an attempt to find out more about the code. > > I'm thinking a blurb at the bottom to the effect of: > > > If you came here looking for Java code in the org.apache.commons > packages then go see the href="http://jakarta.apache.org/commons/";>Apache Jakarta Commons > page. > > -- > Sandy McArthur > > "He who dares not offend cannot be honest." > - Thomas Paine > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Other Jakarta Components
On 3/12/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > > On Sun, 12 Mar 2006, Stephen Colebourne wrote: > > >>>>> DbUtils and DBCP to db.apache.org sounds like a win to me; DBCP > would > >>>>> point back to Jakarta for a dependency on [pool], but that helps to > >>> foster intra-project involvement. > >>>>> > >>>>> Betwixt, Digester and JXPath strike me as a bit more to swallow and > XML > >>>>> might not want to taking such bites. You want to go ahead and ask > them? > > > > Martin Cooper wrote: > >> I think this whole thing is putting the cart before the horse. You're > in > >> the > >> process of destroying Commons, not just dismantling it, and for no good > >> reason that I can see. The people involved with Digester should be the > ones > >> to initiate a discussion about whether or not they want to take > Digester > >> elsewhere. As it is, this is coming across more like "why don't you > guys go > >> away, somewhere far away, 'cos we think that's a good idea". > > > > +1. I believe there is the potential to group Jakarta around perhaps 4 > or 5 > > mailing lists groupings instead of 15+ now. But it cannot be forced. > > Right. My first response was that we needed to be sure community would go > with them. My gut instinct is that the DB ones would go - there's somewhat > of an overlap between db.apache and commons, but I'm not convinced the XML > ones would. > > Asking the question on commons-dev should initiate discussion with those > who care about Digester - ideally asking it here would too but they might > not be paying attention I guess. Waiting for every individual codebase to > individually decide to get active and discuss non-code issues is a > non-starter from the beginning. Why? > Just because db-commons and xml-commons exist doesn't mean that we should > > 'outsource' to them. OSS isn't like that. > > That's no reason to ignore the idea though. OSS is sometimes like that. > > > As I've said before, its in our nature as programmers to look for > > abstractions and hierarchies - to look for order. Community isn't that > > convenient. > > This still comes down to the basic issue :) I believe that as Thomas is a > Jakarta committer it is not an idea being forced from the outside, but > something from the inside. As he's a DB PMC member, then at least half is > very much from the inside - and I think he was involved in the Commons SQL > -> DdlUtils move. > > Even in the model where we only look to those with substantial commits to > a codebase - some of the inactive ones are going to be left behind and > will need someone to be suggesting a direction for them. Why? -- Martin Cooper Hen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Other Jakarta Components
On 3/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > > On Tue, 7 Mar 2006, Thomas Dudziak wrote: > > > On 3/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > >> DbUtils and DBCP to db.apache.org sounds like a win to me; DBCP would > >> point back to Jakarta for a dependency on [pool], but that helps to > foster > >> intra-project involvement. > >> > >> Betwixt, Digester and JXPath strike me as a bit more to swallow and XML > >> might not want to taking such bites. You want to go ahead and ask them? > > > > Well, yes, JXPath migh be a bit much, but Digester and Betwixt IMO > > would fit nicely. > > And obviously the component developers should agree first whether they > > think this is a good idea. And if they are interested, I can ask the > > DB PMC if they agree, as well. > > I don't think there is any active maintenance for DbUtils, and I suspect > not for DBCP either. I've been meaning to do some work on DbUtils - but I > have a long list of those. > > > However, I have no direct connections to XML PMC, and since I'm not an > > comitter on Digester/Betwixt/JXPath, it would feel a bit strange to me > > (though I would if you want me to). > > Go ahead and propose each one (db and xml) separately on commons-dev. See > if anyone speaks up against it - I suspect you'll find that for > betwixt/jxpath/dbutils/dbcp there won't be a huge amount of talk, though > Struts uses digester (I think) and they might have an opinion (they're > well represented on commons-dev). Yes, Struts uses Digester. It also uses BeanUtils, Chain, FileUpload, IO, Logging and Validator. I think this whole thing is putting the cart before the horse. You're in the process of destroying Commons, not just dismantling it, and for no good reason that I can see. The people involved with Digester should be the ones to initiate a discussion about whether or not they want to take Digester elsewhere. As it is, this is coming across more like "why don't you guys go away, somewhere far away, 'cos we think that's a good idea". Stephen's proposal for Jakarta Language Components came from "inside" that grouping. So should any other proposals for groupings or departures. With respect to departures in particular, there is a serious potential for losing community. For example, I keep tabs on a bunch of different Commons components, primarily because all of the discussions happen on communal lists. If Digester and DbUtils, for example, go to some other community where they also share lists, I am very unlikely to sign up for those lists just to keep tabs on those components. Maybe the developers will move, but how much of the community will go with them? -- Martin Cooper We're only going to end up with a Jakarta XML Components at this rate; > which would suck. The DB ones would either be in a Jakarta SQL Components > (suck) or a Jakarta Enterprise Components. The latter isn't so bad, but as > Geronimo shows - there's a lot in J2EE and I suspect that grouping would > balloon. > > Hen > > - > 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] > >
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: 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: 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: 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, 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: [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: 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: 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: [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: 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: 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: 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: 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: 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: 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: [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] > >
[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: 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] > >
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: [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: 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: 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: [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: 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: 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: 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: [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: [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 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: [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: 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: 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: [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: 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: [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: [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: 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: 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: [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: 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] 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: 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: [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: 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: [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: [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] 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 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] 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: 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: 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: 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: 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: 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 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: 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: 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: 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: 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: 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: 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]
