Re: [PMC VOTE] PMC Nominations
from:Sam Ruby [EMAIL PROTECTED] Suggestion: let's call this round complete at this time, and start a new round next month. I'll notify the board later tonight that everyone in the following list (minus Pier) is to be added to the Jakarta PMC: http://marc.theaimsgroup.com/?l=jakarta-generalm=104518242028805w=2 At the same time, I will also request that Stephen Colebourne be dismissed without prejudice [1] from the roster of the Jakarta PMC. Aw hell, I was about to mail in and say that the arguments had been persuasive enough to convince me to give the PMC a try. Oh well, never mind. I'll carry on committing anyway... (In case it wasn't spotted, most of my complaint was about not being notified. Finding out by newsletter was in my view unacceptable) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PMC Nomination
I like to totally endorse Leo's points about the Avalon PMC, My experience with James PMC is very, very similar. James PMC is by and large the whole set of commiters who were active in discussions about the project, rather than just the code. From that POV nothing much has changed, we're a bit more aware of our responsibilities, but it doesn't involve a load more participation. I can see that limiting the size of Jakarta PMC would compel PMC members to take a more active interest in parts of the project that wouldn't normally cross their paths. Conversely extending the PMC to include *trusted* additional members spreads the load, and a wide range of interests in the PMC ensure that every aspect is covered. Then again widening the PMC by indiscriminately including everyone may backfire if they can't rely on each other, so that instead of seven people sharing the load you get 22 people all keeping their own eye on everything. I've been nominated for the Jakarta PMC this round, and I intend to serve if elected, and although I'm not a commiter on any jakarta-projects any more I believe that my small contribution (irrespective of its quality..) will help to ensure that jakarta is a focused community project, and that it has ties with other projects and the wider Apache community. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PMC Nomination
Pier Fumagalli wrote: On 19/2/03 23:10 Leo Simons [EMAIL PROTECTED] wrote: I don't think anyone expects that upon becoming a PMC member one would immediately need to gain and maintain intimate knowledge of all corners of the jakarta codebases. It is just about humanly impossible. So it is probably a good move to ensure the PMC is of a size where there are one or more people who do have that intimate knowledge for each particular corner. If I talk to someone on the HTTPd PMC, he _knows_all_. I don't see why it should be different for Jakarta. And if the problem is size, well, break up the bloody thing, it was never designed to be this huge. If I understand correctly the political trends here, promoting people to the Jakarta PMC is trying to get people involved, and knowing each other and the whole of Jakarta, so that the process of promotion of more and more projects to top-level does not balkanize the communities any more. Also, to promote wider awareness of the big community as a whole. It does not look like bad for me. So, the move is in the right direction, something like making jakarta community grow to later split (re-organize?) it with less trauma (sp?) My 2 pennies. When will you, half europeans ;-) enter the euro stuff so that you can pay me a beer in Madrid with less transaction cost? ;-) Two euro cents in exchange. Santiago Pier - 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]
Would Jakarta like to adopt MaybeUpload?
Hi Introduction: About MaybeUpload URL: http://www.weft.co.uk/library/maybeupload/ I wrote MaybeUpload, a package to make it easy to write Servlets which can do RFC 1867 style file upload, about two years ago, and immediately announced it on Freshmeat as an open source project (BSD license). In March 2002 the Cocoon project asked me if they could include MaybeUpload in the Cocoon 2 distribution, and of course I said I'd be delighted. As far as I'm aware it is still the only open source RFC 1867 compliant Servlet package available. I now think MaybeUpload is now pretty much stable - it is after all a fairly simple piece of functionality. It's to everyone's benefit if it is widely used, because it means that other people don't have to reinvent this particular wheel, and more improvements will feed back into the codebase. I feel it would be likely to get more users if it were an official Apache project. I'm not wishing to hand over or end-of-life MaybeUpload - I'm quite happy to continue to be a or even the maintainer, but I'm equally happy to share repsonsibility with others. Fit with the Jakarta criteria Community MaybeUpload has a mailing list (which isn't very active - I hope because the thing just works and there isn't much to discuss) and has had bug fixes and feature improvements submitted by about a dozen people. I've generally accepted other people's fixes into the codebase provided I've been happy that they do something useful and don't break anything else, and have announced new releases both on the mailing list and on Freshmeat. Core Developers Frankly MaybeUpload has been primarily a one-person project. It does not have three core developers. Alignment with existing Apache subprojects MaybeUpload is already used by the Cocoon project. However, it's not XML related, it's Servlet related, so it doesn't belong in xml.apache, and Jakarta looks a more natural home. MaybeUpload is relevent to Tomcat, and also to things like Struts and Turbine. MaybeUpload depends on Jakarta-RegExp. Scope MaybeUpload is a server side component in the Java language. -- [EMAIL PROTECTED] (Simon Brooke) http://www.jasmine.org.uk/~simon/ Iraq war: it's time for regime change... ... go now, Tony, while you can still go with dignity. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PMC Nomination
And if that works for Italy, I believe it works everywhere else... Erm, are you really suggesting that Italian politics should be the model we emulate? d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Would Jakarta like to adopt MaybeUpload?
On Thursday 20 Feb 2003 1:59 pm, Patrick Ferdig wrote:
how does it compare to http://jakarta.apache.org/commons/fileupload/?
It's well established, widely used, debugged, and stable.
It's also a lot simpler to use. The example given on
URL:
http://jakarta.apache.org/commons/fileupload/apidocs/org/apache/commons/fileupload/package-summary.html
becomes
public class Example extends MaybeUploadServlet
{
...
public void doPost( MaybeUploadRequestWrapper req,
HttpServletResponse res)
throws ServletException, java.io.IOException
{
Object foo = req.get( uploadedfile);
if ( foo instanceof File)
{
// do things with the file
}
}
}
Which, as you can see, saves 90% of the work. There's no distinction between
the types of things which can be got from the request wrapper; simply asking
for them by name (using the names ot the inputs in the HTML form) gets them.
If they're strings, you'll get instances of java.lang.String; if they're
files, you'll get instances of java.io.File. Technically if they are nested
multipart-mixeds (which seems to be allowed by the RFC) you'll get a vector
whose members are either strings or files of further nested vectos, but I
have yet to find a client which can send such a thing.
Of course, if you specify save_uploaded as false in the Servlet config
(web.xml) you'll get a java.io.ByteArrayInputStream instead of java.io.File.
Other things you can specify in the web.xml include:
allow_overwrite
Boolean: whether or not to allow uploaded files to overwrite previously
uploaded files with the same name. Default is we don't.
max_upload
Integer: maximum size in bytes of file to upload. Optional. Default is
524288.
save_uploaded
Boolean: whether or not to save uploaded files directly to disk. Optional.
Default is we do. If we don't, the uploaded file will be returned as a
java.io.ByteArrayInputStream by a call to MaybeUploadRequestWrapper.get()
silently_rename
Boolean: whether or not to rename files whose names collide with existing
files in the upload directory. Default is we do. Note that if both
allow_overwrite and silently_rename are false and a name collision occurs,
we will throw an (@see UploadException).
upload_dir_path
String: A path to a directory in the server-side local file-system in which
uploaded files can be saved. Optional. Defaults to /tmp
upload_dir_url
String: the path to my upload directory (work directory) within the
document root of the web server, if it is within the document root of the
web server, else null. For example, if uploadDirPath was
/home/httpd/htdocs/upload, and the document root of the Web server was
/home/httpd/htdocs, then it would make sense to have uploadDirURL set to
/upload/. Optional. No Default.
All parameters may be supplied either as context-params or as init-params; if
both are supplied the servlet-specific init-param will override the
context-param.
Cheers
Simon
--
[EMAIL PROTECTED] (Simon Brooke) http://www.jasmine.org.uk/~simon/
Iraq war: it's time for regime change...
... go now, Tony, while you can still go with dignity.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
MS vs Open Source link
Overall a good article. http://news.com.com/2100-1001-985221.html?tag=fd_top The scary thing is I have heard clients that they think that if they use any open source... now their software is open source or in a conflict with comerical software they are using. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MS vs Open Source link
The scary thing is I have heard clients that they think that if they use any open source... now their software is open source or in a conflict with comerical software they are using. A good way to handle this is to take the Apache projects, name them something different, add a pretty UI and then sell them for lots of money to those same customers under a more restrictive and closed-source license. Oh, wait, IBM already does this =) (Not bashing IBM, just making a funny - this is sorta the point of the Apache license) -Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MS vs Open Source link
I can understand them thinking that. I had my gut feeling on it slightly off for a while, mainly as I was viewing one type of software. ie) Say I grab an LGPL/GPL Java library and incorporate it into my product, which btw I install onto client's machines via jnlp. As I am distributing a product, I have to open source it and furthermore GPL it. Now, the mistake I made was to apply this example to other software which ran only on the server, ignoring the fact that it wasn't being distributed in this case. Still, it's a pain to have to deal with and not worth the effort. That's only for the viral *GPL stuff though. As for the article itself, I think it's more the open atmosphere to bug-reporting that means opensource is less buggy, and the frequent releases, than the code itself being open. So there's no reason why closed source shouldn't be the same, except that they're unable to replicate the culture that popular open source projects have. Hen On Thu, 20 Feb 2003, Vic Cekvenich wrote: Overall a good article. http://news.com.com/2100-1001-985221.html?tag=fd_top The scary thing is I have heard clients that they think that if they use any open source... now their software is open source or in a conflict with comerical software they are using. .V - 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]
Prof Eben Moglen on L/GPL and jars
With all the discussion about licensing with LGPL stuff, I thought this might be interesting to everyone. Comes from the new Slashdot interview with Eben Moglen. (http://interviews.slashdot.org/interviews/03/02/20/1544245.shtml?tid=117tid=123) 2) Clarifying the GPL by sterno One issue that I know has come up for me is how the GPL applies in situations where I'm using GPL software but I'm not actually modifying it. For example, I write a Java application, and it is reliant on a JAR that is GPL'd. Do I then need to GPL my software? I haven't changed the JAR in anyway, I'm just redistributing it with my software. The end user could just as easily download the JAR themselves, it's just a convenience for me to offer it in my package. Eben: The language or programming paradigm in use doesn't determine the rules of compliance, nor does whether the GPL'd code has been modified. The situation is no different than the one where your code depends on static or dynamic linking of a GPL'd library, say GNU readline. Your code, in order to operate, must be combined with the GPL'd code, forming a new combined work, which under GPL section 2(b) must be distributed under the terms of the GPL and only the GPL. If the author of the other code had chosen to release his JAR under the Lesser GPL, your contribution to the combined work could be released under any license of your choosing, but by releasing under GPL he or she chose to invoke the principle of share and share alike. --- jaaron __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MS vs Open Source link
Henri Yandell wrote: (...) As for the article itself, I think it's more the open atmosphere to bug-reporting that means opensource is less buggy, and the frequent releases, than the code itself being open. So there's no reason why closed source shouldn't be the same, except that they're unable to replicate the culture that popular open source projects have. Culture is already a big enough answer. Being impatient as I am, I find increasingly that culture in closed source groups, no matter how big, is much less cosmopolitan than, say, Apache or Debian people. One of the reasons is because they cannot discuss freely (with lines of code) the technical problems except in a reduced population, and they tend to have narrow thinking. Also, I think a key answer is about shame and pride. I have already felt ashamed committing very hacky code in public repositories due to the need of having it working, quick fixing, etc. In a closed source culture thee is no compelling reason to revisit this code, and the probability of somebody else fixing or refactoring it is quite small. ;-) You have both a positive reason (being proud of your own code) and a negative pressure (being ashamed by other people looking at it) to ensure highr quality of initial Open Source contributions. On top of this, you have a feed back process to fix problems. So, I won't be marvelled if the results are (asymptotically) perfect. Regards, Santiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][PMC VOTE] PMC Nominations
the following committers have passed the PMC nomination vote proposed by sam ruby: - Danny Angus - Peter Carlson - Morgan Delagrange - Ceki Gülcü - Dmitri Plotnikov - Phillip Rhodes - James Strachan - Jason van Zyl - Ted Husted - Rod Waldhoff i'm sending this to let you all know. the role of jakarta PMC is changing but rather than give an opinion and pretend some authority i don't have, take a look at this thread: http://marc.theaimsgroup.com/?l=jakarta-generalm=104561165403863w=2 i hope you'll accept the nomination. - robert On Wednesday, February 19, 2003, at 10:41 PM, Sam Ruby wrote: snip Suggestion: let's call this round complete at this time, and start a new round next month. I'll notify the board later tonight that everyone in the following list (minus Pier) is to be added to the Jakarta PMC: http://marc.theaimsgroup.com/?l=jakarta-generalm=104518242028805w=2 At the same time, I will also request that Stephen Colebourne be dismissed without prejudice [1] from the roster of the Jakarta PMC. Next month, lets start with the nominations that didn't quite make this round, and add to the list. - Sam Ruby [1] http://www.lectlaw.com/def/d062.htm - 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: Would Jakarta like to adopt MaybeUpload?
on 2003/2/20 7:16 AM, Simon Brooke [EMAIL PROTECTED] wrote: It's well established, widely used, debugged, and stable. It's also a lot simpler to use. The example given on URL: http://jakarta.apache.org/commons/fileupload/apidocs/org/apache/commons/fileup load/package-summary.html I think you missed the point...we don't need yet another fileupload package...we need you to work with the existing one to improve it and make it better. -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
