Re: [VOTE] Merge dev lists
+1 On Mon, Oct 19, 2009 at 1:02 PM, Rahul Akolkar rahul.akol...@gmail.com wrote: This is a vote to consolidate the development lists at Jakarta into one development and one notifications list. For background including timing, anticipated benefits and some discussion, see proposal [1] thread. [X] +1 [ ] -1 - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [VOTE] Release 1.8.1 of Cactus
[+1] Go Speed Racer, go. - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [VOTE] Cactus 1.8.0
Ok, here is my +1 again. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Cactus 1.8.0 Release Candidate
+1, for sure... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Petar Tahchiev as Jakarta Committer
Hi all, I'd like to call a vote to have Petar Tahchiev as a Jakarta Committer. Petar currently works as software engineer in Bulgaria, but was a MSc student last year, when we proposed porting the Cactus build to Maven 2 as a GSOC (Google Summer of Code) project. Although the project didn't make it to the allotted ASF projects, Petar kept doing the (hard) work, despite my slowness to support him. Prior to participate on Cactus development, he made some contributions to Apache Ant and other ASF projects. He also has a blog at java.net (http://weblogs.java.net/blog/paranoiabla/). A couple of months ago, I failed (again :-() to setup a sandbox SVN branch at ASF for him to continue his work, so he ended up creating a separated repository on SourceForge where we could do some work in parallel. Now that code is ready to come back to the Jakarta codebase, and the proper legal measures has already been taken (see http://incubator.apache.org/ip-clearance/jakarta-cactus-tahchiev.html). Besides the technical aspect, I can tell from personal experience that he is a talented and enthusiastic developer, and will be a valuable contributor to the Cactus/Jakarta communities. So, here is my (PMC binding) +1 vote. -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Activity
Henri Yandell wrote: Mail: (Aug 19 data) 192 - jakarta-cactus-dev Cactus-user doesn't show up because its archives are broken on mail-archives. Nothing since 2003. Cactus-user has had more activity than the cactus-dev, which get most of its message from Gump notifications (for instance, I've just checked my mailbox and 136 Gump messages were sent in the last 3 months). Anyway, I'm owing a reply to the general list regaring the testing TLP - I will talk more about Cactus status once I send that reply... []s, -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Activity
Henri Yandell wrote: Mail: (Aug 19 data) 192 - jakarta-cactus-dev Cactus-user doesn't show up because its archives are broken on mail-archives. Nothing since 2003. Cactus user has had more activity than the cactus-dev, which get most of its message from Gump notifications (for instance, I've just checked my mailbox and 136 Gump messages were sent in the last 3 months). Anyway, I'm owing a reply to the general list regaring the testing TLP - I will talk more about Cactus status once I send that reply... []s, -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing.apache.org, take 2
Hi Phil, On 6/23/06, Phil Steitz [EMAIL PROTECTED] wrote: With his permission, I am forwarding an excerpt from a recent post from Roy Fielding, in response to questions about a proposed Security TLP originating out of the XML project. The concerns he raises below all pretty much apply directly to Testing. That post pretty much explain the umbrella issue; it would be nice to have it somewhere on Apache's site, so it can be used in other situations. Could be the right approach here is to limit it to Cactus + Jmeter, or even have them each TLP separtately. That was Hen's original idea, but it faded away as these projects didn't feel confident enough to have a TLP of their own (for instance, I'm pretty much the only active Cactus committer right now, and not that active; JMeter is being more active commmitter-wide, but they were not willing to be TLPed alone). OTOH, we had drawn the attention of more people - many of them current Jakarta PMC members, like Rahul, Dion and Yoav - once we pushed the testing TLP, so maybe the JMeter+Cactus TLP could be doable now, although it still requires some decisions/definitions (see below). I think the key is really point 1. above as well as Roy's argument below about not claiming dominion over a topical area. Ok, I agree. So, let's say we decide to promote Cactus+JMeter to a TLP of their own, but not the broad testing.apache.org; I have 3 questions: 1.What should it be named ? 2.What exactly do these 2 projects have in common so they can be grouped together? 3.Could the TLP accept more projects? What's the criteria? Here are my preliminary answers: 2.This is the crucial point and ca be the guide for 1 and 3. Consider the project originated from Jakarta, whose roots come from the Java in the server side, we could work on something related to Java EE Testing or Server-side Java Testing. 1.I'm too bad on naming (JCacter? MetrusJ? :-). 3.My guess is that once 2 is answered, we would have a criteria for letting new projects be incorporated to the TLP. Roy Fielding on 6/22: A federation is simply an umbrella project with no significant responsibilities of its own -- all of its projects report directly to the board and simply view the federation as a communal thing. I think XML and Jakarta should already fall into that category. Starting one is just like starting a project, except that the purpose is limited to community/commons like things and not actual products. Please forgive my ignorance, but I didn't understand this conclusion: does it means we could have testing as a 'federation TLP'? Os does the federation concept would apply to the Cactus+JMeter project? []s, -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
testing.apache.org, take 2
Hi all, Sorry for being quiet so far regarding this issue, but I've been too busy with other real-life subjects (besides, it's World Cup time :-). Anyway, I've read all messages and will try to write a 'condensed' reply of all pertinent issues, plus a couple of statements summarizing them. As such, it's going to be a long email - so, if you don't have the patience to read all replies (I wouldn't :-), jump straight to the end... On Jun 6, 2006, at 6:13 PM, Rahul Akolkar wrote: Yup, there clearly is developer/community interest towards the formation of this project. I second Rahul's comment here. In fact, the proposal started as an effort from Hen to emancipate some projects (Cactus and JMeter) out of Jakarta, but there are many other projects interested to join the new TLP (I will talk more about those projects later). Plus, there is a chance to rejuvenate some existing projects by sheer proximity to newer projects with active developers (amongst other things). This is another good point: one motivation for the TLP is to bring momentum back to some dormant projects (like Cactus). I'm aware this motivation could be dangerous (we could, for instance, end up with a dormant TLP, which is worse than a dormant sub-project), but I'm still confident it's worth a try. Per the umbrella concern, the question then becomes what -- if any -- are the mitigating factors that can address such a concern with regards to this proposal. Ok, that makes sense: such mitigating factors should be on our proposal for the next meeting (I will bring them back after the replies). On Jun 6, 2006, at 9:47 PM, Henri Yandell wrote: It's more in our court to come up with something to convince them I think. Ok, let's try to come out with concrete arguments for the next meeting. Mostly I think we need to detail the cross-ASF interest in the idea. Otherwise Jakarta Test Ok again, let's do that. So far, I can list the following: - Struts developed some testing artifacts also used by MyFaces - WebWork - which has 'merged' into Struts - seems to have some testing stuff which could be migrated to the TLP - Cactus is (I believed) used by other JavaEE related projects (like Geromino and Struts) - we (Rahul and I) have been contacted in private by committers of other ASF projects (like Tomcat and Struts) willing to donate some code to the new TLP - as mentioned in previous messages, there are many other examples of testing artifacts spread across ASF projects that could be migrated into the new TLP. Of course, each case should be analyzed in particular, as not all of then might be suitable for the TLP, but the point is that we have a 'market' for the TLP. On Jun 9, 2006, at 2:50 AM, Phil Steitz wrote: I would also like to understand exactly what the problem is I think the problem is the fear that the TLP, as an umbrella project, grows up in an unorganized way and becomes more of a problem than a solution. and what mitigating steps may be possible. One such step is to have well defined rules on how an existing project would be accepted in the TLP. For instance, the proponent should 'prove' that the new project would aggregate value to the TLP, either technically and/or by bringing 'development momentum'. Another step (related with the previous one) is to define the incubation/sandbox mechanism for such new projects in a way a little bit more rigid than the regular incubation process. In particular, I would very much appreciate a definition of umbrella that allows Geronimo, Logging, Jakarta Commons, DB, XML, Web Services and Struts, but somehow disallows Testing. As others have already pointed out (sorry again for the delay on the reply :-), that definition is not a consensus. Anyway, I think Geronimo and Struts could be risked off the umbrella moniker, as they are focused in a concrete product and not on a generic concept (like the others). Besides, Jakarta Commons - which is the most 'problematic' umbrella, as it's very broad - is not an TLP, but a Jakarta sub-project (well, that's another issue...). On Jun 9, 2006, at 8:55 AM, Jesse Kuhnert wrote: It makes sense that people want to be careful about a tl subdomain. Some of the projects you mentioned are fairly staple diets to a good majority of development projects. (ie struts/logging/xml/commons/etc) . Yes, that's sort of what I meant previously (sorry for the redundancy). Maybe we (ASF) need a formal definition of what makes a TLP: for instance, it could be either a major project with some minor sub-projects (like Struts, Tomcat, Geronimo, Maven, Tapestry, etc..) or the (in) famous 'umbrella' (like Jakarta, DB, XML, Logging, Commons and hopefully Testing). In other words, we would be treating the umbrellas as 'first-class TLPs', and not some sort of 'failed experiments' (please note that I'm not affirming the aforementioned projects are failures, much the opposite. It's just a lack of a better expression :-( What would go into testing.apache.org? I'm all for it as testing
Re: testing.apache.org
Hi Jesse, Initially, the idea was to provide Java-related testing projects. Not that we were against a language-agnostic project - we just didn't think about that. After the proposal, someone raised the questions if we would accepts contributions from other languages and we said it would be fine. So, answering your question, yes, the project is supposed to support libraries from another languages. In fact, the existence of such libraries is an argument for the TLP creation; besides the existing Cactus and JMeter, we have at least 3 sub-projects contenders (the 2 you mentioned and one for testing HTML pages), 4 if we count DbUnit (although this one will take more time due to the licenses incompatibility). -- Felipe Jesse Kuhnert wrote: I hope I'm not butting in in the middle of a known conversation, but was testing.apache.org generally supposed to hold any sort of shared libraries for testing? If so I've got some things I could donate right away, like a dojo test ant task / others. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Move Jakarta Cactus/JMeter to new Testing TLP
Henri Yandell wrote: The answer, I believe, is that yes testing.apache.org would welcome communities built around non-Java test tools. . ie) No indecipherable code dumps, but if a facet of the testing community wants to build around a language other than Java - the more the merrier. Any disagreement with that? The board meeting is next week (I assume, I'm fine with that, as much as the 'welcomeness' does not become an obligation. I mean, we would be open to it, but cannot guarantee we would have the resources available to mentor the incubation of such facet in our TLP - does it make sense? -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Move Jakarta Cactus/JMeter to new Testing TLP
On 4/24/06, Andrew C. Oliver [EMAIL PROTECTED] wrote: BTW, while I simply don't care on this particular issue. I object to the bizarre form of this vote by procedure as a matter of practice. On these issues: 1. If you don't get any response from the dev list of that project coming to the PMC with a vote seems to be call votes until I get the answer I want -- which I have always thought was a bit off. Actually, this is not quite what happened - when this message was proposed on Cactus before, it had enough +1 votes. Besides, these 2 projects have few active commiters nowadays (at least Cactus, not sure about JMeter). 2. The odd form of the vote. +0 is support but won't help and +1 always provides for help. While Apache is a meritocracy rather than a do-ocracy (and believe me...it is different) this ensures that the project will have enough of the labor support that it will need. Removing the labor component of the vote is just plain ill-advised IMO. The reason I've change the vote template is that when Henri send the first proposal to the PMC list it didn't have enough votes (even +0) and he concluded the vote was not approved, but then people complained they should have voted +1 but missed it. No need to explain this to me, I'm just explaining why I may -1 on form and not substance anything that is done this I agree with some of your points and I am not willing to explain/justify the vote (even though I have provided some explanation above), but if you didn't agree with the proposed process, you should have complained on the PMC list before the 'ballots' were sent of (I've sent a message with a template to the PMC prior to the official vote request and the only reply I got was from sebb stating JMeter is not dormant, so I've changed the message to reflect that). way in the future. Yet, I'll of course ignore it if I simply don't care enough about the success for failure of the issue, but I don't think it will fail, as we had enough people interesting on contribute and even suggesting the migration of more projects to the new TLP. silence in this case is not consent :-) No problem, is good to head divergent opinions (although it would be even better if they were expressed before :-( []s, -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Move Jakarta Cactus/JMeter to new Testing TLP
Hi all, In the last months, there have been some discussions internally (at Jakarta PMC, Cactus and JMeter lists) about creating a new Testing TLP (Apache Top Level Project) and moving Cactus and JMeter out of Jakarta to this new project (which eventually could grow and 'acquire' more projects, like DbUnit). The overall consensus seems that such TLP should be created, even though the previous proposal did not get enough votes (looks like it was an misunderstanding from the way it was proposed). So, in order to move the process ahead, I would like to propose a new vote here on the general list (I will notify the dev lists about it). The options are: [ ] +1 I am favorable to the move and would like to contribute to the new TLP [ ] +1 I am favorable to the move but would not be participating in the new TLP [ ] +0 it does not matter to me [ ] -1 I am against it because Notice that I have included 2 +1 options to make it clear that voting +1 does not imply a participation in the new TLP - it only means an agreement that these projects should leave Jakarta to form a new TLP. OTOH, people willing to contribute to the new TLP might also propose themselves to its PMC by editing the proposal on Jakarta's wiki (http://wiki.apache.org/jakarta/TLPCactusAndJMeter). []s, -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of JakartaBoardReport-June2006 by FelipeLeme
You're right - good catch! Dennis Lundberg wrote: Cactus 1.17.2 was released on March 26th, 2006. Shouldn't that be 1.7.2? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Remove SVN restrictions
On 4/6/06, Henri Yandell [EMAIL PROTECTED] wrote: Etiquette-wise, it's good etiquette to send an email prior to your first changes to a codebase. Yes, you're right. And in fact I've intended to do so: I subscribed to the dev list prior to committing but somehow I forgot to send that message (to be honest, maybe I unconsciously though the commit would not work :-). Make sure that people who are currently active in that code know that you're about to jump in too. OK, I will send a message to commons-dev about it - better late than never... No need to email pmc@, they should all be on [EMAIL PROTECTED] Should is a tricky word :-) []s, -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Notice of intent]: Make Jira auth like SVN
On 4/6/06, Henri Yandell [EMAIL PROTECTED] wrote: Anyone know if Bugzilla has the same issue? I haven't used Bugzilla for a while, but as far as I can remember (from the taglib days), it's quite the opposite: everyone (and I mean every bugzilla user, not just jakarta commiters) can do whatever they wish with the issues - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Remove SVN restrictions
Hi Hen, On 4/3/06, Henri Yandell [EMAIL PROTECTED] wrote: Following this email I'll modify things such that we have the following auth groups: jakarta (union of all jakarta-* groups + tapestry) jakarta-pmc (remains the same) jakarta-commons-sandbox (difference of jakarta group and old j-c-s group) jakarta-poi (remains the same) The modifications have taken effect: I was able to commit some files on commons-jelly regarding a couple of patches I have submitted one year ago. Now that brings another question: what should we do regarding Jira issues? I mean, I'm not 'officially' a Jelly developer, so I'm not on the Jira's jelly-developers group (or whatever it's called), so I could not mark those issues as closed (even though I could change the code base). What should we do on these cases? Should we cast a 'Remove Jira restrictions' vote or should this situation be decided on a per-project basis? []s, -- Felipe PS: I've CC this message to the PMC list, but I'm not subscribed there with this email address... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove SVN restrictions
Henri Yandell wrote: [X] +1 [ ] -1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove SVN restrictions
Hi Rahul, Cactus hasn't got away yet, but assuming it does, you can sign yourself as a PMC for the new project - you're help would be greatly welcome. -- Felipe PS: here's Hen's message about signing up: http://mail-archives.apache.org/mod_mbox/jakarta-cactus-dev/200603.mbox/ajax/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/jakarta-cactus-dev/200603.mbox/browser On 3/27/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Too bad cactus got away, I recently had taken a fancy ;-)
[ANN] Cactus 1.7.2 has been released
The Cactus project is pleased to announce the release of version 1.7.2. Cactus is a unit testing framework for testing server side java code. Goals - This release was created just because the previous 1.7.x releases have bundled an LGPL jar (jboss-j2ee.jar, necessary to run the samples), which is not allowe by ASF policies. Other than that, the only technical change is a new feature on the Maven plugin (https://issues.apache.org/jira/browse/CACTUS-231). Changes --- Please check the Changes page at http://jakarta.apache.org/cactus/changes.html for a full list of the changes in version 1.7.2 Known limitations and bugs: --- See http://issues.apache.org/jira/browse/CACTUS . For more information about Cactus, please visit http://jakarta.apache.org/cactus/ . Have fun, -The Cactus team
Re: Jakarta Sandbox?
Hi Rahul (and others), First of all, sorry for the delay (but as they say here Better later than never :-) No, I haven't heard from Pierre and I guess he haven't heard from his managers (as normally he is quick on answer such issues). My feeling is that Sun will not put any efforts on Jakarta Taglibs, as they have an OSI-approved OSS project going on with Glassfish. Still, I think it worths to create a separate sub-project for the Standard Taglibs - even if it's DOA on activity, it's still a different project (because of the TCK, history, importance of JSTL, etc...) -- Felipe Rahul Akolkar wrote: From the initial email in this thread: On 3/6/06, Henri Yandell [EMAIL PROTECTED] wrote: snip/ Additionally we have Jakarta Web Components, which will take on various bits - including Jakarta Taglibs (can't recall if the Standard Taglib would go in there or not). snap/ No, AFAICT. Did you / Felipe hear back from Pierre? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Two community proposals
Henri Yandell wrote: 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. I'm +1 on this one. As others already pointed out, it would help to keep dormant/stable projects more active and would allow committers fixed small bugs on other projects. That's particular useful on commons sub-projects, as its components are used by many projects (for instance, I have submitted a couple of simple patches - including test cases - to Jelly, but they haven't been applied neither commented yet...). -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
Henri Yandell wrote: Inactive Subprojects * Cactus Cactus is more on a 'Hibernation' status; I agree there hasn't been activities in the last weeks, but we have some stuff planned (for instance, I should have relased Cactus 1.7.2 to fix the jboss-j2ee.jar issue, but couldn't do so yet...) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Going to TLP report
Henri Yandell wrote: On the people side of things, that means finding Manual, getting his permission and then talking to any other committers (who'll probably be fine with it I suspect if Manual has said yes). Good news - I've found Manuel and he agreed; I also 'grepped' for the total of authors and there are 13 total. So I have sent another message to the list explaining the situation and more contributors agreed - the tally is now 7/13 and I will wait a couple of days before going after any of the remaining 6 individually... Be sure to use the phrase 'Apache DbUnit' somewhere in the email ;) Or Apache DBUnit... -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STATUS] Chair report Nov 2005
Henri Yandell wrote: - Silk. I'm still unable to understand how we get permission to use the name, and am just posting to the [EMAIL PROTECTED] mailing list every so often. Why? What's the issue with the name? Ideas? Ideas for a new name? Current efforts in this area: archiving inactive Commons Sandbox components. Creating Silk as a future for Taglibs and other subprojects. By speaking of Silk, what's the status? I haven't seem any message here @general (or at the wiki) about the project for weeks... -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fw: Subscribing a new Project into Jakarta
[EMAIL PROTECTED] wrote:
projects, but still, i must ask this to the FtpServer developers (i don´t
know who they are).
Hmm, there is a Maven-generated link that says Who We Are :-)
I didn´t find this information on the site.
Here is the link I mentioned:
http://incubator.apache.org/projects/ftpserver/team-list.html
(of course, you must change the {at} for @ and {d0t} for . :-)
-- Felipe
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Naming for new Jakarta subproject
Henri Yandell wrote: Please vote from the following shortlist of names. Please ignore the Web vs Web App vs Webapp issue for the moment. [X]Apache Silk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebXxxx Naming Was: Web Components/Common project
Martin Cooper wrote: Some other names were added to the wiki page: http://wiki.apache.org/jakarta/CreatingCommonsForWebComponents I forgot to add some names to that page: Webbies(has the same idea of weblets, but causing less confusion) Jakartlets (someone suggested we use a name without Web - it would be cool to be derived from Jakarta then, as Jakarta is tied to server side Java) That would probably add: - web libs - web tools to your list above. (I'm not sure how appropriate 'web libs' would be though, since I'm not sure I'd refer to, say, a compression filter as a 'library'.) Web Tools can be a problem too, as it conflicts with the Eclipse Web Tools Platform. -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Components/Common project
Frank W. Zammetti wrote: point)... It seems like there might be a risk of sub-projects within sub-projects within sub-projects, which I'm not sure would be the best organizational stucture... if you had Jakarta Taglibs as a sub-component of the JWP4J project (assume for the sake of argument that name sticks), and then have Jakarta Standard Taglib as a sub-project of Jakarta Taglibs, is that the best structure to have? How deep of a hierarchy is OK and how deep is too deep? Right now, the Standard is already a sub-project of the Jakarta Taglibs. So, what we meant (sorry for the confusion) is that the Standard wouldn't be migrated to this new project; instead, it would be a Jakarta sub-project, sibling of the new project. Regarding the other taglibs, I agree, it might make more sense for all of them to be direct sub-projects of the new project, instead of having an intermediate taglibs sub-project. But that's something we can decide later one - as we (the Jakarta Taglibs project) decided that we should create new taglibs from scratch (using the legacy code), the structure wouldn't matter at this point. My own JWP project has a taglib package that has individual taglibs within it (AjaxTags, BasicString, etc), so I have the same thing going on... I personally wouldn't go beyond 3-levels like this, and I just wanted to raise the issue now before anything actually moves forward in case others have thoughts on this. I agree - sometimes it makes more sense to aggregate components by functionality than classes. For instance, we could have a Security sub-project which would produce taglibs (like a PageGuardTag), filters and even Struts actions. -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Web Components/Common project
Hello all, What's the status on the new project proposal? Has the discussion moved to another list or has it just staled? Anyway, the Jakarta Taglib Project has voted how it would like to take part on this new project, and the result was: 1.The Jakarta Taglibs Project would like to be merged into the project 2.The Jakarta Standard Taglib should then be a project of its own 3.The remaining taglibs would be gradually migrated to the new project, the most actives first 4.It's not decided yet if the migrated taglibs would have a newer release prior to the migration -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new Standard/JSTL subproject? [WAS Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin]
Henri Yandell wrote: are there any committers involved with JSTL around? Sorry, I raised the question then entered in JavaOne-sleep-mode :( if not, would anyone like to volunteer to sound them out about a move to subproject status? I vote for Standard being a separate Jakarta sub-project. I've mentioned the idea on the taglibs-dev mailing list, no reply as yet. There hasn't being too many messages by the committers lately, specially on votes. So, tomorrow (I'm too tired now :-) I will send a big message summarizing all of these pending votes and hopefully we will get enough committer answers now... -- Felipe - 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]
Martin Cooper wrote: +1 to just one dev and one user list, shared for all components, a la Jakarta Commons. Me too... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of CreatingCommonsForWebComponents by FelipeLeme
I also fixed the alphabetic order of the existing proposals (but accidently typed enter before adding that comment). Apache Wiki wrote: The comment on the change is: - added my suggestions - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
Apache Wiki wrote: Please do not edit comments into this text: please use the CharterForWebCommonsRequestForComments or post to [http://jakarta.apache.org/site/mail.html General At Jakarta]. OK, here I am posting :-) I'd like to suggest 2 things: 1.We prefereably use Maven for the builds, as it helps a lot handling the dependencies (if we stick to Ant, we should at least use Ivy or M2 Ant stuff for dependency management). For instance, I haven't applied some patches to the Jakarta Taglibs because my computers are not set for building them anymore (and I don't have the time/patience to fix it). 2.Regarding the Jakarta Taglibs, we should create the new taglibs from scratch. I mean, of course we should reuse the code, but we better do some refactoring first (for instance, eliminating redundant taglibs, defining a role for TLD names, etc...) - the current Jakarta Taglibs would then be frozen in time. 3.What about the Standard Taglibs? Should it be part of this new project or should it be a separate project. The reasoning here is that, because that sub-project provide the codebase for JSTL's implementation (and maybe other JSR taglibs in the future as well, such as the Web Services taglib), its development activities/cycles might be different from the non-standard ones (we could even try to apply the TCK on such projects in the future, for instance). -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
Felipe Leme wrote: I'd like to suggest 2 things: ... 3 Damn, beaten by the ENTER key again :-( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mail server hacked?
On Tue, 2005-05-17 at 03:53 -0500, Steve Cohen wrote: Might that rule have possibly been overly strict? I notice at least two posts that should have gone out in the past day - one a post I made half an hour ago to the ant-dev list that still has not appeared on the list. Hmm, I think it's also happening with me: I've sent a message to the harmony-dev twice (using jakartalists2 at felipeal) and they haven't arrived yet. -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Which Linux distribution for Java development?
Opt for one with support for NPTL - RH 9 was the first mainstream distro to have it available, but I think most of then supports it now: http://developer.java.sun.com/developer/technicalArticles/JavaTechandLinux/RedHat/ Another aspect that I think it's very important is good fonts - that's the main reason I prefer Eclipse over Swing-based IDEs... -- Felipe On Thu, 2005-01-06 at 17:28, Dennis Lundberg wrote: I'm considering moving to a Linux environment for my Java development. Which distros would be a good choice and which should one stay away from? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lessons Learned
On Sun, 2004-12-12 at 21:15, robert burrell donkin wrote: though committing a few risky patches in the hope of recruiting a new committer might seem like a good plan, there are definite drawbacks. I agree. I didn't mean that all patches, but they should at least be 'acknowledged'. Even a comment like 'this patch seems great, but I do not have time to carefully analyze it right now' would be better than simply ignoring it. -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lessons Learned
I would add a note to Danny's comment: treat contributors as your primary users. I have seem many projects (inside and outside ASF) where people submit patches and the patches are just ignored, without even an explanation why it was not accepted. I know that applying a patch is not that simple in most cases, but I think the risk of breaking something is lesser than the risk of losing a good contributor. After all, if the patch breaks something, you can fix it later; but if you piss-off a contributor he/she will probably put his/her efforts in another project. -- Felipe On Fri, 2004-12-10 at 07:28, Danny Angus wrote: Encourage anyone to contribute, create a welcoming culture but let people earn your trust, don't form a clique. Don't form a clique. Don't patronise - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exception handling Was: Future JDK features 2 items
On Sat, 2004-11-20 at 05:31, Craig McClanahan wrote:
How about two lines, which you can already do today?
try {
...
} catch (Exception e) {
...
}
The problem with such approach is that it catches all exception, checked
or not (see below)
seems to be a standarized log it and exit or log it and rethrow it
in a wrapper exception strategy, which you can deal with quite
easily.
That makes sense for checked exceptions. For instance, when you use
reflection to invoke a method, you have to handle 2 or 3 checked
exceptions, which you typically want to just log and exit as you
described. But if you use a generic catch( Exception e ), you would
catch unchecked exception as well (like NullPointerException).
Sheesh, hasn't anyone ever heard of inheritance around here? :-)
Ask the java.lang folks :-)
I mean, there is a good 'inheritance chain' of
Throwable - Exception - RuntimeException - TheException
for unchecked exceptions, but for checked exceptions is just
Throwable - Exception - TheException ;
I think there is a missing class there. If we had something like this:
Throwable - Exception - UncheckedException - RuntimeException
Throwable - Exception - CheckedException
Or even just:
Throwable - Exception - RuntimeException
Throwable - Exception - CheckedException
Then your idea would make sense: we could just use the CheckedException,
without the need for changing the language sintaxe (just the API and
maybe some internal structures in the VM).
-- Felipe
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any interest in a Jakarta JavaOne BOF?
Hi Kevin, On Fri, 2004-05-21 at 18:00, Kevin Burton wrote: It's about a 1.5 months away but I figured I would try to get a pulse on how much interest there is in holding a JavaOne BOF. I think it would be great. We could have representatives of some projects talking a couple of minutes about the project status (like what's going on, what kind of help they need and so on). But I don't think it should be restricted to Jakarta, as we have many other java-related TLPs (Top Level Projetcts) - in particular, the Maven guys will be (hopefully) releasing Maven 1.0 by the time of the conference, so I guess they have a lot of cool stuff to talk about (like Maven 1.1, Maven 2.0, Maven Wagon, etc...). We've contacted SUN directly and they seem interested... though to be honest I was thinking it would be better to just have us meet at a bar We could meet for the beers *after* the BOF :-) So how many people would be interested...?! +1 Regards, Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
