[collections] binary search removeAll/retainAll + other convenience methods
Hi, I have written a few methods in recent months that may fit with [collections]. I'll do a copy/paste of the signatures + javadoc descriptions. Let me know what you think. (Apologies if any of this functionality already exists in [collections]. I took a quick look but didn't see any duplication.) 1) void removeAllUsingBinarySearch(List list1, List list2) 2) void retainAllUsingBinarySearch(List list1, List list2) Functionally the same as List.removeAll(Collection) and List.retainAll(Collection), but uses a binary search in order to find the matches (as opposed to the linear search in Sun's default implementation). (I was working with collections around 50,000 in size, and this made a very significant performance difference.) 3) List splitByMaximum(List items, int maxSize) Splits a list into sublists. Note that this method makes use of java.util.List.subList(int fromIndex, int toIndex), so the result lists are backed by the original -- changes to the result lists affect the original list. (I was in a situation where I had a large number of operations to perform, but due to memory constraints I had to limit the number of operations per transaction. This did the trick.) 4) Map subMap(Map map, List keys) Creates a subset of a map, containing only the specified keys. 5) List getMapValues(Map map, List keys) Using the provided map, gets the values for the specified keys. cheers, matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] initial crack at DateRange class
Stephen Colebourne wrote: The question with DateRange is whether this is a direction that [lang] should go in. Joda-Time has demonstrated that there are many weird and strange things to consider when dealing with dates. Understood. Well, in the meanwhile, it's in Bugzilla until a final yes/no decision is appropriate. I had a need for the class, but if [lang] isn't a good fit, then that's obviously fine too. There were some edge cases that may constitute the weirdness that you mentioned, like whether or not the range is inclusive (currently yes), or whether a 0-length range is valid (currently yes). The desire for a multitude of behaviors by users may be a good reason not to include it, to avoid having to create a hierarchy like InclusiveDateRange, NonZeroDateRange, etc. Thanks for the feedback. matthew.hawthorne wrote: I mentioned many moons ago that I had created a DateRange class for some vicious date mangling that I had to do. I have now modified it to fit into lang.time, and attached the class + unit test to a bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=38800 I've been away from the commons scene for awhile, so I may have missed some protocol-related details. It'd be great if someone could take a look at what I've done. Below is a quick API description of what is there. I think that subtract is a little iffy (although I did have a need for it), but the rest seems to be fairly simple. Assuming that my commit rights are still in effect, I could add this to the codebase myself -- but I wanted to get some feedback to make sure we were all on the same page. Thanks! DateRange(Date startDate, Date endDate) equals, compareTo, toString -- basic stuff long getTime() -- endDate.getTime() - startDate.getTime() boolean contains(Date) boolean contains(DateRange) -- true if this range contains the specified Date or DateRange boolean intersects(DateRange) -- true if this range intersects with the specified DateRange DateRange intersection(DateRange) -- returns a DateRange representing the intersection between this and the specified range. List subtract(DateRange) -- returns one or more DateRanges representing the difference between the two ranges. If the specified range is larger than this, than the list is empty (representing a null range). If this contains the specified range, then the result will have two parts, a range from the start of this to the start of the specified range, and a range from the end of the specified range to the end of this. - 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: [email] ant dist fails / dependencies not found
C. Grobmeier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dion Gillard wrote: If you define a property (in build.properties) javamail.jar=c:/myjars/javamail-1.3.3.ar AFAIK, the build.xml will notice this and copy it into ./lib No, this doesn't work as expected. Cause the build-file works with get, i get: BUILD FAILED C:\Data\Projects\commons-email\build.xml:211: java.net.MalformedURLException: no protocol: /Data/java-repository/javamail-1.3.3_01/mail.jar when i use slashes, backslashes, double-backslashes, C:, c: and so on. You may want to try the 'file' protocol, like this: file:///Data/java-repository/javamail-1.3.3_01/mail.jar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] initial crack at DateRange class
I mentioned many moons ago that I had created a DateRange class for some vicious date mangling that I had to do. I have now modified it to fit into lang.time, and attached the class + unit test to a bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=38800 I've been away from the commons scene for awhile, so I may have missed some protocol-related details. It'd be great if someone could take a look at what I've done. Below is a quick API description of what is there. I think that subtract is a little iffy (although I did have a need for it), but the rest seems to be fairly simple. Assuming that my commit rights are still in effect, I could add this to the codebase myself -- but I wanted to get some feedback to make sure we were all on the same page. Thanks! DateRange(Date startDate, Date endDate) equals, compareTo, toString -- basic stuff long getTime() -- endDate.getTime() - startDate.getTime() boolean contains(Date) boolean contains(DateRange) -- true if this range contains the specified Date or DateRange boolean intersects(DateRange) -- true if this range intersects with the specified DateRange DateRange intersection(DateRange) -- returns a DateRange representing the intersection between this and the specified range. List subtract(DateRange) -- returns one or more DateRanges representing the difference between the two ranges. If the specified range is larger than this, than the list is empty (representing a null range). If this contains the specified range, then the result will have two parts, a range from the start of this to the start of the specified range, and a range from the end of the specified range to the end of this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang]Action Items
Travis Zimmerman wrote: DateRange/Duration class. I have a DateRange class that just need to be cleaned up a bit. I've been struggling to find the time to do this for at least a month or so. Hopefully I can get it in soon after the 2.1 release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io][patch] skip() support for CountingInputStream
Rob Oxspring wrote: I recently replaced the use of my own CountingInputStream with the commons-io and got burnt because io's CountingInputStream doesn't count skipped bytes. I have a patch with fix and patch if people are interested... or I could just commit it... Thoughts? I am not familiar with this class, but as a general rule, I would suggest that you either submit the class as an enhancement in Bugzilla, or add yourself to the committers list and commit it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] PATCH: Add CollectionContainsPredicate...
James Carman wrote: Has there been any thought to creating an optional Commons Collections Contrib project? If users want to use it, they can. If not, they can stick to the core collections classes (which we could keep small). Sorry if this has already been addressed, but I have not been monitoring this list for a while. I think this is a good idea. Also, it may be a way to offload some of the stuff from [collections], if deemed necessary... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] PATCH: Add CollectionContainsPredicate...
James Carman wrote: Is nobody monitoring the collections project? I'd consider adding your patch to Bugzilla as an enhancement. Nobody has responded to your message for 2 days -- but that definitely doesn't mean that nobody is monitoring [collections]. It just means that nobody has had the time to respond. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] parent-first classloaders
Simon Kitching wrote: You mentioned in your page on JCL (http://www.qos.ch/logging/classloader.jsp): quote Jake also keeps reminding us on the log4j-dev mailing list that the child-parent delegation model is not the only model out there and that parent-first delegation model is alive and well. /quote Are you able to provide the names of some frameworks that use parent-first classloading? I'm curious to find out whether these are large + well-used frameworks or whether these are experimental and/or obsolete systems. You probably already know this, but I think most containers give the option to use parent-first, if so desired. I don't know much about classloaders, but I was working with the WebSphere administration console today and I noticed a drop down for choosing parent-first or child-first classloaders. So, there may be a situation where a developer is forced to work with a parent-first configuration, whether it's considered a good thing or not. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang]/[servlet] Doing some tickling
Sorry to jump in mid-conversation, but I have recently written a
DateRange class of my own.
I think it would be much simpler to make the class only operate on Date
objects, both in the constructor:
DateRange(Date d1, Date d2)
and in the methods to check if dates fall within the range:
contains(Date)
intersects(Date)
I find this easier than dealing with numerous ints for startHour,
startMinutes, endHour, endMinutes.
But again, I'm not 100% sure of the requirements.
If what I've described sounds good, perhaps I could upload it into
Bugzilla. Let me know.
Frank W. Zammetti wrote:
On Mon, March 7, 2005 2:21 am, Henri Yandell said:
Largely trying to avoid throwing it straight in as after many moons of
failing, I'm making a push to get 2.1 out :)
I can certainly appreciate that :)
On the larger ideas (DateRange class), I'd imagine an API of:
// DateRange might not extend the math.Range, but would mimic the API
DateRange range = new DateRange(date1, date2, Calendar.HOUR);
if(range.contains(new Date())) { .. }
Unsure. Maybe it'd be simpler with TimeRange being another range that
provides the kind of feature you want, ie) only based on the time of
day. That way the rather dodgy Calendar.HOUR bit can be thrown out.
To me, the part about mimicing the API makes some sense (so long as there
is an overload version that accepts a Calendar so that my use case is
handled too!). The part about extending math.Range (which I realize you
say you aren't sure about) I wouldn't like. It doesn't feel like it
really applies properly, a bit of a square peg in a round hole if you
will. I think the API is the part that really matters though.
I'm not entirely clear on why there are three parameters when constucting
the DateRange though... Seems like a range by definition should only
require two items, no? :)
Given the criteria above, at least an API of:
DateUtils.inRange(Date time, int startHours, int startMinutes, int
endHours, int endMinutes)
It's the 2,358 number I dislike :)
I can live with that :)
We tend to make the target the first parameter btw, but that's no
biggy. I also switched it to be a Date.
Also not a problem for me. However, I would think it would be better to
create another overloaded version to accept a Date rather than replacing
it. I still think there are cases where the base int-only version will
come in handy, and I'd hate to see if removed. I think all overloaded
versions callind on the int-only version is the most flexible model
anyway... I can't imagine an overloaded version I'd rally against :)
Another approach would be if we added a Time class to represent a time
value independent of the day. I'm not sure if Stephen did this in
JODA, but I suspect that it would be a simple enough addition. Maybe
we could extend java.util.Date so that it could still be used easily
in DateFormat/JDBC etc. Some issues with that, but might be usable
enough with them.
Not a bad thought, but I would make an argument that as an application
developer, I'm not sure I'd be thrilled with having to use something other
than JDK standard classes (even though, to me anyway, its a bit bizarre in
the first place to have to use a Date or Calendar when I'm just dealing
with times). I suppose as long as it was easy to get a Time instance
based off of any of these, i.e., Time t = new Time(calendar); Time t = new
Time(date); ... and so on... then I'd be happy with that. I could see
using that myself.
The String variants have the p/pm hardcoded, which will be a bit
limiting. It'd make things slower, but I presume you could use a
SimpleDateFormat here.
That's a good thought, I didn't think of doing it that way. Certainly, if
I could let the standard JDK classes handle the conversion, then cool.
Plus, it should be able to handle just about any format one throws at it,
so that's certainly worth doing. In any case, I can't imagine it would
effect performance any more than the current implementation probably does
:)
Frank
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang]/[servlet] Doing some tickling
Frank W. Zammetti wrote:
My feeling is that this would lead to confusion... The code I proposed is
specifically for checking TIME ranges, but looking at your suggestion, I
can't tell if it would work in determing if an hour fell within a given
range. It might, but I can't tell from what you've posted here. It also,
in my particular use case, has to work when the range start time is on a
Monday and the range end time is on a Tuesday.
I'm fairly sure that it would.
My 'contains' method looks something like this:
public boolean contains(Date d) {
return this.startDate.before(d) this.endDate.after(d);
}
with 'startDate' and 'endDate' being the 2 dates that are passed into
the DateRange(Date, Date) constructor.
I think the object to ints that you and also Henri I think talked about is
valid, but note that you only supply a single int for range start and end,
you don't specify hours and minutes separately. It is this way because
that's exactly what you get if you do Calendar.get(Calendar.HOUR_OF_DAY;.
Henri already talked about adding a version to accept a Date, which I
think makes sense, as long as its an overloaded version, I certainly have
no objection.
I can't claim that I completely follow you here -- but I think I get the
fundamental point.
I can appreciate your desire to only provide hours and minutes, if that
is all that you care about. Part of the problem is that Java only deals
with dates in the full context: year, month, day, hour, seconds, etc.
So, stripping some of that information away may make the calculations a
bit trickier.
I like the idea of the 'TimeRange' object that was mentioned earlier.
I think that may make the simple hour second calculations easier to
deal with.
However, I think this would suffice only if the comparison takes place
within a single day. Once the calculation spreads across multiple days,
I think it would be better assisted with Date objects, to give it the
additional context.
If the difference in 2 Dates is required, then it may also be nice to
create a simple class that can convert milliseconds (from
Date.getTime()) into more useful units, like seconds, hours, days, etc.
I understand that this is simple math, but it can also be repetitive,
so it may be worth thinking about.
Again, this depends on the requirements. I may be going off on some
weird tangents here.
Now, all that being said, I for one say post your class if something like
it doesn't already exist. Being able to determine if a date falls within
a given range is also a valuable function for sure. :)
OK, sounds good. I'll try to clean it up and post it to Bugzilla when I
get a chance.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] jakarta-commons/mail/Email.java (with patch)
I'd suggest that you create a Bugzilla ticket explaining the reason for the change, and then attach the patch to it. It will make it easier for the change to be noticed and committed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
I think it may be better to post the requirements and code on the wiki (so they don't get lost in the shuffle), and then let the discussion commence here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Exact meaning of getPath, esp. on UNIX?
Stephen Colebourne wrote: getPath is currently coded so that: /a/b/c.txt -- /a/b this is of course correct. However, it is also coded to do: /a/b/c -- /a/b which seems a little odd (for me with a windows background). ie. the method treats 'c' as a file not a folder. This method seems to behave the same as the 'dirname' command in Unix. It returns the directory containing the item, whether the item is a file or a folder. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Java5.0 - Runtime exceptions or assertion errors. What's your preference?
David Graham wrote: The main reason not to use assertions is that they can be disabled at runtime, rendering them fairly useless IMO. I think this was a fundamental goal of assertions. I imagine that the idea is to enable assertions during heavy development time, and disable them once the code reaches a certain degree of stability. The enable/disable concept is appealing to some for performance reasons. I think Sun claims that an assertion will have no performance cost if they are disabled. I'm not sure how much of a difference it would make. Personally, I would remove the null parameter checking entirely and let the code throw a NPE. The caller will see their offending method in the stack trace. I share your philosophy on this. In my opinion, the redundant parameter checking everywhere (especially for null) does more harm than good. I like assertions, except in cases of input checking for a client external to the application (like a web service client, for example). I don't see the enable/disable as much of an issue. The RuntimeException cases are supposed to be caught during development anyway. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [feedparser] Getting Brad Neuberg CVS commit
Kevin A. Burton wrote: Listen... I'm sorry if we're trying to move too fast. We're a startup and on a very aggressive schedule. We're trying to get FeedParser to 1.0 ASAP because its a critical portion of Rojo. Brad is a lead developer and its becoming difficult to synchronize our work without CVS commits. We're constantly having to coordinate our commits due to CVS limitations. If we were using a more anarchic revision control system like bitkeeper or arch this wouldn't be as much of a problem. I apologize in advance if I'm out of line, but has anyone considered if the jakarta-commons-sandbox is truly the best place for [feedparser]? Based on recent emails, it doesn't seem to be a good fit. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cache
John Lucky wrote: Have any of you used Cache from Commons Sendbox? The API documentation built from JavaDocs is not very helpful. I'd love to get some guidance how to use the Cache propertly. I've never used it, but from what I've seen on the list, it isn't very actively used or developed. You may want to consider using something like ehcache instead: http://ehcache.sourceforge.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Betwixt] Absolute file names again (was Re: cvs commit: jakarta-commons/betwixt build.xml)
Stefan Bodewig wrote: On 13 Oct 2004, [EMAIL PROTECTED] wrote: Re-generated ant build (so that latest dependencies are reflected) ... project default=jar name=commons-betwixt basedir=. - property name=defaulttargetdir value=target + property name=defaulttargetdir + value=/Volumes/gSpecials/library/jakarta/jakarta-commons/betwixt/target + /property I thought this is supposed to work with the latest Ant plugin? Are you using an older version, Robert? Anyway, could anybody with karma for betwixt please fix it (I don't to do it manually and I don't run Maven myself). I just fixed this. Hopefully things will work now. Will this absolute path issue ever go away? Perhaps I should look into it and try submitting a patch to Maven... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Each Mutable Number class declares Serializable
Gary Gregory wrote: I see that java.lang.Number declares java.io.Serializable. Number subclasses in java.lang do not but each of our Mutable number classes does. This does not seem necessary. Am I missing something? Can we remove these extra declarations? I guess it depends on how likely we think it is that a user would want to serialize a Mutable Number. Does serialization create maintenance issues that we'd rather avoid? I'm not sure, and don't feel strongly about either choice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Mutable type casts and MutableNumber
Gary Gregory wrote:
1st minor: there are a bunch of unnecessary type-casts, I'd like to
remove those if no one objects. For example, in MutableInteger, this
cast to long is superfluous:
public long longValue() {
return (long) value;
}
That sounds right, perhaps these casts were just an oversight.
2nd: There is no MutableNumber class. It seems to me that the mutable
number classes are paralle to java.lang.Number classes and should
therefore also be subclasssed from a MutableNumber.
Originally, there was such a class, but after some analysis and
refactoring, it wasn't really doing anything and was nominated for
removal. However, I understand your point. If MutableNumber were to be
resurrected, it would serve only as a marker interface. I'm fine with that.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CSV submission for jakarta-commons
- your test-cases should be in a separate directory and named TestXXX If this requirement is necessary to match the existing [codec] test classes, then that's obviously the way to go. But I don't think that this is an Apache-wide standard, nor do I think it should be. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Do we need to support Ant based builds?
Shapira, Yoav wrote: Should we start a new discussion thread on getting commons projects built nightly via Gump @brutus.apache.org? I think this is the ideal solution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][betwixt] Release Betwixt 0.6
-- [ x ] +1 Unreservedly support Betwixt 0.6 Release [ ] +0 Support (with reservations) [ ] -0 Cannot support this release [ ] -1 Betwixt 0.6 should not be released - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Interpolation
David Graham wrote:
--- Stephen Colebourne [EMAIL PROTECTED] wrote:
Potentially, we could use the digester version to start from. (In new
commons style, there would be copy-paste with reference to original, not
dependency)
If we start doing this in commons it will be more ridiculed,
and rightfully so, than it already is.
I see your point, but keep in mind that this was done to make the lives
of the users easier. Forcing a user to include a huge [collections] jar
for a project that only uses 1 or 2 classes from it doesn't seem
practical to me.
Sometimes, in one of my projects, I'll have 2 components that need
a certain thing. I don't always have the ability to make them
depend on each other, nor the ability to create a third component that
they can both share. So, I'll write a class/method and put it in both
components -- but I keep my eye on it, because if it grows, and lives
with other classes/methods that are copy/pasted, then I have a good
reason to make a new component.
I think that [beanutils] (for example) just copy/pasting in a class
from collections is a good idea, if it's just a few. But, if the
number grew, then I'd say just go ahead and include [collections] as a
dependency.
IMO, copy-paste reuse is the worst offense that a programmer can commit.
I agree that it's bad news.
But, I think the worst offense is this:
try {
// ...
} catch (Exception e) {
return null;
}
(shudder)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[io] Re: ProcessUtils and support classes offer
Cris Perdue wrote:
The purpose of the main ProcessUtils class is to make it simpler to call
external programs and receive the results back. It was inspired
especially by the TCL exec function and also resembles the Perl backtick
operator. A simple call to df using the simplest form of call could
look something like:
String filestats = ProcessUtils.exec(new String[] {df});
The package handles program output to standard error and nonzero exit
codes.
This may be a good fit for commons-io
(http://jakarta.apache.org/commons/io/). A class like ProcessUtils
seems interesting, but it would definitely need some extensive testing
on different platforms to make sure it's OK.
Consider submitting your stuff as a Bugzilla enhancement, so that the
commons-io developers can take a look when they
get a chance.
I believe the javadocs state that ProcessUtils throws an exception if
anything is written to stderr. I would like it if this were
customizable, since a lot of programs write warnings and such to stderr,
but still keep on running. Perhaps it could become
some type of callback mechanism.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] logging
Craig McClanahan wrote: On Fri, 27 Aug 2004 13:03:43 -0400, Alex Karasulu [EMAIL PROTECTED] wrote: However I think this issue is one we can resolve if we generalize the problem using monitors and event notification. Logging is just a specific application for a monitor. Paul Hammant described this in the NoLogging wiki here: http://wiki.apache.org/avalon/AvalonNoLogging The problem I have with this general approach is that it trades a dependency on a logging adapter for a requirement to create code that responds to the individual event handling interface for every single library I'm using. This is only a requirement if you have a need to get details about what the library is doing. In most cases, I don't -- but I obviously can't speak for everyone else. Logging (via commons-logging) has become pretty much a standard part of development for me. But for those for which this is not the case, I don't see implementing a simple monitor interface to handle events as much harder than putting log4j into the classpath, setting up the config file to log for the desired class, etc. Either way requires some extra work. The primary benefit of having all the libraries conform to a common logging API (whatever it is) is *precisely* the fact that I, as an application developer, don't have to go through that kind of pain -- I just configure the logging levels and destinations, using my favorite logging implementation (using a single log for everything, separate logs for functional areas, requesting the appropriate amount of detail on a global or local level, or whatever else I want), and it just works. I guess I always saw the primary benefit and purpose of commons-logging to be a bit simpler than this. I thought it was to allow libraries to log, while allowing the user to choose which logging library is used -- nothing more. However, what you've said may indeed be true -- the issue is whether what works best for you works best for everyone else. I'm fine with everything using commons-logging, but that's because I use it in pretty much every project I'm on anyway. For others, it may cause more of an inconvenience, although I'm not quite sure how. Too many jars, maybe. My concern can be dealt with by implementing a commone event monitor API that all the libraries use, so that I can still implement a generic event listening framework ... but isn't that, in spirit (although not in the proposed implementation manner), exactly what commons-logging already does? Very true -- but I don't think this is what anyone was proposing. If this was the idea, then, just as you've said, I think commons-logging does the job fine. No need for commons-monitor or anything weird like that... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [resources] An interesting problem
James Mitchell wrote: I want my test classes to reuse this same test code, but I don't know what the best approach is. I don't want to copy/paste the existing code because I don't care to maintain the same code in 2 places. However, I can't simply reference the jar.because there is no jar, they are just test classes. What would you do? Create a jar containing the test classes. If other projects depend on these tests, then they are a valid artifact produced by the project and no longer just test classes. I run into this situation frequently when I have one component which defines a set of interfaces, and also tests for these interfaces. Then, I have another component which implements the interfaces, and the tests need to reference the interface tests. So, I'm in the habit of producing test jars along side the normal ones. [collections] does something similar to this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [resources] An interesting problem
James Mitchell wrote:
Currently the project.xml produces commons-resources-1.0-dev.jar
Can you help me with how I need to tell maven to create a 2nd artifact?
Something like commons-resources-tests-1.0-dev.jar
The cleanest way is to split the project into 2 subprojects.
commons-resources/
core/
src/
main/
tests/
src/
main/
Make the 2nd project depend on the 1st. You could do maven
multiproject:install
in the commons-resources directory to build them both.
However, a lot of people find this undesirable. You could do some maven.xml
magic to make this happen instead, and keep everything in one source tree.
Here's an example of how I did this, before I switched to the
multiproject format.
!-- Builds and deploys test jar --
postGoal name=jar:jar
ant:jar destfile=${maven.build.dir}/${testjar.name}
fileset dir=${maven.build.dir}/test-classes/
/ant:jar
/postGoal
define the property 'testjar.name' as whatever you want.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Math needs a user email list.
Believe me, I've worked IT support for university professors, sometimes I'm very surprised they even know what an email account is...let alone filtering. That's funny. But, if they don't know what filtering is... what are the chances that they know what a mailing list is? I don't want a bunch of uninteresting messages in my mailbox either, so I just use gmane. Maybe this would be a good suggestion for these professor types? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons Configuration
Wilson, Allen wrote: I am trying to create a java class that will send HTML mail. I have the class created and compile but it errors out specifying that the org.apache.commons.configurtion.Configuration class cannot be found. Does anyone know where I can locate the jar files for the Commons Configuration. I look on the Apache Jakarta site and found the Commons Configuration area but no link to the files could be found. This question seems better suited for the users list. It doesn't seem that commons-configuration has been released, so you'll want to grab a nightly build from: http://cvs.apache.org/builds/jakarta-commons/nightly/commons-configuration/ That should solve your immediate problem. But I didn't really understand your description of the scenario. It seems that you are using another Jakarta library (like commons-email) that requires commons-configuration... but you didn't mention such a thing. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] ArrayUtils monster file
Gary Gregory wrote: ArrayUtils is currently a 3800+ line monster file. I am working on adding add and addAll methods for 2.1 and am wondering what folks would think of a separate class for these ops: ArrayAddUtils? AddArrayUtils? Sounds like a good idea, depending on how many methods you're adding. That's an incredibly large class, but all of the methods seem somewhat simple, so I could see arguments for keeping it together vs. breaking things apart. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [any] NoClassDefFoundError trying to build with Maven 1.0
This strange error was in the log you provided. I'm not sure if it's occurring due to ibiblio being overloaded, or what. But perhaps it's the cause of your problems? Getting URL: http://www.ibiblio.org/maven/velocity/jars/velocity-1.4-dev.jar Received status code: 200 last-modified = Fri, 30 Jan 2004 00:50:23 GMT (1075423823000) Error retrieving artifact from [http://www.ibiblio.org/maven/velocity/jars/veloc ity-1.4-dev.jar]: java.net.SocketException: No buffer space available (maximum c onnections reached?): recv failed Error details java.net.SocketException: No buffer space available (maximum connections reached ?): recv failed at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.io.FilterInputStream.read(FilterInputStream.java:111) at java.io.PushbackInputStream.read(PushbackInputStream.java:161) at java.io.FilterInputStream.read(FilterInputStream.java:111) at org.apache.commons.httpclient.ContentLengthInputStream.read(ContentLe ngthInputStream.java:167) at java.io.FilterInputStream.read(FilterInputStream.java:111) at org.apache.commons.httpclient.AutoCloseInputStream.read(AutoCloseInpu tStream.java:142) at java.io.FilterInputStream.read(FilterInputStream.java:90) at org.apache.commons.httpclient.AutoCloseInputStream.read(AutoCloseInpu tStream.java:161) at org.apache.maven.util.HttpUtils.process(HttpUtils.java:572) at org.apache.maven.util.HttpUtils.retrieveArtifact(HttpUtils.java:538) at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:381) at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:287) at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:181) at org.apache.maven.verifier.DependencyVerifier.getRemoteArtifact(Depend encyVerifier.java:326) at org.apache.maven.verifier.DependencyVerifier.getDependencies(Dependen cyVerifier.java:255) at org.apache.maven.verifier.DependencyVerifier.satisfyDependencies(Depe ndencyVerifier.java:171) at org.apache.maven.verifier.DependencyVerifier.verify(DependencyVerifie r.java:97) at org.apache.maven.project.Project.verifyDependencies(Project.java:1365 ) at org.apache.maven.plugin.PluginManager.loadScript(PluginManager.java:9 60) at org.apache.maven.plugin.PluginManager.runScript(PluginManager.java:99 3) at org.apache.maven.plugin.PluginManager.initialiseHousingPluginContext( PluginManager.java:706) at org.apache.maven.plugin.PluginManager.prepAttainGoal(PluginManager.ja va:685) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java: 624) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266) at org.apache.maven.cli.App.doMain(App.java:486) at org.apache.maven.cli.App.main(App.java:1215) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Artifact /velocity/jars/velocity-1.4-dev.jar doesn't exists in remote repository , but it exists locally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [any] NoClassDefFoundError trying to build with Maven 1.0
Martin Cooper wrote: Anyway, since it exists locally (it was part of the Maven download, after all!), this shouldn't be an issue, right? Maven does keep going after that. I'm not sure that Maven reporting that the file exists locally is correct. I may have created the file locally, started downloading it, then failed to finish the download. Can you examine: C:\Documents and Settings\mcooper\.maven\repository\ velocity\jars\velocity-1.4-dev.jar and confirm that it looks ok? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [any] NoClassDefFoundError trying to build with Maven 1.0
Martin Cooper wrote: On Sun, 25 Jul 2004 11:37:37 -0700, matthew.hawthorne [EMAIL PROTECTED] wrote: Martin Cooper wrote: Anyway, since it exists locally (it was part of the Maven download, after all!), this shouldn't be an issue, right? Maven does keep going after that. I'm not sure that Maven reporting that the file exists locally is correct. I may have created the file locally, started downloading it, then failed to finish the download. Can you examine: C:\Documents and Settings\mcooper\.maven\repository\ velocity\jars\velocity-1.4-dev.jar and confirm that it looks ok? Aha! You're right, it wasn't OK, it was truncated. It appears that all of the ones that caused exceptions are in the same state. Obviously, I can download all of these manually, but that kinda defeats the purpose of Maven, so it would be nice to know why this is happening, and fix my machine so that it doesn't... BTW, I have no problem connecting and downloading these manually, so there must be some odd thing in my setup that's causing Maven to fail. Any ideas much appreciated! I suspect that it has nothing to do with your setup. Perhaps ibiblio was temporarily overloaded, or something. Try this -- delete the directory C:\Documents and Settings\mcooper\.maven\repository\velocity And attempt to run it again. Maybe Maven doesn't use the md5 files to ensure that jars that are found locally are valid. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release vote for JXPath 1.2
Dmitri Plotnikov wrote: I'd like to call for a release vote on JXPath 1.2. It has been stable for a long time, and there are no outstanding bugs against it. It includes about 1.5 years of bug fixes and other improvements. The release candidate build can be found at http://www.apache.org/dist/jakarta/commons/jxpath/jxpath_1.2RC2/ +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [chain] Deploying new website
Stephen Colebourne wrote: From: David Graham [EMAIL PROTECTED] --- Don Brown [EMAIL PROTECTED] wrote: I moved the chain cvs from sandbox to commons proper (long story) and have updated the build and doc files such that the website builds and is ready for deployment. I have not modified the site source for the jakarta website pending deployment of the new chain site. Should I manually deploy the website and if so, what does this involve? I don't know of any other way than manual. I just log into cvs.apache.org and navigate to /www/jakarta.apache.org/commons/chain (not sure if that's exactly the right path), tar up the existing site, untar the new site into that directory and you're done. If anything goes wrong I just untar the old version. The site is built with 'maven clean site'. maven clean site check the website maven site:sshdeploy The last line should install the new website on the server. Stephen Or, you could ssh into Apache first, then build the site and just do site:deploy. I prefer this way, to save bandwidth and speed things up a bit, but it probably doesn't make much of a difference. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Javadoc question
Steve Cohen wrote: What is the right way to express such links in javadoc? Relative paths? is there some sort of root notation that would correctly resolve intra-project javadoc links such as these? Finally, can maven, which generates these page from source help somehow in setting these up? You should use @link tags for intra-project links. For example [EMAIL PROTECTED] org.apache.commons.net.FTPParser} (I'm not sure if that's a real class...) If it's in a @see tag, you can just put the classname without the @link notation. Recent versions of Eclipse will actually tell you if the Javadoc is referring to a class that doesn't work. As far as I know, there's nothing special Maven does with regard to intra-project Javadocs. But for external Javadoc links, you can set the maven.javadoc.links property to a comma separated list of Javadoc URLs (such as http://jakarta.apache.org/commons/collections/apidocs) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Small patch for unusual situation.
Adam Jenkins wrote: Sorry, just realized there is 'System.out' code which will need to be removed...email me if you want me to rip it out. (didn't use a logger due to classloading isolation testing requirements :) ). You should submit this as an enhancement in Bugzilla, so it doesn't get lost. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] JDK1.5
It seems that the vendors are (indirectly) controlling this situation in commons now anyway. I believe that Websphere still only runs on 1.3, so that's the limiting factor as far as JDK versions go -- or else people who use Websphere can't use [collections]. I tried JBoss 3.2.4 the other day and it runs on 1.5 (3.2.3 didn't.) As far as I know, the latest version of Jonas doesn't run on 1.5. I'm not sure about the other servers. I think a branch, or as you suggested, a completely separate project may be the best way to go here. This may be a good thing to discuss for commons as a whole, because it's a complicated situation and no solution seems apparent, other than not using 1.5 features at all. There are wide-spreading new syntax features other than generics (varargs, autoboxing, enums) in 1.5 that seem very nice. But I don't really have the time or the energy for such a thing right now anyway, and I want to spend some time learning how to use the new features before I start abusing them. Stephen Colebourne wrote: While release 3.1 is being tidied up (still time to vote ;-), I thought I'd just put out a note about JDK1.5. One of the key enhancements in JDK1.5 is generics which allows typed classes using the angle bracket notation. The biggest area this impacts is collections. Clearly questions have to be raised as to how this affects [collections]. So far, I have done no work to see if [collections] will compile under JDK1.5. My expectation is that it will, but there are no guarantees. To take full advantage of generics will involve a considerable rewrite of [collections]. It will affect every class, and produce a version that only compiles on JDK1.5. I have no doubt that Sun spent many mandays changing the JDK classes to achieve this update. Personally, I have no plans to update [collections] to JDK1.5 (no itch, too much effort). If anyone else does, feel free to come in and either change [collections], or (more likely) create a new [collections15] project. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/math build.xml
Phil Steitz wrote:
Ouch! Once again, maven is generating local path references. Does
anyone know how to stop this???
I had hand-edited the previous version to correct this.
I had heard it was fixed back around rc1, but was never able to confirm
it. I think it's the ${basedir} references that screw it up, and I'm
never quite sure if I need ${basedir} in there, especially if I'm doing
multiproject builds.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][collections] Release 3.1
- [ x ] +1 Go ahead and release 3.1 [ ] +0 [ ] -0 [ ] -1 Don't release 3.1, because... - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs][all][poll][RESULT] regular expression library or jdk1.4 as minimum requirement
Gary Gregory wrote: I am personally against this kind of super fine slicing and dicing. :-( Our build already has to copy around, put on classpaths for unit tests, distribute, etc, ten (10) apache jars, now you're telling me that one of these is going to blow up into SEVEN?! This is not progress for us. Not progress for you, but maybe progress for others. I think I read that ORO is still going to build an all jar which includes everything, so it shouldn't make a difference. For every person who wants a library to involve one and only one jar, there is another who wants to be able to pick and choose from smaller jars to decrease the overall size of their applicable bundle. I'm not sure which side I'm on, but I've heard people from both sides complain pretty loudly, so I think the best thing is to try and satisfy both, which is what seems to be happening here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] mutables
Henri Yandell wrote: The constructor for MutableNumber is odd. It's a) Empty, so possible to have a MutableNumber without a value yet. b) package-scoped, so only we can extend it. I'm not sure if there are good uses for a), but b) seems like something we don't need to do. I guess I didn't think that anyone would want to create a MutableNumber, they would opt for the more specific MutableInteger, MutableFloat, etc. But if that's not the case, then the package scoping is too restrictive and should be changed to public. The default (empty) constructor doesn't make sense to me either, maybe it was just an oversight. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] mutables
Henri Yandell wrote: First thought when looking at the code is that we could simplify things with a protected Number in MutableNumber, and move the intValue etc methods up into MutableNumber. The getValue/ setValue(Object) can go up too, and all that would be left in the mutable subclass is the primitive override and the constructor. Pro: Less code in the subclasses. Con: A protected rather than private variable. More memory is taken up with the mutable part being an Object and not a primitive. Just a thought. I think the pro of simpler code may be bigger than the con of memory loss. Those involved in hardcore performance tweaking may disagree. For me, the mutable classes were more about the added functionality than the savings in memory, so I'm in agreement with you here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jxpath][VOTE] Release plan for JXPath 1.2
Dmitri Plotnikov wrote: We have received repeated requests to make a new release of JXPath. Even though there have been no major functional changes or additions since 1.1, the number of bug fixes and other improvements warrants a new release. This is a vote to approve the 1.2 release plan (http://wiki.apache.org/jakarta-commons/JXPathRelease1_2e2) and myself as release manager for this release. +0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Resources] - quick question
James Mitchell wrote:
Sorry for the RTFM question, how should I go about getting the iBatis jars
published on ibiblio.org so that our maven script can find them?
I have finished the iBatis Database impl for Resources (with tests) but I
want to make sure I don't break the build since the above mentioned jars are
not available.
And while waiting for the upload request to happen, you may want to just
check in the jars and use Maven's jar override feature to locate them.
Something like:
maven.jar.override=on
maven.jar.ibatis=${basedir}/lib/ibatis.jar
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[lang] mutables
I just made a checkin of some initial code for mutables. I haven't used CVS in a few months now (switched to subversion) so let's hope I didn't screw anything up. I have to admit that I haven't looked at this code for a good time, since around August maybe. So all are welcome to take a look and make improvements. I don't really have a solid use case for these classes anymore, so I'd imagine that others will have a better insight in that regard. The test coverage is pretty good, I think in the 70% range. I remember learning some weird things about the way Java handles primitive number conversions, as I was trying to get the tests to pass. If something looks bizarre give a yell and I'll investigate. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Resources] - Moved database impls down from contrib - NIGHTLY BUILD CHANGES REQUIRED
James Mitchell wrote: * Configuration Issue: Hibernate requires jta.jar and the license (I think) does not allow Ibiblio to make that jar available so whoever runs the nightlies (??Craig??) will need to set that up. There is a note in project.xml with a link to a resource that explains it in detail. Here's something cool I noticed with regard to unpublishable jars -- Geronimo includes J2EE spec jars on ibiblio. I think this is what you need: http://www.ibiblio.org/maven/geronimo-spec/jars/geronimo-spec-jta-1.0-M1.jar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [testutils] Is there any commons area for generic test code?
Alex Karasulu wrote: Is there a place where we can collect and localize utility methods and classes used for unit testing? I have not found anything yet. Is it even worth doing this? The problem with a project like this is that the scope would be hard to define. The only common thing that I use in my tests are: - java.util.Random to generate test data - extentions of junit.extensions.TestDecorator or junit.textui.ResultPrinter in order to do some debugging, such as printing when a test starts So I think it would be hard to get a nice group of test utils that feel like they truly belong together. If you have commit access, as far as I know there is nothing stopping you from creating a new sandbox project and committing some of your ideas. If you've got some cool things then I'm sure others would get interested. Also perhaps things like the commons collections testing framework could be kept here as well. Don't if this is the right thing to do but just a thought. It might not be a good idea since it is so specific to collections but this can be discussed over time. I think the [collections] testing framework belongs in [collections]. I don't think that the test framework is [collections]-specific, but I do think that it falls better under the scope of [collections] than it would a separate testing project. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [collections] Release 3.1 RC1
Stephen Colebourne wrote: This vote is to approve the public release of commons collections 3.1-RC1. This will be a publicly announced RC to enable full feedback pre final release (about two weeks if all is well). http://www.apache.org/~scolebourne/coll31/ - [ x ] +1 Go ahead and release 3.1-RC1 [ ] +0 [ ] -0 [ ] -1 Don't release 3.1-RC1, because... - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Wiki SPAM]
Noel J. Bergman wrote: Or perhaps we should have a [EMAIL PROTECTED] list that committers should subscribe too. Its simple and keeps these messages out of the archives. that would be really cool. and CVS-SPAM too... See, when someone starts talking about CVS commit notices as SPAM, I know that there is the wrong attitude. No one who is developing Jakarta Commons, as opposed to developing WITH Jakarta Commons, should be considering commit notices as SPAM. Perhaps there are people on this list who should be on the user list, instead. +1, well put. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Collections] MultiMap status?
Paul Gear wrote: No takers on my question about spaces rather than tabs? I think it's because tabs are interpreted, and thus represented in different ways in different editors, on different platforms. If this isn't true, then I have no idea. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs][all]maven generated build file and conditional compilation
Mario Ivankovits wrote: If i use maven ant to regenerate the build file for vfs the following chunk will be removed from the current build.xml. The indention is to allow to compile only these pieces which are relly needet. This might only be significat if a user build its own vfs and do not want to download all dependencies. Now i would like to know: Is it really needet to use maven ant to regenearate the build.xml? If yes, is it possible to describe this conditional compilation behaviour? I tried sourceModifications but this do not find its way into the ant build file. Maybe you could do this in a maven.xml preGoal to java:compile? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] MutableXxx Was: [Jakarta Commons Wiki] New: MutableNumbers
So, should I commit what I have into lang.mutable, and we can go from there? I have all of the Number types complete, with some decent tests. This way, anyone who's interested can take a look and make improvements. Stephen Colebourne wrote: From: Henri Yandell [EMAIL PROTECTED] 1 lang.mutable gets my vote. +1 2 MutableXxx gets my vote as a naming scheme. +1 3 I'm in favour of MutableXxx having instance links to XxxUtils to make them more powerful [and delegating calls to all Xxx methods]. This does make it a large lump of work though. -0 for v2.1, +0 after 4 Do we need MutableInteger, MutableFloat etc, or can we just normalize on the main ones? I think we need them all, as casting the get() is a pain otherwise. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] 2.1 TODO
Henri Yandell wrote: Matthew, any idea what the state of Mutables was? There seem to have been many threads off and on for the last year or more. I submitted a bug report with an attached set of classes back at the end of August. I made a few minor changes based on other's suggestions since then. I think we need to reassess if these classes are appropriate for [lang]. If so, I'd be happy to update the bug report, or commit something and let others take a look. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Re: cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang Validate.java
Gary Gregory wrote: Sorry for the flame but this is a 'shake-my-head-in-disbelief' moment that I find discouraging. I pretty much agree, but from my POV [lang] stopped moving forward a while ago anyway. Most new requests or ideas are rejected as out of scope (which is usually valid), and the project has shifted into maintenance mode. Along with this came a certain identity crisis, and that's why the cut-and-paste philosophy came along. As another example, I've never even liked the public constructor in *Utils classes, even though I understand why it's done. Helping and supporting users is important, but I think there is a certain line that has to be drawn. I think that developers should have the freedom to make classes and methods final where appropriate, and make other design decisions that may limit the possible uses of the library. In losing that ability, I believe that the quality of the code suffers. And for someone like me, it makes me less motivated to become involved or share ideas. I may be dead wrong, these are just some feelings that I have. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Collections 2.1.1
Stephen Colebourne wrote: Commons Collections 2.1.1 is a patch release to 2.1 to allow binary compatability with CVS head and the upcoming 3.1 release. [ x ] +1 Yes, release the patch [ ] +0 [ ] -0 [ ] -1 No, because - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections][lang] generic min/max functions
Emmanuel Bourg wrote: Hello, I was looking for a min/max function working with dates and thought such a trivial feature would be already in [lang], but surprisingly it isn't. I expected a min/max(Date, Date) function in DateUtils, then I looked for a min/max(Comparable, Comparable) and I eventually found the ComparatorUtils.min/max(Object, Object, Comparator) functions in [collections]. Wouldn't it make sense to move or copy these functions to [lang] ? Maybe just adding a ComparableUtils class to [lang] would be enough, what do you think ? I can contribute a patch. Can't you just use java.util.Collections min(Collection) and max(Collection)? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections][lang] generic min/max functions
Emmanuel Bourg wrote:
Yes it's an alternative, but at the cost of additional lines to create a
collection.
Date date = ComparableUtils.min(date1, date2)
vs
Collection dates = new ArrayList();
dates.add(date1);
dates.add(date2);
Date date = (Date)Collections.min(dates);
I see your point now. But, in the meanwhile, you could always do it
this way:
Date date = Collections.min(Arrays.asList(new Date[] {date1, date2}))
I'd imagine that this may be a bit wasteful (object-creation wise), but
it's a one liner nonetheless.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sql] [patch] sql server improvments, fix for prior patch
John M wrote: I had previously submitted a patch for the sql project, and it was finally accepted, sort of. It seems only part of the patch was merged. I have included the other parts that didn't make it before, as well as some fixes for SQL Server DDL generation that I discovered while working on a new project with it. Alas, some of the changes in the patch are mere whitespace changes, but I didn't feel like trying to undo all of those. Please submit your patches to bugzilla. If I remember the patches you submitted before correctly, there were reasons that I left pieces out. There were some tests that connected to a local mysql database, which just won't work on everyone's machine. There also was some maven.xml magic that I didn't view as necessary. I'll try to take another look at those parts, to make sure I didn't misunderstand something. Unfortunately, I think I'm the only person who is involved with [sql] these days, and I've been struggling to find time to get it moved over to the db-commons. This is something that I've been wanting to do since the fall. So, bear with me -- I'm not sure when I'll get to commit these. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
Dain Sundstrom wrote: On May 13, 2004, at 2:23 PM, Stephen Colebourne wrote: I am opposed to adding snapshots to ibiblio, as I have seen it create isues. IMHO ibiblio should be released/stable code only. Can you be more clear? I think ibiblio snapshots are great and would hate to see them go away. Think of all the projects out there that are using apache snapshots that would have to add the apache repo to their project. Not only is this a lot of traffic to apache, I think it also sets a bad precedent for other projects. Think of a project using a lot of snapshots and they have to add every small project's repo to the repo list (which may also add to the apache traffic as maven has no idea which repo may have the snapshot, so it tries them all in order) Anyway I'm rambling now I am curious about the issues this creates. Part of the problem was a bottleneck in getting new and updated Apache projects onto ibiblio. There also is a certain degree of snapshot clutter on ibiblio. Especially since ibiblio is only accessible to certain people, I think it makes sense for it only to contain releases, and to have the snapshots at Apache. The traffic issues could probably be handled by the mirrors, if it isn't already. I also don't see adding the Apache repo to a properties file as a big deal -- especially when compared with the chaotic and sluggish nature of the Apache-ibiblio situation, which seems to have been improved greatly with this new system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] eliminate dependencies on commons-logging [was[beanutils] PROPOSAL: eliminate core dependency on collections
Tomasz Pik wrote:
Also, o.a.c.l is probably the biggest success of Jakarta Commons team
and I don't think that such solution is the best in the 'marketing'
terms ('whole world using it so we're going not to use it...').
The fact that many servers already include commons-logging isn't the point.
I typically have at least 10 commons jars in my classpath at all times, but
it isn't fair to assume that everyone else does the same.
Also, I don't think any decision has been made to stop using
commons-logging.
All that is occurring is a conversion of the commons-logging dependency
from mandatory to optional.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] remove dependency on commons-logging
Alex Karasulu wrote: Sorry to step in late but has anyone considered the use of a generic event callback interface for use in monitoring. Beanutil classes can expose a BeanutilsMonitor interface with methods that are called by the executing code to monitor notable events such as failures and successful operations. [snip] This sounds interesting, and for lower-level libraries I think it actually makes more sense -- giving more power to the user. For example, I think that beanutils is justified in defining the types of events that occur, but not necessarily in assigning logging levels to these events. For example, sometimes when things aren't working with betwixt, I'll enable debug logging for org.apache.* (forgetting the huge mistake that I'm making) and then I'll be assaulted by millions of statements from betwixt, digester, beanutils, etc. Perhaps this is a bad example, but my point is it would be nice to allow deeper customization of logging, without getting too fancy. However, I'm not sure that everyone will like this sort of thing -- some may think it's a bit too complicated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] remove dependency on commons-logging
David Graham wrote: I was reluctantly in favor of copying certain Collections classes as a temporary solution to removing that dependency but I don't see why we want to permanently copy Logging classes to other projects. Commons Logging is an abstraction for Log4j and java.util.logging; now we're going to add yet another abstraction above Commons Logging? That doesn't make any sense to me. I'm not a BeanUtils committer but as a user and Commons committer here's my -1. I don't see it so much as an abstraction, but instead as the conversion of a dependency from mandatory to optional. If a [beanutils] user doesn't care about logging, they shouldn't have to worry about including commons-logging in the classpath. The solution to this problem may seem a bit strange to some, but I think that it's worth the trouble. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] eliminate dependencies on commons-logging [was[bean utils] PROPOSAL: eliminate core dependency on collections
Inger, Matthew wrote: Why not a service locator pattern for hooking into the logging implementations? Make a commons-logging-api.jar which has all the core pieces. Then, say a commons-logging-log4j.jar which has strictly the log4j classes, a description file, which the LogFactory searches for at runtime to find implementation classes. I'd be happy to code this up. But this solution seems like it would still require a logging jar for beanutils, even if a beanutils user didn't care about logging. The point of this discussion seems to be how to make commons-logging a truly optional dependency. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] BinaryCompatability tester
Stephen Colebourne wrote: Does anyone know of a tool to test whether a new version of a jar file is binary compatible with the old version? Could you do a checkout of the unit tests for the last release, and run them against the new jar? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Local repository for Maven builds
Eric Pugh wrote: For [configuration] I am doing testing using a jar that hasn't been deployed on ibiblio or any other Maven enabled repository. Has anyone thought about hosting a repository on commons? Maybe http://jakarta.apache.org/commons/repository? It would be nice to have a spot where we can put non Apache/non hosted jars that are needed in various projects without going through the hassle of trying to get it uploaded onto the main Maven repository. http://apache.org/dist/java-repository/ is the Apache repository. It's fairly new. As far as non-Apache jars, I don't think they are allowed to be hosted on ASF hardware. I'm not a politician, so hopefully someone else can step in to officially confirm or deny this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] betwixt support for derived interfaces
Wu, Chien-Hsing wrote: Can someone tell me how would I know if this patch is rejected or accepted? Your best bet would be to create a new Bugzilla item and attach your patch to it. Otherwise, as you've experienced, it is easy for patches to be missed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Size and scope issues
Stephen Colebourne wrote: Sometime, I think this is what many people looking at collections don't appreciate. Implementing the collection interfaces, especially the maps, can be really hard. You can say that again -- I think my head is still spinning from working on a BidiMap implementation during the pre-3.0 days. I find that type of low-level programming to be incredibly difficult. Because of keySet and entrySet, Maps can require you to implement 2 or 3 anonymous inner Iterators just to create a single implementation! And then to figure out what to do when someone invokes Iterator.remove()... ugh... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] MultiKeyMap
Michael Heuer wrote:
Might you also be able to use an unmutable MultiKey for storage in the
hashed map and a mutable MultiKey for lookups, with matching equals and
hashCode implementations?
void put(Obj a, Obj b, ...) {
map.put(new MultiKey(a, b, ..));
}
private MutableMultiKey lookupKey = new MutableMultiKey();
Object get(Obj a, Obj b, ...) {
lookupKey.setKeys(a, b, ..));
return map.get(lookupKey);
}
I have something that works this way lying around somewhere.
I'm not 100% sure, but I don't think this is thread safe, since multiple
threads may be calling the get method at the same time and thus
modifying the lookupKey instance var.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Shared build causes issues in releases
Stephen Colebourne wrote: The problem we face is that we must deliver a project's project.xml with the release because it contains the list of committers, contributers, and also the dependencies. If someone downloads a commons project and sees that project xml, then they might well expect to be able to use maven. This is not about releasing using maven. Its about users using maven. The simplest solution is to add a comment to the top of the project.xml that says - Maven not supported, please build using ant. Not nice, but better than nothing. What about including the commons-build directory with source releases? Maybe somebody has already suggested this... I forget. I just think that saying Maven not supported sounds a little harsh, when it's very easy to get the builds going. All they need is another directory. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Shared build causes issues in releases
Michael Davey wrote: Could something clever be done - perhaps if the project.xml file contained a default maven target that tested to see if commons-build is where project.xml expects and goes and fetches it if not? If the fetch fails (perhaps the user is not online), then print a useful user message? It's an interesting idea, but for all of the magic involved in this scenario I think it would be easier just to write a plugin. If the user is not online, the Maven or Ant builds aren't going to work anyway, unless all of the dependencies are already downloaded. It seems that the issue here can be interpreted as a simple dependency problem. All commons projects now depend on commons-build, and we all have ideas about how to manage this. I know that Mark has said before that he didn't want to make it a plugin, but due to the current complications, it may be worth another thought. Why invent a solution to use with Maven, or abandon Maven for source distros, instead of using one of the things that Maven does best, dependency handling? It could eliminate some work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] @author and @version
Simon Kitching wrote: What benefit is there in having this info in the source? I can't currently see any: * Developers can just use cvs status. * End users just care that the file came from version 2.1. * Maybe it is useful info when working with source snapshots, but that isn't very common. What am I missing? I think it's a convenience to be able to see when the last change was made, and who made it, in the source file -- instead of doing 'cvs status'. But that's about it. However, with the recent craze over @author tags, maybe we shouldn't even be using $Id$ anymore, since it contains the committer's username. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Shared build causes issues in releases
Stephen Colebourne wrote: Our maven scripts now depend on commons-build, however this is of course not included in the release zips. This is a problem and means that maven cannot be used in releases. How is this any different that before, when the Maven scripts depended on jakarta-commons/project.xml? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Serializable decorators
Stephen Colebourne wrote: 1) Make all decorators implement serializable, but some will fail at runtime if you decorate a non-serializable instance. 2) Implement serializable subclasses of each decorator, and use the factory method to create either the serializable or non-serializable subclass as required. #1 is easy, #2 will take much longer. Any views? #1 is the default choice. I like #1 also. It just seems easier. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Matthew Inger as Commons committer
Stephen Colebourne wrote: This vote is still outstanding. Any souls willing to +1 ;-) [ x ] +1 Let him commit [ ] +0 Not bothered [ ] -1 Perhaps not, because - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] current and future status?
Corey Jewett wrote: Jelly is foundational to maven (maven.apache.org). Maven seems to be rapidly replacing ant as the build tool of choice. So I think it's fair to assume that Jelly has a long life ahead of it. I've seen some indications that Maven will be moving away from Jelly as the plugin language. There have been some talks about using Beanshell instead. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote][all] migrate top level commons site to mavenized version.
Mark R. Diggory wrote: All, We'd like to have a vote to verify everyone is in agreement to push the commons-mavenized site over to replace the existing commons top level site. Please look over the mavenized site and vote appropriately. (Note: many of the links do return to the main site, these will map to the appropriate mavenized content once the move is accomplished and the URI's match up.) http://jakarta.apache.org/commons-mavenized [x] +1 yes, and I'll help [ ] +0 yes, go for it, but I'll just watch. [ ] -1 no way, you've got more work before you can do this. Looks good. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] @author tag tidyup
Gary Gregory wrote: I'd actually prefer to just get rid of the @author line entirely. If we're going to keep it, though, the link should really point at something useful, like perhaps the home page of the Digester website. For projects that choose to follow the Board recommendation of not using personal @author tags, it would be nice to have a consistent format across Jakarta. For codec, we now use: * @author Apache Software Foundation I am not sure why this string and not something project specific with an href. If the @author tag doesn't refer to an individual, I think the easiest bet would be to just remove them. @author Apache Software Foundation -- this is restating the obvious. Unless incubator projects would refer to the original author, and not Apache? In that case, it may make sense. (example) @author Jakarta Commons Codec Team -- also very redundant. Who else would have written it? Anyone who commits or submits patches to the project already knows who the official author is, and also the individuals who actually wrote the code behind the scenes. So, the target audience for these new @author tags seems to be people who are unfamiliar with Jakarta Commons. Now, seeing as though these people will probably be viewing the JavaDoc at: http://jakarta.apache.org/commons/codec/apidocs Isn't it redundant to include an href to: http://jakarta.apache.org/commons/codec in each file? I say let's get rid of the @author tags and save ourselves some work. I may be misunderstanding some political issues here, maybe? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] runtime version info
Noel J. Bergman wrote: This class implements the upcoming standard of having org.apache.project-name.Version.getVersion() be a standard way to get version information. That's news to me. I suspect it is news to most. As far as I know, it may be someone's strawman and/or wishful thinking, but this is the first I have heard about it. Isn't this sort of thing supposed to be handled by manifest files? I might be oversimplifying. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript validateUtilities.js validateByte.js validateCreditCard.js validateDate.js validateEmail.js validateFloat.js validateFloatRange.js validateIntRange.js validateInteger.js validateMask.js validateMaxLength.js validateMinLength.js validateRequired.js validateShort.js
[EMAIL PROTECTED] wrote: I realized that after making this patch that there is a DOM javascript call called getAttribute() that will probably work better than what I created. What I have will be succeptable to attribute hiding by an html element named 'attributes' which I am sure exists in somebody's ActionForm. I don't think getAttribute works in IE though. From what I've seen, it works in Mozilla, but in IE you have to use the element.attribute format. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
thoughts on subversion (was - Re: xdocs/ missing?)
Mark R. Diggory wrote: What are our thoughts on migrating to subversion? I've not even had time to try it out myself. Though I have it on my list. I've been using it at work for about 6 months and I like it a lot. Being able to easily move and rename directories and files is very cool. They seemed to focus on fixing CVS' weaknesses and it looks like they did a good job. It took about a day to get used to, and from then on it felt natural. I recently switched my home server over to Subversion and had some problems getting the integration with Apache2 working, but it didn't really matter since I prefer the svn+ssh method anyway. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] test server
Mario Ivankovits wrote: Nice idea, fore sure. But the protocols arent that simple. You could not simply present some captured protocol snipplets. And even if you manage to do so, the test should simulate the real life and therefore it should run against the real server. E.g. if there is a new webdav module for apache, we would like to simply replace it and run the tests again to see if everyting works fine. Even if VFS itself could not made be responsible if such a test fail, it could help the other projects to debug such situation. Maybe we could use well-known download servers to test HTTP and FTP stuff, such as ibiblio or freshrpms.net? The tests could download something like README.txt from a linux distro folder or something. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] test server
Beside this: my base question was where is the maintainer of VFS? i have a couple of patches added to bugzilla which needs discussion too - and hopefully get committed sometimes. The maintainer is this Community. I haven't been paying too much attention, but it seems that there is continued interest in VFS lately. Several of the folks participating in the discussion are Committers. Hopefully, some of the Committers have interest in at least reviewing and applying your patches. Let's see if we can find some Committers to review and apply your patches, and let you work into Committer status. If not, we'll cross that bridge when we come to it. I'd be more than willing to commit patches -- but the same problem remains that Gary stated originally. The test environment is difficult to set up, and we need an easier way. Mario -- perhaps you could write a small doc that explains what is needed to set up the test environment. If it isn't too complicated, I can attempt to set it up on my home machine (SuSe 9), then test and apply your patches. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] test server
Michael Davey wrote: I fiddle with it once in a while as we'd like to use it in our product. Understand that testing VFS properly is a pain as one needs to set up a WWW server, FTP server, etc. Perhaps we could investigate the possibility of having a VFS test server set up permanently - that way users could run the tests using their own builds against the test server. I guess it wouldn't have to be a powerful server. If the entire disk image was no more than 600MB, we could even burn a backup to CD and get the system to rebuild itself periodically to address security concerns. Even an internal server that committers could test against would be a good start, if the security issues made it impossible to host a public server. Publicly exposing something like that for testing might be too large of a task anyway. There are probably quite a few projects (fileupload, net) that would benefit from it. The problem with these types of things is the variations in OS, FTP servers, HTTP servers, etc. It's impossible to test all of them and that's where the users are incredibly valuable. But, even if we could say we're going to test with Apache 2.0 and some version of say, wu-ftpd, we could at least have a simple setup to ensure that things work. * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jeremias Maerki as Commons committer
Henri Yandell wrote: Screwup of mine in asking for a vote to promote Commons-IO was that I should have asked for a vote to add Jeremias to the Commons repository as he has done a large share of the work on IO. Jeremias is a committer from xml-fop and xml-commons. [ x ] +1 [ ] -1 Jeremias applied my patches to [io] before I had commit rights, so I'm a bit biased here ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error when using commons ReflectionToStringBuilder
White, Joshua A (HTSC, CASD) wrote: I receive the following error: java.lang.NoSuchMethodError: org.apache.commons.lang.builder.ToStringBuilder.getObject()Ljava/lang/Object ; at org.apache.commons.lang.builder.ReflectionToStringBuilder.toString(Reflectio nToStringBuilder.java:515) at org.apache.commons.lang.builder.ReflectionToStringBuilder.toString(Reflectio nToStringBuilder.java:265) at org.apache.commons.lang.builder.ReflectionToStringBuilder.toString(Reflectio nToStringBuilder.java:171) at donotcall.TestObject.toString(TestObject.java:17) at donotcall.TestIt.main(TestIt.java:20) Exception in thread main Process terminated with exit code 1 Am I calling this correctly? This is definitely a question for the user list, not the dev list. Are you sure that you have only 1 version of [lang] in your classpath? This looks like a versioning issue maybe? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] CharUtils.isAscii methods and CharSet, two issues
Todd V. Jonker wrote: As is stands, isAsciiAlphaUpper follows DoTheSimplestThingThatCouldPossiblyWork but (perhaps) breaks OnceAndOnlyOnce. Still, I think the existing code is better. Such things tend to be called inside tight inner loops, and as such every bytecode counts. Your suggested rewrite adds no functional improvement while increasing the execution time manyfold. I strongly suggest leaving it as-is. I think that running some performance tests would provide the best insight into possible effects on execution time. Gary, maybe you could write a small test to see if this change truly would cause a performance problem? There are lots of good changes that don't add any functional improvement at the machine level, but a more OO solution may very well improve things at the maintenance and class heirarchy level. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] CharUtils.isAscii methods and CharSet, two issues
Stephen Colebourne wrote: There is a second task that [lang] had which has been lost over time by various changes that people have made. That is that [lang] should be a repository of code that people can cut and paste to their own code. This may scare some, but it is actually quite sensible. Not eveyone wants to pull in the entire [lang] library when they only want a couple of functions. (I fully understand there are many ramifications of cut and paste, but it was IMHO part of the intent of [lang]). I've done the cut-and-paste quite a few times actually. Using Maven makes including new libraries easy, but when I'm on a project that is strictly Ant I'll cut and paste maybe 5 or so methods before including the jar. I also believe [lang] is simple enough that, even if there are quite a few intra-class dependencies, it wouldn't make the cutting and pasting that much harder. When I've had to include extra classes I just make them package private. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for the Commons Sandbox
David Gilliland wrote: I have recently started a project in the Java Foundry on Sourceforge called Jestr, and it seems like it might be a natural fit for the Jakarta Commons project. You can read about it here: http://jestr.sourceforge.net The project uses many Jakarta Commons components and is released under the Apache Software License. Jestr is still Beta software and I would not recommend it for promotion to the Commons proper at this point (besides, it depends on the Functor component which is currently sandboxed), but I'd like to offer it for inclusion in the Commons Sandbox. I just wanted to gauge whether there was any interest in accepting it here. If so, I would of course rename the root package from jestr to org.apache.commons.jestr, or perhaps org.apache.commons.stringify. Other than that there would be little to change, since Jestr uses the standard Jakarta Commons build and directory structure (I cannibalized the Functor component's build.xml). At a glance, this looks interesting. I sometimes wish that there was a way to define and register things at runtime like toString()s, comparators, equals(), and converters without having to modify the actual class. So that instead of having to make an explicit call to your special toString(), it would just magically happen. But, I guess this is what AOP is for. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SANDBOX] policy question (was Re: [VFS][PATCH] make it compile)
Stefan Bodewig wrote: since I have karma for the sandbox, I could easily apply the patch myself. On the other hand I do not plan to get involved with VFS beyond making it compile right now, so it feel wrong to add myself to the status file and commit away. Should I commit it without adding myself to the status file or should I simply wait until the patch gets applied by one of the people listed there? I say go ahead and commit. Since this is a unique situation, adding yourself to the status file is probably still good practice, but not a necessity. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [All] License change
Henri Yandell wrote: Will start doing so tonight. I estimate more than 5 minutes :) relicence new licence.txt new notice.txt include notice in jar build each component cvs ci Can someone post the script used to change the licenses in source files? I think Stephen posted it originally. Better yet, could somebody just place it in their ~/public_html dir so it's easy for anyone to access? Also, is there a list somewhere of which commons components have been re-licensed? Maybe we could make a small HTML page somewhere. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll][all] A very brief poll on your usage of javascript.
Mark R. Diggory wrote: To satisfy our interest on an issue being discussed in [commons-build] please answer this question. Question: Do you disable javascript in your favorite browser? [ x ]No [ ]Yes But I do agree with David here. I'm usually able to avoid using javascript for this sort of thing by using XSLT to build sites. Things are dynamic in real-time, but each time you build they can include navigation or things from other files. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[repo] is sync from java-repository to ibiblio working?
I build a new version of commons-discovery the other day, and put it in apache.org/dist/java-repository, but I don't see it on ibiblio yet. I thought that there was an rsync every 4 hours... am I wrong? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discovery] tests fail under maven build
Henri Yandell wrote: Building under Maven on OS X gives me 1 Failure: * Testcase: testFindResources took 0.019 sec FAILED located 0 resources, failed to locate all 3 resources: testResource junit.framework.AssertionFailedError: located 0 resources, failed to locate all 3 resources: testResource at org.apache.commons.discovery.test.TestAll.testFindResources(TestAll.java:333) I thought I fixed this today... I'll take another look. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discovery] tests fail under maven build
Henri Yandell wrote: Building under Maven on OS X gives me 1 Failure: * Testcase: testFindResources took 0.019 sec FAILED located 0 resources, failed to locate all 3 resources: testResource junit.framework.AssertionFailedError: located 0 resources, failed to locate all 3 resources: testResource at org.apache.commons.discovery.test.TestAll.testFindResources(TestAll.java:333) I thought I fixed this today... I'll take another look. Can you confirm that you're using the current CVS HEAD? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] enum keyword in Java 1.5
If you haven't heard, the word 'enum' is a keyword in Java 1.5. This
causes some errors here and there.
Now that the 1.5 beta is out, should we be making an effort to remove
this word from our sources?
You can sedate the errors and only get warnings if you set:
maven.compile.source=1.4
maven.compile.target=1.4
But this may not be a good long term solution. Thoughts?
Example:
java:compile:
[echo] Compiling to
/home/matth/files/tech/appdev/projects/apache/jakarta-commons/discovery/target/classes
[javac] Compiling 40 source files to
/home/matth/files/tech/appdev/projects/apache/jakarta-commons/discovery/target/classes
/home/matth/files/tech/appdev/projects/apache/jakarta-commons/discovery/src/java/org/apache/commons/discovery/resource/DiscoverResources.java:153:
as of release 1.5, 'enum' is a keyword, and may not be used as an identifier
Enumeration enum =
JDKHooks.getJDKHooks().getResources(loader, resourceName);
^
/home/matth/files/tech/appdev/projects/apache/jakarta-commons/discovery/src/java/org/apache/commons/discovery/resource/DiscoverResources.java:154:
as of release 1.5, 'enum' is a keyword, and may not be used as an identifier
if (enum != null enum.hasMoreElements()) {
^
/home/matth/files/tech/appdev/projects/apache/jakarta-commons/discovery/src/java/org/apache/commons/discovery/resource/DiscoverResources.java:154:
as of release 1.5, 'enum' is a keyword, and may not be used as an identifier
if (enum != null enum.hasMoreElements()) {
^
/home/matth/files/tech/appdev/projects/apache/jakarta-commons/discovery/src/java/org/apache/commons/discovery/resource/DiscoverResources.java:155:
as of release 1.5, 'enum' is a keyword, and may not be used as an identifier
return enum;
^
4 errors
BUILD FAILED
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] [proposal] NotImplementedException with a Throwable cause
Alban Peignier wrote:
I used before a private NotYetImplementedException. I'm refactoring my
code to use the lang.NotImplementedException. One of my previous use
cases is no longer possible :
try {
...
} catch (... e) {
throw new NotImplentedException(... case description ..., e);
}
Does this usage seem useful for most of people ?
While I can't say that I would use it in the same way, I can see your
point here -- the
exception is thrown to indicate a portion of code that hasn't been
written yet. I find myself
stubbing things out in a similar way very frequently.
Any [lang] folks have a problem with this being added?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: new HashedSet + WeakHashedSet classes
Henry Story wrote: I have now finished the two new classes HashedSet and WeakHashedSet. I have added some tests for them, though I should add a lot more. To make this work I needed to make a few changes to AbstractHashedMap. These changes had a few repercussions on other classes. But they now run all the tests successfully. They classes with UML diagrams and some explanations are available on my web site at: http://bblfish.net/java/collections/ You don't need to cross post. Since your talking about new classes and submitting patches, this discussion probably belongs on the developer list, not the user list. And Stephen is subscribed to the list, so you shouldn't need to email him directly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
