Re: [Commons-Email] where are the nightlybuilds?
Craig McClanahan wrote: [snip] I'd be happy to add this to my nightly script, except that there is no build.xml file present. The [email] developers can have Maven generate one for them, by typing maven ant and then checking it in. Be aware, if you do this, that some variants of Maven generate absolute paths for some of the property settings in the generated build.xml file -- you might want to go through by hand and fix those before doing the checkin. Created bug 29995 for this: http://issues.apache.org/bugzilla/show_bug.cgi?id=29995 -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] JDK1.5
Rodney Waldhoff wrote: For the record, while I'm +0 on moving toward JDK 1.5 support within collections, I'm certainly -1 on abandoning JDK 1.4 support in the near future. Is there a simple way to get Ant to strip out the angle brackets from the source before invoking javac? I'd imagine that a JRE 1.5 specific version of collections could be a lot smaller and simpler so collections15 might be a good way to go. I think that there will be a lot of demand for the existing collections codebase for some time so I doubt it will be abandoned any time soon. -- Michael - 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: On Thu, 2004-06-10 at 21:39, Pete Gieser wrote: I may have missed it, but I wanted to mention that there exists a sourceforge project that may have some overlap. http://sourceforge.net/projects/junit-addons FWIW. Pete This is good stuff and pretty much in line with what I was thinking. There is a lot of overlap certainly. I actually saw this project several times before. Many of my utilities map closely to classes in this project. The Addons project admin inspired Bill Venners, who's writings later influenced me. There is also this, by Cedric Beust: http://www.beust.com/testng/ I think it makes sense to collect our own test related code first, then scour the rest of Apache for interesting stuff. Once we have done, that we can try to work with junit-addons and testng to integrate any stuff that is unique to commons-test; and see if either or both communities would like to come to Apache (if appropriate). -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: going with the site update Was: [site] main + sandbox site update
Henri Yandell wrote: [snip] The major change for the prepare page is that I switched it to Cc the PMC for a [RESULT] and not for a [VOTE]. I might be wrong here, but I think that's the intended practice. Looking at the PMC history, Commons are the only ones that Cc them on a vote. Everyone else does results. That means that it is now essential that the votes are summarized in the [RESULT] post (not just the outcome of the ballot), right? -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][collections] Solving binary incompatability
Simon Kitching wrote: On Thu, 2004-05-13 at 11:46, David Graham wrote: --- Stephen Colebourne [EMAIL PROTECTED] wrote: From: David Graham [EMAIL PROTECTED] If I understand correctly, incompatible changes were made to collections after 3.0 and the next planned release is 3.1. So, since you haven't released 3.1 yet, you can still go back and fix the incompatibilities. If only it was that easy :-) The incompatible change is between 2.1 and 3.0 - two released versions. The question is what to do about it. You're allowed to have incompatibilities between different major version numbers. A big problem with Collections is its overuse in other commons components which is in the process of being fixed. Clients don't have to migrate to 3.0 if they don't want so I don't see a problem. If there's demand you can always release bugfixes from the 2.1 series (ie. 2.1.1). For what it's worth, my opinion is that things are ok as they are. For what it is worth, I agree. It is valid to introduce binary incompatibilities for major releases. Ok, these ones weren't intentional, and could have been avoided. But projects that use commons libs should have a plan for migrating across major lib releases. Ok, it might slow the adoption of commons-collections 3.0, as projects wait for new releases of all the other commons libs they depend on so that none of the other libs require collections 2.1. But they'll get there eventually. If you really feel like releasing a 4.0, that would be a solution. But I'm not sure projects will be happy leaping from 2.1 to 4.0, so this may not speed up adoption of the new version anyway. I certainly don't think a 3.1 release which is incompatible with 3.0 is a good idea! After reading Simons comments, then re-reading Davids comments, I agree with David - if we were feeling generous, we would release 2.1.1 (or more likely 2.2) with as much of the new stuff from 3.0 as we can (without breaking compatibility) plus the 2.1-compatible IteratorUtils. It would also be nice to release a 3.0.1 with only documentation changes (to correctly document IteratorUtils) if another release of 3.x is not likely to be forthcoming any time soon. I'd hope that 3.0.1 would not require a lot of effort from the release manager. -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: validator: email-validation not accepting german umlaute
Sven Schliesing wrote: As for version 1.1.1 the Jakarta Commons-Validator is not accepting german umlaute as parts of valid domain names like müller.de or münchen.de Is this a known issue in validator or might this be a setting in Struts? Valid domain names must contain only the characters a-z, A-Z, 0-9, . and -. They must start with a letter and end with a letter or digit. The . symbol is used exclusively to seperate subdomains (see RFC 1035 section 2.3.1 http://www.ietf.org/rfc/rfc1035.txt). To support internationalised domain names (IDN), both the client and the server must be punycode aware. Punycode is a fairly new standards proposal (rfc3492) that encodes non-ascii characters into an ascii string, prefixed with xn--. For instance, müller.de is encoded as xn--mller-kva.de. http://www.faqs.org/rfcs/rfc3492.html http://www.afilias.info/cgi-bin/convert_punycode.cgi Commons-Validator would need to be made Punycode-aware to achieve what you need, or alternatively, you could do the punycode translation in your own code, before passing the string to validator. -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: validator: email-validation not accepting german umlaute
Sven Schliesing wrote:
I wrote a test to make sure where the problem is:
public class ValidatorTest extends TestCase {
public void testEmail() {
EmailValidator emailValidator = EmailValidator.getInstance();
boolean result = emailValidator.isValid([EMAIL PROTECTED]);
assertTrue(invalid email, result);
}
}
Runs with success. So the address [EMAIL PROTECTED] is validated by the
EmailValidator with success.
Seems that the problem is with struts. I also explicitly set the
charset in the struts-config:
controller contentType=text/html;charset=iso-8859-1
processorClass=org.apache.struts.action.RequestProcessor /
No change.
Any other ideas?
So, there are at least three things going on here:
1. The testcase above should fail in validator, but it doesn't because
the validation check isn't good enough.
2. validator doesn't support punycode and doesn't support the
quoted-printable unicode encoding mechanism used in email addresses.
3. The problem you describe in your emails.
[1] could be fixed easily enough. [2] could be fixed by enhancing
validator. Your testcase shows that the problem isn't with validator,
so [1] and [2] are not really of consequence to you right now, but they
have got my interest. After re-reading your original mail and your
latest mail together, I don't understand exactly what it is you are
trying to achieve - could you demonstrate with some code or describe how
you would demonstrate the problem to me?
If you are now fairly sure that the problem lies within Struts, it may
be beneficial to post to the struts mailing list and copy me personally.
Cheers,
--
Michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][site] Finally publishing top level site
Mark, The Jakarta logo is different to the one used on most of the sub-project sites. I seem to recall some recent discussion, but couldn't find the thread when I looked just now. -- Michael Mark R. Diggory wrote: Ok, I just wanted to give a heads up the latest maven (rc1) build of the top level site is up at: http://jakarta.apache.org/commons Please let us know if you see any major mistakes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Shared build causes issues in releases
matthew.hawthorne wrote: 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. 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? -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] [VFS] Where are the committers?
Hello, It looks as though the committers for VFS are currently busy working on other projects. I would like to propose that a vote is held to admit Mario Ivankovits as a Commons-Sandbox committer. Mario has been active on the developer list for over a year and has submitted patches for FTP and VFS. More recently, Mario has spent some time setting up a test server for VFS. http://www.mail-archive.com/[EMAIL PROTECTED]/msg38267.html http://issues.apache.org/bugzilla/show_bug.cgi?id=27776 http://www.mail-archive.com/[EMAIL PROTECTED]/msg38413.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg38412.html There has been increasing interest in the VFS project over the last few months, and it needs someone to be focusing on it. Mario has expressed an interest in moving VFS forward and, I believe, is ready. However, I am not a committer myself, so is there anyone who would be willing to sponsor this proposal and send out the appropriate VOTE email? -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] test server
Mario Ivankovits wrote: Well, i will start in installing the UML for testing on my machine. It might take some while, i will post here when i am ready. I will have a UMLinux test machine available in a couple of days. Please give me a shout if you want to test the image on another machine, or if you need any other help. Cheers, -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] test server
Mario Ivankovits wrote: What if we start by adding various configuration files to VFS to start up your own test-server. The configuration files should be based on: 1) Apache 2.0 (for http and webdav) 2) Samba 3.0 (for smb) 3) openssh 3.7 (for sftp) 4) vsftpd (for ftp) (well any other ftpd would do it too) (i've changed the bullet points to a numbered list) I'd prefer to see an independant test server set up, but lets take a look at this. For http, we could write a very simple class that provides an http listener thread and returns the appropriate test file when requested. I'm sure I have some sample code somewhere that does just this. How difficult would it be to do the same for 2, 3 and 4 (I don't know)? Then, the test classes could create the mini-servers during testing and destroy them afterwards. -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] test server
Mario Ivankovits wrote: matthew.hawthorne wrote: 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. Yes, this is something i thought too, but i think we need read/write access (create files, dirs, set last mod time, file attributes ...) So i think starting with configuration files to setup a local test system is a good idea, if we exactly know what we want, we could try to find a public vfs test server. But how public should/could this server be? Missuse as file-sharing point for some illegal material will be possible then. I'd go back to the point about the server being rebuilt every night. I think it would at least be worth asking Infrastructure about this - they probably have a very good idea about how difficult it would be to achieve what we want, and how long it might take to set up. -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VFS] test server (was: Re: [VFS] Maintainer)
Gary Gregory 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. -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] problem: nightly build distributions are empty
Craig, Try using the version of webdav from http://www.ibiblio.org/maven/slide/jars/webdavlib-1.0.16.jar or applying my patch sent to the -dev list on 6th March. Jacob, Hopefully one of the VFS developers will apply my patch soon ;) -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VFS][PATCH] fix broken get-deps and get ready for Java 1.5
Hi,
I encountered some problems while trying to use VFS for the first time.
Here is a patch:
* changed get-deps in build.xml to get slide-webdav from ibiblio.
The code in CVS will
no longer build with Ant against the version of webdav in lib/slide/jars.
* took the opportunity to rename enum identifiers so that the code
will now build under
Sun's Java 2 SDK 1.5.0-beta1.
* lib/slide can now be deleted from CVS. In fact, I think the whole
of lib can be deleted.
The changes were tested using Sun's SDK 1.4.2-b28 and Ant 1.5.3 with
targets , jar, test and
dist.
--
Michael
? lib-old
? patch
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-commons-sandbox/vfs/build.xml,v
retrieving revision 1.18
diff -u -r1.18 build.xml
--- build.xml 3 Jul 2003 10:13:35 - 1.18
+++ build.xml 6 Mar 2004 18:39:42 -
@@ -190,7 +190,7 @@
/get
get dest=${libdir}/jcifs-0.7.8.jar usetimestamp=true ignoreerrors=true
src=http://www.ibiblio.org/maven/jcifs/jars/jcifs-0.7.8.jar;
/get
-get dest=${libdir}/webdavlib-20030224.jar usetimestamp=true
ignoreerrors=true src=file://${basedir}/lib/slide/jars/webdavlib-20030224.jar
+get dest=${libdir}/webdavlib-1.0.16.jar usetimestamp=true
ignoreerrors=true src=http://www.ibiblio.org/maven/slide/jars/webdavlib-1.0.16.jar;
/get
get dest=${libdir}/commons-httpclient-2.0-beta1.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/commons-httpclient/jars/commons-httpclient-2.0-beta1.jar;
/get
@@ -199,4 +199,4 @@
get dest=${libdir}/xml-apis-1.0.b2.jar usetimestamp=true ignoreerrors=true
src=http://www.ibiblio.org/maven/xml-apis/jars/xml-apis-1.0.b2.jar;
/get
/target
-/project
\ No newline at end of file
+/project
Index: src/java/org/apache/commons/vfs/provider/webdav/WebdavFileObject.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/provider/webdav/WebdavFileObject.java,v
retrieving revision 1.12
diff -u -r1.12 WebdavFileObject.java
--- src/java/org/apache/commons/vfs/provider/webdav/WebdavFileObject.java 3 Mar
2004 07:05:35 - 1.12
+++ src/java/org/apache/commons/vfs/provider/webdav/WebdavFileObject.java 6 Mar
2004 18:39:42 -
@@ -87,9 +87,9 @@
// Resource exists if we can do a GET on it
boolean exists = false;
-for ( Enumeration enum = optionsMethod.getAllowedMethods();
enum.hasMoreElements(); )
+for ( Enumeration methodsEnum = optionsMethod.getAllowedMethods();
methodsEnum.hasMoreElements(); )
{
-final String method = (String)enum.nextElement();
+final String method = (String)methodsEnum.nextElement();
if ( method.equals( GET ) )
{
exists = true;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Book time - Pro Jakarta Commons
robert burrell donkin wrote: [snip] i think that links to new books and articles on jakarta is useful but tacit endorsements of particular products is a little bit of a sensitive subject. How about a simple disclaimer. Something like: The following links are provided as a community resource. The information provided does not necessarily reflect the views of the community or any individual. While The Apache Software Foundation may officially endorse or promote some of the information linked to from this page, a link from this page, in itself, should not be cosidered official endorsement or promotion. To add a link, please email [EMAIL PROTECTED] -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] [jjar] build.xml
Hello,
Here is a trivial patch for JJAR to fix build.xml in light of recent
license changes.
--
Michael
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-commons-sandbox/jjar/build.xml,v
retrieving revision 1.5
diff -u -u -r1.5 build.xml
--- build.xml 26 Aug 2001 16:21:40 - 1.5
+++ build.xml 1 Mar 2004 21:16:00 -
@@ -169,7 +169,7 @@
target name=dist depends=compile,javadoc
description=Create binary distribution
mkdir dir=${dist.home}/
-copy file=LICENSE
+copy file=LICENSE.txt
todir=${dist.home}/
!-- make a complete jar w/ the MinML2 SAX stuff --
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[all] LICENSE vs LICENSE.txt (was: [GUMP@lsd]: jakarta-commons-sandbox/commons-jjar failed)
Gump 'bot (pretending to be Ted Husted) wrote: [snip] Project commons-jjar has an issue affecting it's community integration. The current state is 'Failed', for reason 'Build Failed' [snip] BUILD FAILED /data3/gump/jakarta-commons-sandbox/jjar/build.xml:173: Warning: Could not find file /data3/gump/jakarta-commons-sandbox/jjar/LICENSE to copy. I thought that the idea was that the prefered name is without an extension: quote href=http://apache.org/dev/apply-license.html; *Can the LICENSE and NOTICE files be called LICENSE.txt and NOTICE.txt?* This is permitted. However the preference is that the files be called LICENSE and NOTICE. /quote -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[email] Re: commons e-mail
Joe Germuska wrote: It seems to be languishing, but I don't think it really needs much besides active developers. It could certainly go to the Commons proper as a beta package, where it might get more visibility and more people willing to flush out any remaining bugs. I'd be happy to help out. I couldn't find a todo list, just those two open bugs. It would be great if one of the committers could outline the things needed to get email from here to an initial release. I have an in-development feature for Gump that could use this project. I also recently posted an email to this list regarding the supporting classes for the EmailTask in Ant. Perhaps some of that code could be 'reused' :) . -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[email] SimpleEmail
Hi, Ant has a MailMessage class that can be used like this: // % MailMessage msg = new MailMessage(mailhost, mailport); msg.from(Ant Mail Message [EMAIL PROTECTED]); msg.to([EMAIL PROTECTED]); msg.setSubject(Test subject); PrintStream out = msg.getPrintStream(); out.println( test message line 1 ); out.println( test message line 2 ); msg.sendAndClose(); // % The important bit here is the out.println(). Perhaps something could be added to SimpleEmail to allow the message body to be built up line by line. Either a getPrintStream() method or perhaps an addMsg() method? Also, I feel that there is scope within commons-email for a mail class that doesn't use JavaMail and performs a best-efforts mail delivery. Indeed, this is pretty much what Ant's MailMessage class does. -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH][betwixt] CustomerBean, PersonBean, AddressBean
Hi,
Here are three simple patches that change the contract of the
CustomerBean, PersonBean and AddressBean test classes in betwixt, so
that these beans can be compared in a sensible manner.
The patches change the toString() method and add equals() and hashCode()
methods so that any two CustomerBean, PersonBean or AddressBean
instances with the same data, are equivalent to each other.
I haven't touched LoopBean as changing it in this way would break the
cyclic loop test as it is currently implemented.
--
Michael
begin 644 compare.tar
M061DF5ST)E86XN:F%V82QP871C:#$N,0
M
M # Q,# V-#0 ,#(T-C8U,P P,# P,#$W # P,# P,# R-C,S
M # W-38V,# R,3(W # P,38U,S4 ,
M
M !UW1A@ P,UI8VAA
M960 =5C:EEP
M P,# P,C$P # P,# P,#
M
M
M
M !);F1E#H@:F%K87)T82UC;VUM;VYS+V)E='=I
M'0N:5A9]SF,O=5S=]OFO87!A8VAE+V-O;6UO;G,O8F5T=VEX=]!
M91R97-S0F5A;BYJ879ACT]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T*4D-3(9I
M;4Z(]H;VUE+V-VW!U8FQI8R]J86MAG1A+6-O;6UO;G,O8F5T=VEX=]S
MF,O=5S=]OFO87!A8VAE+V-O;6UO;G,O8F5T=VEX=]!91R97-S0F5A
M;BYJ879A+'8*F5TFEE=FEN9R!R979IVEO;B Q+C$*9EF9B M=2 MC$N
M,2!!91R97-S0F5A;BYJ879ABTM+2!J86MAG1A+6-O;6UO;G,O8F5T=VEX
M=YH96%D+W-R8R]T97-T+V]R9R]A%C:4O8V]M;6]NR]B971W:7AT+T%D
M9')EW-96%N+FIA=F$),3 @2G5N(#(P,#(@,3Z-3,Z,S(@+3 P,# ),2XQ
MBLK*R!J86MAG1A+6-O;6UO;G,O8F5T=VEX=YH96%D+W-R8R]T97-T+V]R
M9R]A%C:4O8V]M;6]NR]B971W:7AT+T%D9')EW-96%N+FIA=F$),3@
M3F]V(#(P,#(@,C$Z,#,Z,3$@+3 P,# *0$ @+38V+#8@*S8V+#@0$ *(\J
M*B \#X\8V]D93Y#=7-T;VUED)E86X\+V-O94^(ES($@V%MQE()E
M86X@9F]R('5S92!B2!T:4@=5S=!C87-ERX\+W ^B @(H*( @*B!
M875T:]R(#QA(AR968](FUA:6QT;SIJW1R86-H86Y 87!A8VAE+F]R9R(^
M2F%M97,@4W1R86-H86X\+V$^BL@(H@0%U=AOB \82!HF5F/2)M86EL
M=\Z;6EC:%E;YD879E4!C;V1EF%G92YOFB/DUI8VAA96P@1%V97D\
M+V$^B @(H@0'9EG-I;VX@)%)E=FES:6]N.B Q+C0@) H@( J+PH@'5B
M;EC(-L87-S($%D9')EW-96%N(EMQE;65N=',@4V5R:6%L:7IA8FQE
M('L*0$ @+3$Q,2PV(LQ,3(L,38@0$ *( @(!]B @( @B @( @'5B
M;EC(%-TFEN9R!T;U-TFEN9R@I('L*+2 @( @( @F5T=7)N('-U5R
M+G1O4W1R:6YG*D@*R B6W-TF5E=#TB(L@W1R965T(L@(BP@8VET3TB
M(L@8VET2L@(BQC;W5N=')Y/2(@*R!C;W5N=')Y(L@(ETB.PHK( @( @
M(!R971UFX@(ELB(L@=AIRYG971#;%SR@I+F=E=$YA;64H*2 K((Z
M('-TF5E=#TB(L@W1R965T(L@(BP@8VET3TBBL@( @( @( @( @
M( @*R!C:71Y*R B+!C;W5N=')Y/2(@*R!C;W5N=')Y(L@(ETB.PHK( @
M('T**R @( **R @(!P=6)L:6,@8F]O;5A;B!E75A;',H($]B:F5C=!O
M8FH@*2E='5R;B!T:ES+FAAVA#;V1E*D@/3T@;V)J+FAA
MVA#;V1E*D[BL@( @?0HK( @( HK( @('!U8FQI8R!I;G0@:%S:$-O
M94H*2![BL@( @( @(')E='5R;B!T;U-TFEN9R@I+FAAVA#;V1E*D[
MB @( @?0H@?0H*
M
M !#=7-T;VUED)E86XN:F%V82QP871C
M:#$N-0
M,#$P,#8T- P,C0V
M-C4S # P,# P,3 ,# P,# P,#(V-3$ ,#U-C8P,#(S-C ,# Q-CU- P
M
M
M '5S=%R # P;6EC:%E9
M !T96-H:65S # P,# R,3
M,# P,# P,
M
M
M $EN95X
M.B!J86MAG1A+6-O;6UO;G,O8F5T=VEX=YH96%D+W-R8R]T97-T+V]R9R]A
M%C:4O8V]M;6]NR]B971W:7AT+T-UW1O;65R0F5A;BYJ879ACT]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T*4D-3(9I;4Z(]H;VUE+V-VW!U8FQI8R]J
M86MAG1A+6-O;6UO;G,O8F5T=VEX=]SF,O=5S=]OFO87!A8VAE+V-O
M;6UO;G,O8F5T=VEX=]#=7-T;VUED)E86XN:F%V82QVG)E=')I979I;F@
MF5V:7-I;VX@,2XUF1I9F8@+74@+7(Q+C4@0W5S=]M97)96%N+FIA=F$*
M+2TM(IA:V%R=$M8V]M;6]NR]B971W:7AT+FAE860OW)C+W1EW0O;W)G
M+V%P86-H92]C;VUM;VYS+V)E='=I'0O0W5S=]M97)96%N+FIA=F$)-R!.
M;W8@,C P,B Q-CHQ-3HP. M,# P, DQ+C4**RLK(IA:V%R=$M8V]M;6]N
MR]B971W:7AT+FAE860OW)C+W1EW0O;W)G+V%P86-H92]C;VUM;VYS+V)E
M='=I'0O0W5S=]M97)96%N+FIA=F$),3@3F]V(#(P,#(@,C$Z,#4Z-3D@
M+3 P,# *0$ @+3@R+#8@*S@R+#@0$ *(\J*B \#X\8V]D93Y#=7-T;VUE
MD)E86X\+V-O94^(ES($@V%MQE()E86X@9F]R('5S92!B2!T:4@
M=5S=!C87-ERX\+W ^B @(H*( @*B! 875T:]R(#QA(AR968](FUA
M:6QT;SIJW1R86-H86Y 87!A8VAE+F]R9R(^2F%M97,@4W1R86-H86X\+V$^
MBL@(H@0%U=AOB \82!HF5F/2)M86EL=\Z;6EC:%E;YD879E4!C
M;V1EF%G92YOFB/DUI8VAA96P@1%V97D\+V$^B @(H@0'9EG-I;VX@
M)%)E=FES:6]N.B Q+C$P(0*( @*B\*('!U8FQI8R!C;%SR!#=7-T;VUE
Re: [general] proposal and status documents
robert burrell donkin wrote: i don't know if it's what you're looking for... ...but jakarta-commons-sandbox/proposal is a template jakarta-commons component. Yup, that is almost exactly what I was looking for. Thanks! -- Michael smime.p7s Description: S/MIME Cryptographic Signature
[general] proposal and status documents
Hi, Is there a template for status and proposal documents? It looks like there is a common layout but I couldn't find a template. I've looked on the jakarta web site and in CVS. Cheers, -- Michael -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
[digester] article (Re: [DRAFT1] Jakarta Newsletter - October 2002)
Henri, David Karr pointed out that there is also a Digester article on JavaWorld. I notice it didn't make it onto the Digester web site either ;) Here is the URL: http://www.javaworld.com/javaworld/jw-10-2002/jw-1025-opensourceprofile.html -- Michael smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH][betwixt] XML files and XMLIntrospector
Robert, Okay, I've just refreshed my CVS view and sure enough the testcase passes. May I suggest that you ditch the ElementDescriptor patch (or comment out the changes) but keep the test patches, for regression purposes? There wasn't very many changes between my previous CVS snapshot (a couple of weeks ago) and tonight's' refresh - the reason for the changed behavior is opaque to me :( -- Michael robert burrell donkin wrote: [snip] On Wednesday, October 30, 2002, at 10:24 PM, Michael Davey wrote: i'm on macOSX. i have a feeling that it's the smime that's confusing my email client. the good news is that i managed to construct a reasonable version from the mailing list archives. the problem is that i don't seem to be able to make it fail. this could be because i stuffed up the test case in the extraction process but it could also be that this bug has been fixed sometime. could you retest against CVS HEAD or a recent nightly? [snip] smime.p7s Description: S/MIME Cryptographic Signature
[PATCH][betwixt] XML files and XMLIntrospector
Robert, Here is the patch again, this time as a uuencoded gzipped tar file. Also, I have remembered to change the email subject line this time ;) Please let me know if you still have problems and I'll make sure to regenerate the the patch files from CVS head (sorry - it would be a hastle to do this tonight as my development machine is part way through an upgrade as I type). Also, please let me know if you are using win32 and I'll attempt to change the line endings to match your platform before creating the archive (they currently have Unix line endings). Here's hoping you shake that cold, -- Michael original message hi Michael sorry for taking so long to reply (i've managed to catch a cold). is there any chance that you could reposting your patches? the line endings in the you emailing got mangled. i gave trying to repair them a go but there's just too much to do. i don't know what went wrong last time but you might need to tar or jar them up. TIA - robert begin 644 patch18619.tar.gz M'XL(!%8P#T W!A=-H,3V,3DN=%R .U?7?:.-:??X=/H?73LX6=PAI M7B4D-:S62!M#MG9LY9!XOUMBL;9*RL_WN^^5;,M7IIDVNYYZM,FCB5= MW3?=^Y-DN5BJOQ4]DO-S_PC$PX'[0,GQG!K!)RO%*L_//HJ5\KE1KW^ M0[E:;S1V:S^4\:KLB=_EG5W%^[WX=YKU%K[/Z A;M[E1_*C^]Z\S7S \.# M+B?6QPV6] _'%O=7EI,DE7(HU)_!ZI]QZ8[)/QZP]\8'PPN,PM=3%S' M+]WPX-[Z)1\;U*P5*KG=;,J;,Q+BW667.]6=DCA]_97JM/AM9-C] MI;$[9[O_.GLQK:I2?G-W^7\7C6?S.FZ9![]\RW48^'_M$8C5IBQ=_ ML71IX7T^OPQVJ#_3RS614\BU4K!^7Z07F7%=]?D3=G9V_HQ.]UAW,A. M:P[]8-Z572:.3UEA;UROE)A._BKQDY/,\R:3%TO8.]GCA441YXQX?N]Z( M1/LS*^'195 F:*IFB9*8HF2E:;O$5-YQW'C3Q#C.%S,[F-A\G-O7:4WN M'WYV_I)[)5O(,RVY %6QH[[/1J['4(ML,_\8H8Q]H)^L%-C%HRA],A M8X^/CK6)8=F!_B(P-YU1R ,QH)S^#5GS6ET5'),DL[..RB4%([MX9MSQ M^6D+V.P9M[S8[;W63F09HS(B)1BZXQZY[+.=-X#\-XT;%I0P3(X9H9A MPD4?8/QCP!W39]#/\CLEIOL%V*I7]T.[A99BFQWV_Z/, TRK;.KL=QA M7.^NP$+8\6F:),-V/UG; 2C,.9YU!=^?23^5^3CT78G' 3=:]]1$(\; M ==AWOH0=DL!P10Q,3*7;,''[/8L-GU3Y#QG03^!^YKL;22?S*IW:3A M#2\I9()K)KB?Q0'6=LQ46TKQWNEZZBS/]MFT^X$YQQ?^A9T\#U(!0W0? M_)_;:^FY/\RY/TR!)]*]7O^_P+7%OD?L\*Z-++L.E\9 #R,X94(H)9 #6V M0MY-$.!A7/U8B2% Y5!O790+D0H+81 CRPTT4,4#NH[*L8H(ZY '[NR4SP M5$EQ+94)2DYIY,[\Z;H\ R(3U=Q#3ZP5WP2?,'46EM*K2*C+JDT2JF8 M=93',K'6:_F7D%CK]7QE-Y%894;AB_1\]A?(93/;9G_]:TIIT;.;3!F)ZP M)R)*GP7\B5G1Y1]%GSSJP1\:6'U)B8\-G1 #X68T ?EVY'M9$)\P3Z' M0#%N]9H'T3,XU*P6RP5T%S:'_G/ 8QLFD-I--N!0N54ZF6+OO-L9- M85RZ]U;/^IE(1I-UN7-=A -FU';)(R ?K(Q8=46Q](6BIXW0+,26F0 M!V?EJR=VH=B[[3RU18G!]NKPCC=J;P$Q%Z-'RLLHS5EJ)(+J\O4.LC4= MQ(#?#SA,'Q-PPP^*1R?-)BB=LW4D^;PE8'(^F09S9GB,4_U)-%']* M=Y\4*__Z^VKSY]$1M_.K52O6FAR8'D1*W[N7SQ'^$BY_ASWN]'088P/^ M*]J9)_C;UZI5:G]9]K5'_CO^^P'7T$TR)F4QPQUJE6-88=X:N2#H6+L MG!=:NRGD\R1Y8QF'M9$RNP[CC.A/QC+?)##5/E43AR',CLQYH#SD3/H20 MGJ(,09TF=NP1_/M-**:%TH[HU#3/^,B8V9!Z-E12?8(_)60P9-O;X+U MC5^)\4_[^G[6#_^J]56[_:I7:7H7?WUOM_%]_'^!JP30'5-I]O]R+/8! M%D/=9XRF 87RRT+E9891]28VATCG0$D[B;-%C?'07WAL?9A37DCL_S[*T$ MW95B17;;J=SS[H=!RP[S%7Y50*Y^[,,8T VA89:T)I#8^4OXS[T[;A8E MQ1XW(8%2R,N#$B;,\+,*GPW9DWY/3DQG(,;XY88*(\MXI 7 7^[LPI M3!:CJPA=9EGR,*4Q G8UJZKEWEDWP=(*F,7-MV[W..70=T\)Q!NV M ]!S(%FK%!X\YD[MD:XJK6!%P7D9%A20ATX]YAD502V94A-Y6TL1$N M )FX9Y(PR19TC,9:\*]4$W595Z3T4O(2\K3D#_OX=J!3205KF.YPAK'? M$T'\UR!]-G$+AG ?2/U4]FT))0!4FE+)6)'J5H!G,!;Z,!RAO9,I03B MJE3RDC+,\.9YX59*,%B8SA!\]M[EYB^0/9$.X-$*^0HE18Q^,+CW;!#!L MNU-XF:N(/7ZD' LN,F!Z42O?W]\5X_EW*%379OFF#NAS0F3V7ADER/H$ MC#R=--0,)$+%F!S^U10GA0$1B!+L_Z*N+,\L3R/E\C/C:FQBV'9(/ M35$7IG!HA4 3LFE$6ELMJ$8ZC_T,9I XFL?7#0JHJ. Q?4.W$!84U^Z!5 M#Q-R4900.)+$I,JC^L![^'(=L08]WT*,^?Q]DX+LVS*PN4O!!5\ MNPH;*$LAH=2[17:UDJF8';2%\(NN.14K1\)+Q'M6+-J:S/%)L/EVN)?YQ M ;KPZSD?_![[-^]WSPKMEK,[B_ZG7?ZF?M,_;/?S;[\.#Y];LG,'_7UC[ M'U]=K\/9=TTR^O+O3V=* IKUF9ZW^WFF=UH7UV=ZYW6O;HL$YWP[T M2WT C0;=/'37#ELJS9!(]YQ=MGNM-_D^4J_T _4+_G^J #?;)SZ++)KIJ] M=ZZOFCVV-5U[ZK;;S-YN?Z?W615._;)]! M$[T#%KOVUW!JS_IGEQ0?TV MKYHM^!4)]Z][IPU!WJW _(#7W09ZUN9]#3?5NK\]M8'YYJN+MN5'F M]]JM 8H9W[5 7#T!5FR?]5NZ7 /RFJ#G,W+WG4%I#MM_]^#?6D)TU+YNO MVWV67=86TE 5!N9H7??:ER*J*A__:H_T ?7S9[WV]9%VO]U[J[?:_4-V MT05-=^1QG6_G8=^!DWJ'JB (J$W+^Z[NND4KTS:/=ZUUH1Q[TWT'-. MF]=H8= ]6:5#8H/ZNKU?D '4!UDGS]Z]:/S'FJ;M-9$=?1!ZV!4HVH]$6 MWD1EW7:KR_TU^U.JXVE723T3N^WV!/O8\5=-'SNR9TSV0'H)F!/;$K*X M3(VT\]9\^RM3AXJ*H.+]'7I3D(Q_O6VF XA/B(-U$/H.'7$,0X,ZU M9Q!((/-B0(DS\L3 G:XY_';F2,G JY;X9IT,6-J;%AC[88S(RBV3UN* M^5TD$M?9T#8*=3ZGQD?IFD#!A7KAAFV2,P_^X#PMX;(H]3WD$R(Z2, % M: $H!!-()9QR:?U[,3=3Y\;SBB6]DK.P5N.6O1MJ)4C5GMYBM*R_SA'7S MK%+%G?;F)55_IIO/,KCHDP$1/ABW?(L-YL-,)MP7!SB-F]MZM_UQR*H[^%B MF=C(U)WI+.'P-9D18WN+%J).J $]C%)JYC^8KGM**6L!;$:_Q185O M#']\:4Q7E/1YD$=T(01N%Y*T0H6WD+_6#^S0/_!=3E48T3)/Y *=L'H ) MQ=H[I5C+(9%D,T!#$*;OU0V5]N#;#$C\[2FP-,(#KZN[ B6:;6$-ZL MBVL9\7Y1/''*D=,D]9HAH6K=)1B(.C(_J(,(=,JIHY5$?L5LMG6;G1O-! M4(MUH.QP8PMJ4BK1B!JD%H0CW%MA?D P3H0U0 2O!;C IEU_ KRGD MD!4;XB,$=42,ACC!]F.LMWG33N1CPF3 M,Q#[I.6C22?HB0;K6YF8T?, M4NCXZ3):J]#H+_^SOYFNZ99GVD1NQ,.MX'T_ ZSB6_?E,^R M=+CF*X8\P-M84RED155.35A$L.'%!D*H 5QC;-EW'GF?4!6!I6JEPN5#[ M*=$U+,+P!Q9*=DX84JHK#OPQ!GRQ#JQ7..:!RF]!1)\)IZA!*UG[N$]B+ MY-A%$HNJJ?)#XG$=1!#XWADC^EB2\E:)#P0=ZZ-^ZQ7Q C(;=6!C(4 MC6*R%
Re: [io] writer/reader sub-packages
Took a while to get the idea into my head. Think I understand you now.
[for the sake of the list]:
The lib you mention has a unified Stream which has both the reading and
writing parts in [summarising a touch]. This is nice except that it means
that 'XmlReadStream' does not extend java.io.InputStream. It'd be nice to
hear some good positives for the joined version
Allows you to do things like:
void write( OutputStream out ) {
out.asFoo( this );
}
void read( InputStream in ) {
in.asFoo( this );
}
/* balanced read/write */
void asFoo( IOStream stream ) {
objA = stream.asFoo( objA );
objB = stream.asFoo( objB );
}
...as I said before, it forces the raeder and writer to be balanced
(that is, it is unlikely that an inteligent programmer will accidentally
code asFoo() in such a way that read() fails to read the data written by
write()).
as I think the surprise of
discovering the io classes don't extend Java ones would be a big negative.
Agreed. I'm not sure the positives outweigh the negative either.
--
Michael
smime.p7s
Description: S/MIME Cryptographic Signature
[general] (was: Re: [beanutils][lang][PROPOSAL] deprecated beanutilsversion of MethodUtils)
Henri Yandell wrote:
Ideas for how to handle dependencies better at Jakarta Commons would be
good. String Taglib is dependent on Lang and the number one problem users
have is not having commons-lang in their classpath.
More of a workaround than a fix, but I'd like to suggest the following:
o Ensure that there is an 'install' task for each component, that
copies (or moves) the jar to ${lib.repo}, where ${lib.repo} is
configured in, say, the users' .antrc
o Use the get/ or optional jjar/ task to fetch the dependencies
--
Michael
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [betwixt] XML files and XMLIntrospector
Michael Davey wrote: Hi, I am having a problem with betwixt and I am not sure whether it is a bug or lack of unserstanding. The problem is that XMLIntrospector (actually ElementDescriptor.hasAttributes()) does not see the 'id' attribute for my inner class when looking for the ID/IDREF attribute (getIDAttribute()) while preparing to write the class. After further investigation... The problem occurs when ElementDescriptor.hasAttributes() is called before ElementDescriptor.getAttributeDescriptors(). Possible fixes: Change javadoc for hasAttributes() to state that getAttributeDescriptors() MUST be called before hasAttributes() and then change XMLIntrospector.findIDAttribute() to comply with the new contract. Change hasAttributes() to call getAttributeDescriptors() if attributes == null. Possible side effects? I'm not familiar with the code, so I couldn't say. -- Michael smime.p7s Description: S/MIME Cryptographic Signature
Re: [betwixt] XML files and XMLIntrospector
robert burrell donkin wrote:
hi Michael
i'm pretty sure that it's a lack of capability in the code. i have been
meaning to revise this area but i've been held by by some classloader
problems in maven that meant i couldn't write the test cases i needed.
these problems now seems to be resolved so i'll try to find time to take
another look.
Thanks. If there is consensus with my analysis and consensus that the
second solution should be implemented (see my follow up email), here are
some patches that fix the problem.
Changes:
o Changed ElementDescriptor.hasAttributes() to call
ElementDescriptor.getAttributeDescriptors() if attributes == null
o Added innerBean helper to AbstractTestClass
o Added innerBean tests to TextXMLIntrospector, refactored
o Added Nodes class and matching betwixt configuration
o Minor documentation changes (better definition of method
contracts) in a couple of places
Paths to new files:
src/test/org/apache/commons/betwixt/xmlunit/Nodes.java
src/test/org/apache/commons/betwixt/xmlunit/Nodes$Node.betwixt
--
Michael
Index: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/AbstractTestCase.java
===
RCS file: /home/cvspublic/jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/AbstractTestCase.java,v
retrieving revision 1.2
diff -u -r1.2 AbstractTestCase.java
--- jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/AbstractTestCase.java 26 Jul 2002 21:04:05 - 1.2
+++ jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/AbstractTestCase.java 27 Oct 2002 23:54:42 -
@@ -70,11 +70,13 @@
import junit.framework.TestSuite;
import org.apache.commons.betwixt.io.BeanWriter;
-
+import org.apache.commons.betwixt.xmlunit.Nodes;
+import org.apache.commons.betwixt.xmlunit.Nodes.Node;
/** Abstract base class for test cases.
*
* @author James Strachan
+ * @author Michael Davey
* @version $Revision: 1.6 $
*/
public abstract class AbstractTestCase extends TestCase {
@@ -117,6 +119,13 @@
address.setCode( "N5" );
bean.setAddress( address );
+return bean;
+}
+
+protected Object createInnerBean() {
+Node bean = new Nodes.Node();
+bean.setId( "foo" );
+bean.setType( "Manager" );
return bean;
}
}
End
Index: jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/ElementDescriptor.java
===
RCS file: /home/cvspublic/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/ElementDescriptor.java,v
retrieving revision 1.3
diff -u -r1.3 ElementDescriptor.java
--- jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/ElementDescriptor.java 1 Jul 2002 18:43:00 - 1.3
+++ jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/ElementDescriptor.java 27 Oct 2002 23:53:19 -
@@ -74,6 +74,7 @@
*
* @author James Strachan
* @author Martin van den Bemt
+ * @author Michael Davey
* @version $Revision: 1.3 $
*/
public class ElementDescriptor extends NodeDescriptor {
@@ -143,8 +144,15 @@
return elementDescriptors != null && elementDescriptors.length > 0;
}
-/** Returns true if this element has attributes */
+/**
+ * Returns true if this element has attributes.
+ * Gets the attribute descriptors if they havn't been read yet.
+ * @return true if this element has attributes, false otherwise
+ */
public boolean hasAttributes() {
+if ( attributeDescriptors == null ) {
+getAttributeDescriptors();
+}
return attributeDescriptors != null && attributeDescriptors.length > 0;
}
@@ -172,7 +180,12 @@
}
-/** Returns the attribute descriptors for this element */
+/**
+ * Returns the attribute descriptors for this element.
+ * This method never returns null
+ * @return the attribute descriptors for this element,
+ * or an empty array if this element has not attributes
+ */
public AttributeDescriptor[] getAttributeDescriptors() {
if ( attributeDescriptors == null ) {
if ( attributeList == null ) {
End
Index: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/TestXMLIntrospector.java
===
RCS file: /home/cvspublic/jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/TestXMLIntrospector.java,v
retrieving revision 1.1
diff -u -r1.1 TestXMLIntrospector.java
--- jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/TestXMLIntrospector.java 10 Jun 2002 17:53:32 - 1.1
+++ jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/TestXMLIntrospector.java 27 Oct 2002 23:55:36 -
@@ -72,6 +72,7 @@
/** Test harness for the XMLIntrospector
*
* @author James Strachan
+
Re: [general] checkstyle report
[EMAIL PROTECTED] wrote: How about using Jalopy to fix the code up? I wasn't even aware of Jalopy. I see it can even sort the ordering of methods and fix license headers ;) Can CVS be configured to use Jaolpy to fix the coding style automagically during checkin? I'm not familiar with CVS server configuration, but I do notice that the command-line plugin for Jalopy supports pipelining. -- Michael -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [general] checkstyle report
Martin Cooper wrote: By default, I believe Mavenised projects are configured for the Sun coding conventions. Maven also directly supports the Turbine conventions, but you can modify either set, or define an entirely new set, on a per-project basis. There are Commons components that use each of these alternatives. The Commons charter allows each component to define its own set of coding conventions, as long as the conventions are documented. The default is the Sun coding conventions, if nothing else is stated. It seems to me that projects tend to override bits of other styles. They say things like [these are] coding conventions that are specific to Jakarta Commons/Net everything else not specificially mentioned here should follow the official Sun Java Coding Conventions http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html. Perhaps it would be possible to define an authorative Maven coding style and then provide a kind of cascading configuration that allows individual projects to add or override conventions? Also perhaps some statistics on which project overrides and new conventions are popular so that over time the Maven coding style could be expanded and refined? I guess Maven could even auto-generate a per-project document that outlines that projects' coding style. -- Michael
Re: [VOTE] Release 2.1 of commons collections
[EMAIL PROTECTED] wrote: Henri Yandell wrote: 2. In the binary distribution (both .zip and .tar.gz), the commons-collections.jar contains a Manifest.mf that lists: Specification-Version: 1.0 Implementation-Version: 2.0 Imp Version done. Spec Version not done. Any suggestions on what it should be? 2.0? 2.1? Following the format of Collections 1, I think it would be 1.0. I would have gussed that the spec version does rise, unless the release is bug fixes only. Thus this should be 2.1. Have any non-private fields, methods or classes been removed since last release? Have new methods been added to interfaces since last release? Has the contract of any non-private class, method or function changed in a way that is not backwardly compatible? If the answer to one or more of the questions is yes, then the spec version should increment IMO. In other words: o an implementation of this version of the specification must be mutually binary compatible with previous implementations of this version of the specification o the implementation contract must be backwards compatible with previous implementation contracts for this version of the specification ...for the specification version to remain unchanged. binary compatible is defined and described here... http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html#44872 -- Michael -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [collection] MultiHashMap class improvements
I've been using the collect sub-package from innig.org for some time. Perhaps we could flatter the author by incorporating some of them into v3.0 of oac.collections? http://www.innig.org/util/innig-util/src/net/innig/collect/ http://www.innig.org/util/innig-util/build/javadoc/ I particularly like the provision of the CompositeMultiMap class and that HashMultiMap/TreeMultiMap extend it. -- Michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: The Comprehensive Java Archive Network
Henri Yandell wrote: I noticed this yesterday Michael after wondering 'who really does own cjan.org'. Have you investigated the JJAR component with respect to cjan? Yes. It is my personal hope that the CJAN developers will enhance JJAR such that it becomes the reference implementation for a CJAN client, with JJAR continuing to be hosted by Apache, and the server-side being developed on SourceForge. This would of course require the backing of the Jakarta community ;) -- Michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Possible addition to StringUtils
Chad wrote: Hmm, After running an example through my head of getting input that is quoted, I'd have to agree. If I got the string bob''s as input I'd want to get it escaped to bobs so I could get it properly unescaped back to its original form. That line of thinking takes me to my next question for the list... Should an unescape method also be added? As far as I can tell this method won't run into the same problem as the current escape() method does (with regards to unescaping), as long as we deal with single chars for the charsToEscape and escapingChar variables. I personally would want an unescape() method to get back to something approaching my original string in a loss-less fashion. Of course, it wouldn't be perfect as unescape() would likely unescape things that that were escaped prior to calling escape(). Has anyone thought of the requirements for HTML strings? = quot; = = amp; = = lt;= = gt;= -- Michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
