Re: [math] J2SE 1.5 static import of methods
Al Chou wrote: It'll be nice when the day comes that we can actually use this feature as the default Yeah, really. It's unfortunate that so many vendors and corporations lag behind the latest Java versions. There are so many cool new features in 1.5, and some good new classes also. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Global project.xml and supporting files
Mark R. Diggory wrote: I've found in a couple other projects I've been working that take advantage of Maven and multiproject plugin that having the global project.xml and other supporting files in a subdirectory similar in nature to those of the subprojects is highly beneficial. /jakarta-commons/global-site/project.xml (etc) /jakarta-commons/collections /jakarta-commons/lang /jakarta-commons/math Thoughts and feelings? This really does make alot of sense to me. Sounds good to me. I usually don't like to run Maven or Ant through Eclipse, but if this helps those who do, so be it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Validate patch
Michael Lanzetta wrote: Please let me know if I've submitted the patch inappropriately, or even if there's just a more preferred method - this is my first patch to Jakarta. Submitting patches as enhancements in Bugzilla is usually the preferred way -- that way there's a permanent record of the patch and it can't get lost. Patches posted to the mailing list are often missed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Array concat?
Janek Bogucki wrote: concat is the best choice because join implies the introduction of a delimiter between the two arrays which is not the outcome, while append implies the extension of an existing object somehow and arrays don't get extended. To me, concat does hint at the production of a new object. I disagree that join implies a delimiter. concat is a good name also, but I'm +1 for join. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [release managers] Rsync with Apache's Maven repository
Paul Libbrecht wrote: On 30-Jan-04, at 06:20 Uhr, __matthewHawthorne wrote: Mark R. Diggory wrote: A.) Version Releases /www/www.apache.org/dist/java-repository b.) Daily Builds /www/cvs.apache.org/builds/java-repository c.) Archives /www/archives.apache.org/dist I think I like this idea. The abundance of snapshots has led to a pollution of ibiblio, and a maintenance headache. If someone wants to depend on an Apache snapshot, they can just edit their build.properties or project.properties to point to the daily builds server. Well... no, that means you would depend on daily build for all of Apache projects which definitely not the intent. Is it really a problem to have one project-name-SNAPSHOT.jar ? (and no dated things)? I disagree. If you specified both ibiblio.org/maven and cvs. apache.org/builds/java-repository as your remote repositories in Maven, you could easily depend on a released version or a SNAPSHOT. Maybe I'm misunderstanding you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Whats in a name (or Group-id's anyone?)
I think that all of Jakarta should deploy under groupId jakarta.apache.org. It would eliminate about 1/4 of the directories on ibiblio right now. That's an exaggeration, but I'm sure you get my point. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [release managers] Rsync with Apache's Maven repository
Mark R. Diggory wrote: rsync is now active between apache and www.ibiblio.org/maven every 4 hours. minotaur.apache.org:/www/www.apache.org/dist/java-repository contents are now rsynced directly to www.ibibilio/maven. by ibibilio. This means anything you place into java-repository will be available through maven within 4 hours. First off, this is great. Thanks Mark, Jason for getting this going. Secondly, does ibiblio do anything to handle cleaning old snapshots? I don't think that Maven can do this. Would it make sense for the rsync to delete things from ibiblio that aren't in the Apache repo? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Configuration] Throws ConfigurationException?
Eric Pugh wrote: Or, if we aren't really sure what the Exception handling of the 1.0 version should be, then skip it (since what we have is good enuf), and move to a release of 1.0 so we can really think about what we want. I think just throwing a ConfigurationException on everything that is explicit is going to make the API harder to use and force bigger changes on everybodies code that wants to use it. Just one more thing.. Having said that about ConfigurationException, I was looking at the ConfigurationFactory and the getConfiguration() method throws an Exception. It really should throw a ConfigurationException that extends NestableException, and then maybe we have ConfigurationException extends NestableException and ConfigurationRuntimeException extends estableRuntimeException? I'm not involved in [configuration], but from what I've read, data can be loaded from a number of sources: database, XML, properties files. RuntimeExceptions are typically used to indicate programmer error. There are plenty of exceptions that can occur under the hood that can naturally occur: SQLException, IOException, SAXException. I don't believe that wrapping these in a RuntimeException would be the best idea. One possible solution would be to create a ConfigurationRuntimeException and another class, FailFastConfiguration (or something similar) that wraps a configuration instance and wraps all checked exceptions as runtime ones. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] [PROPOSAL] IO Operations
You've got some interesting ideas there. However, I still believe that the majority of use-cases will involve quick calls to the static methods in XxxUtils classes, so it makes sense for that to remain the default implementation style. The ability to use specialized execution types, cancellation, and status reporting appears useful, especially for large IO operations -- for example, an IDE would possibly want to use some of these features when copying a large file tree. So, I'll give others a chance to chime in, but overall I think your ideas are good ones. Not as a replacement to the current static-based API, but as additions. Alban Peignier wrote: Hi, For a long time, I wondered how to improve the support of the long operations provided by the Utils classes (file copies, listing, deletion, ). The IO Operations are a proposal to the Commons IO project to provide a API to support long IO operations with several features (progress and status monitoring, canceling, error handling, etc ...). I began a draft implementation. The API Javadoc and sources are available. For more details, see this WikiPage http://wiki.tryphon.org/JavaWiki/IOOperation. I hope some people will find something useful in this design ;o) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jxpath vs. Jaxen?
I'm frequently finding myself needing a Bean query language, and then I remembered that Jxpath can do this easily. But I've done a little reading about Jaxen and wondering if I should give this library it's day in court also. I'm continuing the investigation, but I'm interested in what others have to say. Anyone have feelings favoring one or the other? Apache vs. Codehaus -- who will triumph? It's a true battle of the titans. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] First pass at generating distributions
Mark R. Diggory wrote: 2.) working with infrustructure on a bigger issue (establishing a standard maven repository in www/www.apache.org/dist. for mirroring. Let me know if you need help with this. Once the directory is created, it may be as simple as checking out the entire jakarta-commons and running: maven multiproject:deploy-snapshot Although, if I was on the same machine as the repository, I guess install:snapshot would be better. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons] archives assistance [Configuration]
I have a need to search the archives pretty often, but I don't seem to have the trouble that you have. True, the word configuration is probably very common, but usually a lot of messages that my searches return belong to the same thread, and it's not too hard to sift through and find what I need. Even if hundreds of messages are returned, it usually only takes a few minutes to find what I need. Maybe I'm just lucky ... Either way, what you're suggesting would be a good idea. Maybe try at the archives at: http://nagoya.apache.org/eyebrowse/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] maven site
Stephen Colebourne wrote: I haven't deployed it. My understanding is that we should deploy by committing to CVS under jakarta-commons/docs and then cvs update on the main server. Is this correct? Do we need extra karma to do this? Actually, I just ssh-ed to apache.org, checked out [lang], and did: maven site:generate site:fsdeploy You could probably just do: maven site:deploy but I usually deploy sites on the apache machine to avoid the network traffic. There were talks a few months ago about checking in sites -- but as far as I can see all of the commons project sites are not checked in. I didn't really like the idea anyway, and I'm not sure what the story is anymore. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] More thoughts on CharSets and Encoders (references: R E: [codec] Streamable Codec Framework)
Gary Gregory wrote: (2) What could be done, and please forgive my lack of intimacy with these APIs, is to create [codec] APIs that are forward compatible to any extent possible. What I mean by this if NIO has a class Foo with methods a() and b(Foo) is to create an equivalent [codec] class Bar with methods a() and b(Bar), which would allow one to do search and replace in the future. This is quite a stretch I know, but guess what, we've done this at work in the logging domain (we have our own logging which we want to eventually move to 1.4 or log4j). An alternative to the search-and-replace could be to create an interface which defines the requirements of the functionality that you need. You could then provide a default implementation of the interface, use the Factory pattern to obtain instances, and then in the future, plug in an implementation which delegates to the corresponding 1.4 class once it becomes available in jakarta-land. This could make things transparent to the outside. I've been able to pull this off a few times when I was in the 1.3 to 1.4 transition (I had my own logger too), and I've also been able to plug trash my home-grown solutions in favor of swift libraries such as [dbcp] and [betwixt]. Maybe this is what you were saying and I misunderstood you. Either way, it's painful to not be able to use 1.4, especially with 1.5's new tricks on the horizon. ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] maven site
After numerous times of going to http://jakarta.apache.org/commons/lang and being disappointed at the lack of a site, I finally took some initiative and deployed the site for [lang] today. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] maven site
Tim O'Brien wrote: Tried to upgrade L+F to be consistent with: http://jakarta.apache.org/commons/beanutils/ http://jakarta.apache.org/commons/betwixt/ http://jakarta.apache.org/commons/cli/ http://jakarta.apache.org/commons/codec/ etc... But, you failed to ensure that everything was group writeable on Minotaur. As a general rule, everything under /www/jakarta.apache.org/commons should be chmod g+w. If anyone is going to publish a site, especially for the first time, keep this in mind. The directories are created by the individual performing the publish and they are not group writable. Sorry, I didn't think of that -- it's fixed now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] RC1 Maven site for review
Tim O'Brien wrote: How does the group feel about axing StatCVS reports from Jakarta Commons entirely. They are a rendering nightmare (takes too long), and they encourage metric gather that is not entirely helpful. Does it really matter that psteitz is a 7% committer, and that scole... is a 40% committer. Are we racing? The StatCVS report for commons-collections takes an ungodly amount of time to run. I always comment it out in my local copy when I make any updates. I'd be +1 to getting rid of it for this reason. I do, however, like the information that it presents. I don't think we're racing -- but it is informative to see the amount of contribution from different committers. We're already getting rid of @author tags -- so it's becoming harder to distinguish one project committer from another. This may go against the Apache philosophy, but I do *not* think that all committers on a project are equal. I think that those who do more of the work should have more weight -- and that's usually the way it works out anyway. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] JIRA
Gary Gregory wrote: [...] I say $X and no there is no OS alternatives, there use to be, but they died a long time again 'cuz some companies got really clever and offered their stuff for free to OS projects. [...] Good point. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Maven Distribution's
I started a similar discussion a few weeks ago, which I tried to start again today. The subject was: [maven] developer repository which I just sent to [EMAIL PROTECTED], due to Tim's suggestion. Craig R. McClanahan wrote: Quoting Mark R. Diggory [EMAIL PROTECTED]: 1.) Is there anyone in particular that is in charge or who has ssh access to deploy maven distributions of nightly builds to ibiblio from the jakarta commons area? I create and upload the nightly builds that are at: http://cvs.apache.org/builds/jakarta-commons/nightly/ but don't have a clue who manages updates of the ibiblio repository, since it's not an Apache thing. 2.) I'd like to start getting at least a weekly or monthly build (bin,src,jar) updated to ibiblio via whatever automated process is in place (if any yet). Note that there is a new project in the Apache Incubator focused on building a repository for all of Apache. http://incubator.apache.org/projects/ruper.html I suggest that interested parties who want to see this happen sign up for the mailing list ([EMAIL PROTECTED]) and help make it so. thanks, -Mark Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] RC1 Maven site for review
Maybe that's the style in Maven's CVS HEAD? It looks like maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Time for 3.0 RC1?
Stephen Colebourne wrote: I reckon its time, as everything now seems quiet. Stephen +1, go for it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feeler question for new commons project
Berin Loritsch wrote: I would like to see about getting the Avalon Event package migrated to commons, which really has little to do with Avalon itself. In contrast to the current Jakarat Commons Event package, the Avalon Event package is developed with the Staged Event Driven Architecture (SEDA) style programming in mind. Sounds interesting. Stephen created an [events] package in the jakarta-commons sandbox a little while ago, but I think that was a more low level library built around the concept of observable collections. Can you provide a link (viewcvs or a Maven site) to the code so that people can take a look? From what you've said, I think it sound like a good fit. Anyone else have an opinion? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging][PATCH] project.xml
You may want to enter these patches as enhancements in Bugzilla to make sure that they don't get lost. commons-logging seems to be pretty stable and hasn't had a release in a while. Dennis Lundberg wrote: Hi When I tried to build commons-logging (pulled from CVS) I needed to find the right version of the avalon-framework. The project.xml file says to use version 4.0. When I ran the unit-tests they wanted the class org.apache.avalon.framework.logger.ConsoleLogger, and that is not included in 4.0. After some digging in the CVS I found the class in question in version 4.1.3. The attached patch fixes the project.xml file. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [betwixt] Status of Betwixt
robert burrell donkin wrote: if there's interest from other committers i could think about tidying the refactored stuff up and putting it into a branch so that we can talk about the design. I think this may be the best idea. Or, you could create an experimental/refactoring directory in CVS and put the code in there. I've had no time to work on Jakarta stuff lately, but I use Betwixt and am interested in helping to get a release going. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [uid] Uuid
Gary Gregory wrote: I prefer treating acronyms as words (Uuid), which avoids IMO silly and *unreadable* names like FTPUNIXXMLThing in favor or FtpUnixXmlThing. Gary I agree. Once you have a class with more than 1 acronym in the name, things get out of hand. I feel that this is a nice consistent approach to producing readable names. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] FilenameUtils needs work
I agree that it seems like a lot of work. I work primarily on Unix and can definitely lend a hand, but you may be correct about skipping it for the 1st release. Jeremias Maerki wrote: As announced I'd like to outline how I currently see FilenameUtils. Current problems are: - Some test cases are disable because they fail. - The test cases are incomplete. Some work only on Unix because they use slashes and the Windows path separator is a backslash. Another example: removeExtension looks for the last occurence of a dot which doesn't work as soon as you forget to remove the path before the filename first. - Some methods (like normalize) only work on Unix. They use hardcoded slashes. - Some methods are duplicates and still have to be removed. I've started to work on that last week but have stopped as I realized that we may need to discuss the approach first. FilenameUtils will be expected to be written once and run everywhere. :-) So it has to work on Unix and Windows (at least). Sun with their java.io.File framework have special implementations of the not quite public java.io.FileSystem class that seems to handle some of the platform dependencies. Other things are handled within java.io.File where backslashes get converted to slashes internally. I think we should do that, too. But as in java.io.File there are a few nasty things to consider (like UNC and drive-relative paths). I wonder if we can handle all that properly without too much effort. I doubt so. Another question is what to do with Windows-style filenames on Unix and vice-versa. What should happen when a UNC path is processed on Unix? How to write the test cases? A separate set for Windows and Unix? Should FilenameUtil methods return Windows-style paths on a Unix machine if a Windows-style path is used as input? If a mix is found (a mix of slashes and backslashes) shall FilenameUtils return the platform-specific style? As I stated before I'm not really a fan of working with String filenames so I actually have a rather small motivation to work on this after I found out about all the difficulties. I realize I'd rather skip FilenameUtils for the initial release. If someone working on Unix is really willing to help me (I'm working on Windows) work on FilenameUtils then I'm in. But I'm sure it'll take some time until everything is stable. If we target a release real soon now, I think we have to skip FilenameUtils. In this area we've had a related thread before (for those who want to read that up): http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=380749 That thread and the ideas there make this even more complicated. But we don't have to do everything now I guess. Thoughts? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] SystemUtils.JAVA_IO_TMPDIR
Gary Gregory wrote: Note that the current implementation already does some of this catch and set to null business WRT SecurityExpections. Ah, I didn't realize this. Perhaps it isn't a big deal then -- although I think that providing the constants in this way, although convenient, circumvents some exception mechanisms which provide more explicit error messages. My point is, if something goes wrong, you'll get a NullPointerException and have to look at System.err to see what happened. I don't prefer this, but perhaps others do. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [betwixt] Status of Betwixt
Martin van den Bemt wrote: Hi Tim, Robert is probably busy (or on a holiday?) and James has moved on to On Tue, 2003-12-23 at 19:55, Tim O'Brien wrote: Betwixt is a very useful component, and a number of people would like to start using it in production systems. Could someone give a quick update as to why Betwixt is still at a 1.0 alpha? and, also provide a timeline for a 1.0 release. I use betwixt in production, and would be willing to help push for a release. It would be nice if Robert or Martin could create a roadmap of sorts which could identify all of the works in progress and other things necessary for a betwixt 1.0 release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] SystemUtils.JAVA_IO_TMPDIR
Gary Gregory wrote: Hello, When I use SystemUtils.JAVA_IO_TMPDIR, I really need File file = new File(SystemUtils.JAVA_IO_TMPDIR) Any thoughts/allergic reactions to providing a SystemUtils.JAVA_IO_TMPDIR_FILE? Gary Would proving a static File instance create any strangeness with regard to system resources? I'm not sure. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] SystemUtils.JAVA_IO_TMPDIR
Stephen Colebourne wrote: It would definitely need to be protected in construction to avoid exceptions and set the value to null if it fails. I think that static methods may be a cleaner approach, instead of a static block which much catch IOExceptions when constructing the static File objects. This would elminate the convenience of having static fields, but the possibility of receiving NullPointerExceptions instead of IOExceptions after an error doesn't seem favorable to me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] docs and refactorings
Jeremias Maerki wrote: Packages o.a.c.io.input and o.a.c.io.output I'd like to merge these into one package which contains all InputStreams, OutputStreams, Readers and Writers. Currently, we have 1 Writer, 0 Readers, and the rest are streams. I just think it makes more sense to have these classes side by side. For example -- ProxyInputStream and ProxyOutputStream, DemuxInputStream and DemuxOutputStream. These classes will most like be used together, and change together, so lets put them together. Here are some ideas for a name: o.a.c.io.streams - good, but there may be readers, writers also I like this most. I don't think there is a problem if we put Readers and Writers in there. OK, then perhaps io.streams is the best place. However, I believe that Henri preferred leaving the classes split between io.input and io.output. Henri, can you chime in and give us the reason for your opinion on this again? class o.a.c.io.HexDump This class only has one method, dump(byte[], long, OutputStream, int). I would like to move this method to IOUtils as dumpHex, then deprecate and remove the original class. -0. I'm thinking about visibility. I don't like filling up IOUtils with too much. People need to find out quickly what capabilities IO has. For HexDump (a class I haven't looked at, yet) I can imagine several layout modes. The code for that may inflate IOUtils too much for my taste. I didn't quite understand HexDump. If you feel that it has room to grow and would clutter IOUtils, then let's leave it. Also, what are the opinions on renaming IOUtils to IoUtils? I think there's a guideline in Elements of Java Style that suggests capitalizing acronyms in this way. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] docs and refactorings
Stephen Colebourne wrote: OK, then perhaps io.streams is the best place. However, I believe that Henri preferred leaving the classes split between io.input and io.output. Henri, can you chime in and give us the reason for your opinion on this again? I also support input and output (as is), as they just seem like an obvious classification. Is there any real need for them to be together? [collections] has suffered by putting things in one place when they should have been split. There are 3 examples in the current [io] codebase: Counting [InputStream, OutputStream] Demux [InputStream, OutputStream] Proxy [InputStream, OutputStream] I think that these classes belong in the same package. With regard to streams and readers/writers, I disagree that input and output is an obvious classification. There are many situations, although we only have three in [io] where the concept (or type of stream) is the controlling factor. These classes make use of the same concept, and therefore may make use of similar code and tests. Take a look at java.io: Buffered [InputStream, OutputStream, Reader, Writer] ByteArray [InputStream, OutputStream] CharArray [Reader, Writer] Data [InputStream, OutputStream] File [InputStream, OutputStream] Filter [InputStream, OutputStream, Reader, Writer] LineNumber [InputStream, Reader] Object [InputStream, OutputStream] Piped [InputStream, OutputStream, Reader, Writer] Pushback [InputStream, Reader] Should these classes all be separated by input and output? I don't think so. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
subversion {was Re: [codec] [proposal] Moving To Apache Commons}
Henri Yandell wrote: #1. Commons Codec will be hosted on Subversion -1 I've not been able to install the server on Linux, or the client-ssl on a Mac with ease. Partly this is my own damn stupidity I suspect, but I'm competent on both platforms and would expect it to work pretty easily. I do want to do this, but with the trickle of time I've thrown at it, it's not been easy. I'm with Gary in having asked just why Subversion can't work with a CVS client, are there CVS features that it is unable to support, or that it supports in some non compatible way? I was recently forced to switch to Subversion at work. I haven't yet tried to install a server, but the client and client-ssl were pretty simple -- I just installed the necessary rpms. I'm not sure how easy it is in a non-rpm environment though. As I understand it, the primary reason that Subversion can't work with CVS clients is that they don't speak the same language. Subversion advertises itself as being able to transmit data in a much more efficient way. They take a differing philosophy on how to manage file differences and a lot of other things. The interface to the Subversion client is the piece that is very similar to CVS, not necessarily the guts underneath. So far, so good -- I like Subversion, but I'm not quite ready to switch over yet. I'll probably do it during my next Linux upgrade, which will hopefully be soon ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven] developer repository?
I'm using Maven, but I frequently run into situations where a version of a jar I need isn't on ibiblio. For example, yesterday at work I needed the postgres 7.4 jdbc driver, and also the new xdoclet 1.2, neither of which are there yet. For just a single developer, it's as easy as copying the jar to my local repository. However, in a multi-developer, multi-site situation, it becomes a bit harder. I don't want to have to manually provide these jars to my fellow developers. For these newer jars, I'm thinking of checking them into our version control system and using Maven's jar override feature until they are uploaded onto ibiblio. Now, I've already filed requests for these files in the maven-upload category in Jira as the Maven guys have suggested. However, this process seems to take some time. My idea is to create a developer repository somewhere on an apache/jakarta machine, that any committer can write to. You could put a jar there, specify this url as a secondary repository, and be able to work until the jar gets put on ibiblio. It's just a quick idea that I thought of, that may make things easier. If I need a newer version of [betwixt] or [sql] or some other unreleased component, I can build it myself and put it in this developer repository. I'm already doing something like this in my public_html directory, but I thought that maybe some other developers would like to do the same thing. Think about it: after a commons component is released, how long does it take to get up on ibiblio? In my opinion, it should be available in a remote repository, somewhere, as soon as it is released. For example, [primitives] and [dbutils] still aren't there, and were released over a month ago. What do you think? Is this a good idea or would it just create more headaches? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [maven] developer repository?
As Noel pointed out, there's a repo project starting up elsewhere. In the meantime, though, please be *very* careful about what you make available in your public_html directory. Specifically, you need to ensure that the licenses for all of those components permit redistribution, since that is effectively what you are doing. Will do. I'm not using anything for which there isn't already an older version on ibiblio -- so I think I'm ok. But I'll be sure to double check. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[io] docs and refactorings
I made some updates to [io]'s documentation today. I copied some of the package description for the main package and put it on the main index of the site. I think it's useful to have a nice overview of the projects with links to Javadoc on the front page. Since Maven is so good at generating docs, I'm starting to favor useful xdocs over long package descriptions. It just seems easier to navigate. Now onto the code: I have some ideas that I'd like to mention. Packages o.a.c.io.input and o.a.c.io.output I'd like to merge these into one package which contains all InputStreams, OutputStreams, Readers and Writers. Currently, we have 1 Writer, 0 Readers, and the rest are streams. I just think it makes more sense to have these classes side by side. For example -- ProxyInputStream and ProxyOutputStream, DemuxInputStream and DemuxOutputStream. These classes will most like be used together, and change together, so lets put them together. Here are some ideas for a name: o.a.c.io.throughput - kind of vague o.a.c.io.streams - good, but there may be readers, writers also o.a.c.io - what about putting them in the root package similar to java.io class o.a.c.io.HexDump This class only has one method, dump(byte[], long, OutputStream, int). I would like to move this method to IOUtils as dumpHex, then deprecate and remove the original class. Please chime in with any comments or suggestions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [maven] developer repository?
Jason van Zyl wrote: If some wants to make a maven-like directory within the standard distribution location on ASF hardware right now they can. That could be a first, very practical step the repo project could make. Then let projects put their artifacts in there as they wish. This is what I was suggesting. I figured that others had the same problem that I did, and would be willing to create a space together to hold newer versions than what is currently on ibiblio. Maybe a dirctory in /www/maven.apache.org/repo or something like that. The [EMAIL PROTECTED] project looks great, and I would imagine that this is what Maven will be using in the future (right?). However, I'm looking for a solution which will work with Maven right now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Eric Pugh - new committer
+1 Stephen Colebourne wrote: Well extended rights committer, as he is already well known from the sandbox and elsewhere :-) This vote formalises his rights in commons proper. [ ] +1, let him commit in Jakarta Commons Proper [ ] 0 [ ] -1, perhaps not, because - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] new StringBuffer +
ASHWIN Suresh wrote: How about StringBufferPlus ?? It's not an abbreviation, fits into Stephen's scheme of alphabetical order, doesnt introduce any new terminology/concept, and gives us a new convention (-Plus suffix) to denote our enhancement classes. +1, I like this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[validator] general validation mechanism?
I have a simple validation mechanism that I often use for unit testing, and I'm curious to see if it can be fit into [validator] somehow. I defined a Validator interface, which contains methods which can return a boolean or throw an exception. Usually in my tests I prefer fail-fast behavior, so I use the latter two. Validator boolean isValid(Object) boolean areAllValid(Collection) void validate(Object) throws ValidationException void validateAll(Collection) throws ValidationException I then created a BeanValidator class which accepts a String array in its constructor which contains field names. It expects the object in question to be a bean, and throws an error if any of the field names have null values. I use [beanutils] to do this. The current behavior only validates if the value exists or not, but I would imagine more specific constraints such as number ranges, regexs, etc. may be necessary in the future. I've taken a look at [validator] a few times, but I've never been able to get a firm understanding of how to use it. My needs are not HTML or form based at all. Questions: 1) Is there a way to do what I'm doing with the current code in [validator]? 2) If not, is there any interest in creating a more general validation system, which can be used in non-form based environments? I think that a simple validation framework for beans and simple objects would be great and very useful. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons - TLP
I'm fairly new to the Apache scene, but I think I like the idea. I think that Jakarta Commons is buried down deeper than it should be. Some of the projects such as [digester] and [jxpath] are so gosh darn useful that they deserve to be in a more visible space. However, I'm not sure that I understand your suggestion about Jakarta Commons becoming top level, and then being joined by Apache Commons. I think it should be the other way around -- Jakarta Commons projects should become Apache Commons projects. But in a sense, it can all seem redundant. If Apache Commons then has projects for all languages, there would need to be at least a small separation of projects by language, if only for web site listing, or coding standards, etc. So, there would be a Java branch of Apache Commons -- which is kind of what Jakarta was in the first place, Apache's Java project, right? So, my point is, I agree that Jakarta Commons might benefit in being higher up. I'm surprised that Struts isn't a top level project already, but if it were to be, then that would be another top level project that depends on JC -- which doesn't quite fit with the charter. Although, as I just mentioned, the language issues still confuse me. Henri Yandell wrote: [partially fantasy land/future ideas] The Jakarta Commons charter basically views Commons as a supplier of Jakarta projects, and not Apache projects in general. With many of the Jakarta sub-projects moving to TLP status [ie) ant.apache.org etc], this is increasingly untrue. Jelly's main customer is Maven for example, quite a few XxxxUtils classes in Commons came from Ant, and a lot of code came from a partial merger with Avalon's Excalibur. There are two easy solutions [to think of]. The first is to change the charter to match reality, ie) any ASF TLP is considered a client of Jakarta Commons. The other is for Jakarta Commons to become a TLP. I'd like to speak for the latter suggestion, I'd also then like to suggest a more radical [flame-likely], though obvious next step. Pluses I see for becoming a TLP: * Currently we're viewed as a bit of an odd project in that we're an umbrella project child of an umbrella project. Removing one of these layers will improve the view that we have strong awareness of what's going on and we would report directly to the board. * It helps get us into the ASF community. We're a bit hidden away from new TLP Java projects, such as the currently incubating Directory project, and a TLP placement would lead to more involvement and a larger community spread as new Java projects arrive there. * There's community interest in a TLP Commons, and as a community we have a large amount of knowledge we can bring to the table. The last point suggests an obvious next step, which is some kind of merging with the Apache Commons project. I would like to suggest that the way we do this is that, J-C goes to TLP, with all its current rules and community, A-C projects join J-C [currently just Serf, though a *libtool project that's something to do with compiling C is likely to join A-C too], J-C removes its Java-centric view and allows any language to join. The things I believe we should push for is that our current J-C group should not try to de-java ourselves, but that we allow the A/J-C community to choose its own delineations over time and not try and set them up to begin with. Our mail lists would stay the same and they would join, and over time we would decide, much like httpclient in the past, whether we need new mail lists. The PMC for such a thing would be based on all active committers, so no real change than the current way in which the J-C bazaar is handled. I think the ASF infrastructure group are going to want ASF projects to be using subversion rather than cvs at some point in the future, and the current A-C community has good subversion understanding with which to help us if that should come to pass. There are also obvious ties when similar domain products, serf/httpclient, are able to communicate more openly and easily. --- Does anyone have any negatives/positives of such a thing? Does it make any sense for the future? Does it harm/help J-C? Or am I just suggesting evil thoughts? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] UUID Generator - was RE: UUID Generator?
I've taken a look at some of the uid code that is currently in [lang]. Are we all convinced that these types of classes are definitely a good fit for the project? I think that they're a bit out of scope. However, the obvious problem is -- where else in commons to put them? Phil Steitz wrote: Tim Reilly wrote: Phil, Tim, et al, I just added the thread lifecycle handling to the *draft* UuidClock.java I'd started For the timestamp of a version 1 uuid. I'll share it here. I realize it needs more work. I haven't tested it yet, but I wanted to get some feedback before I do more. I'm not a committer on anything... would it be better to open a bugzilla enhancement and add files like this that way? Yes, it would be best to attach files to a Bugzilla ticket. I will have a look this evening. Is this meant to be used with the axis impl? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] JUnit version, broken tests
Instead of removing it, is it possible to modify the test to expect the failure? I'm not familiar with the test or class that you're speaking of, but sometimes it's nice to keep tests like this around. Maybe catch an expected RuntimeException, or change an assertTrue to an assertFalse, etc.? Phil Steitz wrote: Stephen Colebourne wrote: +1, enough time has now passed for JUnit3.8 to be OK Stephen Done. The enum test remains broken, however under JDK 1.4.2. The test that is failing was added to demonstrate the problem referenced in PR 23374. Since it fails (actually just fails to demonstrate broken behavior) under 1.4.2, I would like to remove it. Any objections to this? Phil - Original Message - From: Phil Steitz [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Saturday, December 13, 2003 8:45 PM Subject: [lang] JUnit version, broken tests Some tests (/builder/ShortPrefixToStringStyleTest, ArrayUtils.Test) have been been added/modified to require Junit 3.8. I have no problem with this; but we need to modify the dependency in project.xml for the maven build to work in this case. Any objections to this change? I am seeing the following failure in the builder tests: Testcase: testNestedBroken took 0.006 sec FAILED expected:0 but was:3 junit.framework.AssertionFailedError: expected:0 but was:3 at org.apache.commons.lang.enum.EnumTest.testNestedBroken(EnumTest.java:432) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) I am using Sun Linux JDK 1.4.2 Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] JUnit version, broken tests
Phil Steitz wrote: __matthewHawthorne wrote: Instead of removing it, is it possible to modify the test to expect the failure? I'm not familiar with the test or class that you're speaking of, but sometimes it's nice to keep tests like this around. Maybe catch an expected RuntimeException, or change an assertTrue to an assertFalse, etc.? The problem is that the test case testNestedBroken in o.a.c.l.enum.EnumTest is expecting broken behavior which does not occur under (Sun Linux) jdk 1.4.2. There is not much else in the test case. That's why I suggested removing it. Phil Ah, now I understand. Since it's such a specific test, you're probably right, it makes sense to remove it. Either that, or perhaps you could use SystemUtils to only run the test if it's on the expected version and platform. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Functor] Unit tests fail in Gump
I think this can be accomplished by adding resources to the build/unitTest element. 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: [lang] new StringBuffer
I don't like the name StringBuf. I just don't see it as descriptive enough.
MutableString is ok. I like CharGroup also.
If it's meant to be an improved replacement for StringBuffer, I always
prefer names like StringBuffer2 or StringBufferX. I guess they can be
considered a bit ugly -- but at least they're generally understandable.
Stephen Colebourne wrote:
I remembered my favorite name - StringBuf. Its always nice if the class
appears in Eclipse next to the one its replacing :-)
Stephen
- Original Message -
From: Ash .. [EMAIL PROTECTED]
Sounds good, I will then work on a StringBuffer replacement, and then
later on get on to providing it with an XUtils.
That way, we will also be able to optimize the subsequent
StringBufferUtils
implementation using package-private access.
I have always been a little disappointed with the facilities
java.lang.StringBuffer
offered, and now I have a chance to do something abt it :)
And now for the name game: I propose MutableString.
Other possible name suggestions, some quite fancy, would be:
Strand, CharStrand
Token,
Bead, CharBead,
CharGroup, CharBunch,
CharLot, StringLot
I find Strand especially useful because that lets us talk about a mutable
string in a conceptually distinct manner. Of course, its replacive role is
not immediate obvious by the name, and some might suggest that it is
better
that the new name reflects its surrogate nature wrt StringBuffer. However,
a
new coin may be useful in the long term. Just my 2 cents.
Ash
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 09, 2003 22:15
To: Jakarta Commons Developers List
Subject: Re: [lang] StringBufferUtils replacement for StringUtils --
Ah, I see what you mean. And no that wasn't what I meant :-)
There is the potential for a StringBufferUtils, with similar methods to
StringUtils, but where the first passed in parameter is a StringBuffer.
However, what I was thinking of (see the todo list in status.html) is a
new
instantiable class
public AStringBuffer() {
private char[] buffer = new char[32];
private int size = 0;
public AStringBuffer() {
}
public void append(Object obj) {
// copy to end of buffer
}
}
ie. a direct StringBuffer replacement.
Both are good candidates for [lang].
Stephen
- Original Message -
From: ASHWIN Suresh [EMAIL PROTECTED]
With the one difference that the methods here don't return aything,
but
instead modify the StringBuffer
passed in, directly.
I will start work on it tonight.
Ash
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 09, 2003 20:07
To: Jakarta Commons Developers List
Subject: Re: [lang] String Utils replacement for StringUtils -- was
([lang] StringUtils.split() functionality wrt separator repeats)
The string buffer class needs to begin by having all the same
methods as
StringBuffer, and they should do exactly the same. Then,
methods to handle
null would be added:
appendSilentNull()
At that point, we could evaluate it and see what else should be
added.
Stephen
- Original Message -
From: ASHWIN Suresh [EMAIL PROTECTED]
Incidentally (or perhaps it was to come), I was about to
send out another
email
proposing a StringUtils-like class that handles
StringBuffer instead.
I would be interested in writing it, but I need to evaluate
how much time
I
can afford
to it (will let u know).
In the meanwhile, assuming I can go ahead, you can list out
right away
what
differences
you see between StringUtils and the StringBuffer
counterpart. I can, for
now, perhaps cover the
simpler methods which are similar to the StringUtils ones.
Regarding tightening admissibility of new methods to a
class because it is
large, I
am of the opinion that for a class of only static methods
such as this
one,
why should there be any hesitation. StringUtils is but a
repository of all
such
features, so as long as we have clear documentation, I see
no reason why
largeness
should lead to limits to having more methods.
Let me know.
Ash
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Monday, December 08, 2003 22:05
To: Jakarta Commons Developers List
Subject: Re: [lang] StringUtils.split() functionality wrt
separator
repeats
With StringUtils, we now face tough decisions. The class is
already very
large, and adding more and more methods is not necessarily
the answer. I am
now applying a fairly high level of justification to new
additions to
StringUtils. ATM more split methods or overloads don't meet
what I'm looking
for.
That said, there are still some misisng methods in
StringUtils, notably
startsWith, endsWith and concat/append. (all null-safe).
In addition, a StringBuffer replacement needs writing, if
you're interested
;-)
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
Re: [events] building
From http://maven.apache.org/reference/project-descriptor.html#dependencies Note: The use of the id element for a dependency is deprecated. Please use groupId and artifactId together instead. Rodney Waldhoff wrote: 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: [collections] LRUMap - which order?
[EMAIL PROTECTED] wrote: Just to confirm, you want map.firstKey() to return the next key to be removed from the map? Stephen Correct, I think this makes the most sense. Anyone else have an opinion? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] binary builds.
You could always ssh into cvs.apache.org, do a CVS checkout, build, and see what happens... Eric Pugh wrote: Okay, I tried the 'ant dist' target on my box, and of course it worked fine. I suspect b/c I am on windows... Looking at the error, I'm guessing that it is some sort of parsing the path that is different between Windows and Linux. Would it be too much of a pain for you to run the maven build and let me know if the path fails there as well? I'm not much of an expert on the differences between windows and linux unfortunantly when it comes to these path resolutions... At least if it fails in Maven and Ant then we know it isn't something funky with how the build.xml file gets generated. Any other configuration developers have ideas? Or have linux and can try it? Eric -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 1:14 AM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: RE: [configuration] binary builds. Quoting Eric Pugh [EMAIL PROTECTED]: Okay, Since the project is primarily built with Maven, the build.xml hadn't been updated in a while. I ran 'maven ant' and the resulting build file works and is now checked in! I just tried it (CVS upate, then ant clean dist), and it doesn't work for me :-(. It still tries to run the tests as part of the dist target, and fails as follows: internal-test: [mkdir] Created dir: /home/craigmcc/Jakarta/jakarta-commons-sandbox/configuration/t arget/test-reports [junit] Running org.apache.commons.configuration.TestBaseConfiguration [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.842 sec [junit] Testsuite: org.apache.commons.configuration.TestBaseConfiguration [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.842 sec [junit] Testcase: testRetrieve took 0.023 sec [junit] Testcase: testInterpolation took 0.076 sec [junit] Testcase: testMultipleInterpolation took 0.002 sec [junit] Testcase: testInterpolationLoop took 0 sec [junit] Testcase: testGetString took 0.001 sec [junit] Running org.apache.commons.configuration.TestClassPropertiesConfiguration [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.87 sec [junit] Testsuite: org.apache.commons.configuration.TestClassPropertiesConfiguration [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.87 sec [junit] Testcase: testClasspathLoading took 0.119 sec [junit] Caused an ERROR [junit] Could not open Resource /org/apache/commons/configuration/test.properties [junit] java.io.FileNotFoundException: Could not open Resource /org/apache/commons/configuration/test.properties [junit] at org.apache.commons.configuration.ClassPropertiesConfiguration. getPropertyStream(ClassPropertiesConfiguration.java:179) [junit] at org.apache.commons.configuration.ClassPropertiesConfiguration. init(ClassPropertiesConfiguration.java:108) [junit] at org.apache.commons.configuration.TestClassPropertiesConfigurat ion.testClasspathLoading(TestClassPropertiesConfiguration.java:93) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess orImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth odAccessorImpl.java:25) [junit] Testcase: testClasspathLoading BUILD FAILED file:/home/craigmcc/Jakarta/jakarta-commons-sandbox/configurat ion/build.xml:94: Test org.apache.commons.configuration.TestClassPropertiesConfigurat ion failed FWIW, I'm running this on Linux (RH 9.0) with Sun JDK 1.4.2. Craig I guess I should follow up with finding out how to get Gump building as well? It seems like most of the jakarta projects seem to use Gump. And with the large number of dependencies that Configuration has, it might be good to include it as well. I ran 'maven gump' and got a resulting gump.xml that looks like what is required? Eric -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Saturday, December 06, 2003 10:56 PM To: Dirk Verbeeck Cc: Jakarta Commons Developers List Subject: Re: [configuration] binary builds. Quoting Dirk Verbeeck [EMAIL PROTECTED]: Craig is the man to talk to for the nightly builds. He runs the builds for jakarta-commons. Yep. The only requirement is that ant clean dist works but you also might want to change the maven generated ant file to a more traditional build.xml file. (take the build file of commons-modeler as example) At least make the junit tests non mandatory. Right now, this problem is blocking my ability to add configuration to the set of nightly builds that I run ... the fact that the unit tests fail (at line 82 of build.xml) blocks the creation of the binary distribution files. -- Dirk Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
Re: [configuration] binary builds.
Ant was in my path by default (/usr/local/bin/ant) Java 1.4 is installed in /usr/local/jdk1.4.2, you'll have to manually set JAVA_HOME to point to this. Eric Pugh wrote: Does Ant and java exist on cvs.apache.org? I'm not too familiar with what resources are available on cvs.apache.org... Could I upload a copy of configuration to my home directory and just run ant from the ssh prompt? Eric -Original Message- From: __matthewHawthorne [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 6:29 PM To: Jakarta Commons Developers List Subject: Re: [configuration] binary builds. You could always ssh into cvs.apache.org, do a CVS checkout, build, and see what happens... Eric Pugh wrote: Okay, I tried the 'ant dist' target on my box, and of course it worked fine. I suspect b/c I am on windows... Looking at the error, I'm guessing that it is some sort of parsing the path that is different between Windows and Linux. Would it be too much of a pain for you to run the maven build and let me know if the path fails there as well? I'm not much of an expert on the differences between windows and linux unfortunantly when it comes to these path resolutions... At least if it fails in Maven and Ant then we know it isn't something funky with how the build.xml file gets generated. Any other configuration developers have ideas? Or have linux and can try it? Eric -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 1:14 AM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: RE: [configuration] binary builds. Quoting Eric Pugh [EMAIL PROTECTED]: Okay, Since the project is primarily built with Maven, the build.xml hadn't been updated in a while. I ran 'maven ant' and the resulting build file works and is now checked in! I just tried it (CVS upate, then ant clean dist), and it doesn't work for me :-(. It still tries to run the tests as part of the dist target, and fails as follows: internal-test: [mkdir] Created dir: /home/craigmcc/Jakarta/jakarta-commons-sandbox/configuration/t arget/test-reports [junit] Running org.apache.commons.configuration.TestBaseConfiguration [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.842 sec [junit] Testsuite: org.apache.commons.configuration.TestBaseConfiguration [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.842 sec [junit] Testcase: testRetrieve took 0.023 sec [junit] Testcase: testInterpolation took 0.076 sec [junit] Testcase: testMultipleInterpolation took 0.002 sec [junit] Testcase: testInterpolationLoop took 0 sec [junit] Testcase: testGetString took 0.001 sec [junit] Running org.apache.commons.configuration.TestClassPropertiesConfiguration [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.87 sec [junit] Testsuite: org.apache.commons.configuration.TestClassPropertiesConfiguration [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.87 sec [junit] Testcase: testClasspathLoading took 0.119 sec [junit] Caused an ERROR [junit] Could not open Resource /org/apache/commons/configuration/test.properties [junit] java.io.FileNotFoundException: Could not open Resource /org/apache/commons/configuration/test.properties [junit] at org.apache.commons.configuration.ClassPropertiesConfiguration. getPropertyStream(ClassPropertiesConfiguration.java:179) [junit] at org.apache.commons.configuration.ClassPropertiesConfiguration. init(ClassPropertiesConfiguration.java:108) [junit] at org.apache.commons.configuration.TestClassPropertiesConfigurat ion.testClasspathLoading(TestClassPropertiesConfiguration.java:93) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess orImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth odAccessorImpl.java:25) [junit] Testcase: testClasspathLoading BUILD FAILED file:/home/craigmcc/Jakarta/jakarta-commons-sandbox/configurat ion/build.xml:94: Test org.apache.commons.configuration.TestClassPropertiesConfigurat ion failed FWIW, I'm running this on Linux (RH 9.0) with Sun JDK 1.4.2. Craig I guess I should follow up with finding out how to get Gump building as well? It seems like most of the jakarta projects seem to use Gump. And with the large number of dependencies that Configuration has, it might be good to include it as well. I ran 'maven gump' and got a resulting gump.xml that looks like what is required? Eric -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Saturday, December 06, 2003 10:56 PM To: Dirk Verbeeck Cc: Jakarta Commons Developers List Subject: Re: [configuration] binary builds. Quoting Dirk Verbeeck [EMAIL PROTECTED]: Craig is the man to talk to for the nightly builds. He runs the builds for jakarta-commons. Yep. The only requirement
Re: [collections] LRUMap - which order?
I think eldest first makes more sense, based on the nature of the class. Stephen Colebourne wrote: The old LRUMap ordered the elements eldest to newest in the iterator. The new LRUMap does the opposite. Should we be sticking to the eldest first ordering? Or is newest first a better more sensible ordering? Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: [collections] Primitive-value maps
I don't think any Map implementations have been created yet. Ash .. wrote: Hi Arun, I had a look at Primitives, but I didnt find anything on primitive-value maps. Am I missing something here? Ashwin -Original Message- From: Arun Thomas [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2003 17:54 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 _ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] pairs package name
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]
Re: [VOTE][RESULT] New committer - Neil O'Toole
It took about 2 weeks for my account to get created. The entire process seems to be a bit disjointed, and I remember there being a proposal for a web application to make it easier for those in power to easily create accounts. They asked for some committers to volunteer. I can't find it in the archives though. Paul Libbrecht wrote: I fear there's very large deadlines somewhere along the the delivery of the CLA and the user-creation. My vote got in about a week before and I still have no news. Paul Stephen Colebourne wrote: Please can you create a new account for Neil. You should have received a committers agreement. Name: Neil O'Toole Email: [EMAIL PROTECTED] Requested User Id: neilotoole Projects: jakarta-commons, jakarta-commons-sandbox Votes from: Stephen Colebourne (scolebourne) Henri Yandell Matthew Hawthorne Arun Thomas Peter Royal John Keyes Thanks in advance Stephen - Original Message - From: Neil O'Toole [EMAIL PROTECTED] CLA has been signed and faxed. Full name: Neil O'Toole Preferred username: neilotoole Email address: [EMAIL PROTECTED] thanks, neil --- Stephen Colebourne [EMAIL PROTECTED] wrote: Neil, could you please review these pages and send in the CLA http://www.apache.org/licenses/#clas http://jakarta.apache.org/site/newbie.html http://www.apache.org/dev/committers.html In addition I need: Full name: Preferred username: Email address: The CLA must be sent/faxed directly to Apache, and must be received before they do anything. Stephen - Original Message - From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Wednesday, November 26, 2003 10:35 PM Subject: [VOTE] New committer - Neil O'Toole I would like to nominate Neil O'Toole as an Apache Jakarta Commons committer. Neil has been a regular contributer to discssions on commons for a long time, and recently made a large contribution in the form of the collections observable package. I feel the time has come for him to be allowed access to commit to the commons CVS and develop this, and other, commons code. Votes close Sunday 30th Nov midnight GMT. Stephen [ ] +1, Yes let him commit [ ] +0 [ ] -0 [ ] -1, No because. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] AMap/IterableMap name
Stephen Colebourne wrote: I can think of various possible names: Map2 - follows Sun naming standards for replacing interfaces MapA - similar idea, but doesn't clash if Sun ever creates Map2 AMap - similar idea but reversed (A is for Apache) IMap - similar idea, but I is for interface IterableMap - the long name If people favour IterableMap, then thats fine. I was looking for something short to indicate that this should be a general replacement to using Map. Maybe IterableMap is clearer though Naming opinions please? I like IterableMap, but I can also see why you wanted a short name. What about XMap or MapX, to indicate a Map extension, like the javax.* packages? Similarly, HashMapX and XHashMap could be used instead of HashedMap. It's kind of a strange situation, but it would be nice to come up with a nice naming standard for classes which can replace their JDK counterparts. Any other suggestions? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] StringUtils.subarray v/s subArray
It seems to depend on whether we see the word array as a proper noun. java.lang.String has both substring and subSequence. There seem to be inconsistencies everywhere. I vote for subArray, since I would define a classname as being a proper noun. Stephen Colebourne wrote: I changed this based on subList() in the collections API. substring() is an alternative precedent, so I am open to opinions. Stephen - Original Message - From: Ash .. [EMAIL PROTECTED] Thanks for integrating the subarray implementation patch. However, I am curious to know why Stephen chose to name the method subArray, in place of subarray. In the English language, the prefix sub in this sense is joined to the word with the resultant word being a single token: subunit, subclass, suburbs, subway... substring, subarray, whereby, as per standard Java conventions, the name ought to be subarray rather than subArray. Even names in Standard API reflect this: substring, etc. thanks, Ashwin _ 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]
Re: [lang] StringUtils.subarray v/s subArray
It seems to depend on whether we see the word array as a proper noun. Could you please elaborate what you meant by that. In my understanding, class names rather represent common nouns, and you can say, specific instances of the class represent proper nouns: Person john = new Person(); Or, am I missing something here? Talking about String.subSequence, if I am right, it was so named because there exists a word called subsequence in English, which has no direct bearing with sub + sequence, thus the emphasis: sub-sequence. Another example would be re-store (= store again.) I was referring to whether we consider the word array to be a common part of language, or a specific concept to programming or something like that. I don't really want to get into a whole grammatical debate because I'm not particularly good at grammar. I see a classname as a proper noun. I think it needs that emphasis because it's a model of something, not the real thing in the real world. Like, in your example, I would refer to the class as *Person* not *person*, to emphasize that I'm talking about the class, not a real flesh-and-blood person. I like subArray because of that emphasis. An example from the numeric side would be: if such a concept as a sub-number existed, which names are preferred: subdouble, sublong, subint OR subDouble, subLong, subInt. I'd choose the latter due to the reasons I've mentioned. I also want to mention that I don't really care that much whether we choose subarray or subArray. What's more important to me is that if we choose a standard with regard to this, that we make our best efforts to stick to it, to avoid the type of ambiguity that Sun has and continues to provide with regard to these types of things. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections][PROPOSAL] Remove Observable subpackage
Is this observable project based on the concept of events? If so, what about something like [events]? Also, there's always [observation]. Stephen Colebourne wrote: Observable is named after the Observer pattern in my eyes. Notifying is OK as a name, and possibly clearer in intent, however I'm not sure that a commons component named [notifying] quite sounds right. [notify] maybe, but then thats not quite right either. Any other naming views? Stephen - Original Message - From: Neil O'Toole [EMAIL PROTECTED] --- Stephen Colebourne [EMAIL PROTECTED] wrote: We've had all positives so far. I'm going to take this as agreed and move the code to a new sandbox project. I reckon [observable] is probably the best name, although I'm open to offers. I don't have strongly held opinions on the naming, but I went through the process of picking a name for a collections observable/notifying/eventsending/callbacking package, and I figured I'd share the thoughts I had on it. Firstly, it certainly should be [observable] rather than [observed], but I'm not going to pretend to remember enough about english grammar to explain why [observable] is better :) I had originally considered this [observable] name when I set about creating my implementation. One of the first things I did (this was circa Sep 2002 I think) was search on the web to see if anybody else had already implemented such a package. The snippet of text that decisively turned me away from the [observable] name was this: Observability. An observable collection is one in which it is possible to view the elements in a collection. @ http://www.haskell.org/ghc/docs/edison/users007.html ... which of course is the crux of the issue. The familiar implementations of the collections API are all observable, in that you can examine the elements of the collection, such as via an iterator. But the [notifying/observable] implementations we've developed *actively* signal information, typically when the collection changes (although that is not necessarily the case - I could envisage an implementation that sends an event when the collection changes *or* every X seconds, or when some other predicate is satisfied). So, rather than denoting passivity, I figured the name needed to indicate the active signaling of state information by the object being observed. A snappier name for this behaviour is notification, so I went with the name [notifyingcollections] over [observablecollections]. You also save a letter in typing ;) Though I don't feel very strongly about it, I still believe that [notifying] is a more indicative name than [observable], and I would suggest we use it. However, I still have a sneaking suspicion that there is a fugitive word out there that better captures the essence of the active signalling of state information by the object being observed, so hats off to anyone who can conjure it up :) neil - 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: [VOTE] New committer - Neil O'Toole
+1 Stephen Colebourne wrote: I would like to nominate Neil O'Toole as an Apache Jakarta Commons committer. Neil has been a regular contributer to discssions on commons for a long time, and recently made a large contribution in the form of the collections observable package. I feel the time has come for him to be allowed access to commit to the commons CVS and develop this, and other, commons code. Votes close Sunday 30th Nov midnight GMT. Stephen [ ] +1, Yes let him commit [ ] +0 [ ] -0 [ ] -1, No because. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Current plan?
I haven't been able to work on [io] for awhile. The last thing I was doing was looking at the Clover report and trying to improve the test coverage. For example. EndianUtils is a class that has 0 tests -- but I didn't have a good enough understanding of it to write any. The tasks page contains the same TODO list as the STATUS.html file. I think these items are all still accurate. FileUtils contains a lot of deprecated methods that need to be removed. The plans were to create a FilenameUtils class that contained a lot of similar methods to FileUtils, but took a String as a parameter instead of a java.io.File. Then there may be implementations behind the scenes for URLs, local or remote files. Henri Yandell wrote: Clover's already on the IO site :) Idiot me. Hen On Sun, 23 Nov 2003, Henri Yandell wrote: Just in case it's of use, I knocked out a clover report for IO. Have recently reinstalled the machine, so the commons licence for clover is not setup. http://www.apache.org/~bayard/io-clover/ Hen On Sun, 23 Nov 2003, Henri Yandell wrote: Jeremias et al, Just wanted to ask what the current plan was for Commons IO. Do you have a todo list anywhere that you're working from? Is there anywhere I can help? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] remove old ant build system
I've had this happen when I had references to ${basedir} in the
project.xml. I think this is supposed to be fixed in maven 1.0-rc1?
Stefan Bodewig wrote:
On Sun, 23 Nov 2003, Henri Yandell [EMAIL PROTECTED] wrote:
I've gone ahead and done this.
One thing that you have to be aware of is that under some - unknown to
me - circumstances maven ant puts strange, absolute (specifc to your
machine) paths into the generated build file.
See http://gump.covalent.net/log/commons-io.html
;-)
Maybe dIon can help you out as he's been able to fix it whenever that
has happened in the past. He may even be able to tell us how to avoid
it, hi dIon 8-)
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[collections] Re: /PROPOSAL 1/ Additions to IteratorUtils
( Remember to prefix subject with [collections] )
In the current CVS HEAD, you can do
IteratorUtils.toArray(Iterator).length
or
IteratorUtils.toList(Iterator).size()
But, your suggestion may be a good addition also.
Also, I think that the method definitions you've provided will all cause
infinite loops -- hasNext() will always return true if you don't call
next(). We'd need to find a way to copy the iterator so we don't modify
it's state when we count the elements.
Anyone else have an opinion?
Lee Crawford wrote:
I'd like to propose the following simple additions to the
o.a.c.c.IteratorUtils
class.
The following is a simple convenience method for counting the number of
elements
in an iteration, something that I find myself recreating somewhat
frequently:
public static
int countElements (final Iterator iter) {
int cnt = 0;
while (iter.hasNext ()) {
cnt ++;
}
return cnt;
}
There isn't an EnumeratorUtils present that might contain an equivalent:
public static
int countElements (final Enumerator enum) {
int cnt = 0;
while (enum.hasNext ()) {
cnt ++;
}
return cnt;
}
Or the slightly less performant:
public static
int countElements (final Enumerator enum) {
return IteratorUtils.countElements (asIterator (enum));
}
Thoughts?
--lee
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections][PROPOSAL] Remove Observable subpackage
I think it's a good idea to remove it. At this point, [collections] is so big that I'm +1 for removing all that we can. I frequently get OutOfMemoryExceptions when doing the maven build due to the size (from the statcvs and linkcheck plugins). Now as to where it should go, I always like the idea of doing it at Apache if possible. Here's an idea: [collections] has already spawned off another subproject in [primitives]. There is the alternative primitive collections (let's call it [primitives2], I forget what the actual name is) that you have at SourceForge, and now the possibility of [observable]. However, all of these projects, in a way, still fall under the domain of [collections]. Perhaps it's time for collections to become a larger project which can contain subprojects. I'm not sure if this is doable in Jakarta Commons, but maybe in top-level Jakarta or the newer Apache Commons? All administrative burdens aside, this makes more sense to me. The current [collections] could become [collections-core], along with the newer [collections-primitives] and [collections-observable]. This would allow proper room to grow for each subproject -- while still keeping related projects together. I realize that this is a semi-radical idea, but maybe it's worth considering? At a minimum, I think it would provide the newer subprojects with more visibility and possible promote a more active community. Stephen Colebourne wrote: I would like to propose that the observable subpackage of [collections] be removed to another location. It remains a relatively self contained part of [collections] following the recent restructuring, and has the potential to grow with other event strategies and integration with GUIs such as Swing. This makes it a relatively poor fit with the rest of [collections]. Either the sandbox, or sourceforge seem appropriate for the code. I know there is demand for the code and a release, but I don't want to let it lie unreleased in [collections] as primitives did for far too long. So, whos in favour of removing it from [collections]? And where to, sandbox (observable), sourceforge (joda-observable), or elsewhere? Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] possible DateUtils method
I believe it's
cvs diff -u
And the most efficient way is to open up an enhancement entry in
Bugzilla and attach the patch there. That way it won't get lost in the mix.
Inger, Matthew wrote:
If i can figure out how to do the patch. is it
diff -n
?
Then do i just post the diff along with the test diff
to the newsgroup?
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 6:12 PM
To: Jakarta Commons Developers List
Subject: Re: [lang] possible DateUtils method
I think this would make a good addition to DateUtils. Would you like to
provide a patch and tests?
Stephen
- Original Message -
From: Inger, Matthew [EMAIL PROTECTED]
public static final long MILLIS_IN_DAY = 1000*60*60*24;
public long getDaysBetween(Calendar c1, Calendar c2)
{
long c1Normalized = c1.getTime().getTime() +
c1.get(Calendar.ZONE_OFFSET) +
c1.get(Calendar.DST_OFFSET);
long c2Normalized = c2.getTime().getTime() +
c2.get(Calendar.ZONE_OFFSET) +
c2.get(Calendar.DST_OFFSET);
long diff = c1Normalized - c2Normalized;
long numDays = diff / MILLIS_IN_DAY;
return numDays;
}
A common mistake most people make is to ignore daylight savings
time when trying to compute the number of days between two Calendar
dates. If you cross the DST boundary when the clock jumps forward,
just subtracting the date objects and dividing will end up giving you
an answer that is off by 1 day. This happens because the clock jumps
ahead, and 00:00 EDT is actually 11:00 EST on the previous day, so the
number of hours is off by 1, and thus the calculation doesn't end up
working
properly. The other thing i'm doing here is to convert to GMT time,
allowing
for the two Calendar objects to have different timezones.
We could have similar methods for getHoursBetween and so forth. Months
would be a bit more complicated of an algorithm.
-
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: [lang][codec] Sanity checking a client project build
You're definitely not nuts, but perhaps a little paranoid ;). From what I've seen, it seems to be a prereq of any released commons component that ALL unit tests must pass. This is one of the reasons that I've never had a doubt about creating a dependency on any project from commons. So, while invoking these tests from your own project does seem safe, it also seems unnecessary. The [lang] developers (which of course includes you) are already ensuring that all of the tests pass and that the code is solid. Now if you're depending on the CVS HEAD, that's a different story. But even in that case, running the tests whenever you do a cvs update seems to be enough. Although, releasing a unit test jar is an interesting idea. Summary: A released version of any project passes all tests. Why create the extra work for yourself? Gary Gregory wrote: Hello, I'll start this topic on [lang] and [codec] only since I am active here. I am considering adding to the unit test suite of /my/ project the unit tests of 3rd party libraries. Why do this? As a simple sanity check. Our project uses [lang], [codec], [pool], [cli], [collections], Xerces, Xalan. I would like the confidence added to /my/ project, that all of these pieces are working as advertised and that no side effects exists. This is why I would like to suggest that [lang] and [codec] deliver their unit tests in jar files instead of plain source. A secondary point I have not thought through is how do you know which tests to invoke. The build.xml file contains a test target which I could invoke from my build file but I like to use the Ant/Junit reporting feature. I do not want to impose this requirement on the build.xml file for a project of course. Any thought? Am I nuts? Paranoid? Thanks, Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang][codec] Sanity checking a client project build
I agree with the idea about testing all Java versions. Testing all platforms is important too. In theory, it seems like we need some type of text matrix, in which we identify all platforms and JREs that the software has been tested on. Something like: 1.21.3 1.4 Solaris x Linux x x x Windows x BSD x x Mac OSX x x Even if we are not able to access every version on every platform, it would be nice to see this information. Users who have access to an untested platform could volunteer to run the tests and submit the results. Is this overkill? Gary Gregory wrote: I agree with all of your responses, I was being a bit paranoid ;-) What about Java versions: 1.2 vs 1.3 vs 1.4? Hopefully a released component has been tested on all. Perhaps this should be part of the release procedure: Make sure the build runs on JDK a, b, and c. I am not sure we have such a guarantee, at least it is not advertised in the release notes or on the web presence for a component: These unit tests pass on JRE a, b, and c-type of statement. Sometimes we catch a 1.4 API call in [lang] and we clean that up, good. But what about 1.3 vs 1.2? Far fetched perhaps but it would be good to know for sure. Thanks for your patience, :-) Gary -Original Message- From: __matthewHawthorne [mailto:[EMAIL PROTECTED] Sent: Friday, November 21, 2003 09:46 To: Jakarta Commons Developers List Subject: Re: [lang][codec] Sanity checking a client project build You're definitely not nuts, but perhaps a little paranoid ;). From what I've seen, it seems to be a prereq of any released commons component that ALL unit tests must pass. This is one of the reasons that I've never had a doubt about creating a dependency on any project from commons. So, while invoking these tests from your own project does seem safe, it also seems unnecessary. The [lang] developers (which of course includes you) are already ensuring that all of the tests pass and that the code is solid. Now if you're depending on the CVS HEAD, that's a different story. But even in that case, running the tests whenever you do a cvs update seems to be enough. Although, releasing a unit test jar is an interesting idea. Summary: A released version of any project passes all tests. Why create the extra work for yourself? Gary Gregory wrote: Hello, I'll start this topic on [lang] and [codec] only since I am active here. I am considering adding to the unit test suite of /my/ project the unit tests of 3rd party libraries. Why do this? As a simple sanity check. Our project uses [lang], [codec], [pool], [cli], [collections], Xerces, Xalan. I would like the confidence added to /my/ project, that all of these pieces are working as advertised and that no side effects exists. This is why I would like to suggest that [lang] and [codec] deliver their unit tests in jar files instead of plain source. A secondary point I have not thought through is how do you know which tests to invoke. The build.xml file contains a test target which I could invoke from my build file but I like to use the Ant/Junit reporting feature. I do not want to impose this requirement on the build.xml file for a project of course. Any thought? Am I nuts? Paranoid? Thanks, Gary - 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: [lang][codec] Sanity checking a client project build
Whoops, I meant test matrix. __matthewHawthorne wrote: I agree with the idea about testing all Java versions. Testing all platforms is important too. In theory, it seems like we need some type of text matrix, in which we identify all platforms and JREs that the software has been tested on. Something like: 1.21.31.4 Solaris x Linux x x x Windows x BSD x x Mac OSX x x Even if we are not able to access every version on every platform, it would be nice to see this information. Users who have access to an untested platform could volunteer to run the tests and submit the results. Is this overkill? Gary Gregory wrote: I agree with all of your responses, I was being a bit paranoid ;-) What about Java versions: 1.2 vs 1.3 vs 1.4? Hopefully a released component has been tested on all. Perhaps this should be part of the release procedure: Make sure the build runs on JDK a, b, and c. I am not sure we have such a guarantee, at least it is not advertised in the release notes or on the web presence for a component: These unit tests pass on JRE a, b, and c-type of statement. Sometimes we catch a 1.4 API call in [lang] and we clean that up, good. But what about 1.3 vs 1.2? Far fetched perhaps but it would be good to know for sure. Thanks for your patience, :-) Gary -Original Message- From: __matthewHawthorne [mailto:[EMAIL PROTECTED] Sent: Friday, November 21, 2003 09:46 To: Jakarta Commons Developers List Subject: Re: [lang][codec] Sanity checking a client project build You're definitely not nuts, but perhaps a little paranoid ;). From what I've seen, it seems to be a prereq of any released commons component that ALL unit tests must pass. This is one of the reasons that I've never had a doubt about creating a dependency on any project from commons. So, while invoking these tests from your own project does seem safe, it also seems unnecessary. The [lang] developers (which of course includes you) are already ensuring that all of the tests pass and that the code is solid. Now if you're depending on the CVS HEAD, that's a different story. But even in that case, running the tests whenever you do a cvs update seems to be enough. Although, releasing a unit test jar is an interesting idea. Summary: A released version of any project passes all tests. Why create the extra work for yourself? Gary Gregory wrote: Hello, I'll start this topic on [lang] and [codec] only since I am active here. I am considering adding to the unit test suite of /my/ project the unit tests of 3rd party libraries. Why do this? As a simple sanity check. Our project uses [lang], [codec], [pool], [cli], [collections], Xerces, Xalan. I would like the confidence added to /my/ project, that all of these pieces are working as advertised and that no side effects exists. This is why I would like to suggest that [lang] and [codec] deliver their unit tests in jar files instead of plain source. A secondary point I have not thought through is how do you know which tests to invoke. The build.xml file contains a test target which I could invoke from my build file but I like to use the Ant/Junit reporting feature. I do not want to impose this requirement on the build.xml file for a project of course. Any thought? Am I nuts? Paranoid? Thanks, Gary - 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: [lang] accessing environment variables
I agree that it could grow to be a PITA. That's why I'm trying to be wary, and limit the functionality that is offered. The majority of Java apps that I've worked on were deployed on Unix machines. In some situations, I was writing a replacement for an existing piece of C or Perl code that relied heavy on environment variables. I don't like env vars in Java apps -- I always try to rely on property files or system properties. But it seems to be a battle that I always lose. That's why I thought it would be nice to add this functionality to [lang]. The problem is the abundance of platforms. Just in looking at the Ant code, they have if/elses for things like Vms and OS2 that I've never used. What a headache. I'm starting to think that maybe this isn't good for [lang] either. If anywhere, maybe it should go into [io] instead. Has anyone else found themselves having to load environment variables in their apps? If not, I'm willing to continue cut and pasting my solution into each of my projects, instead of creating an unnecessary platform issue for [lang]. Phil Steitz wrote: __matthewHawthorne wrote: I posted something a while back about adding a method or class to access environment vars. Henri suggested that I take a look at Ant's solution to this. Ant's env var access is obtained through their execute task. This class has a lot of logic to handle different OS's, and I think that a refactored version may be a worthwhile addition to lang. I had my own small class to do this, but I would image that Ant's version has been more thoroughly tested and bulletproofed. Here's the link to Ant's Execute class. http://cvs.apache.org/viewcvs.cgi/ant/src/main/org/apache/tools/ant/taskdefs/Execute.java?rev=1.70content-type=text/vnd.viewcvs-markup Any thoughts? I think this would be very useful -- just about every project that I've worked on has had to access env vars at some point or another. And providing a nice simple way to execute system commands and grab the output would be cool. While I can definitely see the value for this kind of capability in a build script, I am not sure it belongs in [lang]. I am not violently opposed, just not convinced that it belongs. Could be I am thinking too narrowly in terms of server apps, where I generally try to avoid system calls and environment dependencies like the plague, since these things can lead to brittle solutions and general deployment trauma. Seems like a big PITA to support this kind of thing in a platform-independent (at least from the user's standpoint) way that is safe to use in server applications. Phil - 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: [lang][codec] Sanity checking a client project build
Perhaps we need a simple and generic performance report generator. I've been thinking of how to write a nice junit TestDecorator that would provide performance statistics. It already reports the time of each test, I was thinking of calling System.freeMemory() before and after the test to try and get a grasp on memory load. Then maybe running the tests twice and using the average to be safe. We could output the results to XML and display with a stylesheet, like the junitreport task in Ant. Is this a good idea? Maybe there's something like this already, with a Maven plugin? Phil Steitz wrote: John Keyes wrote: On 21 Nov 2003, at 18:49, __matthewHawthorne wrote: I agree with the idea about testing all Java versions. Testing all platforms is important too. In theory, it seems like we need some type of text matrix, in which we identify all platforms and JREs that the software has been tested on. Something like: 1.21.31.4 Solaris x Linux x x x Windows x BSD x x Mac OSX x x Even if we are not able to access every version on every platform, it would be nice to see this information. Users who have access to an untested platform could volunteer to run the tests and submit the results. Is this overkill? Well I think we should document what we've tested it on. As Jakarta is geared towards server side software this is a great idea. I agree. We actually went through some of this fun in the run up to lang 2.0. I tested using Sun's Linux JDKs 1.2, 1.3 and 1.4 and IIRC, Stephen or Henri ran tests on Windoz. I can't remember exactly which versions and what we had to do to get some of the tests to run under the pre-1.4 JDKs. We probably should document this and include a statement in the release notes. The same comments hold true for performance tests. I have been planning for some time to set up some performance tests for lang, similar to what Craig did for BeanUtils. Any volunteers to help with this? We could gather and publish the test results, along with the platform compatablity tests on the lang web site. I will eventually get to this, but I am a bit time constrained at the moment. Phil -John K - 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]
[lang] accessing environment variables
I posted something a while back about adding a method or class to access environment vars. Henri suggested that I take a look at Ant's solution to this. Ant's env var access is obtained through their execute task. This class has a lot of logic to handle different OS's, and I think that a refactored version may be a worthwhile addition to lang. I had my own small class to do this, but I would image that Ant's version has been more thoroughly tested and bulletproofed. Here's the link to Ant's Execute class. http://cvs.apache.org/viewcvs.cgi/ant/src/main/org/apache/tools/ant/taskdefs/Execute.java?rev=1.70content-type=text/vnd.viewcvs-markup Any thoughts? I think this would be very useful -- just about every project that I've worked on has had to access env vars at some point or another. And providing a nice simple way to execute system commands and grab the output would be cool. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] accessing environment variables
I didn't catch that. I also don't like the idea of batch files in [lang], or any commons component really. I'm sure that we can find a way to factor this out -- I'll keep looking. Stephen Colebourne wrote: A quick glance shows a reference to a batch file needed for Windows95/98. My concern is that this may be a complex thing for [lang], although it probably is useful (I've never needed it) Stephen - Original Message - From: __matthewHawthorne [EMAIL PROTECTED] I posted something a while back about adding a method or class to access environment vars. Henri suggested that I take a look at Ant's solution to this. Ant's env var access is obtained through their execute task. This class has a lot of logic to handle different OS's, and I think that a refactored version may be a worthwhile addition to lang. I had my own small class to do this, but I would image that Ant's version has been more thoroughly tested and bulletproofed. Here's the link to Ant's Execute class. http://cvs.apache.org/viewcvs.cgi/ant/src/main/org/apache/tools/ant/taskdefs /Execute.java?rev=1.70content-type=text/vnd.viewcvs-markup Any thoughts? I think this would be very useful -- just about every project that I've worked on has had to access env vars at some point or another. And providing a nice simple way to execute system commands and grab the output would be cool. - 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: cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections/pairs AbstractTestMapEntry.java
We should start keeping records -- this looks to be the longest commit ever. ;) [EMAIL PROTECTED] wrote: scolebourne2003/11/18 14:37:18 Modified:collections/src/test/org/apache/commons/collections/iterators TestUnmodifiableMapIterator.java AbstractTestListIterator.java AbstractTestMapIterator.java AbstractTestIterator.java collections/src/test/org/apache/commons/collections/list TestSetUniqueList.java TestTransformedList.java TestFixedSizeList.java TestUnmodifiableList.java AbstractTestList.java TestPredicatedList.java collections/src/test/org/apache/commons/collections/bag TestTypedSortedBag.java TestTypedBag.java TestTransformedBag.java AbstractTestBag.java TestPredicatedBag.java TestPredicatedSortedBag.java TestTransformedSortedBag.java collections/src/test/org/apache/commons/collections TestDoubleOrderedMap.java TestLinkedList.java TestSequencedHashMap.java TestLRUMap.java TestCursorableLinkedList.java TestBoundedFifoBuffer.java TestBeanMap.java AbstractTestObject.java TestReferenceMap.java TestUnboundedFifoBuffer.java TestTreeBag.java TestStaticBucketMap.java TestFlat3Map.java TestMultiHashMap.java TestCircularFifoBuffer.java TestBinaryHeap.java TestHashBag.java BulkTest.java collections/src/test/org/apache/commons/collections/buffer TestBlockingBuffer.java collections/src/test/org/apache/commons/collections/bidimap TestDualHashBidiMap.java TestDualTreeBidiMap.java TestTreeBidiMap.java AbstractTestBidiMap.java AbstractTestSortedBidiMap.java collections/src/test/org/apache/commons/collections/observed TestObservableCollection.java TestObservableSet.java TestObservableSortedSet.java TestObservableSortedBag.java TestObservableBuffer.java TestObservableList.java TestObservableBag.java collections/src/test/org/apache/commons/collections/map TestUnmodifiableMap.java TestLazySortedMap.java TestFixedSizeMap.java TestPredicatedMap.java TestFixedSizeSortedMap.java TestListOrderedMap.java TestTransformedMap.java AbstractTestMap.java AbstractTestSortedMap.java TestPredicatedSortedMap.java TestLazyMap.java collections/src/test/org/apache/commons/collections/set TestPredicatedSet.java AbstractTestSet.java TestListOrderedSet.java TestTransformedSet.java TestUnmodifiableSortedSet.java AbstractTestSortedSet.java TestTransformedSortedSet.java collections/src/test/org/apache/commons/collections/comparators TestNullComparator.java TestComparableComparator.java AbstractTestComparator.java TestBooleanComparator.java TestComparatorChain.java TestReverseComparator.java collections/src/test/org/apache/commons/collections/collection TestPredicatedCollection.java TestTransformedCollection.java AbstractTestCollection.java TestCompositeCollection.java collections/src/test/org/apache/commons/collections/pairs AbstractTestMapEntry.java Removed: collections/src/test/org/apache/commons/collections/primitives/adapters TestCollectionDoubleCollection.java TestAll.java TestByteListIteratorListIterator.java TestLongListIteratorListIterator.java TestIteratorLongIterator.java TestDoubleListList.java TestListIteratorFloatListIterator.java TestListDoubleList.java TestListCharList.java TestListIteratorShortListIterator.java TestFloatIteratorIterator.java TestFloatListList.java TestIteratorCharIterator.java TestIntCollectionCollection.java TestCollectionLongCollection.java
Re: [VOTE] Elect Paul Libbrecht as a Jakarta Commons Committer
+1 peter royal wrote: Paul Libbrecht [EMAIL PROTECTED] has been contributing to Jelly in the form of patches and valued support on the user list for over a year now. I think its about time that he be gifted with the ability to take his involvement to the next level. +1 from me. -pete --- Vote: Elect Paul Libbrecht as a Jakarta Commons Committer [ ] +1 Yes let him commit! [ ] +0 [ ] -0 [ ] -1 No way (because of my reason included below...) --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Codec 1.2
+1 Gary Gregory wrote: As previously discussed on commons-dev, we believe Commons Codec 1.2 is ready for release. The source for this release candidate has been tagged as CODEC_1_2_RC1 and is available for download here: http://cvs.apache.org/~ggregory/codec-1.2-rc1/ For more information on Commons Codec, see http://jakarta.apache.org/commons/codec/. 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 Thank you, Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vsf] WAS: [general] Zip file proxy?
I've been in similar situations, where I had a lot of references to File objects, but then started loading resources as URLs from the classpath. Eventually, if you're reading config data you need an InputStream. You may want to consider passing streams or Properties objects around instead of File references -- especially since your config data is read-only. For security purposes, why even allow access to methods like delete() or deleteOnExit()? All the components care about is the content of the File. This obviously doesn't solve your problem... but it may be something to consider. Gary Gregory wrote: You're probably right, I was thinking in a would-it-not-be-nice mode. To be more realistic, I should mention the usage scenario I have in mind: Our server is configured with a config directory which contain a bunch of files and sub-directories. It would be nice if I could read our server's config from a config.zip/tar file instead of a dir. This makes it easier to email configs around. If I can pass a VSF File subclass into our config code, I should not need to fiddle our code, especially since our config is read-only. Gary -Original Message- From: Todd V. Jonker [mailto:[EMAIL PROTECTED] Sent: Friday, November 14, 2003 07:27 To: Jakarta Commons Developers List Subject: RE: [vsf] WAS: [general] Zip file proxy? Hi Gary, Aren't you concerned that your giant-pile-of-code will behave incorrectly due to the fact that a File embedded in a Zip can't implement most of the File API properly? For anything but the most trivial pile I'd be pretty worried about unintended, or even damaging, behavior. On Thu, 13 Nov 2003 17:08:49 -0500, Gary Gregory [EMAIL PROTECTED] said: I agree with the points made /but/, the reason I would like a File subclass is to allow me to get the use a zip file as a directory feature for free, as in, not-change-any-of-my-giant-pile-of-code free. Gary - 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: [collections] Proposal - Subpackages
+1 Stephen Colebourne wrote: I am intending to proceed with this on Sunday all being well, unless I hear objections... Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] Object/JDK integration - was Proposed interface changes
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 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. Quite correct, and such a wrapper would have a large interface to implement. (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. It is asymmetric, but that doesn't bother me especially. (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. True, but it doesn't strike me as a major goal of the library. (J2ME writers would IMO not be using large libraries anyway) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
Re: [VOTE] Elect Simon Kitching As Jakarta Commons Committer
+1 robert burrell donkin wrote: Simon Kitching has been actively contributing to Digester for a long while now. He's actively and knowledgeably answered questions from users for many, many month. Over the last couple of month's he's submitted a substantial quantity of patches both new code and also documentation. He's learnt the value of discussion and knows how to deal (in a very positive fashion) with differences of opinion. here's my +1. - robert -- Vote: Elect Simon Kitching As Jakarta Commons Committer [ ] +1 Yes let him commit! [ ] +0 [ ] -0 [ ] -1 I am against this (please include a reason). -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons Karma for Jean-Francois Arcand
+1 robert burrell donkin wrote: Jean-Francois Arcand ([EMAIL PROTECTED]) is an established jakarta committer with a good knowledge of xml and xml-schema. He's submitted numerous patches over a period of years to help to provide Digester with schema support. He plans to improve and extend the range of support over the next few months. I think that the time has come to allow Jean-Francois to accept responsibility for the product he's helped to create ;) here's my +1. - robert -- Vote: Elect Jean-Francois Arcand As Jakarta Commons Committer [ ] +1 Yes let him commit! [ ] +0 [ ] -0 [ ] -1 I am against this (please include a reason). -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] Digester vs xmlbean vs JAXB
I don't know a great deal about JAXB, but from what I've read, you need a schema to make it work. I've found myself in a few situations where I needed a quick and easily customizable conversion from a bean to XML and back again. After taking a few looks around at different packages, digester and betwixt always seem to be the simplest and fastest option. Samuel Cheung wrote: I have a newbie question. What are the advantages/dis-advantages between Digester vs xmlbean vs JAXB? My understanding is they convert XML file to Java Class. Is that correct? If that is the case, shouldn't one use JAXB over xmlbean and Digester, since JAXB is standard? Thanks for any feedback. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suggestion for new StringUtils.method
Create a bugzilla enhancement entry.
Inger, Matthew wrote:
I've come up with the following class for this.
(I also have a test class which tests a few of the
simple cases). Token parsing is done semi-lazily,
in that when the first token is requested (or the
token count), the whole thing is parsed. And the
reset forgets about the tokens, so you can change
parameters, and re-parse.
public class DelimitedTokenizer
{
public static final char DEFAULT_DELIMITER = ',';
public static final char DEFAULT_QUOTE = '';
public static final String WHITESPACE = \t\n\r;
public DelimitedTokenizer(String input);
public DelimitedTokenizer(String input, char delim);
public DelimitedTokenizer(String input, char delim, char quote);
public char getDelim();
public void setDelim(char delim);
public char getQuote();
public void setQuote(char quote);
// defaults to true
public boolean isIgnoreLeadingWhitespace();
public void setIgnoreLeadingWhitespace(boolean ignoreLeadingWhitespace);
// defaults to true
public boolean isIgnoreTrailingWhitespace();
public void setIgnoreTrailingWhitespace(boolean
ignoreTrailingWhitespace);
// defaults to false
public boolean isTreatEmptyAsNull();
public void setTreatEmptyAsNull(boolean treatEmptyAsNull);
public int countTokens();
public String nextToken();
public void reset();
public String [] getAllTokens();
}
Now the question is how to submit it
-Original Message-
From: J.Pietschmann [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 11, 2003 2:28 PM
To: Jakarta Commons Developers List
Subject: Re: suggestion for new StringUtils.method
Inger, Matthew wrote:
String [] undelimit(String input, char separatorChar, char quoteChar);
It's a tokenizer. It would be handy to have it as an iterator pattern
too (like StringTokenizer).
J.Pietschmann
-
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: [VOTE] Release DbUtils 1.0
+1 Shapira, Yoav wrote: Howdy, +1, looking forward to using it in production ;) Yoav Shapira Millennium ChemInformatics -Original Message- From: Juozas Baliuka [mailto:[EMAIL PROTECTED] Sent: Monday, November 10, 2003 12:40 AM To: Jakarta Commons Developers List Subject: Re: [VOTE] Release DbUtils 1.0 +1 - Original Message - From: David Graham [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, November 09, 2003 10:25 PM Subject: [VOTE] Release DbUtils 1.0 DbUtils is a stable, well tested package suitable for a 1.0 release. The release candidate is available here: http://jakarta.apache.org/~dgraham/dbutils-1.0-rc1/ Here's my +1. David __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - 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] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Separate email list for math development?
+1, and I think [hivemind] could use a separate list also. 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] MapIterator asMapEntry method
+1. I don't really see the point of the asMapEntry() method either. If someone wants the entries, they could just do it the old fashioned way [Map.entrySet().iterator()]. Stephen Colebourne wrote: The MapIterator interface has an asMapEntry() method that gets the current element at the iterator as a Map Entry. The interface desires that the MapEntry returned is connected to the map, such that changes made to setValue affect the map. This can be difficult to implement, and if used would probably mess up the iterator. How useful is the asMapEntry() method? I'm planning to remove it if no one objects :-) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] Maven build oddity
I'll take a guess. In the log message, you can tell that it didn't like your CVSROOT. It looks like you checked out the code using the extssh method in Eclipse? I believe that this is an Eclipse-only connect method, and command line CVS tools don't like it. Perhaps StatCvs doesn't detect this problem very well and bombs via NullPointerException. For a quick fix, you can either check out using the :ext: method and tunnel through ssh, or just comment out the statcvs report in your project.xml when doing local builds. Hope this helps. Gary Gregory wrote: Hello, I've been using Maven to build [codec] locally. All goes well except this one goal: statcvs:generate: [echo] fetching cvs logs... [cvs] cvs log: Unknown method (`extssh') in CVSROOT. [cvs] cvs [log aborted]: Bad CVSROOT: `:extssh:[EMAIL PROTECTED]:/home/cvs'. [mkdir] Created dir: C:\cvs-store\apache.org\jakarta\commons\codec\target\docs\statcvs [mkdir] Created dir: C:\cvs-store\apache.org\jakarta\commons\codec\target\generated-xdocs\statcvs [java] StatCvs-XML - CVS statistics generation [java] [java] java.lang.NullPointerException [java] at net.sf.statcvs.Main.getModuleName(Main.java:193) [java] at net.sf.statcvs.Main.run(Main.java:159) [java] at net.sf.statcvs.Main.main(Main.java:78) [java] null [java] [ERROR] Java Result: 1 Any tips? Thanks, Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] common-math and bloated 3rd party librarie
Here's a thought. One thing we might do to limit the proliferation of jars is to create a jar containing commons-math as all of its dependencies. Maven has an uberjar plugin that might be the ticket to creating such a jar. There ares risk with deploying such a jar as there might be version conflicts if other versions of the dependencies are deployed separately. I'm not a big advocate of this strategy (I've had to many struggles working with products that came bundled with old version of xerces) but it might be to quell some of the dependency backlash. I think this is a great idea. [math] could release both commons-math.jar and commons-math-deps.jar (or something similar). This may be an easy way to get rid of the too many jars situation. It seems that the primary complainers are people who aren't used to dealing with dependencies for other projects. Because of this, I don't think there will be many conflicts with the dependencies included with the main [math] jar. The others, who are accustomed to managing dependencies for the other commons projects that they use, will most likely just grab commons-math.jar and insert it into their environment. For example, if I were to start using [math], I probably would already have all of the dependencies in my environment already. collections, lang, and beanutils always find a way to work themselves into my projects. ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] Object/JDK integration - was Proposed interface changes
This is a tough one. I've gone back and forth a few times, but I think I prefer the sandbox approach. In general, I like the idea of being able to create an ArrayIntList and use it as an IntList, List, or Collection. I find this easier and more efficient that having to create an adapter such as IntCollectionCollection or IntListList. I think that with a good interface - abstract class - implementation heirarchy (which [primitives] already has in a lot of places), this won't complicate the work needed to implement a primitive collection by much. Overall, I think this would make the API easier to use and understand. Stephen Colebourne wrote: As people may or may not be aware, the sandbox contains an implementation of primitive collections that works differently from [primitives]. * [primitives] (commons-proper) - IntCollection is a top-level interface in its own right. A wrapper is needed to integrate with JDK Collection. * primitives-sandbox - IntCollection extends Collection in the JDK. These are two entirely different approaches to the problem space. Here are the reasons why I prefer the sandbox approach: - Integration - an IntCollection IS a JDK Collection, no extra wrappers needed - Number of classes - Because it is a JDK Collection, no wrappers or adaptors are needed - Possible to implement multiple collections in one class, ie. a class could implement both IntCollection and ShortCollection. Main downside: - Methods are named differently from JDK Collection in places because of return type issues * intInterator() * toIntArray() * removeInt() * getInt(index) The benefits of the commons-proper approach appear to be: - Simpler API for IntCollection et al, no confusion with Object world - Methods are named exactly as per the JDK collection (except remove) - Simpler implementation for each class, as it focuses on one task - Theory of relatively low interaction between primitive collections and object ones? Main downside: - Object and JDK integration - keeps Object and primitive worlds separate, which goes against the [primitives] charter in my mind. This thread allows for one final debate as to the best approach for primitives design. We may decide its now too late for commons-proper as it has a release, or we may not. If we decide to stay with the [primitives] commons-proper architecture, I hereby commit to remove the commons-sandbox code from the CVS to non ASF (or rename it if people express a desire to keep it). Finally, this thread started when I proposed a toCollection() method for IntCollection et al, and a toList() method for IntList. If we keep the commons-proper design we should examine these methods as to whether they are not the bare minimum for Object/JDK integration. Stephen From: Rodney Waldhoff [EMAIL PROTECTED] 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?) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] Object/JDK integration - was Proposed interface changes
Comments inline... Rodney Waldhoff wrote: (1) The proposal roughly doubles the number of methods per interface while providing little or no additional functionality. I believe there is a consensus among those agreeing with the proposal that it makes the API easier to use. This, of course, is a matter of opinion. But, it comes down to a fundamental question: is usability a part of 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.) True. But don't the adapters behave in the same way? I would imagine that an IntListList will throw a ClassCastException if an attempt is made to insert a String. I see them as very similar, and I don't find either to be misleading. (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. I can't find IntList.remove(int). IntList.removeElement(int) and IntList.remove(Object) seem to be equivalent. Are you speaking of IntList.removeElementAt(int) vs. IntList.remove(Object). These two are indeed very different - but I don't see the inconsistency. (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. This is a valid argument is we are of the belief that changing method names is bad. But this isn't change for change's sake... I think that this is a side effect of the proposal. (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. I think you're right. Perhaps the proposal could be modified to include constructors which accept both primitive or object collections as parameters? In a sense - the collection could be a bidirectional adapter, Also, I don't see the ability to use a List as an IntList to be that beneficial. One of the selling points of primitive collections is efficiency and performance - since I've already got a List full of objects, why bother? (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. True, but as stated above, this could be fixed. (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. This is an interesting point, as I've never seen packages constructed in this manner. Did you purposefully structure it so that different packages could be used in different JREs? The standard baseline of support for jakarta-commons is Java 1.2... are you suggesting a move backwards? If supporting pre-1.2 JREs is a requirement for certain packages, then let's document it somewhere. Otherwise, I disagree that this is a valid argument against the proposal. The current implementation provides the same functionality as the proposed change, in a smaller, more consistent, and more coherent fashion. The current code contains smaller classes than the proposal, but more of them. So it is smaller - sort of. More consistent, more coherent - with a few tweaks, this is arguable. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] common-math and bloated 3rd party libraries
I, for one, like the idea of commons projects depending on each other
when necessary. There is always a lot of controversy with regards to
including another jar that I don't quite understand. I agree that if
there are only 1 or 2 references, it may be reasonable to include the
dependencies as package private classes, or make more of an effort to
avoid them in the first place. But this avoidance of code reuse
sometimes disturbs me.
Are you short on disk space or something? To me, 850 kb isn't really
that much.
Kasper Nielsen wrote:
Hi gang,
I love commons-math, one problem though!
lets take a look at the dependecies
common-lang: 189 kb
commons-beanutils: 116 kb
commons-collections-SNAPSHOT.jar 463
commons-discovery 70 kb
commons-logging-1.0.3.jar 31 kb kb
Thats 850 kb!!! of 3rd party libraries that are only used in a few places.
So to calculate a simple mean I need to include around 6 jars (including
commons-math)
So lets get the list down a bit.
* Commons-lang
Getting rid of Commons-lang is pretty easy since it is only used in one
place: MathException
Solution : Let MathException extend Exception instead of
NestableException. There aren't really anywhere we use the ability to
nest Exceptions inside other Exceptions in commons-math.
* Commons-collections
Getting rid of commons-collections is also pretty easy
Solution: Getting a copy of HashBag (and the Testcase) and put into
math.util (no need to copy the interface)
now we got rid of ~ 650 kb in around 2 minutes, 3 jars left, this is a
fun game!!
* Commons-Beanutils
Okay the transformers are nice but come on how many people are going to
use them?
Solution: put them into a new small library: commons-math-transformers.jar
** Commons-Discovery
KISS keep it simple stupid, who on earth is going to provide there own
UnivariateRealSolverFactory??
and for those few people that need it... I think they are smart enough
to do figure it out themself.
Solution: remove it (or do something like we do for commons-logging)
** Commons-logging
Lastly commons-logging...
I would think returning NaN is enough, but okay if people insist we can
do something like (pseudo code)
public class logutil
static Method logMethod;
static {
try
{
Class clazz = Class.forName(commons.LogFactory);
logMethod = clazz.getMethod(error);
}
catch (ClassNotFoundException e) {}
}
public static logError(String msg, Throwable t)
{
if (logMethod!=null)
{
logMethod.invoke(msg + t);
}
}
}
and whoops we have now gotten rid of all the libraries, and we have easy
embeddable little commons math jar.
regards
Kasper
Kasper Nielsen
kaspern at apache.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Primitives 1.0
+1 Rodney Waldhoff wrote: 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: [lang] web site
I successfully performed a 'maven site:deploy' for [io] a few weeks ago without a problem. As long at siteAddress and siteDirectory are correct, it should go smoothly. I would suggest doing it on cvs.apache.org, since you'll avoid the overhead of copying the site across the network - but either way works fine. Either remotely or locally on cvs.apache.org, siteDirectory should be /www/jakarta.apache.org/commons/lang, which I would assume it already is. Phil Steitz wrote: __matthewHawthorne wrote: I don't think that the HTML for each commons project's site is stored in CVS, only the main commons HTML. Log in to cvs.apache.org, cd to /www/jakarta.apache.org/commons and do a 'cvs diff', you'll see what I mean. Also, as long as the siteDirectory is correct in lang's project.xml, you shouldn't have to copy the site docs manually to /www/jakarta.apache.org/commons/lang - doing a 'maven site:deploy' remotely or 'maven site:generate site:fsdeploy' while on cvs.apache.org should put the files in the correct place. If running remotely, a username property needs to be set, but I can't find the exact name in the docs. It'll tell you if you don't have it set. Thanks! Have you (anyone?) done either of the maven deployment steps above successfully? Call me a wimp, but given the strange behavior that I have sometimes seen from maven, I am hesitant to be the first to try this on cvs.apache.org. If I do the deploy from cvs.apache.org, what should siteDirectory be? Everything else looked correct to me. I don't think it's silly to do this now - I haven't heard anything about the main site becoming mavenized anytime soon. Phil Steitz wrote: I have put a first cut at a mavenized lang site at http://www.apache.org/~psteitz/docs/ There is nothing new or different in terms of content. Comments welcome. There are a couple of errors that I know about -- the link in the upper right does not work and should be replaced by the Commons logo image and incl_nav has not been updated to reflect the recent promotions of math and dbutils. I will make these changes. Modulo a little clean up, I would like to publish this to the public site. I would appreciate confirmation (or gentle indication that I am out of my mind) re the following steps to accomplish this: 1. Add xdocs directory to jakarta-commons/lang cvs including the files used to make the maven site. 2, Remove lang.xml from jakarta-commons/xdocs (this is replaced by index.xml in jakarta-commons/lang/xdocs). 3. Edit jakarta-commons/xdocs/components.xml and jakarta-commons/stylesheets/menus/components.xml to remove references to lang.html 4. Follow the instructions in jakarta-commons/BUILD_DOCS.txt to build the main commons site locally, commit the changes and update the site. I have done this successfully up to the commit. 5. Generate the mavenized [lang] site locally and move the files manually to /www/jakarta.apache.org/commons/lang. The last step seems odd to me, since we seem to be storing HTML in CVS for all of the of the non-maven sites. Did I miss anything? Is it silly to do this before moving the main site to maven? Are we planning to migrate the main site soon? Phil - 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: [vote] Al Chou for Commons Math Commiter
+1 Mark R. Diggory wrote: Commons and Math commit rights for Brent Warden. [ ] +1 [ ] +0 [ ] -0 [ ] -1 Al Chou has provided many patches and contributions while math has been in the sandbox. I'd like to see him have commit rights on the math project. -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Flat3Map, faster than HashMap
Performance is always a strange issue. When you say that Flat3Map is faster than HashMap for = 3 gets/puts, I would think that you're talking about milliseconds. And, if an application has a performance problem, I would suspect that it isn't coming from wasted milliseconds caused by small HashMaps. It's a proven fact that less object creation equals better performance. My concern is always the cost required to obtain this situation. I'll always prefer a nice clean object oriented solution over one that is tweaked for performance. I'll never avoid using a complex type or creating an object just because it will hurt performance. Whether this preference is practical in the real world, I'm not sure. My point is, I'd never see myself using a Flat3Map to improve my apps performance, mainly because any performance problems that exist are coming from somewhere else. I'm not sure if there is a valid problem for which Flat3Map is a solution. Question: Did you try testing HashMap with different values for initialCapacity and loadFactor? Any other thoughts? Stephen Colebourne wrote: Well I think I've achieved a neat little class in Flat3Map, but I guess others should decide that. (Its checked in, but if people don't like it I'll remove it or rename it or otherwise modify it) Flat3Map is a Map implementation that is optimised for size 3 and less. It stores data in ordinary fields and does not create an array, map entry or other complex object until size 3 is breached. Once size 4 is reached, a HashMap is created and the Flat3Map behaves as per a decorated HashMap. Performance wise - - Gets at size 3 or less are about 0-10% faster than HashMap. - Puts at size 3 or less are over 4 times faster than HashMap. - Performance 5% slower than HashMap once size 3 exceeded once. The gains on put are probably down to object creation and therefore garbage collection. The new MapIterator should be used to get the maximum advantage, as it doesn't create MapEntry objects. The performance test class is also checked in so you can try it out (you have to play with the comments in the loop). I also suspect, but can't think how to prove, that Fast3Map will be easier for the garbage collector to dispose of as it contains no arrays or complex types to hunt through for dependencies. Any ideas on how to test this? Opinions? And should there be a Flat1Map, Flat5Map etc. And what about a Flat3List?? Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [General] What title for resume?
I like the title committer. It's the same description used in the Apache community, plus it has a nice official sound to it. Yoav Shapira wrote: Hi, In the process of revisiting my resume, I was wondering what titles people use to describe their contributions to Apache. Contributor? Software Engineering? Something else? Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Flat3Map, faster than HashMap
Comments inline... Stephen Colebourne wrote: From: __matthewHawthorne [EMAIL PROTECTED] When you say that Flat3Map is faster than HashMap for = 3 gets/puts, er = size 3. You can get/put as often as you like, without exceeding size 3. Sorry, I just phrased that wrong. I knew that you meant size=3 My concern is always the cost required to obtain this situation. I'll always prefer a nice clean object oriented solution over one that is tweaked for performance. I'll never avoid using a complex type or creating an object just because it will hurt performance. Whether this preference is practical in the real world, I'm not sure. Well of course the point here is that as far as the API user is concerned there is no change - you just use a Map interface. Do you need to care how it is implemented? You're right - once again I phrased this wrong. From the user's perspective there is no difference. My point was to question whether performance tweaked code is the type of thing that we want to add to commons. I'm not convinced that classes specific to certain number of Map or List entries would be useful additions. Obviously, I can only speak for myself - does anyone else have a need for such a thing? Question: Did you try testing HashMap with different values for initialCapacity and loadFactor? Actually I just did some more tests: Create new Flat3Map() vs create new HashMap() 2910 vs 4060 Create new Flat3Map() put 3 mappings vs create new HashMap() put 3 mappings 4170 vs 8120 Memory usage Size 0: 56 bytes vs 120 bytes Size 1: 56 bytes vs 144 bytes Size 2: 56 bytes vs 168 bytes Size 3: 56 bytes vs 192 bytes Size 4: 272 bytes vs 216 bytes Size 5: 296 bytes vs 240 bytes Object creation on construction: None vs Entry[16] Maybe I wasn't specific enough. Did you try creating a HashMap using an initial capacity of 3 [ via new HashMap(3) ]? In this case, I believe that only 3 objects are created on construction. I think that setting the loadFactor to 1 [ via new HashMap(3,1)] would also ensure that the Map is only rehashed when the entries become greater than 3. I would imagine that using loadFactor and initialCapacity may provide performance close to Flat3Map. It seems that Sun put them there for situations when the number of entries is known - the same situation you're in. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] new list for cvs commits? (was Re: commons-configuration)
gmane.org is great, that's how I access the apache mailing lists. A good filtering technique is to mark all messages as read, except for projects that you're interested in. I apologize for going off topic, but has anyone experienced delays when sending with gmane? My sent messages show up almost instantly on commons-dev and commons-user, but on the maven lists it takes 15 minutes or so, and on the ant lists it sometimes takes up to 12 hours. Is there a known reason for the delay? Craig R. McClanahan wrote: Emmanuel Bourg wrote: It seems some prefer to keep the commit messages in the list, and others prefer a clean list with just the discussions. So what about this : - commons-dev : discussions + cvs messages - commons-cvs : only the cvs messages - commons-talk: only the discussions or maybe easier to set up : - commons-dev : only the discussions - commons-cvs : only the cvs messages - commons-commiters : discussions + cvs messages (this list is subscribed to commons-dev and commons-cvs with a Reply-To header set to commons-dev) This would suit to everyone. Emmanuel -1. Doing things this way (and it's been this way for several years now on nearly every Jakarta project) is a critical success factor in assuring the quality and popularity of the software created here. Developer lists are for the people developing the packages, and those folks need to see the commits at all times in order to understand what is changing, in addition to their responsibility to review commits at all times. Because it's open source, we're perfectly happy for non-developers to listen in, offer suggestions, and do their own reviews as well -- but a dev list is the fundamental working tool for the people actually developing the code. It therefore needs to be set up to meet *their* needs. If you want discussions and conversations about packages, without the commit messages, that's what the user list is for. On most user lists, the developers hang out as well, and will answer questions about what's coming up in addition to how to use the package. If you want to see isolated discussions for a particular commons package, encourage the developers for that package to create their own specialized -dev and -user lists, like the httpclient folks did. (I personally wouldn't mind if the [math] folks did that, but it's totally up to them -- I've got a filter for their traffic, which includes a whole lot more discussion than it does CVS commits, by the way :-). If you just want to lurk on the developer lists, but still reduce the message count, subscribe in digest mode instead. Then, you'll get all the messages for each day in one single message instead of individually. If you've got NNTP access, consider reading the groups through a newsgroup interface. For example, the news server at http://gmane.org mirrors many mailing lists, including this one (news host is news.gmane.org, newsgroup is gmane.comp.jakarta.commons.devel). But, at the end of the day, if you are using a mail reader that can't filter, get a new mail reader. I'm sorry, but it's hard to be sympathetic with that argument in this day and age. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] logic for determing log level
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]
[sql] anyone around?
I spent some time checking out the [sql] project in the commons sandbox today. I may try it out in a project that I'm working on. [sql] seems to be pretty dead lately, are there any active committers listening? I have a few documentation fixes, and also the project.xml needed some updates in order to build successfully. It needed jelly-SNAPSHOT in order to property process the xdocs. Is it alright if I go ahead and commit these changes? Is there a standard procedure to follow in this situation? If a project has become stagnant, and another committer wants to do some work on it, should they just send a message to the dev list, and if no response is given in a few days, go ahead and start working? Thanks for any info. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-configuration
As far as I know, there's no such thing as a commons-configuration specific mailing list. All commons development discussions and cvs activity go to: [EMAIL PROTECTED] All commons user concerns go to: [EMAIL PROTECTED] Hernan Silberman wrote: I'm looking for a mailing list specific to the commons-configuration sandbox project. The link from the project page led me to sign up to this list: http://jakarta.apache.org/commons/sandbox/configuration/mail-lists.html Just wondering if that's right, I wasn't expecting to get an email anytime there's a CVS commit on any commons file. thanks... Hernan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] UnmodifiableSortedMap bug?
Looks like a bug to me. Perhaps we need some tests to prove that it
isn't doing what it's supposed to... then a fix to make it behave correctly.
Gary Gregory wrote:
Hello,
Looking at UnmodifiableSortedMap, I see the following methods that look odd:
public SortedMap subMap(Object fromKey, Object toKey) {
SortedMap map = getSortedMap().subMap(fromKey, toKey);
return new UnmodifiableSortedMap(getSortedMap());
}
public SortedMap headMap(Object toKey) {
SortedMap map = getSortedMap().headMap(toKey);
return new UnmodifiableSortedMap(getSortedMap());
}
public SortedMap tailMap(Object fromKey) {
SortedMap map = getSortedMap().tailMap(fromKey);
return new UnmodifiableSortedMap(getSortedMap());
}
In each method, the local variable map is never used.
?
Gary
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
