This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-04-02/commons-jelly-tags-html.html
Buildfile: build.xml
init:
[mkdir] Created dir:
Hi all,
I recently posted this message to a thread in commons-user, but I didn't get
any response. As the content seems more apropriate in this list and I'd be
really interested in comments I hereby pick the thread up again.
In summary the discussion is about how XMLOutput should consume text
Hi Jeffrey,
I made a bit of rework on the telnet client patch in order to
(partially) solve the problems you saw.
- The Apache license has been added to all sources
- I tried to improve compliance with the coding style
standards (I'm still not able to run maven, so I can't see
the reports...)
-
bayard 2003/04/02 08:28:15
Added: lang/src/java/org/apache/commons/lang/math RandomUtils.java
Log:
A Utils class that wraps java.lang.Math.random() and offers up methods
similar to that found on the java.util.Random class. Effectively this class
contains the methods that
Hello All,
What is the status of Sandbox-Commons-Codec?
I see in the current HTTPClient (2.0 Alpha) Javadoc that Codec will be used
in HTTPC 2.1. Is Codec stable? I am looking for a Base64 implementation and
an API change in a deeply buried Xerces base64 impl is making me look for a
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18617.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Let's say it's stabilizing. The code there is also slated for 2.0 of
Apache XML-RPC. We have been the most recent project to work on that
code, but are coordinating with the HttpClient team on agreeing on the
API. The API is probably not stable as of now, but I'd love to see your
ideas on
I'm aiming to restructure the Collections API a bit. Basically an
annoyance at things like:
SequencedHashMap, when the Hash part of it shouldn't be there. Ditto for
MultiHashMap etc etc.
I've one question I'd like to air-out first though:
ProxyMap has a constructor which takes a Map. It uses
The Java collections all use your number 1 approach. I believe it would be
very confusing for users if commons-collections behaved differently. An
example of the Java collections wrapping technique is
Collections.synchronizedMap(Map). Using this technique would be familiar
and easy to
Howdy,
I'd like to standardise this as either something we obey, or don't
obey.
Personally I've never liked it and not obeyed it, as a putAll or addAll
method easily handles this functionality. Usually the Collections
project
has obeyed it however, as it is an unwritten part of the specification
That's fine.
So ProxyMap is special, all ProxyMap implementations should be
package-private and available through a MapUtils class and can have
constructors which take a collection as copy-by-reference as it's not a
public API?
So, SequencedHashMap would be deprecated and removed, and
An alternative approach to using MapUtils.sequencedMap(Map) and similar
methods in ListUtils, etc. would be to group those wrapping methods in
CollectionUtils. That would be similar to how Java groups the wrapping in
the Collections class. Either placement is fine with me.
David
From:
At what point is a Utils class considered to have too many inner classes?
For example, does no one else find the 1200 line MapUtils quite painful? :)
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
Moving those inner classes into package scoped classes would be good.
David
From: Henri Yandell [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List
[EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Subject: [collections] XxxUtils inner classes
Date: Wed, 2 Apr
Hi,
Personally: at 1. I dislike inner classes ;)
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 02, 2003 12:37 PM
To: Jakarta Commons Developers List
Subject: [collections] XxxUtils inner classes
At
Hi ,
Attached is a tag I created for this purpose sometime ago (pre execption
handling change), so may or may not work with latest CVS but may be of some
use ..
Don't ask why it's called elephant :)
j:jelly
xmlns:e=jelly:org.apache.commons.jelly.tags.elephant.ElephantTagLibrary
e:xmlOutput
I seem to be asking lots of questions to the ether today :)
When are we going to remove the deprecated classes?
Do they go on the next major release? So for things deprecated at 2.1, we
would keep them for 2.2, but remove for 3.0?
Hen
From a first-scan, it looks like the following classes still need to
deprecate and hide behind MapUtils:
SequencedHashMap
ReferenceMap
MultiHashMap
LRUMap [extends SequencedHashMap]
none of these really seem to need to implement or extend HashMap [but I
could be missing subtleties].
Hen
On
So do we move to a structure in which each Utils class has its own
package?
org.apache.commons.collections.CollectionsUtils, which also contains
Collection implementations and Collection features [the package-scoped
classes which hide inside CollectionUtils].
I prefer not to have subpackages in commons components,
It is better to propose a new experimental componet or move it as top level
project if it grows too mutch.
- Original Message -
From: Henri Yandell [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent:
Howdy,
I actually disagree with Mr. Baliuka on this one, which doesn't happen
often ;) I like the suggestion of bag, map, etc. subpackages. But I
don't see it as essential. If need be, all the collections can stay in
the org.apache.commons.collections package.
Yoav Shapira
Millennium
Howdy,
Either next major release, or three minor releases, whichever comes
sooner.
So something deprecated in 2.1 will be gone in 2.5 or 3.0, whichever
comes sooner.
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]
Sent:
Yet another option is to put the static creation methods on the class
itself:
Map fooMap = FooMap.createFooMapFor(sourceMap);
I find this much more natural than going through a separate static
utility class. The ostensible reason for the Java Collections API
putting the creation methods into
Base64, Hex, Soundex, and Metaphone are stable and ready for consumption.
The legacy Base64 implementation has been preserved in order to preserve
backwards compatibility for projects which currently depend upon codec 1.0.
http://jakarta.apache.org/commons/sandbox/codec/index.html
Tim
On of arguments is import declarations :
import org.apache.commons.collections.*;
import org.apache.commons.collections.bag.*;
import org.apache.commons.collections.functor.*;
.. more stuff ..
or better :
import org.apache.commons.collections.SomeClass1;
..
The Jakarta standard is that anything deprecated in a release can be removed
in the next release. So 2.1 deprecated items can be removed in 2.2.
http://maven.apache.org/development/deprecation.html
David
From: Henri Yandell [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List
[EMAIL
On Wed, 2 Apr 2003, Alex Chaffee / Purple Technology wrote:
Yet another option is to put the static creation methods on the class
itself:
Map fooMap = FooMap.createFooMapFor(sourceMap);
If the class itself is viewable, then this is fine. It seems the usual
view is to hide the
I expected people to be unhappy with having hundreds of classes in one
package, even if most were hidden.
I'm quite happy to deal with the spam though, so will scratch the
sub-package idea.
Hen
On Wed, 2 Apr 2003, David Graham wrote:
I see no problem with using just 1 package
Well, the java.lang and java.util packages have many classes in them. All
of the Java collections classes are in java.util not java.util.bag,
java.util.map, etc.
Number of classes is not the right benchmark for determining package size.
The cohesion of the classes in the package is.
David
I don't agree. It's all to do with stereotypes I think [not the
programming term, the real world term].
Given a group of things, that go beyond some size [ie) all Java classes
are Java classes, why not put them all in java.*], you immediately look
for stereotypes to break them down into
rdonkin 2003/04/02 11:03:34
Added: digester/src/java/org/apache/commons/digester
AbstractRulesImpl.java
Log:
Added new Rule implementation based on a pluggable regex implementation. Also test
case and a simple regex matching implementation
Revision
rdonkin 2003/04/02 11:03:44
Added: digester/src/java/org/apache/commons/digester
RegexMatcher.java
Log:
Added new Rule implementation based on a pluggable regex implementation. Also test
case and a simple regex matching implementation
Revision
rdonkin 2003/04/02 11:04:30
Added: digester/src/java/org/apache/commons/digester
RegexRules.java
Log:
Added new Rule implementation based on a pluggable regex implementation. Also test
case and a simple regex matching implementation
Revision Changes
rdonkin 2003/04/02 11:04:42
Added: digester/src/java/org/apache/commons/digester
SimpleRegexMatcher.java
Log:
Added new Rule implementation based on a pluggable regex implementation. Also test
case and a simple regex matching implementation
Revision
rdonkin 2003/04/02 11:04:58
Added: digester/src/test/org/apache/commons/digester
RegexRulesTestCase.java
Log:
Added new Rule implementation based on a pluggable regex implementation. Also test
case and a simple regex matching implementation
Revision
rdonkin 2003/04/02 11:05:12
Modified:digester build.xml
digester/src/java/org/apache/commons/digester package.html
Log:
Added new Rule implementation based on a pluggable regex implementation. Also test
case and a simple regex matching implementation
Revision
hi eric
did you miss my post?
http://marc.theaimsgroup.com/?l=jakarta-commons-devm=104922470020557w=2
(making a .betwixt file is pretty easy but i'm not sure that it'll do any
good.)
- robert
On Wednesday, April 2, 2003, at 07:50 PM, [EMAIL PROTECTED] wrote:
I recieved any feedback on
after bit of thought about some recent comments from user, i've committed
some code based around the idea of using regex's in a pattern matching
Rules implementation. in order to give flexibility, i've made the actual
regex matching implementation pluggable.
i was thinking about creating regex
Howdy,
Contributions are always welcome, and I'm glad to see you're
pre-resolved licensing issues, but aren't there already a ton of utils
that do stuff like this, e.g. castor?
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: Jonathan Corbin [mailto:[EMAIL PROTECTED]
i started a commons etiquette page on the wiki a little while ago which
contains some opinions on the promotion process:
http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaCommonsEtiquette
it might of some help a little further down the line.
- robert
On Wednesday, April 2, 2003, at 07:07
Actually the mistake was made by me not pushing hard enough for better named
static utility classes. My original proposal was:
FixedSizeCollections.fixedSizeList(list)
PredicatedCollections.predicatedCollection(coll)
SequencedCollections.sequencedMap(map)
etc.
The advantage with this scheme is
hi richard
i've cut a few commons releases and i'd be willing to volunteer to act as
release manager (if no one else wants to jump in).
if you want to cut it yourself then you might find the draft extended how
to release documentation (http://jakarta.apache.org/commons/releases/)
useful.
Package scoped classes should not be included in the javadoc because they
are implementation classes that you can't use or extend in the first place.
Javadoc should be geared towards a user of commons-collections, not an
extender or customizer who will be looking through the source anyways.
On Wed, Apr 02, 2003 at 03:10:51PM -0500, Shapira, Yoav wrote:
Howdy,
import org.apache.commons.collections.* good.
Import org.apache.commons.collections.[onlyTheClassYouNeed] is good.
Import .* is annoying and all the jakarta projects should have import
cleanups as part of their
Howdy,
I know there are two camps ;) I'm not really interested in pursuing
this debate though ;) It's kind of like the debate on including version
numbers in jar file names. Hence the IMHO in my remark and my not of
complaining that import scrubbing is not part of our standard
procedures.
I agree there are two camps. A decent way to compromise is to use explicit
imports unless there are n or more imports from a particular package.
I think more important than which style is used, is that the same style is
used consistently across a project. Doesn't Apache have any standard defined
Yep. Standard is:
Match the style of the source, unless it's expressly stated in the Sun
coding standard.
Restyling source is rude :)
Hen
On Wed, 2 Apr 2003, SPRINGER,IAN (HP-NewJersey,ex1) wrote:
I agree there are two camps. A decent way to compromise is to use explicit
imports unless
I wouldn't call that a standard.
I disagree that restyling is rude, particularly when the original author
might not still be the primary contributor to the class, or even a
contributor at all. Also, it's easy enough to use Jalop, IntelliJ, or
whatever to restyle code back to how you like it.
|
OK, fine, it looks like the debate is raging already, so I'll chime in:
On Wed, Apr 02, 2003 at 03:19:45PM -0500, Henri Yandell wrote:
Biggest pain for me was discovering a large codebase with a lot of
unfamiliar package names that were all .* imported. Made it quite hard to
have a clue what
On Wed, 2 Apr 2003, David Graham wrote:
Date: Wed, 02 Apr 2003 13:15:03 -0700
From: David Graham [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: RE: [collections] XxxUtils inner classes
Import .* is annoying and all the jakarta
My 2 cents ;)
1. Implicit is best while in major development (for code completion).
2. Explicit is best (by far) when code is stable.
3. Imports should be optimized (explicit) for any major or minor
release.
Anything spelled out (explicit) is much easier to comprehend than
something that is
Biggest problem there is CVS. It's a fault of CVS' probably, but it can be
quite painful to see diff's that are encumbered with restylings.
In the situation you describe, in which the primary contributor [or some
such designation] has changed, then a restyle sounds fine. I do think that
the
Howdy,
I agree with Senor Ross.
The use of Jalopy (my fav) or another tool allows each developer to use
whatever mechanism they see fit for their own use. But for releases, it
should definitely be explicit.
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: Kevin Ross
Wow. I was impressed at all the things I'd said, before I realised the
second half weren't mine. Damn.
It's always fun when this debate comes up :) I think one of the biggest
problems is the IDE. They do not separate the model and the view.
For example, I should be able to say:
Show me the
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Promotion is probably a good idea, but it should be without
backwards compatability code IMO. You imply that there is a
codec 1.0 release, but this cannot be as sandbox components
may not have releases...
On Wed, Apr 02, 2003 at 04:45:17PM -0500, Henri Yandell wrote:
It's always fun when this debate comes up :) I think one of the biggest
problems is the IDE. They do not separate the model and the view.
For example, I should be able to say:
Show me the source in this style, but do not
Ryan HoeggDoes anyone have an opinion on what they'd like to see in Codec
before a release? /Ryan Hoegg
FYI, our only requirement right now is for a Base64 class. We use three
different ones so far (don't ask).
Gary
-Original Message-
From: Ryan Hoegg [mailto:[EMAIL PROTECTED]
Sent:
In this particular case, why not release a clean commons-codec-1.0.jar
without the deprecated classes and a sandbox compatible
commons-codec-1.0-deprecated.jar (better name needed)? Isn't there a
precedent for this in other Jakarta projects?
Gary
-Original Message-
From: [EMAIL
I couldn't agree more with Craig. I have come across the exact
situation he describes, where there exists classes:
com.foo.a.ClassA
com.foo.a.Utils
org.bar.ClassB
and you have code:
// MyClass.java
package com.acme.c;
import com.foo.a.*;
import org.bar.b.*;
[...]
public void
btw, I grant that naming a class Utils is probably asking for
trouble. But this was way back when, before we realised how many
classes there were going to be out there ;) That being said, how many
classes are there named Document?
--- Neil O'Toole [EMAIL PROTECTED] wrote:
I couldn't agree more
Here are my pennies: We uses explicit imports as computed by Eclipse's
Organize Imports feature.
Before saving or committing a file, we (usually) all do a
CTRL-SHIT-O/Organize Imports and a CTRL-SHIFT-F/Format. (It would be nice if
this were done automatically when you save a file, someday
I apologize if anyone has already made this point, but...
If I'm writing code that uses a class called org.cavity.Thing...
import org.cavity.*
import org.apache.*
public class Test {
Thing t = new Thing();
}
But later on, if the class org.apache.Thing is created, the code will no
Hello,
It seems ponderous to write:
byte b1[] = Base64.encodeBase64(commArea);
byte b2[] = Base64.decodeBase64(commArea);
Why not simply:
byte b1[] = Base64.encode(commArea);
byte b2[] = Base64.decode(commArea);
After all the Base64 class will not have other ??codeBase* methods.
Gary
On Wed, 2 Apr 2003, Henri Yandell wrote:
That's fine.
So ProxyMap is special, all ProxyMap implementations should be
package-private and available through a MapUtils class and can have
constructors which take a collection as copy-by-reference as it's not a
public API?
-1 to making
On Wed, 2 Apr 2003, O'brien, Tim wrote:
I don't think it is a good policy to require backwards compatibility for
sandbox components, but I think we have a special case here since codec has
been in use for a sustained period of time.
Rarely is backwards compatiblity a bad thing.
- Rod
So I don't really mind if the vote goes the other way, but I thought
I'd respond, as nobody else seems to be starry-eyed...
My main complaint with explicit imports is that is cripples a *very*
handy IDE feature (auto-complete).
On Wed, Apr 02, 2003 at 06:49:35PM -0500, Gary Gregory wrote:
On Wed, Apr 02, 2003 at 06:52:26PM -0500, __matthewHawthorne wrote:
But later on, if the class org.apache.Thing is created, the code will no
longer compile, right?
Right.
Isn't this an untouchable reason for using explicit imports?
No; it's a reason for doing a full clean build and unit
No; it's a reason for doing a full clean build and unit test run
before checking in any changes.
This way whoever added org.apache.Thing, or updated the library that
added it, is responsible for not breaking everyone else's build.
In this case causing a compiler error is good; the error
Static encoding and decoding functions follow the pattern,
encodealgorithm, decodealgorithm. So is done to avoid a conflict with
the Encoder, Decoder, BinaryEncoder, and BinaryDecoder interfaces.
Tim O'Brien
-Original Message-
From: Gary Gregory [mailto:[EMAIL PROTECTED]
Alex,
Your points are all well taken and I can see things from your POV. It is
indeed a religious issue. I am not convinced though that a given style
should be adopted just to make life better for an IDE. After all, IDEs like
Eclipse are constantly evolving.
From my POV, there is so much junk
On Wed, 2 Apr 2003, Alex Chaffee / Purple Technology wrote:
Date: Wed, 2 Apr 2003 16:45:27 -0800
From: Alex Chaffee / Purple Technology [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED],
[EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL
On Wed, 2 Apr 2003, Rodney Waldhoff wrote:
On Wed, 2 Apr 2003, Henri Yandell wrote:
That's fine.
So ProxyMap is special, all ProxyMap implementations should be
package-private and available through a MapUtils class and can have
constructors which take a collection as
On Wed, 2 Apr 2003, __matthewHawthorne wrote:
I apologize if anyone has already made this point, but...
If I'm writing code that uses a class called org.cavity.Thing...
import org.cavity.*
import org.apache.*
public class Test {
Thing t = new Thing();
}
But later on, if the
Hi Oleg,
This all looks fine.
I'd guess Sergio Berna is right and the problem lies with the
WebLogic proxy plugin rather than with HttpClient.
Thanks,
Padraig
Kalnichevski, Oleg wrote:
Hi Padraig
I just checked the way HttpClient handles request content-length header
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18355.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Eeek! Sorry, I should have been more explicit that I am using an old
version here (old version at work, latest version at home). We had to
release our product something like two months ago (before the
HttpMultiClient merge) and went with a nightly HttpClient from around
that time. We're
Is there any progress on this problem (it was posted to the newsgroup back
in early Feb.). I'm running into the same situation where a POST with a
request body is made to an authorizing server. The initial POST fails for
401, the retry posts all the headers but doesn't appear to repost the
77 matches
Mail list logo
