Re: Announcements without Release Notes
On Tue, 2009-01-06 at 12:51 -0800, Otis Gospodnetic wrote: Hello, General announcement question I have. I like getting announcem...@jakarta emails, as it allows me to passively keep abreast of new releases. What I like even more is when announcements have a link to release notes of some kind, so I can have a look at and quickly get an idea about the project's direction, velocity, focus, maturity, etc. without being intimately familiar with the project. For example, I just got an email about Mailet 2.4 release, but there was no link to release notes or a JIRA link that might show what was done between 2.3 and 2.4. I couldn't find any information on the site either. So, my questions are: Maybe I just don't know where to look? in this case there weren't any substantial changes between 2.3 and 2.4: 2.4 is just a release independent of the server. but i agree about this point in general and i will try to include more information in future. - robert (who hopes no one remembers that he wrote quite a lot of the release documentat...@jakarta) - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
RE: [VOTE] Move POI to TLP
On Mon, 2007-05-07 at 15:36 -0500, Laubach, Shawn Contr 555 ACSS/GFLA1 wrote: So I can vote for this but then I'm not a committer anymore? Just curious. anyone can vote (and please feel free to do so). however only some votes are binding upon apache. in this case, it's Jakarta PMC votes. if POI graduates then only Apache POI PMC votes will be binding. - robert signature.asc Description: This is a digitally signed message part
Re: [VOTE] Move POI to TLP
On Fri, 2007-05-04 at 10:17 +0100, Nick Burch wrote: snip So, now is the time to vote on the proposal: [X] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... - robert signature.asc Description: This is a digitally signed message part
Re: My svn account
On Wed, 2007-01-10 at 16:44 -0500, Andrew C. Oliver wrote: IIRC, this is my 4th attempt to resolve this (I try like every 3-4 months). I would like to commit something. My SVN account is not working. per the instructions off the SVN page I emailed [EMAIL PROTECTED] I got no response. I am still able to log in to people.apache.org. svnpasswd...? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Jakarta Commons Betwixt 0.8 Released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Jakarta Commons community is pleased to announce that Apache Jakarta Commons Betwixt 0.8 is now available for download from http://jakarta.apache.org/site/downloads/downloads_commons-betwixt.cgi. Please remember to verify the release when downloading from a mirror. Commons Betwixt is a reflective, dynamic, bean-centric object-xml mapper. It provides a flexible way to map beans into XML - and vice versa. It requires Java 1.3 or higher. For more details see http://jakarta.apache.org/commons/betwixt. Betwixt is an open source library developed by the Jakarta Project of the Apache Software Foundation (see http://jakarta.apache.org/) and released under the Apache License 2.0 (http://www.apache.org/licenses/LICENSE-2.0). Jakarta commons is an open development community. All are invited to contribute by joining us on the mailing lists (see http://jakarta.apache.org/commons) or by raising issues and submitting patches through http://issues.apache.org. Betwixt 0.8 is a feature release. Support for polymorphic mappings has been improved. More flexible mapping are possible using new strategies. Enhancements have been made to mapping formats. Mixed collections are now handled more completely. Complete details can be found in the release notes http://jakarta.apache.org/commons/betwixt/betwixt-0.8/RELEASE-NOTES.txt. Betwixt 0.8 is compatible with 0.7. Documentation for this release is available from http://jakarta.apache.org/commons/betwixt/betwixt-0.8/docs/index.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFFltPll6Otx30NTe0RAvu7AJ9L3vcD7XH8AYGMF0kqwto3G70AqQCgiwsc KDmH0kjk/bzAyhDwkdLz5ZQ= =BfSe -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[NOTICE] New OpenPGP Subkey For Email
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have now switched to using a subkey to sign email. Those using GnuPG may wish to upgrade to the latest version and gpg --refresh-keys. I maintain a statement of my OpenPGP policy at http://people.apache.org/~rdonkin/openpgp_policy.asc. Thanks Robert Burrell Donkin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFElwfd1TNOdbExPeIRAgsUAJ46C9ugHsZQfw5JyXfnAT7JlIfh7gCeI7YQ 5BenpnDyKs5R1bI+vNwt4Hw= =t4wD -END PGP SIGNATURE- signature.asc Description: This is a digitally signed message part
Re: testing.apache.org
On Mon, 2006-06-12 at 14:24 -0400, Rahul Akolkar wrote: On 6/11/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Thu, 2006-06-08 at 22:50 -0700, Phil Steitz wrote: Rahul Akolkar wrote: snip/ Per the umbrella concern, the question then becomes what -- if any -- are the mitigating factors that can address such a concern with regards to this proposal. Based on Hen's email, seems like the ball is still in the board's court -- as we wait for the next meeting -- so maybe its premature to discuss if we should be trying to address those comments yet? I would also like to understand exactly what the problem is and what mitigating steps may be possible. In particular, I would very much appreciate a definition of umbrella that allows Geronimo, Logging, Jakarta Commons, DB, XML, Web Services and Struts, but somehow disallows Testing. (this is the way i see the world and so is likely biased) the ASF runs on sub-minimal rules. most votes are subjective and not objective. the criteria applied are personal and evolve over time. past decisions are not revised to take account of changing opinions. snap/ Thanks for that input Robert, seems in line with what I had anticipated -- nice and fuzzy on an objective level. you know me too well :) often fuzziness indicates that the issues haven't really been completely settled as yet The thing that is clear, however, is that this is membership driven (as it should be too, IMO) so I'll pretty much step aside at this point and return to my seat as a casual (yet keenly interested) observer. we don't have the answers. we may not even know the questions. but we do have confidence in our ability to learn and evolve. that's one reason why the ASF chooses to grow policy and why policy changes over time. it's important that every consensus is challenged. once any consensus opinion of the membership is accepted as true just because it is received from that group, ossification and group speak sets in. evolution and growth stops. these are the real threats to apache. we need to people to ask 'why?' (so please don't stop) coming back to henri's comments: the ASF prefers self-organisation. reorganisations are much more likely to be approved if it's the committers involved who are pushing for them. if the communities are effected are strongly in favour then this has great weight. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Commons-modeler release request
On Wed, 2006-05-24 at 18:00 -0400, Henri Yandell wrote: On Wed, 24 May 2006, Bill Barker wrote: -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] snip Backwards incompatible shouldn't be a worry (imo), that's what major version numbers are for - but if you mean that Tomcat would need specific deep down customisations, that does sound like a problem. A realization that the component design just doesn't work anymore. Backwards incompatible was never really a big concern. The discussion on [EMAIL PROTECTED] was more focused on the fact that [modeler] doesn't have a community, so there wouldn't be enough people for 3 +1s to release it. So far, there aren't any special Tomcat-specific customizations in Tomcat's fork. There is work to reduce it's footprint, but that would just make it a 2.0 version. In terms of community - due to history you're all still Jakarta committers afaik and mostly on the PMC, so lots of +1s there. we had a bit of a crisis of confidence over commons releases late last year but i think that we're over that now. we're now using the correct voting scheme which is binding votes for all pmc'ers (no more component specific voting). Plus with the recent move to mostly jakarta-wide svn authentication, you also now have svn access. +1 if it's just a push towards a release that's needed, i'm willing to help out if there's anything useful i can do. So in terms of future direction, I don't think there's anything stopping Tomcat from being the driving part of the community for modeler. Struts definitely does that with some of the components that it is dependent on. The original idea of Commons as I understand it was as a place for Jakarta projects to come together. The diaspora out of Jakarta has lessened that and I think we should be expanding to thinking about it as a place for Apache projects to come together. It definitely helps that our committer based covers 25% of the ASF already :) +1 - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-fileupload: Streaming mode
On Tue, 2006-05-23 at 07:24 -0400, Yoav Shapira wrote: Hola, +1 to you getting commons-fileupload karma and doing it yourself ;) +1 i've kicked off the formal vote on commons-dev. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Tiles as the seed for Jakarta Web Components
On Tue, 2006-04-25 at 22:54 -0700, Martin Cooper wrote: 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'd prefer to move away from the term sub-project since it has negative formal associations. it can't be a project mini-me with formal structure of it's own. just a Jakarta component: separate product, same project, same formal organisational structure. AIUI (and it might be a good idea to check this out with PR) the naming guidelines mean that it should be Apache Tiles (not Jakarta Tiles or Jakarta Web Components Tiles). the reason for this is to ensure we can use trademark law to protect ourselves (if that's ever needed). IHMO Apache Tiles from the Jakarta Web Components team sounds pretty good anyway - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Tiles as the seed for Jakarta Web Components
On Wed, 2006-04-26 at 14:55 -0500, Greg Reddin wrote: Sorry to be a latecomer to this thread. I've had some trouble subscribing for whatever reason. But I just wanted to add that I am working on Standalone Tiles over at the Struts project and am willing to support it if it's moved to some Jakarta subproject. cool :) I'll let you guys hash out how the community is structured :-) I haven't participated in Jakarta enough lately to have an opinion. i'd hope we're not trying to structure the community, just the formal organisation supporting it. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Tiles as the seed for Jakarta Web Components
On Wed, 2006-04-26 at 11:48 -0400, Henri Yandell wrote: The Web Components thread is much older than the recent set of threads, it was back in 2005. So I don't think we've heard your reasons against a JWC Sub-Project as opposed to the not-community-of-community threads. i have worries about any more formal sub-projects: they are too much like project mini-me's with their own formal structure. IMO the legal and formal structures are best aligned. i do like the idea of a JWC grouping or community within jakarta. with all the trappings that the old sub-projects had (mailing lists, web site and so on) but no separate classes of committers under the same pmc. i think a manifesto would be needed for each grouping (somewhere between guidelines and a charter) which should define the scope. I can find this on wiki: http://wiki.apache.org/jakarta/CreatingCommonsForWebComponents which includes a charter - though I think the charter needs changing as that's a copy of the Commons charter which is 5% charter and 95% developer guidelines. IIRC the document on the wiki was intended to be the starting point for a charter. I know we voted on the name, I thought we voted on the creation of the subproject as part of that but would need to check archives. Will do that in a bit. i seem to recall a vote but not sure what it was on... On Wed, 26 Apr 2006, Andrew C. Oliver wrote: No. There isn't a consensus. andrew's right that since he dissents, there isn't an absolute consensus. i do suspect that he's views are in the minority, though. we should push things forward until we have something concrete to vote on. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
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. 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 Sun, 2006-04-09 at 10:20 -0400, Andrew C. Oliver wrote: snip Totally NOT how the incubator was described to me. As I understand it if Tomcat (for instance) wants to create a new JSP engine, that's kosher for Tomcat. However if someone in POI wanted to create a new AI engine (having nothing to do with MS file formats) then that is Incubator-toast. that is a matter of scope, not incubation policy a hypothetical example might help to illustrate the difference: JSP engines are in-scope for tomcat but out-of-scope for xerces. xerces is not allowed a JSP engine as part of that project. but if a new JSP engine wanted by tomcat was created outside the ASF, it would need to come in through the incubator. if it arrives without a external community (for example, because it was developed off-shore by tomcat developers) then it's a simply process of legal sign off. if it arrives with a community then it needs to enter as a podling to ensure that the community gets the help they need to understand how apache works. however, if the xerces developers (let's say for sake of argument) wanted to create a JCP engine at apache but outside tomcat they would need to create a new project. it is now seems more difficult for new projects to be created at apache (the test is subjective and democratic so this is an observation not a rule). it is much easier to create a new project offshore and then bring it in through the incubator. so, the scope issue would (for practical purposes) probably require them to go through the incubator. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encoding and format of RSS.XML
On Sat, 2006-04-01 at 22:50 +0100, sebb wrote: Should the RSS.XML file use encoding=WINDOWS-1252? Most (all) the other files use encoding=ISO-8859-1. Also, the layout is not all that easy to read - not all that important for end-users, but makes it a bit harder to review changes. Adding indent=yes should sort this. Any objections to changing these items? sounds good - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove SVN restrictions
On Mon, 2006-03-27 at 02:50 -0500, Henri Yandell wrote: [X] +1 [ ] -1 - robert signature.asc Description: This is a digitally signed message part
Re: [VOTE] Remove SVN restrictions
On Mon, 2006-03-27 at 20:01 +0100, sebb wrote: On 27/03/06, Henri Yandell [EMAIL PROTECTED] wrote: Vote to remove the SVN barriers within Jakarta such that all jakarta-* groups are merged into the one jakarta group with the exception of jakarta-hivemind, jakarta-slide, jakarta-cactus and jakarta-jmeter under the assumption that they are moving to having their own PMCs. Tapestry is already within its own auth group. [X] +1 Can Jakarta committers for projects moving to their own PMCs remain as Jakarta committers ? that's what's happened in the past - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Submitting patches
On Sun, 2006-03-26 at 12:41 +0100, sebb wrote: Generally I find that patches are much easier to process as Bugzilla attachments, rather than sent to the developer list as an attachment. And if the patch is large, it uses everyones mail resources, most of whom aren't interested. Just received such a patch on JMeter - the poster helpfully has a blog where he says that he followed the guidelines in: http://jakarta.apache.org/site/source.html#Patches which do indeed suggest sending patches to the developer mailing list. I'd like to suggest a change, so that the preferred method of submitting patches is via Bugzilla or JIRA. In the case of projects using JIRA, I believe that asks for a software grant, so it's important that code is submitted that way. [Actually, I'm not sure when emailed patches are appropriate...] I'd also like to split the patch section into two: Patch Creation Patch Submission Any objections to this? sounds good :) If not, I'll make a start on updating the text - and put a copy on my home page for review. no need to bother: if the feedback's positive then commit and we'll review the diffs. perhaps this information may be better at foundation level but any move can wait until you've patched... - robert - 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 Wed, 2006-03-22 at 22:04 -0500, Henri Yandell wrote: Now Martin's answer becomes very apt - something to sell across the ASF and there will be push back. ie) Good luck. However, I think it's not a bad idea. commons.apache.org as a Federation for the various Commons projects around the ASF - even if I am suggesting that J-C and J should start to merge into each other. Assuming I'm understanding what you mean by virtual front. i think that we need to start breaking the legal and formal organisation from the ontological. all the components in the various commons across apache are similar in many ways. users should really need to care which particular committee is charged with oversight. i think that DOAP can help. the germ's there but it's going to need a lot richer system of categorisation. the output generated by projects.apache.org needs some styling but that should be easy enough to do. how about introducing a suitable category and forwarding to that category? i like administration being decentralised: any suitable component in any apache project could join just by declaring the category in the DOAP. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
On Wed, 2006-03-22 at 15:51 -0300, Felipe Leme wrote: Hi Rahul (and others), First of all, sorry for the delay (but as they say here Better later than never :-) +1 Still, I think it worths to create a separate sub-project for the Standard Taglibs - even if it's DOA on activity, it's still a different project (because of the TCK, history, importance of JSTL, etc...) we're trying to move away from sub-projects so possible a standards grouping might make more sense. a home for EL as well ;) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation
On Sat, 2006-03-18 at 23:32 -0500, Henri Yandell wrote: I'm assuming at the moment that this is a case of somebody spoofing Karthik's address. I doubt the spam is from Karthik - just something that snuck through the spamassassin and various other email controls and happens to be a subscribed address. looks like we're going to need to think about turning on address checking sooner or later this year. probably need to think about ways to allow committers to post from their apache addresses... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
software grants drop location
when a software grant is received, it's important that the actual donated code is recorded in the repository: the actual code donated is identified by it's MD5 sum. it seems best to me to adopt a single drop point in jakarta for these grants. i propose http://svn.apache.org/repos/asf/jakarta/grants/. any objections/improvements? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: software grants drop location
On Sun, 2006-03-19 at 12:09 -0500, Henri Yandell wrote: On Sun, 19 Mar 2006, robert burrell donkin wrote: when a software grant is received, it's important that the actual donated code is recorded in the repository: the actual code donated is identified by it's MD5 sum. it seems best to me to adopt a single drop point in jakarta for these grants. i propose http://svn.apache.org/repos/asf/jakarta/grants/. any objections/improvements? Should it be an incubator location? ie) one place for all of Apache? leo think so and (on reflection) i agree. waiting for more feedback and i'll report back a little later... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Cleanup pmc members
On Fri, 2006-03-17 at 10:48 -0500, Henri Yandell wrote: On Fri, 17 Mar 2006, Noel J. Bergman wrote: 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. Why not just send out e-mail to the PMC members asking them if they want to remain active? Sounds good. Seems to fit with Sandy and Danny's preferences without being too complex - just a chunk of email to send out. Can deal with those who've not replied and email addresses that bounce if and when that happens. +1 Will do so if no one is against the idea in 10 days or so. We have done this with another PMC, and had one person repeatedly ask to stay listed as active. I don't think that I've seen a post from him other than that in some years now, but as long as he's happy reading and has nothing to say, I have no problem with keeping him. There is no quorum to be met for the PMC. There is on the Jakarta PMC (informally due to our charter), but it's something we should drop anyway. :) +1 is this a board thing or can we just vote to fix it now? i agree with noel we should aim for as few rules as possible :) in this spirit, i wonder whether we actually need to formally remove people from the committee (once the quorum issue is fixed). i agree that it's important to know which pmc'ers are still active to address oversight but this could be achieved without formally removing anyone from the pmc: just create a subsection on the website inside the pmc section for emeritus pmc'ers. in the case of those people who don't reply, move them to that subsection of the website but leave them on the legal committee. saves paperwork and means that there's no hassle reactivating. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
On Tue, 2006-03-07 at 19:13 +, Stephen Colebourne wrote: Reposted (edited) from original commons proposal. Currently this proposal has general, though not unanimous, support. A vote thread may follow this thread if the mood remains positive. i'm a little unsure whether this will turn out for better or worse but if people out there have energy, i'm willing to give it a go. time's probably right for a little innovation and experimentation. i like the idea of tagging emails better: a single list with cool server side filtering and metrics. we don't have the technology for this yet so i'm willing to see the mailing lists split so long as people would be willing to consider coming back if it every arrives... I hereby propose the creation of a new Jakarta entity named 'Jakarta Language Components'. This will be formed from the following codebases: [lang] [io] [collections] - expected to divide [primitives] [codec] [id] - on exit from sandbox [beanutils] - logging to be removed The following are invited to join if their communities desire: [oro] [regexp] [cli] Jakarta Language Components mission: 'Enhancing Java SE' Jakarta Language Components will: - develop multiple independent components yep - each component will have no dependencies - each component will have no configuration perhaps a description may be better than a proscription: charters are bad since they need votes and formalism. groupings should be less formal and more social than sub-projects. i think groupings will only work if the formal structures required (voting, karma, websites and so on) can be kept fixed and cross grouping so that groupings can be more fluid. - each component provides an extension to the JavaSE - code judged by would it be out of place in the JavaSE probably the wrong test: some of the stuff that's included is pretty controversial and grows in scope all the time. i'm not sure that this is really what a lot of the extra rubbish is wanted: eg logging, crypto, sql, corba, swing. isn't it only really the lang, util, io and beans packages that are really of interest? - a component typically has a broad API (many callable methods) - each method typically does relatively little processing KISS: not needed in a charter might be better to be descriptive: offer a separate positive description of an architypical component. this can be longer and can be amended more easily. grouping ethos document, perhaps? - have mailing lists (language-user/language-dev) is there any need for a another user list? given smaller mail volumes and the nature of the audience for these components (java developers), i think it would be better to retain a common user list but encourage posting by users to the dev list. the commons was more active when there was no user lists. i'd like to propose we try that again for this new grouping. if a user list proves necessary then it can easily be added later. - not have a sandbox does that mean: use the jakarta sandbox if every needed? - use [EMAIL PROTECTED] ML (new) for cross group issues general would feel better (to me) for discussing cross group issues but maybe dev might be needed for votes later... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components
On Mon, 2006-03-06 at 19:49 +0100, Ortwin Glück wrote: Sandy McArthur wrote: As a programmer looking for useful code to help me with uploaded files, I'm going to look in something named Jakarta *Web* Components first. When I see Jakarta HTTP Components I think of interacting with the HTTP protocol. I know FileUpload does both, but when I'm writing an webapp I think I'm working with a *web* app first and while I am working with HTTP it is a secondary concern. -- Sandy McArthur This may be true, but it shouldn't influence how the communities around the code are organised. This is more a matter of communication and branding. i think that's one of the advantages of flattening karma and voting: . we need to separate the formal legal structure (karma, voting) from the community (developers hanging out) from the ontological (communicating that the components are). from an ontological perspective, fileupload needs to be tagged as both http and web component with a sideways relationship to codec. from a community perspective, martin feels more at home with the httpclient team and it sounds like there are sound reasons to believe development might be more progressive. from a legal perspective, we're all jakarta: karma and voting need to be communal. in some ways, we need to find a way since the whole of apache is going to be facing these problems soon... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
On Tue, 2006-03-14 at 15:29 -0500, Henri Yandell wrote: Board report done - now I can irritate you all on these threads again :) On Tue, 14 Mar 2006, robert burrell donkin wrote: snip - each component provides an extension to the JavaSE - code judged by would it be out of place in the JavaSE probably the wrong test: some of the stuff that's included is pretty controversial and grows in scope all the time. i'm not sure that this is really what a lot of the extra rubbish is wanted: eg logging, crypto, sql, corba, swing. isn't it only really the lang, util, io and beans packages that are really of interest? +1. 'core of JavaSE' ? better :) nice'n'fuzzy - have mailing lists (language-user/language-dev) is there any need for a another user list? Also, why cause users pain while we experiment. How about we do the -dev list, and see how the -user list goes? given smaller mail volumes and the nature of the audience for these components (java developers), i think it would be better to retain a common user list but encourage posting by users to the dev list. the commons was more active when there was no user lists. i'd like to propose we try that again for this new grouping. if a user list proves necessary then it can easily be added later. Ah. I thought you were suggesting that they would continue to use commons-user. :) both at once, really :) any users who want to can use the commons-user list but not having a user list will encourage more people to subscribe to dev. which is a good thing. I'm +1 to commons-user. I'm only +1 to not havin a user list if we get the commits/wiki/jira out of the user's face. that'd be easy. might be better for oversight to have these posted to [EMAIL PROTECTED] anyway. - not have a sandbox does that mean: use the jakarta sandbox if every needed? Pretty sure it does. - use [EMAIL PROTECTED] ML (new) for cross group issues general would feel better (to me) for discussing cross group issues but maybe dev might be needed for votes later... Yep. Re-word as: - use Jakarta wide lists for cross group issues. We can modify what those are if we think that general@ is overwhelmed by Jakarta and we'd like it to be more pan-Apache Java or general-interest. +1 start here with the probably that we'll move later - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On Mon, 2006-03-06 at 16:53 +0100, Martin van den Bemt wrote: Just zap alexandria (we just zapped the mailinglist too). We can look at it as being promoted to TLP anyway (gump). ORO and Regexp ar kind of finished I thought, we should mark it stable or something like that. Don't know about ECS though. ECS is pretty much complete. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Other Jakarta Components
On Mon, 2006-03-13 at 19:18 -0500, Noel J. Bergman wrote: In terms of finding homes, I wonder if we should have a root directory under which we have inactive codebases. One problem would be that no PMC would be responsible. Or we could create a sort of reverse incubator: a curatorship, where no active development takes place, but where oversight exists. If a community wakes up around the codebase again, the curators can help put the codebase back into a community. curatorship is an interesting idea :) a good curator does what's necessary to preserve the codebase and so wouldn't preclude some development (the very occasional bug fix and the like). probably no reason why the code needs to be moved or websites changed. perhaps use a single mailing list with apmail magic to forward and prefix messages from the old lists. this would give confidence about oversight. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of OneCommunityProposals by StephenColebourne
On Sun, 2006-03-12 at 23:32 +0100, Andrew C. Oliver wrote: I'd like to note my opposition. I don't have the same vision as you do and do not wish to be distracted by 100 irrelavant emails a day about Commons ABCD. I'm glad Henri posted that reorganization things were being discussed. I would have preferred that he posted a more detailed message as I think others would likely be opposed to such forms of social engineering. Things evolve the way the evolve for a reason. That POI has relatively little to do with Commons-DB is not really a good reason to force us to listen to noise/interference. In radio, you tend to try and pick bands that aren't real close together so that you don't overlap and trample on each other's bandwidth. I had to do this with my wireless network because my neighbor's stuff kept interferring. No I don't think it would be great if we both shared channel 6 and I don't feel like vetting some non-technical irrelevant change by someone who wanted to get their API used by more projects (nevermind that it performs half as well as the JDK implementation and sucks down 100 other dependencies). And I bet [EMAIL PROTECTED] would be REALLY popular...so popular that ALL questions about POI would go to [EMAIL PROTECTED] with CC to every email address I've ever had and appologies for not posting on the list but half the time you can't unsubscribe and I really don't want 1 emails a day about stuff I'm not using. you've just an excellent argument for moving poi to top level :) like it or not, it's the jakarta pmc which has the binding votes. henri's proposal only formalises and organises the actual current state of affairs. if you don't trust my judgement enough to allow me a veto on poi commits then you need to talk to the other poi committers about graduating poi to top level status. If projects share obvious common technical ties then it makes sense, otherwise lets let darwin decide rather than radical social engineering. The PMC should ASK the individual projects if they would like to share a common list and set of committers rather than a top down decision proposed on a list that most committers don't subscribe to (which might indicate...duh...that they don't want to be on a list mostly not about their project). This proposal and any that resemble it are non-starters for me. A lot of this sounds like Commons trying to remake Jakarta in its image. As an alternative why can't commons be top level? The namespace is now free (http://commons.apache.org/). hmmm... commons, taglibs, http components and whatnot going to commons.apache.org that'd only leaves POI in jakarta: does that really make more sense than apache poi? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of OneCommunityProposals by StephenColebourne
On Mon, 2006-03-13 at 23:48 +0100, Andrew C. Oliver wrote: that'd only leaves POI in jakarta did you have a point there? :-) thanks for highlighting my bad grammar (it's past my bed time) the point was the bit you snipped :) preserving jakarta as a special umbrella for poi seems more than a little odd to me. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OT: Gmail Labels enhancement: show recent message count in a label
On Wed, 2006-03-08 at 00:09 -0500, Sandy McArthur wrote: spam I wrote a GreaseMonkey user script to help me manage the mail on the Jakarata mailing lists and thought I'd share because I noticed a good number of people here email from Gmail. If this is completely inappropriate to post here let me know and I won't do it again. this is just what this list used to be for in the good-old bad-old days. we need more off topics posts :) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Other Jakarta Components
On Tue, 2006-03-07 at 22:20 +0100, Thomas Dudziak wrote: As a side note, perhaps this is an opportunity to evaluate if there are better homes for some of the components ? E.g. betwixt/digester/jxpath could benefit from going to XML commons, xml tends to be about nuts and bolts. not really suitable. webservices is a possibility. jxpath is a bean utility and has quite a lot in commons with beanutils. betwixt is a data mapping tool and IMHO has a lot more in common with the db community than with xml. a move to db would probably be healthy for betwixt. dbcp and dbutils from going to DB etc. ? this is a community issue: dbcp is very closely related to pool. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Other Jakarta Components
On Tue, 2006-03-07 at 23:07 +0100, 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 might be a bit much, but Digester and Betwixt IMO would fit nicely. definitely not xml. webservices would be a possibility. not particularly keen, though. IMHO moving would mean no more releases (too few full time developers to gain a quorum outside jakarta). realistically it means shutting down these components so it would be throwing code over the wall. would be kinder to shoot them. in terms of community, db would be a better home for betwixt: it's has much more in commons with bean-based OR mappers than with schema catalogs. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subproject Charters
On Sun, 2006-03-05 at 17:31 -0500, Henri Yandell wrote: On Sun, 5 Mar 2006, Martin Cooper wrote: 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: snip 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. Other way, frameworks -1 to being within Jakarta. Depends on definition of framework - VFS is a framework to me; an interface structure designed for multiple implementations. I'd stay +1 for small things like VFS. IMO VFS is a bridging library, not a framework. bridging libraries have a simple, user facing API is intended to be used as a standard library. they also have a SPI (typically a mini-framework) to allow the library to be extended by adding new implementations. normal users should never use this: they just use it as a normal library. there are actually a number of bridging APIs in the commons and some more are in the sandbox (for example, proxy). they are small and useful for library creators since they allow projects to support multiple backend configurations. bridging APIs have a number of similarities and would probably make sense as a grouping. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Commons SubProject Proposal
On Fri, 2006-02-17 at 14:57 +0530, Karthik Kumar wrote: On 2/17/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Wed, 2006-02-15 at 16:52 -0800, Martin Cooper wrote: 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: Hmm.. okay. it isn't a large framework. but, okay. jakarta commons does bricks not frameworks (however, it is possible that you are actually describing something which is an adaptive bridge brick and not technically a framework) http://db.apache.org/ +1 but don't let that discourage you :) jakarta isn't really accepting sub-projects any more: we're very slowly moving away from that model towards something flatter. - robert I was specifically referring to the Commons. Well, okay! :) it was the language that fooled me :) sub-projects are jakarta mini-me's with separate communities, mailing lists and so on. apache has found that sub-projects don't scale. components are the bricks the community happens to be working on. but martin's right that we try to push data access related proposals towards the db project. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT] ApacheCon EU 2006
The ApacheCon Planners have announced that ApacheCon Europe 2006 will be held in Dublin, Ireland, at the Burlington Hotel (http://www.jurysdoyle.com/ireland/doyle_burlington.htm), June 26-30. Further details to follow as they are available. Robert signature.asc Description: This is a digitally signed message part
Re: [RESULT] Tapestry TLP
On Tue, 2006-02-07 at 09:43 -0800, Howard Lewis Ship wrote: Below is the result of the recent Tapestry committers vote to move Tapestry to an Apache top level project. Pending the approval of the Jakarta PMC, we'll be submitting the request to the Apache board. is another VOTE needed for approval or can we just go with the VOTE held on the tapestry thread? - robert signature.asc Description: This is a digitally signed message part
Re: Users on Tomcat
for a more quantitative answer, please ask on the tomcat user list. please read http://tomcat.apache.org/lists.html. - robert On Thu, 2006-02-02 at 10:56 -0500, Travis Quarterman wrote: Carl, Don't know the exact answer, but Apache is scaled better than Tomcat's Http server. This can be proven during a load test. On 2/2/06, Carl Crawford [EMAIL PROTECTED] wrote: How many users can tomcat support at one time. We are using tomcat's build in http server not apache. Thanks, Carl - 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 subproject-package system
On Wed, 2005-12-28 at 09:55 -0100, jan meskens wrote: Hello Henri, I was looking to these page : http://jakarta.apache.org/commons/charter.html Maybe that's the wrong page for these info... . not wrong probably just a little confusing the jakarta commons charter encapsulates the opinions of the jakarta pmc at that particular moment in time. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Notice of intent.... #2
On Tue, 2006-01-10 at 10:20 -0800, Martin Cooper wrote: 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. +1 gave up groups (topological or even finite simple) when i left uni ;) 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. not sure i like the idea of fuzzy groupings with 1-N components need to be mapped 1-1 to dev mailing lists but 1-N would work fine on user lists. might be possible to factor 1-1 dev lists (for traffic purposes) whilst retaining fuzzy users 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. i don't like the idea of magic notifications (to the board) but something needs to be done: ATM we're dysfunctional. just take a look at the nominations per nominator over the last year or two: nomination hasn't become ingrained in the culture. ATM we're slipping up but maybe statistics and reminders may be better for the moment than automatic nomination... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: feed parser enclosure support
this list is for general matters effecting the whole of jakarta. please read http://jakarta.apache.org/site/mail.html and subscribe to either commons-user or commons-dev. please read http://jakarta.apache.org/site/mail.html and remember to add [feedparser] as a prefix to the subject. - robert On Tue, 2005-11-01 at 10:34 -0800, m h wrote: Hello Trying to use feedparser for some rss parsing tasks -- need enclosure support. The LinkFeedParserListener mentions that it is there, but there are no onEnclosure methods -- I cant find any such methods in any of the classes. Whats wierd is when I go to http://jakarta.apache.org/commons/sandbox/feedparser/xref/org/apache/commons/feedparser/RSSFeedParser.html I do see some support for enclosures, however in the RSSFeedParser class available in cvs, those sections are absent. Can anyone help on this issue? Thank you in advance. __ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: no jsp2 path possible NO SUFFICIENT DOCUMENTING
the usual comment when this arises is: please post to the correct list (which is tomcat-user please read http://tomcat.apache.org/lists.html). however, i'd would strongly suggest that you research your problem and try to prepare a better question before posting. tomcat is a specification-compliant servlet container and i suspect that your question is really related to the servlet specification in general (rather than tomcat specifically). it does not contain general information about creating J2EE application since better sources exist elsewhere. there are very many books and articles (in many languages) which cover tag libraries. please take a while to google and then read them. IMHO this will prove a lot more productive than asking on the list. - robert On Tue, 2005-10-25 at 01:00 +1000, NICEPHOTOG wrote: [Tomcat docs not sufficient about .tld and tag handler classes] FINALLY THIS MESSAGE IS TO LET YOU KNOW THERE IS NO SUFFICIENT DOCUMENTING FOR WEB APP CUSTOM TAG CLASSES RELATING EITHER JAR OR DIRECTORY FOR JASPER-TOMCAT5.0 ANYWHERE ON THE WEB OR THE PLANET BUT TRUTHFULLY FOR ANY LEVEL OF JSP AND ENGINE. [its all well to say org.apache... says its a path in a jar but its not part of my or anyone elses application and i have looked through suns jsp2.0 specs, then thats j2ee and that would probably operate FOR J2EE.] I cannot find either a path or jar file path system to operate the tag handlers through .tld for tomcat 5.0 Im new to tomcat but i have never found and for the point ANY documentation that explicitly tells the path to a tag handler class in the .tld relative or in context to the web application custom web-app base. web.xml servlet matching, most do not find required for custom tag handler classes but i have got it down to the .tag will load but the classes do not and are not explicitly either not loading or not found after being sure the path is either /WEB-INF/tags or /META-INF/tags with the .tld /WEB-INF/wap.tld in the .war The servlet operated ok but the jsp custom tagging cannot be located as either jar or class. jsp-config jsp-property-group tag-class name tag(not tag-file) thanks anyway though - 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: Subscribing a new Project into Jakarta
On Tue, 2005-10-11 at 14:36 -0300, [EMAIL PROTECTED] wrote: Hello, my name is João, i'm a Brazillian Java developer. hi João In this email i will describe the general proposal for my project, the JFTP4I (Java FTP for Integration). My intentions are basically to put my project inside the Jakarta/Apache umbrella. the way these things are done now is through the incubator http://incubator.apache.org/. please take some time to read the documentation on the site. i don't want to dampen your enthusiasm but i'd like to offer a realistic assessment of some of the obstacles you may find upon your way... jakarta's been self consciously shrinking over the last few years (it's just too big and too complex) with a lot of old sub-projects graduating to lop level status. it's more difficult now to persuade people that new sub-projects should be accepted. (of course, this doesn't mean that JFTP4I couldn't aim for top level or for a sub-project of another project) there's quite a deal of ceremony associated with incubation now: it requires time, dedication and effort to succeed (up and beyond creating a successful open source project). the aim of incubation is to try to help the new project to learn apache ways and adopt systems which we believe lead to healthy long term projects but the process is still evolution and there are some rough edges left still... For that i give you a detailed description of my project. Project Description: The JFTP4I is a new idea for the concept of using FTP for integration purposes. Here in Brasil (and i think very much in the rest of the world), all the legacy systems are basically using FTP as a way of integrating different platforms running under TCP/IP. i wouldn't have thought associated dynamic applications with ftp but now you pointed it out, it can see why a project like this makes sense :) snip The project has already started (exists), and is hosted in the sourceforge.net. I have 3 friends helping me develop the solution. The FTP engine, trace, and Log are already done, and we are now working in the transaction and delegation parts for the requests. You can found a alpha version to be download in the following link: http://sourceforge.net/projects/jftp4i Obs.: I don´t now if you guys can actually download the code, but if this is important, and you could not download the source, please contact me and i will be glad to send to you. PS.: This is not another FTP Server, this is actually a framework that uses a FTP engine to dinamically generate content. BTW http://producingoss.com/ is a good read for people starting open source projects... all the best and good luck with jftp4i - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Request for Comment] Http Components proposal
On Sun, 2005-09-25 at 12:27 +0200, Oleg Kalnichevski wrote: On Sat, 2005-09-24 at 20:34 -0700, Martin Cooper wrote: On 9/24/05, Henri Yandell [EMAIL PROTECTED] wrote: ... * 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. Hi Martin, This statement is not accidental. The plan is to factor the multipart content handling out of HttpClient. There's already a project in Commons Sandbox led by Mark R. Diggory http://svn.apache.org/repos/asf/jakarta/commons/dormant/codec-multipart/ for that end. Unfortunately the project has been dormant for quite some time but the plan is to revive the project at some point, get it graduate from Sandbox and possibly get it merged with Commons Codec proper at some point of time. IMHO a clause need to be inserted to allow the sub-project maintain the existing codebase (since it will be out-of-scope otherwise). actually, i'd prefer to see the pmc give the explicit responsibility for maintenance to the sub-project. * 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. Actually we see more and more often HttpClient code used to implement server side of the protocol as well. This statement is primarily to ensure that the project will not sidetrack into developing and _application_ API competing with javax.servlet API. We merely want to provide low level generic transport primitives. IMHO if this is the vision then it would be better to rephrase the final clause to make this clear. maybe something like: * Jakarta Http Components will provide ONLY a toolset of low level generic transport APIs. In particular, server side application layer APIs WILL NOT be developed. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: GMANE
On Thu, 2005-09-01 at 15:13 -0400, 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. 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. if you think so then create a patch and contribute it though bugzilla :) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: List moderation
On Thu, 2005-08-11 at 22:13 +0200, Torsten Curdt wrote: we're moving towards insisting on pgp keys so we could check and moderate through all signed apache.org email without danger. You mean forcing all subscribers to use gpg Although I love the idea of forcing people to sign their mails http://vafer.org/blog/tcurdt/archives/93.html http://vafer.org/blog/tcurdt/archives/000174.html I fear there is no way we can get away with that. not for all posts, just for those unsubscribed. given that there's a rising tide of demand to make all lists subscriber only, i think that this would be better than simply sending all unsubscribed posts to /dev/null. This would leave open for moderation only a few broad lists (for instance [EMAIL PROTECTED], which I have the pleasure to moderate :-( ), killing a lot of wasted hours. Also, FYI, joes2 is doing some info gathering on moderation request to aid us in filtering incoming moderation spam. See irc://irc.freenode.net/#asfinfra for more info. Language is english for all lists. Filtering out mails with all kinds of weird characters would be a first step. Still wondering why we don't have that already. +1 i've been wondering for a while whether it'd be better to move towards bots and some sort of web app for smarter collaborative moderation. (one moderators marks a message as spam and all identical ones are automatically rejected from all pending lists.) That would be much better ...but it's also quite an effort to set this up. I just don't know whether it's worth it for those few cross postings i have personal itches about some of the required technologies and i know some of the spam assassin guys are keen on some of the others. maybe i'll try to ambush some people on irc... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: List moderation
On Wed, 2005-08-10 at 17:25 +0200, Santiago Gala wrote: El mié, 10-08-2005 a las 11:27 +0200, Torsten Curdt escribió: Hi, I've been a moderator for the bcel-dev@jakarta.apache.org and bcel-user@jakarta.apache.org for a few months now. In that time there have been 2 valid emails from people who weren't subscribed, and a few thousand spam mails. I'm rather tired of being a human spam filter for the mailing list. As the ratio of bad to good emails is so high, I suggest that all mails from unsubscribed users simply be discarded making moderation unnecessary. What's the general opinion about this? The question is why do we use moderation at all? I can see only the reason of cross-posting which is discouraged anyway ...and still could be done by people who are subscribed to both lists. ...so I am with you on this with some scripting magics, we could add to the allow list of all maining lists all apache.org addresses and aliases set up in some files (iclas.txt and other ones), which would also kill the main use case for moderation. Even allowing all email addresses subscribed to any apache.org list to post to the rest of the public onesm though this would be less safe. we're moving towards insisting on pgp keys so we could check and moderate through all signed apache.org email without danger. This would leave open for moderation only a few broad lists (for instance [EMAIL PROTECTED], which I have the pleasure to moderate :-( ), killing a lot of wasted hours. Also, FYI, joes2 is doing some info gathering on moderation request to aid us in filtering incoming moderation spam. See irc://irc.freenode.net/#asfinfra for more info. i've been wondering for a while whether it'd be better to move towards bots and some sort of web app for smarter collaborative moderation. (one moderators marks a message as spam and all identical ones are automatically rejected from all pending lists.) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Components/Common project
On Mon, 2005-08-08 at 13:14 -0400, Frank W. Zammetti wrote: On Mon, August 8, 2005 12:42 pm, robert burrell donkin said: On Mon, 2005-08-08 at 01:54 -0300, Felipe Leme wrote: snip Anyway, the Jakarta Taglib Project has voted how it would like to take part on this new project, and the result was: 1.The Jakarta Taglibs Project would like to be merged into the project 2.The Jakarta Standard Taglib should then be a project of its own 3.The remaining taglibs would be gradually migrated to the new project, the most actives first 4.It's not decided yet if the migrated taglibs would have a newer release prior to the migration I'm not sure there was ever a consensus on what the overall structure of the project would be either (someone can correct me if I'm wrong on that point)... It seems like there might be a risk of sub-projects within sub-projects within sub-projects, which I'm not sure would be the best organizational stucture... if you had Jakarta Taglibs as a sub-component of the JWP4J project (assume for the sake of argument that name sticks), and then have Jakarta Standard Taglib as a sub-project of Jakarta Taglibs, is that the best structure to have? How deep of a hierarchy is OK and how deep is too deep? any deep is too deep :) AIUI everything will be flat: collective management and only social divisions. standard taglibs will become a jakarta sub-project. BTW is there any real reason not to start the promotion process for standard taglibs ASAP? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT] Jakarta-Commons Betwixt 0.7 Released
The Jakarta Commons Team is pleased to announce the latest release of common-betwixt from Apache. Betwixt is a flexible, dynamic, start-from-beans xml-object binder. For more information on Betwixt, please see http://jakarta.apache.org/commons/betwixt/. Betwixt 0.7 is a feature release adding numerous new features. It is binary compatible with the last release (0.6) but there are a small number of semantic changes. It is believed that these should have minimal impact on existing users but these users are advised to read the release notes. Binary and source distributions can be download from http://jakarta.apache.org/site/downloads/downloads_commons-betwixt.cgi. Since the distributions are download from mirrors, please check the md5 sum and verify the detach signature using the files linked from the download page (hosted on an ASF server). Robert signature.asc Description: This is a digitally signed message part
Re: Copyright line in code submissions
On Tue, 2005-07-26 at 08:57 +0100, Danny Angus wrote: Robert wrote: i sometimes find it hard to work out where opinion stops and policy begins... Then again... it is surely the PMC's business to know or find out, and enforce? I mean, IANAL but as a manager I would think that if the PMC is charged with oversight it is surely marginally better for the PMC as a body to mis-interpret and mis-enforce centrally than for there to be n different personal mis-interpretations of legal requirements of all kinds. I would have thought that a jakarta web-page of legal FAQ would at least allow us to have an auditable standard, and if the standard is wrong it should then be wrong for all to see, wrong everywhere to the same degree and require one fix, rather than a big analysis effort up front. i think i'm (almost) persuaded by this. it's been too fuzzy for too long and we need to start tightening things up. we have been trying to move any more general material from jakarta to the foundation site. so, this would be better at the foundation level. probably better quality of oversight there, as well. i follow the licensing list. IIRC there was a plan to create a legal FAQ for committers. i might volunteer to set something in motion... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r225366 - in /jakarta/site: docs/site/downloads/downloads_tomcat-connectors.html xdocs/downloads/downloads.xml
hi Jean-Frederic docs/site/downloads/download_tomcat.html is generated and so these changes are in grave danger of being reverted next time someone regenerates the site. - robert On Tue, 2005-07-26 at 18:08 +, [EMAIL PROTECTED] wrote: Author: jfclere Date: Tue Jul 26 11:08:22 2005 New Revision: 225366 URL: http://svn.apache.org/viewcvs?rev=225366view=rev Log: Arrange dowload page for mod_jk. Modified: jakarta/site/docs/site/downloads/downloads_tomcat-connectors.html jakarta/site/xdocs/downloads/downloads.xml Modified: jakarta/site/docs/site/downloads/downloads_tomcat-connectors.html URL: http://svn.apache.org/viewcvs/jakarta/site/docs/site/downloads/downloads_tomcat-connectors.html?rev=225366r1=225365r2=225366view=diff == --- jakarta/site/docs/site/downloads/downloads_tomcat-connectors.html (original) +++ jakarta/site/docs/site/downloads/downloads_tomcat-connectors.html Tue Jul 26 11:08:22 2005 @@ -2,7 +2,7 @@ html head meta http-equiv=Content-Type content=text/html; charset=iso-8859-1/ -titleThe Jakarta Site - Tomcat Connectors (mod_jk, mod_jk2, mod_webapp) Downloads/title +titleThe Jakarta Site - Tomcat Connectors (mod_jk, mod_jk2) Downloads/title link rel=stylesheet href=/style/style.css type=text/css/ /head body @@ -161,8 +161,8 @@ td class=main-body valign=top align=left div class=section div class=section-header -a name=Tomcat Connectors (mod_jk, mod_jk2, mod_webapp) Downloads -strongTomcat Connectors (mod_jk, mod_jk2, mod_webapp) Downloads/strong +a name=Tomcat Connectors (mod_jk, mod_jk2) Downloads +strongTomcat Connectors (mod_jk, mod_jk2) Downloads/strong /a /div p @@ -197,7 +197,7 @@ p The codeKEYS/code link links to the code signing keys used to sign the product. The codePGP/code link downloads the OpenPGP compatible signature from our main site. /p -pFor more information concerning Tomcat Connectors (mod_jk, mod_jk2, mod_webapp), see the a href=http://jakarta.apache.org/tomcat/connectors-doc/; class=nameTomcat Connectors (mod_jk, mod_jk2, mod_webapp)/a site. /p +pFor more information concerning Tomcat Connectors (mod_jk, mod_jk2), see the a href=http://jakarta.apache.org/tomcat/connectors-doc/; class=nameTomcat Connectors (mod_jk, mod_jk2)/a site. /p div class=links span class=link a href=http://www.apache.org/dist/jakarta/tomcat-connectors/KEYS;KEYS/a @@ -215,18 +215,18 @@ /div ul li class=download -a href=[preferred]/jakarta/tomcat-connectors/jk/source/jakarta-tomcat-connectors-current-src.tar.gzJK 1.2.10 Source Release tar.gz/a +a href=[preferred]/jakarta/tomcat-connectors/jk/source/jk-1.2.14/jakarta-tomcat-connectors-1.2.14.1-src.tar.gzJK 1.2.14 Source Release tar.gz/a ul class=attributes li -span class=pgp[a href=http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jakarta-tomcat-connectors-current-src.tar.gz.asc;pgp/a]/span +span class=pgp[a href=http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jk-1.2.14/jakarta-tomcat-connectors-1.2.14.1-src.tar.gz.asc;pgp/a]/span /li /ul /li li class=download -a href=[preferred]/jakarta/tomcat-connectors/jk/source/jakarta-tomcat-connectors-current-src.zipJK 1.2.10 Source Release zip/a +a href=[preferred]/jakarta/tomcat-connectors/jk/source/jk-1.2.14/jakarta-tomcat-connectors-1.2.14.1-src.zipJK 1.2.14 Source Release zip/a ul class=attributes li -span class=pgp[a href=http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jakarta-tomcat-connectors-current-src.zip.asc;pgp/a]/span +span class=pgp[a href=http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jk-1.2.14/jakarta-tomcat-connectors-1.2.14.1-src.zip.asc;pgp/a]/span /li /ul /li Modified: jakarta/site/xdocs/downloads/downloads.xml URL: http://svn.apache.org/viewcvs/jakarta/site/xdocs/downloads/downloads.xml?rev=225366r1=225365r2=225366view=diff == --- jakarta/site/xdocs/downloads/downloads.xml (original) +++ jakarta/site/xdocs/downloads/downloads.xml Tue Jul 26 11:08:22 2005 @@ -1047,13 +1047,13 @@ /downloads /project -project id=tomcat-connectors name=Tomcat Connectors (mod_jk, mod_jk2, mod_webapp) href=http://jakarta.apache.org/tomcat/connectors-doc/; +project id=tomcat-connectors name=Tomcat Connectors (mod_jk, mod_jk2) href=http://jakarta.apache.org/tomcat/connectors-doc/; downloads keys=jakarta/tomcat-connectors/KEYS primary=http://www.apache.org/dist/; mirrored=true archive=http://archive.apache.org/dist/jakarta/tomcat-connectors/; md5-text=false group label=JK 1.2 download name=JK 1.2 Binary Releases href=jakarta/tomcat-connectors/jk/binaries/ directory=true/ group label=Source - download name=JK 1.2.10 Source
Re: svn commit: r225366 - in /jakarta/site: docs/site/downloads/downloads_tomcat-connectors.html xdocs/downloads/downloads.xml
On Tue, 2005-07-26 at 16:52 -0400, Rahul Akolkar wrote: On 7/26/05, robert burrell donkin [EMAIL PROTECTED] wrote: hi Jean-Frederic docs/site/downloads/download_tomcat.html is generated and so these changes are in grave danger of being reverted next time someone regenerates the site. snip/ I also see a pending mod for Stefan's update of whoweare.html. i posted something to stefan off list (wanted to email him anyway). I just regenerated the site, but I avoided reverting those two. I could easily have committed those; I just didn't know what the etiquette is. for me, it's a judgement call depending on the person and the change. hopefully, other people will jump in here with more general opinions... - robert signature.asc Description: This is a digitally signed message part
Re: Copyright line in code submissions
On Mon, 2005-07-25 at 17:22 +1200, Simon Kitching wrote: snip Basically, I think it's legal for code submitted to apache to have the copyright of the original author but there are good reasons to avoid this if possible. Certainly the norm for commons projects is to have only one copyright statement, being that of the ASF. +1 I'd be interested to know if there is a general Apache policy on this. i sometimes find it hard to work out where opinion stops and policy begins... cliff schmidt seems like a good person (http://www.apache.org/foundation/) to ask and is pretty approachable. IANAL and all that. +1 legal discuss is the list for committers where those who are lawyers hang out... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT][POLL] drop point 12
+1 - robert On Mon, 2005-07-04 at 02:16 -0400, Henri Yandell wrote: We should do the same on Commons at some point. Throw out the ones that seem dead. Hen On Sun, 3 Jul 2005, robert burrell donkin wrote: i count 4 +1's the consensus seems to be in favour of removal so that's what i'm going to do. i propose to leave retain the number by noting those that have been deleted (rather than removing them). - 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]
[RESULT] [POLL] drop 8
i count 5 +1's and no objections so i'm going to go ahead and delete it. - robert On Sun, 2005-07-03 at 19:44 +0100, 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]
Re: [site] Added svn resource to library.xml
committed. many thanks. - robert On Tue, 2005-07-05 at 20:19 +0200, Fredrik Westermarck wrote: Henri Yandell wrote: Is there a BZ or Jira where one can open issues and add patches to the jakarta-site module? Or is all such requests handled on this ml? This mailing list is the best place. Hi! Here's the patch that I promised. Regards, Fredrik Westermarck Plain text document attachment (library.diff) Index: xdocs/site/library.xml === --- xdocs/site/library.xml(revision 208774) +++ xdocs/site/library.xml(arbetskopia) @@ -73,6 +73,12 @@ /p p +ba href=http://svnbook.red-bean.com/;Version Control with Subversion/a/bbr/ +Written by Ben Collins-Sussman, Brian W. Fitzpatrick amp; C. Michael Pilato. +This is a Subversion manual that currently provides information about Subversion 1.0 and 1.1. +/p + +p h3Source Code Philosophy Resources /h3 The following are a set of articles written about the recent source code movements that help illustrate some of the attributes of a collaborative project such as this. You may not agree with all of - 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
there doesn't see any enthusiasm for those new ideas and no objections to phil's draft. i think we should go ahead and make the changes suggested by phil. - robert On Sun, 2005-07-03 at 22:39 +0100, robert burrell donkin wrote: On Sun, 2005-07-03 at 13:13 -0700, Phil Steitz wrote: Here is a stab at replacement text for 15, 17 and 18. great :) looks good but threw up some ideas... 15-1 Any member of the community may propose a new package. To be accepted, a package proposal must receive majority approval of the subproject committers and at least one committer must volunteer to serve as an initial package team member. Proposals should identify the rationale for the package, its scope, its interaction with other packages and products, the insert-subproject-name resources, if any, to be created, the initial source from which the package is to be created, and the sponsoring committers. 15-2 The subproject will maintain an svn repository, referred to as the isandbox/i, as a workplace for new packages. Once approved, new packages must all begin in the sandbox. Any apache committer may contribute code directly to the sandbox and this code may form the initial source for new packages. Code from existing apache projects can, with the support of the contributing projects, also be imported directly into the sandbox. Finally, patches contributed incrementally by community members may be committed to the sandox by a subproject committer. If the initial source for a new package is from outside of apache, the new package must be brought into apache via the apache incubator. not sure but wonder whether we might need to tightening this last sentence so that it can't be read as implying that having only a portion of the initial source from external sources is ok. opinions? 15-3 A majority vote among subproject commiters is required to graduate a package from the sandbox to become a proper package. Only proper packages may make releases. If a package remains in the sandbox for more than six months, a majority vote will be required to prevent its being archived from svn and removed from the subproject web site and any other public locations (e.g. nightly or continuous integration builds). Proper packages may not release code with dependencies on sandbox packages. 1. i wonder whether it'd be better to have bi-annual reviews to simplify administration. in january, review all sandbox components which were created before the previous july. could run them as a single vote. 2. i wonder whether we actually need to remove them from svn: just could copy them into an archive directory. - 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] Marking changes
On Tue, 2005-07-05 at 15:23 -0400, Rahul Akolkar wrote:
(Was: Re: [Jakarta Wiki] Update of
DraftCharterForWebComponentCommons by RobertBurrellDonkin) - pasted
here since the title was getting too long ;-)
Thanks for making the changes Robert!
I propose we wrap changes in {{{DELETED}}} and {{{/DELETED}}} tags
(or ADDED tags, as appropriate) rather than purely relying on font
minutae. Amongst other things, that will work better for
accessibility. I'm +1.
if it'll make things easier to read and you're willing to do the
formatting changes, i'm +1
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dormant guidelines proposal?
On Fri, 2005-07-01 at 01:55 -0500, Curt Arnold wrote: There has been some discussion about modifying the Logging Services project bylaws (http://logging.apache.org/site/bylaws.html) to address some concerns particular to the project. I was researching the Jakarta guidelines and stumbled across http://jakarta.apache.org/ site/proposal.html. It is referenced at the bottom of http:// jakarta.apache.org/site/guidelines.html as a working proposal, but it does not appear from the SVN log to have any activity for over two years. i thought that it'd been removed during spring cleaning earlier this way. anyone remember any reasons why it was retained? Was there a resolution on the proposal? If so or if has been abandoned, then it might be good to pull it and the link from the site or at least update the status. Has the activity moved elsewhere or is it just sleeping? it's a bit of a long story. the only real records exist on the (private) archives of the jakarta pmc mailing list. IIRC this represents the earliest stage of the long road towards reform. the consensus was that the problem wasn't the guidelines but the basic bylaws. once these were fixed, arguing about the guidelines became moot... If either was going to be considered as a starting point for a rework of the LS bylaws, would you recommend the proposal or the accepted guidelines? i'm not sure whether it'd be a good idea to start from either. i'd start from the bylaws and from henri's wiki pages. it seems to me that the guidelines have really turned into a directory page for general information. a lot of the information linked to probably belongs at the foundation level (though would need editing). I haven't had a chance to attempt to compare and contrast the current and proposed guidelines, but the proposal's one page format left a better impression since you can see everything at one glance. the proposals are a good document in a cool format but didn't solve the real problems One of significant differences between our current bylaws and either of the proposal or existing guidelines is that the PMC is tasked with electing new committers. There is a desire to move that decision towards the sub-project, i recommend asking this question again on community. the model used by jakarta is believed (by many seniors figures from other projects) to be both unusual (within apache) and far from best practise. some feel that too much delegation to sub-projects may be to the detriment of the community spirit at project level. others that it creates problems with oversight. IMHO the model works ok for us here but i'd hesitate to recommend it to other projects. but I'm concerned that without any role for the PMC and no private medium for the vote, that there isn't a clean way for the PMC to address a potential disruptive or legally entangling committer candidate except to accept the sub-project vote and for the PMC to attempt to revoke his committer rights requiring a full consensus. AIUI no project is actually entitled to abdicate responsibility for oversight. IMHO the right way to proceed (if this happened here at jakarta) would be to -1 the result posted to the pmc list and so veto the action (lazy consensus). this should force a vote on the pmc list. one of the problems with holding votes for committers on public lists is that there is no way that the individual in question could be kept from the knowledge of their rejection. There would also be no private forum to discuss any sensitive issues since only the PMC has a private list. this is a problem that we have here at jakarta. current practise is that there is usually a certain amount of private chat (but it would be better if this happened on a private list). For the LS bylaws, I was considering suggesting a two-phase vote, lazy consensus at the sub-project and then lazy approval followed by lazy consensus at the PMC. Considering the damage a rogue committer could do, having the PMC with some means of intervening without invoking the nuclear option would seem to be warranted. the pmc is charged with oversight. whatever system is agreed must provide that. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][POLL] drop point 12
i count 4 +1's the consensus seems to be in favour of removal so that's what i'm going to do. i propose to leave retain the number by noting those that have been deleted (rather than removing them). - robert - 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 Sat, 2005-07-02 at 14:33 -0400, Martin Cooper wrote: 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. i think we've established a consensus on this. any objections to amending the draft appropriately? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[POLL] drop 8
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]
Re: new components
On Sat, 2005-07-02 at 14:52 -0400, Martin Cooper wrote: On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote: On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: snip 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. ;-) yep. vaporware can take care of itself :) 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. then at some time later, a promotion vote is held. 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.) +1 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. +1 maybe the whole sandbox issue should have it's own subsection detailing how the sandbox is to work and how promotion should work. 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. sorry: meant 17 - robert - 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 Sat, 2005-07-02 at 12:27 -0700, Phil Steitz wrote: Martin Cooper wrote: On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote: On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: snip 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. Agreed. After a little more discussion, we should rewrite this. +1 anyone feel like jumping volunteering to come up with a draft? FWIW, I did NOT mean to suggest that only committers could *suggest* projects, only that to actually get one *started*, support from ideally more than one committer is required. I think the following is also possible, since at least one j-c component started this way: 4) A new component is proposed by a (some) non-committer(s). One or more existing committers are interested in working on the component. The initial code base is built up incrementally in the sandbox from patches contributed by community members. This is more or less the way we started commons-math. The initial code base was contributed incrementally, with patches discussed, reviewed and in some cases refactored before being committed. I don't see anything wrong with this, nor requiring a trip through the incubator. +1 but i think that this can be covered as a subcase of the sandbox route. the key factor is that the code is original. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new components
On Sun, 2005-07-03 at 13:13 -0700, Phil Steitz wrote: Here is a stab at replacement text for 15, 17 and 18. great :) looks good but threw up some ideas... 15-1 Any member of the community may propose a new package. To be accepted, a package proposal must receive majority approval of the subproject committers and at least one committer must volunteer to serve as an initial package team member. Proposals should identify the rationale for the package, its scope, its interaction with other packages and products, the insert-subproject-name resources, if any, to be created, the initial source from which the package is to be created, and the sponsoring committers. 15-2 The subproject will maintain an svn repository, referred to as the isandbox/i, as a workplace for new packages. Once approved, new packages must all begin in the sandbox. Any apache committer may contribute code directly to the sandbox and this code may form the initial source for new packages. Code from existing apache projects can, with the support of the contributing projects, also be imported directly into the sandbox. Finally, patches contributed incrementally by community members may be committed to the sandox by a subproject committer. If the initial source for a new package is from outside of apache, the new package must be brought into apache via the apache incubator. not sure but wonder whether we might need to tightening this last sentence so that it can't be read as implying that having only a portion of the initial source from external sources is ok. opinions? 15-3 A majority vote among subproject commiters is required to graduate a package from the sandbox to become a proper package. Only proper packages may make releases. If a package remains in the sandbox for more than six months, a majority vote will be required to prevent its being archived from svn and removed from the subproject web site and any other public locations (e.g. nightly or continuous integration builds). Proper packages may not release code with dependencies on sandbox packages. 1. i wonder whether it'd be better to have bi-annual reviews to simplify administration. in january, review all sandbox components which were created before the previous july. could run them as a single vote. 2. i wonder whether we actually need to remove them from svn: just could copy them into an archive directory. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Name for commons-like area for web
On Mon, 2005-06-27 at 19:37 +0200, Torsten Curdt wrote: Pardon my ignorance, but if Web were a subproject under Jakarta Commons, could Web itself have subprojects? AFAIK there is no project that has such subproject. ...but that does not mean it's completely impossible. Probably needs to be discussed. please, please no sub-sub-projects! apache has been trying to unwind the deep hierarchical structure (that jakarta used to have) for several years now in favour of a flatter model. the reason is simple: hierarchical structures tend to fragment and create problems with oversight. this issue of oversight is of critical importance for the board (and anyone else who cares about the future of the foundation). projects and sub-projects are constructs for legal oversight and management. one of the issues for a flatter jakarta is guiding uses through a myriad of components managed by a single community of developers. all components are equal but the management structure and the relationship structure expressed by the website navigation do not necessarily need to coincide. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The content of the folder weapps of tomcat disappeared.
this sounds to me like a question that would be better directed to the tomcat user list. see http://jakarta.apache.org/site/mail.html. - robert On Fri, 2005-06-24 at 16:05 -0300, Cosmo Luís Arrivabene wrote: The content of the folder weapps of tomcat disappeared. Did not have intervention human being, somebody can help to understand it? Tank's My tomcat version is 4.1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
new Standard/JSTL subproject? [WAS Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin]
On Thu, 2005-06-23 at 20:14 -0400, Henri Yandell wrote: On Thu, 23 Jun 2005, robert burrell donkin wrote: On Thu, 2005-06-23 at 00:49 -0300, Felipe Leme wrote: Apache Wiki wrote: Please do not edit comments into this text: please use the CharterForWebCommonsRequestForComments or post to [http://jakarta.apache.org/site/mail.html General At Jakarta]. OK, here I am posting :-) 3.What about the Standard Taglibs? Should it be part of this new project or should it be a separate project. The reasoning here is that, because that sub-project provide the codebase for JSTL's implementation (and maybe other JSR taglibs in the future as well, such as the Web Services taglib), its development activities/cycles might be different from the non-standard ones (we could even try to apply the TCK on such projects in the future, for instance). if the new subproject is anything like the commons then each component will have it's own development rhythm. it might be easier to raise extra hands when needed for these efforts if these share the same infrastructure (mailing lists, subproject organization and so on). opinions? My vote is for the active Taglibs to roll into the web component subproject, but for the Standard/JSTL taglib to move to Jakarta subproject status. Taglibs-user is dominated by JSTL questions and the JSTL committers don't have any obvious overlap with the other taglib committers (that I've noticed). Also in terms of codebase, Standard is the relative behemoth. Lastly it has a much higher profile than other parts of web-component-subproject will have and as a spec implementation it has a different set of issues to deal with. +1 are there any committers involved with JSTL around? if not, would anyone like to volunteer to sound them out about a move to subproject status? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of CreatingCommonsForWebComponents by FelipeLeme
On Thu, 2005-06-23 at 00:38 -0300, Felipe Leme wrote: I also fixed the alphabetic order of the existing proposals (but accidently typed enter before adding that comment). thanks - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [ANNOUNCEMENT] Proposal For Jakarta Sub Project For WebApplication Components
On Thu, 2005-06-23 at 09:45 -0400, Bernard, Shawn wrote: If someone is interested in this project, what should they do? you've already taken the first step: signing up to this list and joining in :) at the moment, this is just a proposal. for this to get any further, there are some tangible things that need to happen such as choosing a name and creating a charter. there are also intangible things like bootstrapping a community. the jakarta committers will need a name and a charter as well as a community to be convinced of the viability. right now, we need community support in developing (in more concrete terms) exactly what this new subproject should be and how it should be organised. the final charter should be an expression of these ideas. take a look at the documents on the wiki and post improvements and criticisms (at the moment, they are just a starting point: copies of the current jakarta commons charter). (sign up and) add new linked documents containing anything you think might help (ideas for components, perhaps or best practices). think of names or come up with reasons why a particular name should be picked (or not picked). the wiki should provide bootstrap documentation for the subproject. join in the discussions. in other words: get involved in the best way you see fit. - robert - 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
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: snip Here are some comments on the draft charter. It is nice to see so much borrowed from the (at least I think) successful j-c model ;-) everything borrowed, in fact. not that it'll stay that way for long... A couple of things should be changed, though, IMHO. i'm sure there are few more than that ;) i've decided to chop phil's good reply up into bits so that items requiring more discussion can get their own threads... First in the scope statement intended for use in server-related development could be narrowed to web application development +1 Uniformly change CVS to SVN (I assume! :) +1 snip 4.2 should probably reference JSP/Servlet spec level requirements as well as JDK requirements +1 +1 to bullet under 7 :-) ++1 Don't know what kind of goo 12 would result in or who would use such a thing ;-) +1 i'm all for removing 12. this proved just too difficult to coordinate. unless anyone feels the need to -1 any of these, someone should go ahead and make these changes... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mailing lists for components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
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? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
configuration files [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: 9 or somewhere else should speak to J2EE or other external config requirments, which should be fine, even encouraged in some cases is 9 needed? are any configuration guidelines needed? if they are then i agree that they should encourage specification compliance. would a general statement about specification compliance be better? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[POLL] drop point 12 [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: snip Don't know what kind of goo 12 would result in or who would use such a thing ;-) this has proved impractical in the jakarta commons. i propose we drop point 12. - 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]
new components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: snip 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. is 19 needed in addition to 15? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: snip I guess 18 refers to the sandbox? I do not understand what the intent of this is. is boils down to the question: does this subproject need it's own sandbox or will neophyte components start in the jakarta commons sandbox? - robert - 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
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: snip One final thing to think about. I know lots of apache people are opposed to umbrella projects for lots of reasons, one of which is the fragmentation and abandonment that can result. We have certainly not been immune to that in j-c. Two things that have been critical to keeping us going have been 1) a relatively small (changing over time) set of key contributors who look after multiple components and 2) some large internal customers (tomcat, struts, maven et al) whose committers jump in to push things along as needed. This project would be starting without the large internal customers. It would probably be a good idea, therefore, to start with a narrower, rather than broader scope, so that the fledgling community would not get fragmented too quickly and the key contributors could emerge. Just a thought. good points it's clear to me that there needs to be sufficient interest from developers with free time for this subproject to be viable - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
On Thu, 2005-06-23 at 00:49 -0300, Felipe Leme wrote: Apache Wiki wrote: Please do not edit comments into this text: please use the CharterForWebCommonsRequestForComments or post to [http://jakarta.apache.org/site/mail.html General At Jakarta]. OK, here I am posting :-) I'd like to suggest 2 things: 1.We prefereably use Maven for the builds, as it helps a lot handling the dependencies (if we stick to Ant, we should at least use Ivy or M2 Ant stuff for dependency management). For instance, I haven't applied some patches to the Jakarta Taglibs because my computers are not set for building them anymore (and I don't have the time/patience to fix it). jakarta commons is agnostic (but uses maven for the website). i'd recommend official agnosticism with unofficial encouragement to maven. it is a good idea to provide ant scripts generated by maven in SVN. 2.Regarding the Jakarta Taglibs, we should create the new taglibs from scratch. I mean, of course we should reuse the code, but we better do some refactoring first (for instance, eliminating redundant taglibs, defining a role for TLD names, etc...) - the current Jakarta Taglibs would then be frozen in time. IMHO it would probably be more convenient to maintain these frozen taglibs (from an official perspective) within the new subproject. with subversion, it's really nice and easy to have cool directory structures... 3.What about the Standard Taglibs? Should it be part of this new project or should it be a separate project. The reasoning here is that, because that sub-project provide the codebase for JSTL's implementation (and maybe other JSR taglibs in the future as well, such as the Web Services taglib), its development activities/cycles might be different from the non-standard ones (we could even try to apply the TCK on such projects in the future, for instance). if the new subproject is anything like the commons then each component will have it's own development rhythm. it might be easier to raise extra hands when needed for these efforts if these share the same infrastructure (mailing lists, subproject organization and so on). opinions? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
On Thu, 2005-06-23 at 00:52 -0300, Felipe Leme wrote: Felipe Leme wrote: I'd like to suggest 2 things: ... 3 Damn, beaten by the ENTER key again :-( shades of monty python's flying circus ;) - robert - 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
On Sun, 2005-06-19 at 15:34 -0400, Frank W. Zammetti wrote: robert burrell donkin wrote: web parts is a good name. I thought so... that's why I chose it ;) trademarks are of particular importance for the ASF but it's also important to do the right thing ethically. i wouldn't be happy to see a jakarta subproject take the name of a related open source project against the wishes of those involved in that project. It might be worth noting that this weekend marked the first actual release of my project... granted it's a pre-alpha release, but a release none the less. I am still interested in collapsing my project into this new Jakarta sub-project, hence my participation in this discussion... if that happens, Jakarta Web Parts sounds good to me, I'd have no problem closing down my project and passing the name along. If my project remains separate though, I'd prefer to not have to change my name :) 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. anyone have any opinions about this? web parts appears to in use by dot net. not sure whether anyone holds trademarks. FWIW AIUI sun are opposed to names such as java web parts (trademark reasons): they believe it should be web parts for java (WP4J). Well, if it is part of .Net, then maybe I have to change mine anyway :) In any case, I actually very much like the Sun approach here, although I'm not sure I know why! Web Parts For Java (WP4J) sounds pretty good... although JWP is a shorter abbreviation ;) 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... in any case, the official name would be jakarta web parts (or jakarta web bricks). if a consensus emerges then the pmc could probably check out the legal side. Or Jakarta Web Parts For Java, or JWP4J, which has the benefit of being what I am now (JWP) with 4J appended. I for one like it! that sounds good to me too. anyone else have an opinion? this leads to the question: what's the best way to develop the charter? i've been contemplating using the wiki to store a working draft whilst debating content on this list. opinions? That seems reasonable to me... In fact, what might be nice is to have a link off the Wiki page labeled Request For Comments... that way people can post their ideas to that without the possibility of missing anything on the mailing list, and without changing the content outright... I'm sure we all have our filters set up and we all try to manually filter as well, and I for one can't say I've never missed something I would have been interested in. that sounds like a good plan. - robert - 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
On Wed, 2005-06-22 at 16:53 -0400, Frank W. Zammetti wrote: I'll step back and let you guys get it off the ground then... no one's asking you to step back :) the reason why this discussion was moved to this forum was to encourage people to get involved with the discussion and help to shape the sub project. consider staying and doing that. it's important to understand that there's a distinction between importing existing code into apache (which would mean incubation to build a community, educate committers and ensure there were no legal issues) and collaborating in the development of new code covering similar ground. i can think of (at least) one example of a Jakarta Commons committer who developed open source libraries covering similar ground. the apache contributions were new code and so the question of importing code does not arise. However, the one point that I believe to be very relevant at this junction, in light of what Robert has said about a name being required up-front, is that I may not be willing to give up the Java Web Parts name. Since that was one of the suggestions, I think that is a relevant point. And since mere similarity of names was mentioned by someone as well, it is that much more relevant. fine (feel free to remove any names you're not happy with from the wiki) Martin Cooper wrote: Can we please separate the two different topics being discussed here? +1 we need to start some new threads with better subjects... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] Proposal For Jakarta Sub Project For Web Application Components
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? - 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]
Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: Stephen Colebourne wrote: robert burrell donkin wrote: there have been a number of long running threads in the commons discussing the possibility of commons components for use in web applications. the consensus emerged that it would be best if a new subproject with a structure similar to the commons was created for components intended for use in web applications. opinions, please! I am in favour of this, although whether I would be able to spare much time is debatable. I am also in favor, also not likely to have much time to contribute. Here are some comments on the draft charter. It is nice to see so much borrowed from the (at least I think) successful j-c model ;-) the text is the jakarta commons charter :) but it's just a starting point: hopefully it'll stimulate some discussion and people can start to move to forward... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] site change for Jelly release
committed. hopefully, someone will sort you out with site karma sometime soon (it's open to all jakarta committers upon request)... - robert On Fri, 2005-06-17 at 02:34 +1000, Brett Porter wrote: As per http://jakarta.apache.org/commons/releases/release.html I am sending this here. I do not have access to the jakarta-site SVN module and am not a Jakarta PMC member. Would somebody be able to apply the above to jakarta-site? I've scp'd the resulting docs files up to the web server and confirmed the permissions are right, so next svn up from there should just merge them in. Thanks, Brett - 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] subproject that's a home for bricks reusable in java web applications
there have been a number of long running threads in the commons discussing the possibility of commons components for use in web applications. the consensus emerged that it would be best if a new subproject with a structure similar to the commons was created for components intended for use in web applications. opinions, please! in particular: a charter needs to be developed (based on the commons one) a name needs to found (feel free to start new threads on these topics) some debate has already started on various lists (pmc, commons-dev, taglibs) but all are invited to consolidate the discussions onto this list... - robert signature.asc Description: This is a digitally signed message part
Re: Need JAR file with...
jetspeed has graduated to: http://portals.apache.org/ follow the instructions to download the jetspeed jars - robert On Mon, 2005-06-13 at 10:07 -0700, Bosko Popovic wrote: ...org.apache.jetspeed.security.spi.impl.LdapCredentialHandler class as well as all necessary prerequisite classes, thanks Boli Popovic - Discover Yahoo! Have fun online with music videos, cool games, IM more. Check it out! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Last Call For ApacheCon Europe 2005 Early Birds
Forwarded Message ApacheCon Europe 2005 - Early Bird registration runs out June 17. ApacheCon Europe 2005 July 18-22, 2005 Stuttgart, Germany Only a few days to save money! By registering prior to June 17 you can save more than 200 EUR! More pricing specials such as company team discounts and a 25% off for students are available as well. ApacheCon Europe 2005 offers an immense program consisting of several half-day and full-day tutorials on July 18 and 19 and more than 70 sessions on July 20-22. With plenty of room for networking and peer discussions, attendees can meet ASF members and and participants during the ApacheCon Expo, evening events, Birds-of-a-Feather sessions and a number of informal social gatherings. Among the highlights of ApacheCon Europe 2005 you can find a keynote presentation by Horst Zuse, son of Konrad Zuse, who is considered as the inventor of the first programmable computer. Horst Zuse will give a keynote presentation on the origins of the computer, leading through the history of computing. All information on ApacheCon Europe 2005 and registration possibilities can be found at http://www.apachecon.com. Best Regards... -- Lars Eilebrecht [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Update jakarta site with commons-lang 2.1 release info
hi steven i don't think that the diff made it. you might need to upload it to people.apache.org or create an issue report alternatively, you could ask for site karma and apply it yourself... - robert On Sun, 2005-06-12 at 14:39 -0400, Steven Caswell wrote: Per the instructions at http://jakarta.apache.org/commons/releases/release.html, I have attached the diff for the jakarta site files I've changed for the commons-lang 2.1 release. Could someone please complete the step for updating the jakarta site. TIA - 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: Apache cannot connect to Tomcat in httpd.conf
hi andreas you'll probably get a faster response if you post this question to the tomcat user list. please read http://jakarta.apache.org/site/mail.html. - robert On Sun, 2005-06-05 at 12:54 +0200, Andreas Bauer wrote: Hello! Can somebody help me, please? My OS is Suse 9.2 pro. Apache and Tomcat work for me. But If I start Apache with normal httpd.conf, Apache works for me. If I paste my lines for Apache-Tomcat Connection, Apache doesn't work for me, only Tomcat. It must be something wrong with this lines, but the same lines in httpd.conf in a windows XP Tomcat-Apache configuration works for me: The pasted lines in httpd.conf are: LoadModule jk2_module modules/mod_jk2.so Location /*.jsp JkUriSet worker ajp13:localhost:8009 /Location Location /mywebapp JkUriSet worker ajp13:localhost:8009 /Location The Tomcat Connector Modul mod_jk2.so is in the rigth directory and Apache doesn't send an errormessage,, because of the module, when I start Apache from the commandoline. If I took another Tomcatconnectormodul, I got errormessage. With the old one, not. My jk2.properties is: TOMCAT_DIR/conf/jk2.properties, adding the following line: channelSocket.port=8009 Configuration of server.xml is: server.xml configuration from Tomcat/conf directory: look for the non-SSL Coyote HTTP/1.1 Connector. This is the standard Tomcat-only connector and comment it out since we'll be using Apache for handling HTTP requests. In the same file, look for a commented line that says Context path= docBase=ROOT debug=0. Right after that line, add the following Context path: Context path= docBase=APACHE_DIR/htdocs debug=0 reloadable=true crossContext=true/ Workers2.properties is: APACHE_DIR/conf directory/workers2.properties: [shm] file=APACHE_DIR/logs/shm.file size=1048576 # socket channel [channel.socket:localhost:8009] port=8009 host=127.0.0.1 # worker for the connector [ajp13:localhost:8009] channel=channel.socket:localhost:8009 The working script is from http://www.dynamicobjects.com/d2r/archives/002574.html http://www.dynamicobjects.com/d2r/archives/002574.html The same T-A Connector Configuration with a windows Connector Module works for me in a windows system. Best regards and many thanks Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SSH access to jakarta.apache.org
AIUI the dns names have changed around a bit. jakarta.apache.org is now being served from ajax. you should now access your minotaur as people.apache.org. ajax is mirrored so you'll need to wait for the mirrors to sync before you'll be able to see any changes you make. - robert On Thu, 2005-05-05 at 19:01 +0200, Oliver Zeigermann wrote: Folks! As already said it seems I will need SSH access to jakarta.apache.org to update the jakarta commons transaction website - which I am a committer for. Is that right? If so who can grant that for me? Thanks, Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Verifying Downloads
sadly, AFAIK this document does not exist as yet. (i have been intending to create one for quite a long time.) please google for the theory behind these technologies but i'll try to give a brief guide. md5 is a checksum. a checksum is a numeric hash of a file. the idea is that two different files will have different checksums. you use a secure, trusted channel to learn the checksum then use the same algorithm to calculate the checksum for the file which has been obtained from an untrusted channel. if the checksum calculated matches then you can conclude that the file is identical to the one that the trusted checksum was calculated from. in ASF terms, downloading a file from a apache mirrored and an md5 checksum from an apache server and calculating the md5 sum for that file should allow you to determine whether the file you downloaded from the mirror is identical to the file that the sum placed on the apache server was calculated from. checking the md5 sum should be a good enough guarantee for the vast majority of users. if you have more stringent requirements, you might also want to check the openPGP compatible digital signature. this tells you something different: which key was used to sign the release. if you have a public key matching the private key used to sign the release then you can verify the signature of the file. this tell you whether the file is identical to the one used to create the signature. note that you can only trust this method of verification as far as you can trust the public key. unless your web of trust extends to the key in question, this method may be no more secure than the md5 sum. see http://people.apache.org/~henkp/. in terms of implementations, i use http://www.gnupg.org for the signatures, and openssl or md5sum for the sums. - robert On Sun, 2005-05-01 at 12:02 -0600, Robert Voelkerding wrote: Please direct me to an explanation of how to use MDE and/or PGP keys to verify downloads. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Verifying Downloads
On Sun, 2005-05-01 at 14:59 -0400, Henri Yandell wrote: That would be a good link to have on the download pages wouldn't it :) Googling, I get: http://www.hybridized.org/forum/viewtopic.php?t=222 which contains nice links to Windows programs. Verifying MD5 is easy on unix-based machines as it's the output of either the md5 or md5sum commands. Closer to home Apache-wise, there's the HTTPD document on verifying the PGP keys. http://httpd.apache.org/dev/verification.html Hope that helps, and I'll add having a better answer on the site to the todo list. the best place would probably be in the release FAQ over on the foundation site. i've been meaning to add some information on this for a while but haven't found the time as yet. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Tomcat - TLP
On Wed, 2005-04-06 at 19:36 -0400, Ian F. Darwin wrote: [X] +1 Vote in support [ ] 0 Abstain [ ] -1 Vote against (Jakarta PMC) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: help with patch submission for VFS
you'll find general information on contributing on the website and in particular http://jakarta.apache.org/site/getinvolved.html. there are two ways to submit patches: either through bugzilla (http://issues.apache.org) or by posting an email to the commons-dev list (see http://jakarta.apache.org/site/mail.html) with subject prefix [vfs][PATCH]. you might need some patience and require some gentle reminders before it's picked up. - robert On Tue, 2005-04-05 at 19:55 -0600, Dan Mingus wrote: I'm trying to figure out where to submit a patch for the VFS sandbox project in jakarta-commons. Any help? - 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?
On Mon, 2005-03-28 at 10:49 +1000, Brett Porter wrote: There are a few alternatives. If webDAV is the answer from infra, then we can definitely get that into the site plugin. It is on the todo list as Tim noted, but the list remains very long at this point :) sounds familiar: so much work, so few hours :) a lot of folks are keen on mavenised websites here so i think that we should be able to find volunteers to hack the code provided that there are maven folks willing to give a lead and make sure the work's done in the right way. given that infrastructures talking about switching off accounts on minotaur in a matter of months and there's work that's going to be needed to be done, it's probably worth trying to pull some stuff together sooner rather than later. this seems like an apache-wide infrastructure issue for maven so there are a number of lists that might be appropriate for this discussion (maven-dev, infrastructure, general at jakarta). i'd be inclined to leave the thread here (might be easier to find bodies who aren't working on maven right now). opinions? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
future for maven generated websites?
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]
Re: Jakarta Apache Tomcat as a TLP ?
On Mon, 2005-03-21 at 17:20 -0800, Bill Barker wrote: - Original Message - From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta General List general@jakarta.apache.org Sent: Monday, March 21, 2005 2:45 PM Subject: Re: Jakarta Apache Tomcat as a TLP ? From: Henri Gomez [EMAIL PROTECTED] Well I'd like to know the pros and cons of Tomcat being TLP. As I said in tomcat-dev, it was proposed when ant became TLP and at this time the consensus was to stay under jakarta umbrella. What motivate the move to TLP now. Currently, Tomcat developers are having to take time away from their main task (coding) to answer management issues raised by Jakarta. This raises the question of whether Tomcat is big enough and mature enough to manage these issues itself, without the involvement of Jakarta. Great. Now this thread has moved from JBoss-bashing to dissing the entire Tomcat community. I'm looking forward to your involvement on tomcat-dev so that we can all know that Tomcat has the proper adult supervision. this isn't tomcat bashing: it applies equally to all jakarta sub-projects. the jakarta pmc (including stephen) supervises every sub-project (including tomcat) on behalf of the board. once a sub-project community feels that they are ready to manage their own affairs, that's great but there can be no question of self-governing sub-projects: it's time for them to move on and up :) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [draft-2] SD Magazine: request for change
On Sun, 2005-03-20 at 20:40 +0100, Torsten Curdt wrote: Hi Kate, I'd like to thank SD/Jolt on behalf of the Jakarta community for the JOLT Productivity Winner award for Tomcat 5.0. Media recognition of the work the Tomcat community puts in is always very welcome. I'm also writing to let you know about a [serious] error on your JOLT product excellence awards press release because I am concerned it might be reproduced in your forthcoming June 2005 issue: I would drop serious +1 http://www.sdmagazine.com/pressroom/jolt_winners_2005.pdf The release [incorrectly] attributes Apache's Tomcat 5.0 product to The Also the incorrectly +1 Apache Jakarta Project and leading Tomcat contributor JBoss. There is one big problem with this attribution for us, Apache does not have a concept of leading contributors. It is completely out of sync with the very philosophies that lie at the heart of the Apache Software Foundation (ASF), as there are 70 committers to the Tomcat codebase, many of whom are employed by other companies or contribute individually. We would like to request that this be changed to: request sounds a bit harsh ...what about see +1 Tomcat 5.0 (The Apache Software Foundation) in both the press release (pdf url above) and the forthcoming June 2005 issue. Officially the name of the product is Apache Tomcat 5.0 and not just Tomcat 5.0, but I will leave it to your discretion as to whether you'd like to prefix Tomcat with Apache or not, as the subsequent mention of the ASF is fine. ...always play nice on the first contact. +1 sometimes less says more :) am i right in thinking that the importance of pushing Apache Tomcat now is about trademark issues? (one neat way of diffusing this the whole issue might be for the attribution to be corrected but a quote given by remy of jboss) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] kill proposal.html page
On Wed, 2005-03-16 at 01:53 -0500, Henri Yandell wrote: The following page looks very dated, and I suspect utterly dead: http://jakarta.apache.org/site/proposal.html I'd like to kill it, and will do if I hear no -1's by Friday evening. +1 - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
