[fileupload] Re: Feature request. Multiple file upload.
I think you're looking for [EMAIL PROTECTED], which I've cc'ed. - Rod On Wed, 1 Sep 2004 [EMAIL PROTECTED] wrote: I've been asking on commons-user about how to upload multiple files at once, and I'm told this is not a feature of fileUpLoad. The classic interface would be a file chooser, shift select for a group, control select for n individuals, then ftp to the server. This is not provided by HTML, and is a mess in javascript. If the number of files is not known in advance it gets really messy. Regards DaveP. snip here * -- DISCLAIMER: NOTICE: The information contained in this email and any attachments is confidential and may be privileged. If you are not the intended recipient you should not use, disclose, distribute or copy any of the content of it or of any attachment; you are requested to notify the sender immediately of your receipt of the email and then to delete it and any attachments from your system. RNIB endeavours to ensure that emails and any attachments generated by its staff are free from viruses or other contaminants. However, it cannot accept any responsibility for any such which are transmitted. We therefore recommend you scan all attachments. Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent those of RNIB. RNIB Registered Charity Number: 226227 Website: http://www.rnib.org.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
site update process?
Is there documentation somewhere for the currently recommended process of updating the commons site? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: site update process?
OK, so maven site will actually upload the site to the server? Specifically (all from jakarta-commons/commons-build): 1. run maven site:generate and confirm the local copy looks OK 2. run maven site which will both generate and deploy the site Is that right? Do we want commons-site-generate and commons-site-deploy instead? Will this publish the sandbox as well, or do I do that independently? - Rod On Wed, 14 Jul 2004, Mark R. Diggory wrote: The strategy is to use the maven site goal in the /jakarta-commons/commons-build project to build an deploy a new copy of the site. Usually it is wise to run 'site:generate' first and verify the local copy was built properly. -Mark Rodney Waldhoff wrote: Is there documentation somewhere for the currently recommended process of updating the commons site? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: site update process?
On Wed, 14 Jul 2004, Mark R. Diggory wrote: Rodney Waldhoff wrote: OK, so maven site will actually upload the site to the server? Specifically (all from jakarta-commons/commons-build): 1. run maven site:generate and confirm the local copy looks OK 2. run maven site which will both generate and deploy the site Is that right? Pretty much. It would probibly be wise to instert a backup step before deploying just for easy recovery if anything goes wrong. while this could be automated, it may be wiser for the person to physically backup the /www/jakarta.apache.org/commons directory by hand into a temporary tar file, so they know they are properly backed up before going forward. Its important to note that all the project sites are subdirectories of /www/jakarta.apache.org/commons, I sometimes wish this were not the case and that the toplevel could be updated without any risk to the contents of those subdirectories, which would be the case if they existed within separate dorectories from the top level site. Do we want commons-site-generate and commons-site-deploy instead? I'd rather stick to the defaults as much as possible instead of customizing the goal name being called, there is still room to customize in maven.xml via overloading, pre-goal and post-goal tags. You misunderstand me. There already exists commons-site-generate and commons-site-deploy in commons-build/maven.xml. Do we use those? What are they for? Will this publish the sandbox as well, or do I do that independently? No, there is a separate sandbox-build projects for the sandbox at this time. Just for clarification, this only rebuilds the top level site, its upto each project to keep their site uptodate by running 'maven site' in thier project directory. So if I want to update commons-foo's site, I repeat the process above, but from jakarta-commons/commons-foo instead, correct? Doesn't the maven-reactor stuff carry this through from the root on down? -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: site update process?
So it comes down to (a) use maven and (b) push it to the server any way that works? I thought you guys had set up something sexier than that, but it works for me. - Rod - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons cache
On Wed, 14 Jul 2004, Baum, Karl wrote: The project almost seems like yet another caching implementation in itself, not a thin wrapper (I could be wrong though since I just quickly looked it over.). No, that's right, it's YACI, although I believe it pre-dates some of those you mention. I am wondering [...] if it's still actively being developed? No, it's not, although the existing code is functional. Karl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[primitives] XxxStack questions
I've been doing a little clean-up of commons-primitives in order to move toward a 1.1 (or better) release. I notice that back in April several Stack implementations were introduced, with names like FloatStack and IntStack, etc. I wonder if: 1) in keeping with the XxxList implementations, if XxxStack should in fact be an interface, rather than a concrete class 2) we might be able to get away with simply adding the stack methods (push/peek/pop) to the XxxList interfaces, and providing adapters to and from the Object based Stack, as necessary. 3) we should make XxxStack descend from XxxCollection, at minimum Any thoughts? - Rod - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Closing a sandbox project Was: [ANN] Chain Promoted to Commons Proper
On Sat, 3 Jul 2004, Henri Yandell wrote: Options: a) cvs remove everything and add a README.txt or STATUS.html to indicate that it is dead. b) kill it. I effectively did this with 'io' as I merely moved the old sandbox repo bodily over into the main commons module. c) cvs remove everything, then use it as a development branch. This has been done before, but not much recently. My view is b) a) c), but I suspect the community view is more a) b) c). I also prefer (b), as this saves the version history. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] JDK1.5
For the record, while I'm +0 on moving toward JDK 1.5 support within collections, I'm certainly -1 on abandoning JDK 1.4 support in the near future. - Rod On Wed, 23 Jun 2004, Stephen Colebourne wrote: While release 3.1 is being tidied up (still time to vote ;-), I thought I'd just put out a note about JDK1.5. One of the key enhancements in JDK1.5 is generics which allows typed classes using the angle bracket notation. The biggest area this impacts is collections. Clearly questions have to be raised as to how this affects [collections]. So far, I have done no work to see if [collections] will compile under JDK1.5. My expectation is that it will, but there are no guarantees. To take full advantage of generics will involve a considerable rewrite of [collections]. It will affect every class, and produce a version that only compiles on JDK1.5. I have no doubt that Sun spent many mandays changing the JDK classes to achieve this update. Personally, I have no plans to update [collections] to JDK1.5 (no itch, too much effort). If anyone else does, feel free to come in and either change [collections], or (more likely) create a new [collections15] project. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [testutils] Is there any commons area for generic test code?
On Wed, 9 Jun 2004, Alex Karasulu wrote: Is there a place where we can collect and localize utility methods and classes used for unit testing? I have not found anything yet. Is it even worth doing this? If the answer is no, then yes to the two questions above, is it worth creating a sandbox area where we can start gathering useful utilities for unit testing? The existing sandbox project JUX (http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/jux/) was created for a simliar purpose, although it looks like someone has removed its web prescence. The code there has gone stagnant but is still works as well as ever. Also, someone once contacted me about a simliar and apparently larger project on sourceforge, although I can't find it now, junit add-ons or something like that. - Rod - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [testutils] Is there any commons area for generic test code?
On Fri, 11 Jun 2004, Alex Karasulu wrote: I looked at JUX just now and saw that you have one class there called ObjectTestCase.java. Would you rather move the stuff already put into test to JUX or just add this class to the test project? Feel free to move it (and its tests) over to the test project. If I can find the time, maybe I'll poke around a bit in the test project as well. - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[functor] Broken links around /commons/sandbox/functors (fwd)
FYI, I hadn't noticed before but the re-mavenization that occured a little while broke a number of links in functor, since the previous (also maven generated) functor site included the source and test xrefs. - Rod -- Forwarded message -- To: [EMAIL PROTECTED] From: Randy J. Ray Date: Thu, 10 Jun 2004 15:49:09 -0700 Subject: Broken links around /commons/sandbox/functors Came across the pages on the Functor part of the Jakarta Commons project, but all of the links for code examples and the programming katas series were broken. Shame too, I'd have liked to see the code... :-) Randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections][lang] generic min/max functions
On Tue, 25 May 2004, matthew.hawthorne wrote:
Emmanuel Bourg wrote:
Yes it's an alternative, but at the cost of additional lines to create a
collection.
Date date = ComparableUtils.min(date1, date2)
vs
Collection dates = new ArrayList();
dates.add(date1);
dates.add(date2);
Date date = (Date)Collections.min(dates);
I see your point now. But, in the meanwhile, you could always do it
this way:
Date date = Collections.min(Arrays.asList(new Date[] {date1, date2}))
I'd imagine that this may be a bit wasteful (object-creation wise), but
it's a one liner nonetheless.
Or, for what it's worth:
Date date = date1.compareTo(date2) 0 date2 : date1;
- R.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] improvements to the charter
Sections 2 and 3 are part of the form requested by the Jakarta PMC as part of a sub-project proposal (this info used to live at http://jakarta.apache.org/site/newproject.html before the incubator came into being.) I'm not sure why we'd want to remove this information, although it might make sense to note where reality deviated from the plan. Also note the comment at the top the charter page. This was the specific proposal approved by the PMC. If we want to make revisions or comments to that charter, so be it, but let's not pretend that the revision is the history. On Fri, 14 May 2004, Henri Yandell wrote: [hopefully all these general emails won't mean that only one turns into a living thread] I'd like to try and get us moving forward on the Commons charter a bit. It's easy to turn this into a long series of misunderstood arguments, so my first suggestion is hopefully something very unargumentative. [cf http://jakarta.apache.org/commons/charter.html] I'm proposing that we: ** Remove (1.5.2) as it has never happened and is nothing our community is striving to make happen. This also involves a FAQ entry on the directory being removed. Remove (2) as this is not relevant to the charter nowadays, plus it's not even an accurate representation of the original components. If this information is deemed useful, we need to ask Craig to give us another history lesson and make some notes, probably elsewhere. Remove (3) as it is no longer relevant and should be documented in an available resources section. [ie) can a new Commons component use JIRA, where is our wiki etc]. ** I don't believe any of these are too big a deal and getting things moving will give us a foundation for future discussions. I think that a typical 3 +1 and no -1 vote should be fine for such a thing [unless anyone knows of obscure rules], and will plan to send out such a vote on the above if no discussion occurs. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] [PROPOSAL] Release 2.1.1
+1 On Sat, 22 May 2004, Stephen Colebourne wrote: I am proposing that we release a patch release to v2.1, called v2.1.1. The aim of the patch is to indicate to those still using 2.1 the changes that they must make to be compatible with 3.1. The patch includes: 1) Deprecate clashing methods in IteratorUtils (emptyIterator, arrayIterator, singletonIterator) 2) Add two new classes EmptyIterator and EmptyListIterator to be used as deprecation destinations. Any objections to this strategy? Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is Jakarta Commons?
I don't follow. The current Jakarta Commons charter reads (under scope of the subproject): The subproject shall create and maintain packages written in the Java language, intended for use in server-related development, and designed to be used independently of any larger product or framework. in what way is anything in j-c specifically different from that statement? On Sat, 20 Dec 2003, Stephen Colebourne wrote: Jakarta is having trouble redefining what is truly stands for. I had hoped that in Jakarta-Commons we knew. However, since its specifically different to what is in the charter, I guess we should decide. And then update the charter. http://jakarta.apache.org/commons/charter.html From the websites: 'small scale, reusable, code components that are useful in multiple Jakarta subprojects' 'focused on all aspects of reusable Java components' 'creating and maintaining reusable Java components' 'collaboration and sharing, where developers from throughout the Jakarta community can work together on projects to be shared by the Jakarta projects and Jakarta users' There are other practical ways to define it. Each J-C component has insufficient community on its own to survive at Apache, either as an independent TLP or within another TLP. Yet within J-C the component is supported and watched over. For example, one way to view this is by mailing lists. If each commons component had its own mailing list, then most would be very quiet. Not enough to stand alone. My preferred short definition of J-C is: 'creating and maintaining small-scale, reusable, utility components written in Java' Is this definition OK? Any comments? Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] [proposal] Moving To Apache Commons
As a contributor to and user of commons-codec, I'm voting -1. My reasons, as I've described in more detail on the apache-commons list and probably others, are: 1) a-c organization: I think the organizational structure of apache-commons (one list per component, balkanized karma rights, etc.) is bad for those components technically and socially, and possibly bad for the ASF from an oversight perspective. 2) subversion: I think moving tiny components to subversion first (i.e., before larger projects), creates social issues for those components. (see http://article.gmane.org/gmane.comp.apache.commons.general/127 for more on this) I assume this is a majority vote, not a consensus one, so this is just a vote, not a veto. (If this is to be a concensus vote, I can probably be persuaded to change my vote to -0. I don't really want to block this move if the majority really want to do it, I just think it is a bad idea at this time.) - Rod On Fri, 19 Dec 2003, Tim O'Brien wrote: Codec, a small - probably the smallest - piece of code in Jakarta-land. Is well suited for inclusion in Apache Commons. I propose that Codec be used as a guinea pig of sorts to test the waters of Apache Commons. It is not language specific, and it is something that could be excised from the Commons with limited fuss. To this end, I propose that Jakarta Commons Codec be officially transformed into Apache Commons Codec. Simultaneous with the move from J-C to A-C - #1. Commons Codec will be hosted on Subversion Why? Subversion is ready and superior in almost every aspect. Moving smaller projects such as this one to Subversion will allow us to iron out any kinks, and will help nudge more projects in this direction. #2. Commons Codec will use Jira for issue tracking. #3. All committers to Commons Codec are also granted access to Apache Commons - 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: [Functor] Unit tests fail in Gump
The (manually created) build.xml file in the commons-functor CVS tree now
includes ${test.home} within ${test.classpath}, which fixes this problem.
I'd recommend that gump use that, rather than a maven-generated build.xml.
Thanks for pointing this out Stefan.
- Rod http://radio.weblogs.com/0122027/
On Fri, 12 Dec 2003, Stefan Bodewig wrote:
See http://gump.covalent.net/log/commons-functor.html.
The problem is that two of the kata 4 tests try to load .txt files
as resources from the classloader, but the (Maven generated) build
file doesn't copy them to the appropriate place (target/test-classes
would probably the expected place).
I don't know enough about Maven to send a patch, sorry.
I've fixed Gump by adding the test source directory itself to Gump's
classpath, but would love to get rid of the hack.
Thanks
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [events] building
In commons-primitives, the following tag seems to work: dependency idcommons-collections:commons-collections-testframework/id versionSNAPSHOT/version /dependency unless I've done something funky locally that I've forgotten about. On Wed, 10 Dec 2003, Stephen Colebourne wrote: The idcommons-collections+testframework/id came from Brent, so I assume is valid Maven. I am still hoping to get a valid SNAPSHOT onto ibiblio before xmas. Unless your 20031207 references mean that you have already sent an update to ibibilio? Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] roadmap
What does hash plugins mean? On Tue, 9 Dec 2003, Stephen Colebourne wrote: o.a.c.primitives - common utilities, eg XxxUtils classes o.a.c.p.collection - collections o.a.c.p.list - list o.a.c.p.iterator - iterators o.a.c.p.hash - hash plugins o.a.c.p.map - maps Stephen - Original Message - From: Rodney Waldhoff [EMAIL PROTECTED] I'm in favor of re-packaging for 2.0 (though I'd like to do a 1.1 release first), but I'd like to only have to do it once. What's the proposed new structure? On Sat, 6 Dec 2003, Stephen Colebourne wrote: Are you still happy to move to the o.a.c.primitives package structure (v2.0)? Stephen -- - Rod http://radio.weblogs.com/0122027/ - 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] -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang][collections][primitives] etc, JDK compatibility query
I'm strongly opposed to requiring JDK 1.4 at this time in collections or primitives. I don't use or contribute to lang, but I suggest it's a bad idea there too. On Mon, 8 Dec 2003, Ash .. wrote: I wish to know what the compatibility objectives of the forthcoming releases for the components lang, collections, and primitives are. Specifically, will they necessitate use of JDK 1.4? Ash - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] roadmap
I'm in favor of re-packaging for 2.0 (though I'd like to do a 1.1 release first), but I'd like to only have to do it once. What's the proposed new structure? On Sat, 6 Dec 2003, Stephen Colebourne wrote: Are you still happy to move to the o.a.c.primitives package structure (v2.0)? Stephen -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: class-mobility between packages
On Fri, 5 Dec 2003, Stephen Colebourne wrote: The 'line' is the release. Once code is released we have a duty of backwards compatability to it. Thats not to say it will never move, but it can only do so by deprecating the original. I think we should be trying harder than that. While we may not *need* to always maintain backward compatiablity with unreleased code, in the sense that we haven't promised it to anyone, we should strive to maintain compatiablity anyway. To do otherwise is to harm our early adopters, and to do that is to harm the project itself. Some refactoring occurs because of history - collections was a bundle of collections written elsewhere rather than a dedicated, planned re-usable component. Collections 3.0 switches from bundle to planned, which does involve some deprecation moves. It should be much quiter after collections 3.0 (lang was much quiter after 2.0). Primitives was a special case in that code existed unreleased for so long that it became release-like. Hence care has been taken in how it has been moved. Stephen -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] roadmap
I'd like to do a 1.1 release some time soon. This would include: a) performance improvements to TypeList.clear b) the static Adapt class both of which are already in place. Other changes small enough to be fully backward compatiable could be rolled in as well. On Fri, 5 Dec 2003, Ash .. wrote: I would like to know what the general roadmap for the primitives project is, when the next release is slated to be, what remains to be done in view of that release, and the kind. Ash -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [collections] Primitive-value maps
No, classes for this purpose which previously existed in collections were moved to (and released from) the commons proper project primitives. http://jakarta.apache.org/commons/primitives On Thu, 4 Dec 2003, Arun Thomas wrote: Ash, Classes for this purpose which previously existed in COLLECTIONS were moved to the Sandbox project - PRIMITIVES. Please take a look there. There's apparently a lot of work going on with these classes, so check it out. -AMT -Original Message- From: Ash .. [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2003 9:51 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [collections] Primitive-value maps While waiting for a +1 on the MapUtils.getPrimxxxValue() methods, I have been wondering why the commons collections framework does not have Maps that store and help retrieve primitive values. Stuff like IntMap with put(Object key, int value), etc. I mean, when there are primitive-value collections (lists and sets), why not map? Maybe this was discussed before. In any case, perhaps we can have them. Comments. Ash Reposting this, so that if we are decided on the method signatures, I can work on the implementation this weekend. Ash [Stephen] I would only add the full signature version (with default). That way the method name can just be getDouble(). But that would provoke the question if I want to retrieve a primitive without specifying a default, why should I have to mention a default (even 0) everytime?? I would propose we inlclude both variants (with and sans default), and have a uniform naming for them. Even if we add only the default-taking method today, what if we decide tomorrow that the defaultless one can be useful. And then, I think it is ok if we cannot preserve the same method names. so, I propose the following: public static double getIntValue(Map map, Object key) public static double getIntValue(Map map, Object key, int defaultValue) etc for each prim (and String) Waiting for feedback from others. I can implement these methods after I am done with the subarray(prim[]) ones. This is a very old class in [collections] and pre-dates me. I would probably oppose adding these methods now. But why?? Ash -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] This is a very old class in [collections] and pre-dates me. I would probably oppose adding these methods now. However, now that we have them, I would support having the primitive methods as you propose. I would only add the full signature version (with default). That way the method name can just be getDouble(). Stephen - Original Message - From: Ash .. [EMAIL PROTECTED] I am curious to know why MapUtils does not have getters that return primitive types. Perhaps there was a discussion on whether it was needed or not, you could point me to such discussion that took place in the past when this class was conceived. In any case, I think that getters that return primitives could be very useful, much more than those that return wrapper objects. Thus, I think we could do with methods like: MapUtils.getDoubleValue(Map map, Object key [,defaultValue]); If the answer to my question is you can do a MapUtils.getDouble(map, key).doubleValue() and so on, I would say, having a built-in method enhances the use of this class than having a programmer resort to such multiple method call. Of course, the internal implementation would do the same, but in the end, client code would look far neater. Let me know, Ash _ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Tired of 56k? Get a FREE BT Broadband connection http://www.msn.co.uk/specials/btbroadband - 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] -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] pairs package name
Why can't these all just go with the maps? On Wed, 3 Dec 2003, Stephen Colebourne wrote: The pairs package name is perhaps not quite right. I would like the package to hold all non-collection data structure: - MapEntry - KeyValue - MultiKey How about renaming the package to data? (no backwards compatability issues) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] pairs package name
Maybe I just need to dig into this more deeply, but I find any form of Pair or Object[2] class being exposed as a public interface of commons-collections a bit questionable. On Wed, 3 Dec 2003, __matthewHawthorne wrote: o.a.c.c.data could work. some other ideas: o.a.c.c.types o.a.c.c.elements Stephen Colebourne wrote: KeyValue is not directly associated with maps - its a free form key value pair. MultiKey could also be used in a List or Set. Stephen - Original Message - From: Rodney Waldhoff [EMAIL PROTECTED] Why can't these all just go with the maps? On Wed, 3 Dec 2003, Stephen Colebourne wrote: The pairs package name is perhaps not quite right. I would like the package to hold all non-collection data structure: - MapEntry - KeyValue - MultiKey How about renaming the package to data? (no backwards compatability issues) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Rod http://radio.weblogs.com/0122027/ - 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] -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] Re: [PROPOSAL] emeritus committers?
With 6 binding +1s [Rodney Waldhoff, David Graham, Yoav Shapira, Martin Cooper, Gary Gregory, Robert Burrell Donkin] and no -1s, this vote has passed. As noted in the thread, Arun and Ted have been otherwise active, so that leaves the following 14 committers being moved to emeritus status: arron - Arron Bates conor - Conor MacNeill dsale - Doug Sale dwinterfeldt - David Winterfeldt hammant - Paul Hammant jariw - jariw AT hyperlink-interactive DOT co DOT uk jefft - Jeff Turner marcsaeg - Marc Saegesser mas - Michael Smith nacho - Ignacio J. Ortega noel - Noel J. Bergman paulo - Paulo Gaspar serge - Serge Knystautas vmassol - Vincent Massol I can set up the emeritus committers page today, but I don't think I've got karma for modifying the avail file. Can someone volunteer to take care of the avail file? On Thu, 13 Nov 2003, Rodney Waldhoff wrote: There is a perception in some circles that Jakarta as a whole, and Jakarta Commons in particular, is too large for sufficient PMC oversight. In my opinion, particularly with respect to Jakarta Commons, this is not the case, but one way to combat that perception is to recognize that although the CVS avail file lists 72 committers for the jakarta-commons repository (see http://cvs.apache.org/~rwaldhoff/jakarta/jakarta-committers.html), not all of those folks are actively working in Jakarta Commons anymore. Removing inactive committers from the avail file (and naming them emeritus committers) is one way to recognize that fact. The jakarta guidelines state At times, Committers may go inactive for a variety of reasons. A Committer that has been inactive for 6 months or more may lose their status as a Committer. Getting access back is as simple as re-requesting it on the project's Developer mailing list. http://jakarta.apache.org/site/roles.html The following 16 folks are listed in the CVS avail file, but have not made any commits in the past year (since 13 Nov 2002): amamment - Arun Mammen Thomas arron - Arron Bates conor - Conor MacNeill dsale - Doug Sale dwinterfeldt - David Winterfeldt hammant - Paul Hammant husted - Ted Husted jariw - jariw AT hyperlink-interactive DOT co DOT uk jefft - Jeff Turner marcsaeg - Marc Saegesser mas - Michael Smith nacho - Ignacio J. Ortega noel - Noel J. Bergman paulo - Paulo Gaspar serge - Serge Knystautas vmassol - Vincent Massol It may be that some of these folks have been active in non-CVS ways, for instance, by posting to the commons-user or commons-dev lists, I haven't checked (nor am I exactly sure how I could programmaticly check that). Removing those 16 would reduce the number of active committers to 56, a more that 20% reduction in the perceived size of jakarta-commons (by that metric at least). Just to clarify, I have no issues with any or all of those folks maintaining access to the jakarta-commons CVS module, nor is this some sort of judgment of a lack of activity (indeed there are a number of folks on that list that I have a lot of respect for). Rather, this is a recognition that those folks have moved on for the time being and an attempt to make the perceived size of Jakarta Commons more accurately reflect the reality of the matter. As the guidelines state, a simple post to commons-dev would be all that is needed to restore direct CVS access and reverse the inactive status. The Proposal: Unless anyone on that list wants to declare themselves active right now (or someone else can vouch for some sort of commons related activity in the past year or so), let's invoke that paragraph of the jakarta guidelines and declare these folks inactive committers. Specifically, let's: (1) remove those folks from the avail file and (2) add an emeritus committers page (or section of some existing page) to the jakarta-commons website that acknowledges their contributions and indicates the mechanism by which they can once again get CVS access. -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] emeritus committers?
On Fri, 14 Nov 2003, Shapira, Yoav wrote: Howdy, BTW i think that exercise is something that we'll need to repeat sometime soon for the whole of jakarta. I agree, which is why I wanted to ask for the script/method used to produce this list of inactive committers for a given module. Me three, I just wanted to start small. Yoav Shapira - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Presence for ALL Jakarta Commons components
On Fri, 14 Nov 2003, Martin Cooper wrote: Personally, I'd prefer to see any given component exist (actively) in either Proper or the sandbox, but not both. Once a component has been promoted, it should stay in Proper, and its presence in the sandbox should be removed. I understand the history in the particular case of CLI, but I'd just as soon avoid that particular scenario going forward. +1 - Rod http://radio.weblogs.com/0122027/ Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] Object/JDK integration - was Proposed interface changes
Alternatively, you're welcome to develop an alternative implementation of primitive collections within a distinct jakarta-commons component, or even within commons-primitives itself (although I suspect we'd all want distinct distributions of the two approaches). My veto was to the notion of removing the current approach, not to developing a second approach in one form or another. Indeed, the commons charter recognizes, perhaps even encourages, alternative implemenations of the same interface/design space. On Fri, 14 Nov 2003, Stephen Colebourne wrote: Unfortunately, previous attempts to get me a signin at codehaus failed, probably due to my ineptitude at command lines. I know the sourceforge way, so it'll do for the moment. If you or anyone else wants to help out, drop me a line. Stephen From: __matthewHawthorne [EMAIL PROTECTED] Don't forget about codehaus.org, they have some cool projects also. But I'm not sure how hard it is to get a project going over there... Stephen Colebourne wrote: I have applied for a sourceforge project, joda-primitives, to house the primitives sandbox code. Hopefully that will go OK and the move will then take place. The sandbox code will be relicenced to the Joda Software Licence (my personal licence, which is a reworded Apache clone). Any objections please state now! Stephen - Original Message - From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Thursday, November 06, 2003 9:43 PM Subject: Re: [primitives] Object/JDK integration - was Proposed interface changes I hereby accept the -1 veto on this topic (it is also valid according to the rules ;-). Part of my aim with this thread was to try to draw these long ongoing discussions to a final conclusion by clearly agreeing on design once and for all. There are two clear and distinct philosophies here, and I don't think either holds all the answers. My responses to the specific points are inline below - they are intended for information rather than discussion. --- I would like to move the discussion forward into a world where there are two primitive collection package designs (there seems to be a demand for both). [primitives] has the name, history and rights to be the commons implementation. (It may be a new project, but the code is old). I hope that it can be improved with agreements on interface extensions, package changes and additions - hopefully from the similarly designed PCJ library. I also hope I can contribute to it. Therefore, the primitives sandbox code needs either: a) a new name, remaining at commons b) a new home, away from Apache I'm guessing (b) is more likely, although I instinctively prefer Apache and (a). I also hope to continue some work on this codebase, wherever it is, and bring it to a release. Opinions on a/b? --- Responses inline (1) The proposal roughly doubles the number of methods per interface while providing little or no additional functionality. The additional functionality is integration. (2) The proposed API is misleading. Every resulting interface and implementation contains many methods that declare an Object parameter but in actuality only accept Objects of a specific Type. (E.g., IntCollection would have add(Object) method that only accepts Integer or at most Number.) Although not implemented, I wanted to have the ability to effectively plugin a converter between primitive and Object. (3) The proposed API is inconsistent: (3.a) IntList.add(Object) and IntList.add(int) are more or less equivalent (assuming Object instanceof Integer), but IntList.remove(Object) and IntList.remove(int) mean two dramatically different things. This is actually a problem with the commons-proper version to some degree, however the solution of two different method names is undoubtably simpler when not extending the JDK. (3.b) As proposed, methods that can be overloaded by changing the signatures e.g., add(Object) and add(int), will retain the same name while methods that require different return types must change the method name e.g., get(int):Object and getInt(int):int. I toyed with the idea of always using the term 'value' when referring to primitives, eg. addValue(), removeValue(), toValueArray(). This worked until I thought about the confusion when a Map was implemented. The alternative consistent approach is addInt(), removeInt(), toIntArray(). This seems an acceptable choice too. (4) At least one of the suggested advantages of the proposed approach--that no wrappers or adapters are needed--is incorrect. If IntList extends List, then an IntList can be used directly wherever a
[PROPOSAL] emeritus committers?
There is a perception in some circles that Jakarta as a whole, and Jakarta Commons in particular, is too large for sufficient PMC oversight. In my opinion, particularly with respect to Jakarta Commons, this is not the case, but one way to combat that perception is to recognize that although the CVS avail file lists 72 committers for the jakarta-commons repository (see http://cvs.apache.org/~rwaldhoff/jakarta/jakarta-committers.html), not all of those folks are actively working in Jakarta Commons anymore. Removing inactive committers from the avail file (and naming them emeritus committers) is one way to recognize that fact. The jakarta guidelines state At times, Committers may go inactive for a variety of reasons. A Committer that has been inactive for 6 months or more may lose their status as a Committer. Getting access back is as simple as re-requesting it on the project's Developer mailing list. http://jakarta.apache.org/site/roles.html The following 16 folks are listed in the CVS avail file, but have not made any commits in the past year (since 13 Nov 2002): amamment - Arun Mammen Thomas arron - Arron Bates conor - Conor MacNeill dsale - Doug Sale dwinterfeldt - David Winterfeldt hammant - Paul Hammant husted - Ted Husted jariw - jariw AT hyperlink-interactive DOT co DOT uk jefft - Jeff Turner marcsaeg - Marc Saegesser mas - Michael Smith nacho - Ignacio J. Ortega noel - Noel J. Bergman paulo - Paulo Gaspar serge - Serge Knystautas vmassol - Vincent Massol It may be that some of these folks have been active in non-CVS ways, for instance, by posting to the commons-user or commons-dev lists, I haven't checked (nor am I exactly sure how I could programmaticly check that). Removing those 16 would reduce the number of active committers to 56, a more that 20% reduction in the perceived size of jakarta-commons (by that metric at least). Just to clarify, I have no issues with any or all of those folks maintaining access to the jakarta-commons CVS module, nor is this some sort of judgment of a lack of activity (indeed there are a number of folks on that list that I have a lot of respect for). Rather, this is a recognition that those folks have moved on for the time being and an attempt to make the perceived size of Jakarta Commons more accurately reflect the reality of the matter. As the guidelines state, a simple post to commons-dev would be all that is needed to restore direct CVS access and reverse the inactive status. The Proposal: Unless anyone on that list wants to declare themselves active right now (or someone else can vouch for some sort of commons related activity in the past year or so), let's invoke that paragraph of the jakarta guidelines and declare these folks inactive committers. Specifically, let's: (1) remove those folks from the avail file and (2) add an emeritus committers page (or section of some existing page) to the jakarta-commons website that acknowledges their contributions and indicates the mechanism by which they can once again get CVS access. -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] emeritus committers?
On Thu, 13 Nov 2003, Noel J. Bergman wrote: We've done this on James, as well. However, we consider more than CVS commits in terms of activity. And in the one case where someone was mistakenly listed because of a lack of CVS commits, despite being active on the mailing list, he complained. And rightly so. Right on. The act of complaining alone makes one active. This isn't kicking anyone out, it's just removing CVS access to avoid giving the impresssion that there are 70+ people actively making changes to the jakarta-commons CVS tree, when more that 20% of those people haven't made any commits. I'm more than happy to acknowledge any sort of activity as making one an active committer. In fact, simply indicating that one would like to be considered an active committer is more than enough for me. If someone who hasn't made any commits in a year would like to retain access anyway, just say so. If we remove access now and such a person would later like to have access once again, just say so. Emeritus committer is the same as committer, except for what's listed in the avail file (the thing that will tell you don't have sufficient karma to commit to the repository). A simple post to the list will get one added back into that list. This is an entirely reversible action. --- Noel - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] emeritus committers?
On Thu, 13 Nov 2003, Shapira, Yoav wrote: Howdy, Actually, I'm curious to know how you obtained this list: some script with mixed CVS commands? I'd like to come up with similar lists for other modules where I'm a committer. I *know* for example that tomcat hasn't had more than 10 active committers during the past year even though there are 64 on the page you cited. I've been playing with some ruby scripting to do this and the jakarta-committers.html report, but shell and system commands do most of it. In particular: cvs log -d 2002/11/132003/12/21 | grep state: gives you the date and name of all changes to the repository for a given date range. A little regular expression matching on that will give you the names (or at least user ids). E.g., this script will give you a list of the unique accounts that have made commits in the past year: #!/usr/bin/ruby @tempFile = log.tmp @cmnd = cvs -d log -d \2002/11/132003/12/31\ | grep \ state:\ [EMAIL PROTECTED] system([EMAIL PROTECTED]) people = Array.new File.open(@tempFile,r) do |f| f.each_line do |line| matches = / author: ([^;]*); /.match(line) person = matches[1].strip people.push(person) if not people.include?(person) end end File.chmod(0644,@tempFile) File.delete(@tempFile) people.sort! puts people I just diff'ed that list with a list of commiters (cut and pasted from the jakarta-committers.html page) to find out who's not on that list. Yoav Shapira Millennium ChemInformatics - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] emeritus committers?
On Thu, 13 Nov 2003, Rodney Waldhoff wrote: On Thu, 13 Nov 2003, Noel J. Bergman wrote: We've done this on James, as well. However, we consider more than CVS commits in terms of activity. And in the one case where someone was mistakenly listed because of a lack of CVS commits, despite being active on the mailing list, he complained. And rightly so. Right on. The act of complaining alone makes one active. This isn't kicking anyone out, it's just removing CVS access to avoid giving the impresssion that there are 70+ people actively making changes to the jakarta-commons CVS tree, when more that 20% of those people haven't made any commits. Correction: haven't made any commits in at least a year. I'm more than happy to acknowledge any sort of activity as making one an active committer. In fact, simply indicating that one would like to be considered an active committer is more than enough for me. If someone who hasn't made any commits in a year would like to retain access anyway, just say so. If we remove access now and such a person would later like to have access once again, just say so. Emeritus committer is the same as committer, except for what's listed in the avail file (the thing that will tell you don't have sufficient karma to commit to the repository). A simple post to the list will get one added back into that list. This is an entirely reversible action. --- Noel - Rod http://radio.weblogs.com/0122027/ -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] emeritus committers?
I did not take sandbox commits into account, since the sandbox is open to any jakarta, or indeed, apache commmitter. I.e., I was treating jakarta-commons-sandbox as a different kind of repository. So, so far we're moving Ted and Arun over to the active category. On Thu, 13 Nov 2003, Martin Cooper wrote: I'm OK with this in principle. However, there would appear to be a bug in the process used to determine the initial list. For example, Ted Husted has been active quite recently: http://marc.theaimsgroup.com/?l=jakarta-commons-devm=106502784302590w=2 Perhaps you did not take sandbox commits into account? -- Martin Cooper On Thu, 13 Nov 2003, Rodney Waldhoff wrote: There is a perception in some circles that Jakarta as a whole, and Jakarta Commons in particular, is too large for sufficient PMC oversight. In my opinion, particularly with respect to Jakarta Commons, this is not the case, but one way to combat that perception is to recognize that although the CVS avail file lists 72 committers for the jakarta-commons repository (see http://cvs.apache.org/~rwaldhoff/jakarta/jakarta-committers.html), not all of those folks are actively working in Jakarta Commons anymore. Removing inactive committers from the avail file (and naming them emeritus committers) is one way to recognize that fact. The jakarta guidelines state At times, Committers may go inactive for a variety of reasons. A Committer that has been inactive for 6 months or more may lose their status as a Committer. Getting access back is as simple as re-requesting it on the project's Developer mailing list. http://jakarta.apache.org/site/roles.html The following 16 folks are listed in the CVS avail file, but have not made any commits in the past year (since 13 Nov 2002): amamment - Arun Mammen Thomas arron - Arron Bates conor - Conor MacNeill dsale - Doug Sale dwinterfeldt - David Winterfeldt hammant - Paul Hammant husted - Ted Husted jariw - jariw AT hyperlink-interactive DOT co DOT uk jefft - Jeff Turner marcsaeg - Marc Saegesser mas - Michael Smith nacho - Ignacio J. Ortega noel - Noel J. Bergman paulo - Paulo Gaspar serge - Serge Knystautas vmassol - Vincent Massol It may be that some of these folks have been active in non-CVS ways, for instance, by posting to the commons-user or commons-dev lists, I haven't checked (nor am I exactly sure how I could programmaticly check that). Removing those 16 would reduce the number of active committers to 56, a more that 20% reduction in the perceived size of jakarta-commons (by that metric at least). Just to clarify, I have no issues with any or all of those folks maintaining access to the jakarta-commons CVS module, nor is this some sort of judgment of a lack of activity (indeed there are a number of folks on that list that I have a lot of respect for). Rather, this is a recognition that those folks have moved on for the time being and an attempt to make the perceived size of Jakarta Commons more accurately reflect the reality of the matter. As the guidelines state, a simple post to commons-dev would be all that is needed to restore direct CVS access and reverse the inactive status. The Proposal: Unless anyone on that list wants to declare themselves active right now (or someone else can vouch for some sort of commons related activity in the past year or so), let's invoke that paragraph of the jakarta guidelines and declare these folks inactive committers. Specifically, let's: (1) remove those folks from the avail file and (2) add an emeritus committers page (or section of some existing page) to the jakarta-commons website that acknowledges their contributions and indicates the mechanism by which they can once again get CVS access. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: math to apache commons was Re: [all] Separate email list for math development?
I'd say that the discussed scope, at least some visions of it, make it more appropriate for a top level project than apache-commons, but I'll second Henri's advice to cut a 1.0 release from jakarta-commons and draft up a scope/vision document, then make the choice based upon what feels right at the point. I don't think it stretches the jakarta-commons or jakarta-general scope much (or at all, relative to other jakarta projects) to include a set of basic, java-based mathematical utilities--there are certainly plenty of server-side applications of that. A set of basic, not-necessarily-java-based utilities would be more appropriate in apache-commons. A more-than-basic set of utilities, in or out of java, would be more appropriate at the top level IMO. How one defines basic here is obviously an important part of answering this question. On Wed, 12 Nov 2003, Danny Angus wrote: Robert wrote: IMHO we're now starting to forget the original charter. Gier replied: Starting??? :) Please, we've been stretching the charter for *years*. Isn't that a major contributory factor in the, how can I put it.. concern expressed in some quarters about Jakarta? And if so is it not also something we should be addressing by being realistic about issues like this one? You're notion of sorting it out seems to be remove from Jakarta community. That may be what the people involved want to do, which is fine by me, but if they want to stay, it behooves us on the PMC to try and see what we can do to help them out. I'd say that if there is not a _real_ justification for math being in Jakarta which is aligned with Jakarta's mission it is our duty to Jakarta to be realistic about math, and not simply to fudge an artificial accomodation, avoid tough the decisons, and provide ammunition for critics of Jakarta's organisation. I would then feel that I had a moral obligation to the math community to help them find an acceptable new home, and Apache commons seems like a perfectly reasonable suggestion. After all if the math mission really is divergent from our charter then leaving won't be a big wrench, on the other hand if it is aligned well with the charter that is enough justification for math staying. Surely? d. - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [functor] [patch] contributions
Committed, with minor modifications (to reduce the amount of cut-and-paste code between DoWhile and WhileDo). Thanks Herve. On Thu, 6 Nov 2003, Herve Quiroz wrote: Here are the loop ones: DoWhileProcedure and WhileDoProcedure. With some unit tests. Regards, Herve -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [functor] [patch] contributions
This opens the door for Unary and Binary variations of DoWhile and WhileDo, of course. Herve, were you planning on introducing those as well? - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Separate email list for math development?
-0 on splitting commons-math. I don't mind the traffic, and would expect it to be cyclical anyway. (E.g., Jelly was once a very big part of commons dev traffic, but isn't anymore. primitives has been the source of lot of traffic recently, and may be off and on for the next few weeks, but I wouldn't expect that to continue.) I'd think math either reaches a certain level of maturity/stability, and hence generates less traffic, or grows to a point where it no longer belongs in commons at all. -1 on splitting off hivemind by the way. It's not even a commons-proper component yet, so if it's not something of interest to the general commons-dev list, it should move to tapestry-sandbox or sourceforge or something. A sandbox only component should not have it's own list. Where's the oversight? Where's the community? -1 on splitting off jelly, unless its to move jelly out of commons entirely. Jelly accounts for very little traffic these days. On Fri, 7 Nov 2003, Mark R. Diggory wrote: I know from positions taken by Craig and others there is some interest in seeing some of the discussion in the math project get moved off to another list. I know that sometimes the lengthy discussions we have about what must appear to some to be like String Theory, just PLAIN OUT THERE... ;) If its really in the publics interest, I'd be willing to propose possibly starting a separate math developers list. Let me know if theres really a consensus of opinion on this. -Mark -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Separate email list for math development?
splitting here means splitting the mailing lists I had not read robert's proposal before posting this. On Sun, 9 Nov 2003, Rodney Waldhoff wrote: -0 on splitting commons-math. I don't mind the traffic, and would expect it to be cyclical anyway. (E.g., Jelly was once a very big part of commons dev traffic, but isn't anymore. primitives has been the source of lot of traffic recently, and may be off and on for the next few weeks, but I wouldn't expect that to continue.) I'd think math either reaches a certain level of maturity/stability, and hence generates less traffic, or grows to a point where it no longer belongs in commons at all. -1 on splitting off hivemind by the way. It's not even a commons-proper component yet, so if it's not something of interest to the general commons-dev list, it should move to tapestry-sandbox or sourceforge or something. A sandbox only component should not have it's own list. Where's the oversight? Where's the community? -1 on splitting off jelly, unless its to move jelly out of commons entirely. Jelly accounts for very little traffic these days. On Fri, 7 Nov 2003, Mark R. Diggory wrote: I know from positions taken by Craig and others there is some interest in seeing some of the discussion in the math project get moved off to another list. I know that sometimes the lengthy discussions we have about what must appear to some to be like String Theory, just PLAIN OUT THERE... ;) If its really in the publics interest, I'd be willing to propose possibly starting a separate math developers list. Let me know if theres really a consensus of opinion on this. -Mark -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: math to apache commons was Re: [all] Separate email list for math development?
On Sun, 9 Nov 2003, robert burrell donkin wrote: commons-maths will still be part of jakarta-commons :) it'll only be managed by the apache-commons pmc. Which will make it in no way a part of jakarta-commons. Related to or linked from perhaps, but not strictly a part of in any meaningful way. best of both worlds :) - robert - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN][hivemind] hivemind has been temporarily taken offline
The pmc mailing list is [EMAIL PROTECTED] I believe it is closed to pmc mebmers only. Like robert suggests, [EMAIL PROTECTED] might be a good place for general pmc discusion. On Fri, 7 Nov 2003, Harish Krishnaswamy wrote: Yeah where is the pmc mailing list? I was looking for it too, to see what's going on. Is it only for the pmc? -Harish Howard M. Lewis Ship wrote: Beet me to the punch; I was just looking for the Jakarta PMC mailing list, since my previous posting (to the Jakarta General list) got no response. Taking HiveMind offline is drastic, but may be the best course forward. I need to see what the delay is at WebCT. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2003 2:27 AM To: Jakarta Commons Developers Cc: [EMAIL PROTECTED] Subject: [ANN][hivemind] hivemind has been temporarily taken offline the jakarta-pmc have decided to take the hivemind directories offline for a temporary period. this decision was taken in order to protect every body involved from legal action. this is not a judgement of the legal rights and wrongs of the situation nor should it be construed as an admission of guilt. i'd like to thank howard for drawing these possible issues to our attention and hope that he continues to work with the pmc to help us resolve the issues as quickly as possible. the [EMAIL PROTECTED] mailing list is probably the best forum for future discussions of this action or the pmc can be mailed directly. thanks for your understanding. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] Object/JDK integration - was Proposed interface changes
As someone who has both authored and extensively worked with the code in both formulations, I strongly believe the current approach to be the right one. So strongly in fact, that I'm going to veto (-1) the proposed change. Here's several technical reasons why: (1) The proposal roughly doubles the number of methods per interface while providing little or no additional functionality. (2) The proposed API is misleading. Every resulting interface and implementation contains many methods that declare an Object parameter but in actuality only accept Objects of a specific Type. (E.g., IntCollection would have add(Object) method that only accepts Integer or at most Number.) (3) The proposed API is inconsistent: (3.a) IntList.add(Object) and IntList.add(int) are more or less equivalent (assuming Object instanceof Integer), but IntList.remove(Object) and IntList.remove(int) mean two dramatically different things. (3.b) As proposed, methods that can be overloaded by changing the signatures e.g., add(Object) and add(int), will retain the same name while methods that require different return types must change the method name e.g., get(int):Object and getInt(int):int. (4) At least one of the suggested advantages of the proposed approach--that no wrappers or adapters are needed--is incorrect. If IntList extends List, then an IntList can be used directly wherever a List of Integers is expected, but the converse is not true: an adapter is still required to support a List of Integers where an IntList is expected. (5) As a result of previous point, the proposed API is asymmetric--the way in which we treat a List of Integers as an IntList is different from the way we treat an IntList as a List of Integers. (6) The proposed API is more demanding of the runtime environment. The current base package, being independent of java.util.*, can be used in any every released Java version (from 1.0.2 on), and in embedded/micro or sandboxed (e.g., applet) environments that do not include the java.util Collections API. Note that the time and space savings of the primitive collections API are of particular interest to these platforms/environments. The current implementation provides the same functionality as the proposed change, in a smaller, more consistent, and more coherent fashion. - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
hivemind repository taken offline
Please accept my apologies for any inconvenience this may cause, but on behalf of the Jakarta PMC, I've backed up and removed the hivemind directory from the jakarta-commons-sandbox CVS repository until the ASF's ownership of this code base is clear. Further apologies if it turns out I've over-stepped my authority here, but a lazy majority vote of the pmc has approved of making this part of the repository unavailable, and the consensus seems to be that the sooner this happens, the better. I've mentioned on the [EMAIL PROTECTED] list where a copy of this backup is located, when it is time restore the repository. - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Company Acknowledgements [was :Re: [HiveMind] 1.0 Beta]
On Tue, 4 Nov 2003, Robert Leland wrote: You've acknowledged that when you commit any code to Apache you give up ownership of that code. That's not quite right. When you commit any code to Apache (under the Contributors License Agreement), you grant the ASF a non-exclusive right to that code. You retain your rights on your contributions, you're just sharing some rights with the ASF as well. Also what is said on the Web site is governed by the same Apache license. In order to endorse any product or company on an Apache web site there needs to be written permission from the Apache Foundation. The fact that no other company is officially endorsed (Maven has some hidden acknowledgments in it's plug-in docs) says you are asking for a new precedent to be set. While you certainly could make suggestions in the negotiating terms, if that is what the Apache Foundation member, wants to do, is not your responsibility. It is your responsibility to bring this matter to the Apache Foundation as a good steward. It's not clear to me exactly what Howard and or WebCT is asking for. Also plain committers like us are not Apache Foundation members. - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [functor] possible contributions
I would just do it as an internal class for the time being. On Wed, 5 Nov 2003, Herve Quiroz wrote: On Tue, Nov 04, 2003 at 09:06:37AM -0800, Rodney Waldhoff wrote: There are some others but I need to classify them and decide which ones are generic enough to be part of commons-functor... Obviously, I will provide everything with complete Javadoc support and test cases whenever it is relevant. Great. Feel free to submit patches to the dev list. I have already refactored DoWhileProcedure and WhileDoProcedure. The problem I have now is for unit tests. I plan to test it using a loop that increments a counter (probably an Integer). So I could assert values and predicates reagarding the counter at beginning and at the end of the loop. To do this, I need a procedure such as IntegerIncrementProcedure that increments an internal counter at run(). So I ask you: should I code this class as a internal class restricted to testing purposes or should I provide this class as a public one to the commons-functor package ? In the later case, where should I put it (in which package) ? maybe org.apache.commons.functor.core.number ? But this could instead be the scope of a commons-math subpackage... What do you think of it ? Herve PS: While reading my mail looking for typos, I realized that such a procedure would not be quite useful (IntegerIncrementProcedure). Instead, what about some IntegerIncrementUnaryProcedure that increments the parameter o at run(Object o) ? The former Procedure could then be built using a BoundProcedure... PPS: Maybe things are going to be a litlle more complex than I thought with this math/functor issue... I should probably code what I need as an internal class (or an example at least) for now before you decide what to do with this math/functor stuff. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] Proposed interface changes
Some comments inline. I'll use the voting syntax, in an effort to be concise, not formal. On Sat, 18 Oct 2003, Stephen Colebourne wrote: I would like to propose the following changes for the primitives code as we establish it: New interface Collectable (better names?). Superinterface of XxxCollection and XxxMap - size() - clear() - isEmpty() There are so many times that I've needed a shared interface between Collection and Map +0, I've never had that need, but it sounds reasonable to me. - clone() Fix a JDK error I'm +1 to making the implementations cloneable, -1 to requiring this at the interface level (e.g., I'm opposed to IntCollection extends Cloneable). Among other problems, this will be difficult to enforce at the adapter level. - isModifiable() This would be nice to know I'm +0 to a Modifiable interface, but -1 to an isModifiable method. It would be impossible to reliably implement isModifiable at the adapter level. Also, I'm not sure that Modifiable is the proper resolution. Some types may allow set or remove but not add, etc. (SingletonIterator is one such example in the object case). Is such a collection modifiable? - optimize() For example, implemented as a trimToSize +1 New interface PCollection (or PrimitiveCollection): - toCollection() It should be really easy to get a JDK collection from a [primitives] one. TypeCollectionCollection.wrap(mytypecollection) does this already. I'd be OK with adding a convenience method somewhere, though I'm not sure PrimitiveCollection is the right place for it. (Perhaps PrimitiveCollections.toCollection(TypeCollection): Collection?) New methods on IntCollection (et al): - addAll(int[]) - removeAll(int[]) - containsAll(int[]) Primitive handling is often done with arrays at present, so provide good integration -0, I'd prefer simply providing an array-to-primitive collection (or list) adapter, which would then support all these methods and more. - toArray(int[], int) Offers a way to get the primitives into a specific index in an existing array. This is functionally similar to addAll(int,IntCollection)? Then as above, I'd prefer the wrapper approach, or at least the signature addAll(int,int[]) New interface PList (or PrimitiveList): - toList() It should be really easy to get a JDK collection from a [primitives] one. As above (for PCollection.toCollection). - removeRange(int, int) Although possible via subList(), this is quicker and more obvious -0, I'm not sure that's quicker, and the sublist as range operation stuff is pretty well established, but we could do worse. New methods on IntList (et al): - first() - last() Because list.get(list.size() - 1) is a pain +1 - indexOf(int, int) - lastIndexOf(int, int) Completes the set of index methods as per String +1 As long as a reasonable implementation can be made within the adapters. - addAll(int, int[]) Primitive handling is often done with arrays at present, so provide good integration I'm not sure I understand the relationship between this and toArray(int[],int) as above. Do you mean for toArray(int[],int) to return a new array with the elements of the collection inserted? That sounds useful I guess, but I'd stick it in some convenience method and not the core interface. Again I think an adapter between a primitive array and a primitive collection might be most helpful here. IMO, these represent a balanced extension to the JDK collection design to fit well in the primitives problem space. Opinions welcome. Stephen -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Jakarta Commons Primitives 1.0 Released
The Jakarta Commons Team is pleased to announce the first release of Jakarta Commons Primitives. Primitives provides a collection of types and utilities optimized for working with Java primitives (boolean, byte, char, double, float, int, long, short). Generally, the Commons-Primitives classes are faster, smaller and easier to work with than their purely Object based alternatives. DOWNLOADS (source and binaries -- from mirror): * Binary: http://jakarta.apache.org/site/binindex.cgi#commons-primitives * Source: http://jakarta.apache.org/site/sourceindex.cgi#commons-primitives For more information on Jakarta Commons Primitives, see the web site at http://jakarta.apache.org/commons/primitives. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [functor] possible contributions
On Tue, 4 Nov 2003, Herve Quiroz wrote: Hi, I am using commons-functor to build a network simulator (based upon an XML document modified through procedures and validated against predicates each cycle). I had to develop several additions to commons-functor and I thought I could donate them to commons-functor. There are several functors but here are IMHO the most relevant ones: - class Predicates: Predicates utility methods public static Or or(Collection predicates); public static And and(Collection predicates); As there is no constructor for Or/And predicates with a collection as parameter, these methods provide a way to get them. Sounds like a good idea, although I'm having trouble coming up with a reason why we just wouldn't make these methods of Or and And directly? - class WhileDoProcedure: loop procedure The constructor takes a condition (Predicate) and an action (Procedure). The run() method loops, each time testing the condition and running the action. - class WhileDoProcedure: loop procedure Same as above but the running the action and then test the condition. Note: the two last classes extend AbstractLoopProcedure Sounds good as well. I assume one of these is not named WhileDo, perhaps the latter is DoWhile? There are some others but I need to classify them and decide which ones are generic enough to be part of commons-functor... Obviously, I will provide everything with complete Javadoc support and test cases whenever it is relevant. Great. Feel free to submit patches to the dev list. Regards, Herve -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release Commons Primitives 1.0
As previously discussed on commons-dev, we believe Commons Primitives 1.0 is ready for release. The source for this release candidate has been tagged as PRIMITIVES_1_0_RC1 and is available for download at http://cvs.apache.org/~rwaldhoff/commons-primitives/RC1/. For more information on Commons Primitives, see http://jakarta.apache.org/commons/primitives/. Please direct all VOTEs and discussion to commons-dev. A [RESULT] note will be posted to [EMAIL PROTECTED] when voting is complete. Ballot: [ ] +1 I support this release [ ] +0 If you say so [ ] -0 I don't think it's a good idea, but I won't stand in your way. [ ] -1 I'm opposed - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Primitives 1.0
+1 from me, of course On Tue, 4 Nov 2003, Rodney Waldhoff wrote: Please direct all VOTEs and discussion to commons-dev. A [RESULT] note will be posted to [EMAIL PROTECTED] when voting is complete. Ballot: [X] +1 I support this release [ ] +0 If you say so [ ] -0 I don't think it's a good idea, but I won't stand in your way. [ ] -1 I'm opposed -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [functor] possible contributions
On Tue, 4 Nov 2003, Herve Quiroz wrote: On Tue, Nov 04, 2003 at 09:06:37AM -0800, Rodney Waldhoff wrote: On Tue, 4 Nov 2003, Herve Quiroz wrote: - class Predicates: Predicates utility methods public static Or or(Collection predicates); public static And and(Collection predicates); As there is no constructor for Or/And predicates with a collection as parameter, these methods provide a way to get them. Sounds like a good idea, although I'm having trouble coming up with a reason why we just wouldn't make these methods of Or and And directly? I did that not to modify the existing ones. And moreover not to modify the way it is (should?) be handled, that is: OR is a binary operation so you need to compose several ORs that are ORed together to build an n-ary OR. I am not sure I said it clearly enough. Maybe that's a proof that my arguments are not relevant after all. What do you think of it ? Currently the AND and OR functions are not implemented as pure binary operations, but rather operations on a collection (list) of values. Specifically, each maintains a list of predicates. OR evaluates to true if at least one child evaulates to true (and hence evalutes to false when the list is empty). AND evaluates to true if all of its children evaluate to true (and hence evaluates to true when the list is empty). You can already do new And(a,b,c) or new And(a).and(b).and(c) or new And(a,b).and(c), etc., each of which should get you to the more or less tha same predicate. A static factory constructor, such as: And.and(a) == new And(a) or And.and(a,b) == new And(a,b) which would allow: And.and(a).and(b).and(c) or something like that would probably be convienient. So would: And.and(Collection) or And.and(Iterator) - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] 1.0 RC1 available
After looking into this a bit more deeply, it seems that the best way to address this with maven is to modify the maven-dist plugin.jelly file slightly. I've made local changes, and submitted a patch to [EMAIL PROTECTED], but there aren't any changes necessary to the jakarta-commons files to address it. Assuming that the line endings on the README.txt file isn't considered a show stopper, I'm not going to bother to cut a new RC for that. It should be fixed in the final 1.0 release. On Thu, 30 Oct 2003, Rodney Waldhoff wrote: On Thu, 30 Oct 2003, Stephen Colebourne wrote: From: Rodney Waldhoff [EMAIL PROTECTED] On Thu, 30 Oct 2003, Stephen Colebourne wrote: I have checked the src and bin zip files. They seem OK. The only (minor) issue is that the text files have unix line endings. We fixed this on [lang] using an ant call. By fixed, do you mean switch to windows/dos line endings? It seems the files will have to be one or the other. What we did was zip file to have 'windows' endings and targz to have 'uniz' endings. I reckon this keeps most people happy. Sounds reasonable. I used maven to build this distro, but I'll have a look at the lang build.xml and see if I can't get it to do the same. Stephen -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sandbox 'article'
I have not reviewed or (obviously) committed them, although I've made no other changes to cache either, so your diffs should be as good as they ever were. Unfortunately I don't really have time to commit to sheparding patches to the cache stuff in the jakarta-commons-sandbox. If you're a Jakarta or Apache committer, feel free to work with the stuff directly. Otherwise, unless another existing committer wants to pick up this cause, my suggestion would be to move/fork this code to another location and look toward moving it back when there is a more active community. You might also try googling for similiar open source cache projects. I believe there are others. The sandboxed cache stuff is perfectly functional in my experience (I still use it every day in production apps), but clearly isn't backed by a very strong community. You could probably find other projects with as much functionality and a stronger community, or alternatively, build your own such community from the existing codebase, assuming you adhere to the ASF license in doing so. Sorry. I would be happy to field any questions you may have on this code, of course. - Rod http://radio.weblogs.com/0122027/ On Tue, 21 Oct 2003, Lavandowska wrote: Rod, Whatever happened with the patches I sent you for Cache? Did you ever get a chance to review them? Lance --- Rodney Waldhoff [EMAIL PROTECTED] wrote: Also, I'll confirm that cache is indeed dead or at least very very idle. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] 1.0 RC1 available
Great, thanks. A couple of minor comments inline: On Thu, 30 Oct 2003, Stephen Colebourne wrote: I have checked the src and bin zip files. They seem OK. The only (minor) issue is that the text files have unix line endings. We fixed this on [lang] using an ant call. By fixed, do you mean switch to windows/dos line endings? It seems the files will have to be one or the other. I use unix, and so didn't have an md5 utility. The one I found (claims to be a GNU port), rejected the src md5 file until I added '* commons-primitives-1.0-RC1.zip' after the checksum. Then it was OK. However looking at the other jakarta md5s they don't seem to use this format, so I assume its particular to this program. Anyone recommend a better/alternative md5 program for Windows? Doesn't cygwin have an md5 impl? Otherwise I think I've seen Java based impls as well. If we find one that works well, we should add a link to it on the http://jakarta.apache.org/commons/releases/release.html page. Stephen Thanks to Robert by the way for his docs on the mirrored/signed release process. So far it's been very easy to follow. - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] 1.0 RC1 available
On Thu, 30 Oct 2003, Stephen Colebourne wrote: From: Rodney Waldhoff [EMAIL PROTECTED] On Thu, 30 Oct 2003, Stephen Colebourne wrote: I have checked the src and bin zip files. They seem OK. The only (minor) issue is that the text files have unix line endings. We fixed this on [lang] using an ant call. By fixed, do you mean switch to windows/dos line endings? It seems the files will have to be one or the other. What we did was zip file to have 'windows' endings and targz to have 'uniz' endings. I reckon this keeps most people happy. Sounds reasonable. I used maven to build this distro, but I'll have a look at the lang build.xml and see if I can't get it to do the same. Stephen -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] logic for determing log level
Assuming the if() clause isn't there, then:
Is + descriptor + empty?
is evaluated before the call to log.trace(), whether or not that call will
actually yield any output. Putting the if() { } around it prevents the
arguments to log.trace() from being executed if log.isTraceEnabled() is
false.
See
http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/Category.html#isDebugEnabled()
for example.
On Thu, 30 Oct 2003, __matthewHawthorne wrote:
This is a general use question about [logging]. I'm looking through the
source for [betwixt], and I see lines like the following:
if ( log.isTraceEnabled() ) {
log.trace( Is + descriptor + empty? );
}
What is the purpose of doing this check? If trace *is* enabled, then
isn't the same check done inside of the underlying logging implementation?
Is this some type of trick to improve performance? I'm probably
misunderstanding it, but I just think that it adds clutter.
Any insights?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
- Rod http://radio.weblogs.com/0122027/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[primitives] 1.0 RC1 available
I've updated the primitives site at http://jakarta.apache.org/commons/primitives/ and created RC1 distributions at http://cvs.apache.org/~rwaldhoff/commons-primitives/RC1/. Can you all take a look and see if there are any outstanding issues before calling a vote on a 1.0 release? Also, this is my first pass at signing a release, so if someone would like to confirm the md5 and/or asc signatures that'd be much appreciated. Thanks, - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
add commons-primitives to nightly build
Can someone (I guess someone typically means Craig in this case) add commons-primitives to the nightly builds at http://cvs.apache.org/builds/jakarta-commons/nightly/ ? commons-primitives seems to be buildable via ant and maven now. Note that it requires the commons-collections-testframework JAR now being generated by ant dist or maven dist on commons-collections. Thanks, - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] First steps
FYI, I've requested that the maven folks add/update: 1) commons-collections-SNAPSHOT.jar 2) commons-collections-20031027.jar 3) commons-collections-testframework-SNAPSHOT.jar in the repository (see http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-971) and also that they add commons-primitives-SNAPSHOT.jar to the repository (see http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-972). Once commons-primitives and commons-collections-testframework are available via maven, we can deprecate the commons-collections versions to point to the new locations, and once again update the commons-collections-SNAPSHOT to the deprecated versions. At that point we should be free to proceed with a release of either or both components, as far as I can tell. On Thu, 16 Oct 2003, Rodney Waldhoff wrote: I guess I wasn't quite clear there. It was my intention as well to strip the collections part of the current packaging before the release. The plan then is to: A) Repackage what's currently in [primitives] from org.apache.commons.collections.primitives.** to org.apache.commons.primitives.** B) Deprecate what's currently in [collections] at *.primitives.**, to point to the [primitives] version C) Ask the maven folks to publish a -SNAPSHOT and dated build from the resulting commons-collections HEAD to the ibiblio repository D) Initiate a 1.0 release of [primitives] with the current code base, slighly repackaged. E) Remove the *.primitives.** packages from [collections], either before or after D. (With all things being equal, we should probably at least allow the deprecation warnings to show up in the nightly builds for a couple of days first.) Is that right? (Assuming it is) I'll volunteer to be the primitives 1.0 release manager, but I won't have much time until next week to dig into it. Also, I haven't done a release since the mirroring structure was set up, but I suppose I'll be able to muddle through. Are there documenation on that process somewhere? - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
(please) Re: add commons-primitives to nightly build
Where are my manners? I mean that to be please add commons-primitives to the nightly build On Mon, 27 Oct 2003, Rodney Waldhoff wrote: Can someone (I guess someone typically means Craig in this case) add commons-primitives to the nightly builds at http://cvs.apache.org/builds/jakarta-commons/nightly/ ? commons-primitives seems to be buildable via ant and maven now. Note that it requires the commons-collections-testframework JAR now being generated by ant dist or maven dist on commons-collections. Thanks, - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sandbox 'article'
I didn't check the full thread, so maybe someones already pointed this out, but jelly has already been promoted (http://jakarta.apache.org/commons/jelly/). Also, I'll confirm that cache is indeed dead or at least very very idle. - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] First steps
If everyone else is OK with releasing the 1.0 version under org.apache.commons.collections.primitives (rather than o.a..commons.primitives), that sounds OK to me. If we were to repackage along the type-of-collection lines, we'd likely be able to deprecate-and-move from o.a.c.primitives as well, but I guess this way gives us the freedom to choose the new packaging arbitrarily. On Sat, 18 Oct 2003, Stephen Colebourne wrote: The reason that this matters is that there are interfaces involved that we can't change later. So what might get changed? Well I don't see the need to remove anything from the current interfaces. I do believe that there are some methods that can be added. (separate email thread). Can we execute the 1.0 release before digging too deeply into changes to the existing structure? -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] First steps
I guess I wasn't quite clear there. It was my intention as well to strip the collections part of the current packaging before the release. The plan then is to: A) Repackage what's currently in [primitives] from org.apache.commons.collections.primitives.** to org.apache.commons.primitives.** B) Deprecate what's currently in [collections] at *.primitives.**, to point to the [primitives] version C) Ask the maven folks to publish a -SNAPSHOT and dated build from the resulting commons-collections HEAD to the ibiblio repository D) Initiate a 1.0 release of [primitives] with the current code base, slighly repackaged. E) Remove the *.primitives.** packages from [collections], either before or after D. (With all things being equal, we should probably at least allow the deprecation warnings to show up in the nightly builds for a couple of days first.) Is that right? (Assuming it is) I'll volunteer to be the primitives 1.0 release manager, but I won't have much time until next week to dig into it. Also, I haven't done a release since the mirroring structure was set up, but I suppose I'll be able to muddle through. Are there documenation on that process somewhere? - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] First steps
On Tue, 14 Oct 2003, Stephen Colebourne wrote: Are you certain that this makes sense from a commons perspective? To release a version of collections with these classes in only to immediately remove them? Yes, but I think you misunderstand me. The nightly builds have contained collections.primitives for nearly a year. The maven -SNAPSHOT build has as well. To suddenly drop those classes from those JARs seems unnecessarily abrubt. Why not: 1) Deprecate commons.collections.primitives, with pointers to commons.primitives 2) Upload a dated maven snapshot and -SNAPSHOT JARs with that version before removing the classes from commons-collections. This warns users of the change, and gives a binary equivalent to what their used to. Quick and painless and I'll take care of it. The proposed 0.1 release of primitives has exactly the same classes, in the same packages, unaltered. The only change for a user of nightly builds is to add/move to a different jar file. This recognises that there are nightly build users to be looked after (who I would venture to say actually have relatively few rights in terms of complaining about compatability). These users have some change to cope with yes, but one that is trivial to deal with (a new jar file). This seems entirely reasonable to me. A 0.1 release of primitives is ready to go as far as I can see. It just waits a vote, plus a release manager. Is there a reason not to do this? Calling this release 0.1 suggests it's about an order of magnitude less production ready than it is. Why not 1.0? Stephen -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] First steps
For backwards compatiablity, I think what we want is a release of commons-collections.jar containing these types, perhaps marked as deprecated. By date or by name is all the same to me, but if it's not some version of commons-collections.jar, it's not really backwards compatiable with the nightly releases for the past 9 months. On Tue, 14 Oct 2003, Stephen Colebourne wrote: As you will have noticed, the primitives component now exists in jakarta-commons. I have imported the code from [collections] as is, no package changes. The package will need to change to reflect the new component. However for backwards compatability we need to have some kind of a release of these classes in these packages. I am open to suggestions as to how to go about creating this 'release'. It could be a maven style snapshot, or just a 0.1 labelled version. At present, the ant build has been tweaked to create a jar with the name commons-primitives-collections.jar, rather than commons-primitives.jar. Maybe all we need to do is get that jar into ibiblio? Suggestions and proposals please. We also need a website. Is this just a case of creating the xdocs folder as with [collections]? Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] Package layout strategy
Given that a version of the code in question was passed over for release in commons-collections 2.0 for no particuarly good reason and has been complete, stable and in production use in its current form for the past 9 months, why don't we release what we have now as commons-primitives 1.0 and pick up this debate for the 2.0 release? On Tue, 14 Oct 2003, Stephen Colebourne wrote: Well this simple question threw up some debate :-) The debate over packages raises a question over the ambition of the [primitives] component. I am looking to add additional Map, and maybe Set, implementations to [primitives]. I have needed a int/Object and Object/int map on more than one occasion, so I believe that there is a good case for coding it in [primitives]. I don't believe this has to be before the 1.0 release, although it would be nice. As has been pointed out, the complete combination of Maps leads to a lot of classes. See http://pcj.sourceforge.net/docs/api/index.html. This should not greatly concern us however, as we should be code generating the combinations. Although many may be less useful, the overhead is small once code generation is adopted. What is significant is being able to grasp the component quickly. Different people do this in different ways. I am in the camp that prefers lots of smaller packages of related classes. I do not concern myself greatly with inter-package connections because IMO the Java language does not have the scoping rules to make such restrictions possible or worthwhile. (If Java had a friend scope, or a subpackage scope my views might be different.) --- Of the proposed solutions: 1) Named after the primitive type, eg. o.a.c.primitives.boolean Fails because you can't name packages with a keyword, and its not great for maps. 2) All in one. I really dislike this because the package will be ridiculously large, and a new user won't be able to navigate it. 3) Split by collection/adaptor/decorator. This works up to a point, but breaks down due to size in a similar way. 4) Grouped by interface. My choice. This wins for me because a new user arriving at the component can see instantly what interfaces are supported simply by looking at package names. It also means that the top level package is left free for static utilities which often get lost otherwise. I have no problem with the list package extending the collection package. o.a.c.primitives.collection o.a.c.primitives.collection.adaptor (or adaptor.collection?) o.a.c.primitives.collection.decorator (or decorator.collection?) o.a.c.primitives.list o.a.c.primitives.iterator o.a.c.primitives.map o.a.c.primitives.iterator o.a.c.primitives.listiterator o.a.c.primitives.hash o.a.c.primitives.comparator o.a.c.primitives.io Stephen - Original Message - From: Rodney Waldhoff [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Monday, October 13, 2003 6:07 PM Subject: Re: [primitives] Package layout strategy On Mon, 13 Oct 2003, __matthewHawthorne wrote: I believe that there will be a lot of code generation involved, Stephen checked in some Velocity templates a few weeks ago. Rather than generating the 64 pairwise primitive-to-primitive maps, their associated iterfaces, base classes, adapaters, decorators (immutable, sychronized) and variations (ordered/unordered, hash/tree, etc.), why not wait until we have an actual, real-world application that calls for them? So the battle has become: o.a.c.primitives.boolean o.a.c.primitives.byte o.a.c.primitives.short o.a.c.primitives.int o.a.c.primitives.long o.a.c.primitives.float o.a.c.primitives.double vs. o.a.c.primitives.collection o.a.c.primitives.list o.a.c.primitives.iterator o.a.c.primitives.map Any other opinions? Yes, leave well enough alone. Again, what problem are we trying to solve? -- - Rod http://radio.weblogs.com/0122027/ - 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] -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] Package layout strategy
-0 to partitioning by collection or type. Neither is going to be a clean partitioning. For a collection counter-example, consider an ordered set/unique list. For a type counter-example, consider a map of chars to ints or ints to booleans, etc. Similarly, this name-spacing doesn't accurately represent the relationships between classes. A class in primitives.list.* is likely to be more closely bound to classes in primitives.collection and primitives.iterator than to many other classes in primitives.list. Also, I'd strongly discourage bundling the adapters into the same package as the primitive collections. The adapter classes, being dependent upon the java.util collections, has a different role, a different set of dependencies, and to my mind quite logically belongs in a different (if nested) namespace. To put it another way, it generally makes a lot of sense to me to have the package hierarchy represent the dependency hierarchy, so that classes in a.b.c depend more upon (or have closer relationship to) classes in a.b than to classes in a.b.d. Similarly, a class in a.b should only extremely rarely depend upon a class in a.b.c. We don't currently have any map-like implementations. Why don't we wait to repackage until we have an actual use case for it? What problem are we trying to solve? Also, in the suggested repackaging, where does the stuff currently in primitives.adapters.io go? On Fri, 10 Oct 2003, Stephen Colebourne wrote: I've been thinking about how the new project should structure its packages. [primitives] will (I hope) be looking at Map implementations in addition to the List ones currently existing. I would like to restructure the packages into an interface based scheme. primitives.collection primitives.list primitives.map primitives.iterator Each package would contain the interface, implementation, wrapper and adaptor. I believe this will give [primitives] the room it needs to grow, and allow users a quick grasp of the features available. (If you want to see what this turns out like see the sandbox primitives) However, this is a change from the current layout of the code held in [collections]. So I propose that - the primitive classes in [collections] are imported directly into [primitives] without changing the package name - we arrange a snapshot build of [primitives] using this package structure - we reorganize the packages into the new layout - we head towards a release How does this sound??? Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] Package layout strategy
On Mon, 13 Oct 2003, __matthewHawthorne wrote: I believe that there will be a lot of code generation involved, Stephen checked in some Velocity templates a few weeks ago. Rather than generating the 64 pairwise primitive-to-primitive maps, their associated iterfaces, base classes, adapaters, decorators (immutable, sychronized) and variations (ordered/unordered, hash/tree, etc.), why not wait until we have an actual, real-world application that calls for them? So the battle has become: o.a.c.primitives.boolean o.a.c.primitives.byte o.a.c.primitives.short o.a.c.primitives.int o.a.c.primitives.long o.a.c.primitives.float o.a.c.primitives.double vs. o.a.c.primitives.collection o.a.c.primitives.list o.a.c.primitives.iterator o.a.c.primitives.map Any other opinions? Yes, leave well enough alone. Again, what problem are we trying to solve? -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New commons proper component - pcollections - REMINDER
Why state The API will mimic as closely as possible the object-based API? This isn't true of the current codebase (consider InputStreamCharIterator or RandomAccess*List for example, neither of which have direct correlation to anything in java.util) and as a design decision, not an scope one, shouldn't be part of proposal. I think we should strike the sentence under rationale reading The API will mimic as closely as possible the object-based API and the phrase under scope reading mimicing the object-based API. Similiarly, we should probably add something like and related types to the scope definition, since things Iterator and other helper types (or for that matter, Map), aren't strictly Collections. On Wed, 8 Oct 2003, Stephen Colebourne wrote: Reminder!! This vote for a new commons proper component is still open and awaiting responses. There are 2 +1s and 2 +0s at present so more votes are needed :-) Stephen PROPOSAL: html head titleProposal for PCollections Package/title /head body bgcolor=white div align=center h1Proposal for emPCollections/em Package/h1 /div h3(0) Rationale/h3 p The Java Collection Framework defines a well-known and widely used API for collections. This framework is object-based, but the Java language also contains primitive types. The framework requires each primitive to be wrapped in an object, such as Integer, before they can be used in collections. This has a memory and performance overhead. /p p The pcollections component will provide an API for collections based on primitives The API will mimic as closely as possible the object-based API. Wrappers and adaptors will be provided for integration with the object-based API. /p h3(1) Scope of the Package/h3 p The package will create and maintain a set of collections for primitive types, mimicing the object-based API, distributed under the ASF license. /p h3(1.5) Interaction With Other Packages/h3 p emPCollections/em relies only on standard JDK 1.2 (or later) APIs for production deployment. It utilizes the commons-collections test framework and the JUnit unit testing framework for developing and executing unit tests, but this is of interest only to developers of the component. /p p No external configuration files are utilized. /p h3(2) Initial Source of the Package/h3 p The initial codebase is taken from commons-collections, where it was unreleased. /p pThe proposed package name for the new component is codeorg.apache.commons.pcollections/code./p h3(3) Required Jakarta-Commons Resources/h3 ul liCVS Repository - New directory codepcollections/code in the codejakarta-commons/code CVS repository./li liMailing List - Discussions will take place on the general em[EMAIL PROTECTED]/em mailing list. To help list subscribers identify messages of interest, it is suggested that the message subject of messages about this component be prefixed with [pcollections]./li liBugzilla - New component PCollections under the Commons product category, with appropriate version identifiers as needed./li liJyve FAQ - New category commons-pcollections (when available). /ul h3(4) Initial Committers/h3 ul liRodney Waldhoff/li liStephen Colebourne/li /ul /body /html - Original Message - From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 1:06 AM Subject: [VOTE] New commons proper component - pcollections The [collections] component has been housing unreleased, but stable primitive collections code for some time. These are collections that store primitive arrays behind the scenes instead of objects. (Note that JDK1.5 does NOT address the need for these classes). Following discussion within the [collections] component on the best release strategy, we would like to create a new commons-PROPER component to house the code. The aim is to give this useful code room to grow without impacting the widely used main [collections] (object-based) component. It is important to emphasise that this is not new code - it is stable and ready for release. Thus commons-proper, rather than the sandbox, is the appropriate place for the new component. The proposal is attached for the new component 'pcollections'. (No one likes this name, but we haven't found a better one). Please vote as to whether you support this new commons-PROPER component. [ ] +1 Yes, lets create [pcollections] [ ] +0 [ ] -0 [ ] -1 No, I oppose this because Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To
Re: [pcollections] Proposal amendment
+1 one to the amended proposal. On Thu, 9 Oct 2003, Stephen Colebourne wrote: (0) Rationale The Java Collection Framework defines a well-known and widely used API for collections. This framework is object-based, but the Java language also contains primitive types. The framework requires each primitive to be wrapped in an object, such as Integer, before they can be used in collections. This has a memory and performance overhead. The pcollections component will provide an API for collections based on primitives. Wrappers and adaptors will be provided for integration with the object-based API. (1) Scope of the Package The package will create and maintain a set of collections for primitive types and related types, distributed under the ASF license. --- There are now enough votes to create this component. Stephen - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 09, 2003 1:11 PM Subject: Re: [VOTE] New commons proper component - pcollections - REMINDER I'm happy to make changes along these lines. You are right about Iterator and RandomAccess classes. Stephen from:Rodney Waldhoff [EMAIL PROTECTED] Why state The API will mimic as closely as possible the object-based API? This isn't true of the current codebase (consider InputStreamCharIterator or RandomAccess*List for example, neither of which have direct correlation to anything in java.util) and as a design decision, not an scope one, shouldn't be part of proposal. I think we should strike the sentence under rationale reading The API will mimic as closely as possible the object-based API and the phrase under scope reading mimicing the object-based API. Similiarly, we should probably add something like and related types to the scope definition, since things Iterator and other helper types (or for that matter, Map), aren't strictly Collections. On Wed, 8 Oct 2003, Stephen Colebourne wrote: Reminder!! This vote for a new commons proper component is still open and awaiting responses. There are 2 1s and 2 0s at present so more votes are needed :-) Stephen PROPOSAL: html head titleProposal for PCollections Package/title /head body bgcolor=white div align=center h1Proposal for emPCollections/em Package/h1 /div h3(0) Rationale/h3 p The Java Collection Framework defines a well-known and widely used API for collections. This framework is object-based, but the Java language also contains primitive types. The framework requires each primitive to be wrapped in an object, such as Integer, before they can be used in collections. This has a memory and performance overhead. /p p The pcollections component will provide an API for collections based on primitives The API will mimic as closely as possible the object-based API. Wrappers and adaptors will be provided for integration with the object-based API. /p h3(1) Scope of the Package/h3 p The package will create and maintain a set of collections for primitive types, mimicing the object-based API, distributed under the ASF license. /p h3(1.5) Interaction With Other Packages/h3 p emPCollections/em relies only on standard JDK 1.2 (or later) APIs for production deployment. It utilizes the commons-collections test framework and the JUnit unit testing framework for developing and executing unit tests, but this is of interest only to developers of the component. /p p No external configuration files are utilized. /p h3(2) Initial Source of the Package/h3 p The initial codebase is taken from commons-collections, where it was unreleased. /p pThe proposed package name for the new component is codeorg.apache.commons.pcollections/code./p h3(3) Required Jakarta-Commons Resources/h3 ul liCVS Repository - New directory codepcollections/code in the codejakarta-commons/code CVS repository./li liMailing List - Discussions will take place on the general em[EMAIL PROTECTED]/em mailing list. To help list subscribers identify messages of interest, it is suggested that the message subject of messages about this component be prefixed with [pcollections]./li liBugzilla - New component PCollections under the Commons product category, with appropriate version identifiers as needed./li liJyve FAQ - New category commons-pcollections (when available). /ul h3(4) Initial Committers/h3 ul liRodney Waldhoff/li liStephen Colebourne/li /ul /body /html - Original Message - From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta Commons Developers List
Re: [pcollections] Name change?
+1 to the name primitives over pcollections On Thu, 9 Oct 2003, Stephen Colebourne wrote: Should we name it [pcollections]? Or is [primitives] better? (The sandbox primitives is then a sandbox for the proper component for experimentation). I had forgotten about the special io input stream stuff, which might lead to the name [primitives]. I don't think that this affects the vote, but it does affect the CVS creation! Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] TestMap is sweet
On Fri, 3 Oct 2003, Henri Yandell wrote: I half think this should form part of some kind of JUnit-Collections-compliancy jar or application. Coincidentally, Stephen has been preparing a distro of the commons-collections test framework so we can split *.collection.primitives off into its own component. - Rod http://radio.weblogs.com/0122027/ Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Re: Working commons-collections nightly no longer available
On Tue, 30 Sep 2003, Craig R. McClanahan wrote: The nightly build process for Commons packages (for Collections, the output goes to http://cvs.apache.org/builds/jakarta-commons/nightly/commons-collections/) runs on my home server, and simply runs an ant dist on each package, tars/zips up the output in the dist directory and the source, and publishes them. You will note that recent nightly builds (such as last night's -- 20030930) do indeed contain both JARs. My mistake. I had assumed based upon the changes to build.xml and from Tim's report that only commons-collections.jar was available in the nightly distro. Tim, you'll want to grab both JARs from the nightlies for now. The nightly build process for Commons packages does not, and never has, automated the publishing of the individual JAR files anywhere. In particular, publishing anything to ibiblio is something that someone else would need to be doing. Yes, of course. I don't think anyone expected otherwise. Thanks Craig. Craig McClanahan - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] jar file names
On Tue, 30 Sep 2003, Stephen Colebourne wrote: My aim with this change was to keep the name commons-collections for the object only jar. Unfortunately it was late and I read the ant file as only producing two jars, one object and one primitive. Also, I had thought that was what was agreed (ie. no combined jar file). To be clear this time, my choice for jars is for: - commons-collections.jar - object only as it always has been - commons-collections-primitves.jar - an optional additional jar of primitives No combination jar, as that leads to classpath/version issues. Commons-collections.jar hasn't always been object only, indeed, up until three days ago it contained the primitive collections, as it has since they were first committed nearly 18 months ago. I'm not strongly opposed to commons-collections.jar excluding the primitive collections, as long as some all-inclusive JAR is available. I'm not sure why you're trying to prohibit that. A number of projects (e.g., log4j) and components (e.g., commons-logging) distribute overlapping JARs without signficant problems. I'll suggest these classpath/version issues are a hyptothetical problem. I don't imagaine anyone is going to be profoundly confused as to whether or not commons-collections-all.jar contains all of commons-collections. But as we saw yesterday, not providing a complete JAR has caused actual classpath and versioning issues. Of course, my view remains that primitives are a specialised extension to collections, not part of the main code. As you know, I don't believe that they should be directly managed with [collections]. For example, I was going to invite you to write the release notes for primitvies, as you are the only coder in those packages. You need to understand that I am far from comfortable with managing/releasing these classes in this way. Despite being release manager, I sometimes feel like -1ing my own release. Don't do anything you're not comfortable with, but frankly I'm beginning to resent repeated attempts to ghettoize this code base. The primitive collections have just as many committers, and quite likely more users, as other collections sub-packages (notably collections.observed.*). They are designed around real-world user experience. They have 100% test coverage. They have been stable for nearly 9 months. Just because you personally aren't interested in using this code (or more accurately, just because you're interested in exploring alternative implementations of this code) doesn't justify ostracizing it from the rest of the package. You're trying to make the primitive collections a second-class citizen here. As before, if you want to make primitive collections a first class citizen in another commons proper component, then propose that, but it will require some extra work to extract the shared bits from the commons-collections code base. Stephen - Rod PS: Now maven and ant generate different commons-collections.jar files, by the way. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.3 vs. 1.4 jdk [was Re: [ANN][DBCP][Pool] First Release Candidates available for the 1.1 releases of Commons DBCP Pool]
If I remember correctly, previously we've been releasing the 1.4 compiled JARs (and that's what the nightly builds are as well). This seems to work just fine under 1.3 (even 1.2) in pratice, the only caveat being you should avoid using the JDK 1.4 only methods from JDK 1.3 (otherwise you'll get a NoSuchMethodError or something like that when the DBCP-delegates try to access methods of the underlying driver that don't actually exist. - Rod http://radio.weblogs.com/0122027/ On Wed, 1 Oct 2003, Henri Yandell wrote: Compile two jars? In [dbutils] I need to learn how to do conditional compilation as it absolutely has to have two jars due to extension of ResultSet, but it's not such a need in dbcp. Still, maybe the answer is the obvious one. Hen On 30 Sep 2003, John McNally wrote: Code compiled with a 1.3 jdk is not compatible with java 1.4 jdbc api. I did not check, but assume any jars for release will be compiled with a 1.4 jdk? I think the hope is that a jar compiled with 1.4 will be usable in a 1.3 environment, so that we only distribute one. I'm not sure if that compatibility has been verified. I'm not sure but maybe I have used a 1.3 compiled dbcp in a 1.4 jvm, though that does not seem like it would work. Basically, I'm saying I don't know the answer, but have we verified the best jdk for compatibility? john mcnally On Tue, 2003-09-30 at 13:08, Dirk Verbeeck wrote: Release Candidates can be downloaded here: http://cvs.apache.org/~dirkv/builds/ Preview of the updated websites here: http://cvs.apache.org/~dirkv/dbcp/ http://cvs.apache.org/~dirkv/pool/ The release schedule forsees a 2 week review period. http://cvs.apache.org/viewcvs/jakarta-commons/pool/RELEASE_PLAN_1_1.txt?rev=1.2content-type=text/vnd.viewcvs-markup * Preparation Period:28 September 2003 - 30 September 2003 * Review Period: 1 October 2003 - 15 October 2003 * Implementation Period: 16 October 2003 - 19 October 2003 * Release Pool 1.1: 20 October 2003 Please report any issue to the commons-dev mailing list as soon as possible. Positive reports are also very welcome :-) (specify tested database, OS, JVM, hardware, container/framework) Cheers Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] include/import
This might be a better post for the user list, but if you post a sample of your scripts it might be easier to tell what's going on. I've had good luck with this structure: file: parent.jelly: j:jelly xmlns:j=jelly:core j:include uri=child.jelly/ /j:jelly file: child.jelly: j:jelly xmlns:j=jelly:core xmlns:log=jelly:log log:debug name=mylogHello World!/log:debug /j:jelly but that's with a slightly old version of jelly. I suspect this should still work. The semantics of include vs. import aren't quite the same as the XSLT notions. As far as I can tell both include and import are more functionally equivalent to the jsp:include/ tag--they'll invoke a different, stand-alone script. - Rod http://radio.weblogs.com/0122027/ On Tue, 30 Sep 2003, Tony Pelton wrote: hi, new to jelly. i am trying to do some very simplistic stuff with Jelly. i got a basic script working, doing a define for a little bean and calling the script from some simple java code that creates a context and runs the script. worked great. i then wanted to see how i could execute a jelly script from within a script. i assume that include or import is the way to do this ? so i tried it by creating a _very_ simple wrapper script for the first script i wrote that works great. when i execute the wrapper script, i get NoClassDefFound errors complaining about classes for some of the taglibs that jelly supports ... such as JMS for instance. i am not referencing JMS tags in any way. i don't have this problem when i execute the script standalone. i don't understand. Tony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[collections] Re: Working commons-collections nightly no longer available
Tim Anderson wrote: From: Tim Anderson [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Working commons-collections nightly no longer available Date: Tue, 30 Sep 2003 19:30:44 +1000 Hi, I'm trying to get M2 running, but it looks like there is no longer a nightly build of commons-collections available which contains the primitive collections. The relevant classes appear to have been moved into jakarta-commons-sandbox/primitives. Not exactly. The jakarta-commons sub-project has elected to split commons-collections into at least two JARs--one containing the object-based collections and one containing the primitive collections. Initially there were three JARs: commons-collections.jar, containing everything, and commons-collections-objects.jar and commons-collections-primitives.jar, containing the object based and primitive based collections, respectively. Recently the nightly builds have been changed so that commons-collections.jar contains only the object based classes, so that -primitives is the only JAR that contains the primitive collections. Unfortunately, the nightly builds were not updated to actually publish the -primitives JAR anywhere, making a pre-built binary version is unavailable. Personally, I strongly prefer having a single JAR containing org.apache.commons.collections.** available, but whether this is named commons-collections.jar, commons-collections-all.jar, or anything else reasonable isn't a signficant issue for me. The sandbox primitives package is an alternative implementation of primitive collections and possibly more, but is not currently a replacement for org.apache.commons.collections.primitives.*. The 3.0 release of collections will contain the current primitive classes. There is a SNAPSHOT version on ibiblio.org, but was built in April. Would it be possible for a datestamped snapshot version of commons-collections containing the necessary classes to be uploaded to ibiblio.org? If the snapshot currently on ibiblio doesn't contain all the requistite classes I'll be happy to lobby the maven folks to upload something that will, but I believe the ibiblio snapshot is sufficient. In the interim, a hand-rolled build of commons-collections (either maven or Ant should be OK) should contain the primitive collections in one JAR or another. If I get some time today, I'll try to make a build available somewhere, but I'm not sure I'll be able to get to it terribly soon. Thanks, Tim - Rod PS: Note I'm cross-posting this to both [EMAIL PROTECTED] and [EMAIL PROTECTED], as I think the commons-dev team should be aware of this issue. _ High-speed Internet access as low as $29.95/month (depending on the local service providers in your area). Click here. https://broadband.msn.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[collections] deprecate CursorableLinkedList?
If there are no complaints, I'd like to deprecate CursorableLinkedList for the 3.0 collections release, to be removed in the 4.0 release. CursorableLinkedList provides a List implementation that supports a type of Iterator (called a Cursor) that isn't bothered by concurrent modifications--you can safely add or remove items before or after the current location of the cursor and the cursor will simply see the current status of the list when it gets there. While this functionality works fine, it's too complicated by half, and there are bugs in other areas of the interface (well, the only bug I'm aware of is that it isn't really Serializable, despite what the interface claims.) I suspect that commons-pool is the only consumer of this class, where it is used to walk through the set of pooled objects while borrowObject or returnObjct calls may asynchronously modify the underlying list. By deprecating (and eventually removing) this class, we could either move CursorableLinkedList over to pool, or (my preference) replace the CursorableLinkedList with a significantly simpler but slightly less predictable approach (like iterating via list.get(counter++%list.size()), but that's a topic for another thread. Contrariwise, if we'd like to keep CursorableLinkedList, we should either fix the Serialization or remove the implements Serializable part of the class declaration. - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] deprecate CursorableLinkedList?
On Thu, 18 Sep 2003 [EMAIL PROTECTED] wrote: If I append something asynchronously to the end of the list while a Cursor is open, will the cursor pick that up? Yes. Or, does a cursor merely take a snap-shot of the underlying list and iterate over whatever is there currently? No. Not a snapshot. If I remember correctly, CursorableLinkedList is a doubly linked list. The cursor maintains a reference to some node in that list. If you muck around with any other node, the Cursor doesn't care, indeed it doesn't really know. The only tricky bit is when you want to remove the node that the cursor is currently sitting on, in which case the cursor slides forward. Just curious. Sure. No problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] deprecate CursorableLinkedList?
Since both Craig and you have expressed an interest in keeping this class around, I'm more than happy to leave it. Let's remove implements Serializable for the 3.0 release, unless someone feels like making it work (probably a missing a transient somewhere). On Thu, 19 Sep 2003, Simon Kitching wrote: On Fri, 2003-09-19 at 05:03, Rodney Waldhoff wrote: If there are no complaints, I'd like to deprecate CursorableLinkedList for the 3.0 collections release, to be removed in the 4.0 release. Bugger. I was just intending to propose using this class from within commons-digester. It would be no big deal I guess to have a private implementation of this functionality (or some subset thereof). Still, it would be nice if the class was available in commons-collections. Cheers, Simon -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Running the tests
I'm think -1 to forcing the user to use **/TestAll.java to select the unit test suite to execute. What's the harm in giving the user a way to execute the full test suite without using Ant/Maven or an IDE to inspect the filesystem for Test classes? On Sat, 13 Sep 2003, Phil Steitz wrote: Currently neither the ant nor maven [collection] builds runs the subpackage tests. Janek Bogucki just submitted a patch (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23155) to change the entry point to the ant test target from TestAll (just the top level) to TestAllPackages. I have locally modified project.xml to include **/TestAll.java. I would like to commit these changes. Any objections? Also, why not dispense with the ant entry point (and TestAllPackages) and just use **/TestAll.java to select tests? What am I missing here? Phil -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives][collections] primitive collections and PROPOSAL
It seems that you are interested in experimenting with a new scope and possibly a new implementation for the collections.primitives stuff. My suggestion then is this: A) Go ahead with a commons-collections release including collections.primtives.* B) Continue experimenting with the new primitives component in the sandbox, perhaps seeding it with a repackaged version of collections.primitives. C) If at some future point we decide that collections.primitives.* is a better fit elsewhere, we deprecate collections.primitives.* in one release, say Collections 4.0 (roughly coincident with a release of the alternative packaging and/or implementation of that functionality), and remove it in a following release, say Collections 5.0. Holding back on stable, release-ready, unit- and field-tested code so that we can play around with alternative implementations or groupings seems unnecessary when there are backward and forward compatible options available. - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[primitives][collections] primitive collections
As you may know, this past weekend was a holiday here in the states. Many folks, myself included, have been off line for the past few days. I'm playing catch-up here, but here are some general comments: * The auto-boxing features of JDK 1.5, and for that matter, the generics support, is only superficially similar to the functionality that the collections.primitives package provides. Using auto-boxing saves you the trouble of typing new Integer(value) or ((Integer)obj).intValue(). It does not change the underlying representation of the value (which in the case of Integer versus int, is twice as large as it would otherwise be). * Even if JDK 1.5 supported the functionality of collections.primitives (which it doesn't), many users and environments don't have the luxury of moving to JDK 1.5. The current collections.primitives package works with JDK 1.1 or later, with or without the java.util collections stuff, which makes it fully usable on any Java platform. * I'm -1 to moving collections.primitives, or more generally, any release ready code, to the sandbox, as this moves it further away from a release rather than closer. * I'm +0 to splitting collections.primitives to a component distinct from commons-collections, although I'll note: a) The two code bases are not truly independent, they share a unit test suite, so if we split the two we'll probably want to extract the shared unit testing framework. b) It is quite likely that we'll eventually want primitive implementations of Bag and other commons-collections-only extensions, which would introduce direct collections/primitive-collections dependencies, at least at the adapter level. This would also imply that collections and primitive-collections packages are likely to change together, since changes to commons-collections extensions would imply changes to the primitive collections. * I'm +0 to having the commons-collections component release multiple JARs, for example, commons-collections.jar (everything minus *.primitives), commons-collections-primitives.jar (*.primitives.*), and commons-collections-all.jar (everything). * I'm unsure about the notion of primitives as opposed to primitive collections. Precisely what non-collection stuff do we believe to be in scope for primitives? - Rod http://radio.weblogs.com/0122027/ (Actually, when I said +0 above, I'd actually volunteer to help with either of those options, I just don't have strong preference for either of those over leaving the code right where it is.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives][collections] primitive collections and PROPOSAL
On Wed, 3 Sep 2003, Stephen Colebourne wrote: sc From: Rodney Waldhoff [EMAIL PROTECTED] rw * I'm -1 to moving collections.primitives, or more generally, rw any release ready code, to the sandbox, as this moves it rw further away from a release rather than closer. sc I'm balancing this worry with the desire to not release something new sc that is in the wrong place. The basic issue is that primitive sc collections are quite disconnected (ie. totally) from the rest of sc the package. This argues sc for a separate project, as you have done in the sc past over parts of lang (which has happened). What I have argued in the past, and I'll argue now, is that cohesive components are constructed out of classes that are (a) interdependent, (b) commonly used together, and/or (c) commonly change together. Adapters and test suites aside, currently collections.* and collections.primitives.* fail the first test but pass the second two. Of course, many of the collections.* classes have this profile, for just one example, LRUMap and ArrayIterator. rw a) The two code bases are not truly independent, they share rw a unit test suite, so if we split the two we'll probably want rw to extract the shared unit testing framework. sc I would see this as a compile-time dependency on [collections]. Except that the unit testing framework isn't currently distributed in any form. This is a compile-time (or test-time) dependency on code that's currently internal to the commons-collections code base. rw b) It is quite likely that we'll eventually want primitive rw implementations of Bag and other commons-collections-only rw extensions, which would introduce direct rw collections/primitive-collections dependencies, at rw least at the adapter level. This would also imply that rw collections and primitive-collections packages are likely to change rw together, since changes to commons-collections extensions would rw imply changes to the primitive collections. sc Primitive collections may depend on the Bag interface, but sc probably little else. From a quick glance, Bag, BoundedCollection, Buffer, MultiMap, OrderedMap, OrderedSet, PriorityQueue, ResetableIterator, ResetableListIterator and SortedBag all seem like interfaces that we'd quite likely want to support within the primitive collections sooner or later. Many interfaces that aren't commonly implemented via decorators would likely fall into this category as well. Any change to the object based implementations will likely necessitate a change in the primitive implementations and/or their adapters. sc This could be solved by adding a [collections] dependency, or by sc simply including the Bag interface in the primitive-collections jar. sc (I know that sounds scary, but an isolated interface, thus sc non-changing, should be fine in two jars) This is indeed one approach, but what problem are we trying to solve? rw * I'm +0 to having the commons-collections component release rw multiple JARs, for example, commons-collections.jar (everything rw minus *.primitives), commons-collections-primitives.jar rw (*.primitives.*), and rw commons-collections-all.jar (everything). sc I'm -0.5 to this approach. I think it confuses users Primitive collections are there, object collections are here, what's confusing about that? How's [pcollections] and [collections] less confusing, or for that matter, different? sc and leads to classpath issues with the same class in two jars. Fair enough, so drop commons-collections-all.jar. rw * I'm unsure about the notion of primitives as opposed to rw primitive collections. Precisely what non-collection stuff rw do we believe to be in scope for primitives? sc Well, comparators aren't actually collections. Plus Mutable priimtive sc wrapper classes are also possibilities. Primitive comparators are pretty much defined by the built-in operators (either '-' or ''), and/or by auto-boxing. (And the most common use of comparators is handled by java.util.System methods anyway). Currently object-level comparators are in collections, so I don't think this is making the problem any worse. (Not that there are primitive comparator implementations in the code base currently anyway). Arguably there is overlap with lang, math, collections and functor on this point. sc PROPOSAL: sc We copy the existing [collections] primitive code to a new sc sandbox project [pcollections] unaltered except for the package name. sc (I've already tried this locally and it works). (Thus I volunteer for sc this) sc sc [pcollections] and [primitives] can then cooexist, and Darwin will sc then decide. If you want to push for [pcollections] promotion and sc release, that will be your call. Alternatively you could wait a month sc or so to see how [primitives] turns out :-) Independent of moving the component or jar distributions around, I'm -1 to repackaging code from org.apache.commons.collections.primitives at this time. I've already got a significant
Re: [combo] Commons Core release?
On Fri, 15 Aug 2003, Henri Yandell wrote: On Fri, 15 Aug 2003, Rodney Waldhoff wrote: On Thu, 14 Aug 2003, Henri Yandell wrote: Forcing a user of three api's to grab dependencies for 12 other api's is going to kill combo dead in the water. An observation: a user of 3 APIs doesn't need to grab any external dependencies outside of those three APIs. If you never load or use the dependent classes, you never need to load their dependencies. It's very hard to know though. Not hard at all. Look for NoClassDefFound. I look at the dependency list and it says it needs 5 jars. What dependency list? The compile-time ant and/or maven descriptors? We don't have a formal or even conventional run-time dependency indication AFAIK, although maybe this suggests we need one. We don't publish a 'you need this jar for this, this jar for this' list. Also, who wants to trust that? Actually I believe in several places we do (e.g,. http://jakarta.apache.org/commons/logging/userguide.html, http://jakarta.apache.org/commons/httpclient/sslguide.html). The STATUS files used to hold this information, probably many of them have not been maintained. Only power users will be able to deal with this easily, and they have no need for a combo jar. Automating a build of this gets difficult I believe, plus you'd have to not run certain tests. It feels like a rather manual solution. Both maven and gump seem to automate this rather well. Hen - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [combo] Commons Core release?
On Wed, 13 Aug 2003, Craig R. McClanahan wrote: Trying to define combo as anything other than the latest released version of every Commons package seems like it's guaranteed to cause arguments. The collection you propose below, for example, is totally useless to me and all the projects I work on. But commons-combo as it is currently built would be useful to me, and to you, and to anyone else. I'm with Craig on this. +0 to a combo that contains everything in commons (even httpclient) in a single JAR (and we'll cross our fingers that won't introduce any versioning issues.) -1 anything like commons-core that tries to pick and choose which products the user is likely to want. This is impractical at best, and political at worst. = Apache Commons Core v1.0 consists of: Jakarta Commons BeanUtils 1.6.1 Makes the JavaBean specification easier to deal with. Jakarta Commons CLI 1.0 A command line interpreter. Used to handle all the flags passed to your program on the command line. Jakarta Commons Codec 1.1 Common encoders and decoders. Jakarta Commons Collections 2.1 Many more implementations that fit the Collections API. Jakarta Commons Lang 1.0.1 Enhancements to classes found in java.lang. === A url to a build is: http://www.apache.org/~bayard/commons-core/ I'm doing some trickery to turn BeanUtils' commons-logging dependency into a JDK1.4 util.logging dependency. It would be nice to add Pool, HttpClient and maybe Net [with some regexp trickery] and consider that a version 1.0. We can talk about that on a [beanutils] specific thread, but I'd be -1 on doing this to the real BeanUtils code. A very large number of BeanUtils users do not have the luxury to run on a 1.4 JDK. This is probably better suited to another thread, but I'm -1 on making BeanUtils require JDK 1.4. With respect to versioning of something like commons-combo, I'd rather see either: (1) straight incremental version numbers--release 1, release 2, ... , release n--or (2) a straight date based system--17 Aug 2003, 23 Sept 2003, etc. Anything else is going to confuse the suitation more than clarifying it. If you want to know which specific versions of each component are contained, you're gonna have to look at the release notes anyway. - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [combo] Commons Core release?
On Thu, 14 Aug 2003, Henri Yandell wrote: Forcing a user of three api's to grab dependencies for 12 other api's is going to kill combo dead in the water. An observation: a user of 3 APIs doesn't need to grab any external dependencies outside of those three APIs. If you never load or use the dependent classes, you never need to load their dependencies. For example: Commons-Logging: log4j. logkit. avalon-framework. Commons-Logging runs just fine without log4j, logkit, or avalon-framework. Compiling Commons-Logging without these things is a different matter, of course. Similarly: it would not contain HttpClient (?) which I thought might be 1.4 dependent now for SSL and would not include BeanUtils with the current api munging. If you're not using HTTPS support within HttpClient, you don't need to have the SSL libraries (which weren't 1.4 dependent when I last checked) around either. Including a component (such as Latka or Jelly, for example) with dependencies on a large number of external JARs would not require all users of commons-combo to grab those external JARs. (Of course, neither Latka nor Jelly has 1.0 release IIRC, so they probably wouldn't be included anyway.) I'm doing some trickery to turn BeanUtils' commons-logging dependency into a JDK1.4 util.logging dependency. It would be nice to add Pool, HttpClient and maybe Net [with some regexp trickery] and consider that a version 1.0. We can talk about that on a [beanutils] specific thread, but I'd be -1 on doing this to the real BeanUtils code. A very large number of BeanUtils users do not have the luxury to run on a 1.4 JDK. Yeah, I've no desire to apply this to the BeanUtils code itself, and doing said munging concerns me that we might introduce bugs. However, commons-logging is not self-contained and therefore would invalidate commons-beanutils. Creating a comons-beanutils-for-commons-core.jar that's different from commons-beanutils.jar is an extremely bad idea IMO. This creates a much worse problem than the one commons-core/commons-combo is trying to solve. - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DBCP][Pool] Volunteering to fix some issues / apply patches
On Sun, 10 Aug 2003, Noel J. Bergman wrote: Dirk, If you've got patches for the bug fixes, go for it. :-) +1 - Rod http://radio.weblogs.com/0122027/ --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [functor] Iterator and Generator
Maybe that post came out with the wrong emphasis. I'm not trying to say we should prefer external iterators to internal ones, indeed much of the value of commons-functor comes from replacing external iteration with internal iteration. It just seems that if you add a next() method to Generator, then Generator extends Iterator, and that seemed like a reasonable thing to add. Given that the java.util.Collections are external iterator based, they will remain a force to be reckoned with in Java. I'm still trying to wrap my head around bits of the Generator package and how and why it's implemented in certain ways. Let me hold off on any sort of Generator extends Iterator changes for the time being, and work through some other concerns. - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[functor] changes to EachElement
I've just checked in a somewhat significant change to the implementation, but not the functionality, of EachElement. Let me describe it for comment: Previously EachElement was an instantiable class implementing Generator, but all the non-static methods simply delegating to some underlying Generator instance (typically IteratorToGeneratorAdapter). In other words, EachElement was nothing more than a proxy/decorator for some other Generator instance. The other part of EachElement (that is, the static part) provided factory methods for creating EachElement instances, e.g., EachElement.from(someCollection). Since the instantiable EachElement instance didn't seem to be adding any value, I've removed it. Now EachElement is just a container for the static factory methods (the from methods). Also, I made those factory methods handle null values a bit more robustly, so that EachElement.from(null) return null, and added tests for this behavior. What we've lost, relative to the previous revision of EachElement is: 1) the ability to write something like new EachElement(someCollection), instead one must write EachElement.from(someCollection), or if you really like new, then new IteratorToGeneratorAdapater(someCollection.iterator()). 2) the ability to write something like new EachElement(generator), or even EachElement.from(generator). It's not clear to me why that was provided in the first place. new EachElement(generator) simply creates an equivalent Generator, but with an extra level of indirection. If someone is strongly opposed to these changes we can always roll back to the previous revision. - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[functor] Iterator and Generator
As far as I can tell, the role of generator is essentially that of an
Iterator, it provides a mechanism for doing something to each element in a
collection (not necessarily a Collection). The major differences being:
* Generator has a close method (currently stop()). This is used for
things that need to clean up after themselves a little bit, like closing
files or sockets. EachLine was an example of this.
* Generator has convenience methods for internal iteration
(Algorithms.*)
* Generator doesn't have a next() function, currently it only exposes the
internal iteration methods like run(UnaryProcedure)
It seems to me that it is possible to simplify and unify these two
concepts with an implementation like the following:
interface Generator extends Iterator {
/** stops this Generator, freeing any associated resources */
void stop();
// the convenience methods, if desired at this level
Generator apply(UnaryFunction f);
boolean contains(UnaryPredicate p);
Object detect(UnaryPredicate p);
// etc.
}
abstract class BaseGenerator implements Generator {
public abstract Object next();
public void remove() {
throw new UnsupportedOperationException();
}
public boolean hasNext() {
return !(isStopped());
}
public void stop() {
closed = true;
}
// insert implementations of the convenience methods here, e.g.,
public void foreach(UnaryProcedure proc) {
while(hasNext()) {
proc.execute(next());
}
}
/** note this method is protected here */
protected boolean isStopped() {
return closed;
}
protected void finalize() {
if(!isStopped()) { stop(); }
}
private boolean closed = false;
}
Implementations of Generator would then look something like:
/**
* This one is infinite, if you don't call
* stop(), it'll generate for ever.
*/
class RandomIntegers extends BaseGenerator {
public Object next() {
return new Integer(random.nextInt());
}
private Random random = new Random();
}
or,
/**
* This is finite and doesn't really need
* to be manually stopped. It's really no
* better than an Iterator, except it adds
* the convenience methods like:
* Elements.from(myArray).contains(myPredicate);
*/
class Elements extends BaseGenerator {
public Elements(Object[] values) {
this.values = values;
this.next= 0;
}
public boolean hasNext() {
return !isStopped() (next values.length);
}
public Object next() {
return values[next++];
}
public static Elements from(Object[] values) {
return new Elements(values);
}
/** You could override stop() here if you want: */
public void stop() {
values = null;
super.stop();
}
private int next;
private Object[] values;
}
or,
/**
* This one actually needs to be stopped,
* although the finalizer will protect
* you a little bit. (And we call
* stop() internally if you iterate all
* the way to the end of the stream.)
*
* You can treat this as an Iterator
* (i.e., pass it off to a method that
* expects an Iterator), but you'll
* have to follow the close what you open
* strategy and call stop() yourself.
*/
class Lines extends BaseGenerator {
public Lines(BufferedReader in) {
this.in = in;
}
public boolean hasNext() {
return !isStopped() (nextSet || setNext());
}
public Object next() {
if(hasNext()) {
nextSet = false;
return next;
} else {
throw new NoSucheElementException();
}
}
public void stop() {
in.close();
in = null;
next = null;
super.stop();
}
private boolean setNext() {
next = in.readLine();
if(null == next) {
stop();
nextSet = false;
} else {
nextSet = true;
}
return nextSet;
}
private boolean nextSet = false;
private String next = null;
private BufferedReader in;
}
etc.
Is there a disadvantage to doing it this way that I'm missing?
- Rod http://radio.weblogs.com/0122027/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [functor] generators
On Tue, 15 Jul 2003, Jason Horman wrote: I am +1 to your proposal of removing specific generators (EachLine) from functor. I assume you will keep EachElement and NumberRange. Yes, I just want to avoid obscure dependencies for the time being, where I'll define obscure as most things outside of java.lang java.util, or maybe more to the point, anything that requires Exception. There's already a lot of code/classes in functor just supporting the basic functionality. I'd like to try to keep the 1.0 release relatively simple (and therefore avoid any contriversial issues). The reason I included EachLine was really to demonstrate how a Generator can be more powerful than an Iterator. That reason being that the EachLine Generator controls the opening, iteration, and closing of the file such that it is transparent to the functors applied. And a good example it is. Do you plan on keeping CollectionAlgorithms around given that Algorithms duplicates much of its functionality? The two methods that are missing from Algorithms are remove and retain. The reason for this was that the concept of removal is a little funny when the generator is an EachLine file generator. No, that's one of several things I think it would be useful to sort out. I do think it would be useful to have a place for utility Generators. I already have an EachLine, XPath, and database generator that can be quite useful. I'm not sure where to put these for now. Personally I think in the long run something like EachLine belongs in commons-io (or something like it), database generator (EachRow?) belongs in commons-sql (or something like it), etc. Functor is remarkably general purpose. I think we're better off keeping domain-specific functors with other domain-specific code. In the short run we could sit on them, build out a functor-sandbox source tree, move them to another component, or potentially create new sandbox components like commons-functor-io, commons-functor-sql, etc. Not knowing which path is best, I'm inclined to just sit on them for now. No individual functor is particuarly complicated to implement. - Rod http://radio.weblogs.com/0122027/ -jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [functor] generators
I've been digging into the generator stuff Jason submitted a while back a little more closely, and I have a few questions and comments I'd like to drill into, but let me start with an easy one. Currently functor.generators includes a io subpackage, containing EachLine, which is a Generator for each line of some BufferedReader. Since BufferedReader may throw an IOException, this introduces a need for GeneratorException (a RuntimeException wrapping an Exception, in this case, an IOException), which in turn introduces a dependency on JDK 1.4 (for the RuntimeException(Exception) constructor). In the long run, it seems like there may be quite a number of functor subpackage like io (or net, or sql, etc.). These may have a home in functor itself, in extension jars distributed via the functor component (functor-core.jar, functor-io.jar, functor-sql.jar, etc.) or in some other component (in commons or elsewhere) that happens to use or support the functor interfaces (commons-io.jar, for example). In the short run, which may include everything up to a 1.0 release, I wonder if we may be better off not including these sorts of extensions in functor itself. These aren't difficult to create outside of functor and not having them will allow us to punt on a host of issues (packaging and exception handling to name just two) in the interim. In particular, this would mean dropping EachLine (and hence GeneratorException) from current HEAD, which would remove a few types, a package, and as restore support of JDK 1.2 and 1.3 (as well as 1.1 with the java.util collections). Complaints? - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math][functor] More Design Concerns
On Tue, 1 Jul 2003, Mark R. Diggory wrote: Part of this issue is technical the other political, [...] [Functor] isn't going to be available as a maven/build dependency until it graduates. For the record, whether appropriate or not, other commons-sandbox components are available via maven, although functor currently isn't. The technical side of this could be fixed real quick. - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Martin Poeschl as commons committer
+1, which makes at least 3 by my count. Welcome Martin. - Rod http://radio.weblogs.com/0122027/ On Sat, 28 Jun 2003, David Graham wrote: Martin is currently a committer on Turbine, Torque, and OJB and has expressed an interest in maintaining the commons-dbcp project (which is in need of new developers). I suggest we add him as a commons committer. Here's my +1. David __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP status?
The code was buggy and added complexity both in and out of the AbandonedConnectionPool. Some would argue that recovering from programmer error is not an appropriate role for a component like DBCP, and for what it's worth, I think I'm probably one of those. That said, I think changing dbcp/pool to be more compositional and less extend-to-customize-oriented would be a good move all around, and should make it possible to add abandoned object recovery (or abandoned object logging, or a host of other things) as a decorator--which should make it orthogonal to the other implementations/concerns. - Rod http://radio.weblogs.com/0122027/ On Sat, 28 Jun 2003, Noel J. Bergman wrote: - Better support/debugging for forcing connections closed after being open for too long This is exactly what got DBCP into trouble in the past. I'm -1 on providing any ability in DBCP to close lost connections. DBCP should provide the ability to *log* when it detects a resource leak but the application is responsible for the health of the pool. I understand your view, but do you believe that there is no possible solution? If it is just an implementation concern, I'd just as soon see what solution someone comes up with. In your opinion, what are/were the problems in handling abandoned connections in DBCP? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Checked vs Runtime exceptions
On Wed, 25 Jun 2003, David Graham wrote: Logging was merely an example (probably a poor one). Agreed. Logging was one of my examples, and it's a bad one for the sake of this discussion. In practice no logging API I'm aware throws Runtime or checked Exceptions, but silently fail as far as the calling code is concerned, and perhaps attempt to report the failure to the user via some other channel. Indeed given that the actual logging typically happens asynchronously, this is pretty much the only possible strategy, on top of being the most desirable one. For the remainder of this discussion can we drop the logging example? There's still three (or two, depending upon how you factor it) concrete examples out there. - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [functor] generators
Patch applied. Sorry for the delay Jason. - Rod http://radio.weblogs.com/0122027/ On Sun, 15 Jun 2003, Jason Horman wrote: I was just wondering if you had a chance to look at the Generator stuff I sent a while ago? http://marc.theaimsgroup.com/?l=jakarta-commons-devm=105159751911611w=2 http://marc.theaimsgroup.com/?l=jakarta-commons-devm=105108654904036w=2 -jason horman [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]
