Re: nice
Robert Simmons wrote: Welcome to real life business. In the real world, not everything goes your way. You get to choose between a mass of political bullshit and having no choice at all. you have a choice: open source software. And it's a good choice for real life business, too. cheers :D - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Logging strategy
Has jakarta got a strategy/guideline/regulation that recommends a certain logging api to be used by jakarta projects? Are existing and future jakarta projects allowed to choose between log4j, LogKit, commons-logging or even JDK1.4-Logging? We are currently choosing a logging api and implementation to be used in our business projects. While I favor the power of the log4j implementation, I ask myself if it would be wise to use a -- maybe more future-proof -- thin bridge like commons-logging on top. thanks, Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging strategy
[..] to choose between log4j, LogKit, commons-logging or even JDK1.4-Logging? There is also logging delivered by Avalon-Framework. My personal view is that the makers of reusable components should not log at all and the the logging choice (log4J directly or one of the abstractions here) is the preserve of the application maker (uses many components). I am moving towards a monitor model for 'events' in my components that allow the user of that comp to choose redirection to logging or some other programatic strategy. http://cvs.apache.org/viewcvs/jakarta-avalon-excalibur/altrmi/src/java/org/apache/excalibur/altrmi/server/ServerMonitor.java It can be a bit brittle during development though. - Paul __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging strategy
Dani Estermann wrote: Has jakarta got a strategy/guideline/regulation that recommends a certain logging api to be used by jakarta projects? Are existing and future jakarta projects allowed to choose between log4j, LogKit, commons-logging or even JDK1.4-Logging? We are currently choosing a logging api and implementation to be used in our business projects. While I favor the power of the log4j implementation, I ask myself if it would be wise to use a -- maybe more future-proof -- thin bridge like commons-logging on top. As always, choose the right tool for the job. If you need to be able to switch logging implementations, use Commons Logging. If you need more power, use log4j. If you are 100% sure that you will use 1.4+ Java, and have people accustomed to that logging, use Jdk1.4+ logging. Just see what is more important to your project. If one size fit all, we wouldn't have to choose from ;-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nice
Those who cast the votes decide nothing. Those who count the votes decide everything. --Josef Stalin Robert Simmons wrote: JCP is the Java community process. A federation of hundreds of companies that produces standards (such as EJB) for the Java community. Anyone can be a member and your vote counts. JCP is what Java has that .NET never will and that is why .NET will win. -- Robert - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 3:12 AM Subject: Re: nice Interesting points. Who runs the JCP? Is Apache just a member, or an actual runner? If so, is it Apache's role to comment in anyway on the current disatisfaction with the hidden-ness of the JCP? Or is that the JCP themselves [if such exists] role? [Apache's role, along with all the other top-level members of the JCP]. Hen On Tue, 28 Jan 2003, Andrew C. Oliver wrote: http://rasmussen.homeip.net:8088/fileblog/blog/computers/java/culture#jcp_mys tery -Andy - 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: nice
Real life business shouldn't be bullshit. I'm not going to buy into that. It is people like you who opt into the flawed choices instead of speaking up that allow the flawed choices to continue on longer than they should. -jon +1 Well said Jon. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging strategy
On Wed, 29 Jan 2003, [iso-8859-1] Paul Hammant wrote: [..] to choose between log4j, LogKit, commons-logging or even JDK1.4-Logging? There is also logging delivered by Avalon-Framework. I thought that was LogKit Paul? My personal view is that the makers of reusable components should not log at all and the the logging choice (log4J directly or one of the abstractions here) is the preserve of the application maker (uses many components). Which doesn't really work with reusable components. The developer who uses lots of reusable components has to work with larger, more opaque objects, while the developer who codes anew each time has tight, focused logging. My view has been that an application should use util.log if in 1.4, Log4j otherwise [or LogKit, I just lack experience with it]. A pre 1.4 reusable component should use commons-logging. A post 1.4 reusable component should use util.log. Someone had told me that Log4j was/will-be pluggable behind util.log (?) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging strategy
For frameworks, you can't tell how the end-user will be configured. That's why we switched Tapestry over to commons-logging, so that the end-user can get the benefits of logging, regardless of whether they are using Log4J, javax.logging or something else. We also ship Log4J, since we try to maintain compatibility all the way back to JDK 1.2. The only problem is that Tapestry originally had a special, built-in web page for creating Log4J loggers (nee categories), and changing Log4J levels (nee priorities). This used addtiional methods in Log4J Logger for setting the level, and elsewhere for creating new loggers. The commons-logging folks are pretty adamant that extrending the framework for these operations isn't appropriate. (I disagree, but it's not a fight I'm prepared to wage, or expect to win). Howard - Original Message - From: Dani Estermann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 5:21 AM Subject: Logging strategy Has jakarta got a strategy/guideline/regulation that recommends a certain logging api to be used by jakarta projects? Are existing and future jakarta projects allowed to choose between log4j, LogKit, commons-logging or even JDK1.4-Logging? We are currently choosing a logging api and implementation to be used in our business projects. While I favor the power of the log4j implementation, I ask myself if it would be wise to use a -- maybe more future-proof -- thin bridge like commons-logging on top. thanks, Daniel - 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: Logging strategy
At 11:21 29.01.2003 +0100, Dani Estermann wrote: Has jakarta got a strategy/guideline/regulation that recommends a certain logging api to be used by jakarta projects? Are existing and future jakarta projects allowed to choose between log4j, LogKit, commons-logging or even JDK1.4-Logging? We are currently choosing a logging api and implementation to be used in our business projects. While I favor the power of the log4j implementation, I ask myself if it would be wise to use a -- maybe more future-proof -- thin bridge like commons-logging on top. I believe log4j is here to stay. Its user base is large and growing. As time passes, more people will gravitate to it as it keeps improving. We have enough cool features in pipe to keep us busy for the foreseeable future. Simile, the future is bright and open! Daniel -- Ceki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nice
On Wednesday, January 29, 2003, at 08:32 AM, Henri Yandell wrote: It's only by understanding the JCP and infiltrating it that we have much chance to try and change it though. The whole thing is just one opaque block from here. We have 'infiltrated' it. The ASF is a member of the J2SE/J2EE executive committee (I am the current representative), and we have many members (and non-members) participating in various JSRs. FYI - Through the significant efforts of Jason Hunter, the previous JCP rep, and others (Chuck Murko, for example), the ASF was instrumental in fostering change in the JCP process, and will continue to do so. There is a JCP mail list, but because of various non-disclosure agreements made by the ASF, it's limited to ASF members, who are bound by the same agreements. If there is sufficient interest in an open JCP discussion list, I'm sure we can set that up. geir -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nice
On Wed, 29 Jan 2003, Geir Magnusson Jr. wrote: We have 'infiltrated' it. The ASF is a member of the J2SE/J2EE executive committee (I am the current representative), and we have many members (and non-members) participating in various JSRs. Yeah I know. Thus my questions as to whether Apache/you should/could be saying anything against the negative views of the JCP. FYI - Through the significant efforts of Jason Hunter, the previous JCP rep, and others (Chuck Murko, for example), the ASF was instrumental in fostering change in the JCP process, and will continue to do so. This is about all I do hear regarding ASF/JCP. There is a JCP mail list, but because of various non-disclosure agreements made by the ASF, it's limited to ASF members, who are bound by the same agreements. If there is sufficient interest in an open JCP discussion list, I'm sure we can set that up. Just the FAQs. Like, does Apache have a non-profit membership? So that anyone who is an ASF member is able to be on multiple JSRs, or are you all members via your companies? As a member through Apache, does that cause any legal contractual issues with employers? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nice
Andrew C. Oliver wrote: Those who cast the votes decide nothing. Those who count the votes decide everything. --Josef Stalin Actually, the latest update to this is, The court that decides whether to recount the votes... decides everything. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nice
On Wednesday, January 29, 2003, at 09:38 AM, Henri Yandell wrote: On Wed, 29 Jan 2003, Geir Magnusson Jr. wrote: We have 'infiltrated' it. The ASF is a member of the J2SE/J2EE executive committee (I am the current representative), and we have many members (and non-members) participating in various JSRs. Yeah I know. Thus my questions as to whether Apache/you should/could be saying anything against the negative views of the JCP. Of course we/I can/will. It's no secret that Apache had significant problems with the managing process of the JCP, and much effort was invested to improve it. If you remember, Jason Hunter was on stage at last year's JavaOne's announcement of the changes. While there are still plenty of valid issues that people have with the JCP as a whole, or JSRs in specific, the intent of the ASF's participation is to be a constructive advocate of the way we think that standards and software should be developed. We are just one vote of many - we can say our piece, lobby and try to convince others, support our representatives on JSRs, but at the end of the day, we are just one voice. FYI - Through the significant efforts of Jason Hunter, the previous JCP rep, and others (Chuck Murko, for example), the ASF was instrumental in fostering change in the JCP process, and will continue to do so. This is about all I do hear regarding ASF/JCP. What else would you like to know? What are your specific problems? is there a specific technology/spec that you are interested in participating in? have you ever interacted with the expert group of a JSR via their interest list or during a public, community review? I started my participation by just sending comments to the servlet EG, and I found them extremely responsive, far more responsive that I would have expected for a random comment from the ether. Of course, this differs from EG to EG, just like different communities differ on OSS projects. There is a JCP mail list, but because of various non-disclosure agreements made by the ASF, it's limited to ASF members, who are bound by the same agreements. If there is sufficient interest in an open JCP discussion list, I'm sure we can set that up. Just the FAQs. Like, does Apache have a non-profit membership? So that anyone who is an ASF member is able to be on multiple JSRs, or are you all members via your companies? The ASF is a member. Any ASF member is covered by that agreement, and can thus, if they choose, represent the ASF on the EG if the EG accepts. IIRC, non-members can also represent the ASF on an expert group, but it does require JCP agreements to be signed. Remember, it's up to the expert group to accept members for participation. You are free to represent your company, if you choose. As a member through Apache, does that cause any legal contractual issues with employers? That depends upon your employment agreement/contract with your employer. geir -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging strategy
The only problem is that Tapestry originally had a special, built-in web page for creating Log4J loggers (nee categories), and changing Log4J levels (nee priorities). This used addtiional methods in Log4J Logger for setting the level, and elsewhere for creating new loggers. The commons-logging folks are pretty adamant that extrending the framework for these operations isn't appropriate. (I disagree, but it's not a fight I'm prepared to wage, or expect to win). I agree with you - partially. We should have a config mechansim - but it shouldn't be part of the core logging interfaces. I would vote +1 on an optional interface that allows some basic configuration ( like setting the level for a category ), but I don't think it would get a majority. My prefference is JMX for configuration - log4j already has some support for that, and it would be possible to create mbeans to manage jdk1.4 logging as well ( or other logging impl. ). It is on my todo list ( next to using JDNI java:env/ to select the logger implementation ) - but I don't have the time right now. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging strategy
I'll probably get this functionality by operating directly on the Log4J API, but enabling the page only if Log4J is on the classpath. - Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 10:48 AM Subject: Re: Logging strategy The only problem is that Tapestry originally had a special, built-in web page for creating Log4J loggers (nee categories), and changing Log4J levels (nee priorities). This used addtiional methods in Log4J Logger for setting the level, and elsewhere for creating new loggers. The commons-logging folks are pretty adamant that extrending the framework for these operations isn't appropriate. (I disagree, but it's not a fight I'm prepared to wage, or expect to win). I agree with you - partially. We should have a config mechansim - but it shouldn't be part of the core logging interfaces. I would vote +1 on an optional interface that allows some basic configuration ( like setting the level for a category ), but I don't think it would get a majority. My prefference is JMX for configuration - log4j already has some support for that, and it would be possible to create mbeans to manage jdk1.4 logging as well ( or other logging impl. ). It is on my todo list ( next to using JDNI java:env/ to select the logger implementation ) - but I don't have the time right now. Costin - 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: Logging strategy
--- Ceki Gülcü [EMAIL PROTECTED] wrote: At 11:21 29.01.2003 +0100, Dani Estermann wrote: Has jakarta got a strategy/guideline/regulation that recommends a certain logging api to be used by jakarta projects? Are existing and future jakarta projects allowed to choose between log4j, LogKit, commons-logging or even JDK1.4-Logging? We are currently choosing a logging api and implementation to be used in our business projects. While I favor the power of the log4j implementation, I ask myself if it would be wise to use a -- maybe more future-proof -- thin bridge like commons-logging on top. I believe log4j is here to stay. Its user base is large and growing. As time passes, more people will gravitate to it as it keeps improving. We have enough cool features in pipe to keep us busy for the foreseeable future. Simile, the future is bright and open! I agree with Ceki, Log4j has a bright future indeed. If it were my project, I'd pick Log4J first, then the Merlin logging (even if I were using JDK 1.4). I don't known too much about LogKit, but it's probably fine as well. Don't use commons-logging unless you're absolutely sure you need it. If you are distributing your code to other companies, then you might have an argument for a logging facade in order to plug into their logging framework. However, if your code is intended for internal use only, using a facade is more work with no benefit. - Morgan Daniel -- Ceki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] = Morgan Delagrange http://jakarta.apache.org/taglibs http://jakarta.apache.org/commons http://axion.tigris.org http://jakarta.apache.org/watchdog __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nice
I think the next improvement on who decides should mention guns, anthrax, etc.? At 10:08 AM 1/29/03 -0500, you wrote: Andrew C. Oliver wrote: Those who cast the votes decide nothing. Those who count the votes decide everything. --Josef Stalin Actually, the latest update to this is, The court that decides whether to recount the votes... decides everything. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] LEGAL NOTICE This electronic mail transmission and any accompanying documents contain information belonging to the sender which may be confidential and legally privileged. This information is intended only for the use of the individual or entity to whom this electronic mail transmission was sent as indicated above. If you are not the intended recipient, any disclosure, copying, distribution, or action taken in reliance on the contents of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please delete the message. Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: nice
http://info.astrian.net/jargon/terms/g/godwin_s_law.html Tom -Original Message- From: Micael [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 29, 2003 12:20 PM To: Jakarta General List Subject: Re: nice I think the next improvement on who decides should mention guns, anthrax, etc.? At 10:08 AM 1/29/03 -0500, you wrote: Andrew C. Oliver wrote: Those who cast the votes decide nothing. Those who count the votes decide everything. --Josef Stalin Actually, the latest update to this is, The court that decides whether to recount the votes... decides everything. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging strategy
on 2003/1/29 5:56 AM, Ceki Gülcü [EMAIL PROTECTED] wrote: I believe log4j is here to stay. Its user base is large and growing. As time passes, more people will gravitate to it as it keeps improving. We have enough cool features in pipe to keep us busy for the foreseeable future. Simile, the future is bright and open! Log4J is a perfect example of the failure of the JCP. The JSR for Java logging was a failure because it didn't simply pick up Log4J as the standard. Go Ceki! -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging strategy
On Wed, 29 Jan 2003, Jon Scott Stevens wrote: on 2003/1/29 5:56 AM, Ceki Gülcü [EMAIL PROTECTED] wrote: I believe log4j is here to stay. Its user base is large and growing. As time passes, more people will gravitate to it as it keeps improving. We have enough cool features in pipe to keep us busy for the foreseeable future. Simile, the future is bright and open! Log4J is a perfect example of the failure of the JCP. The JSR for Java logging was a failure because it didn't simply pick up Log4J as the standard. Go Ceki! +1 Politics over de-facto standards. :( Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nice
on 2003/1/29 7:16 AM, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: The ASF is a member. Any ASF member is covered by that agreement, and can thus, if they choose, represent the ASF on the EG if the EG accepts. IIRC, non-members can also represent the ASF on an expert group, but it does require JCP agreements to be signed. Correct. -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nice
So the solution for committers who would like to be involved in the JCP is to hand around their announce list and website, when a particular new JSR is announced they can go volunteer. If successful, then they would do the agreement thing and be an ASF representative? Hen On Wed, 29 Jan 2003, Jon Scott Stevens wrote: on 2003/1/29 7:16 AM, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: The ASF is a member. Any ASF member is covered by that agreement, and can thus, if they choose, represent the ASF on the EG if the EG accepts. IIRC, non-members can also represent the ASF on an expert group, but it does require JCP agreements to be signed. Correct. -jon - 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: nice
Jon Scott Stevens wrote: (...) Real life business shouldn't be bullshit. I'm not going to buy into that. It is people like you who opt into the flawed choices instead of speaking up that allow the flawed choices to continue on longer than they should. IMO, the closeness of the JCP process brings most of the bullshitness of it. Even having open (to read, not to post) lists for the different groups would change a lot of the JCP procedures and results, by making obvious dark political moves attackable from the outside. Regards, Santiago -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nice
Geir Magnusson Jr. wrote: (...) What else would you like to know? What are your specific problems? is there a specific technology/spec that you are interested in participating in? have you ever interacted with the expert group of a JSR via their interest list or during a public, community review? I started my participation by just sending comments to the servlet EG, and I found them extremely responsive, far more responsive that I would have expected for a random comment from the ether. Of course, this differs from EG to EG, just like different communities differ on OSS projects. How did you get a base for your comments? I imagine you were commenting on, let's say, Servlet2.2 when they were working on Servlet2.3, or something similar, maybe a public draft. But when a group gets formed in Jan-2002 (http://www.jcp.org/en/jsr/detail?id=168), and there is no single line of output from it till (http://nagoya.apache.org/wiki/apachewiki.cgi?PlutoProposal), Jan 2003, I don't see a way to send a meaningful comment.Comment on what? When a Draft is published, I expect a response like It's too late to make major changes now, we'll consider for release 2 to any serious comment. You can see what I meant with my previous post about closeness of the process. (...) geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Open ThunderGraph in Jakarta ?
Martin van den Bemt wrote: Love to see a gui framework / tools thingy on apache.. Working on that stuff a lot lately (of course has a Apache Style License) Jesktop (http://jesktop.sourceforge.net/) is written by Apache commiters, Avalon based and could be a good foundation for a GUI project ;-) Regards, Santiago Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator home page (was Tapestry)
Nicola Ken Barozzi wrote: [EMAIL PROTECTED] wrote: This is one of my least favourite features of this forrest skin. Look at this version, which is a modified forrest skin, if it's better: http://www.krysalis.org/centipede/ I took all the suggestions from users like this one and made that skin from the Forrest one. We will evaluate what users prefer from this one for the next CSS-only Forrest skin version coming out soon. It would be great if the abbreviated items had an alt tag with the full name, to be shown as tooltip. Take it as Just one more user suggestion ;-) Regards, Santiago (...) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nice
on 2003/1/29 10:26 AM, Henri Yandell [EMAIL PROTECTED] wrote: So the solution for committers who would like to be involved in the JCP is to hand around their announce list and website, when a particular new JSR is announced they can go volunteer. If successful, then they would do the agreement thing and be an ASF representative? Hen Correct. -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator home page (was Tapestry)
Santiago Gala wrote: Nicola Ken Barozzi wrote: [EMAIL PROTECTED] wrote: This is one of my least favourite features of this forrest skin. Look at this version, which is a modified forrest skin, if it's better: http://www.krysalis.org/centipede/ I took all the suggestions from users like this one and made that skin from the Forrest one. We will evaluate what users prefer from this one for the next CSS-only Forrest skin version coming out soon. It would be great if the abbreviated items had an alt tag with the full name, to be shown as tooltip. Take it as Just one more user suggestion ;-) Ciao Santiago :-) The suggestion is a good one, and it has been fixed a couple of days ago by brother Jeff. Thanks :-) Oh, btw we have also fixed that link highlighting bug and now all our skins validate as HTML4.01. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nice
Yeah, for instance, I was once interviewed for a contract to hire gig at Microsoft. (This was circa '97 prior to my involvment in Java). Had I sold my soul, would I still be able to be a member of Apache? While I do not subscribe to the jcp ot apache det org mailing list due to the NDA contractual obligations surrounding it (hear no evil, see no evil, and therefore speak no evil), what if Jon said Hi Andy, fellow member, here is the scoop on whats going on with JSR-1234 or moreover what if he didn't? Maybe I'm tainted by merely speaking (electronically) with Jon due to his indemic taint of JCPness. So then I go back to work at M$ and start hacking on I dunno ASP or something. Sun gets wind of it and says HEY ASP is stealing our stuff (though we stole it from them) Or since the JCP seeks to create a spec for everything, what if I work for some other company which say puts out anything to do with Micro devices (pdas, etc) or portals. Am I a potential object of litigation just through my association with Apache and Apache's association with the JCP? I'd sure feel a lot less fear, uncertainty and doubt if all my fellow apache members weren't under NDAs carrying around tainted knowledge which is proprietary of Sun. It seems an open process would sure make the JCP a whole lot more appealing. But then I'm weird like that. -Andy - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 9:38 AM Subject: Re: nice On Wed, 29 Jan 2003, Geir Magnusson Jr. wrote: We have 'infiltrated' it. The ASF is a member of the J2SE/J2EE executive committee (I am the current representative), and we have many members (and non-members) participating in various JSRs. Yeah I know. Thus my questions as to whether Apache/you should/could be saying anything against the negative views of the JCP. FYI - Through the significant efforts of Jason Hunter, the previous JCP rep, and others (Chuck Murko, for example), the ASF was instrumental in fostering change in the JCP process, and will continue to do so. This is about all I do hear regarding ASF/JCP. There is a JCP mail list, but because of various non-disclosure agreements made by the ASF, it's limited to ASF members, who are bound by the same agreements. If there is sufficient interest in an open JCP discussion list, I'm sure we can set that up. Just the FAQs. Like, does Apache have a non-profit membership? So that anyone who is an ASF member is able to be on multiple JSRs, or are you all members via your companies? As a member through Apache, does that cause any legal contractual issues with employers? 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: nice
And they would not be able to collaborate with their fellow members who are not in the expert group due to NDAs. -Andy - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 1:26 PM Subject: Re: nice So the solution for committers who would like to be involved in the JCP is to hand around their announce list and website, when a particular new JSR is announced they can go volunteer. If successful, then they would do the agreement thing and be an ASF representative? Hen On Wed, 29 Jan 2003, Jon Scott Stevens wrote: on 2003/1/29 7:16 AM, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: The ASF is a member. Any ASF member is covered by that agreement, and can thus, if they choose, represent the ASF on the EG if the EG accepts. IIRC, non-members can also represent the ASF on an expert group, but it does require JCP agreements to be signed. Correct. -jon - 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: nice
There is a JCP mail list, but because of various non-disclosure agreements made by the ASF, it's limited to ASF members, who are bound by the same agreements. If there is sufficient interest in an open JCP discussion list, I'm sure we can set that up. +1 - especially if a goal of it is to foster change within the JCP and promote an open model for the JCP and Java. -Andy geir -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-247-1713(m) [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: Logging strategy
Nicola Ken Barozzi wrote: As always, choose the right tool for the job. If you need to be able to switch logging implementations, use Commons Logging. If you need more power, use log4j. If you are 100% sure that you will use 1.4+ Java, and have people accustomed to that logging, use Jdk1.4+ logging. Just see what is more important to your project. If one size fit all, we wouldn't have to choose from ;-) I understand most of the logic here except for the idea that one should use 1.4 logging if using jdk 1.4. Log4j is a more powerful logging tool, so why not use it in the 1.4 environment as well? Granted, 1.4 logging being embedded in the environment makes it a tempting choice as default. And if log4j cannot provide compelling features to convince developers to use it instead of the 1.4 logging, then yeah, developers should use 1.4 logging. I don't think that is the case, even with 1.4 logging basically ripping off the log4j design/interface. And we are going to continue to innovate at a faster pace than Sun or the JCP. http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/Log4jv13Featu res for a biased list of new, upcoming features. I'm the only committer that has updated this page so far. :-) -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Discussion] (Fake)Forrest for Jakarta!
Hi all! I saw the Tapestry discussion, and this remindet me, that I wanted to carry FakeForrest to Jakarta! So what is it? Simple: It's a set of 2 Velocity/Anakia template-files and some images. The Velocity templates are build upon the Jakarta-ones and follow the Jakarta-Anakia-DTD! What does it? It renders Anakia-build websites with the (current - with some small modifications - see below) Forrest skin. Where can I find it? We currently use this to build the http://ant.apache.org website so you can preview the result there and the sources are in the Ant-cvs http://cvs.apache.org/viewcvs/jakarta-ant/xdocs/stylesheets/. Why should we use it? IMHO it is the FASTEST way to provide a nice, functional and consistent look of the entire xxx.apache.org website! Are there any limitations? Yes: Currently there are no multiple tabs for menues on the left side, but this can easyly be solved by allowing multiple menu-sections in the proect.xml Additionally: We (Conor ;)) recently fixed some incompatibilities with the HTML 4.01 standard so it now generates validatable HTML 4.01 code! It's proved, it works, it's nice ;). Remark: I do not see Fake-Forrest as the final solution, but its a nice and fast way in moving to a nice new, consisten etc. look of the Apache website, as I said before! Thoughts? Christoph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
I feel so vindicated.
http://www.freeroller.net/page/ara_e/20021214 I think we are going to see more and more of this over the coming year as the economy gets worse and worse and people are expected to produce real working applications. People are going to start to clue in to the fact that EJB sucks. JSP sucks. JCP sucks. Struts sucks. JSTL sucks. People are going to start to look for real solutions to their problems. Not just marketing hype and bullshit business practices. I feel so vindicated. How many years have I been saying the same thing over and over again? =) -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LGPL beans imported into code at Apache....
Pier, The end of the thread on cocoon-dev... http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] gmsgId=625635 We came to the conclusion (I believe) that we don't _want_ it. Agree. Much better truly open linkables. Roughly the whole thread: http://nagoya.apache.org/eyebrowse/SearchList?listId=listName=cocoon-dev%40 xml.apache.orgsearchText=LGPLdefaultField=subjectSearch=Search An interesting read... different subject/ I am not sure of Steffano's assertion that a Cocoon block can be GPL from the last of that thread.. If it does an import of org.apache.anything it is in trouble from my understanding of RMS's typed GPL wisdoms (pasted below from http://www.fsf.org/licenses/license-list.html#GPLIncompatibleLicenses ) : The Apache License, Version 1.1 http://www.apache.org/LICENSE-1.1. This is a permissive non-copyleft free software license with a few requirements that render it incompatible with the GNU GPL. We urge you not to use the Apache licenses for software you write. However, there is no reason to avoid running programs that have been released under this license, such as Apache. As far as I know this covers any alleged GPL work importing org.apache.* and any Apache 1.1 licensed work importing anything that is GPL. I appreciate we have our own stand in this (the link to which I have lost), that basically says we can't see the problem and want clarification from the FSF. - - - With respect to LGPL, I am proceeding carefully with use with great care. As it happens the LGPL lib in question is proving difficult to use... - Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT] JXPath 1.1 Beta 1 released
JXPath 1.1 Beta 1 has been released. We released JXPath 1.0 in July 2002. Since then we have added some new features, fixed a significant number or problems, refactored and beefed up the JUnit test system. The package has been very stable for quite some time. Please see draft release notes at http://jakarta.apache.org/commons/jxpath/release-notes-1.1.html Home page: http://jakarta.apache.org/commons/jxpath Downloads (source and binaries): http://jakarta.apache.org/builds/jakarta-commons/release/commons-jxpath/v1.1 b1 Dmitri Plotnikov [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
