Re: Apache CommonNet 2.0 support
Dale Harris schrieb: Hi, I was wondering where I can ask to get support for Apache CommonNet 2.0 as I have an issue with TelnetClient class not connecting. I am using Java 1.6_13 on Windows Vista. The supplied telnet example doesn't work when trying to connect to a local telnet server; Putty works okay. The library is commons net, not CommonNet. Googling for that gives: http://commons.apache.org/net/ as the first hit, which is correct. Click on the Project Information link to see info about the project mailing lists. You should first join the user list, then email your question to that list. Regards, Simon - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [VOTE] Commons moving to TLP
On Sun, 2007-05-13 at 01:06 +0200, Martin van den Bemt wrote: If the new TLP is java-only it seems very rude to take the name commons.apache.org : it's far too generic. Perhaps jakarta-commons.apache.org would be appropriate.. Leaving means not using the Jakarta name anymore. I don't see why. As a member of the Jakarta PMC I'm willing to allow jakarta-commons.apache.org to use our trademark :-) But if that's so then perhaps jcommons.apache.org? Or commons4j.apache.org? (though that implies IBM to me...) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons moving to TLP
http://wiki.apache.org/jakarta-commons/TLPResolution [ ] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... I'm not really convinced that this change will improve anything. In particular I'd be sad to lose the current SVN access system, where any Jakarta committer has commit access to any other Jakarta project and general common-sense was used to govern things rather than technical/bureaucratic blocks. I thought this brought down a lot of unnecessary walls, but moving commons to a TLP will erect these walls again I presume. We want committers to apache projects that *use* commons libs to have a fairly low barrier for contributing back to commons; as currently set up any jakarta committer can just do so. However I don't feel strongly enough to vote against this proposal. But I do oppose using the name commons.apache.org. The current jakarta commons community is exclusively Java, and that should remain so. Having multiple languages supported under one PMC will lead more oversight issues, and less community cohesion, than currently exist. If the new TLP is java-only it seems very rude to take the name commons.apache.org : it's far too generic. Perhaps jakarta-commons.apache.org would be appropriate.. BTW, as I don't really support this change I'm reluctant to add my name to the initial PMC list on the wiki page. However if the TLP does go ahead (and that looks likely) then I would like to be on the PMC. What's the best thing to do? Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Morph as Jakarta-sponsored podling WAS Morph proposal
I'm definitely interested. BeanUtils tries to do too many things in one lib, and besides it is really ugly internally. So something like Morph would be very useful to have. For a commons-digester 2.x (if it ever occurs) I would definitely like to get rid of the existing BeanUtils dependency, and that means finding some alternative. However I don't personally have the time necessary to work on this at the moment. Regards, Simon On Tue, 2007-04-03 at 07:16 -0700, Matt Benson wrote: Just wanted to confirm the complete lack of interest here. Unless I hear differently, I'll assume that's lazy [-0]s all around and let the matter drop. Thanks, Matt --- Matt Benson [EMAIL PROTECTED] wrote: Morph's incubation proposal follows, sent here first in an effort to gain the sponsorship of Jakarta, and possibly to attract mentors as well. :) Thanks! Morph defines a comprehensive API for performing object-to-object conversions in Java. PROPOSAL BACKGROUND/RATIONALE As information flows through an application, it undergoes multiple transformations. While the most prevalent examples of this in the J2EE space are well-known (e.g. HTTP request parameters to domain/data transfer objects, DTOs to domain objects) the overall problem space is characterized by the lack of a simple, well-known, conveniently extensible solution. At least one JSR (295) describes such a facility as a dependency. Having identified the basic commonalities among the best known application operations requiring object conversion, Morph consolidates these into a single API which, along with various bundled implementation classes, seeks to achieve the oft-repeated software development goal of making the simple things easy, and the hard things possible with regard to its problem domain. CURRENT STATUS Meritocracy: The Morph team is eager to invest more fully in the meritocracy approach taken by the ASF. To date, however, Morph's development team has been accumulated by a sort of meritocracy-on-spec approach: Matt Benson was originally given commit rights solely on the basis of his ideas; only later did his work vindicate that decision. [If sponsored by Jakarta: This is a similar approach to that taken in the Jakarta community: a community member simply announces his desire to work on a component, then proceeds with the community's blessing.] Community: It is somewhat difficult to gauge the size of Morph's community. There have been modest but consistent downloads of the project since its initial prerelease: these average 21/month over 28 months. The traffic on its user and developer lists is similarly light, but several bug fixes and enhancements have resulted from the input of Morph's users. An additional possible benefit of Morph's joining the Apache community is that increased cooperation with and buy-in from other ASF projects may increase its user and/or developer communities. Core Developers: Matt Sgarlata is Morph's founding architect and developer. He has been a member of the Jakarta and Struts user communities for some years. Matt Benson is a member of the Apache Ant PMC and a Jakarta committer, so is familiar with (and fond of) the consensus and transparency encouraged in ASF development. Alignment: Morph currently contains interoperability code for commons-beanutils, commons-chain, and Velocity. Because it is Morph's secondary purpose to provide implementations of common conversions, code that facilitates Morph's use with well-known libraries in easily anticipated ways is considered in-scope. As has already been implied, it is expected that citizenship at the ASF would facilitate cooperation with existing projects to mutal benefit. Finally, precedent demonstrating the desirability of such a project at Apache exists in the form of Jakarta commons-convert (this component ultimately failed to achieve maturity). Morph's original design specifications are actually the generic subset of those drafted on the commons-dev mailing list as a next-generation implementation of this project. KNOWN RISKS Orphaned Products: The Morph developers are part of its user base. Object conversion may be relevant to any of various components of a basic Java application. The risk of itch cessation is therefore minimized; Morph should continue to be an applicable technology at low risk for being abandoned by its developers. Inexperience with Open Source: As previously indicated, one of the initial committers has some years of experience as a committer and PMC member at the ASF. Additionally, Morph has always been open-source software, with its evolution being directly guided by user input and developer consensus in similar fashion to other Apache projects. Homogenous
Re: Three votes of PMC members required
+1 On Sun, 2006-10-15 at 15:44 +0200, Jochen Wiedmann wrote: Hi, AFAIK the policy is still that three votes of PMC members are required. In other words, may I point you to http://marc.theaimsgroup.com/?t=11606631873 and ask kindly for positive votes? (Unless you have reason for negative votes, of course.) Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Off to Vienna
Hi All, Just wanted to let people know I will be off-line for the next three weeks or so while on holiday in Vienna, Austria (and Nuremberg, Germany) [1]. I hope to meet up with a few Apache people while there as there are damn few in New Zealand! I've emailed a couple of people but if there's anyone else nearby please drop me a message at s_kitching at yahoo dot com. See you in three weeks.. Simon [1] I'm not gloating..much :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta Sandbox (was [VOTE])
On Sun, 2006-04-09 at 19:19 -0400, Noel J. Bergman wrote: Andrew C. Oliver wrote: Then there is no NEED for a sandbox. As you know, the sandbox predates the Incubator, and AIUI, the Sandbox exists so as to allow experiments without polluting the respository in such manner that would confuse the public and ourselves about what is real and what is play. There may be other ways in to achieve that goal. Agreed. I think much of the Sandbox concept owes its existence to the limitations of CVS, and that with Subversion and the recent jakarta-wide commit access a lot of the need for a sandbox is gone. A project which has ties to an existing one (eg a refactoring of common code out of a project into a common component) can be done in a sandbox subdir of that project (sibling to trunk/tags/branches). Discussion can be held on that project's lists. Oversight is provided by the committers on that related project. When it's ready to be promoted, a simple svn mv and the creation of a separate email list will do the job. For projects which are brand new but likely to become part of jakarta commons, the existing commons sandbox (using the existing commons-dev list) seems appropriate to me. Oversight is provided by the commons community. Of course if the project is a kind of language extension then it might want to hang out on the proposed commons-lang-components list instead of the original commons list. Projects that originate outside apache and are being brought in go through the incubator of course. Oversight is provided by those kind apache committers who subscribe to the incubator lists. The only problem I see is largish projects that are originated by existing Apache committers and have no close affiliation to existing projects. There aren't likely to be very many of these. I would suggest that if such a project can't find an existing project willing to effectively sponsor it by allowing their own list and subversion dir to be used to host the project for a while, then it belongs in incubation. The other issue to consider is where websites for sandbox-status projects can live. I think it would be nice to group these together, eg under jakarta.apache.org/sandbox. This provides a way for such projects to publish sites while making it clear to users that they aren't yet approved. To summarise: I suggest setting up a parent website for jakarta-wide sandbox stuff, and dropping the existing sandbox docs that encourage non-commons projects to come and play in the commons sandbox. Otherwise things can be pretty much left as they are... Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
On Sat, 2006-04-08 at 00:51 -0400, Henri Yandell wrote: On Sat, 8 Apr 2006, Simon Kitching wrote: And who is expected to subscribe to [EMAIL PROTECTED] Those who want to? :) I imagine those working on sandbox components at the moment, plus a handful of people who tend to subscribe to such lists. Out of interest - if we take a list with N mails a day, and have 2 lists with N/2 mails a day, is that something you'd view as more painful or the same amount of pain? I know that when subscribing to Jakarta subprojects I'm not interested in as a coder, I subscribe to both the -user and -dev and funnel them both into the same folder. For my level of interest it's just [EMAIL PROTECTED], not ecs-xxx@ etc. So I'm probably answering more pain to the above, but I've got a simple solution that hides the minor pain increase. I'm more concerned about the other direction - a lack of people watching this new sandbox. Currently, all commons developers are subscribed to commons-dev, and therefore get to see sandbox stuff. Ok, it's sometimes a little annoying. However it does mean that we're all aware of what's going on at a general level. Commits including non-ASF copyright statements are going to be picked up for example, as are commits of jarfiles. Help/comments are also often offered by committers not specifically working on that sandbox project. I'm worried that if the sandbox becomes its own world, then it will end up with very few subscribers, and that good projects will therefore have a hard time becoming a success. Ideally, a sandbox project should be adopted by its closest living relative, and use that project's list until it grows up. This [EMAIL PROTECTED] idea looks more like a communal orphanage to me... Of course if a big bunch of people volunteer to join this proposed sandbox community then that would resolve my concerns. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
On Fri, 2006-04-07 at 16:28 -0700, Martin Cooper wrote: On 4/7/06, Henri Yandell [EMAIL PROTECTED] wrote: Calling a vote to create a Jakarta Sandbox; which entails: * Move Jakarta Commons Sandbox to Jakarta Sandbox * Migrate Jakarta Taglibs Sandbox into Jakarta Sandbox * Create development mailing list ([EMAIL PROTECTED]) * Create wiki (and migrate wiki bits from j-c-s/j-t-s) * Jakarta Sandbox to initially use the Commons sandbox processes. What would be the constraints on what could go in there? Anything, as long as it's written in or for Java? And who is expected to subscribe to [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove SVN restrictions
On Mon, 2006-03-27 at 02:50 -0500, Henri Yandell wrote: Vote to remove the SVN barriers within Jakarta such that all jakarta-* groups are merged into the one jakarta group with the exception of jakarta-hivemind, jakarta-slide, jakarta-cactus and jakarta-jmeter under the assumption that they are moving to having their own PMCs. Tapestry is already within its own auth group. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Managing communities and emails (was Re: [PROPOSAL] Jakarta Language Components)
On Tue, 2006-03-14 at 20:23 +, robert burrell donkin wrote: On Tue, 2006-03-07 at 19:13 +, Stephen Colebourne wrote: Reposted (edited) from original commons proposal. Currently this proposal has general, though not unanimous, support. A vote thread may follow this thread if the mood remains positive. i'm a little unsure whether this will turn out for better or worse but if people out there have energy, i'm willing to give it a go. time's probably right for a little innovation and experimentation. i like the idea of tagging emails better: a single list with cool server side filtering and metrics. we don't have the technology for this yet so i'm willing to see the mailing lists split so long as people would be willing to consider coming back if it every arrives... I was just considering proposing exactly this! The issues about groupings, subprojects, etc. are completely irrelevant it seems to me. A community is the set of people subscribed to emails about a particular project, no more and no less. Unfortunately the way email lists are currently run at apache forces a strict hierarchy onto community structure, and forces a choice between coarse-grained and fine-grained style communities (eg one commons list vs one-per-project). PMCs are structured hierarchically, and that is reasonable, but communities don't need to be this way. The perfect system, to me, would be a website that allows a user to register a username/email-address; the process would confirm that the user's email address is valid. A set of checkboxes would allow a user to subscribe to various lists, or to virtual groupings such as jakarta commons which would implicitly subscribe to the list for every project that is tagged as being a jakarta-commons project. Of course this implies fine-grained email lists (ie one for each project); the problems of partitioning the subscriber base too much is avoided by the existence of the groupings. This system would allow overlapping groups to occur; for example commons-digester can be filed under both commons and xml virtual groups; someone subscribing to *either* group would receive digester-related emails. It also allows projects to move from one PMC to another without destroying the existing community (which *is* the set of people receiving emails). Groups also allow new projects to be created and added to the group; all people subscribed to the group would then automatically get emails related to that new project. Any list which has less than 3 subscribers would automatically forward its emails to the PMC list (or similar) for purposes of oversight. Any person subscribed to 3 or more projects associated with commons would automatically be subscribed to the whole commons group (or maybe just sent a weekly nag email recommending they do so). That hopefully allows casual commons developers to get just postings for one or two projects, without destroying the useful commons-wide community that exists now. Having a single point for managing subscriptions would also help greatly with something that regularly frustrates me: suspending subscription when I'm away on holiday. Currently, I need to unsubscribe to half-a-dozen lists then resubscribe on return. This sort of functionality probably already exists in one of the open-source mailing list management packages; it isn't anything radical as far as I can see. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Other Jakarta Components
On Sun, 2006-03-12 at 12:38 -0800, Martin Cooper wrote: On 3/7/06, Henri Yandell [EMAIL PROTECTED] wrote: Yes, Struts uses Digester. It also uses BeanUtils, Chain, FileUpload, IO, Logging and Validator. I think this whole thing is putting the cart before the horse. You're in the process of destroying Commons, not just dismantling it, and for no good reason that I can see. The people involved with Digester should be the ones to initiate a discussion about whether or not they want to take Digester elsewhere. As it is, this is coming across more like why don't you guys go away, somewhere far away, 'cos we think that's a good idea. I'm a committer on commons-digester, and don't mind Henry or others discussing these topics at all. The pot of ideas needs a good stir from time to time (and Henry is a good stirrer :-). I do see some merit in having digester involved more with the xml crowd in the xml project. However I would currently think the disadvantages outweigh the advantages. In particular: * Digester is really pretty stable. There is no great demand for new features from users, and not many outstanding issues. * The package names org.apache.commons.digester would be odd for a component in the xml umbrella, but there's just NO reason to force a package name change on users. * As Martin says, there already exists a community here. There is *enough* support available at the moment in commons for Digester's stable needs. So while I'm +1 for taking a look at each existing commons component to determine *if* there might be a better home for it, I'm -0 to moving Digester. I *will* have a think about whether Digester 2.x would be better off in the xml project. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
On Wed, 2006-03-08 at 16:54 +, sebb wrote: I'd much prefer something like Jakarta Lang[uage] Components Jakarta Web Components etc I then have some idea what each contains, with having to remember that Bogart means Language, and Bacall means Web etc. Otherwise, we might as well call them Jakarta Group A Jakarta Group B Jakarta Group C +1 Simple project or group names seem best to me. For us developers who are working with jakarta stuff daily clever names are not a nuisance because we soon memorise what they are associated with. However I think they just make it harder for others to find projects they are interested in. These clever names can also be hard on non-native english speakers. For them, the name can be a completely meaningless phrase. Silk? Syllable? And of course there's the earlier point that what's currently under discussion is *not* a project or a TLP; it's just a grouping of jakarta stuff to reduce mail-list and website overload. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
On Mon, 2006-03-06 at 22:42 -0500, Henri Yandell wrote: Over on Commons-Dev, Stephen has suggested that we split some of the components out to form a Jakarta Language Components group. Consensus is in favour of the idea, so I'm sure we'll see a vote on that and some movement soon. Commons ID (and Commons CSV perhaps) are two elements in the Commons Sandbox which would potentially go to JLC, but there are (wisely) no plans for a separare JLC Sandbox. 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). That has a Sandbox as well. Lastly we have Jakarta HTTP Components - formerly Commons HttpClient - which technically lost access to its sandbox - though I suspect it's been a long time since it used it. To that end, I'd like to propose that Commons Sandbox and Taglibs Sandbox merge into Jakarta Sandbox - servicing all of Jakarta - though I imagine it would mostly be the component groupings. Thoughts? I presume that a commons committer would have commit access to both old commons and Language Components? Having a separate commit list would set the barrier to high for movement between the groups. Actually, the proposed jakarta-wide commit access would be even better. Regarding sandboxes, the issue is really where the commit mails will go. An experimental project that hopes to be promoted to community X really should have its commit messages go to the mailing list for that community. Other than that, what *is* a sandbox exactly? In general, though, the split-off of Jakarta Language Components seems wise. Commons email traffic is a pretty hefty burden, so halving it for people only interested in one of the two new commons pieces is good. I believe there are enough people interested in each community to allow the separate pieces to thrive. Of course people should be encouraged to subscribe to both where possible - and general always! Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Two community proposals
On Sun, 2006-03-05 at 12:22 -0800, Nathan Bubna wrote: On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: Given that we are one project and that we should be acting as one community - I propose that we: 1) Remove SVN restrictions, all Jakarta committers can commit anywhere in Jakarta, with the exception of the Commons-Sandbox as it allows Apache committers in general to commit. i think this is fine. it brings our practice more in line with the legal realities of the organization. it adds potential for greater cross-pollination and lower barriers to resuscitating dormant projects. it's true that most of us committers are myopic and do nothing with the greater freedom, but the potential is there for some to more easily serve the community and their own needs through this. +1 Commons committers voted in for their work on one project technically have access to other projects. This has not had any negative results as fa as I am aware, and it has lowered the barriers for those committers to become involved in other commons projects where appropriate. I've not seen any case where a committer made inappropriate changes to another project - and if it did happen, normal community oversight would pick that up. I would expect jakarta-wide commit privileges to work just as well as commons-wide. Re measuring community size of a project and determining *who* the community is, I agree that the committer list for that project isn't actually very effective. There are several possible measures I can see: * counting vote emails as mentioned by Henri * counting SVN commits to a particular project * inspecting the maven project.xml's committers section and then cross-checking whether the listed people are actively committing to ANY project (ie whether they are still around) * annual online survey that all committers are asked to complete, in which we indicate what projects we actively participate in. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: License Apache and LGPL
On Sat, 2006-01-21 at 19:44 +0100, Angelo zerr wrote: Hello, I created RTFTemplate project, RTF template engine (if you are interested, see http://rtftemplate.sourceforge.net/index.html) and I use LGPL license. But RTFTemplate use Jakarta Velocity library which is Apache license. Can I use LGPL license? Must I change license LGPL to Apache license? Can I use GPL license otherwise? Thank's for your response. The best place to ask this question is probably on the list legal-discuss@apache.org (you might want to check the archives first in case the answer is already there). However I believe that it is ok to combine Apache software with GPL or LGPL software (as long as the acknowledgement clause is followed). The resulting combination can legally be distributed under the GPL (or LGPL) licence. Of course the result *cannot* be distributed just under the Apache license, which is why Apache projects cannot include GPL/LGPL code directly. Note: I am not a lawyer. The legal-discuss list is the best place for a professional opinion. There was some discussion a while ago about creating a web-page with these sorts of questions answered, but I don't think it exists yet... Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: License Apache and LGPL
On Sun, 2006-01-22 at 17:33 +1300, Simon Kitching wrote: On Sat, 2006-01-21 at 19:44 +0100, Angelo zerr wrote: Hello, I created RTFTemplate project, RTF template engine (if you are interested, see http://rtftemplate.sourceforge.net/index.html) and I use LGPL license. But RTFTemplate use Jakarta Velocity library which is Apache license. Can I use LGPL license? Must I change license LGPL to Apache license? Can I use GPL license otherwise? Thank's for your response. The best place to ask this question is probably on the list legal-discuss@apache.org (you might want to check the archives first in case the answer is already there). However I believe that it is ok to combine Apache software with GPL or LGPL software (as long as the acknowledgement clause is followed). The resulting combination can legally be distributed under the GPL (or LGPL) licence. Of course the result *cannot* be distributed just under the Apache license, which is why Apache projects cannot include GPL/LGPL code directly. Note: I am not a lawyer. The legal-discuss list is the best place for a professional opinion. There was some discussion a while ago about creating a web-page with these sorts of questions answered, but I don't think it exists yet... By the way, the jboss project already does this: combines its own GPL software with Apache projects like Tomcat. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how can i download the poi project?
On Tue, 2005-10-25 at 13:30 +0530, prakash jaya wrote: hi friends, i want work on this project ,for this i need this poi library.From where i can down load this package.please give me the proper link to download this link. google apache poi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Localization Support
On Thu, 2005-08-25 at 10:38 -0500, Patrick Doran wrote: I am researching I18N and L10N support in Jakarta components for a G11N project. Do the Jakarta commons components externalize messages in resource bundles for translation? If so, are localized versions of any of the components available? In particular we are interested in the Discovery, Logging, Digester, Collections, and Commons-Cli components. As you're asking specifically about commons libraries, you may get a better response if you ask this on the commons-user email list. There are two types of strings: those intended for users, and those intended for developers. Neither Logging nor Digester generate any user type messages. This is not unusual for commons components; they are generally libaries that don't have any UI stuff in them. They do generate messages in exceptions when things go wrong, and can be configured to output diagnostic information to assist debugging. Such developer-type messages are NOT externalised; the messages are english only and are embedded in the code. The xml files that digester parses can be in multiple languages; in particular when using the xmlrules module it is a reasonably easy job to translate the rule files so that localised xml element and attribute names can be accepted in the input. It's possible to also do this via the digester API but of course that's the responsibility of the developer writing the code that *uses* digester. The commons-logging configuration file is in English. However there's very little configuration that needs to be done for commons-logging (except when using the SimpleLog class). Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CLA for Brian Stansberry
Thanks Jim. It would appear that the US Postal service have lost the letter then. Hmm.. I'll ask Brian to post another one. Regards, Simon On Tue, 2005-08-09 at 10:46 -0400, Jim Jagielski wrote: Not rec'd. On Aug 9, 2005, at 6:16 AM, Simon Kitching wrote: Hi, Brian posted in his CLA around 1st of July (that's 5 weeks ago). Is there any sign of it? I've emailed Jim directly but got no response. Thanks, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
List moderation
Hi, I've been a moderator for the bcel-dev@jakarta.apache.org and bcel-user@jakarta.apache.org for a few months now. In that time there have been 2 valid emails from people who weren't subscribed, and a few thousand spam mails. I'm rather tired of being a human spam filter for the mailing list. As the ratio of bad to good emails is so high, I suggest that all mails from unsubscribed users simply be discarded making moderation unnecessary. What's the general opinion about this? Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta - Cleaning house
On Tue, 2005-08-09 at 17:53 -0400, Henri Yandell wrote: BCEL/BSF challenged to show they shouldn't be considered frozen. Work on policies for how to spot freezing/graveyard targets; BUT don't wait on this to create them Dave Brosius has been reasonably active on BCEL recently. There might be a bugfix release coming out in the not to distant future. Long-term I suspect that it is still unlikely to gain new features (esp. java5.x features which are really needed for the project to survive). However given Dave's good work I suggest it qualifies as sleepy rather than dead. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CLA for Brian Stansberry
Hi, Brian posted in his CLA around 1st of July (that's 5 weeks ago). Is there any sign of it? I've emailed Jim directly but got no response. Thanks, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dual licensing of code
On Tue, 2005-07-26 at 13:33 +0200, Stefan Bodewig wrote: On Mon, 25 Jul 2005, Simon Kitching [EMAIL PROTECTED] wrote: I am now looking at writing an article about unit testing and would like to be able to provide these classes as code in the public domain, just to make it as easy as possible for readers of the article to reuse that code. Is there any issue with doing this? What is the exact procedure I should follow? IANAL and all that. Since you've written the code, you retain the copyright and can re-license it under whatever license you want to. Just make sure it is your original submission and nothing else. If anybody else contributed code, make sure you get them to agree with your wishes. Thanks Stefan. As there has been no other feedback on this, I think I will try asking on legal-discuss instead. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Brian Stansberry as jakarta-commons-logging committer
Hi, Any sign of Brian's CLA having been received?? Thanks, Simon On Mon, 2005-07-11 at 16:50 +1200, Simon Kitching wrote: Hi, Brian sent his CLA in by post about 12 days ago. How can I check whether it has been received/processed? Thanks, Simon On Sat, 2005-06-25 at 22:50 +1200, Simon Kitching wrote: The votes to elect Brian Stansberry as a committer for jakarta-commons-logging are as follows: +1 Dion Gillard +1 Phil Steitz +1 Robert Donkin +1 Yoav Shapira +1 Emmanuel Bourg +1 Henri Yandell +1 Simon Kitching Brian is therefore elected (Brian has indicated privately that he is willing to accept). Brian, the first thing you need to do is complete a Contributor License Agreement and send it in by mail or fax. Details are here: http://www.apache.org/dev/new-committers-guide.html Once this is completed we can create a user account for you and arrange the necessary access rights. Note that processing of CLAs can sometimes take a week or two. Your contributions to jakarta commons so far are very appreciated and we all hope you'll enjoy being part of the commons community. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Brian Stansberry as jakarta-commons-logging committer
On Tue, 2005-07-26 at 19:49 -0700, Martin Cooper wrote: On Wed, 27 Jul 2005, Simon Kitching wrote: Hi, Any sign of Brian's CLA having been received?? Nope, not yet. Jim added in a bunch of received iCLAs on 7/14, and Brian's was not amongst them. You might want to ask him to fax it again, in case it got lost somehow. It was posted, rather than faxed. I don't believe the US post is that slow is it?? On Mon, 2005-07-11 at 16:50 +1200, Simon Kitching wrote: Hi, Brian sent his CLA in by post about 12 days ago. How can I check whether it has been received/processed? Thanks, Simon On Sat, 2005-06-25 at 22:50 +1200, Simon Kitching wrote: The votes to elect Brian Stansberry as a committer for jakarta-commons-logging are as follows: +1 Dion Gillard +1 Phil Steitz +1 Robert Donkin +1 Yoav Shapira +1 Emmanuel Bourg +1 Henri Yandell +1 Simon Kitching Brian is therefore elected (Brian has indicated privately that he is willing to accept). Brian, the first thing you need to do is complete a Contributor License Agreement and send it in by mail or fax. Details are here: http://www.apache.org/dev/new-committers-guide.html Once this is completed we can create a user account for you and arrange the necessary access rights. Note that processing of CLAs can sometimes take a week or two. Your contributions to jakarta commons so far are very appreciated and we all hope you'll enjoy being part of the commons community. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Dual licensing of code
Hi All, In the last couple of months I wrote two classes to assist in unit-testing of jakarta commons logging. These classes have been committed to the commons-logging subversion with an Apache copyright and the standard APL 2.0 attached. I am now looking at writing an article about unit testing and would like to be able to provide these classes as code in the public domain, just to make it as easy as possible for readers of the article to reuse that code. Is there any issue with doing this? What is the exact procedure I should follow? Note that the classes are 100% my own work as can be seen from the subversion history. The actual classes in question are PathableTestSuite.java PathableClassLoader.java which can be seen here: http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/ or here: http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/ Thanks, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Copyright line in code submissions
On Mon, 2005-07-25 at 01:08 -0400, Rahul Akolkar wrote: I recently came across a code contribution [ http://issues.apache.org/bugzilla/show_bug.cgi?id=35740 ], which contains the Copyright [] [name of copyright owner] line in every file as pointed out in the Appendix at the bottom of [ http://www.apache.org/licenses/LICENSE-2.0.txt ]. The appendix talks about How to apply the Apache License to your work, does it also hold for code submitted for inclusion in existing Apache projects? While the above contribution may be useful, I wanted to check what the norm is within Jakarta, or Apache for accepting code submissions with such copyright lines. Thanks, -Rahul P.S.-Originally asked here [ http://marc.theaimsgroup.com/?l=taglibs-devm=112146053822157w=2 ] This was discussed briefly on [EMAIL PROTECTED] You can find my opinion (which I haven't changed) here: http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200502.mbox/% [EMAIL PROTECTED] Basically, I think it's legal for code submitted to apache to have the copyright of the original author but there are good reasons to avoid this if possible. Certainly the norm for commons projects is to have only one copyright statement, being that of the ASF. I'd be interested to know if there is a general Apache policy on this. IANAL and all that. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
access to committers svn module
Hi, I find I am unable to access https://svn.apache.org/repos/private/committers as described here: http://www.apache.org/dev/pmc.html I believe that this should be open to all committers. Would someone mind checking? I think the necessary access permissions are defined somewhere in /x1/svn/repos-private on svn.apache.org but that dir is only accessable to members of svnadmin. Thanks, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: access to committers svn module
Hi Brett, On Sat, 2005-07-16 at 13:07 +1000, Brett Porter wrote: Works for me and you are definitely in the right group according to asf-authorization. Ok, it was a password thing. Thanks. I had made the assumption that as I could access the jakarta stuff automatically due to my svn cached password (~/.subversion/auth) that I wouldn't need to enter a password. As I haven't used the password explicitly for years, I dug into ~/.subversion/auth to find out what it was, entered it and all was ok. Sorry you bother you, and thanks for the help. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
List Moderator: please unsubscribe pgaldon@i-slanda.com
Hi, Whenever a message is posted to this group, an automated reply is sent by [EMAIL PROTECTED] My spanish isn't great, but Pedro appears to have changed email address and left the old address on auto-respond with the new address info. quote La direccin [EMAIL PROTECTED] pronto dejar de estar activa. Anota mi nueva direccion de correo: [EMAIL PROTECTED], y escribeme a esta nueva direccin a partir de ahora. Gracias. /quote So if you could unsubscribe the [EMAIL PROTECTED] address that would be appreciated. Thanks, Smon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
On Thu, 2005-06-23 at 17:55 -0400, Frank W. Zammetti wrote: robert burrell donkin wrote: if the new subproject is anything like the commons then each component will have it's own development rhythm. I think this is a cogent point... if the idea is that this is like a Commons project, than I have to ask the question: why not just have a few new Commons projects, as was my original proposal? The relevant questions are: * what percentage of the existing commons developers are interested in working on web components * what percentage of the prospective web developers are interested in participating in other commons projects * what percentage of users and interested in both web and normal commons projects. If the answer to any of these is high then the benefits of a combined community outweigh the nuisance of excessive emails, overly-large subproject lists and general distraction. I would guess the critical threshold to be about 25% - but I don't think that will be reached, ie I believe that less than 25% of existing commons committers would be interested in web commons components of the sort proposed. Therefore having such components in the existing commons will just annoy people without having any significant benefits (other than allowing this startup hassle for web commons to be skipped). Already we have people (both developers and users) agitating for separate per-component mail lists due to the volume of emails in commons. Some people have stated that they refuse to subscribe or be part of the community while there is a shared list. I would hate to see separate lists, but they have a point - there is an upper limit to the amount of mail people can handle (esp. people on dial-up connections; filtering by mail subject doesn't reduce the bandwidth needed to download all the mails). There is also the issue of community size. Commons has a couple of dozen regular committers, which means we all recognise each other's names. That's quite important I think, and brings some sense of team membership. Diluting this with another dozen developers (I hope web commons will grow to that size!) may change that sense of community (esp. if we don't have many interests in common). And likewise for new web commons committers - I think the sense of a team will be stronger with a separate project/mail-list etc. I admit it's all guesswork and a little crystal-ball-gazing. If web-commons is a failure, ie only a couple of projects get off the ground, then the existing commons would be a better home. But I hope that's not the case - there does seem to be a reasonable number of ideas and people willing to push them forward. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [svn] Alexandria: migrate or archive?
On Fri, 2005-06-24 at 01:35 -0400, Henri Yandell wrote: I can't remember, are we going to migrate Alexandria over to SVN, or treat it like jakarta-site, jakarta-site-old and other obviously dead modules. If we want to migrate it, does anyone mind me just going ahead and doing so? I'm in favour of migrating it. There may well be stuff that people want to go back and look into over the next few years. That will be difficult when Apache no longer provides CVS access The site stuff is different; there's no obvious reason for looking at the history of any of that, or retrieving any old versions. Please go ahead. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is wrong with this upload filename (UTF-8) encoding?
Hi, On Fri, 2005-05-20 at 17:09 -0300, Lauriberto Alves (Engenharia-BSB) wrote: I was trying to submit a html form which has a html:file tag This general@jakarta.apache.org list is intended for messages related to administration of the jakarta project. Your message looks useful, but unfortunately won't reach the right readers here. Please post your message on the struts user list instead: http://struts.apache.org/mail.html Thanks, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FYI: cvs/svn info on jakarta site updated
Hi, I've recently made some minor tweaks to this page: http://jakarta.apache.org/site/cvsindex.html to improve info related to subversion. The old page (without stylesheet though) can be found here if anyone is interested in comparing the two. http://people.apache.org/~skitching/old-jakarta-site/cvsindex.html If anyone has any objections I'm happy to fix (or at worst, revert) my change. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: wiki administration: bang_meta]
I got no response to this on the PMC list. Maybe someone here can help? Forwarded Message From: Simon Kitching [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: wiki administration: bang_meta Date: Fri, 29 Apr 2005 18:59:10 +1200 Hi, I have noticed that in the commons wikis, the syntax !SomeName could previously be used to suppress the default behaviour of turning such a string into a link. This behaviour appears to have been disabled. Could we please turn this back on? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
InterWiki links
Hi, Jakarta-commons had this link: [wiki:Jakarta/FrontPage] which presumably used to link to http://wiki.apache.org/jakarta/FrontPage But it was just linking to http://wiki.apache.org/jakarta-commons/InterWiki which is of no use at all. I have fixed the jakarta-commons page by using a direct link, but don't know if this syntax is being used elsewhere... Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Wiki structure
Hi All, Sorry to ask what is probably a newbie question. Apache has a main wiki, which is then supposed to link to physically separate wikis, yes? And Jakarta is supposed to have one of these separate wikis to itself? It's just that it looks to me like: http://wiki.apache.org/jakarta is jakarta's wiki site, but the jakarta-related links on the main wiki page: http://wiki.apache.org/general appear to me to link to pages on the *main* wiki, not on the jakarta wiki, eg http://wiki.apache.org/jakarta-commons when I would expect to see http://wiki.apache.org/jakarta/commons Am I wrong in my understanding of where the links on the apache wiki main page link to? If I am, can anyone tell me how I can tell which physical wiki a particular page resides on? And by the way, what is the reason for having all these separate wikis anyway, instead of just one? Thanks, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Daffodil Replicator an Open Source : Suggestion
On Sat, 2004-08-07 at 05:20, Nicola Ken Barozzi wrote: Ashish Srivastava wrote: Hi, We are a product based company named Daffodil Software Ltd, based in India. We have developed many good products using JAVA out of which our two premium product Daffodil DB (an RDBMS) and Daffodil Replicator (database utility software) is largely accepted by world software community. We are planning to make our Daffodil Replicator an open source project. How can we make it with www.apache.org please let us know how we have to proceed. I visited at http://incubator.apache.org but unable to find the answer how to proceed in order to make our product open source. I'm cross-posting to lists where there might be interest in helping you out on this. www.daffodildb.com Hi Ashish, The following is just my personal opinion, as a member of the ASF (Apache Software Foundation); I am not speaking on behalf of the ASF. I think it is great that you are considering releasing some of your code under an open-source licence. I am sure there are a number of people that are willing to offer advice on the process of releasing your code as open-source. And if you do this, you are certainly welcome to reuse the Apache Public License legal document as the base for the license terms you release your code under; the ASF and its legal advisors deliberately designed the license in a way that makes it easy for non-ASF-hosted projects to use. However if you are suggesting that the code you release may be hosted and maintained by the Apache Software Foundation, I personally think this is unlikely to happen. Firstly, the code you are considering releasing under an open-source licence is an add-on to a proprietory product. The ASF is unlikely to consider adopting that kind of project. This doesn't mean that making the code open-source is a bad idea, it's just something that the ASF usually avoids being involved with. Secondly when the ASF adopts existing code, the provider of the code is expected to show evidence that there is a group of developers willing to continue maintenance and development of the code in the future. Apache doesn't want to end up hosting lots of code with no associated developers. Given that the code you are considering releasing can only be used with a proprietory database which does not have a large market share, I think this will be a difficult thing for the Daffodil Replicator project to demonstrate. If your replicator tool can actually replicate data for multiple different brands of database then please let us know; that would make the project much more interesting, and therefore more likely to obtain an adequate pool of developers. In particular, if it could be used with the IBM CloudScape product which has recently been offered by IBM and accepted by the ASF (and to be renamed Derby I believe), there could be significant interest. The result could well be an improved replicator for both Derby and Daffodil - but only if the architecture of your current code is not too tightly bound to the Daffodil database. If you are interested in discussing this further, then please describe what Daffodil Software expects to gain by outsourcing this software. There are a number of different open-source licences available, and which one is appropriate depends upon the business strategy of Daffodil. The ASF always uses the apache license, which is a BSD-like license, but there are many successful open-source projects that use a different approach. You may wish to investigate MySQL and JBoss as alternative business models. As I am sure you are aware, the ASF is not the only way to make code open-source. You can always host the source code and associated development framework (newsgroups, email lists, etc) on your own site, or use the SourceForge site. If you let us know a little more about the business goals of Daffodil Software we may be able to offer better advice. Disclaimer: No responsibility is taken for any consequences of you or your company acting on any statements made in this email. Regards, Simon PS: Sorry for the wide cross-posting. Nicola's reply suggested this topic may be of interest to all these groups.. PPS: Nicola, I hope Ashish is actually subscribed to one of the lists receiving this email. If this is not the case, could you please forward this email. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
