Re: Jakarta at the center of the (ASF) universe
On Nov 18, 2007 10:20 AM, Thomas Vandahl [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: Why? W/o Jakarta, the diagrams don't make any sense. For example, the Jakarta-free one has velocity's only relationship to DB (!), and for Harmony, to DB and XML! Ant, arguably one of the most pervasive projects, has no connection to anything else... I agree with Geir. The graph that includes Jakarta looks much more realistic than the other one. It also pretty clearly illustrates what happens when splitting up Jakarta was a deliberate choice, not a random activity. In other words, the resulting connectivity afterwards is more of the well, duh variety. It is effect, not cause. Craig Bye, Thomas. - 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] The future of Jakarta
On 5/22/07, Danny Angus [EMAIL PROTECTED] wrote: On 5/22/07, Martin van den Bemt [EMAIL PROTECTED] wrote: It's pretty simple to solve this though (even though repeating myself here) : Let (a flattened) commons become Jakarta.. I thought that that idea was unpopular with some commons commiters on this PMC? I'm a Commons Committer (although not active lately, nor likely to be again soon because of other personal interests, so take this for what it's worth) ... but I always assumed that what Martin describes (commons becomes Jakarta) was the natural endgame when you've encouraged all the active subprojects that should be TLPs to do so, and dealt appropriately with dormant/dead/inactive codebases. The only other reasonable alternative would seem to mean sending Commons somewhere else and retiring the Jakarta name. That doesn't make marketing sense to me ... although (even though I have a Business Admin degree, Marketing was definitely my least favorite subject :-) On the other hand, are there enough Commons committers (across *all* the libraries) to matter (i.e. create a viable community), or should we just consider the whole thing an exercise that has come to a natural conclusion (a bunch of mature code, and a bunch of experiments that never attracted much community) and call it a day? If Commons is still viable, then Commons - Jakarta only makes sense, and the sooner the better to minize user confusion. Otherwise, the discussion of what to do next seems a bit academic. Craig PS: Yes, of course, there are passionate believers in the development of particular libraries. Are there enough to make a viable community for *any* of the libraries on their own? Or enough that care about the Commons ecosystem as a whole to satisfy Apache's notions of community? It is not clear to me (any longer) that a commons type environment fits Apache culture (as it is currently being discussed) at all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2 config] was: Re: svn commit: r430653 - /jakarta/jakarta-build/trunk/pom.xml
On 8/27/06, Phil Steitz [EMAIL PROTECTED] wrote: snip/ Dennis Lundberg wrote: I don't think so. After I had deployed the pom, Maven wanted to deploy *all* of the sandbox components. At this point I simply canceled the rest of the deploy. By the way, there is a technique to avoid this problem .. mvn -N deploy will only deploy the POM in the directory you're executing the command from, while mvn deploy does that POM and all its modules. Craig Thanks again, Dennis. Let's take this to commons-dev now. Sorry, all, about all the noise. Phil Still in learning mode here... Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE][SHALE] Apache Shale Top Level Project Is Now Up And Running
You might have seen the recent announcement that Apache Shale, originally developed as part of the Apache Struts project, has been approved as an Apache top level project of its own. This message is an announcement that the project resources are now completely set up (thanks to the prompt attention of the Apache infrastructure team), and ready for use: Project Web Site: http://shale.apache.org/ Project Wiki Site: http://wiki.apache.org/shale/ Mailing List Information / Subscription / Archive Links: http://shale.apache.org/mail-lists.html Nightly Builds: http://people.apache.org/builds/shale/ On the web site, you will notice that there is, as of yet, no logo for the project. In fact, we would really like two images -- one for the web site logo, and a Powered By Shale logo that can optionally be included by web applications built with Shale. As someone who can barely draw a rectangle with straight lines, this seems like the perfect opportunity to get the community involved in a design ... so we're going to have a logo contest. Read about it on our wiki page, and submit your creative ideas there: http://wiki.apache.org/shale/LogoContest then, join the Shale User mailing list and root for your favorites. Craig McClanahan
Re: Submitting patches
On 3/26/06, sebb [EMAIL PROTECTED] wrote: OK, here goes: http://people.apache.org/~sebb/source.html I removed the CVS references. Note that the #Patches anchor is referenced from getinvolved vendors so I kept the original heading and added subheadings for the various aspects. So long as there are no objections, I can apply the changes tomorrow and regenerate the site. +1 ... looks great! S. Craig On 26/03/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Sun, 2006-03-26 at 12:41 +0100, sebb wrote: Generally I find that patches are much easier to process as Bugzilla attachments, rather than sent to the developer list as an attachment. And if the patch is large, it uses everyones mail resources, most of whom aren't interested. Just received such a patch on JMeter - the poster helpfully has a blog where he says that he followed the guidelines in: http://jakarta.apache.org/site/source.html#Patches which do indeed suggest sending patches to the developer mailing list. I'd like to suggest a change, so that the preferred method of submitting patches is via Bugzilla or JIRA. In the case of projects using JIRA, I believe that asks for a software grant, so it's important that code is submitted that way. [Actually, I'm not sure when emailed patches are appropriate...] I'd also like to split the patch section into two: Patch Creation Patch Submission Any objections to this? sounds good :) If not, I'll make a start on updating the text - and put a copy on my home page for review. no need to bother: if the feedback's positive then commit and we'll review the diffs. perhaps this information may be better at foundation level but any move can wait until you've patched... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Name for commons-like area for web
On 6/25/05, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Web Commons Web Components For me it depends how fine grained those components are. Say, if there is a project which cummulates all filters for a servlet container I am for web commons as it might result in project sizes we have in commons. If we manage (what I prefer) to have much much smaller parts say a filter component to handle access control based on the ip address with hosts allow/deny rules or another simple component to have commons-validator available as tags for jsf (yes I know there is shale) I am for web components. I am +1 for web components too ... but just wanted to note that the integration between JSF and Commons Validator in Shale is usable even if you don't buy in to the rest of the Shale architecture -- it doens't have any dependencies on the core Shale framework. That kind of independence is one of my goals for the Tiles integration in Shale as well. Except for the configuration interface (which is hooked in to the configuration of Shale overall, but is easily separable), the same is also true for the Dialogs part of Shale ... it has no runtime dependencies on the Shale framework classes, only on the portable JSF APIs. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Tomcat - TLP
+1 Craig McClanahan (Jakarta PMC Member) On Apr 6, 2005 4:36 PM, Ian F. Darwin [EMAIL PROTECTED] wrote: As has been discussed on this list on tomcat-dev, the Tomcat people are interested in moving up. Attached please find a Resolution to this effect from the proposed new Tomcat PMC to the Board. This is a binding procedural vote to be decided by a simple majority of those eligible and casting votes (as per http://www.apache.org/foundation/voting.html). All current members of the Jakarta PMC have binding votes. Since this involves creation of a new project I believe we should give people a week to vote; votes must therefore be registered by midnight Eastern time on Wednesday, 13 April 2005. At that point we will tally the votes and, if the vote is in the affirmative, forward the Resolutions to the Board. The question: I vote in support of the proposal to move Tomcat to an Apache Top Level Project as detailed in the attached Resolution. [ ] +1 Vote in support [ ] 0 Abstain [ ] -1 Vote against Thanks. Ian Darwin --- Draft TLP Resolution --- Establish the Apache Tomcat Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the implementation of the Java Servlet and Java Server Pages specifications, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Tomcat PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Tomcat PMC be and hereby is responsible for the creation and maintenance of software related to creation and maintenance of open-source software related to the implementation of the Java Servlet and Java Server Pages specifications based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Tomcat be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Tomcat PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Tomcat PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Tomcat PMC: Jean-Francois Arcand ([EMAIL PROTECTED]) Bill Barker ([EMAIL PROTECTED]) Kin-man Chung ([EMAIL PROTECTED]) Jean-Frederic Clere ([EMAIL PROTECTED]) Ian Darwin ([EMAIL PROTECTED]) Tim Funk ([EMAIL PROTECTED]) Henri Gomez ([EMAIL PROTECTED]) Filip Hanik ([EMAIL PROTECTED]) Larry Isaacs ([EMAIL PROTECTED]) Jim Jagielski ([EMAIL PROTECTED]) Jan Luehe ([EMAIL PROTECTED]) Costin Manolache ([EMAIL PROTECTED]) Remy Maucherat ([EMAIL PROTECTED]) Kurt Miller ([EMAIL PROTECTED]) Glenn Nielsen ([EMAIL PROTECTED]) Amy Roh ([EMAIL PROTECTED]) Peter Rossbach ([EMAIL PROTECTED]) Yoav Shapira ([EMAIL PROTECTED]) Mark Thomas ([EMAIL PROTECTED]) Mladen Turk ([EMAIL PROTECTED]) Keith Wannamaker ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Remy Maucherat be appointed to the office of Vice President, Apache Tomcat, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Tomcat PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Tomcat Project; and be it further RESOLVED, that the initial Apache Tomcat PMC be and hereby is tasked with the migration and rationalization of the Apache Jakarta PMC Tomcat subproject; and be it further RESOLVED, that all responsibility pertaining to the Jakarta Tomcat sub-project and encumbered upon the Apache Jakarta PMC are hereafter discharged. --- End draft TLP resolution --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: new sandbox projects
Done. Craig On Sun, 19 Dec 2004 10:15:01 -0800, Martin Cooper [EMAIL PROTECTED] wrote: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exception handling Was: Future JDK features 2 items
On Fri, 19 Nov 2004 23:21:02 -0800, Daniel Rall [EMAIL PROTECTED] wrote:
On Fri, 2004-10-29 at 13:35 -0400, Henri Yandell wrote:
...
How about just being able to do multiple Exceptions in one block?
try {
} catch(JMSException, RemoteException, SQLException e) {
}
or possibly even:
try {
} catch( (JMSException | RemoteException | SQLException) e) {
}
Something like this would be truly excellent. I'm so sick of having to
write 30 lines of exception handling code.
How about two lines, which you can already do today?
try {
...
} catch (Exception e) {
...
}
If you really want to treat different types of exceptions differently,
you can special case by putting specialized catch blocks for the
special cases in front of this. The predominant use case, though,
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.
Sheesh, hasn't anyone ever heard of inheritance around here? :-)
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: FYI: Author tags
Recently, a new twist on @author tags came up, from a direction I never would have expected. It seems that the JDK 1.5 compiler whines when you have non-ISO-8859-1 characters in Javadoc comments in your source files. Someone was kind enough to run a compile of a bunch of open source projects with 1.5, to help identify projects that have such sources. It turns out that commons-beanutils has a few such occurrences -- because of non-ASCII characters in the authors's names in the @author tags. Guess we need to tell such people to change their names if they want to be an @author :-). Craig McClanahan On Mon, 13 Sep 2004 12:48:33 -0400 (EDT), Henri Yandell [EMAIL PROTECTED] 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. 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: Where is Cloudscape?
On Tue, 03 Aug 2004 23:33:35 -0700, Kevin A. Burton [EMAIL PROTECTED] wrote: Hm... wanted to check this code out of CVS but can't find it :-/ Maybe I'm jumping the gun a bit... I can be patient ;) http://infoworld.com/article/04/08/03/HNclouscape_1.html Kevin As with any other project under incubation, it'll show up at incubator.apache.org first, when the code is posted. I'd suggest subscribing to [EMAIL PROTECTED] (to subscribe, send an empty message to [EMAIL PROTECTED]) to keep up to date, until the project has its own mailing lists. Craig -- Please reply using PGP. http://peerfear.org/pubkey.asc NewsMonster - http://www.newsmonster.org/ Kevin A. Burton, Location - San Francisco, CA, Cell - 415.595.9965 AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 IRC - freenode.net #infoanarchy | #p2p-hackers | #newsmonster - 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't instantiate Tapestry component TablePages
On Tue, 27 Jul 2004 11:45:09 +0200, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Greetings ladies and gentlemen, I am attempting to create a table/grid component using the Tapestry framework and have hit my head a few times in doing so. Currently I am getting an exception and I can't understand why. It reads: Unable to instantiate an instance of class org.apache.tapestry.contrib.table.components.TablePages. Could someone please provide me with some extra info as to why this would happen. Thanks very much Richard, You're much more likely to get help on this question if you ask it on the Tapestry User's List. To subscribe, send an empty message to [EMAIL PROTECTED]. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Updated: JakartaPMC
Henri Yandell wrote: I wonder if we can configure wiki to make the comment mandatory :) Doubt it would help much ... like many people, I often play the game of what's the minimum amount of stuff needed to pass the validation on this field?. Most commonly, a simple . will do the trick :-). Hen Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT][NET] jakarta-commons/net 1.2 Released
Jeffrey D. Brekke wrote: Praveen, To join in the Jakarta/Commons community is the first step. There is alot of information on the Jakarta site about how to contribute. The first thing would be to read some this documentation, monitor the commons-user and commons-dev mailing lists ( where most discussions are taking place ) and learn how to submit patches to the source code. This is barely scratching the surface of *how to join an open source project* so I hope you investigate a little further on your own. A couple of specific starting points are quite useful: * How the ASF Works: http://www.apache.org/foundation/how-it-works.html * How to Get Involved (Jakarta): http://jakarta.apache.org/site/getinvolved.html Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why use maillists??
Serge Knystautas wrote: J Aaron Farr wrote: Finally, Jakarta did have forums at one time but I don't think they were heavily used: http://issues.apache.org/jive/index.jsp IMO this is the best point. Open source projects get to try dozens of different communication patterns (IM, IRC, NNTP, personal email, Forums, Wikis, mailing lists, phone calls, CVS, bugzilla, etc...). Mailing lists have emerged as the most effective means for open source development. There's another reason that is critically important to me ... offline access. I often have to travel with my laptop on an airplane, and mailing lists let me take the current state of my IMAP-accessible mailbox with me and perform offline processing, ready for synchronization next time I've got Internet access. Note that the fact that Apache uses mailing lists does *not* prohibit accessing that information via forum-oriented UIs ... anything from mailing list archives to NNTP-based access (gmane.org and friends) make that quick and easy. So, get off our case already! :-) Personally, I won't use any forum-based communication mechanism unless I'm paid to do so. Mailing lists have proven their worth for longer than some of the complainers about them have been alive :-). Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
