Re: [Jexl] String Literals with Newline do not work
On 06/07/07, Christoph Gaffga (triplemind.com) [EMAIL PROTECTED] wrote:
hi all,
I have some problems to use Jexl expressions to look for special
characters in strings, like newline or tabs:
e = ExpressionFactory.createExpression(foo.bar.indexOf('\n'));
Does not look valid syntax.
Try
e = ExpressionFactory.createExpression(foo.bar.indexOf('\n'));
o = e.evaluate(jc);
there seem to be no way to encode the linebreak, I also tried '\\n' etc.
No chance, always get an exception.
Is this a bug in Jexl or is it my fault? Has anybody done this? How?
I would appreciate any help...
kind regards,
Christoph
P.S.: Here is my test programm:
import org.apache.commons.jexl.Expression;
import org.apache.commons.jexl.ExpressionFactory;
import org.apache.commons.jexl.JexlContext;
import org.apache.commons.jexl.JexlHelper;
public class TestJexlLinebreaks {
public static class Foo {
String bar = This is line 1,\nline 2,\nline 3.;
public String getBar() {
return this.bar;
}
}
public static void main(String[] args) throws Exception {
// First make a jexlContext and put stuff in it...
JexlContext jc = JexlHelper.createContext();
jc.getVars().put(foo, new Foo());
jc.getVars().put(number, new Integer(10));
// access a property...
Expression e = ExpressionFactory.createExpression(foo.bar);
Object o = e.evaluate(jc);
System.out.println(Return foo.bar: + o);
// try to search for newline...
e = ExpressionFactory.createExpression(foo.bar.indexOf('\n'));
o = e.evaluate(jc);
System.out.println(Return foo.bar.indexOf('\\n'): + o);
}
}
-
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: [Jexl] String Literals with Newline do not work
On 06/07/07, Christoph Gaffga [EMAIL PROTECTED] wrote:
hi,
thanks for your quick reply.
Try
e = ExpressionFactory.createExpression(foo.bar.indexOf('\n'));
now I got a syntax error, do you mean:
e = ExpressionFactory.createExpression(foo.bar.indexOf('\\n'\));
Sorry, yes, I was thinking of another language.
Try using a variable instead:
jc.getVars().put(nl,\n);
e = ExpressionFactory.createExpression(foo.bar.indexOf(nl));
I tried some variations, still the same exception.
regards,
Christoph
sebb wrote:
I have some problems to use Jexl expressions to look for special
characters in strings, like newline or tabs:
e = ExpressionFactory.createExpression(foo.bar.indexOf('\n'));
Does not look valid syntax.
Try
e = ExpressionFactory.createExpression(foo.bar.indexOf('\n'));
-
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: svn commit: r553201 - /jakarta/commons/trunks-proper/KEYS
Might be worth adding a suitable note to the file ? On 04/07/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Please do.. Mvgr, Martin Dennis Lundberg wrote: Do I also need to copy the new KEYS file to http://www.apache.org/dist/jakarta/commons/KEYS ? ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r553201 - /jakarta/commons/trunks-proper/KEYS
Yes, but the note does not say where to copy the file after it has been updated... On 04/07/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Doesn't it contain a note on top ? Mvgr, Martin sebb wrote: Might be worth adding a suitable note to the file ? On 04/07/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Please do.. Mvgr, Martin Dennis Lundberg wrote: Do I also need to copy the new KEYS file to http://www.apache.org/dist/jakarta/commons/KEYS ? ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 4th attempt: Release commons-io 1.3.2
I assume that the artefacts and site are as before, i.e:
http://people.apache.org/~jochen/commons-io/dist/
http://people.apache.org/~jochen/commons-io/site/
The MD5, SHA1 and ASC files all check out OK. Licence and notice files
are present in all files (twice in sources.jar, but better twice than
none).
The source zip builds and tests OK (there are deprecation warnings
from test sources but these are to be expected)
==
The RELEASE-NOTES.txt say:
Enhancements since 1.3.1
...
- The FileCleaner is deprecated.
which is no longer true.
Also, the changes.xml says:
release version=1.3.2 date=2007-May-16
yet some items have been updated since then.
The sources.jar file does not contain all the files present in the
src.jar file - e.g. it does not contain the test or xdocs trees. I'm
not familiar with Maven and its repositories, so perhaps this is
normal.
The bin.zip archive contains bin.jar and the javadoc.
However it also contains the src.jar and the javadoc.jar.
Seems a bit unnecessary to me.
The page:
http://people.apache.org/~jochen/commons-io/site/rat-report.html
has a link called
RAT (Release Audit Tool).
which links to
/~jochen/commons-io/site/${project.url}
which does not exist - perhaps this will disappear when the real site is built?
Could not find any reference to the minimum version of Java that is
required. It would be useful to add this to the dependencies section.
S///
On 27/06/07, Jochen Wiedmann [EMAIL PROTECTED] wrote:
Hi,
I have prepared a further release candidate, with the following changes:
- Deprecation tags have been removed from the FileCleaner. (In the 1.3
branch only,
not in the trunk.) The discussion has clearly shown, that opinions
vary on this
topic, nevertheless I feel forced to make that change against my
personal opinion.
IMO, releasing a 1.4 release with as little changes as that would be
the greater
evil.
- The extracted source distribution is now using the -src suffix.
- The .md5 and .sha1 files meet the commons standard and have the format
checksum *filename
Please cast your vote.
Thanks,
Jochen
[ ] +1
[ ] =0
[ ] -1
--
Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.
The german government justifying the use of electronic voting machines
and obviously believing that we don't need a police, because all
illegal actions are forbidden.
http://dip.bundestag.de/btd/16/051/1605194.pdf
-
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: infrastructure work for TLP move
Does anything need to be done to the SVN authorization file? There is currently a commons group in it, but it contains only commons=gstein,jerenkrantz Presumably all the new commons committers are currently in the jakarta group. No point removing them (at least at present), but do they need to be added to the commons group, or does a new commons group need to be created? The new SVN parent may need to be added, along with the appropriate rights. S. On 27/06/07, Torsten Curdt [EMAIL PROTECTED] wrote: I've prepared the TODO for the infrastructure work. Please cross- check and give feedback. I am not sure how we want to handle the wiki migration. cheers -- The board has agreed to create the Commons project. (Please note that there has been a previous commons TLP) To aid in the process, would the Infrastructure team please do the following: #=== [1] Root Tasks Create unix group commons. If it already exists remove previous members. Add following usernames to group commons: bayard jochen imario scolebourne dennisl niallp mvdb ozeigermann joehni oheger mbenson martinc psteitz tcurdt dfs rwinston luc pietsch dion brentworden skitching rahul Verify that domain commons.apache.org is correctly setup. #=== [1] Mailing List (i) addresses I. [EMAIL PROTECTED] * Henri Yandell[EMAIL PROTECTED] * Jochen Wiedmann [EMAIL PROTECTED] * Mario Ivankovits [EMAIL PROTECTED] * Stephen Colebourne [EMAIL PROTECTED] * Dennis Lundberg [EMAIL PROTECTED] * Niall Pemberton [EMAIL PROTECTED] * Martin van den Bemt [EMAIL PROTECTED] * Oliver Zeigermann[EMAIL PROTECTED] * Jörg Schaible[EMAIL PROTECTED] * Oliver Heger [EMAIL PROTECTED] * Matt Benson [EMAIL PROTECTED] * Martin Cooper[EMAIL PROTECTED] * Phil Steitz [EMAIL PROTECTED] * Torsten Curdt[EMAIL PROTECTED] * Daniel Savarese [EMAIL PROTECTED] * Rory Winston [EMAIL PROTECTED] * Luc Maisonobe[EMAIL PROTECTED] * Joerg Pietschmann[EMAIL PROTECTED] * Dion Gillard [EMAIL PROTECTED] * Brent Worden [EMAIL PROTECTED] * Simon Kitching [EMAIL PROTECTED] * Rahul Akolkar[EMAIL PROTECTED] II. [EMAIL PROTECTED] migrate subscribers from commons- [EMAIL PROTECTED] III. [EMAIL PROTECTED] migrate subscribers from commons- [EMAIL PROTECTED] NOTE: if possible forward [EMAIL PROTECTED] to [EMAIL PROTECTED] (ii) remote moderators ... As this is a migration of the mailing list the current moderators will take over on the different domain. (iii) archives I. http://commons.apache.org/mail/commons/user/MM.gz II. http://commons.apache.org/mail/commons/dev/MM.gz III. [EMAIL PROTECTED] to be archived in the private area. (iv) options I. Reply-To: Header [X] yes [ ] no II. Message Trailer [X] yes [ ] no #=== [2] Source Control (i) Subversion Move the existing jakarta/commons tree to TLP #=== [3] Initial Committer list bayard jochen imario scolebourne dennisl niallp mvdb ozeigermann joehni oheger mbenson martinc psteitz tcurdt dfs rwinston luc pietsch dion brentworden skitching rahul #=== [4] Wiki (i) Wiki pages need to be migrated http://wiki.apache.org/jakarta-commons/FrontPage This can be done by the community itself. #=== [5] Bug tracking (i) Project URLs need to be migrated This can be done by the community itself. - 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: centralized KEYS file?
On 13/06/07, Ben Speakmon [EMAIL PROTECTED] wrote: I condensed all KEYS files from dist/jakarta/commons into the file at: http://people.apache.org/~bspeakmon/KEYS-commons-proper.gpg I only removed duplicates and made sure the whole thing imported correctly into my gpg; I didn't try to verify them against a store or check for expiry. The following have expired: sub 1024g/6AE82A1A 2003-11-23 [expires: 2005-11-22] sig DB00048C 2003-11-23 Tim O'Brien [EMAIL PROTECTED] and sub 1056g/EF8E1258 2003-08-27 [expires: 2005-08-26] sig F2A46D40 2003-08-27 Rob Leland (For Uploading Builds/Releases) [EMAIL PROTECTED] Not sure what needs to be done with it from here...? On 6/12/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: And replace the current KEYS files with soft links? Dunno how the mirrors handle that. -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 3rd attempt: Release commons-io 1.3.2
On 13/06/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: On 6/12/07, Ben Speakmon [EMAIL PROTECTED] wrote: I can't find the GPG key you used to sign the tarballs -- it's not in http://www.apache.org/dist/jakarta/commons/io/KEYS and there isn't a KEYS file in the svn. Looks good otherwise. +0 as is, with +1 once the key is updated and I can verify the sigs. Rats, I already *had* a proposed KEYS file in my dist directory, but seems I removed it. Ok, I have created a KEYS file for future use, which you find at http://people.apache.org/~jochen/commons-io/dist/KEYS together with the other files. Hope, that's fine. I think it should also be in SVN. Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 3rd attempt: Release commons-io 1.3.2
On 13/06/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: On 6/13/07, Henri Yandell [EMAIL PROTECTED] wrote: * tar.gz files match zips for structure. What does that mean? In Opera I got broken images on this page. http://people.apache.org/~jochen/commons-io/site/changes-report.html You are right, this is http://jira.codehaus.org/browse/MSITE-190 I suggest that I fix this manually in the deployed site. Same on this useless looking report (in that it will always be out of date): http://people.apache.org/~jochen/commons-io/site/jira-report.html Again, I have no problem to remove it from the deployed site. Personally I feel that when voting on a new rc dist, the previous +1s still count (by lazyness) and its really about converting the -1s over to +1s. That's interesting. If others feel the same, then I'd like to see this fixed somewhere. I'll bring up a different thread on that. I'm -1 with respect to the md5s. Presuming you did them by hand, it's something you can easily fix without rerolling anything. Even if not, I'd just fix them by hand anyway. Ok, as you are the second one asking for it, I've changed it. Same for the .sha1 files. I think the MD5 standard is: 32 chars checksum single space * (for binary) or space (for ascii) filename so in theory there should be a * after the space for most of the md5 files. Not sure if (m)any programs insist on this. S. I'm -0 on the validator bit meaning a reroll. I dislike how Maven1 puts the site in the binary and am looking forward to doing a Maven2 build and finding a way to only put the real docs in the binary (javadoc, release notes and user guide). That's a matter of opinion. I for my part do like if the site is included. Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] releasing jci RC4 as 1.0
On 13/06/07, Torsten Curdt [EMAIL PROTECTED] wrote: As (more or less) requested I've also created a source and binary distributions http://people.apache.org/builds/jakarta-commons/jci/1.0-RC4/dists/ No KEYS file? There's one in SVN, but it will need to be in dist as well at some point. The website is live http://jakarta.apache.org/commons/jci/ No reference to KEYS file - or is that going to be done via http://jakarta.apache.org/site/downloads/downloads_commons-jci.cgi ? And maven artifacts are here http://people.apache.org/builds/jakarta-commons/jci/1.0-RC4/org/ apache/commons/commons-jci/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC4/org/ apache/commons/commons-jci-core/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC4/org/ apache/commons/commons-jci-fam/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC4/org/ apache/commons/commons-jci-eclipse/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC4/org/ apache/commons/commons-jci-groovy/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC4/org/ apache/commons/commons-jci-janino/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC4/org/ apache/commons/commons-jci-javac/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC4/org/ apache/commons/commons-jci-rhino/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC4/org/ apache/commons/commons-jci-examples/1.0/ So please cast your votes to release commons jci RC4 as 1.0 cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] releasing jci RC3 as 1.0 ...maybe this time?
On 13/06/07, Luc Maisonobe [EMAIL PROTECTED] wrote: Torsten Curdt a écrit : But seriously: be realistic. Those people building the releases from will have subversion on their machine. And what can be simpler than a one-liner to checkout the sources? Even downloading it from an apache mirror is more work. People may have subversion but may not be able to use it. For example, I cannot use svn (nor cvs for that matter) through my corporate firewall. Wait a sec - you cannot use http from your development machine? http is fine from browsers that handle proxy with username/password, https was allowed only recently and may be shut down at any time, svn, ssh, cvs pserver are all filtered. Configuring svn clients to handle proxy username/password is not straightforward. For command-line svn it is handled by the user configuration file for servers, not by command-line options. I don't know about graphical clients or IDE embedded clients. I also know another company where http filtering is more strict, with files without any extension suppressed, files with some extensions suppressed, files modified on the fly to comply with some rules, user-agent is checked to allow only certified browsers to connect ... For example on this network, these so called « security rules » prevented me from downloading security upgrades for Debian computers (which are simple binary files downloads on an http server) ... When I need a package that is only available by checking out from its repository, I have to check it out from home, put it on an USB stick and copy it the next day at work. It is very inconvenient. That's a truly sad story ...but we cannot provide a good solution for every awkward workplace. I agree this is weird and cannot be generalized. I also agree that in the Apache case, this can be circumvented as anonymous access to the subversion server is http-based. I only wanted to point out that since a version control system is not a publication system, using it for that purpose may be tough for some people. What would you think - how many percent of the developers that require to build a project from the source have no http access to the internet? Well, for jci I will personally send them a tar of the checkout - if they have email :-p Source is not only needed for building the binary; it's also useful to have access for debugging purposes in IDEs. I would only advise to have a simple and classical way to distribute: an archive on a web server people can retrieve using a web browser. +1 Well, this is only my view and it is probably distorted, you can ignore it. It's my view too. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: centralized KEYS file?
On 14/06/07, Ben Speakmon [EMAIL PROTECTED] wrote: Let's deal with them after we get things merged (which I'm doing right now in fact :) ). What do we do with the above? Getting rid of them is only a problem if they were used to sign a release. If so, we need to resign such releases with valid keys before throwing them out permanently. Good point. However there will be copies of the KEYS files in the dist (and archive) directories. One way to deal with this would be to create the KEYS file with all the entries, and then remove any expired keys that are not used in current releases. So the key would still be recoverable via SVN and from the archives. Just a suggestion. S - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] releasing jci RC3 as 1.0 ...maybe this time?
On 14/06/07, Torsten Curdt [EMAIL PROTECTED] wrote: What would you think - how many percent of the developers that require to build a project from the source have no http access to the internet? Well, for jci I will personally send them a tar of the checkout - if they have email :-p Source is not only needed for building the binary; it's also useful to have access for debugging purposes in IDEs. Source artifact are in the maven repo for that exact reason. But downloading stuff from the Maven repo is not as easy as getting it from the Apache mirrors. Why should I have to get the binaries from one place and the source from another completely different server? I would only advise to have a simple and classical way to distribute: an archive on a web server people can retrieve using a web browser. I the situation you are in it won't buy you anything as the build system is maven ...and it would need access to the network too. Not necessarily; one can build up local copies of dependencies. How you get work done in such an environment is beyond me :) Not my environment luckily. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1
On 12/06/07, Henri Yandell [EMAIL PROTECTED] wrote: I think we're finally ready for CLI 1.1 to be released: http://people.apache.org/~bayard/commons-cli/1.0-rc1/ There are clirr and jardiff reports here with the site in: http://people.apache.org/~bayard/commons-cli/1.0-rc1/site/ No mention of the clirr / jardiff reports - seems like it would be useful to add them. One quirk to note. The site is from trunk while the release is from the 1.0.x branch (needs renaming). [ ] +1, quick release before it's 5 years since 1.0 [ ] -1, let's go for 6 years +1 Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1
On 12/06/07, Henri Yandell [EMAIL PROTECTED] wrote: On 6/12/07, sebb [EMAIL PROTECTED] wrote: On 12/06/07, Henri Yandell [EMAIL PROTECTED] wrote: I think we're finally ready for CLI 1.1 to be released: http://people.apache.org/~bayard/commons-cli/1.0-rc1/ There are clirr and jardiff reports here with the site in: http://people.apache.org/~bayard/commons-cli/1.0-rc1/site/ No mention of the clirr / jardiff reports - seems like it would be useful to add them. The clirr/jardiff information is summarized in: http://people.apache.org/~bayard/commons-cli/1.0-rc1/site/upgrading-1.0-to-1.1.html Yes, but the details would also be useful. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 3rd attempt: Release commons-io 1.3.2
On 06/06/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, I have created a new distribution and a new site which you find at http://people.apache.org/~jochen/commons-io/dist Are the jar archives necessary? Other projects tend only to release zip and tar.gz. If they are not needed, it would make reviewing easier if they were not produced. http://people.apache.org/~jochen/commons-io/site The RAT report description is wrong, but that is due to a bug in the Maven RAT package. I've filed a bug against it. [When it's fixed, there will be a lot of sites to update!] This version matches revision 544971, which I intend to tag as commons-io-1.3.2 in case of a successful vote. Compared to the previous vote, the following changes have been made: - Rahul Akolkar has convinced me, that the FileCleaningTracker should not be declared serializable, because it isn't. The resulting issues must be resolved within commons-fileupload and not commons-io. - As observed by Niall Pemberton, the -sources and -javadoc jar files did not contain LICENSE.txt and NOTICE.txt files. This is now ensured by the POM. It is an open issue for me, whether this change can be pushed up to the commons-parent POM. Please cast your vote. +1 S/// - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] releasing jci RC2 as 1.0
On 30/05/07, Torsten Curdt [EMAIL PROTECTED] wrote: The RAT report shows that there are quite a few non-trivial files that don't yet have Apache License headers - these should really be fixed before release. Ehm ...what are those!? I only see the pom's, the properties files and the package.html files without ASL header. I would consider those trivial. I agree that the package.html and properties files are trivial, but IMO the others aren't. Is it trivial to create a POM from scratch? I fear that probably comes down to the personal opinion :) IMO - yes, it is trivial to write a POM from scratch. It just describes the project. All you need to know are the dependencies. The rest are details you don't necessarily need. See: http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200702.mbox/[EMAIL PROTECTED] which says that ALL files need headers, unless they are very short and having the header would have a negative affect on the application. So I think the headers are needed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] releasing jci RC2 as 1.0
It would be helpful to have a pointer to the KEYS file. Also where is the web-site? On 29/05/07, Torsten Curdt [EMAIL PROTECTED] wrote: Only minor code changes since RC1. But we are voting on the actual binaries for the release now. The website should be fixed as well as some other packaging bits that were not OK. http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ apache/commons/commons-jci/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ apache/commons/commons-jci-core/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ apache/commons/commons-jci-fam/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ apache/commons/commons-jci-eclipse/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ apache/commons/commons-jci-groovy/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ apache/commons/commons-jci-janino/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ apache/commons/commons-jci-javac/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ apache/commons/commons-jci-rhino/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ apache/commons/commons-jci-examples/1.0/ Please cast you votes to release RC2 into the wild. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] releasing jci RC2 as 1.0
On 29/05/07, Torsten Curdt [EMAIL PROTECTED] wrote: On 29.05.2007, at 19:05, sebb wrote: It would be helpful to have a pointer to the KEYS file. Well, there is none for the component itself (yet). I would think we should have one for commons altogether and link to it from the website. (Have I been missing the link?) I would put it here: http://svn.apache.org/repos/asf/jakarta/commons/proper/ and/or somewhere here http://svn.apache.org/repos/asf/jakarta/site/ No idea if there already is such a file ...or how to deal with this from the maven perspective. Where should I put it / add my key? Sorry, no idea where they are supposed to go in commons. You could just put the file in the top level of the project for now and move it later if need be? Also where is the web-site? Sorry - thought that was obvious :) I had assumed that the web-site was also to be reviewed before being published, as some other projects do it that way. http://jakarta.apache.org/commons/jci/ OK. Comments on the files: I don't think there is any need to have sha1 and md5 digests of the asc files. The RAT report shows that there are quite a few non-trivial files that don't yet have Apache License headers - these should really be fixed before release. Web-site - It would be better if the Javadocs link opened in a new window, otherwise the navigation panel is lost. Likewise the two Xref links. See http://people.apache.org/~tv/jcs/maven-reports.html for an example. S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] releasing jci RC2 as 1.0
On 29/05/07, Torsten Curdt [EMAIL PROTECTED] wrote: Where should I put it / add my key? Sorry, no idea where they are supposed to go in commons. You could just put the file in the top level of the project for now and move it later if need be? Done http://svn.apache.org/repos/asf/jakarta/commons/proper/jci/tags/1.0- RC2/KEYS.txt Also where is the web-site? Sorry - thought that was obvious :) I had assumed that the web-site was also to be reviewed before being published, as some other projects do it that way. Well, not sure it's worth the effort until you maintain one for multiple versions. OK. I'm not saying you have to do it that way, just explaining why I was not sure where the site was. I don't think there is any need to have sha1 and md5 digests of the asc files. That's the maven way I think Doesn't seem right to me; if it's the default then Maven is being stupid ;-) http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-core/ 2.2.0-RC1/ The RAT report shows that there are quite a few non-trivial files that don't yet have Apache License headers - these should really be fixed before release. Ehm ...what are those!? I only see the pom's, the properties files and the package.html files without ASL header. I would consider those trivial. I agree that the package.html and properties files are trivial, but IMO the others aren't. Is it trivial to create a POM from scratch? Web-site - It would be better if the Javadocs link opened in a new window, otherwise the navigation panel is lost. Likewise the two Xref links. See http://people.apache.org/~tv/jcs/maven-reports.html I can look into that. But as the site is not part of the release that should not block the release. Agreed. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IO] Filename relativiser?
On 21/05/07, sebb [EMAIL PROTECTED] wrote: On 21/05/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 5/21/07, sebb [EMAIL PROTECTED] wrote: Are there any plans to implement a filename relativiser? i.e., given an absolute directory and absolute filename it would return a relative filename. e.g. (in Unix syntax): /a/b/c and /a/b/c/d/e.txt = d/e.txt and optionally: /a/b/c/f and /a/b/c/d/e.txt = ../d/e.txt It does not look particularly difficult to do, but it does not seem trivial either, so it might be a useful addition to Commons IO... +1 sounds like a good candidate for FilenameUtils - commons JCI has a relative method in its ConverstionUtils class s/stion/sion/ http://tinyurl.com/2kj6ul Thanks. That would handle the first case above, but not the optional case. Actually it does not handle /a/b/c/ and /d/e/f/g.txt as it assumes that the base is a proper parent of the file, which is presumably true for JCI, but not for the general case I need. The optional case probably needs a dottiness (!) limit - i.e. how many .. segments are allowed. S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[IO] Filename relativiser?
Are there any plans to implement a filename relativiser? i.e., given an absolute directory and absolute filename it would return a relative filename. e.g. (in Unix syntax): /a/b/c and /a/b/c/d/e.txt = d/e.txt and optionally: /a/b/c/f and /a/b/c/d/e.txt = ../d/e.txt It does not look particularly difficult to do, but it does not seem trivial either, so it might be a useful addition to Commons IO... S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IO] Filename relativiser?
On 21/05/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 5/21/07, sebb [EMAIL PROTECTED] wrote: Are there any plans to implement a filename relativiser? i.e., given an absolute directory and absolute filename it would return a relative filename. e.g. (in Unix syntax): /a/b/c and /a/b/c/d/e.txt = d/e.txt and optionally: /a/b/c/f and /a/b/c/d/e.txt = ../d/e.txt It does not look particularly difficult to do, but it does not seem trivial either, so it might be a useful addition to Commons IO... +1 sounds like a good candidate for FilenameUtils - commons JCI has a relative method in its ConverstionUtils class s/stion/sion/ http://tinyurl.com/2kj6ul Thanks. That would handle the first case above, but not the optional case. The optional case probably needs a dottiness (!) limit - i.e. how many .. segments are allowed. S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r539899 - /jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLUtil.java
Author: sebb
Date: Sun May 20 11:10:17 2007
New Revision: 539899
URL: http://svn.apache.org/viewvc?view=revrev=539899
Log:
Add optional argument to help output
Modified:
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLUtil.java
Modified:
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLUtil.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLUtil.java?view=diffrev=539899r1=539898r2=539899
==
---
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLUtil.java
(original)
+++
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLUtil.java
Sun May 20 11:10:17 2007
@@ -46,12 +46,15 @@
final String name = options[i].getName();
String description = options[i].getDescription();
int flags = options[i].getFlags();
+boolean argumentOptional =
+((flags CLOptionDescriptor.ARGUMENT_OPTIONAL) ==
+ CLOptionDescriptor.ARGUMENT_OPTIONAL);
boolean argumentRequired =
((flags CLOptionDescriptor.ARGUMENT_REQUIRED) ==
-CLOptionDescriptor.ARGUMENT_REQUIRED);
+ CLOptionDescriptor.ARGUMENT_REQUIRED);
boolean twoArgumentsRequired =
((flags CLOptionDescriptor.ARGUMENTS_REQUIRED_2) ==
-CLOptionDescriptor.ARGUMENTS_REQUIRED_2);
+ CLOptionDescriptor.ARGUMENTS_REQUIRED_2);
boolean needComma = false;
if( twoArgumentsRequired )
{
@@ -78,6 +81,10 @@
sb.append( name );
}
+if (argumentOptional)
+{
+sb.append( [[=]argument]);
+}
if( argumentRequired )
{
sb.append( argument );
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r539900 - /jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/package.html
Author: sebb Date: Sun May 20 11:11:02 2007 New Revision: 539900 URL: http://svn.apache.org/viewvc?view=revrev=539900 Log: Correct typo: optional args cannot be separate Modified: jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/package.html Modified: jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/package.html URL: http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/package.html?view=diffrev=539900r1=539899r2=539900 == --- jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/package.html (original) +++ jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/package.html Sun May 20 11:11:02 2007 @@ -143,9 +143,9 @@ argument bc while -a bc is an option 'a' with no argument, followed by the text bc. /p pIt is also possible to place an '=' sign between the option -and it's argument. So if we assume that a is an option that -requires an argument then the following are all equivalent; --a=bc, -a bc -abc. +and its argument. So if we assume that a is an option that +requires an argument then the following are equivalent; +-a=bc and -abc. /p p In the case of a long option with an optional argument, the '=' sign is required. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r539901 - /jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/Token.java
Author: sebb
Date: Sun May 20 11:11:36 2007
New Revision: 539901
URL: http://svn.apache.org/viewvc?view=revrev=539901
Log:
Add NON-NLS marker
Modified:
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/Token.java
Modified:
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/Token.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/Token.java?view=diffrev=539901r1=539900r2=539901
==
---
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/Token.java
(original)
+++
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/Token.java
Sun May 20 11:11:36 2007
@@ -65,7 +65,7 @@
{
final StringBuffer sb = new StringBuffer();
sb.append( m_type );
-sb.append( : );
+sb.append( : ); // $NON-NLS-1$
sb.append( m_value );
return sb.toString();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r539904 - /jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLOptionDescriptor.java
Author: sebb
Date: Sun May 20 11:22:14 2007
New Revision: 539904
URL: http://svn.apache.org/viewvc?view=revrev=539904
Log:
Remove deprecated method (OK as code has not been released)
Modified:
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLOptionDescriptor.java
Modified:
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLOptionDescriptor.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLOptionDescriptor.java?view=diffrev=539904r1=539903r2=539904
==
---
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLOptionDescriptor.java
(original)
+++
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLOptionDescriptor.java
Sun May 20 11:22:14 2007
@@ -143,15 +143,6 @@
}
/**
- * @deprecated Use the correctly spelled [EMAIL PROTECTED]
#getIncompatible} instead.
- * @return the array of incompatible option ids
- */
-protected final int[] getIncompatble()
-{
-return getIncompatible();
-}
-
-/**
* Get the array of incompatible option ids.
*
* @return the array of incompatible option ids
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r539920 - /jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLOptionDescriptor.java
Author: sebb
Date: Sun May 20 12:41:25 2007
New Revision: 539920
URL: http://svn.apache.org/viewvc?view=revrev=539920
Log:
Remove deprecated constructor (OK as code has not been released)
Modified:
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLOptionDescriptor.java
Modified:
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLOptionDescriptor.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLOptionDescriptor.java?view=diffrev=539920r1=539919r2=539920
==
---
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLOptionDescriptor.java
(original)
+++
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLOptionDescriptor.java
Sun May 20 12:41:25 2007
@@ -59,9 +59,15 @@
final int id,
final String description )
{
-this( name, flags, id, description,
-((flags CLOptionDescriptor.DUPLICATES_ALLOWED) 0)
-? new int[0] : new int[]{id} );
+
+checkFlags(flags);
+
+m_id = id;
+m_name = name;
+m_flags = flags;
+m_description = description;
+m_incompatible = ((flags DUPLICATES_ALLOWED) 0)
+ ? new int[0] : new int[] { id };
}
/**
@@ -71,21 +77,30 @@
* @param flags the flags
* @param id the id/character option
* @param description description of option usage
- * @param incompatible an array listing the ids of all incompatible options
- * @deprecated use the version with the array of CLOptionDescriptor's
+ * @param incompatible an array listing the descriptors of all
incompatible options
*/
public CLOptionDescriptor( final String name,
final int flags,
final int id,
final String description,
-final int[] incompatible )
+final CLOptionDescriptor[] incompatible )
{
+
+checkFlags(flags);
+
m_id = id;
m_name = name;
m_flags = flags;
m_description = description;
-m_incompatible = incompatible;
+m_incompatible = new int[incompatible.length];
+for (int i = 0; i incompatible.length; i++) {
+m_incompatible[i] = incompatible[i].getId();
+}
+}
+
+// helper method - check for invalid flag combinations
+private void checkFlags(final int flags) {
int modeCount = 0;
if( (ARGUMENT_REQUIRED flags) == ARGUMENT_REQUIRED )
{
@@ -113,32 +128,6 @@
{
final String message = Multiple modes specified for option +
this;
throw new IllegalStateException( message );
-}
-}
-
-/**
- * Constructor.
- *
- * @param name the name/long option
- * @param flags the flags
- * @param id the id/character option
- * @param description description of option usage
- */
-public CLOptionDescriptor( final String name,
-final int flags,
-final int id,
-final String description,
-final CLOptionDescriptor[] incompatible )
-{
-m_id = id;
-m_name = name;
-m_flags = flags;
-m_description = description;
-
-m_incompatible = new int[incompatible.length];
-for( int i = 0; i incompatible.length; i++ )
-{
-m_incompatible[i] = incompatible[i].getId();
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r539927 - /jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLOption.java
Author: sebb
Date: Sun May 20 12:54:54 2007
New Revision: 539927
URL: http://svn.apache.org/viewvc?view=revrev=539927
Log:
Remove deprecated method (OK as code has not been released)
Improve toString() output
Add toShortString() method for testing
Modified:
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLOption.java
Modified:
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLOption.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLOption.java?view=diffrev=539927r1=539926r2=539927
==
---
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLOption.java
(original)
+++
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLOption.java
Sun May 20 12:54:54 2007
@@ -71,19 +71,6 @@
}
}
-/**
- * Retrieve id of option.
- *
- * The id is eqivalent to character code if it can be a single letter
option.
- *
- * @return the id
- * @deprecated use codegetDescriptor().getId()/code instead
- */
-public final int getId()
-{
-return m_descriptor == null ? TEXT_ARGUMENT : m_descriptor.getId();
-}
-
public final CLOptionDescriptor getDescriptor()
{
return m_descriptor;
@@ -158,8 +145,14 @@
public final String toString()
{
final StringBuffer sb = new StringBuffer();
-sb.append( [Option );
-sb.append( (char)m_descriptor.getId() );
+sb.append([);
+final char id = (char) m_descriptor.getId();
+if (id == TEXT_ARGUMENT) {
+sb.append(Text );
+} else {
+sb.append(Option );
+sb.append(id);
+}
if( null != m_arguments )
{
@@ -169,6 +162,28 @@
sb.append( ] ); // $NON-NLS-1$
+return sb.toString();
+}
+
+/*
+ * Convert to a shorter String for test purposes
+ *
+ * @return the string value
+ */
+final String toShortString() {
+final StringBuffer sb = new StringBuffer();
+final char id = (char) m_descriptor.getId();
+if (id != TEXT_ARGUMENT) {
+sb.append(-);
+sb.append(id);
+}
+
+if (null != m_arguments) {
+if (id != TEXT_ARGUMENT) {
+sb.append(=);
+}
+sb.append(Arrays.asList(m_arguments));
+}
return sb.toString();
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r539978 - in /jakarta/commons/proper/cli/branches/avalon-implementation/src: java/org/apache/commons/cli/avalon/CLArgsParser.java test/org/apache/commons/cli/avalon/ClutilTestCase.java
Author: sebb
Date: Sun May 20 16:07:14 2007
New Revision: 539978
URL: http://svn.apache.org/viewvc?view=revrev=539978
Log:
Fix long optional args to require = as per documentation
Modified:
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLArgsParser.java
jakarta/commons/proper/cli/branches/avalon-implementation/src/test/org/apache/commons/cli/avalon/ClutilTestCase.java
Modified:
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLArgsParser.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLArgsParser.java?view=diffrev=539978r1=539977r2=539978
==
---
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLArgsParser.java
(original)
+++
jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLArgsParser.java
Sun May 20 16:07:14 2007
@@ -450,11 +450,6 @@
//should never get to here when stringIndex != 0
addOption( new CLOption( m_args[m_argIndex++] ) );
}
-else if( STATE_OPTIONAL_ARG == m_state m_isLong m_ch != 0)
-{
-m_state = STATE_NORMAL;
-addOption( m_option );
-}
else
{
parseArguments();
@@ -560,12 +555,15 @@
return m_args[m_argIndex].charAt( m_stringIndex++ );
}
+private char m_tokesep; // Keep track of token separator
+
private final Token nextToken( final char[] separators )
{
m_ch = getChar();
if( isSeparator( m_ch, separators ) )
{
+m_tokesep = m_ch;
m_ch = getChar();
return new Token( TOKEN_SEPARATOR, null );
}
@@ -579,6 +577,7 @@
}
while( !isSeparator( m_ch, separators ) );
+m_tokesep = m_ch;
return new Token( TOKEN_STRING, sb.toString() );
}
@@ -658,6 +657,13 @@
addOption( m_option );
m_state = STATE_NORMAL;
return;
+}
+
+if (m_isLong '=' != m_tokesep) // Long optional arg must have =
as separator
+{
+addOption(m_option);
+m_state = STATE_NORMAL;
+return;
}
if( '=' == m_ch ) // $NON-NLS-1$
Modified:
jakarta/commons/proper/cli/branches/avalon-implementation/src/test/org/apache/commons/cli/avalon/ClutilTestCase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/avalon-implementation/src/test/org/apache/commons/cli/avalon/ClutilTestCase.java?view=diffrev=539978r1=539977r2=539978
==
---
jakarta/commons/proper/cli/branches/avalon-implementation/src/test/org/apache/commons/cli/avalon/ClutilTestCase.java
(original)
+++
jakarta/commons/proper/cli/branches/avalon-implementation/src/test/org/apache/commons/cli/avalon/ClutilTestCase.java
Sun May 20 16:07:14 2007
@@ -196,6 +196,30 @@
assertEquals( option2.getArgument( 0 ), null );
}
+public void testOptionalArgLongEquals() {
+final CLOptionDescriptor[] options = new CLOptionDescriptor[] { ALL,
TAINT };
+
+// Check that optional args work woth long options
+final String[] args = new String[] { --taint=param, -a };
+
+final CLArgsParser parser = new CLArgsParser(args, options);
+
+assertNull(parser.getErrorString(), parser.getErrorString());
+
+final List clOptions = parser.getArguments();
+final int size = clOptions.size();
+
+assertEquals(Option count, 2, size);
+
+final CLOption option0 = (CLOption) clOptions.get(0);
+assertEquals(Option Code: + option0.getDescriptor().getId(),
TAINT_OPT, option0.getDescriptor().getId());
+assertEquals(Option Arg: + option0.getArgument(0), param,
option0.getArgument(0));
+
+final CLOption option2 = (CLOption) clOptions.get(1);
+assertEquals(option2.getDescriptor().getId(), ALL_OPT);
+assertEquals(option2.getArgument(0), null);
+}
+
public void testShortOptArgUnenteredBeforeOtherOpt()
{
final CLOptionDescriptor[] options = new CLOptionDescriptor[]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 2nd attempt: Release commons-io 1.3.2
On 17/05/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: On 5/17/07, sebb [EMAIL PROTECTED] wrote: The site report page http://people.apache.org/~jochen/commons-io/site/project-reports.html says that the RAT report is a Report on binary and source API differences between releases That's a bug in the rat-maven-plugin and cannot easily be fixed now. Sorry, OK, in that case, perhaps the text could be changed? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-io 1.3.2
Permissions problem with some file types: You don't have permission to access /~jochen/commons-io/dist/commons-io-1.3.2-bin.zip on this server. You don't have permission to access /~jochen/commons-io/dist/commons-io-1.3.2-bin.zip.asc on this server. You don't have permission to access /~jochen/commons-io/dist/commons-io-1.3.2-sources.jar on this server. Only md5 and sha1 seem to be accessible ... So that has to be -1! S. On 16/05/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, I'd like to call for a vote on the release of commons-io 1.3.2. The proposed distributables can be found at http://people.apache.org/~jochen/commons-io/dist A KEYS file is included. The proposed site is at http://people.apache.org/~jochen/commons-io/site It includes a RAT report. Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-io 1.3.2
Forgot to say - the reports page says that the RAT report is a: Report on binary and source API differences between releases However, the RAT only contains license checks. Oh, and some source files probably need licenses, e.g. navigation.xml build.xml PROPOSAL.html STATUS.html On 17/05/07, sebb [EMAIL PROTECTED] wrote: Permissions problem with some file types: You don't have permission to access /~jochen/commons-io/dist/commons-io-1.3.2-bin.zip on this server. You don't have permission to access /~jochen/commons-io/dist/commons-io-1.3.2-bin.zip.asc on this server. You don't have permission to access /~jochen/commons-io/dist/commons-io-1.3.2-sources.jar on this server. Only md5 and sha1 seem to be accessible ... So that has to be -1! S. On 16/05/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, I'd like to call for a vote on the release of commons-io 1.3.2. The proposed distributables can be found at http://people.apache.org/~jochen/commons-io/dist A KEYS file is included. The proposed site is at http://people.apache.org/~jochen/commons-io/site It includes a RAT report. Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 2nd attempt: Release commons-io 1.3.2
On 17/05/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, I have fixed the issues with the file permissions and added license headers to most of the files, with the only exception of MANIFEST.MF. Now, I'd like to call for another vote on the release of commons-io 1.3.2. The proposed distributables can be found at http://people.apache.org/~jochen/commons-io/dist A KEYS file is included. The proposed site is at http://people.apache.org/~jochen/commons-io/site The site report page http://people.apache.org/~jochen/commons-io/site/project-reports.html says that the RAT report is a Report on binary and source API differences between releases However it is only a license check currently. Is there an API difference report somewhere? Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - 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]
svn commit: r530846 - in /jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl: HostConfigurationWithHostFactory.java HttpHostFactory.java SocketFactoryWrapper
Author: sebb Date: Fri Apr 20 09:18:16 2007 New Revision: 530846 URL: http://svn.apache.org/viewvc?view=revrev=530846 Log: set svn:eol-style native Modified: jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/HostConfigurationWithHostFactory.java (props changed) jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/HttpHostFactory.java (props changed) jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/SocketFactoryWrapper.java (props changed) Propchange: jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/HostConfigurationWithHostFactory.java -- svn:eol-style = native Propchange: jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/HttpHostFactory.java -- svn:eol-style = native Propchange: jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/SocketFactoryWrapper.java -- svn:eol-style = native - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [http-client] Does HttpClient support the HttpOnly cookie attribute?
On 16/04/07, Oleg Kalnichevski [EMAIL PROTECTED] wrote: On Sun, 2007-04-15 at 09:48 -0400, Tom Muldoon wrote: It appears that the HttpOnly cookie attribute is not recognized by the CookieSpec class (in both HttpClient 3.0 and 3.1rc). i.e. the following message is logged ... CookieSpec - Unrecognized cookie attribute: name=HttpOnly, value=null This appears to be a bit of a show stopper, as the server redirects the subsequent request back to the Login page after a seemingly successful login. In looking at the cookie that is included in the subsequent request, the HttpOnly attribute is missing altogether. So, does HttpClient support HttpOnly cookie attribute??? Tom, I am not aware of HttpOnly attribute mentioned anywhere in RFC2109 or RFC2965. HttpClient does not support cookie attributes that are not defined in the HTTP state management specification. However it appears that using CookiePolicy.BROWSER_COMPATIBILITY will ignore the unrecognised atribute, so you could try that. S/// - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r529017 - /jakarta/commons/proper/cli/branches/avalon-implementation/src/conf/MANIFEST.MF
Author: sebb Date: Sun Apr 15 10:18:33 2007 New Revision: 529017 URL: http://svn.apache.org/viewvc?view=revrev=529017 Log: CLI2 - Avalon Modified: jakarta/commons/proper/cli/branches/avalon-implementation/src/conf/MANIFEST.MF Modified: jakarta/commons/proper/cli/branches/avalon-implementation/src/conf/MANIFEST.MF URL: http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/avalon-implementation/src/conf/MANIFEST.MF?view=diffrev=529017r1=529016r2=529017 == Binary files - no diff available. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r529019 - /jakarta/commons/proper/cli/branches/avalon-implementation/src/test/data/
Author: sebb Date: Sun Apr 15 10:20:39 2007 New Revision: 529019 URL: http://svn.apache.org/viewvc?view=revrev=529019 Log: Not used for Avalon CLI Removed: jakarta/commons/proper/cli/branches/avalon-implementation/src/test/data/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r529021 - in /jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon: AbstractParserControl.java CLArgsParser.java CLOption.java CLOptionDescripto
Author: sebb Date: Sun Apr 15 10:22:41 2007 New Revision: 529021 URL: http://svn.apache.org/viewvc?view=revrev=529021 Log: Fix ASF licence; add NON-NLS markers Modified: jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/AbstractParserControl.java jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLArgsParser.java jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLOption.java jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLOptionDescriptor.java jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLUtil.java jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/ParserControl.java jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/Token.java Modified: jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/AbstractParserControl.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/AbstractParserControl.java?view=diffrev=529021r1=529020r2=529021 == --- jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/AbstractParserControl.java (original) +++ jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/AbstractParserControl.java Sun Apr 15 10:22:41 2007 @@ -1,26 +1,28 @@ -/* - * Copyright 2002-2005 The Apache Software Foundation - * Licensed under the Apache License, Version 2.0 (the License); - * you may not use this file except in compliance with the License. - * You may obtain a copy of the License at - * +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the License); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * * http://www.apache.org/licenses/LICENSE-2.0 - * + * * Unless required by applicable law or agreed to in writing, software - * distributed under the License is distributed on an AS IS BASIS, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or - * implied. - * + * distributed under the License is distributed on an AS IS BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. + * */ + package org.apache.commons.cli.avalon; //Renamed from org.apache.avalon.excalibur.cli /** * Class to inherit from so when in future when new controls are added - * clients will no have to implement them. - * @version $Revision: 1.2 $ + * clients will not have to implement them. + * * @see ParserControl */ public abstract class AbstractParserControl Modified: jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLArgsParser.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLArgsParser.java?view=diffrev=529021r1=529020r2=529021 == --- jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLArgsParser.java (original) +++ jakarta/commons/proper/cli/branches/avalon-implementation/src/java/org/apache/commons/cli/avalon/CLArgsParser.java Sun Apr 15 10:22:41 2007 @@ -1,19 +1,21 @@ -/* - * Copyright 2002-2005 The Apache Software Foundation - * Licensed under the Apache License, Version 2.0 (the License); - * you may not use this file except in compliance with the License. - * You may obtain a copy of the License at - * +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the License); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * * http://www.apache.org/licenses/LICENSE-2.0 - * + * * Unless required by applicable law or agreed to in writing, software - * distributed under the License is distributed on an AS IS BASIS, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or - * implied
svn commit: r529022 - /jakarta/commons/proper/cli/branches/avalon-implementation/src/test/org/apache/commons/cli/avalon/ClutilTestCase.java
Author: sebb Date: Sun Apr 15 10:23:15 2007 New Revision: 529022 URL: http://svn.apache.org/viewvc?view=revrev=529022 Log: Fix ASF licence Modified: jakarta/commons/proper/cli/branches/avalon-implementation/src/test/org/apache/commons/cli/avalon/ClutilTestCase.java Modified: jakarta/commons/proper/cli/branches/avalon-implementation/src/test/org/apache/commons/cli/avalon/ClutilTestCase.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/avalon-implementation/src/test/org/apache/commons/cli/avalon/ClutilTestCase.java?view=diffrev=529022r1=529021r2=529022 == --- jakarta/commons/proper/cli/branches/avalon-implementation/src/test/org/apache/commons/cli/avalon/ClutilTestCase.java (original) +++ jakarta/commons/proper/cli/branches/avalon-implementation/src/test/org/apache/commons/cli/avalon/ClutilTestCase.java Sun Apr 15 10:23:15 2007 @@ -1,19 +1,21 @@ -/* - * Copyright 2002-2005 The Apache Software Foundation - * Licensed under the Apache License, Version 2.0 (the License); - * you may not use this file except in compliance with the License. - * You may obtain a copy of the License at - * +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the License); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * * http://www.apache.org/licenses/LICENSE-2.0 - * + * * Unless required by applicable law or agreed to in writing, software - * distributed under the License is distributed on an AS IS BASIS, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or - * implied. - * + * distributed under the License is distributed on an AS IS BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. + * */ + package org.apache.commons.cli.avalon; //Renamed from org.apache.avalon.excalibur.cli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r529023 - /jakarta/commons/proper/cli/branches/avalon-implementation/xdocs/examples/
Author: sebb Date: Sun Apr 15 10:23:46 2007 New Revision: 529023 URL: http://svn.apache.org/viewvc?view=revrev=529023 Log: Not used for Avalon CLI Removed: jakarta/commons/proper/cli/branches/avalon-implementation/xdocs/examples/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r529024 - in /jakarta/commons/proper/cli/branches/avalon-implementation/xdocs/images: commandlines.png options.png
Author: sebb Date: Sun Apr 15 10:24:22 2007 New Revision: 529024 URL: http://svn.apache.org/viewvc?view=revrev=529024 Log: Not used for Avalon CLI Removed: jakarta/commons/proper/cli/branches/avalon-implementation/xdocs/images/commandlines.png jakarta/commons/proper/cli/branches/avalon-implementation/xdocs/images/options.png - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r529025 - /jakarta/commons/proper/cli/branches/avalon-implementation/maven.xml
Author: sebb Date: Sun Apr 15 10:24:55 2007 New Revision: 529025 URL: http://svn.apache.org/viewvc?view=revrev=529025 Log: Fix ASF licence Modified: jakarta/commons/proper/cli/branches/avalon-implementation/maven.xml Modified: jakarta/commons/proper/cli/branches/avalon-implementation/maven.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/avalon-implementation/maven.xml?view=diffrev=529025r1=529024r2=529025 == --- jakarta/commons/proper/cli/branches/avalon-implementation/maven.xml (original) +++ jakarta/commons/proper/cli/branches/avalon-implementation/maven.xml Sun Apr 15 10:24:55 2007 @@ -1,17 +1,18 @@ !-- -Copyright 2002-2006 The Apache Software Foundation. + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the License); you may not use this file except in compliance with + the License. You may obtain a copy of the License at -Licensed under the Apache License, Version 2.0 (the License); -you may not use this file except in compliance with the License. -You may obtain a copy of the License at + http://www.apache.org/licenses/LICENSE-2.0 - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, software -distributed under the License is distributed on an AS IS BASIS, -WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -See the License for the specific language governing permissions and -limitations under the License. + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. -- project default=jar:jar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r529026 - /jakarta/commons/proper/cli/branches/avalon-implementation/xdocs/manual/
Author: sebb Date: Sun Apr 15 10:25:27 2007 New Revision: 529026 URL: http://svn.apache.org/viewvc?view=revrev=529026 Log: Not used for Avalon CLI Removed: jakarta/commons/proper/cli/branches/avalon-implementation/xdocs/manual/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r529028 - /jakarta/commons/proper/cli/branches/avalon-implementation/project.xml
Author: sebb Date: Sun Apr 15 10:26:36 2007 New Revision: 529028 URL: http://svn.apache.org/viewvc?view=revrev=529028 Log: Fix ASF licence header Fix Avalon references Modified: jakarta/commons/proper/cli/branches/avalon-implementation/project.xml Modified: jakarta/commons/proper/cli/branches/avalon-implementation/project.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/avalon-implementation/project.xml?view=diffrev=529028r1=529027r2=529028 == --- jakarta/commons/proper/cli/branches/avalon-implementation/project.xml (original) +++ jakarta/commons/proper/cli/branches/avalon-implementation/project.xml Sun Apr 15 10:26:36 2007 @@ -1,10 +1,11 @@ ?xml version=1.0 encoding=UTF-8? !-- - Copyright 2001-2006 The Apache Software Foundation - - Licensed under the Apache License, Version 2.0 (the License); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the License); you may not use this file except in compliance with + the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 @@ -24,7 +25,7 @@ description Commons CLI provides a simple API for presenting, processing and validating a command line interface. This is an implementation from -Avalon's code base. +Avalon's code base, as used in Apache JMeter. /description logo/images/logo.png/logo @@ -52,8 +53,8 @@ distributionDirectory/www/jakarta.apache.org/builds/jakarta-commons/cli//distributionDirectory repository - connectionscm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/cli/trunk/connection -urlhttp://svn.apache.org/repos/asf/jakarta/commons/proper/cli/trunk/url + connectionscm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/cli/branches/avalon-implementation/connection + urlhttp://svn.apache.org/repos/asf/jakarta/commons/proper/cli/branches/avalon-implementation/url /repository mailingLists @@ -71,75 +72,8 @@ /mailingList /mailingLists - developers -developer - nameJames Strachan/name - idjstrachan/id - email[EMAIL PROTECTED]/email - organizationSpiritSoft, Inc./organization -/developer -developer - nameBob McWhirter/name - idbob/id - email[EMAIL PROTECTED]/email - organizationWerken/organization - roles -rolecontributed ideas and code from werken.opt/role - /roles -/developer -developer - nameJohn Keyes/name - idjkeyes/id - email[EMAIL PROTECTED]/email - organizationintegral Source/organization - roles -rolecontributed ideas and code from Optz/role - /roles -/developer -developer - nameRob Oxspring/name - idroxspring/id - email[EMAIL PROTECTED]/email - organizationIndigo Stone/organization - roles -roledesigned CLI2/role - /roles -/developer - /developers - - contributors -contributor - namePeter Donald/name - roles -rolecontributed ideas and code from Avalon Excalibur's cli package/role - /roles -/contributor -contributor - nameBerin Loritsch/name - email[EMAIL PROTECTED]/email - roles -rolehelped in the Avalon CLI merge/role - /roles -/contributor -contributor - namePeter Maddocks/name - email[EMAIL PROTECTED]/email - organizationHewlett-Packard/organization - roles -rolesupplied patch/role - /roles -/contributor - /contributors - dependencies -!-- used in PatternOptionBuilder -- -dependency - groupIdcommons-lang/groupId - artifactIdcommons-lang/artifactId - version2.1/version -/dependency - !-- used for unit tests -- dependency groupIdjunit/groupId @@ -176,8 +110,8 @@ aspectSourceDirectory/ resources resource - directorysrc/java/org/apache/commons/cli2/directory - targetPathorg/apache/commons/cli2/targetPath + directorysrc/java/org/apache/commons/cli/avalon/directory + targetPathorg/apache/commons/cli/avalon/targetPath includes include**/*.properties/include /includes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r529031 - /jakarta/commons/proper/cli/branches/avalon-implementation/gump.xml
Author: sebb Date: Sun Apr 15 10:27:22 2007 New Revision: 529031 URL: http://svn.apache.org/viewvc?view=revrev=529031 Log: Not used for Avalon CLI Removed: jakarta/commons/proper/cli/branches/avalon-implementation/gump.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r529032 - /jakarta/commons/proper/cli/branches/avalon-implementation/build-gump.xml
Author: sebb Date: Sun Apr 15 10:27:38 2007 New Revision: 529032 URL: http://svn.apache.org/viewvc?view=revrev=529032 Log: Not used for Avalon CLI Removed: jakarta/commons/proper/cli/branches/avalon-implementation/build-gump.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r529044 - /jakarta/commons/proper/cli/branches/avalon-implementation/pom.xml
Author: sebb Date: Sun Apr 15 11:33:27 2007 New Revision: 529044 URL: http://svn.apache.org/viewvc?view=revrev=529044 Log: Create minimal POM Added: jakarta/commons/proper/cli/branches/avalon-implementation/pom.xml (with props) Added: jakarta/commons/proper/cli/branches/avalon-implementation/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/avalon-implementation/pom.xml?view=autorev=529044 == --- jakarta/commons/proper/cli/branches/avalon-implementation/pom.xml (added) +++ jakarta/commons/proper/cli/branches/avalon-implementation/pom.xml Sun Apr 15 11:33:27 2007 @@ -0,0 +1,95 @@ +?xml version=1.0 encoding=UTF-8? +!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the License); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +-- +project +xmlns=http://maven.apache.org/POM/4.0.0; +xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; +xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; + parent +groupIdorg.apache.commons/groupId +artifactIdcommons-parent/artifactId +version1/version + /parent + modelVersion4.0.0/modelVersion + groupIdcommons-cli-avalon/groupId + artifactIdcommons-cli-avalon/artifactId + version2.0-SNAPSHOT/version + nameCLI-Avalon/name + + inceptionYear2002/inceptionYear + description +Commons CLI (Avalon) provides a simple API for processing and +validating a command line interface. + /description + + urlhttp://jakarta.apache.org/commons/cli//url + + issueManagement +systemjira/system +urlhttp://issues.apache.org/jira/browse/CLI/url + /issueManagement + + scm + connectionscm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/cli/branches/avalon-implementation/connection + developerConnectionscm:svn:https://svn.apache.org/repos/asf/jakarta/commons/proper/cli/branches/avalon-implementation/developerConnection + urlhttp://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/avalon-implementation/url + /scm + + + dependencies + +!-- used for unit tests -- +dependency + groupIdjunit/groupId + artifactIdjunit/artifactId + version3.8.1/version + scopetest/scope +/dependency + +!-- used for unit tests -- +dependency + groupIdjdepend/groupId + artifactIdjdepend/artifactId + version2.5/version + scopetest/scope +/dependency + + /dependencies + + build +sourceDirectorysrc/java/sourceDirectory +testSourceDirectorysrc/test/testSourceDirectory +resources +resource + directorysrc/java/org/apache/commons/cli/avalon/directory + targetPathorg/apache/commons/cli/avalon/targetPath + includes +include**/*.properties/include + /includes +/resource +resource + directory./directory + targetPathMETA-INF/targetPath + includes +includeNOTICE.txt/include +includeLICENSE.txt/include + /includes +/resource +/resources + /build + +/project \ No newline at end of file Propchange: jakarta/commons/proper/cli/branches/avalon-implementation/pom.xml -- svn:eol-style = native Propchange: jakarta/commons/proper/cli/branches/avalon-implementation/pom.xml -- svn:keywords = Author Date Id Revision - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r529050 - /jakarta/commons/proper/cli/branches/avalon-implementation/doap_cli.rdf
Author: sebb Date: Sun Apr 15 12:24:53 2007 New Revision: 529050 URL: http://svn.apache.org/viewvc?view=revrev=529050 Log: Not used for Avalon CLI Removed: jakarta/commons/proper/cli/branches/avalon-implementation/doap_cli.rdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r529051 - /jakarta/commons/proper/cli/branches/avalon-implementation/build.xml
Author: sebb Date: Sun Apr 15 12:25:18 2007 New Revision: 529051 URL: http://svn.apache.org/viewvc?view=revrev=529051 Log: No longer reflects Maven.xml Removed: jakarta/commons/proper/cli/branches/avalon-implementation/build.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r529087 - /jakarta/commons/proper/cli/branches/avalon-implementation/src/conf/MANIFEST.MF
Author: sebb
Date: Sun Apr 15 15:58:56 2007
New Revision: 529087
URL: http://svn.apache.org/viewvc?view=revrev=529087
Log:
Fix properties
Modified:
jakarta/commons/proper/cli/branches/avalon-implementation/src/conf/MANIFEST.MF
(contents, props changed)
Modified:
jakarta/commons/proper/cli/branches/avalon-implementation/src/conf/MANIFEST.MF
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/avalon-implementation/src/conf/MANIFEST.MF?view=diffrev=529087r1=529086r2=529087
==
Binary files - no diff available.
Propchange:
jakarta/commons/proper/cli/branches/avalon-implementation/src/conf/MANIFEST.MF
--
svn:eol-style = native
Propchange:
jakarta/commons/proper/cli/branches/avalon-implementation/src/conf/MANIFEST.MF
('svn:mime-type' removed)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cli-avalon] svn commit: r529017 - /jakarta/commons/proper/cli/branches/avalon-implementation/src/conf/MANIFEST.MF
On 15/04/07, Rahul Akolkar [EMAIL PROTECTED] wrote: On 4/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: sebb Date: Sun Apr 15 10:18:33 2007 New Revision: 529017 URL: http://svn.apache.org/viewvc?view=revrev=529017 Log: CLI2 - Avalon Modified: jakarta/commons/proper/cli/branches/avalon-implementation/src/conf/MANIFEST.MF Modified: jakarta/commons/proper/cli/branches/avalon-implementation/src/conf/MANIFEST.MF URL: http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/avalon-implementation/src/conf/MANIFEST.MF?view=diffrev=529017r1=529016r2=529017 == Binary files - no diff available. snip/ Binary? Fixed - not sure how this happened (I did not create the file). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cli-avalon] svn commit: r529044 - /jakarta/commons/proper/cli/branches/avalon-implementation/pom.xml
On 15/04/07, Rahul Akolkar [EMAIL PROTECTED] wrote: On 4/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: sebb Date: Sun Apr 15 11:33:27 2007 New Revision: 529044 URL: http://svn.apache.org/viewvc?view=revrev=529044 Log: Create minimal POM Added: jakarta/commons/proper/cli/branches/avalon-implementation/pom.xml (with props) [...] Since this a new component, we should preferably discuss its creation (then have a vote if needed etc.). Not sure I follow that - all I've done is create a Pom so it can be built independently - the code has been in SVN for some while now, waiting for someone to do a release (please!) Sebb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons DBCP 1.2.2 (reprise)
On 25/03/07, Phil Steitz [EMAIL PROTECTED] wrote: I have fixed the JRockit test compatibility issue raised during the first DBCP 1.2.2 release vote and would like to kick off a new release vote based on RC3, with links provided below. Since RC2, the following changes have been made; * Fixed JRockit test compatibility issue (tested with Linux versions of jrockit-R27.1.0-jdk1.5.0_08, jrockit-R27.1.0-jdk1.4.2_12, and jrockit-jdk1.5.0_06) * Added a note to release notes and README calling out the lack of JDK 1.6 / JDBC 4.0 support * Fixed 'Built-By' manifest attribute The release zips/tarballs are here: http://people.apache.org/~psteitz/dbcp-1.2.2-RC3/ http://people.apache.org/%7Epsteitz/dbcp-1.2.2-RC1/ RC3 or RC1? Please note that, despite the release names, these distributions are *not* official apache releases, so should be used only for inspection/verification during the duration of this VOTE. Release notes: http://people.apache.org/~psteitz/dbcp-1.2.2-RC3/RELEASE-NOTES.txt http://people.apache.org/%7Epsteitz/dbcp-1.2.2-RC1/RELEASE-NOTES.txt RC3 or RC1? Web site: http://people.apache.org/~psteitz/dbcp-1.2.2-RC3/docs/ http://people.apache.org/%7Epsteitz/dbcp-1.2.2-RC1/docs/ RC3 or RC1? The svn tag is DBCP_1_2_2-RC3. Assuming a successful VOTE, I will copy the tag to DBCP_1_2_2 and move the distributions above to the mirrors. Votes, please. The vote will close end of day (GMT) 28-March-2007. Assuming the files are in the RC3 directory (not the RC1 directory given in the ) The src.zip contains the jar file - is that intentional? Also the java files in the src.zip have Unix line-endings rather than Windows ones. Not sure what the policy is on that. Thanks! Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cli] bug in parser(s)
On 16/03/07, Torsten Curdt [EMAIL PROTECTED] wrote: On 16.03.2007, at 05:28, Henri Yandell wrote: On 3/15/07, Torsten Curdt [EMAIL PROTECTED] wrote: IMO we should do a cli 1.0.1 bug release and get then get 2.0 out of the door ASAP. Someone needs to have the energy (and comprehension) to push them out. I get the CLI 1.x code and can do a 1.1 or 1.0.1 release; no one really seemed to be demanding it. I am :) ...this has been bugging a couple of times already. And I even dug into the code. So I would be happy to help with that too. But my main focus for now is to get jci out of the door ...and I don't want to wait for a cli release for that. When I started looking into CLI 2.x I found myself in the minority position of thinking it was worse than CLI 1.x so I quietly backed away from it. Really? Care to elaborate? What's the story with the branches again? I lost track. cli/ itself is cli2. cli-1.x/ is the active cli1 branch. cli-avalon/ or something like that.. that's what I called it on trunk/ is the avalon code that someone uses and loves (I forget who). We use it in JMeter, but we have our own copy in SVN. I copied the source to JMeter from Avalon, as there were some bugs we needed fixing for JMeter. Having fixed the bugs, it seemed to work fine for JMeter, so I thought it might be useful for others, and so it was provided as a patch for Commons CLI. Since JMeter has its own copy, it does not matter to us whether the CLI copy is ever released, but it seems a shame as it is working well for us. I had a look recently at SVN with a view to making a release of just the Avalon CLI but I got bogged down. There seemed to be a lot of stuff that was not related to Avalon CLI, and I don't know Maven. Note that the Avalon API is rather different from the CLI1/CLI2 APIs. Will have a look into that ...at some stage. All three need stake in the ground releases so N years of bugfixing can be stabilized. Sure - 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: [logging] 1.1.1 release?
On 13/03/07, Henri Yandell [EMAIL PROTECTED] wrote: On 3/12/07, Julius Davies [EMAIL PROTECTED] wrote: Hi, I've had the same problem. I *cannot* get 1.2 running on linux anymore. I hate to say it but the only way I can get 1.2 going these days is by installing it on Windows. Installs really nicely, to tell the truth. Yup. I hear you can patch your glibc on Linux, but I went with Windows for 1.2. Except I decided to be clever and install all versions on there and that screwed things up for some reason (1.6 was being too smart). Seems to work now though, so I can wince and do a build on Windows. The install process puts a copy of java.exe (and javaw.exe) in windows\system32 which can appear earlier in the classpath than your desired Java directory ... == I find it useful to define variables for each of the installed Javas(eg): JAVA142_HOME=C:\j2sdk1.4.2_13 JAVA150_HOME=C:\jdk1.5.0_11 JAVA160_HOME=C:\jdk1.6.0 I can then define JAVA_HOME as one of those, and add JAVA_HOME\bin to the path. I've got some JAVAxxx.CMD files that I use in DOS boxes to set the appropriate version - you're welcome to a copy, just let me know. S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r515317 - in /jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/params: TestParamsAll.java TestSSLTunnelParams.java
Author: sebb Date: Tue Mar 6 13:41:04 2007 New Revision: 515317 URL: http://svn.apache.org/viewvc?view=revrev=515317 Log: Add svn:eol-style native Modified: jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/params/TestParamsAll.java (props changed) jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/params/TestSSLTunnelParams.java (props changed) Propchange: jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/params/TestParamsAll.java -- svn:eol-style = native Propchange: jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/params/TestSSLTunnelParams.java -- svn:eol-style = native - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r512283 - in /jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri: compiler/ExpressionPath.java model/dom/DOMNodePointer.java
On 27/02/07, Matt Benson [EMAIL PROTECTED] wrote: --- [EMAIL PROTECTED] wrote: Author: mbenson Date: Tue Feb 27 07:35:26 2007 New Revision: 512283 URL: http://svn.apache.org/viewvc?view=revrev=512283 Log: fix broken nightlies that compile file on JDK 5 but not below due to my excessive fascination with the ternary operator. :| Er, compile fine, and A poor workman blames his tools. ;) BTW, SVN allows one to change the log comment ;-) S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r510581 - /jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/URI.java
Author: sebb
Date: Thu Feb 22 08:36:38 2007
New Revision: 510581
URL: http://svn.apache.org/viewvc?view=revrev=510581
Log:
Use super.clone() to ensure subclass clone() methods work
Make rootPath final
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/URI.java
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/URI.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/URI.java?view=diffrev=510581r1=510580r2=510581
==
---
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/URI.java
(original)
+++
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/URI.java
Thu Feb 22 08:36:38 2007
@@ -714,7 +714,7 @@
/**
* The root path.
*/
-protected static char[] rootPath = { '/' };
+protected static final char[] rootPath = { '/' };
// -- Generous characters for each component validation
@@ -3683,9 +3683,9 @@
*
* @return a clone of this instance
*/
-public synchronized Object clone() {
+public synchronized Object clone() throws CloneNotSupportedException {
-URI instance = new URI();
+URI instance = (URI) super.clone();
instance._uri = _uri;
instance._scheme = _scheme;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r510582 - /jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/server/SimpleHost.java
Author: sebb
Date: Thu Feb 22 08:42:43 2007
New Revision: 510582
URL: http://svn.apache.org/viewvc?view=revrev=510582
Log:
Use super.clone() to ensure subclass clone() methods work
Modified:
jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/server/SimpleHost.java
Modified:
jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/server/SimpleHost.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/server/SimpleHost.java?view=diffrev=510582r1=510581r2=510582
==
---
jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/server/SimpleHost.java
(original)
+++
jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/server/SimpleHost.java
Thu Feb 22 08:42:43 2007
@@ -53,12 +53,18 @@
public SimpleHost (final SimpleHost httphost) {
super();
-this.hostname = httphost.hostname;
-this.port = httphost.port;
+init(httphost);
}
-public Object clone() {
-return new SimpleHost(this);
+ private void init(final SimpleHost httphost) {
+ this.hostname = httphost.hostname;
+this.port = httphost.port;
+ }
+
+public Object clone() throws CloneNotSupportedException {
+ SimpleHost copy = (SimpleHost) super.clone();
+ copy.init(this);
+return copy;
}
public String getHostName() {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r510585 - /jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HostConfiguration.java
Author: sebb
Date: Thu Feb 22 08:52:16 2007
New Revision: 510585
URL: http://svn.apache.org/viewvc?view=revrev=510585
Log:
Use super.clone() to ensure subclass clone() methods work
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HostConfiguration.java
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HostConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HostConfiguration.java?view=diffrev=510585r1=510584r2=510585
==
---
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HostConfiguration.java
(original)
+++
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HostConfiguration.java
Thu Feb 22 08:52:16 2007
@@ -81,7 +81,11 @@
* @param hostConfiguration the hostConfiguration to copy
*/
public HostConfiguration (final HostConfiguration hostConfiguration) {
-// wrap all of the assignments in a synchronized block to avoid
+init(hostConfiguration);
+}
+
+ private void init(final HostConfiguration hostConfiguration) {
+ // wrap all of the assignments in a synchronized block to avoid
// having to negotiate the monitor for each method call
synchronized (hostConfiguration) {
try {
@@ -107,7 +111,14 @@
* @see java.lang.Object#clone()
*/
public Object clone() {
-return new HostConfiguration(this);
+ HostConfiguration copy;
+ try {
+ copy = (HostConfiguration) super.clone();
+ } catch (CloneNotSupportedException e) {
+throw new IllegalArgumentException(Host configuration could not
be cloned);
+ }
+ copy.init(this);
+return copy;
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r510587 - in /jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient: HttpHost.java ProxyHost.java
Author: sebb
Date: Thu Feb 22 08:56:08 2007
New Revision: 510587
URL: http://svn.apache.org/viewvc?view=revrev=510587
Log:
Use super.clone() to ensure subclass clone() methods work
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpHost.java
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/ProxyHost.java
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpHost.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpHost.java?view=diffrev=510587r1=510586r2=510587
==
---
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpHost.java
(original)
+++
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpHost.java
Thu Feb 22 08:56:08 2007
@@ -114,16 +114,23 @@
*/
public HttpHost (final HttpHost httphost) {
super();
-this.hostname = httphost.hostname;
+init(httphost);
+}
+
+ private void init(final HttpHost httphost) {
+ this.hostname = httphost.hostname;
this.port = httphost.port;
this.protocol = httphost.protocol;
-}
+ }
/**
+ * @throws CloneNotSupportedException
* @see java.lang.Object#clone()
*/
-public Object clone() {
-return new HttpHost(this);
+public Object clone() throws CloneNotSupportedException {
+ HttpHost copy = (HttpHost) super.clone();
+ copy.init(this);
+return copy;
}
/**
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/ProxyHost.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/ProxyHost.java?view=diffrev=510587r1=510586r2=510587
==
---
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/ProxyHost.java
(original)
+++
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/ProxyHost.java
Thu Feb 22 08:56:08 2007
@@ -74,10 +74,12 @@
}
/**
+ * @throws CloneNotSupportedException
* @see java.lang.Object#clone()
*/
-public Object clone() {
-return new ProxyHost(this);
+public Object clone() throws CloneNotSupportedException {
+ ProxyHost copy = (ProxyHost) super.clone();
+return copy;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r510589 - /jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/params/DefaultHttpParams.java
Author: sebb
Date: Thu Feb 22 09:04:52 2007
New Revision: 510589
URL: http://svn.apache.org/viewvc?view=revrev=510589
Log:
new Boolean() is inefficient
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/params/DefaultHttpParams.java
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/params/DefaultHttpParams.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/params/DefaultHttpParams.java?view=diffrev=510589r1=510588r2=510589
==
---
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/params/DefaultHttpParams.java
(original)
+++
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/params/DefaultHttpParams.java
Thu Feb 22 09:04:52 2007
@@ -209,7 +209,7 @@
}
public void setBooleanParameter(final String name, boolean value) {
-setParameter(name, new Boolean(value));
+setParameter(name, value ? Boolean.TRUE : Boolean.FALSE);//
Boolean.valueOf() = Java 1.4+
}
public boolean isParameterSet(final String name) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r507325 - /jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpClient.java
Author: sebb
Date: Tue Feb 13 16:12:43 2007
New Revision: 507325
URL: http://svn.apache.org/viewvc?view=revrev=507325
Log:
Remove redundant null check
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpClient.java
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpClient.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpClient.java?view=diffrev=507325r1=507324r2=507325
==
---
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpClient.java
(original)
+++
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpClient.java
Tue Feb 13 16:12:43 2007
@@ -153,9 +153,7 @@
}
this.params = params;
this.httpConnectionManager = httpConnectionManager;
-if (this.httpConnectionManager != null) {
-this.httpConnectionManager.getParams().setDefaults(this.params);
-}
+this.httpConnectionManager.getParams().setDefaults(this.params);
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r507324 - /jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpURL.java
Author: sebb Date: Tue Feb 13 16:12:11 2007 New Revision: 507324 URL: http://svn.apache.org/viewvc?view=revrev=507324 Log: password can be null Modified: jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpURL.java Modified: jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpURL.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpURL.java?view=diffrev=507324r1=507323r2=507324 == --- jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpURL.java (original) +++ jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpURL.java Tue Feb 13 16:12:11 2007 @@ -549,7 +549,8 @@ escaped user not valid); } String username = new String(escapedUser); -String password = new String(getRawPassword()); +char[] rawPassword = getRawPassword(); + String password = rawPassword == null ? null : new String(rawPassword); String userinfo = username + ((password == null) ? : : + password); String hostname = new String(getRawHost()); String hostport = (_port == -1) ? hostname : hostname + : + _port; @@ -644,7 +645,7 @@ throw new URIException(URIException.PARSING, username required); } String username = new String(getRawUser()); -String password = new String(escapedPassword); +String password = escapedPassword == null ? null : new String(escapedPassword); // an emtpy string is allowed as a password String userinfo = username + ((password == null) ? : : + password); String hostname = new String(getRawHost()); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r507323 - /jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/URI.java
Author: sebb
Date: Tue Feb 13 16:11:22 2007
New Revision: 507323
URL: http://svn.apache.org/viewvc?view=revrev=507323
Log:
Remove unnecessary String.toString()
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/URI.java
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/URI.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/URI.java?view=diffrev=507323r1=507322r2=507323
==
---
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/URI.java
(original)
+++
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/URI.java
Tue Feb 13 16:11:22 2007
@@ -2231,12 +2231,12 @@
_is_IPv6reference = false;
// set a registry-based naming authority
if (escaped) {
-_authority = original.toString().toCharArray();
+_authority = original.toCharArray();
if (!validate(_authority, reg_name)) {
throw new URIException(Invalid authority);
}
} else {
-_authority = encode(original.toString(), allowed_reg_name,
charset);
+_authority = encode(original, allowed_reg_name, charset);
}
} else {
if (original.length() - 1 next hasPort
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r507321 - /jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/util/URIUtil.java
Author: sebb
Date: Tue Feb 13 16:10:51 2007
New Revision: 507321
URL: http://svn.apache.org/viewvc?view=revrev=507321
Log:
Remove unnecessary String.toString()
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/util/URIUtil.java
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/util/URIUtil.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/util/URIUtil.java?view=diffrev=507321r1=507320r2=507321
==
---
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/util/URIUtil.java
(original)
+++
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/util/URIUtil.java
Tue Feb 13 16:10:51 2007
@@ -625,7 +625,7 @@
for (int i = from.length; i 0; --i) {
original = replace(original, from[i], to[i]);
}
-return original.toString();
+return original;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Status of components
On 07/02/07, Henri Yandell [EMAIL PROTECTED] wrote: I made a stab of defining the current status for Commons for the Jakarta board report: http://wiki.apache.org/jakarta/JakartaBoardReport-current Here's the summary. Any thoughts on the ?? marks and the dormancy candidates? Feel free to add things to the wiki page. I've not added all of this yet. Attributes - Needs a new release, after that a dormancy candidate. BeanUtils - Inactive. 1.8.0 slowly being worked on. Betwixt - Just released. Chain - ?? CLI - Inactive. Dormancy candidate? JMeter is currently using the same code as the Avalon CLI - which is mixed up in the rest of CLI2. There have been no reported problems for the CLI in JMeter for a long time now. It is not the same animal as CLI and CLI2, so perhaps it should be moved somewhere else? Can it be made a separate mini project in Commons? Seems a shame that the only use of the code is in JMeter at present. Once it has been released, it can remain happily in maintenance mode... I'm happy to do the work. Codec - Inactive. Collections - Inactive - new releases discussed but not much movement. Configuration - Active. Daemon - ?? Dormancy candidate? DBCP - 1.2.2 release in the works. DbUtils - 1.1 release made. No plans for 1.2. Digester - ?? Discovery - 0.4 release made, nothing new planned. Dormancy candidate. EL - ?? Dormancy candidate? Email - Maybe a 1.1 release in the works. Not much activity yet. FileUpload - 1.2 release in the works. IO - 1.3 just released. Jelly - ?? Dormancy candidate? Jexl - ?? Dormancy candidate? We're using it in JMeter. JXPath - ?? Dormancy candidate? Lang - 2.3 release in the works. Launcher - Inactive. Dormancy candidate. Logging - Needs a 1.1.1 release, no plans beyond that. Math - Slow activity. Modeler - Inactive - dormancy? Net - New JDK 1.5 version in the works. Pool - New version in the works. Primitives - Inactive. Dormancy candidate? SCXML - Active, just released. Transaction - Release being discussed. Validator - Active. VFS - Active and releasing. Dormant - Nothing likely to leave dormancy. Sandbox - Nothing that looks like moving to proper anytime soon. Some for dormancy (finder, id). - 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: [net] Latest 2.0 RC Ready
On 28/01/07, Rory Winston [EMAIL PROTECTED] wrote: (Resending as I left out commons-user) Hi all I have cut a new RC, with some changes and fixes, many of which were distribution-related and suggested by Niall earlier (thanks Niall). RC (minus MD5s etc for now) is here: http://people.apache.org/~rwinston/commons-net-2.0/ Some users have been testing out this 2.0 branch for a while, so I'm going to kick off a vote pretty soon. Any comments welcome. Some of the source files don't seem to have the correct license. For example: AllTests.java - no license TelnetTestSimpleServer.java - old license, with copyright years Looks like it is mainly (only?) the test tree that is affected. [There also seem to be a few classnames that start with lower-case letters, but there's probably not a lot can be done about that now.] S/// - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] exceptions and localization
On 29/01/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Selon Jörg Schaible [EMAIL PROTECTED]: [...] My bottom line: If you build an application, you have to do localization (of exception and logging) at the application layer, because only there you can give the user a context, that is really useful. +1 I think error messages belong to the information set that *may* be propagated to upper layers according to upper layers design choices. If upper layer is localized, lower layers should also be localized. I don't agree that this follows at all. S/// - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CLI-126) CLI2 should support multiple property args on command line
[ http://issues.apache.org/jira/browse/CLI-126?page=comments#action_12454307 ] Sebb commented on CLI-126: -- This could break exisiting scripts that rely on the current behaviour, so (if implemented) the existing method should return the last definition to maintain compatibility. What is the use case for this? CLI2 should support multiple property args on command line -- Key: CLI-126 URL: http://issues.apache.org/jira/browse/CLI-126 Project: Commons CLI Issue Type: Improvement Affects Versions: 2.0 Reporter: Sanjay Dahiya If I specify a command line like -Dsomekey=value1 -Xsomekey=value2, after parsing the value of somekey is overwritten as WritableCommandLine maintains a single set for all properties irrespective of switch. There should be a way of handling this case. CommandLine should probably return a set of all the switches from which we get properties. comments? I can submit a patch for this if its ok to make this change. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CLI-126) CLI2 should support multiple property args on command line
[ http://issues.apache.org/jira/browse/CLI-126?page=comments#action_12454391 ] Sebb commented on CLI-126: -- Sorry, my mistake - you are quite right. Brain not in gear. (I was thinking of -Dkey=val1 -Dkey=val2 ...) BTW, the Avalon CLI parser (as used in JMeter) supports this already. However, it has a very different API. CLI2 should support multiple property args on command line -- Key: CLI-126 URL: http://issues.apache.org/jira/browse/CLI-126 Project: Commons CLI Issue Type: Improvement Affects Versions: 2.0 Reporter: Sanjay Dahiya If I specify a command line like -Dsomekey=value1 -Xsomekey=value2, after parsing the value of somekey is overwritten as WritableCommandLine maintains a single set for all properties irrespective of switch. There should be a way of handling this case. CommandLine should probably return a set of all the switches from which we get properties. comments? I can submit a patch for this if its ok to make this change. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Tapestry and JCL
On 31/07/06, Henri Yandell [EMAIL PROTECTED] wrote: On 7/28/06, James Carman [EMAIL PROTECTED] wrote: ... Sure you could argue that log4j is more powerful, but the same could be said of ORO. Increasingly people just aren't going to care. We're starting to talk about moving to 1.3 so we can get the regexp support without a dependency ([io] for example), when do we start talking Surely java.util.regex requires 1.4? about 1.4 so we can drop the commons-logging dependencies? ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Splitting the mailing list
On 24/07/06, Henri Yandell [EMAIL PROTECTED] wrote: On 7/24/06, Simon Kitching [EMAIL PROTECTED] wrote: On Sat, 2006-07-22 at 21:53 -0700, Henri Yandell wrote: I had a thought just now on the multiple list concept - and a positive reason for splitting the lists in general. By having lists for commits, jira, wiki, ci etc filters become a lot, lot easier. Much easier for someone to come up with a list of commits they're interested in and we can have people who are interested in their own defined groupings while having to still see the general dev discussions as they come through. One problem is that of temporarily unsubscribing. We've all regularly seen what happens when someone goes on holiday for a few weeks and sets their email to auto-respond out of office without unsubscribing from these lists first. When there are 4 commons lists, how are people going to manage this? I believe one commonly used mailing list system provides a web page where you can suspend your subscriptions to all lists in one go. As far as I know, though, the apache system doesn't provide this. Don't use your work email for open source mailing lists :) I can only I'm surprised at how many companies (large ones too) let OOO e-mails outside their company boundaries. These can provide valuable information for social engineering purposes... see the out of office making sense if its a work email - otherwise I'd expect people to continue checking their mail or just let it build up. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ezmlm edit [was: How can I search the mailing list archive]
On 18/06/06, Phil Steitz [EMAIL PROTECTED] wrote: If you want to suggest contents for commons-dev-faq, we should be able to get that content added (maybe someone with more ezmlm-foo than me can give a clue on how to do this). As it happens, I found this out yesterday - if you have remote admin privs, you can send an e-mail to [EMAIL PROTECTED] For details of all editable files, try: [EMAIL PROTECTED] If your ASF mails are forwarded to GMail (say) you can add -asfid=apache.org (without ) just before the @ and the reply will be sent to the ASF address and thence to Gmail. That trick can be used with all ezmlm moderator commands (e.g. -list). S/// - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (COLLECTIONS-214) ExtendedProperties - field include should be non-static and private
ExtendedProperties - field include should be non-static and private --- Key: COLLECTIONS-214 URL: http://issues.apache.org/jira/browse/COLLECTIONS-214 Project: Commons Collections Type: Bug Versions: 3.2 Reporter: Sebb The field include in ExtendedProperties is currently static and protected, yet has instance get/set accessors. Given that there are accessors, it seems unnecessary for the field to be protected - it could be private. The field should also surely be non-static - or the accessors should be made static, if the field really is supposed to be shared among instances. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [csv] j2se1.3 compatibility / header line writer
On 22/05/06, Nicolas De Loof [EMAIL PROTECTED] wrote: It is supported in jdk1.3.. Just cast the stringbuffer passed in to an object, so like StringBuffer.append((Object) StringBuffer)). Much more efficient than an if... Surely a StringBuffer is already an Object? Or am I missing something here? StringBuffer has a new method in Java 1.4 to append another Stringbuffer without invoking it's toSring() method. Code that uses StringBuffer.append(stb) and compiled by a JDK 1.4 will not work on Java 1.3. I miself recommand Using StringBuffer.append(stb.toString()) that looks better than an apparently useless (Object) cast : checkstyle or IDE may warn for unecessary cast. But that won't work so well on Java 1.4+. Can't one just use: sb1.append(sb2); for both 1.3 and 1.4, and let the method do the work as needed? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [csv] j2se1.3 compatibility / header line writer
OK, I see. Whatever method is chosen, it's worth documenting the reasons for the strange coding... If a release is being built to support 1.3 and above, it might be worth using the 1.3 compiler - or at least using the 1.3 jars. S. On 22/05/06, Martin van den Bemt [EMAIL PROTECTED] wrote: That just works when compiling on jdk1.3 and will not work on jdk1.3 when compiled on jdk1.4 To prevent this, you specifically have to cast it to object to say use the append which takes an object or as Nicolas suggested a toString(), but the last one is not my favorite solution.. Mvgr, Martin sebb wrote: On 22/05/06, Nicolas De Loof [EMAIL PROTECTED] wrote: It is supported in jdk1.3.. Just cast the stringbuffer passed in to an object, so like StringBuffer.append((Object) StringBuffer)). Much more efficient than an if... Surely a StringBuffer is already an Object? Or am I missing something here? StringBuffer has a new method in Java 1.4 to append another Stringbuffer without invoking it's toSring() method. Code that uses StringBuffer.append(stb) and compiled by a JDK 1.4 will not work on Java 1.3. I miself recommand Using StringBuffer.append(stb.toString()) that looks better than an apparently useless (Object) cast : checkstyle or IDE may warn for unecessary cast. But that won't work so well on Java 1.4+. Can't one just use: sb1.append(sb2); for both 1.3 and 1.4, and let the method do the work as needed? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] activation and javamail
The source may be released under CDDL, but as far as I can make out, distribution of the binaries still has the old licence. For JavaMail 1.4, this includes the following paragraph: g) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Redistributable. Seems potentially rather expensive. The only JAF download I can find at present is 1.1 Early Release and not for redistribution. It even says 3.4 Licensee shall have no right to use the Licensed Software for productive or commercial use. Perhaps Sun are in the process if changing the binary licenses, but that's not yet apparent. S. On 03/05/06, Torsten Curdt [EMAIL PROTECTED] wrote: Hurray! http://weblogs.java.net/blog/kohsuke/archive/2006/05/javamail_and_ac.html Could someone add that to email, please? cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release RC10 As Commons Logging 1.1
On 27/04/06, Simon Kitching [EMAIL PROTECTED] wrote: On Wed, 2006-04-26 at 21:34 +0100, robert burrell donkin wrote: after some investigation, the issue which turned up with RC8 was determined not to be a bug. notes have been added to the troubleshooting documentation. RC10 is available from: http://people.apache.org/~rdonkin/commons-logging. please download, check and then vote. What's the file commons-logging-1.1-RC10-ide.zip in commons-logging-1.1-RC10.zip for? The files in it don't have the leading directory name which is present in the top-level zips. i will tally the votes no earlier than 2300GMT Wednesday 3rd Mat 2006 [X] +1 Release Candidate 10 As JCL 1.1 - 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: [all] Clover version
But surely LGPL code cannot be distributed by the ASF, which means it cannot be stored in SVN? On 25/04/06, Brett Porter [EMAIL PROTECTED] wrote: Cobertura (at least in the Maven plugins), is executed via a fork, so the licensing is not an issue. - Brett Brian K. Wallace wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A question about licensing and control of Cobertura: With part of it being GPL'ed, is it possible to control it in a project's SVN? I remember some headway made in controlling LGPL as long as it's not a required part of the software but can't find the link to the page and don't remember the details well enough to be sure. [this may answer the what about switching question :-/] Brian Gary Gregory wrote: What about switching to Cobertura? http://cobertura.sourceforge.net/ Gary -Original Message- From: Brian K. Wallace [mailto:[EMAIL PROTECTED] Sent: Monday, April 24, 2006 2:22 PM To: Jakarta Commons Developers List Subject: [all] Clover version I saw a thread on this from (almost) a year ago with no visible resolution - so here goes again. :-) The current version of the clover.jar in the committer's repo is version 1.3.2. This version will not compile annotations (and results in an NPE if attempted). (Is it possible / What will it take) to get a newer version of clover? The license file states it's valid for 0.x and 1.x - the latest 1.x (as of this writing) is 1.3.12 (which does compile annotations properly). Brian -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFETh+UaCoPKRow/gARAsVyAJwPIT6J/GW06FvLDTM52pYy6klWkwCg1DFg ytquH7563kLw7WZ4Tnv2K8c= =b0HJ -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cli] [patch] build bug
On 19/04/06, Henri Yandell [EMAIL PROTECTED] wrote: On 4/19/06, Andrew Shirley [EMAIL PROTECTED] wrote: On Wed, Apr 19, 2006 at 09:36:49AM +1000, [EMAIL PROTECTED] wrote: Hi Henri, What do you think? Is the cli2 package clearly superior to the cli[1] package? I think so. There doesn't seem to be any advantage to cli[1], cli2 is better designed and the avalon code appears to be simpler (I havn't actually used it). Should we dump the old one, test the issues reported against cli[1] that are now fixed in cli2 and move on; or should we dump the cli2 package and stick with the cli one? This is a tricky question, because people already use the current CLI API. The CLI2 API is quite different, so people would have to migrate their code to the new API, and I can imagine that a lot of people would be loathe to do that. I think we should investigate the possibility of having CLI as a façade to the (superior) CLI2 package. This could ease migration problems, as well as solve the outstanding parsing issues. My vote is to move towards CLI2, but do it in such a way that we can avoid disturbing users of CLI as much as possible. My gut instinct is that it shouldn't be too difficult to effectively reimplement cli1 using cli2 as I havn't encountered anything that can be done in cli but not cli2. Generally, I think we should be moving away from cli1 whether that is by simply deprecating it or reimplementing it as a facade Seems to be pretty overwhelmingly in favour of cli2 - good to hear that people are using it and are happy. Another option is to split the two packages up and keep cli1 on a branch. Then we can do a cli1.1 release, but for a lot of the bugs we'll just be saying Sorry, move to cli2. Another question - why keep the Avalon logger? (Presuming we were to release cli 2.0 and an easier cli 1.1). What's its raison d'etre? [It's not a logger ...] Because projects may still be using it. And it works, and has a fairly extensive test package, and (hopefully) adequate documentation. It just needs to be packaged and released. When I looked at converting JMeter to CLI, it seemed to be a lot of effort, as the way the options are defined is very different. CLI2 was not ready at the time, so I did not investigate that. Converting from the original Excalibur Avalon version to the updated Avalon version merely requires changing at most 4 import statements. JMeter has its own copy of the source, as the commons-cli version has not been released. So it does not matter to us if it is dropped. But it seems a shame to force other projects to change to a different package merely to get an updated CLI parser. But maybe there are no other projects using it. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cli] [patch] build bug
On 18/04/06, Henri Yandell [EMAIL PROTECTED] wrote: On 4/18/06, Andrew Shirley [EMAIL PROTECTED] wrote: On Thu, Apr 13, 2006 at 07:46:24PM +0100, sebb wrote: Might I suggest you create a Bugzilla patch and then attach the files to it? On 13/04/06, Andrew Shirley [EMAIL PROTECTED] wrote: I have just tried entering this in bugzilla but the post_bug.cgi was 404ing! I tried this again this morning and bugzilla is working fine. http://issues.apache.org/bugzilla/show_bug.cgi?id=39334 About 5 days ago would be when it was being moved from one machine to the other. For the last year or so the machine the bug trackers were running on was under heavy load - often not for their own fault. Google hitting the mailing list archives has the hard drives pretty spun out :) So I imagine this migration and/or instability before hand is what you hit - sorry about that. Should be better now that it's on a new box and only issue tracking probelms can hurt it. Course, there are about 6 issue trackers on there now, 3 jira, 2 bugzilla and 1 scarab :). I know you're not getting much noise back on the CLI issues, but it's definitely appreciated. One style you'll notice in Commons is that many developers hop from project to project, choosing a project based on the number of issues that have built up. Lang's my current target, and if I knew which direction to take CLI, it'd be next. What do you think? Is the cli2 package clearly superior to the cli[1] package? Should we dump the old one, test the issues reported against cli[1] that are now fixed in cli2 and move on; or should we dump the cli2 package and stick with the cli one? There's a 3rd package, which is the Avalon one as used in JMeter. Perhaps it needs to be renamed, as it currently appears to be part of cli[1], and it is not. It's also the one that is probably the most mature, having started life as Excalibur Avalon. But that's not to say that CLI[2] is not worth pursuing. IIRC, it offers a choice of command-line syntax options; whereas Avalon just has the one. CLI[1] seemed to me to be in need of a lot of work when I looked at it a year or so ago. I did not look at CLI[2] in any detail. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cli] [patch] build bug
Might I suggest you create a Bugzilla patch and then attach the files to it? Unless anyone deals with the patches in the near future, they are likely to get lost amongst all the rest. It's also a lot easier when applying patches to refer to a Bugzilla issue in the commit messages. S. On 13/04/06, Andrew Shirley [EMAIL PROTECTED] wrote: Hi, I have just tried entering this in bugzilla but the post_bug.cgi was 404ing! When running ant test org.apache.commons.cli2.resource.ResourceHelperTest was failing as it needs a .properties file copying from src/test to target/test-classes/ I have created a patch to build.xml (attached) which has a copy which copies .properties files for tests in much the same way as the existing one for src/java If there is anything else I can do just email. cheers Andrew Shirley - 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: [all] Suggestion for all of Commons
On 30/03/06, Phil Steitz [EMAIL PROTECTED] wrote: On 3/29/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/29/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 3/29/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/29/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 3/29/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Or maybe we should simply advertise the dependencies pages better? Dependencies should be listed on the download page. The mind set of someone wanting to to use a component is and I know this from having done it a dozen or so times: I've come to believe that dependencies should be included in the distribution. Also that we shouldn't bother with binary and source distributions anymore; be like tapestry/hivemind (I think they're the ones) and have just the one dist file. I'm almost cool with that. I'd be happy with a full download (binary.jar, sources, docs, etc) and just the raw binary.jar 85% of the time downloading the binary distrobution is just an extra step to get to what I want: the binary.jar Yeah, +1. I tend to go to ibiblio to get downloads half the time now; sad :) Definitely valuable to be able to download just the jar, especially for Commons things. If you don't like ibiblio, you can of course always use http://www.apache.org/dist/java-repository/ Bundling dependencies is a last century waste of bandwidth, IMHO. I agree though that making it clear what they are is important. Might we worth a maven ticket to get them moved up in the default nav . I vaguely remember this being discussed before either here or on maven-user. +1 Why not include it in the Download section of the navigation - e.g: Download * Releases (mirrored) * Nightly snapshots + Dependencies - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On 29/03/06, Martin Cooper [EMAIL PROTECTED] wrote: On 3/29/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/29/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 3/29/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Or maybe we should simply advertise the dependencies pages better? Dependencies should be listed on the download page. The mind set of someone wanting to to use a component is and I know this from having done it a dozen or so times: +1 I've come to believe that dependencies should be included in the distribution. Also that we shouldn't bother with binary and source distributions anymore; be like tapestry/hivemind (I think they're the ones) and have just the one dist file. -1 if that is the only archive type made available Urk. No thanks. If I download a couple of Commons components, and they share a couple of dependencies, and the bundled versions of those dependencies are different, what should I, as a user, do? I think that would just cause more confusion within the user base. +1 As for having just a single distribution, I'm not in favour of that either. The vast majority of users don't give a dickey bird about the source, and it just bulks up the distribution, and therefore the size of the end user's distribution as well. I doubt our users will thank us for increasing the size of their own applications, potentially increasing their bandwidth usage for customers to download their products. +1 Seems to me the binary download should be the minimum needed to run the component; the source download should not include any jars that are in the binary download. Depending on the component, potentially put the javadoc in a separate jar. -- Martin Cooper 1. Find the component's site. 2. Find the download link on the site. 3. See want they want to download (src/bin, tar/zip) 4. Unpack 5. Find the jar and add it to their project. Step #3 is where we have the most cranial activity available to us and we should take advantage of that. Any other step and the end user is just going through the motions trying to get their work done with as little effort as possible. Agreed. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] Inspecting an RC
Some suggestions for the checklist: * 3rd party jars and licences * do the MD5 and PGPs work OK? * do the archives contain everything that is needed? For example, if there are source and binary jars, then the union of the two should produce a set of files that includes everything in the repository. * do the archives contain anything they shouldn't? E.g. unversioned source files, test logs etc. * if there are multiple archives, does each contain what is necessary and sufficient, or is there some duplication that could be eliminated? HTH S. On 28/03/06, Henri Yandell [EMAIL PROTECTED] wrote: Anyone mind if I split the Things To Look For When Inspecting A Release Candidate section of http://jakarta.apache.org/commons/releases/prepare.html into its own page? And add in some bits about Phil's tools (I've been making modifications to them, hope you've been noticing Phil :) ). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [RESULT] Demote Latka and Resources to Dormant
On 14/03/06, Stephen Colebourne [EMAIL PROTECTED] wrote: I suggest that a discussion about renaming Dormat to Unmaintained starts in a new thread. How about Doormat instead ;-) [Sorry ...] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons IO 1.2 (based on RC3)
On 13/03/06, Henri Yandell [EMAIL PROTECTED] wrote: Errors are: [...] Testcase: testGetFreeSpace_String(org.apache.commons.io.FileSystemUtilsTestCase): FAILED expected:9.4452176E7 but was:4.7226088E7 junit.framework.AssertionFailedError: expected:9.4452176E7 but was:4.7226088E7 at org.apache.commons.io.FileSystemUtilsTestCase.testGetFreeSpace_String(FileSystemUtilsTestCase.java:68) The problem here is that OS X uses 512 byte block sizes, not 1k as the test assumes. So no way it'll pass. BTW, OpenVMS also uses a 512 byte block size. S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] MD5 and PGP generation [Was: [feedparser] News / Status]
On 03/03/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/2/06, Simon Kitching [EMAIL PROTECTED] wrote: On Thu, 2006-03-02 at 14:50 -0800, Henri Yandell wrote: We're not supposed to be using the pgp on minotaur; so my TODO is to figure out how to get my key off of there, hope I still know the passphrase, i hope so too :) there are various ways to export the key but copying the files should work fine too. Advice is to revoke it - as who knows what you evil buggers have been doing to it :) It's not because people with access to minotaur are untrustworthy that keys shouldn't be there :-) That was one of the reasons I was given :) It's that if the key is on there, someone who hacks that machine has *both* the key *and* the ability to publish what would seem to be official releases. The solution to that is easy though. Two apache machines. So must be more than that. If releases are signed on committers private machines, then this is more than two machines ... and each private machine will only have a few private keys on it. By the by, generating the signing keys with a short life-span (1-2 years) should help protect in the long term. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] MD5 and PGP generation [Was: [feedparser] News / Status]
Here's an Ant target we use in JMeter for creating MD5 checksums:
!--
Utility target to create MD5 checksums in standard format (with *filename)
Usage:
antcall target=_md5
param name=path value=${dist.dir}/${dist.name}_src.tar/
/antcall
--
target name=_md5 unless=md5.skip
echo message=Creating MD5 for ${path}/
basename property=_base file=${path}/
checksum file=${path} property=md5/
echo message=${md5} *${_base} file=${path}.md5/
/target
Creating a PGP key is as simple as:
$ gpg -ba file
or using the verbose flags:
$ gpg --armor --output foo.tar.gz.asc --detach-sig foo.tar.gz
once you have installed GnuPG (which is not all that difficult)
See: http://www.apache.org/dev/release-signing.html
S.
On 02/03/06, Henri Yandell [EMAIL PROTECTED] wrote:
md5 bit is easy, given a command line. It's also easy to write Java
for, and I suspect Maven 2 will easily be doing that for us.
PGP is the thing that stops me doing releases. I accept that it's
important, but that hasn't helped me grokk how to do it.
Hen
On 3/2/06, James Carman [EMAIL PROTECTED] wrote:
I would have to agree that the release process is a bit daunting. That's
why I haven't released Commons Proxy 1.0 yet. I really don't know how to do
all of that stuff on the release preparation document (md5 signatures and
the like).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cli] Moving forward
The repository also contains a version of Avalon Excalibur CLI (as used in JMeter). There were some bugs in the Avalon code, and there did not seem to be any likelihood of any fixes, so we imported the source into JMeter, and fixed the bugs (and test cases). Just in case someone else might find it useful, the code was copied to the CLI repository - see: http://issues.apache.org/bugzilla/show_bug.cgi?id=34672 for the contribution. It would be nice if there could be a release of this - we could import the jar and drop the source from JMeter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] please check release candidate 1
On 23/01/06, robert burrell donkin [EMAIL PROTECTED] wrote: BTW does anyone know a reliable way to convert unix-windoz file endings for text file endings? (i know stephen prefers zip's to use windoz format.) Can't you use the Ant fixcrlf task with eol=dos or eol=crlf? S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] Trouble updating main Jakarta site
On 20/12/05, Phil Steitz [EMAIL PROTECTED] wrote: I am getting a troubling number of html diffs after generating the main Jakarta site locally. Lots of single character changes and various flavors of lines like this: -hr size=1 noshade=noshade/ +hr noshade=noshade size=1/ I thought I had fixed this a while back by ensuring that tags with more than one attribute are defined using nested xsl:attribute elements - see the comments at the top of site.xsl, and the CheckXSL target in build.xml. Seems there is a new xsl sheet (news2content.xsl) which does not follow this strategy. However, this only affects the files news-2005-q[34].html files. [I'll fix it shortly] Did you find problems with other generated HTML files? S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][POLL] what files to fixcrlf for windows distributions
On 27/11/05, Phil Steitz [EMAIL PROTECTED] wrote:
snip
I am working on a patch to the maven dist plugin that makes the crlf
filter property configurable. Arnaud pointed out in another thread
that there should probably a similar filter applied to make sure lf
line endings are used in the tar.gz distros. My inclination is to
apply this to *all* files in the tar.gz distros by default. It occurs
Won't this cause corruption of .jar, .class, .jpg, etc files?
Doh! Good point. Would need to exclude at least these.
to me now that because of the eol=native svn props, RMs who cut
releases on Windows are likely making tars with crlf line endings
(since svn will convert files to crlf on checkout). Note that this
applies to ant as well as maven-built distros.
And RMs who use Unix will be creating zips with LF line endings...
Yes, IIUC, that is the consequence of using eol=native. Having the
file contents of distros different depending on the OS used to cut the
release does not seem like a good thing to me. Could be I have
Agreed. But we are talking about different contents for the zip and
tar.gz releases.
something wrong here. Maybe someone who has both unix and Windows
boxes set up can test and see if the the Windows-built distros (from
Windows checkouts) end up with CRLF everywhere (at least for files
with eol=native).
[Are there any who use Macs?]
I will make the unix filter configurable as well, but want feedback on
what the default should be, as well as what our policy should be in
commons on line endings in tar.gz as well as zip distros.
Ideally the default would depend on the svn:eol-type.
i.e. if svn:eol-type=native, then convert the file for the appropriate
native format, otherwise leave alone.
Dunno whether this can be made to work or not, though.
But this would still result (again, assuming I have it right) in
different line endings in distros depending on what OS was used to cut
the release - unless we all set up Windows boxes to cut the zip
releases and *nix boxes for the tarballs ;-)
Hopefully not - I assumed that the maven/ant task would change the
line-endings as needed, so as to create an archive that was the same
as if it had been created on an OS with a different native setting.
That's why it needs to know what SVN has done.
It's possible that a particular file type may have different endings
for different files.
For example on JMeter, the old JMX files were CRLF on Windows, but the
new JMX files are LF on all OSes.
Is this specified in the svn eol props for these files?
Yes (or it should be).
It now occurs to me that assuming my understanding of how eol=native
is correct, we should be fixing crlf for non-txt files in zip distros
I assume you mean files with an extension that is not .txt here ...
as well, since if these are cut using Windows, e.g. the java source
files will have CRLF line endings. So, in terms of properties, it
seems we need
maven.dist.lf.filter=**/*.java, **/*.txt, all other non-binary file
specs, i.e. all files that could have eol=native
maven.dist.crlf.filter=**/*.txt (plus whatever else we agree on)
and have the plugin do the following:
For tar.gz distributions, run fixcrlf with eol=lf and
includes=${maven.dist.lf.filter}
For zip distributions, run fixcrlf first with eol=lf and
includes=${maven.dist.lf.filter} and then again with eol=crlf and
includes=${maven.dist.crlf.filter}.
If one can use svn:eol-type, then this can all be automated, as the
eol-type will determine whether or not the line endings have been
changed by SVN.
I guess another alternative would be to agree to cut all distros on
unix, maybe even using minotaur to do the release builds (I know this
would have some practical problems associated with it now). Then all
we would need is the first property, assuming we want lf line endings
everywhere else (IIRC, in the cvs days, that was the standard).
Sorry if I have misunderstood the way the svn client works or if
others view this as a non-issue. I just want to patch the plugin so
that we can get consistent distros built using maven.
And Ant, ideally.
Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][POLL] what files to fixcrlf for windows distributions
On 27/11/05, Phil Steitz [EMAIL PROTECTED] wrote: On 11/15/05, Stephen Colebourne [EMAIL PROTECTED] wrote: Mario Ivankovits wrote: [X] .txt [ ] .java [ ] .properties [ ] .xml [ ] .css [ ] .mf My preference is for all ASCII files not in the src/java or src/text folders to be converted. Note that I doubt [collections] or [io] do this fully yet. Stephen I am working on a patch to the maven dist plugin that makes the crlf filter property configurable. Arnaud pointed out in another thread that there should probably a similar filter applied to make sure lf line endings are used in the tar.gz distros. My inclination is to apply this to *all* files in the tar.gz distros by default. It occurs Won't this cause corruption of .jar, .class, .jpg, etc files? to me now that because of the eol=native svn props, RMs who cut releases on Windows are likely making tars with crlf line endings (since svn will convert files to crlf on checkout). Note that this applies to ant as well as maven-built distros. And RMs who use Unix will be creating zips with LF line endings... [Are there any who use Macs?] I will make the unix filter configurable as well, but want feedback on what the default should be, as well as what our policy should be in commons on line endings in tar.gz as well as zip distros. Ideally the default would depend on the svn:eol-type. i.e. if svn:eol-type=native, then convert the file for the appropriate native format, otherwise leave alone. Dunno whether this can be made to work or not, though. It's possible that a particular file type may have different endings for different files. For example on JMeter, the old JMX files were CRLF on Windows, but the new JMX files are LF on all OSes. This all assumes that tar.gz is for Unix and .zip for Windows users - not unreasonable, but should probably be documented somewhere (perhaps it is ?). Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] LRUBug
On 22/11/05, Phil Steitz [EMAIL PROTECTED] wrote: On 11/21/05, Stephen Colebourne [EMAIL PROTECTED] wrote: robert burrell donkin wrote: i've been running the SOAK tests for over 7 days now without a problem. Just to report that I have run the synchronized soak test using 5 threads and 10,000,000 loops on AlphaServer 4X00 5/400 4MB, 4 CPUs Running OpenVMS 7.3-1 java version 1.4.0 Java(TM) 2 Runtime Environment, Standard Edition Fast VM (build 1.4.0-1, build J2SDK.v.1.4.0:01/10/2003-09:47, native threads, jit_140) This took about 8 minutes. The unsynchronized test fails rapidly with just 2 threads: java.lang.NullPointerException at org.apache.commons.collections.map.AbstractLinkedMap.removeEntry(AbstractLinkedMap.java:292) at org.apache.commons.collections.map.AbstractHashedMap.removeMapping(AbstractHashedMap.java:542) at org.apache.commons.collections.map.AbstractHashedMap.remove(AbstractHashedMap.java:324) at SoakLRUMapUn.soak(SoakLRUMapUn.java:69) at SoakLRUMapUn.run(SoakLRUMapUn.java:80) at java.lang.Thread.run(Thread.java:536) HTH. S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pool] synchronization issues in Pool
On 24/10/05, Sandy McArthur [EMAIL PROTECTED] wrote:
On 10/23/05, robert burrell donkin [EMAIL PROTECTED] wrote:
are there any pool developers out there with time to pick this up?
otherwise, we could probably do with a volunteer to go through and
analyse these issues. anyone fancy taking a crack at this?
I'm not a pool dev but I'll make some time to implement fixes for the
problems Mayur Naik found and submit patches.
While I'm at it would it be desirable to transition to the privately
head lock idiom to defend against intentionally malicious code? eg to
defend against:
synchronized (aPool) {
Thread.sleep(Integer.Max_Value);
}
by making anything that synchronized on this synchronize on a private field.
+1 If possible, but one cannot always do this.
If a class is conditionally thread-safe, i.e. it needs external
synchronisation - then the appropriate lock object must be made
available to clients. E.g. HashTable needs external synch for its
Iterator [Bloch, Item 52]
S.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pool] synchronization issues in Pool
On 23/10/05, Stephen Colebourne [EMAIL PROTECTED] wrote: My main question is can these tests be run against any class? We're particularly stuck with http://issues.apache.org/bugzilla/show_bug.cgi?id=32573 collections LRUMap at present where a bug can easily be reproduced when you don't sync, but not at all when you do sync. Yet we have bugs reported! So, is The issue is not clear to me on the exact circumstances when the reported bugs do occur: - do problems ever occur in single-threaded use? - if problems only occur in multi-threaded use, is access synchronized? and, just as important: - are all uses of Iterators synchronized on the map? See for example: http://java.sun.com/j2se/1.4.2/docs/api/java/util/Collections.html#synchronizedMap(java.util.Map) HTH. S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pool] synchronization issues in Pool
On 23/10/05, robert burrell donkin [EMAIL PROTECTED] wrote: On Sun, 2005-10-23 at 14:56 +0100, Stephen Colebourne wrote: This looks interesting. I'll leave the pool comments to a pool developer. However, could adding a lot more synchronoization could cause other issues with locking and performance? probably. however, IMHO an object pool really needs to be thread safe. i've taken a quick look and think that perhaps it'd be better to fix any race conditions as the performance price that has to be paid for the design chosen. opinions? As Knuth put it ... premature optimization is the root of all evil. And Jackson: Rule 1. Don't do it Rule 2. (for experts only). Don't do it yet - that is, not until you have a perfectly clear and unoptimized solution. [From Bloch, Effective Java, Item 37] It's not only race conditions that might need to be fixed - Synchronization is required for reliable communication between threads as well as for mutual exclusion. [Ibid, Item 48] He says that modern JVMs have much lower overheads for synchronisation than the early releases, especially if the synchronisation is uncontended, as would be the case for single-threaded access. So I'd suggest doing enough synch to ensure that the user can use all the methods individually without needing to synchronise. Iterators would likely still need external synch (except when running single-threaded). are there any pool developers out there with time to pick this up? otherwise, we could probably do with a volunteer to go through and analyse these issues. anyone fancy taking a crack at this? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
