Re: [PROPOSAL] J2EEUnit donation to ASF
At 09:57 AM 3/27/01, Vincent Massol wrote: OK ... sigh If you have ideas, they are welcome ... It seems to me the '2' could go, because that's nailing it to a version, and the second 'E' could go because we don't need an Edition. Then we're left with JEUnit for Java Enterprise Unit testing framework. That's not so bad. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Request karma for jakarta-site2
I need to update the Jakarta web site for a new Struts release. (I'm the release manager.) Can someone give me karma to do this, please? Thanks! -- Martin Cooper -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: committed mail.xml
Done. -- Martin Cooper - Original Message - From: Andrew C. Oliver [EMAIL PROTECTED] To: general at jakarta [EMAIL PROTECTED] Sent: Saturday, January 26, 2002 5:03 PM Subject: committed mail.xml Hi, I just committed this. If someone with a www account can make this active, I'd appreciate it. Once that's done I can start transitioning people off of the old poi mail archive and on to the new. Thanks, Andy On Sat, 2002-01-26 at 19:33, Andrew C. Oliver wrote: Index: mail2.xml === RCS file: /home/cvspublic/jakarta-site2/xdocs/site/mail2.xml,v retrieving revision 1.37 diff -u -r1.37 mail2.xml --- mail2.xml 20 Jan 2002 04:10:03 - 1.37 +++ mail2.xml 27 Jan 2002 00:40:17 - @@ -525,6 +525,35 @@ /p /section +section name=POI +p +bThe POI User List/bbr/ +bLow Traffic/b +a href=mailto:[EMAIL PROTECTED];Subscribe/a +a href=mailto:[EMAIL PROTECTED];Unsubscribe/a +a href=http://www.mail-archive.com/poi-user@jakarta.apache.org/;Archive/a +/p +p +This list is for users of POI to ask questions, share knowledge, +and discuss issues. POI developers are also expected to be lurking +on this list to offer support to users of Lucene. +/p +p +bThe POI Developer List/bbr/ +bMedium Traffic/b +a href=mailto:[EMAIL PROTECTED];Subscribe/a +a href=mailto:[EMAIL PROTECTED];Unsubscribe/a +a href=http://www.mail-archive.com/poi-dev@jakarta.apache.org/;Archive/a +/p +p +This is the list where participating developers of the POI project +meet and discuss issues, code changes/additions, etc. Subscribers to +this list also get notices of each and every code change, build +results, testing notices, etc. bDo not send mail to this list with +usage questions or configuration problems/b +/p +/section + section name=Regexp p bThe Regexp User List/bbr/ -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: StudioZ (was: Re: JakartaOne?)
- Original Message - From: Geir Magnusson Jr. [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Monday, March 04, 2002 12:46 PM Subject: Re: StudioZ (was: Re: JakartaOne?) On 3/4/02 3:42 PM, Jon Scott Stevens [EMAIL PROTECTED] wrote: on 3/4/02 12:38 PM, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: If we do that, we can do something technical as well in the Covalent space? I don't think that would be a good idea because then you would be asking people to travel all over town. Just do the event in StudioZ...we have two spaces and the 'smaller' B space (3000+ sq feet) is perfect for technical sessions... Dirk offered to bring projectors and I can probably borrow one from BrianB as well... That would be great then. Just didn't want to have to shout over the noise from the dance floor :) My sentiments exactly! ;-) -- Martin Cooper -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting You're going to end up getting pissed at your software anyway, so you might as well not pay for it. Try Open Source. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] ASL vs. GPL page: is this okay?
Are you referring to the noun or the verb? http://dictionary.cambridge.org/define.asp?key=licence*1+0 In short, licence is the noun, license is the verb. Geez, these Americans think they speak English... ;-) ;-) -- Martin Cooper - Original Message - From: Ted Husted [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Thursday, March 07, 2002 4:22 AM Subject: Re: [VOTE] ASL vs. GPL page: is this okay? http://www.dictionary.com/search?q=license http://www.dictionary.com/search?q=licence alex wrote: At 09:16 07/03/02, Danny Angus wrote: It is spelled licence. ;-) Wow - we managed to correct Jon on a technical point! (Just kidding Jon - no offence) licenSe is what Apache Software Foundation does - ie the act of licensing. licenCe is the document or permit given - eg the file itself. Since this is all about the document then licenCe is the correct spelling (ignoring Case that is). Personally I feel the existing web page which Jon reminded us of was quite good and if there is anything important missing then that is the page which should be improved. Alex -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JakartaOne: The Gathering
Where are we on this? It would be so sad to have so many of us attending JavaOne in the same place, but without the opportunity to get together as Jakarta people. Jon is right - there are a bazillion places we could meet, and a bazillion places we could eat. Sorry, the container is ready. [EMAIL PROTECTED] - Original Message - From: Geir Magnusson Jr. [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Friday, March 15, 2002 11:12 AM Subject: Re: Micro JakartaOne On 3/15/02 12:52 PM, Jon Scott Stevens [EMAIL PROTECTED] wrote: on 3/15/02 5:18 AM, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Any suggestions for a good restaurant anyone? There are a bazillion good restaurants in SF. You just pick the style of food you want and I can list off about 100 for each style. Also, I'm still willing to show people the club, even if we aren't doing anything... What kind of attendance commitment would it take to open the bar for a small crowd? We can just meet there? I certainly want to see the place... -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Age and treachery will always triumph over youth and talent -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JakartaOne: The Gathering
Monday would be better for me - as Marc mentioned, there are BOFs that might cause a conflict on Wednesday - but I'm sure I could make other nights. I haven't been to the Thirsty Bear either. It's very close to Moscone, though. The cuisine is Spanish, and the prices look reasonable (for San Francisco). It looks like the bar is quite big, from the photo on the web site. The JBoss people have reserved a room there on Tuesday and Wednesday, although their party is elsewhere. Again, I haven't been there personally, but it seems promising. -- Martin Cooper At 12:35 AM 3/22/02, Geir Magnusson Jr. wrote: There are people starting to travel (they are already traveling...) so lets decide. Jon, can you suggest a place that isn't too far away from Moscone that has a large bar (with real beer...) we can gather in, with a reasonably-priced restaurant that we can then have dinner in? Cuisine can be anything, but a 'normal' american upscale bar menu might be the most appealing to the majority. How about Monday or Wed night? How about the Thirsty Bear? I don't know anything about the place - isn't that where the Jboss people are holding court? geir On 3/22/02 1:48 AM, Martin Cooper [EMAIL PROTECTED] wrote: Where are we on this? It would be so sad to have so many of us attending JavaOne in the same place, but without the opportunity to get together as Jakarta people. Jon is right - there are a bazillion places we could meet, and a bazillion places we could eat. Sorry, the container is ready. [EMAIL PROTECTED] - Original Message - From: Geir Magnusson Jr. [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Friday, March 15, 2002 11:12 AM Subject: Re: Micro JakartaOne On 3/15/02 12:52 PM, Jon Scott Stevens [EMAIL PROTECTED] wrote: on 3/15/02 5:18 AM, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Any suggestions for a good restaurant anyone? There are a bazillion good restaurants in SF. You just pick the style of food you want and I can list off about 100 for each style. Also, I'm still willing to show people the club, even if we aren't doing anything... What kind of attendance commitment would it take to open the bar for a small crowd? We can just meet there? I certainly want to see the place... -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Age and treachery will always triumph over youth and talent -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting My inner cowboy needs to yodel. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JakartaOne: The Gathering
OK, we need to make a decision, pronto! Let's meet at 21st Amendment (563 2nd Street) at 7:30pm on Monday. We can take the rest from there. Martin. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 22, 2002 11:24 AM Subject: Re: JakartaOne: The Gathering Jon, can you suggest a place that isn't too far away from Moscone that has a large bar (with real beer...) we can gather in, with a reasonably-priced restaurant that we can then have dinner in? Cuisine can be anything, but a 'normal' american upscale bar menu might be the most appealing to the majority. How about Monday or Wed night? How about the Thirsty Bear? I don't know anything about the place - isn't that where the Jboss people are holding court? Soapy Bear is horrid- they clean their tubes badly, use too much detergent when they do, and as a result you get old yeast and other crap. Always a headache the next day. I'd also be against the Irish place - too noisy to talk :-) Other near by ones which are good to OK IMHO, have good beer and good food are and are quiet enough to talk: Rickenbacher bar; 2nd and mission 21st Amendment; 2nd 2 blocks down. Dw -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JakartaOne: The Gathering
I've printed a scaled-up copy of The Jakarta Project logo, and am hoping to tape it up, or make it otherwise visible, somewhere in the bar, so that we can find each other. Alternatively, Dirk's Lego project idea might help, although it's been a very long time since I played with Lego... :-) -- Martin Cooper - Original Message - From: Marc Saegesser [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Sunday, March 24, 2002 4:32 PM Subject: RE: JakartaOne: The Gathering I'll be there. I'm in SF now, for the conference. Any idea how to identify Jakarta group? I've only met a couple in person before. Marc Saegesser -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED]] Sent: Saturday, March 23, 2002 1:36 AM To: Jakarta General List Subject: Re: JakartaOne: The Gathering OK, we need to make a decision, pronto! Let's meet at 21st Amendment (563 2nd Street) at 7:30pm on Monday. We can take the rest from there. Martin. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 22, 2002 11:24 AM Subject: Re: JakartaOne: The Gathering Jon, can you suggest a place that isn't too far away from Moscone that has a large bar (with real beer...) we can gather in, with a reasonably-priced restaurant that we can then have dinner in? Cuisine can be anything, but a 'normal' american upscale bar menu might be the most appealing to the majority. How about Monday or Wed night? How about the Thirsty Bear? I don't know anything about the place - isn't that where the Jboss people are holding court? Soapy Bear is horrid- they clean their tubes badly, use too much detergent when they do, and as a result you get old yeast and other crap. Always a headache the next day. I'd also be against the Irish place - too noisy to talk :-) Other near by ones which are good to OK IMHO, have good beer and good food are and are quiet enough to talk: Rickenbacher bar; 2nd and mission 21st Amendment; 2nd 2 blocks down. Dw -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [DRAFT1] Jakarta Newsletter - June 2002
-Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED]] Sent: Monday, July 01, 2002 6:18 AM To: Jakarta General List Subject: Re: [DRAFT1] Jakarta Newsletter - June 2002 The Url no works. Nice job though [from the email]. Wonder when there'll be a drive for a separate mail list just for the newsletter, or to send it to the announce list. How about now? ;-) For people who are not necessarily involved with Jakarta, but want to keep tabs on what's going on here, I think either of these would be good. I don't have a strong preference for one or the other. A separate list is commonly used for newsletters elsewhere, but then again, people who want to keep tabs on what's going on here are likely to be subscribed to announcements@ already. -- Martin Cooper Hen Jakarta Newsletter == Issue: 1 Date: June 2002 URL: http://jakarta.apache.org/newletter/200206.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Fw: Jakarta Newsletter
+1 -Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Sent: Monday, July 01, 2002 7:56 AM To: Jakarta General List Subject: Re: Fw: Jakarta Newsletter Any thoughts / preferences? or do we stick with Jakarta Newsletter? Rob Jakarta Newsletter informs on what it is and at a quick glance I have a great idea what to expect from it. Jakarta Jist, or some other monkier while it may be viewed as catchier it may not strike an immediate flame of recognition, especially those who do not have the relevant experience with Western or Anglo-derivative cultures. Thats the best feedback I can give on that. Lets paint the bikeshed yellow, with the word bike shed on the side of it, so that people will see it and understand its function. -Andy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Poll result] Committers, who are we?
-Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 19, 2002 9:56 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [Poll result] Committers, who are we? Hi, A week ago, I have sent an email to all Apache committers. I was curious to know who the other committers where, whether they shared the same beliefs I have, etc. I have posted the questions I sent and the results here: http://jakarta.apache.org/~vmassol/whoarewepoll/docs/site/poll /poll.html I haven't done any analysis yet of the results. Do you think there are any useful analysis that can be made out of this? Does it make you react in any way? My initial reaction is that, with responses from only around 1 in 7 committers, we shouldn't be drawing any big conclusions from the data collected. ;-) -- Martin Cooper ATM, I have posted this on my own jakarta web page. However, I you think it is worthwhile, we could add it to the jakarta/xml/etc main web site, so that others can get a feeling of what to expect and what kind of persons the existing committers are. For jakarta, we could put a link to that page on http://jakarta.apache.org/site/whoweare.html Comments? Thanks -Vincent ___ Vincent Massol Managing Director OCTO Technology UK Ltd http://www.octo.com [EMAIL PROTECTED] Tel: +44 208 996 9540 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Poll result] Committers, who are we?
-Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 6:49 AM To: Jakarta General List Subject: Re: [Poll result] Committers, who are we? I'd be more interested to hear statistics on how many people are California-based versus non-California based. Isn't that covered by 3c, I'm fluent but I live in a non-English speaking country? ;-) I guess you're looking for more detail, though... -- Martin Cooper (It would help me with my research into Apache cultures and cliches ;-) for a paper I'm writing ) On Fri, 2002-10-04 at 08:41, Jeff Turner wrote: Carnegie Mellon did a survey of ~300 Apache developers (56 committers) a while ago, and posted interim results to respondents last month. With the permission of the researcher, here are some stats: On Thu, Oct 03, 2002 at 03:35:18PM +0100, Danny Angus wrote: Vincent Massol once wrote: I was curious to know who the other committers where, whether they shared the same beliefs I have, etc. This prompted me to wonder: 1/ are we.. a)male b)female 98.89% male 1.11% female 2/are we a) young b) 20-30 c) 30-40 d) 40-50 d) old 19 : 1.1% 20-29 : 50.55% 30-39 : 41.03% 40-49 : 6.59% 50 : 0.73% 3/about English a)its my native language b)its a second language, I live in an English speaking country c)I'm fluent but I live in a non-English speaking country d)other, tell me.. Strangely they didn't ask this. However, 90% of people come from what I hazily regard as English speaking countries (US, England, Aus, NZ). 4/do we have a)a full beard b)a goatee c)a moustache d)noneoftheabove 5/wear sandals a)never b)sometimes c)always Nor did they ask these, missing a golden opportunity to come up with an identikit-style portait of J Random Apache Hacker. The person running the survey is Jeff Roberts (jroberts at andrew.cmu.edu). --Jeff d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com - software solutions for business http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in Java http://krysalis.sourceforge.net/centipede - the best build/project structure a guy/gal could have! - Make Ant simple on complex Projects! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Differences between Structs and Turbine ???
-Original Message-
From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 07, 2002 5:28 PM
To: [EMAIL PROTECTED]
Subject: Re: Differences between Structs and Turbine ???
Actually, yes.
Here is the specific reason(s):
http://jakarta.apache.org/velocity/ymtd/ymtd-saying-hello.html
Of course, I know Velocity fans won't like this any better, but if you bring
the JSP example on that page up to date, using JSTL, you'll have this:
html
headtitleHello/title/head
body
h1
c:choose
c:when test=${empty param.name}
Hello World
/c:when
c:otherwise
Hello, c:out value=${param.name}/
/c:otherwise
/c:choose
/h1
/body/html
No hoops to jump through any more.
--
Martin Cooper
Most specifically, if you want to make the word doesn't in
the example
below bold...now, you have embedded HTML into your
println...and we know it
isn't MVC to embed HTML into Java code, right?
#if ($foo)
Andy bdoesn't/b think its good
#end
Of course I wrote the YMTD document so that we don't have to
have these same
discussions over and over again.
-jon
--
StudioZ.tv /\ Bar/Nightclub/Entertainment
314 11th Street @ Folsom /\ San Francisco
http://studioz.tv/
on 2002/10/7 5:13 PM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
And to resurface the old issue, this is so much worse than
#if (..)
#end
in Velocity...?
--
dIon Gillard, Multitask Consulting
Work: http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers
Andrew C. Oliver [EMAIL PROTECTED] wrote on
08/10/2002 09:50:15 AM:
Right...my problem with JSP isn't its dogged speed its the
conceptual
nastiness of it.
%
if (you.have(this).in.your(html)) {
out.println(Andy doesn't think its good);
}
%
-Andy
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Differences between Structs and Turbine ???
-Original Message-
From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 07, 2002 6:04 PM
To: [EMAIL PROTECTED]
Subject: Re: Differences between Structs and Turbine ???
on 2002/10/7 5:41 PM, Martin Cooper
[EMAIL PROTECTED] wrote:
Of course, I know Velocity fans won't like this any better,
but if you bring
the JSP example on that page up to date, using JSTL, you'll
have this:
c:choose
c:when test=${empty param.name}
Hello World
/c:when
c:otherwise
Hello, c:out value=${param.name}/
/c:otherwise
/c:choose
I dunno about you, but I would much rather teach my
non-programmer designers
to type:
#if ($foo)
Hello, $foo
#else
Hello World
#end
You mean this, taken from the page, don't you?
html
headtitleHello/title/head
body
h1
#if ($request.getParameter(name) == null)
Hello World
#else
Hello, $request.getParameter(name)
#end
/h1
/body/html
At least if you're using JSP/JSTL, you don't have to explain method calls to
your non-programmer designers.
Than the bunch of pseudo XML programming language junk you quoted
above...ouch, my hands hurt just looking at that...oh wait, people are
supposed to use GUI drag and drop for all of that
stuff...yea...right...
Oh yea, should I mention that Velocity syntax has remained
unchanged since
it was first released as 1.0 (back in April 2001)? I wonder
how many times
JSP/JSTL/Struts/FooBar syntax will need to be brought 'up to date'...
I see no syntax changes, only new tags and attributes.
--
Martin Cooper
WAKE UP PEOPLE.
-jon
--
StudioZ.tv /\ Bar/Nightclub/Entertainment
314 11th Street @ Folsom /\ San Francisco
http://studioz.tv/
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Differences between Structs and Turbine ???
-Original Message-
From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 07, 2002 7:10 PM
To: [EMAIL PROTECTED]
Subject: Re: Differences between Structs and Turbine ???
snip/
The above could just as easily be written as:
html
headtitleHello/title/head
body
h1
#if (!$name)
Hello World
#else
Hello, $name
#end
/h1
/body/html
Ah, well that looks a bit better than what is promoted as the Velocity way
at the link you provided. You might want to update that page, along with an
update to the JSP/JSTL way of doing things, if you're serious about
providing a comparison.
No method calls. Let's see how easy you can make the JSTL equivalent.
I see no syntax changes, only new tags and attributes.
Actually, the syntax changed quite a lot...a simple if
statement went from
a single element (which made no sense) to a multiple element
syntax (clearly
to support what XSLT doeswhich IMHO only complicates
things even further
because XSLT is even further above what most designers understand...):
from:
logic:notPresent parameter=name
to:
c:choose
c:when test=${empty param.name}
The language syntax did not change at all. What did change was the way in
which the page developer elected to perform a given task. He/she had the
choice of which syntax to use. Of course, you're going to tell me that that
is something that never happens with Velocity...
What does c stand for? Oh wait...explain that to your
designers.
Gee, Jon, I was led to believe you are a smart guy... You can specify
whatever prefix you want, so if you want to use tags like:
jonHatesJsp:out value=Jon is God/
you are perfectly free to do so.
Also, I
believe you forgot a bunch of other junk that you have to put
at the top of
the file or in configuration files to configure what c means anyway.
A bunch of junk? One line:
%@ taglib prefix=c uri=http://java.sun.com/jstl/core; %
Oh, and it's real hard to change 'c' to 'core' or whatever you want it to
be...
It is quite funny to me to see you try to justify something that is
obviously more difficult to understand and write.
I'm not trying to justify anything. I'm happy using what I'm using, and
thousands of other people are too. If you're happy using what you're using,
that's cool too.
I find it even more amusing to see you try to defend
-jon
--
StudioZ.tv /\ Bar/Nightclub/Entertainment
314 11th Street @ Folsom /\ San Francisco
http://studioz.tv/
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PROPOSAL] Tapestry joins Jakarta
-Original Message- From: Jon Scott Stevens [mailto:jon;latchkey.com] Sent: Saturday, October 19, 2002 4:40 PM To: [EMAIL PROTECTED] Subject: Re: [PROPOSAL] Tapestry joins Jakarta on 2002/10/19 4:22 PM, Pier Fumagalli [EMAIL PROTECTED] wrote: I want to start a new project for a new Servlet Container that is not Tomcat! :-) Let's see how many fans I'm going to get! :-) Pier Yea, let's see if we can move Jetty under Jakarta. If you use a Turbine to provide enough Torque, you might be able to Slide it in at Jetspeed, too. ;-) -- Martin Cooper =) -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org
RE: Adding Lists to EyeBrowse - how?
-Original Message- From: Peter Donald [mailto:peter;apache.org] Sent: Tuesday, October 29, 2002 11:42 PM To: Jakarta General List Subject: Re: Adding Lists to EyeBrowse - how? On Wed, 30 Oct 2002 18:32, Daniel Rall wrote: I'm actually working on updating nagoya to the latest Eyebrowse code ... drastically increases the performance of the ViewLists servlet. Woooh! +1. ;-) -- Martin Cooper -- Cheers, Peter Donald Duct tape is like the force. It has a light side, and a dark side, and it binds the universe together ... -- Carl Zwanzig -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org
RE: New Jakarta logo to push live
-Original Message- From: Arnaud HERITIER [mailto:aheritier;sopragroup.com] Sent: Wednesday, November 06, 2002 9:24 AM To: 'Jakarta General List' Subject: RE: New Jakarta logo to push live Yes : http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-site2/doc s/images/logos /jakarta-logo.png What happens to people whose systems don't support png format? -- Martin Cooper Arnaud -Message d'origine- De : [EMAIL PROTECTED] [mailto:dion;multitask.com.au] Envoye : mercredi 6 novembre 2002 18:31 A : Jakarta General List Objet : Re: New Jakarta logo to push live Is there a version with a transparent background? -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers Nicola Ken Barozzi [EMAIL PROTECTED] wrote on 07/11/2002 12:24:22 AM: To make the Jakarta Logo more evident in the affiliation to Apache, and to make it nicer, we've made a new version of it, similar to the one on www.apache.org. There have been comments on the general list about it, and I've committed the results, which it seems we all agree on, in the jakarta-site2 CVS module. There is a normal version (gifsvg), a special blue-background version for Maven sites (gifsvg), and png version with trasparent background. http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta- site2/xdocs/images/jakarta-logo.gif?rev=HEADcontent-type=image/gif http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta- site2/xdocs/images/jakarta-logo-blue.gif?rev=HEADcontent-type =image/gif Can someone please push it live? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org ForwardSourceID:NT0008B2AA -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org
RE: Mozilla mail filters
-Original Message- From: Stéphane MOR [mailto:stephane_listes;yahoo.fr] Sent: Friday, November 15, 2002 10:57 AM To: Jakarta General List Subject: Re: Mozilla mail filters Pier Fumagalli wrote: On 15/11/02 0:50 Stéphane MOR [EMAIL PROTECTED] wrote: I think we could link to the file from the Mailing Lists section of jakarta-site2. Any thoughts ? Yes, start using news.betaversion.org (which will move to news.apache.org once I'm over my friggin deadline), which works with mozilla and filters messages for you (and expires them after one month so that you won't clog up your local cache)... Why not but how ? Try your favourite news reader. -- Martin Cooper The only thing that I see when pointing my browser to news.betaversion.org is the default welcome page of Apache ... Am I supposed to use mozilla mail, or ??? Thanx for any pointers. Stéphane Pier -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org
Re: FYI: Follow up on the XML'ization of MS Office 11
On Tue, 17 Dec 2002, Henri Yandell wrote: On Tue, 17 Dec 2002, Jon Scott Stevens wrote: on 2002/12/17 10:22 AM, Brian Ewins [EMAIL PROTECTED] wrote: This is old news I but I just saw it today: there's a tool that can convert word 2000 docs (saved as html) to an xml doc and an xsl-t script to generate xsl:fo - and from there to PDF. http://www-uk.hpl.hp.com/people/fabgia/wh2fo/wh2fo.html Very nice trick. On OSX you can simply save as a PDF when you print the document. No XML needed. Get a Mac. You'd be amazed how quickly you take this for granted. I quite happily tell people to send it to me in PDF format. Before I got a mac I used to view PDF as some proprietary, impossible to create nasty thing. Seems as if most of Jakarta use OS X now. Is it just that us X-junkies are loud and proud about it? Yep. ;-) -- Martin Cooper Hen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [discussion] jakarta-gump as community property
+1 Not sure what I could help with, but ping me if you think of something. ;-) -- Martin Cooper On Thu, 19 Dec 2002, Sam Ruby wrote: Gump is now two years old. It has had contributions from over a dozen people, about a half-dozen this month alone. There seems to be a renewed interest in gump (some in response to a little nudging grin). Considering all of this, what I would like to propose is that the contents of jakarta-alexandria/proposal/gump get moved to jakarta-gump, all committers to any jakarta code base be given karma and voting rights on the full contents (descriptors, code, and stylesheets alike) and that a single [EMAIL PROTECTED] mailing be created (we are all devs here, right?) Thoughts? - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Forum Software.
On Wed, 22 Jan 2003, Costin Manolache wrote: James Mitchell wrote: So the suggestion is: All Users lists become forums. Developer lists stay. I will fight to my dying breath to make sure this DOESN'T happen (with what little persuation I can muster). I have come to rely deeply on these lists. +1 +1 Omigosh! I just agreed with Costin! I spend my offline hours (daily commute, boring meetings, vacations, etc) going over the list discussions. I have accumulated a large amount of data that I transform into documentation just from this single source of knowledge transfer. PLEASE PLEASE PLEASE DON'T DO THIS! Same here. +1 Twice in one message! What's the world coming to? ;-) -- Martin Cooper Costin Only problem I see there is that Developers won't check the forums as much as they should, unless the Users forum has a mail list interface. Hen On Wed, 22 Jan 2003, Robert Simmons wrote: Well, once again I would like to bring up the concept of forum software for Jakarta. The reason I am bringing it up again is that mailing lists are intrusive and spammy. Daily I get flooded with a ton of email that I have absolutely no interest in reading. However if I unsubscribe to the lists than when there is something that I would like to know about or answer, I will miss it. In addition, if I unsubscribe I'm not able to post my own issues. With a mailing list, the communication mechanism is just too intrusive. On a forum I can pick and choose what I want to read and reply to. As for them being used, its a simple matter of retiring mailing lists for forum software. When we consider that at least 90% of Jakarta users are not Jakarta developers but will often have a question or an important insight, than the folly of communicating only in mailing lists becomes clear. -- Robert Simmons -- James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org/ The man who does not read good books has no advantage over the man who cannot read them. - Mark Twain (1835-1910) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Apache/Jakarta @ JavaOne?
On Sat, 31 May 2003, Mark Womack - Apache wrote: Are there any official or unofficial Jakarta/Apache activities planned around the JavaOne conference in SF? There's a Struts gathering after the conference finishes on Friday, but other than that, I'm not aware of any. Last year, we had a Jakarta get-together in a bar one evening, at which I enjoyed chatting and putting faces to names, and I'd certainly be up for something similar this year. I'm afraid I don't have cycles to help set it up this time around, but if someone else does, I'll most likely show up. ;-) -- Martin Cooper -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mail2.html - mail.html
On Sun, 20 Jul 2003, Michael Davey wrote: Tetsuya Kitahata wrote: No, my original intention was derived from just this simple question: Why doesn't each subprojects' left-side navi point to the *appropriate* section in mail2.html? I was dead against this when Tetsuya first raised the issue, but I think Like Danny, I still am. I am coming round to Tetsuya's way of thinking. Perhaps ezmlm could be changed so that the confirm subscription and welcome email messages start with some text similar to that used on the mail.html page. I'm sure it could. But people would completely ignore that text. That's exactly the point of having mail and mail2 separated as they are. Additionally, the -dev lists could warn that -user should be used for questions including developer questions, where appropriate. Some Apache lists already do one or both of these, but many don't do either. You mean the lists themselves, or the people on them? The struts-dev list gets a fair number of messages that should have been sent to struts-user instead, and it's really pretty annoying. The more we can do to get people to use the right list in the first place, the better. Hopefully few novices will be inclined to post to a list without first subscribing They may subscribe, but they are also likely to ignore any instructions they are given, even if those instructions are repeated at the end of every message to the list. How many times have you seen unsubscribe messages on lists whose message footers include the instructions? (I know that many here do post to lists to which they aren't subscribed, which is fine as they aren't new to the community, so they know what to do and what not to do). In any case, I don't think we can protect ourselves completely from fools ;) Sad but true. ;-( -- Martin Cooper -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] HiveMind Service Framework
Accepting this proposal as currently written would also involve the acceptance of five new individuals as Apache committers. Based on where the HiveMind repo currently is/was, that implies giving five unknowns (to me, anyway) access to Jakarta Commons as a whole. I'm not so sure I'd be willing to sign up for that. -- Martin Cooper On Tue, 11 Nov 2003, Nayak, Prashant wrote: Proposal for the HiveMind Project (0) Rationale HiveMind is a simple framework for creating pluggable, configurable, reusable services. Simple: HiveMind is a way to create a network of services in terms of Java interfaces and classes; it cherry picks the most useful ideas from Service Oriented Architectures such as J2EE, JMX and SOAP, but removes the aspects that are typically overkill for most applications, such as service remoteability and language neutrality. HiveMind creates a natural network of related services and configuration data, all operating within a single JVM. Pluggable: HiveMind enforces a complete separation of service definition and implementation. This is manifested by a division of services into an interface definition and a service implementation as well as a split between defining a service (as part of a HiveMind module) and providing the implementation of that service (potentially, in a different module). Configurable: HiveMind integrates a service oriented architecture to a sophisticated configuration architecture; the configuration architecture is adapted from the Eclipse plug-in model, wherein modules may define configuration extension points and multiple modules may provide contributions to those extension points. Reusable: HiveMind is a framework and container, but not an application. The HiveMind framework and the services it provides may be easily combined with application-specific services and configurations for use in disparate applications. The API for HiveMind allows thread-safe, easy access to services and configurations with a minimal amount of code. The value-add for HiveMind is not just runtime flexibility: it is overall developer productivity. HiveMind systems will entail less code; key functionality that is frequently an after-thought, such as parsing of XML configuration files, logging of method invocations, and lazy creation of services, is handled by the HiveMind framework in a consistent, robust, and well-documented manner. HiveMind fits into an area that partially overlaps the Apache Avalon project, with significant differences. HiveMind's concept of a distributed configuration is unique among the available service microkernel's (Avalon, Keel, Spring, Picocontainer, etc.). Avalon is firmly rooted in a type-1 inversion of control pattern (whereby services must explicitly, in code, resolve dependencies between each other using a lookup pattern similar to JNDI). HiveMind uses a mix of type-2 and type-3 IoC, whereby the framework (acting as container) creates connections between services by setting properties of the services (type-2) or making use of particular constructors for the services (type-3). HiveMind represents a generous donation of code to the ASF by WebCT (http://www.webct.com). HiveMind originated from internal requirements for a flexible, loosely-coupled configuration management and services framework for WebCT's industry-leading flagship enterprise e-learning product, Vista. Several individuals in WebCT's research and development team in addition to Mr. Howard Lewis Ship contributed to the requirements and concepts behind HiveMind's current set of functionality including Martin Bayly, Diane Bennett, Bill Bilic, Michael Kerr, Prashant Nayak, Bill Richard and Ajay Sharda. HiveMind is already in use as a significant part of Vista. (1) Scope of the package The package shall entail a core framework JAR (containing essential classes and services), a standard library JAR (containing generically useful services), along with ancillary artifacts such as Maven plug-ins and, of course, documentation, all distributed under the Apache Software License. (1.1) Interaction with other packages HiveMind has dependencies on several standard commons packages, including: commons-lang, commons-beanutils, commons-collections and commons-logging. HiveMind makes use of the Javassist bytecode generation library, which is available under the MPL (Mozilla public license). (2) Identify the initial source for the package The initial code base has been developed by Howard M. Lewis Ship within the Jakarta Commons incubator. http://jakarta.apache.org/commons/sandbox/hivemind (2.1) Identify the base name for the package org.apache.hivemind Note: the current code base reflects an alternate package name, org.apache.commons.hivemind. Subsequent research has shown that HiveMind is not a suitable candidate for the Jakarta Commons. The existing code base will be migrated to the new package during the transition out
Re: [NOTICE] to all jakarta committers
On Thu, 13 Nov 2003, robert burrell donkin wrote: will all jakarta committers please ensure that there apache.org email account is set up so that it forwards mail to an account that they read. Or, if not forwarded, please ensure that you read mail to your Apache account. For example, you can ssh to minotaur and read it using pine. -- Martin Cooper this is very easy to configure - just log on to cvs.apache.org using ssh and then edit the .forward file. (one way to do this is to use vi. type vi .forward type i then your normal email address next press ESC :x ENTER.) official mail from the ASF is directed to your apache.org email account. you need to be able to read it. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOTICE] to all jakarta committers
On Thu, 14 Nov 2003, Stefan Bodewig wrote: On Thu, 13 Nov 2003, Martin Cooper [EMAIL PROTECTED] wrote: Or, if not forwarded, please ensure that you read mail to your Apache account. For example, you can ssh to minotaur and read it using pine. Which you'll be unable to do if your account has to be locked because of a security incident. And the mail that explained that to you would be in your @apache.org mbox. Happenend two and a half years ago.[1] Good point. The reason I do read my mail on minotaur directly is so that I have one place I can go, from home, work or elsewhere, to read it and, more particularly, store it. POP doesn't help me, web clients suck, and I'm too cheap to pay for access to an IMAP server or whatever. ;-) -- Martin Cooper I'd recommend forwarding. Stefan Footnotes: [1] http://www.apache.org/info/20010519-hack.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New project proposal -- Html4Java
On Mon, 17 Nov 2003, Mike Goudie wrote: None of those is what I had in mind. I was thinking of something more like this: http://www.sapdesignguild.org/resources/htmlb_guidance/index.html --1. Introduction --* What is HTMLB? That sounds almost exactly like JSF to me (except that JSF doesn't prevent you from using JavaScript to manipulate controls), so I must be missing something fundamental. Could you elaborate, please? -- Martin Cooper Original Message --- Also there's JSF, which also seems to be leaning into attempts to make web creation like gui creation: http://java.sun.com/j2ee/javaserverfaces/ Hen On Mon, 17 Nov 2003, Danny Angus wrote: Sounds interesting, but have you seen ECS? http://jakarta.apache.org/ecs/index.html And for something more weighty in the realm of component architecture for web-pages there's Tapestry http://jakarta.apache.org/tapestry *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Lim ited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
On Mon, 1 Dec 2003, Henning Schmiedehausen wrote: [I like Turbineers. :-) ] I am one of them, and I did some discussion about JCS @ ApacheCon with Martin Poeschl (who seems to do the odd fix to JCS because he uses it in Torque), another Turbineer. We basically were came to the same conclusion as robert: - JCS is cute and should have a larger exposure - JCS isn't related at all to Turbine. At most it is related to Torque - JCS could be moved to db.apache.org but it is not really database specific - There is (almost) no resistance to move this project out of Turbine. So my vote is --8 (comments here, please) --8 [ ] leave it within turbine [ ] move it to apache commons [X] move it to jakarta commons [ ] move it to incubator [ ] something else (please specify)... If JCS really catches on, we can still move it back to Jakarta as Jakarta JCS. This all makes sense to me, and coming from a Turbineer, it's something I would support. It might even provide a path to resolution for what we do with Commons Cache, which is currently in a coma (at best)... -- Martin Cooper Regards Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PMC membership : I fear additional responsibility
On Sat, 20 Dec 2003, Geir Magnusson Jr wrote: I want to share a conversation that I hope sheds some light on what it means to be on the PMC. I was talking to a friend yesterday who said I fear additional responsibility. I told him that he should have nothing to fear, as what's being asked for is that the committers simply continue to pay attention. His response was paying attention is a _big_ responsibility That's true, I thought. So I told him but if you are interested in the project you are going to do that anyway. IOW, most committers are paying attention to what's coming in jakarta is just so big though Aha! Being on the PMC doesn't mean you have to watch *every* commit in *every* project. The requirement of the PMC is that it, as a committee delegated oversight authority by the board, is responsible as a *group* for that oversight. If we can organize ourselves so that there is coverage that to an outside observer would be deemed reasonable and effective, then we satisfy the needs of the ASF. (The board could void this interpretation, but so far has indicated that it wouldn't). If a PMC member doesn't watch every commit in every project - as surely few, if any, do - s/he needs to at least have trust in enough other PMC members to cover the projects s/he is not involved with. Because, as a PMC member, s/he is still responsible for decisions made by the PMC. That's a good deal of trust to place in others s/he might not encounter anywhere other than on the [EMAIL PROTECTED] list. -- Martin Cooper So this person, who participates in foo and some components of Jakarta Commons, would just continue to do what he normally does - participate as he does already. The only difference is that we would do our job and ensure that he understands the rules about contributions, CLAs, and what code contributions require the Incubator for IP accountability. ( Incubator = Largish contributions from outside of the ASF. Largish is loosely defined : Small patch- and file-sized commits and contributions don't need Incubator, an entire database project from Oracle does. The line is somewhere in the middle :) Anyway, I hope this example helps. It certainly gave me insight into what this individual was struggling with, and I assume that he isn't the only one... geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
On Tue, 30 Dec 2003, Ted Husted wrote: - Original message From: Geir Magnusson Jr. [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 16:05:11 -0500 Subject: Re: [PROPOSAL] Proactively encourage TLP status SNIP/ I never understand why you keep doing this. There is no 'schism' between the PMC and the community, and no one is proposing it. I hate to appeal to authority because the ASF charter does provide a healthy bit of freedom for any given PMC, but for example, if we want to follow the model of the httpd project, from which the ASF bylaws were fashioned, and I know you are a vocal proponent of the 'ASF Way', it is my understanding they invite committers onto the PMC after some time after receiving committership when it's clear that is appropriate for that person. Committing != oversight. There are people who are committers that may not wish to participate on the PMC. We want everyone to, but if they aren't *interested* in doing it, putting them on the PMC achieves nothing, and actually, IMO, weakens the PMC. There are all sorts of valid reasons to not want to be on the PMC, I suppose, and we should never stop inviting that person. 100% should be the goal, not the requirement. The schism is that the PMC did not elect our committers. In the normal course, the body that elects the committers also decides which committers (or other interested parties) merit inclusion in the PMC. However, Jakarta has not done things in the normal course. The PMC did not select most of the committers: the subproject communities did. And when our community selected the committers they expected that these individuals would be the ones actively managing the codebase. The community expected these individuals to have the rights and responsibilities we now abscribe only to the PMC. This doesn't seem quite right to me. I agree that when we have voted in a new committer, both the existing committers and the new committer have had the same expectations with respect to their rights and responsibilities *within the sub-project*. While those rights and responsibilities may be the same ones that apply to members of the PMC, the domain over which they apply is very different. I don't think it would be right to turn around now, and tell a committer on sub-project X oh, by the way, you're now part of the PMC and that means that you are (collectively) responsible for all of Jakarta. That doesn't meet the expectations *I* originally had at all, when I first became a Jakarta committer myself. Foisting additional responsibility on committers doesn't seem like the right way to go, to me. Allowing - even encouraging - them to take on the additional responibilities of a PMC member would fit much better with *my* original expectations, at least. -- Martin Cooper I believe from the ASF perspective committing==voting and committing==oversight Every time a committer commits, they vote for the code they commit. Most often, it a vote subject to lazy consensus, and in rare cases it might not be binding. But, it is vote nonetheless. Every time a committer commits, they either donate code to the ASF or facilitate a donation, and they incur the obligation to ensure, to the best of their ability, that this is IP that can be donated to the ASF. If we have a committer that does not accept these obligations, then a misunderstanding has occurred, and such committers should step down. The ASF does not grant write-access lightly. I think people understand that. In the normal course, virtually all ASF committers are PMC members, because its the committers make the decisions and do the work. It is true that on occasion an ASF committer will not yet be member of the project PMC. Their votes may not be binding, and their commits will be scrutinized by PMC members (which is to say other members of the development team). But, in due course, the PMC that made them a committer also makes them a member. When our community elected all of our committers, it was with the understanding that they were the ones with binding votes, that they were the decision makers, that the Jakarta Committers were, in practice, the Jakarta PMC. In my humble opinion, it is the duty of the PMC to now ratify the decisions our community has already made. Since we now know that the PMC is *not* a steering committee and is in fact the active managers of the codebase, we are obligated to finish the job our community started: give the committers the legal rights and responsibility that we always believed they already had. Make the committers the PMC, because they are the only true PMC that we have ever had. Each and every one of our committers have earned their stripe. They have all proven to the community that they are thoughtful, responsible self-starters capable of managing our codebase
Re: [VOTE] HiveMind as a Jakarta sub-project
On Wed, 3 Mar 2004, Geir Magnusson Jr wrote: [X] +1 I support this proposal [ ] -1 I don't support this proposal [ ] 0 I abstain from voting for or against this proposal -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Tapestry 3.0 rc1 released
On Wed, 17 Mar 2004, Erik Hatcher wrote: Yes, on the tapestry-dev list at the top of the Votes section here: http://jakarta.apache.org/tapestry/changes.html Are we supposed to get releases approved by the PMC? Well, technically, it is only PMC members who can vote. ;-) However, the working model we are using allows the sub-project committers to make the decision, but the PMC needs to be notified of the vote result, preferably including a link to the vote thread on the project's -dev list. -- Martin Cooper On Mar 17, 2004, at 6:47 PM, [EMAIL PROTECTED] wrote: Was there a vote for it? -- dIon Gillard, Multitask Consulting Harish Krishnaswamy [EMAIL PROTECTED] wrote on 17/03/2004 11:55:38 PM: Tapestry 3.0 Release Candidate 1 has been released. -Harish - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to place LICENSE file in a jar?
I recall reading somewhere that the desired location is such that they would show up at the top of a listing. That suggests that they should be in the root directory. On the other hand, META-INF seems more logical, IMHO. -- Martin Cooper On Tue, 16 Mar 2004, Martin Holz wrote: Hello, if I put the LICENSE and NOTICE file into a jar archive, where should it go? To META-INF or into the root directory? Regards Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apache XML federation
This is something we at Jakarta should probably keep our eyes on: http://article.gmane.org/gmane.comp.apache.incubator.general/3103 It's going to be interesting to watch this process, I think, and see how well it works. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts mailing lists
On Thu, 1 Apr 2004, Shapira, Yoav wrote: Hi, I assume the website is about to be updated with this information? I tried to email [EMAIL PROTECTED], but typically, heh, the recipients mail server was down or unreachable ([EMAIL PROTECTED]). Send a note to the struts-dev list, they're responsible for updating their own website. Don't rely on the webmaster@ address ;) The web site will be updated, and a message will also be sent to the lists. I've been waiting for the wiki to be fully set up, so that one set of changes and one announcement are all that's necessary, rather than one for each set of changes. The problem is that nobody with the appropriate privileges seems to have any time to move over some pages from the old wiki to the new one. I've been waiting patiently since March 24th. (INFRA-51 on Jira, for anyone with privs and a few minutes! ;) -- Martin Cooper Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts mailing lists
-Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED] Sent: Thursday, April 01, 2004 11:02 PM To: Jakarta General List Subject: RE: Struts mailing lists I've been waiting for the wiki to be fully set up The problem is that nobody with the appropriate privileges seems to have any time to move over some pages from the old wiki to the new one. If all that is missing is karma, write a shell script with a list of mv commands, and put it in your home directory. Then add it as a request. Sure. Just as soon as I figure out how to write *nix shell scripts... It is easier, and faster, to review a list of mv commands for pages than to hunt up the data. OK, so the list of 'mv' commands consists of: http://nagoya.apache.org/jira/browse/INFRA-51 -- Martin Cooper --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts mailing lists
On Thu, 1 Apr 2004, Martin Cooper wrote: -Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED] Sent: Thursday, April 01, 2004 11:02 PM To: Jakarta General List Subject: RE: Struts mailing lists I've been waiting for the wiki to be fully set up The problem is that nobody with the appropriate privileges seems to have any time to move over some pages from the old wiki to the new one. If all that is missing is karma, write a shell script with a list of mv commands, and put it in your home directory. Then add it as a request. Sure. Just as soon as I figure out how to write *nix shell scripts... It is easier, and faster, to review a list of mv commands for pages than to hunt up the data. OK, so the list of 'mv' commands consists of: http://nagoya.apache.org/jira/browse/INFRA-51 I can't believe I actually sent that! What a major cut-and-paste-o! Anyway, it's been pointed out to me (thanks, sebb!) that the perms on the directory have changed from when I first tried this, and now I can do it myself, so I have. :-) -- Martin Cooper -- Martin Cooper --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [site] thinking about adding a couple of links from resources
-Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 06, 2004 2:03 PM To: Jakarta General List Subject: [site] thinking about adding a couple of links from resources in the light of the recent debate over on licensing about the inability for java folks to take their jakarta fix in the usual packaged/ported *nix fashion For the benefit of those of us not on licensing@, could you, or someone else, summarise that debate briefly, please? That list doesn't appear to be in public archives. (I'm on license@, which is publicly archived - I didn't realise there were two separate lists.) TIA. -- Martin Cooper , i thought i might add links to a couple of well-known downstream distributors of packages and ports to the resources (unofficial) section: http://www.jpackage.org/ http://www.freebsd.org/ports/java.html comments anyone? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why wiki logs to [EMAIL PROTECTED] -- site-cvs@ might be better
On Thu, 8 Jul 2004, Tetsuya Kitahata wrote: Hi, Why wiki log (diff) messages would have occupied [EMAIL PROTECTED] It seems appropriate to me, since these messages are notifications of changes to the general (sic) Jakarta wiki. The folks on general@ seem like the right crowd to watch what's going on there, and spot any inappropriate changes. -- [EMAIL PROTECTED] might be better and I could suggest, I think. I'm not sure I see why site-cvs@ would be better. Can you elaborate? I'm also not sure who is on that list, since it doesn't seem to come with site2 karma. I think we'd want the changes to go to a wider group in any case. -- Martin Cooper What would you think? Thanks, - Tetsuya Kitahata -- Terra-International (Independent) E-mail: [EMAIL PROTECTED] http://www.terra-intl.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why wiki logs to [EMAIL PROTECTED] -- site-cvs@ might be better
On Thu, 8 Jul 2004, Tetsuya Kitahata wrote: Hi, Martin Cooper wrote: -- [EMAIL PROTECTED] might be better and I could suggest, I think. I'm not sure I see why site-cvs@ would be better. Can you elaborate? I'm also not sure who is on that list, since it doesn't seem to come with site2 karma. I think we'd want the changes to go to a wider group in any case. Yes, very simple reason. Compare to ws.apache.org (I mean, webservices @ apache). In ws.apache.org, every cvs commit logs go to [EMAIL PROTECTED] (see the logs @ eyebrowse / nagoya.apache) On the other hand, in jakarta.apache.org, they had not been. They have gone to [EMAIL PROTECTED] (I am not sure why, but I believe it that there WERE very reason for it) Then, I could not understand (then) why wiki commit logs -- similar to cvs commit -- could come to [EMAIL PROTECTED] What i meant is - site-cvs would be rather for the guys who have much concerns in the changes of the websites of jakarta.apache and related -- and who can supervise. I think you are arguing against yourself here. ;-) If the people who can make changes should be the same people doing the monitoring, which seems to be what you are saying, then it makes perfect sense for general@ to review wiki changes, since anyone on that list can make changes to the wiki. Similarly, if site2 karma and site-cvs were tied (but see below), it would make sense for site-cvs folks to be reviewing site2 changes. By the way, it would be needed to join to [EMAIL PROTECTED] list to obtain site2 karma No, it doesn't work that way. I have site2 karma, but am not (and have never been) subscribed to site-cvs. -- Martin Cooper -- Only you should subscribe for posting a message to [EMAIL PROTECTED], if i remember correctly. (I mean, no need to obtain site2 karma) There are about 100 people watching. Sincerely, - Tetsuya Kitahata -- Terra-International (Independent) E-mail: [EMAIL PROTECTED] http://www.terra-intl.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding project version to bugzilla
On Wed, 21 Jul 2004, Shapira, Yoav wrote: Hi, Please remind me what I need to do / whom I need to ask that a new version (e.g. 5.0.26 and 5.0.27 for tomcat) be added to the list in Bugzilla's Version field? Asking here is fine. I've added 5.0.26 and 5.0.27 for Tomcat 5. -- Martin Cooper Thanks, Yoav Shapira Millennium Research Informatics - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Adding project version to bugzilla
-Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Thursday, July 22, 2004 6:00 AM To: Jakarta General List Subject: Re: Adding project version to bugzilla Any idea who the people with access to do this are Martin? Within Jakarta anyway? Apart from the folks who've chimed in, the only other person I know for sure has the right perms is Craig. -- Martin Cooper Hen On Wed, 21 Jul 2004, Martin Cooper wrote: On Wed, 21 Jul 2004, Shapira, Yoav wrote: Hi, Please remind me what I need to do / whom I need to ask that a new version (e.g. 5.0.26 and 5.0.27 for tomcat) be added to the list in Bugzilla's Version field? Asking here is fine. I've added 5.0.26 and 5.0.27 for Tomcat 5. -- Martin Cooper Thanks, Yoav Shapira Millennium Research Informatics - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: md5 checksum formats on BSD
Do you happen to know which flavour Ant creates? For Struts releases, the Ant build file generates the MD5 files using the checksum task. That seems like a pretty obvious way to generate them for any project that uses Ant, but the task doesn't appear to have any switch for determining flavour (and the docs don't appear to say anything about different flavours of MD5). -- Martin Cooper On Wed, 11 Aug 2004 13:06:00 -0400, Mark R. Diggory [EMAIL PROTECTED] wrote: A subject came up on the Tomcat developers list which we thought should be shared with the whole community. Specifically, it was found that BSD's default md5 format is not parsable by some external programs that clients are using to verify the integrity of our downloads. While we thought this not mission critical, we did think it wise that we should begin making the following recommendation when creating md5 signatures for files. We discovered there is a -r option which makes BSD md5 generate md5 signature format that is the same as that of GNU's md5sum, a more prevalent tool for generating checksums of files. We also found that on BSD, cksum is comparable to to GNU's md5sum --check functionality and that it works on both the BSD and GNU file format. Our recommendation is that Apache should be signing with the more prevalent GNU formated output so that other file integrity software available on platforms other than BSD can verify the file integrity more easily. This is simply accomplished by adding the -r option For Example: %md5 -r foo.bar foo.bar.md5 We should remember that md5 signatures are for the public to verify the integrity of our software package distributions. Making sure that everyone can verify our file integrity is probably more important than maintaining a platform specific format because it is the default for the OS these were generated on. -Mark Diggory Mark R. Diggory wrote: For example here are the outputs of the various signing tools we use at this time: BSD md5: md5 commons-collections-3.1.jar MD5 (commons-collections-3.1.jar) = d1dcb0fbee884bb855bb327b8190af36 while the GNU md5 script generates the following: [EMAIL PROTECTED] jars]$ md5sum commons-collections-3.1.jar d1dcb0fbee884bb855bb327b8190af36 commons-collections-3.1.jar And maven just generates and uses: d1dcb0fbee884bb855bb327b8190af36 Yes, the nice thing about BSD md5 is that the -r can be used to make it look like the GNU md5sum output, it would probably be good if we started to use this as it will be more prevalent and possibly is the closest one can get to a standard: md5 -r commons-collections-3.1.jar d1dcb0fbee884bb855bb327b8190af36 commons-collections-3.1.jar Mark R. Diggory wrote: This is the md5 output generated by BSD md5 and not necessarily a standard, GNU md5sum generates a different format that is not standard as well. For maven, just the checksum portion of the content is stored in the file. It would be nice if there was a standard in this area, but I have yet to see one in the internet community. We have the same problem with generating md5 checksums for the maven repository at the moment. -Mark Shapira, Yoav wrote: Hi, The format I use for MD5 sums is the standard one. Every other project I know uses this format, so I think if anything this user needs to adjust his preferences ;) However, if there's a standard or spec somewhere that mandates we use md5 -r (reverse output format), then sure, someone point me to it and I'll follow that spec when signing releases. Yoav Shapira Millennium Research Informatics -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 5:26 AM To: Tomcat Developers List Subject: Re: Fwd: md5 sums for jakarta downloads Pier Fumagalli wrote: Begin forwarded message: From: Andy Mudrak [EMAIL PROTECTED] Date: 10 August 2004 00:57:44 BST To: [EMAIL PROTECTED] Subject: md5 sums for jakarta downloads Hi, I noticed that your MD5 sums on your website are not all formatted correctly. I specifically downloaded the Tomcat 5.0.27 MD5 file, and found this out. Not that it's a big deal or anything like that, but it'd be good to have the MD5 properly formatted, that is the MD5 sum and then the file name... I am not sure that is a good idea: +++ -bash-2.05b$ openssl md5 toto MD5(toto)= efd6b079984c77cd80254ff266e9ab43 +++ And looking in the Jakarta Binary downloads I have found that a lot of other MD5 file are using the Tomcat format. Thanks, Andy Mudrak [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: FYI: Author tags
On Mon, 13 Sep 2004, Henri Yandell wrote: Many will remember the discussion on whether the ASF should discourage, ban or allow @author tags. I'm not sure that the end result was reported out to the whole community, so going ahead and doing so now. Apologies if a repeat. The boards statement (via Sam) is that: Sam: The choice of @authors or not is a PMC level decision. For the benefit of those who were not around at the time, I think it's only fair to include the following official statement that was made by the board: - author tags are officially discouraged. these create difficulties in establishing the proper ownership and the protection of our committers. there are other social issues dealing with collaborative development, but the Board is concerned about the legal ramifications around the use of author tags -- Martin Cooper Many do think that @author tags are not useful, but we're free to do what we want. My opinion: If we ever get subprojects where things are getting childish over @author tags and recognition for fixing newlines or removing unused imports (made up examples), then we should just take the easy way out on that subproject and remove the @author tags. Otherwise, we continue as normal. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS-SVN Was: SVN of ECS
On Sat, 25 Sep 2004 21:25:37 +0100, robert burrell donkin [EMAIL PROTECTED] wrote: On 24 Sep 2004, at 19:55, Henri Yandell wrote: Sounds good to me. ORO's the first to goto SVN then. cool Noel (or any other local to Jakarta infra people), before I go ahead and just make a request, is there a particular process you'd like us to adhere to? given jakarta's large and diverse, i'd say that we need some kind of documented procedure. otherwise, it could get really messy and create a lot of trouble for infrastructure. There is this to start with: http://www.apache.org/dev/cvs2svn.html -- Martin Cooper - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can I use Hibernate in an Apache project without compromising the Apache License?
On Mon, 27 Sep 2004 18:06:09 +0200, Oliver Zeigermann [EMAIL PROTECTED] wrote: OK, I understand I can not check in the jar. But what about having it included in a Maven like build with dynamically downloading it. Theoretically, I suspect you could write such a build target, but you would not be able to distribute the results of such a build. -- Martin Cooper I was wondering if the dynamic linking thing hasn't be explitictely clarified in this: http://www.hibernate.org/196.html Or is the above still not satisfying? Just wondering... Oliver Henri Yandell wrote: Correct. We can't check in LGPL, and I don't believe you can check in code that depends on LGPL. The reason for this is that their interpretation of dynamic linking is debatable and the ASF takes the other side in that debate. The options appear to be to either have a plugin module which depends on the LGPL library and is a java.net or SF project etc, or to find a BSD dependency. Hen On Mon, 27 Sep 2004, Tim O'Brien wrote: AFAIK IANAL, no. Checking in LGPL binaries is not something we can do here. Tim -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Monday, September 27, 2004 2:38 AM To: Jakarta General List Subject: Can I use Hibernate in an Apache project without compromising the Apache License? Folks, I was considering to use Hibernate for persistence in the Slide project. Now, Hibernate is LGPL, but in http://www.hibernate.org/196.html the authors explain their idea of dynamic linking as mentioned in the LGPL text. This looks just fine to me. Additionally, I understand I can even put the jars into the Slide CVS if I include a reference to the license, right? Thanks for any comments in advance, Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS-SVN Was: SVN of ECS
On Tue, 28 Sep 2004 10:32:06 -0400 (EDT), Henri Yandell [EMAIL PROTECTED] wrote: On Tue, 28 Sep 2004, Henning Schmiedehausen wrote: Hi, ok. So this means, once we get e.g. /jakarta/turbine, we could set the repository structure below it just as we see it fit? We (Turbine) currently have (for history reasons) a lot of CVS repositories and consolidating them is a real pet peeve for me. ;-) Yep. My suggestion would be to go with a: /jakarta/turbine/component/tags|branches|trunk|site but that may not fit every subproject. I have a definite Commons view of the world where every component is equal. I'm not sure how commons-sandbox should be handled though. We've been discussing the same subject over at Struts, and one excellent point that Craig brought up is consideration of ease of refactoring / moving code across units of source control. I think this might be an important consideration for Commons as well, in determining whether separation occurs above or below the 'trunk' point in the tree. -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axion / Derby status?
You'd likely get better answers on these if you ask the folks in the incubator, since that is the path into the ASF for both of the projects you're asking about. See: http://incubator.apache.org/ My understanding is that the Axion folks wanted to wait until they're done with their 1.0 release at Tigris before moving the code over. I don't know about Derby. -- Martin Cooper On Thu, 30 Sep 2004 13:11:48 +1000, Mark Livingstone [EMAIL PROTECTED] wrote: Hi Guys, Could someone in the know :-) please tell me what the hold up seems to be with Axion moving into the incubator from it's current Tigris site? From an outsiders perspective nothing seems to be happening. Likewise (as appropriate) for Derby? TIA MarkL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mail list page
On Wed, 1 Dec 2004 10:05:11 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: Couple of questions When are we going to remove projects which have been promoted from Jakarta, from the mail list page? Anyone mind if I do it now? Feel free to remove Struts. -- Martin Cooper The watchdog-dev mail list appears to be gone (which makes sense). Is there a list left for Watchdog, should its entry direct people to [EMAIL PROTECTED] Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new sandbox projects
On Wed, 15 Dec 2004, Torsten Curdt wrote: Hey, folks! Hey Torsten, Over at cocoon we have some code that might be worth sharing on jakarta commons. So I was wondering if the sandbox is open to any committer or only to jakarta committers? (which I am not) I heard different stories... Any Apache committer can have sandbox karma just for the asking. I factored out our javaflow (java continuations) implementation and a java compiler interface (jci) featuring a compiling classloader. Any opinions on hosting that at jakarta commons? Or should we keep that stuff under our umbrella? These sound good to me. I would be +1 for having these in the Commons sandbox. -- Martin Cooper cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new sandbox projects
On Wed, 15 Dec 2004, Torsten Curdt wrote: Any Apache committer can have sandbox karma just for the asking. The only complication is that the committer will need to get the jakarta unix group, so it'll take us a little bit longer to add karma. Any voting needed for the sandbox components? To get in to the Sanbox, no. To get out again, to Commons Proper, yes. ;-) Otherwise it would be great if I could get access to the sandbox so I can move the stuff over. I'll make a request to have you added to the jakarta group. -- Martin Cooper cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Converting Jakarta site and site2 to SVN
+1 to all of the proposals below. -- Martin Cooper On Sat, 18 Dec 2004 13:41:59 -0500, Tim O'Brien [EMAIL PROTECTED] wrote: I'm looking for comments on the following proposal to move jakarta's site module to Subversion. jakarta-site2 CVS will be moved to /jakarta/ /site/ (jakarta-site2 HEAD) I don't think we need trunk, tags, and branches for this module. Anyone disagree? Also, does anyone have any objections to not migrating the jakarta-site module? I believe this module has been unused for 3 years. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] moving jakarta-site2 to subversion
On Sat, 18 Dec 2004 22:39:24 -0500, Tim O'Brien [EMAIL PROTECTED] wrote: This is the simplest SVN migration in Jakarta. The migration instructions follow for review: http://wiki.apache.org/jakarta/Site2_20Conversion_20Instructions 72 hours for this vote - classify this as a public release vote requires majority (at least 3 +1s and more +1s than -1s ) [X] +1, migrate jakarta-site2 CVS to /jakarta/site SVN [ ] +0 [ ] -0 [ ] -1, No -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new sandbox projects
On Tue, 14 Dec 2004 21:52:57 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: On Tue, 14 Dec 2004, Martin Cooper wrote: On Wed, 15 Dec 2004, Torsten Curdt wrote: Over at cocoon we have some code that might be worth sharing on jakarta commons. So I was wondering if the sandbox is open to any committer or only to jakarta committers? (which I am not) I heard different stories... Any Apache committer can have sandbox karma just for the asking. The only complication is that the committer will need to get the jakarta unix group, so it'll take us a little bit longer to add karma. Torsten (tcurdt) is now in the 'jakarta' Unix group. Can someone with karma karma please give him access to the Commons Sandbox? Thanks! -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta CVS modules
On Sun, 26 Dec 2004 12:11:36 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: Partly to do with CVS-SVN and partly to do with figuring out just what we're sitting on top of, here's a review of our CVS structure. The phrase 'needs migration' may just mean that it's already been migrated and needs deletion. jakarta-* = jakarta-jetspeed + jakarta-jetspeed-2 need migration to portals. jakarta-log4j + jakarta-log4j-sandbox need migration to logging. jakarta-ecs2 looks dead. jakarta-ojb needs migration to db. jakarta-pluto needs migration to portals. jakarta-site is dead. jakarta-tools looks dead. Wow, I'd never even heard of -tools before. The only reference I can find to it (or at least to moo) is from watchdog, so we should be able to archive it along with that. Note that Gump is still building this, so we'll need to remove those references first. Additionally, we know we need to archive: jakarta-watchdog jakarta-watchdog-4 jakarta-alexandria On our CVS page, we claim to be looking after the following java-* repositories, but they are no longer in the main cvs.apache.org location: * java-framework * java-icalendar * java-jserv * java-jukebox * java-jyve (dead) * java-jyve2 (dead) * java-mod_java * java-picoserver * java-site * java-spfc * java-ssi * java-utils * java-whiteboard Where did these all go? Have they all been archived already? We should definitely remove all the broken links. -- Martin Cooper Ideally they would be in our archive too. Comments? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: download pages in j.a.o.
On Tue, 28 Dec 2004, Tetsuya Kitahata wrote: Just I've tried to improve the usability of Download Pages in jakarta.a.o. (by Adding Table Of Contents in Release Source Drops section) The problem I have with this change is that it pretty much guarantees that people will completely skip reading anything about the fact that they are downloading from a mirror site, and especially the fact that they need to verify the signature of what they download. If we could put that info before the links, I would be much happier. ;-) -- Martin Cooper http://jakarta.apache.org/site/binindex.cgi http://jakarta.apache.org/site/sourceindex.cgi The migration of CVS repository (jakarta-site2) into SVN had slipped my mind -- very sorry. -- BTW: Perhaps, commons-*** lines can be separated, by creating /commons/binindex.cgi plus commons/sourceindex.cgi and by adding these lines below to .htaccess in jakarta-site2 module (migrated into SVN?). | RedirectMatch ^/site/binindex.cgi#commons-(.*) http://jakarta.apache.org/commons/binindex.cgi#$1 | RedirectMatch ^/site/sourceindex.cgi#commons-(.*) http://jakarta.apache.org/commons/sourceindex.cgi#$1 (... not sure. I am not familiar with RedirectMatch.) Sincerely, - Tetsuya Kitahata -- Terra-International, Inc. E-mail: [EMAIL PROTECTED] http://www.terra-intl.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cleaning up Site2
On Tue, 28 Dec 2004 00:35:08 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: The jakarta-site2 module is horrendously old, overpowered and creaky. There's support in there for using xml/xsl-html instead of anakia, and support for printable pages. I'm not sure the use of Anakia is even justified given the limited amount that is being done. In increasing order of effort level: 1) Running ant doc_print, I can't say I'm too excited by the printable page version. I'd like to scrap it. Fine with me. I had no idea it was there. ;-) 2) There's an XSL variant of the site generation which may be used instead of Anakia. It's not used afaik and I think it should be ditched; except that: 3) Are we really using Anakia enough to make it worth it? It seems to me that it could easily be replaced with CSS and a single Java class to kick off a simple XML/XSL conversion of each xdoc to a doc. Even that might be overkill as I suspect we could just have regexp search and replace to achieve the same goal. I would be +0 for just using Ant's xslt (a.k.a. style) to kick off a simple XSLT conversion along with a CSS stylesheet. (I would be +1 if I was more practised in the use of these myself.) This is how we generate the Struts documentation, and it's worked well for us. Also, I suspect that using XSLT instead of Anakia would open up the possibility of more contributors, and using CSS would allow for some folks to come up with a much snazzier site much more easily. 4) What should the min JDK be for building the Jakarta site? Is there any reason why it can't be 1.3/1.4 (whichever one gets sane XML-wise). ie) The lib/ directory should not be needed. I'd say just require JDK 1.4 and a recent version of Ant, and you're all done. The lib directory can go. 5) Really contraversial: Killing dead pages. idiot.html, jars.html, ide*.html, os.html, and of course jon.html. Probably other pages too. No opinion on this one. 6) Less contraversial (as no mention of Jon or idiots): Kill vendors page? How about legal and acknowledgements? Should these be under the ASF umbrella level now and not Jakarta specific. If there's stuff that makes sense to move to the main ASF site, then we should do that. Other stuff, like perhaps the vendors page, might make more sense on the wiki. I'd be leery of moving too much out, though, since I suspect a lot of people don't think to look outside the Jakarta site for help. 7) Needs moving Geir: 'Apache on the JSPA'; jspa-position.html. 8) Faqs is something I would merge in with my 'one page index' idea with cvs/svn, javadoc, jars, source, binary, issue-tracking, mailing lists, wiki. I admit I may not get it all on one page :) The challenge is how to make a 50 x 10 table look good. The FAQs page is pretty big all by itself. Not sure how you're going to manage incorporating that into a 'one page index', but I'll look forward to seeing what you come up with. ;-) -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta download pages Was: download pages in j.a.o.
On Mon, 27 Dec 2004 23:27:51 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: I spent a fair while walking circles in the basement (carrying the unhappy baby) and thinking on the download pages. My first thoughts were on what they exist for. From an info-arch point of view, they are a search system in addition to the project pages themselves. The fact that the project pages link back to them is a mistake on the usability side (though does make our lives fractionally easier). My next thought is, why are there separate pages for mailing lists, source code, cvs repositories, binaries? A lot of information is repeated in attempting to provide navigation to get to the part desired. One reason for the separate pages is so that separate information may be obtained, but I believe there is a different solution to that one. So as a general direction, I think we should have a single project summary page that provides the links to all the relevant resources. This does give us a problem with how to handle the context sensitive message of how to use the resource. I think that closer.cgi has the solution there: For example: http://www.apache.org/dyn/closer.cgi/maven/binaries/maven-1.0.2.exe It has problems. Mainly in that it doesn't really provide much a context sensitive message. It should be mentioning signatures, keys, md5s etc. It also loses the navigation of the project it's on and dumps you into a global Apache navigation. However, I think it's the right solution architectually. A dynamic page that contains a standard message and is filled with dynamic info. I actually think that page is horrible. Almost the entire page is filled with stuff the user doesn't care a whit about - a big list of mirror sites. The vast majority of users don't care about mirror sites, they just want to download what they want. The list of mirror sites should be stashed away in a drop-down list, as we have it now. I think, if we had a standard template for download pages, each subproject could have its own download page, something like we have for Struts: http://struts.apache.org/download.cgi this would be a more workable approach. I don't see a need to have one page with all of the available downloads (with the possible exception of Commons, but I'm not sure we need that either). So I see the same thing existing for cvs/svn (context message is how to use cvs/svn etc), mail lists (usual message about politeness etc), downloads, jars (ibiblio links?), javadocs etc. Now, circling the basement is not conducive to coherence, or correct spelling I suspect, so I'm going to ramble a bit here in vague justification. Jakarta is different to other TLP's in that it's an umbrella. One of the reasons I like the approach above is that it is playing to Jakarta's role as an umbrella. Each project will link directly to the dynamic resource page, ie) closer.cgi for downloads. Jakarta then provides an umbrella navigation system for when people want to see all this information from a single location and not click on each sub-project. --- Baby's feed is near an end I suspect, so I need to wrap things up a bit. Direct comments on the current binindex page (with srcindex inheriting most of these flaws): 1) Demo Builds, Milestone Builds: Do we even use these terms regularly? We have 1 demo build, and I thought we did RC's rather than Milestones. I'm not sure we even need to push the nightlies at this level; the project pages themselves should be fine as anyone looking for a nightly is probably deeply involved with that project as a user. I'd be fine with getting rid of separate sections for these, and simply putting RCs in the main section, but that presupposes that we want to mirror RCs... 2) I'm not sure we need to advertise the Apache blog or Jakarta news here. It's on the front page, why use up valuable space. Yep. 3) Why advertise related projects? They're in the navbar about an inch away. I think the original purpose of this section was to provide links to projects that had moved out of Jakarta to TLPs. It would help people who were not yet aware that a project had gone TLP. Now, however, that section seems to have a lot more in it, making it somewhat less meaningful. It might make sense to reinstate the original purpose, listing only graduated projects and renaming the section to reflect that. 4) Same complaint as Martin has. Why have the download information if we let people click right past it. The table at the top is a noble effort, but I think we need a lot more to solve the problem. Yep. 5) Agreed, Commons needs some kind of grouping to bring it together. I think Commons needs its own page to sort out all of the components, instead of trying to deal with a large number of artifacts of one subproject on the same page as all the other subprojects. -- Martin Cooper That's it. Hopefully much food for thought. Hen On Mon, 27 Dec 2004, Martin Cooper wrote
Re: Jakarta download pages Was: download pages in j.a.o.
On Tue, 28 Dec 2004 18:23:37 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: On Tue, 28 Dec 2004, Martin Cooper wrote: On Mon, 27 Dec 2004 23:27:51 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: 1) Demo Builds, Milestone Builds: Do we even use these terms regularly? We have 1 demo build, and I thought we did RC's rather than Milestones. I'm not sure we even need to push the nightlies at this level; the project pages themselves should be fine as anyone looking for a nightly is probably deeply involved with that project as a user. I'd be fine with getting rid of separate sections for these, and simply putting RCs in the main section, but that presupposes that we want to mirror RCs... Should RC's even be on this page? The reality is that currently we list about 3% of all the RC's made. It would make sense for subprojects whose RCs would cause significant bandwidth consumption. However, I think the only subproject that would likely cause such volumes today is Tomcat, but they don't have RCs. (Struts used to put RCs on this page when we were in Jakarta, to take the load off the ASF servers.) So you may be right - maybe this section should go. I'm going to kill the Demo Build section as the only link (Velocity demo) fails. 3) Why advertise related projects? They're in the navbar about an inch away. I think the original purpose of this section was to provide links to projects that had moved out of Jakarta to TLPs. It would help people who were not yet aware that a project had gone TLP. Now, however, that section seems to have a lot more in it, making it somewhat less meaningful. It might make sense to reinstate the original purpose, listing only graduated projects and renaming the section to reflect that. Switching to Graduated. I've removed DB, Geronimo, Gump, HTTP Server, Incubator, Web Services and XML as ones I don't think came from Jakarta. Hard to say with Gump, DB, Web Services. I'm not sure if bits didn't exist in Jakarta. Gump originated at Jakarta, certainly. -- Martin Cooper (at least, I'm doing this. Should be live relatively soon) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 3-column jakarta.apache.org?
On Wed, 29 Dec 2004 14:01:27 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: Here's my mockup proposal: http://www.apache.org/~bayard/mock-jakarta-frontpage.html Changes: 3 column Strikethrough of links/pages I'd like to kill. Less news. Removal of Related section (aim is to make this a new page). Rewrite of the welcome message to hopefully say the same main thing, but use a lot less space. This looks OK. The one thing I would change, though, is to get rid of the indentation under the headings (which would probably necessitate a slightly larger gap between the columns). As it is now, with the indent, the center text - and especially the table - becomes a rather tall, skinny column in a default-sized browser window. The aim would also be to switch entirely over to the XSL build version which seems to work fine and dump Anakia creation. +1 -- Martin Cooper Hen On Wed, 29 Dec 2004, Henri Yandell wrote: I'm a fan of the www.apache.org look and how it gives us a lot more usability in terms of available column space. I'd like to change Jakarta to the 3-columns (though not the lf or anything). Switching to 3-columns means less space in the center for content, however I also want to simplify the content so I think it will look fine. Any views? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mess in jakarta.apache.org/
I zapped the 'userGuide' file. I don't see any point in keeping old sites that are being redirected away from anyway. Unless I'm mistaken, nobody will ever see them. However, it would be good to check with the projects that have moved away from Jakarta, to make sure, since they may not be monitoring this list, and they just might care. ;-) Anything obviously broken or dead should go. Not sure what's left after that. -- Martin Cooper On Wed, 29 Dec 2004 00:52:45 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: Worringly, this is just the flotsam lying around at the top level :) What on this list cannot be rm -r'd? There's usually one or two important ones in the pile of junk, so I'll be relatively careful. BUGS/ Copy of a CVS/. Odd. bcel.org/ Old copy of BCEL site. broken/ A maven repo by the looks of it. builds/ Old build system. Seems somewhat empty and broken. How long to maintain? buildsite.sh Something to do with TAC. Dead way to build site. cjan/ Dead java-repo for pre-cursor to Maven. commons-mavenized/ Old test Commons site. cvsweb/ Broken symlink. gump/ Entire site, though htaccess is redirecting. How long to maintain this? index-new.html Dead copy of index.html jakarta-gnats.tar.gz Dead bug tracking system. jjar/ Dead java-repo for pre-cursor to Maven. jmeter201/ Copy of JMeter site. Bizarrely seems to be kept up to date. log4j/ Entire site, though htaccess is redirecting. How long to maintain this? main.template Old dead file. ojb/ A simple redirect. How long to maintain this? oldsite.tar.gz Dead old file. pluto/ Entire site, though htaccess is redirecting. How long to maintain this? phoenix/ Broken symlink. resources A struts file. Odd. struts/ Entire site. Redirecting so not viewable. How long to maintain this? tac.jar Something to do with TAC. Dead way to build site. tomcat-4.0/ Bizarre. An installation of Tomcat 4. tomcat-old/ Old copy of Tomcat site. turbine.old/ Old copy of Turbine site. userGuide A struts file. Odd. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 3-column jakarta.apache.org?
On Wed, 29 Dec 2004 21:41:00 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: On Wed, 29 Dec 2004, James Mason wrote: Henri, Looks good. Big improvement, I think :). I especially like how the third column brings more information above the status bar. A few comments: Thanks :) 1) The first paragraph sounds more like it's describing the ASF than describing Jakarta. A suggestion: - The Jakarta Project offers a diverse set of open source Java solutions and is a part of [The Apache Software Foundation] (ASF). Like all ASF [projects] Jakarta encourages a collaborative, consensus-based development process under an [open software license]. - It actually is meant to be describing the ASF :) To cut down on text, I threw away 'jakarta, like all ASF, encourages...' to the simpler 'ASF encourages'. It's just as true and uses less space. I'd like to dump 'for all its projects' to be honest, but didn't want to lose the link to the ASF Project page. It's tempting to chop the last 4 words and add a ASF link on the right, together with the other ASF ones, under a new heading of About Apache or something. 2) The first sentence of the second paragraph seems awkward to me. It's not immediately apparent why that information is useful. If I don't know what a TLP is it doesn't really help me, and if I'm looking for a TLP that used to be part of Jakarta it doesn't tell me how to find it. Unfortunately I haven't been able to come up with a better wording. Hopefully someone else is feeling inspired :). Two big parts I'm looking for in this paragraph. 1) Jakarta = umbrella project. I don't want to say umbrella as that's an odd metaphor to the uninitiated. 2) Definition of graduating, attempt at an explanation of why projects are no longer to be found in Jakarta (a common user confusion I think). The TLP acronym isn't highly important (at first I thought it was good to get it accross, but it's too much info). Linking to the bit above, I could dump the TLP acronym and make this the link to the ASF project page. 3) Graduated on the left needs to be in the context of a noun. Maybe swapping the left and right columns (leaving About on the left) and making the right column Projects with subheadings of Subprojects and Graduated? That might take up too much space, though. Gah! Much as I want to scoff at the suggestion for the pain it causes, I think you're right, to be correct it should be a noun. Putting the projects on the right was an option, but I think that consumers will mostly want to click through to a subproject, rather than any other link there and the LHS is the prime navigation spot. It also matches the www.apache.org approach, which is nice for the symmetry of a user clicking through and not having to adjust their navigation flow. Possibly I could change Graduated to Graduated Subprojects? Seems a bit long. 'Graduates' seems wrong. Looking for a good label here :) Alumni? -- Martin Cooper 4) Removing the margin from the ul that makes up the news would help spread that section out a bit. Yep. I'm going to hassle a few web designers I know on spacing issues once I've updated the XSL build to output this site. All their suggestions will involve CSS, so I'll need to have a CSS sheet by then I suspect. Thoughts? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 3-column jakarta.apache.org?
On Fri, 31 Dec 2004 00:26:15 -, Stephen Colebourne [EMAIL PROTECTED] wrote: What I was thinking of for projects is something like: ++ |=Projects===| +--Subprojects---+ | * Alexandia| | * etc... | +--Graduated-+ | * Ant | | * etc... | ++ I have two concerns with this: It takes up more space and nothing else uses subheadings. It does put Graduated into context with a noun, though. My concern is that most users don't care about TLP vs Jakarta owned. So, does the terminology 'graduated' help? Why does the user care that some projects started at Jakarta, while other Java projects didn't? Because resource information for projects that have moved away are no longer found on the Jakarta site. For example, going to the Jakarta mailing lists page is not going to help you find information on the Struts mailing lists. I believe the distinction is important to helping users find what they're looking for. Unless and until Jakarta can become a Java portal @ Apache we have to deal with this though. It would seem to me that 'Related' was a looser word for these projects, and allows us to include other projects that didn't start at Jakarta. We (meaning Hen ;) just got done cleaning up a bunch of related links that didn't seem particularly coherent, so I'd be against putting it right back again. ;-) Also, I don't see any need to use a noun/subheadings here. For me, 'Related' on its own would be a sufficient defintion. I suggested Alumni but I don't think I got any takers. It seemed like the logical noun to replace Graduated to me. IMO, Related is too broad, and it was being misused before. -- Martin Cooper Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jakarta-site2 now live on xslt
On Mon, 3 Jan 2005 09:02:23 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: On Mon, 3 Jan 2005, sebb wrote: On Sun, 2 Jan 2005 19:15:59 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: On Sun, 2 Jan 2005, sebb wrote: Looks like a *lot* of other projects use the Anakia jars and/or stylesheets from jakarta-site2 - not just jakarta-tomcat-site...so perhaps those need to be restored. Sites with the older lf: Taglibs, Velocity, BSF, ECS, JMeter, Lucene, ORO, Regexp, Slide, Tomcat, Watchdog. However, the following all appear to be self contained/non-users: Taglibs, Velocity, BSF, Watchdog, Slide. Sorry, should have remembered that, as it used to apply to jmeter... + JMeter. So the broken ones look like they are Tomcat, Regexp, ORO, Lucene, ECS. I did a search for the string jakarta-site2 in the build.xml,v files in CVS, and that produced quite a lot of hits (see http://www.apache.org/~sebb/js2.txt - note that the matched text is *followed* by the file name). Some of the matches relate to history items, but some are in the HEAD versions of the files, for example: http://cvs.apache.org/viewcvs.cgi/ant/proposal/ant-site/anakia/build.xml?only_with_tag=HEADview=markup http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/build.xml?only_with_tag=HEADview=markup Of course we don't know if the build targets are actually still used, but it suggests that these files are rather more generally used. Both HttpClient and Ant appear to use Maven or Forrest for their sites though, so I'd think it's a pretty low chance that they still use things. I think all of Commons is Mavenised, and I checked all of Jakarta in this way to find old style lf and then examined those by hand. Looking at the graduated projects, Struts and James still look old style; so they've got a good chance of still using site2. Looking at them, both Struts and James appear to be on XSLT variants, but no use of the site2 jars or stylesheets. WRT Struts, it does not depend on site2. Its site generation is self-contained. -- Martin Cooper Still, not to say that others in your list don't use it, such as jyve or various proposals in James etc, just nothing 'big' I think. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Last call for comments Was: [site] next step - 3-tier + welcome
On Thu, 6 Jan 2005 00:19:37 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: http://www.apache.org/~bayard/jakarta-3tier.html Rolled back to remove the table-div header change for the moment. I'd like to go ahead and make the change to a 3 column on Friday. Looks OK to me. I'd say go for it. There are a couple of tweaky things - like the font seems a little bigger than it needs to be, and the section headers are different from the main ASF site - but they really are tweaky things that we can talk about and fiddle with later. -- Martin Cooper Any nay-sayers before then, let me know. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] clean up
On Thu, 6 Jan 2005 17:57:38 +, robert burrell donkin [EMAIL PROTECTED] wrote: On 6 Jan 2005, at 09:09, Danny Angus wrote: Robert, and is any planning needed so that no toes are stepped on? An advance heads-up would warn other projects which might link to those pages. Though as a redirect wouldn't break the links I guess its not that important, James has been bitten by Jakarta changes before, though I hasten to add it is James' own fault for not moving quick enough, and anyway I don't think this would affect James. it's hard to know which projects links to jakarta and where would be the right place to post any advance warning. so, though i definitely take your point, i'm not sure that there's much that can be done. I wonder if there's a link checker doodad that we could run on *.a.o, perhaps as a cron job, and have it send out Gump-like nag messages when something breaks? -- Martin Cooper i do try to ensure that any changes i make do not break links. the redirects should ensure that this doesn't happen. what i will try to do is to collect and collate the changes (once there's a reasonable number) and post an email to community detailing the new pages and together with the redirected pages from jakarta. this should allow projects which may be linking to redirects to update their links. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] Removing things
On Fri, 7 Jan 2005 20:50:28 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: Next up is to clean up various bits on the large front page. Here's the list of changes. For each one, if I don't hear a -1 by Tuesday I'll go ahead and make the change. 1) Rewrite of the welcome message to the welcome message at http://www.apache.org/~bayard/mock-jakarta-frontpage.html. Including additions to the products table as shown in the mock. 2) Removal of the elsewhere news section. Point redirects to news/index.html. 3) Remove License renewal and news blog from Headlines section. Rename Headlines to News. 4) Removal of Graduated from the left navbar. I haven't kept up with all of the discussion in the last few days - why are we removing this? IMHO, it's still valuable for the less frequent visitor to our site. 5) Removal of Related table at the bottom of the index. 6) Move Legal link to the bottom of the page (with the copyright), as shown in mock. 7) Removal of Our Mission. Redirect to front page. This seems to me like an important thing to have stated up front. If what we have now isn't what we think we're about, we should fix it rather than removing it. If we don't think we can fix it, then we have a serious problem. ;-) -- Martin Cooper 8) Removal of links to Japanese/Korean translations. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] Removing things
On Sat, 8 Jan 2005 17:28:34 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: On Sat, 8 Jan 2005, Martin Cooper wrote: On Fri, 7 Jan 2005 20:50:28 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: Next up is to clean up various bits on the large front page. Here's the list of changes. For each one, if I don't hear a -1 by Tuesday I'll go ahead and make the change. 4) Removal of Graduated from the left navbar. I haven't kept up with all of the discussion in the last few days - why are we removing this? IMHO, it's still valuable for the less frequent visitor to our site. Graduated is a confusing concept that we then have to somehow explain. Then let's just call it Ex-Jakarta. Additionally, how long would we maintain links to said projects etc? 6 months to a year. Let me ask the reverse question: How long would you keep the link to a subproject once it leaves? Would you remove it as soon as the project leaves, or keep it around for a while? If the latter, why wouldn't you move it to an Ex-Jakarta section instead? I think Graduated is best replaced by: News item on graduation that stays prominent for a few months. Some kind of larger [EMAIL PROTECTED] page. It's not clear to me that people will go and read the News section if they can't find the link to the subproject. After all, if there's no link, then it can't be a Jakarta subproject, so why would there be Jakarta news about it? -- Martin Cooper 7) Removal of Our Mission. Redirect to front page. This seems to me like an important thing to have stated up front. If what we have now isn't what we think we're about, we should fix it rather than removing it. If we don't think we can fix it, then we have a serious problem. ;-) It's a pointless page. The Welcome + Navbars contains all the information it has, so it just adds to the general clutter. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] Removing things
On Sat, 8 Jan 2005 19:38:17 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: On Sat, 8 Jan 2005, Martin Cooper wrote: On Sat, 8 Jan 2005 17:28:34 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: On Sat, 8 Jan 2005, Martin Cooper wrote: On Fri, 7 Jan 2005 20:50:28 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: Next up is to clean up various bits on the large front page. Here's the list of changes. For each one, if I don't hear a -1 by Tuesday I'll go ahead and make the change. 4) Removal of Graduated from the left navbar. I haven't kept up with all of the discussion in the last few days - why are we removing this? IMHO, it's still valuable for the less frequent visitor to our site. Graduated is a confusing concept that we then have to somehow explain. Then let's just call it Ex-Jakarta. Seems okay :) I'll promote this suggestion to a new thread, see if anyone disagrees. Additionally, how long would we maintain links to said projects etc? 6 months to a year. Let me ask the reverse question: How long would you keep the link to a subproject once it leaves? Would you remove it as soon as the project leaves, or keep it around for a while? If the latter, why wouldn't you move it to an Ex-Jakarta section instead? Spent an hour pondering it, and I'm swayed by your arguments. I'm happy too keep the links to old Jakarta sites. The only real problem it causes us is when things get closed (Avalon), but those projects should have sites kept up anyway. And hopefully what happened with Avalon won't happen very often... By News section, I'd meant the front page. Given the tighter mock, an item in the news section of the front page is pretty prominent, but it's probably more valueable spacewise than the bottom left of the navbar, so maintaining links to ex-jakarta is much better. 7) Removal of Our Mission. Redirect to front page. This seems to me like an important thing to have stated up front. If what we have now isn't what we think we're about, we should fix it rather than removing it. If we don't think we can fix it, then we have a serious problem. ;-) It's a pointless page. The Welcome + Navbars contains all the information it has, so it just adds to the general clutter. Any comment on this? Can 'Our Mission' go? I guess so. It just feels like something we should have, but, as you mentioned, we don't really have much of anything to say at the moment. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] Odd Ant question
I haven't tried it, but how about this: * Use subant with 'genericantfile' (referencing the same build file) and a dirset for the directories you want. * In the target invoked by subant, use available to determine whether or not the HTML file exists, and invoke another target that only runs 'if' the property is set. That second target would do the copy. * Use pathconvert to generate the name of the CGI file based on the name of the HTML file. -- Martin Cooper On Sun, 13 Feb 2005 21:38:32 -0500, Henri Yandell [EMAIL PROTECTED] wrote: Before I lug myself off to the Ant lists, thought I'd ask here. I'm trying to come up with a way to make the cgi work for the downloads pages. One way would be to rewrite the cgi, have it take arguments and be more dynamic. Another easier way would be to simply copy the cgi file lots of times (as it's already been copied many times already). To do this copying, I basically want to do the equivalent of: --- For each downloads_*.html file copy downloads.cgi downloads_*.cgi Any idea how I do that in Ant? Mappers seem like they'd want to be copying the html file to the cgi file; ie) wildcard in to and from. There's no for loop, so not sure how I'd do such a thing. Maybe one way would be to call a target on each file in a list of files. Any ideas? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: PMC contact for Wiki Admin
On Thu, 17 Feb 2005 14:35:59 -0800, Tim Colson (tcolson) [EMAIL PROTECTED] wrote: Hello Most Reverent and Kind Jakarta Gentlefolk :-) I have a suggestion/request and it seems this might (or might not) be the place to suggest/request it. :-) As per below... I'd like to request the MoinMoin wiki be upgraded to 1.3.x. You'd need to take this up with the infrastructure team ([EMAIL PROTECTED]). There has been some discussion of upgrading MoinMoin, and the most likely target at this point seems to be 1.2.4. IIRC, there was some resistance to go to 1.3.x, I think because there were bigger implications. But infrastructure@ is the place to get the real scoop. -- Martin Cooper Personally I'd love to see Confluence replace the Python Moin Moin, since Confluence is written in Java, shows off Jakarta through the use of many Jakarta packages, and shows support open source projects by being FREE for them. But barring that... I'd really like to see the upgrade to MoinMoin happen because the wiki is becoming a huge benefit for collaboration on the Velocity and Velocity Tools projects. I realize Apache is a volunteer org and we all know this is stuff we all do in our not so copious free time -- but I'd really like to know how/where/who admins the MoinMoin install and offer to help in any way I can. Cheers, Tim Colson, Geek P.S. If you suggest something it is a suggestion, but if you request something, why isn't it a requestion? grin -Original Message- From: Will Glass-Husain [mailto:[EMAIL PROTECTED] Sent: Thursday, February 17, 2005 10:43 AM To: Velocity Developers List Subject: Re: PMC contact for Wiki Admin Velocity doesn't have a PMC since it's not a top level project. Our PMC is the Jakarta PMC. Many of the committers (but not me) are members of the PMC. I can't seem to find the address for the pmc mailing list. You might use general@jakarta.apache.org as a substitute (although it's a public list). That might be a good place to advocate for this anyway. WILL - Original Message - From: Tim Colson (tcolson) [EMAIL PROTECTED] To: Velocity Developers List velocity-dev@jakarta.apache.org Sent: Thursday, February 17, 2005 9:28 AM Subject: PMC contact for Wiki Admin So I'm not in the Know on this one... i.e. WHO is the admin for the MoinMoin stuff? I searched to try and figure it out, also tried to figur out how to make requests for MoinMoin other than create a new site... Seems the only way will be to send an email to the infrastructure alias at apache ...and cc the PMC (who IS that for Velocity these days? Will?) http://wiki.apache.org/general/HowToMakeWikiAdminRequests What I want to request: upgrade MoinMoin to 1.3.x ...while not as spiffy as Confluence, at least it's a HELLUVALOT better than the current version 1.1.x. Lots of detailed observations on what's improved here: http://confluence.atlassian.com/display/DISC/Comparison+Matrix Cheers, Timo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [site] New download pages
Looks good to me, apart from the not-working-ness. ;-) +1 -- Martin Cooper On Thu, 17 Feb 2005 19:47:37 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: I'd like to go ahead and move to my suggested new download pages: http://jakarta.apache.org/~bayard/jakarta/site/downloads/downloads.html [ ] +1 [ ] -1 or alternatively: [ ] +1, but fix this first: [ ] Currently the filenames match the names on the binindex.cgi page, I'm trying to stay as close as possible to the current site before making any other changes. It's easy enough to then do things like change 1.0.zip to hivemind-1.0.zip as Howard suggested. Post change, I'll focus on improving the Taglibs page to match the Commons one in style. 72 hour consensus vote. ie) a single -1 is a veto. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems under 1.5 Was: [site] New Jakarta download pages
On Tue, 22 Feb 2005 14:09:48 -0500, Howard Lewis Ship [EMAIL PROTECTED] wrote: I think we should not be checking in derived files. One of the reasons for that is so that anyone on the infrastructure team can quickly replace the site if it is corrupted or vandalised somehow. They should not have to go through a build process before they can do that. -- Martin Cooper I think the process should be: 1) Build and test locally 2) SVN checkin 3) Log into jakarta 4) SVN checkout 5) Build to staging area; test stage 6) Build to production; test production The build.xml needs to have targets: build -- local build (to target/site) build-stage -- to /www/jakarta-stage.apache.org ? build-prod - to /www/jakarta.apache.org The build scripts can be smart about setting file permissions etc. On Tue, 22 Feb 2005 12:42:45 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: On Tue, 22 Feb 2005, Stefan Bodewig wrote: While it was using XSLTC, which is the TraX processor shipping with JDK 1.5. We now switched to Xalan-J's CVS HEAD. I give up :) How would I force it to be dependent on a particular version of Xalan? Along with the problems with .cgi files and xhtml, xsltc appears to sort the attributes of a html tag differently so if we have 1 person using 1.4 and 1 using 1.5, our diffs are going to be spammed by attributes rotating back and forth. Throw in possible worries that the http:// url was causing problems under 1.4 and it seems to not be worth the trouble. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] bug update
On Wed, 23 Feb 2005 00:41:38 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: After grumbling out loud, my wife pointed out I was being an idiot. So a quick bit of scripting hackery and a very one-off link checker is off and running. Jakarta downloads at about 560Meg by the way :) A bunch more fixes made. From svn: Configuration had a typo 'commons-commons'. Daemon doesn't have commons- at the front. DBCP had typo of version number, I did 2.1.1 instead of 1.2.1. JEXL doesn't have binaries/source directories. Modeler doesn't have commons- at front. Transaction uses .tgz. ECS had -src in wrong place. JMeter uses _src. Lucene had -src in wrong place. ORO doesn't have a -src at all in its src download. Slide had duplicated extra bad lines and the jca link was typo'd. md5/pgp turned off for cli. md5 turned off for jexl. nightly link fixed for transaction. md5 turned off for tomcat 3. Fix to turbine nightly build. Known problems: * Chain, IO, Transaction, Validator use .MD5 instead of .md5 I think this is an Ant vs. Maven issue, although I don't recall which way around. * ORO uses .sig instead of .asc This might be a PGP vs. GPG issue. I use PGP, but rename the generated files from .sig to .asc. -- Martin Cooper * JEXL has no KEYS file * Turbine is quite fubar'd (was in binindex too). Out of date. Missing lots of entries. * ECS .asc files are fubar'd, they appear to be binary. Hen On Tue, 22 Feb 2005, Henri Yandell wrote: While I futz my way along fixing things, thought I'd disclose which bugs have existed today. Couple of hours between 7 and 9am EST we had problems due to JDK 1.5 and unpredictability of building on other people's environments. Solution will be to hardwire a Xalan dependency. All Commons -src downloads were screwed. I c+p'd the -src into the wrong place in the filename. Bug in group of group md5/pgp's meant those links failed for 5 download pages. HttpClient, Collections, Tomcat 5, Hivemind and Tomcat-Connectors were affected. Wrong information on the original binindex page for mod jk 1.2. Fixed now. HttpClient binary download was broken due to difference in url from other Commons projects (binary rather than binaries). - I'm slowly checking all the links to make sure they're ok. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javadoc management
On Wed, 16 Mar 2005 00:49:08 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: Interested in finding out if anyone else thinks this would be a good idea. Rather than have each subproject managing their release javadocs separately, I think it would be good if we treated the javadoc more like the releases. Located in a central location, perhaps mirrored, all versions available and perhaps with additional tools like ashkelon or multidoc to bring them together. Sounds good to me (assuming you mean all *released* versions available). On download pages, we could have binaries, sources and javadocs, with options for javadocs being download or view online (a bit like Sun's download pages). We might not need to mirror right away - we could wait to see how much this gets used. I'm not familiar with ashkelon or multidoc. What would they bring to the party? -- Martin Cooper Subprojects would still be hosting their latest cvs head javadocs internally, but they would deploy a versioned javadoc as a part of releasing, and we wouldn't end up with the issue where users cannot view the latest released javadoc due to a site rebuild etc. Javadoc seems less important for some projects, Taglibs and Tomcat leap to mind, so it may not apply for all (though seeing a tag doc in javadoc style would rock). Anyway. Looking for community interest. If there, I'd make it my 2005 Q2 task, probably along with trying to hassle on LGPL stuff again. As it's my current weapon of choice, I'd probably end up with an xml/xslt solution much like the download stuff, so feel free to point out that that wasy crap. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: future for maven generated websites?
I believe you're really talking about deployment, rather than generation. I doubt that any changes will be needed in generation itself. The current hand-wavy answer on updating web sites when shell accounts go away is WebDAV. I'm not sure if anyone has thought this through yet, though - when I asked for more detail, the answer was essentially dunno yet. So I guess we'll have to wait and see, although if you have suggestions / want to keep up to date, infrastructure@ is the place to be. -- Martin Cooper On Sun, 27 Mar 2005 11:29:28 +0100, robert burrell donkin [EMAIL PROTECTED] wrote: does anyone have a plan to cope with rebuilding maven based websites when shell access is switched off to the machine serving the website? will we be able to run regular maven site regeneration on a jakarta.apache.org partition? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of InterWiki by ManikSurtani
What's happened is that the wiki change notifications seem to be sent to a separate list now ([EMAIL PROTECTED]) instead of where they were sent before ([EMAIL PROTECTED]). This has also happened for some (all?) of the other wikis. I'm assuming this change happened as part of the upgrade to the newer wiki version. I've already put in a request to the infrastructure folks to change this back to the way it was. -- Martin Cooper On Wed, 30 Mar 2005 23:48:13 +0100, Kevin Jones [EMAIL PROTECTED] wrote: I hate to do this as I know this is not an admin list but in the last few days I've started receiving these notifications that the wiki has changed. I haven't subscribed to this list so I'm assuming I was added 'accidentally', how do I get off the list? Kevin Jones http://public.xdi.org/=kevin.jones skype (www.skype.com): kevinrjones -Original Message- From: Apache Wiki [mailto:[EMAIL PROTECTED] Sent: 30 March 2005 23:32 To: Apache Wiki Subject: [Jakarta Wiki] Update of InterWiki by ManikSurtani Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by ManikSurtani: http://wiki.apache.org/jakarta/InterWiki -- List of valid InterWiki names this wiki knows of: [[InterWiki]] - Subprojects under Jakarta that have wiki pages: + Subprojects under Jakarta that do not have wiki sites of their own (under http://wiki.apache.org) but have a few wiki pages under this wiki: JakartaRegexp MoinMoin marks the InterWiki links in a way that works for the MeatBall:ColourBlind and also is MeatBall:LynxFriendly by using a little icon with an ALT attribute. If you hover above the icon in a graphical browser, you'll see to which Wiki it refers. If the icon has a border, that indicates that you used an illegal or unknown BadBadBad:InterWiki name (see the list above for valid ones). BTW, the reasoning behind the icon used is based on the idea that a Wiki:WikiWikiWeb is created by a team effort of several people. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications
Can we please separate the two different topics being discussed here? The original purpose of this discussion was to see if there is general concensus that a Webapp Commons (or whatever name we end up with) is a good idea. If we think it is, then we need to develop a charter, come up with a name, and officially make the proposal to the PMC. We also need to discuss other aspects, such as whether or not we want to follow the Jakarta Commons model, with separate Proper and Sandbox components. Once we've got to that point, we can have discussions about the various sources from which code might be contributed. Some of those will be from inside of Jakarta, or other ASF projects, and some might be from external sources. IMHO, the discussion of potential external sources and potential new ASF committers is premature at this point. I think we need to get off the ground first. Finally, I'll point out that any substantive contributions would need to come in through the incubator. That being the case, we're not in any position to make judgements or promises, here and now, about what can be brought in and / or who may or may not become committers on the new subproject. (Frank, I am *not* trying to shut you out. I'm simply trying to get the new subproject off the ground without complicating things by discussing external elements prematurely.) -- Martin Cooper On Wed, 22 Jun 2005, Frank W. Zammetti wrote: robert burrell donkin wrote: that's understandable but is likely to cause wrinkles in the approval process. a subproject needs a name and a charter before it can be approved. no guarantees could be offered since accepting new committers is something that sould be delegated to the new community. I definitely see the conundrum. You touched on something too that I hadn't even brought up directly... If I'm going to give up the name, and end my project and contribute all the code I've written, I don't think it is unreasonable to ask to be a committer on the new Jakarta project. I may be mistaken, but I thought part of the approval process is a list of initial committers? I thought I had seen that at one point on the new project proposal paperwork. If so, I'd say that could take care of this part of things because I could be named a committer initially, then everything else as far as names and initial code goes falls in to place pretty easily. anyone have any opinions about this? If the above isn't true, one possible suggestion is to proceed with a contingent name... The contingency being the community accepting me as a committer. There would still be a name in reserve if that should not happen. I hope I'm not coming across like an a**hole here trying to worm my way in... I believe what I'm saying is reasonable, if anyone disagrees please feel free to tell me so. if you could leave it a little while before changing the name of your project to WP4J, that might give us some time to prepare the documents in... I actually didn't mean I would change my project name... In my mind, there are three possible paths here... One is that the Jakarta project takes my name, and my projects ends and all the code is contributed. Two is that the Jakarta project takes a completely different name and I still end my project and contribute all the code. Third is that my project continues as-is and the Jakarta project takes a completely different name. There is the fourth option of me changing my proejects' name and keeping in separate, but that presents problems for me at this point so I wouldn't be especially inclined to do that. I suppose I wouldn't rule it completely out, but it would definitely be last on my list. Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] Proposal For Jakarta Sub Project For Web Application Components
On Wed, 22 Jun 2005, robert burrell donkin wrote: i considered posting this to one or more of the announcement lists in an attempt to widen the audience but i didn't feel confident that it would be appropriate or wise. opinions? IMO, it doesn't need to go to announcements lists at this point. People who are only on those lists are likely interested only in things that have become real. When (if) the subproject is created, it might be more appropriate, but I don't feel a proposal is right for [EMAIL PROTECTED] I did, however, forward the message to taglibs-dev and taglibs-user, since they may end up with a vested interest in this. -- Martin Cooper - robert On Wed, 2005-06-22 at 22:48 +0100, robert burrell donkin wrote: There has been considerable interest over the last few weeks and months concerning the possibility of a new Jakarta sub project similar to the Jakarta Commons but aimed at independent reusable web application components. There are a number of matters which need to be discussed and ideas developed. Anyone who is interested is invited to subscribe to the general list at Jakarta (http://jakarta.apache.org/site/mail.html). A start has been made at documenting some of these: http://wiki.apache.org/jakarta/CreatingCommonsForWebComponents. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On 6/25/05, Stephen Colebourne [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: is boils down to the question: does this subproject need it's own sandbox or will neophyte components start in the jakarta commons sandbox? +1 for sandbox (non-binding) Its slightly hard to imagine anything otherwise, but maybe I'm just used to seeing how commons and taglibs work. If Taglibs join, we have a bunch of Taglibs in sandbox, they will need to be housed somewhere, and I don't see them migrating to commons sandbox ;-) Right? Yes, +1 to a sandbox. Although it can create issues, I think has more benefits than downsides. +1 -- Martin Cooper Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] drop point 12 [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On 6/25/05, Stephen Colebourne [EMAIL PROTECTED] wrote: robert burrell donkin wrote: this has proved impractical in the jakarta commons. i propose we drop point 12. 12. The subproject will also provide a single JAR of all stable package releases. It may also provide a second JAR with a subset of only JDK 1.1 compatible releases. A gump of nightly builds will also be provided. --8--- [X] +1 Get rid! [ ] -1 Keep it (please give a reason...) -- One jar didn't work for commons, no reason to expect it will here. +1. Let's ditch it. -- Martin Cooper Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mailing lists for components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote: On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: 4.1 in the guidelines repeats the error that I thought was fixed in the j-c guidelines saying that each package has its own mailing list. If that is intentional, I think that is a *bad* idea, especially to start. it was intentional in as much as it was a copy of the jakarta commons charter :) Don't like the many little lists implied by 11 -- dev + user works fine in j-c (I know some disagree, but I personally view this as the key to the health of j-c) i agree. just dev and user lists. in jakarta commons, the common mailing lists hold together the single community. i'd like to see just one mailing list with components using prefixing (as per jakarta commons). i'd like to see changes to the draft so that it's clear that this will be the arrangement. opinions? +1 to just one dev and one user list, shared for all components, a la Jakarta Commons. -- Martin Cooper - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote: On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: 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. is 19 needed in addition to 15? This seems to be a different topic entirely, but my vote would be yes, because 15 relates only to the proposal, while 19 relates to the component as it exists, and is developed, within the subproject. -- Martin Cooper - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] drop 8
+1 -- Martin Cooper On 7/3/05, Phil Steitz [EMAIL PROTECTED] wrote: +1 to drop this Phil robert burrell donkin wrote: 8. Packages are encouraged to either use JavaBeans as core objects, a JavaBean-style API, or to provide an optional JavaBean wrapper. doesn't seem very relevant. i think that it'd be simpler just to drop it. here's my +1 - robert --8--- [ ] +1 Get rid! [ ] -1 Keep it (please give a reason...) -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Brian Stansberry as jakarta-commons-logging committer
On Mon, 11 Jul 2005, Simon Kitching wrote: Hi, Brian sent his CLA in by post about 12 days ago. How can I check whether it has been received/processed? I just checked, and it has not yet been recorded. I'll keep an eye out for it, though. -- Martin Cooper Thanks, Simon On Sat, 2005-06-25 at 22:50 +1200, Simon Kitching wrote: The votes to elect Brian Stansberry as a committer for jakarta-commons-logging are as follows: +1 Dion Gillard +1 Phil Steitz +1 Robert Donkin +1 Yoav Shapira +1 Emmanuel Bourg +1 Henri Yandell +1 Simon Kitching Brian is therefore elected (Brian has indicated privately that he is willing to accept). Brian, the first thing you need to do is complete a Contributor License Agreement and send it in by mail or fax. Details are here: http://www.apache.org/dev/new-committers-guide.html Once this is completed we can create a user account for you and arrange the necessary access rights. Note that processing of CLAs can sometimes take a week or two. Your contributions to jakarta commons so far are very appreciated and we all hope you'll enjoy being part of the commons community. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Brian Stansberry as jakarta-commons-logging committer
On Wed, 27 Jul 2005, Simon Kitching wrote: Hi, Any sign of Brian's CLA having been received?? Nope, not yet. Jim added in a bunch of received iCLAs on 7/14, and Brian's was not amongst them. You might want to ask him to fax it again, in case it got lost somehow. -- Martin Cooper Thanks, Simon On Mon, 2005-07-11 at 16:50 +1200, Simon Kitching wrote: Hi, Brian sent his CLA in by post about 12 days ago. How can I check whether it has been received/processed? Thanks, Simon On Sat, 2005-06-25 at 22:50 +1200, Simon Kitching wrote: The votes to elect Brian Stansberry as a committer for jakarta-commons-logging are as follows: +1 Dion Gillard +1 Phil Steitz +1 Robert Donkin +1 Yoav Shapira +1 Emmanuel Bourg +1 Henri Yandell +1 Simon Kitching Brian is therefore elected (Brian has indicated privately that he is willing to accept). Brian, the first thing you need to do is complete a Contributor License Agreement and send it in by mail or fax. Details are here: http://www.apache.org/dev/new-committers-guide.html Once this is completed we can create a user account for you and arrange the necessary access rights. Note that processing of CLAs can sometimes take a week or two. Your contributions to jakarta commons so far are very appreciated and we all hope you'll enjoy being part of the commons community. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Brian Stansberry as jakarta-commons-logging committer
On Wed, 27 Jul 2005, Simon Kitching wrote: On Tue, 2005-07-26 at 19:49 -0700, Martin Cooper wrote: On Wed, 27 Jul 2005, Simon Kitching wrote: Hi, Any sign of Brian's CLA having been received?? Nope, not yet. Jim added in a bunch of received iCLAs on 7/14, and Brian's was not amongst them. You might want to ask him to fax it again, in case it got lost somehow. It was posted, rather than faxed. I don't believe the US post is that slow is it?? Not usually. ;-) You might want to e-mail Jim. All I can tell you is that Brian's name isn't in the iCLAs file, and it didn't get added and then accidentally removed. Beyond that, I have no clue. For all I know, Jim might not have picked up from the PO box for a while, the CLA could be lying on his desk, or it could have fallen into a black hole. Sorry. -- Martin Cooper On Mon, 2005-07-11 at 16:50 +1200, Simon Kitching wrote: Hi, Brian sent his CLA in by post about 12 days ago. How can I check whether it has been received/processed? Thanks, Simon On Sat, 2005-06-25 at 22:50 +1200, Simon Kitching wrote: The votes to elect Brian Stansberry as a committer for jakarta-commons-logging are as follows: +1 Dion Gillard +1 Phil Steitz +1 Robert Donkin +1 Yoav Shapira +1 Emmanuel Bourg +1 Henri Yandell +1 Simon Kitching Brian is therefore elected (Brian has indicated privately that he is willing to accept). Brian, the first thing you need to do is complete a Contributor License Agreement and send it in by mail or fax. Details are here: http://www.apache.org/dev/new-committers-guide.html Once this is completed we can create a user account for you and arrange the necessary access rights. Note that processing of CLAs can sometimes take a week or two. Your contributions to jakarta commons so far are very appreciated and we all hope you'll enjoy being part of the commons community. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tracking commons component liveliness
On Wed, 27 Jul 2005, Simon Kitching wrote: Hi All, There have recently been some discussions about handling dormant/dead commons projects. And I've been wondering about the activity levels of some projects recently (whether they are dead or not). It's hard to track activity by email volumes, and subversion commit counts can be misleading for two reasons: * some commits are done to fix widespread issues such as copyright dates, while not actually indicating activity on a project * some projects are perfectly stable, and so have low activity counts though they are by no means dead and still have maintainers around. I've got a suggestion to make about tracking this. We could put up a page on the wiki (or maybe directly on the jakarta-commons main page) listing all the projects (main and sandbox). Next to each project would be listed the currently active developers and a date. I have a big problem with putting people's names beside projects and components on a public web page. Besides being yet another thing that needs to be kept up to date, it will only encourage people to contact the developers directly, instead of using the mailing lists. From my own perspective, this is a huge problem already, and I'd be -1 to anything that's going to further exacerbate it. -- Martin Cooper People would be expected to regularly (as often as they like but at least every 3 months) go to the page and update the date next to their name for projects they still are actively involved in, and remove their name against any projects they no longer do anything on. By actively involved I mean that they respond to bug reports or patches submitted for the project, not just that they are currently coding on it. Periodically (eg before the board report is due) the Jakarta PMC chair can post a few mails reminding people to update their details. And then names where the dates get too old can be removed as they clearly aren't responding to those prompter emails. A quick look at this page by users or apache people would show the stability of projects: zero, one or multiple maintainers. It doesn't seem an unfair burden; I'm happy to update 3 or 4 lines on a wiki page once every 3 months. Anyway, it's just a thought for the PMC, Henri, etc. to follow up on if you think it's worth doing for us or the users. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Components/Common project
On 8/9/05, Rahul Akolkar [EMAIL PROTECTED] wrote: On 8/8/05, Rahul Akolkar [EMAIL PROTECTED] wrote: On 8/8/05, robert burrell donkin [EMAIL PROTECTED] wrote: snip/ IMO the proposal can be finished off pretty quickly but i'm unsure about the best way to handle the name issue. didn't seem to be any sort of a consensus. opinions? snap/ Is there any interest in resolving the name issue as mentioned below? I think everyone's perception of the methodology used is key to a swift resolution, so it'd be nice to flesh out what the method should be. Yes. We need to pick a name ASAP so that we can get the new subproject off the ground with its own mailing lists, SVN repo, etc. The problem is that the list of candidate names, as it is now, is rather long, which could make for a somewhat messy vote. Therefore, I'd like to propose removing some of those candidate names prior to a vote: * Remove anything that has potential conflict. Let's just not go there. * Remove League, Confederation and Bloc. I honestly don't think those are serious names. * I would also recommend removing Weblets, since this suggests a uniformity of structure that simply won't be there. That would still leave us with quite a few options to choose among. -- Martin Cooper -Rahul While it would be nice, I doubt this is going to be unanimous. Unless there are other suggestions, or someone else beats me to it, I will call a vote in 24 hours. I plan to keep it simple, mark X before the name that appeals most to you. snip/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: GMANE
On Thu, 1 Sep 2005, David Smiley wrote: Hello all. I love using GMANE ( http://www.gmane.org ) to access mailing lists because: 1. one stop mailing-list shopping -- a consistent experience 2. NNTP access 3. easiest path to posting a question to a list that you're not a member of, examining the responses, and then leaving. IMHO, this is actually a reason to *not* provide a link to Gmane on our site, since it's anti-community, and community is what we are about. One other point to bear in mind is that Gmane isn't the only service of its kind. I believe Roomity aspires to be another Gmane, and there are probably others. I'm not sure we want to be keeping pointers to all of them, and we shouldn't be picking favourites. ;-) -- Martin Cooper 4. emails for lists don't go into my mailbox; I don't want them there (I prefer NNTP) I think a mention of GMANE on Jakarta would be helpful for the community. This page could use it: http://jakarta.apache.org/site/mail.html (by the Archives section) And perhaps elsewhere; I don't know. Thanks for listening. ~ David Smiley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Request for Comment] Http Components proposal
On 9/24/05, Henri Yandell [EMAIL PROTECTED] wrote: Prior to calling a PMC vote here in a week or two, I'd like to ask if anybody has any comments on the following proposal for Commons HttpClient to become a Jakarta subproject focusing on Http components. Hen * (The following charter for Jakarta Http Components project is pending approval of the Jakarta Project Management Committee (PMC). ) Rationale: = The original Jakarta Commons HttpClient API has a number limitations that cannot be resolved without a significant architectural redesign. Moreover, Jakarta Commons HttpClient has been increasingly used in applications and environments it has not been specifically designed for. The existing monolithic design no longer adequately reflects the use patterns of HttpClient. HttpClient needs to be refactored into a toolset of simple, low level HTTP components suitable for building more specialized HTTP services. Project scope: = * Jakarta Http Components develops a toolset of low level components focused exclusively at the transport aspects of HTTP protocol. * Jakarta Http Components MUST be content agnostic. The project DOES NOT develop components intended to produce or consume content of HTTP messages. While I understand what you're trying to say here, this wording appears to preclude some of what is in HttpClient today, namely multipart content handling. * Jakarta Http Components continues the development of Jakarta HttpClient (formerly Jakarta Commons HttpClient) based on the toolset of HTTP components. This tool focuses strictly on the client side of HTTP. * Jakarta Http Components MAY develop non-client components (such as an HTTP connector, a lightweight server component, proxy components) as reference material to demonstrate the capabilities of the toolset. The said artifacts ARE NOT meant for production use and are not released as official Apache Jakarta products. * Jakarta Http Components collaborates with other projects to develop specialized HTTP services for production use based on the toolset of HTTP components. * Jakarta Http Components DOES NOT define a server side API on top of the low level transport API. Again, I understand what you want to say. However, I think it would be better said in terms that make it clear that it is intended for use on the client side _of the protocol_, since many people are using HttpClient on the server side today, but as a client to other servers. -- Martin Cooper Targeted specifications and standards: = * RFC1945 Hypertext Transfer Protocol -- HTTP/1.0 * RFC2616 Hypertext Transfer Protocol -- HTTP/1.1 * RFC2617 HTTP Authentication: Basic and Digest Access Authentication * RFC2109 HTTP State Management Mechanism -- Cookies * RFC2965 HTTP State Management Mechanism -- Cookie2 * A standard for robot exclusion - robots.txt parser (contribution requiring Software Grant - http://www.osjava.org/norbert/) Initial set of committers: == Project Lead Michael Becke Project Committers Adrian Sutton Ortwin Glueck Oleg Kalnichevski Henri Yandell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multipart/form-java
I would recommend that you use something like Commons HttpClient to
construct and make the request, instead of trying to do so manually, as you
are now. See:
http://jakarta.apache.org/commons/httpclient/
You might also want to use Commons FileUpload to parse the request, instead
of the O'Reilly package, so that you don't get tangled up in the strange
licensing conditions of the O'Reilly package. See:
http://jakarta.apache.org/commons/fileupload/
--
Martin Cooper
On 12/27/05, Lamberto Altieri [EMAIL PROTECTED] wrote:
Hi there,
I have a problem!
I must send a post multipart/form-data message from an applet to a
servlet,
I wrote this piece of code:
try{
// Create a socket to the host
String hostname=localhost;
int port=8080;
InetAddress addr=InetAddress.getByName(hostname);
Socket socket=new Socket(hostname,port);
// Construct data
String dataA=--AaB03x\r\n,
dataB=Content-Disposition: form-data; name=\submitter\\r\n,
dataC=\r\n,
dataD=Larry\r\n,
dataE=--AaB03x\r\n,
dataF=Content-Disposition: form-data; name=\files\;
filename=\file1.txt\\r\n,
dataG=Content-Type: text/plain\r\n,
dataH=\r\n,
dataI=... contents of file1.txt ...\r\n,
dataL=--AaB03x--\r\n;
int len=dataA.length()+
dataB.length()+
dataC.length()+
dataD.length()+
dataE.length()+
dataF.length()+
dataG.length()+
dataH.length()+
dataI.length()+
dataL.length();
// Send header
String path=/upload/requestupload;
BufferedWriter wr=new BufferedWriter(new OutputStreamWriter(
socket.getOutputStream()));
wr.write(POST +path+ HTTP/1.0\r\n);
wr.write(Content-Length: +len+\r\n);
wr.write(Content-Type: multipart/form-data;
boundary=--AaB03x\r\n);
wr.write(\r\n);
// Send data
wr.write(dataA);
wr.write(dataB);
wr.write(dataC);
wr.write(dataD);
wr.write(dataE);
wr.write(dataF);
wr.write(dataG);
wr.write(dataH);
wr.write(dataI);
wr.write(dataL);
wr.flush();
// Get response
BufferedReader rd=new BufferedReader(new InputStreamReader(
socket.getInputStream()));
String line;
while((line=rd.readLine())!=null)
System.out.println(line);
wr.close();
rd.close();
socket.close();
}
catch(Exception e) {e.printStackTrace();}
but this kind of error is thrown by tomcat 5.5:
24-dic-2005 1.45.27 org.apache.catalina.core.ApplicationContext log
GRAVE: error reading or saving file
java.io.IOException: Corrupt form data: premature ending
at com.oreilly.servlet.multipart.MultipartParser.init(
MultipartParser.java:205)
at com.oreilly.servlet.MultipartRequest.init(MultipartRequest.java
:222)
at DemoRequestUploadServlet.doPost(DemoRequestUploadServlet.java:80)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(
StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(
StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke(
StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(
ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(
StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(
CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(
Http11Processor.java:856)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection
(Http11Protocol.java:744)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(
PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(
LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
ThreadPool.java:684)
at java.lang.Thread.run(Unknown Source)
I use cos.jar crated by o'reilly for reading the multipart/form-data
message.
Is this an encoding problem? Can you help me?
If you need further info.
Thanks
Yours,
Lamberto Altieri
Re: Notice of intent.... #2
On 1/10/06, Henri Yandell [EMAIL PROTECTED] wrote: As a second email in the Notice of intent series; here's what I think being a Jakarta component will be like in the future. * Jakarta is a collection of components. Hopefully all sitting at the same level. ie) a big bag of things. * Groups exist. These are categorically not subprojects, but a way to allow for slicing of the website etc. Some groups may have their own mail list; thus the importance of making sure they don't become subprojects. An important rule will probably be that they must do votes on the main list. I prefer the term groupings (which, interestingly, you switch to below ;) over groups. I also think we should allow the component:grouping relationship to be 1:N, since not all components will fit tidily into a single grouping. As a corollary, I don't believe groupings should have their own mailing lists. Hopefully we can keep it at a point where the groups are really just there to refine the flow of mail, not to separate it. HttpComponents is an example of this (though not a good one as most of its components came from HttpClient). WebComponents (formerly hoped to be known as Silk) is another example. Commons would be groupalized out. Hopefully. Groupings are not vague names - HttpComponents good, Silk bad. CoreComponents good, Turbine bad. The idea with that being that boring grouping names are intentionally dull, no subcommunity identification. * No svn authentication beyond being in the jakarta group. Velocity coders have rw access to POI. * Improved Committer-PMC process. Chair's responsibility (I've failed at this so far) is to turn around the new committer process. A new committer of 6 months is effectively voted against going to the PMC, not for. Might not be able to make it exactly that way, but the idea being that joining the PMC is the exception, not the norm. Personally I'd like to see committership be removed if people repeatedly are not allowed onto the PMC. Well, except that the process is that the PMC has to vote in a new committer to the PMC and then notify the board of that vote. I'm definitely not in favour of magic notifications to the board when the six months are up, without an associated vote. * Application of Commons thinking. Not entirely sure on this one as I think we've overcomplicated things in Commons a bit; but things like a common build system, common site system etc. * Sandbox becomes a Jakarta resource, not a Commons resource. Much of the same rules as it has currently. Probably a separate mailing list. A separate mailing list for the sandbox would be a double-edged sword.Yes, it would keep the noise out of other mailing lists, but it also, at least, partially condemns sandbox components to death, by limiting their exposure much more than now. And if everyone has to subscribe to the sandbox list anyway, to know what's happening, then a separate list is of limited utility. -- Martin Cooper - Shout, scream, yell :) Hen On Mon, 12 Dec 2005, Henri Yandell wrote: dum de dum de dum. Just to be public so that it doesn't look like I'm sneaking around trying to manipulate things. -- I'm starting to open the question of TLP on many of the Jakarta dev mailing lists. It's with a general plan where we would see another half a dozen subprojects move to TLP and then really leave Commons as the main entity inside Jakarta along with some commons-like components that are currently subprojects. I've been talking unofficially with lots of people at ApacheCon, so I've had a fair bit of feedback on various bits. The important part is that the loose plan above finds a way to coalesce the Jakarta community into a much tighter, more TLP e like project. I've talked with a couple of board members to feel out things would be. One question being, is it a problem if we're pushing a TLP with just a few committers. The answer I had was that Excalibur is the example TLP, it's rather dormant and it's not a problem. I was also advised to be a bit more active in pushing forward. I think this makes sense, a lot of our cross-community activity is gone because people with high activity tend to move to TLP, so we need a bit more drive to get things done. Thus the change of tack that I'll be trying to pull off without getting hung :) Please discuss, argue, wibble; but what I'm looking for are active ways forward instead of maintaining the status quo. I don't think the status quo is good for Jakarta as an entity, it puts strain on our oversight because the number of subprojects stretches the chair's and community in general's ability to keeps things covered. *denies the blindfold and stands against the wall waiting* Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: Jakarta stats
On 1/12/06, Henri Yandell [EMAIL PROTECTED] wrote: On Thu, 12 Jan 2006, Danny Angus wrote: I'm one of the 1) Inactive PMC members : 39 For historical reasons I made it onto this PMC just as the project I was really involved with (James) got promoted to TLP. I hung around to try to help make sure that Jakarta didn't die as a result of all the reorganisation, and wasn't killed off because we failed to provide adequate oversight while we carried out the controlled expansion of the PMC. On the one hand I think it may be time for me to move on, on the other hand I think that Jakarta PMC might benefit from the continuity provided by letting the interest of me and the others like me fade away as Jakarta continues to evolve. Whatever I think, I would happily relinquish my PMC vote if the active PMC members think it would help in any way. Personally, I think that as long as we don't have to have any form of quorom, and as long as the inactive PMC member is on the mailing list (which really means they're not completely inactive), then it's not a problem. We do need quorom on one issue: The Chairman or any member may be removed from the PMC by a 3/4 vote of the PMC. Of course, we only have 60% active right now, so presuming only committers to the current Jakarta voted, that line of the charter would be impossible. What, you think we're going to let you off the hook as PMC Chair any time soon? Ha ha ha! ;-) -- Martin Cooper Not a biggy I think, I think the chair can sidestep the charter if the community allowed it and removing the chair is more about the PMC sending a vote of no confidence to the board regardless of %, the board's interpretation of that vote would be subjective. ie) I doubt a chair could be removed for doing what the board said had to be done. 75% or no 75%. :) It's one of the places where Jakarta modelled itself on the ASF, but isn't the same as the ASF. -=-=-=-= Mostly I'm worried about: PMC members who are not on pmc@ (there's a handful) PMC members who are not on general@ (never looked. I will soon) Inactive committers who are not on the PMC (200+) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jakarta struts binary
On 2/8/06, John Armstrong [EMAIL PROTECTED] wrote: I'm trying to learn java struts and an old Jakarta Struts book is telling me to go to jakarta.apache.org for the jakarta struts binary. When I go there there's no mention of such under downloads. There's just Struts under Ex-Jakarta, and when I go there, there's numerous downloads besides Jakarta Struts Binary. How can I get the Jakarta Struts binary for Windows? Struts is no longer part of Jakarta, so it's now Apache Struts. If you're just starting to learn Struts, you'll probably want to start with our most recent GA release, which is Struts 1.2.8. You can find that on the Struts downloads page, here: http://struts.apache.org/downloads.html For documentation, you'll want the corresponding release web site, here: http://struts.apache.org//struts-doc-1.2.8/index.html Hope that helps. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subproject Charters
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: I notice that Commons and HTTP Components both have charters. Other subprojects may have them and I've just missed in my very quick look. Do these serve any purpose? Are they a legacy of the days when we tried to create an ASF-like structure within Jakarta to organize things? They were originally created to define the (sub)projects we were creating, and they still serve that purpose. If you get rid of the charter, where would you propose that we define the purpose and scope of these projects? And what would you call that if it isn't a charter? Any reason not to go ahead and kill these subproject charters? Yes. See above. There needs to be some place where we state the official purpose and scope, and that isn't just some words that someone happened to use as a description on some page that's part of the site. Say some Prolog constraint framework decided it wanted to be part of Commons. Where would you point them to explain that that's not what Commons is about? -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Two community proposals
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: I started to write a long email on the problems in Jakarta, on umbrellas, on the lack of a Jakarta community and existence only of subcommunities and on how it should be there is no Jakarta Xxxx, you are members of Jakarta - not a subproject; but you've heard it all before. So, proposal: - Given that we are one project and that we should be acting as one community - I propose that we: 1) Remove SVN restrictions, all Jakarta committers can commit anywhere in Jakarta, with the exception of the Commons-Sandbox as it allows Apache committers in general to commit. What problem is this solving? I just don't see the need. 2) All vote threads to occur on the general@ mailing list; or the pmc@ mailing list if deemed private. I agree with Sandy on this one. The votes should stay on the relevant developer list. -- Martin Cooper - Comments? The only negative I have for 1) is that I like to use the commit lists to see who is on which subproject (for 3 PMC member oversight checking), but that is a flawed idea anyway. The real way is to see who is voting on issues (especially releases) for that project. If it's an inactive project, the real way is to ask the -dev mailing list for 3 PMC replies else the subproject gets mothballed. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: I really shouldn't be sending multiple emails at the same time - you'll all jsut end up replying to one of them. However, itching while the itch is present. Alexandria is dead. We need to represent it as so on the site. Why? You're trying to save one mouse click? It's clear as day that it's dead as soon as you click on the link. ECS, ORO, Regexp are inactive development-wise - represent - site. Slide, POI, Turbine, JCS seem pretty inactive - should we represent such? Why do we need to do this on the front page? Each site can say whatever it needs to, since, as you indicated in a subsequent message, there are many different flavours of done-ness. I think about the only person that needs such a summary on one page is you, Hen. ;-) And it's just one more thing to maintain that means updating the Jakarta site instead of the subproject site, which is backwards to me. -- Martin Cooper What labels should we use? I suggest: * Delete Alexandria. It's at the same level as the java-* CVS stuff, ancient history to be forgotten. * ECS, ORO, Regexp to be moved to a label of Inactive. * Others to be raised as questions separately and voted on. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
