[all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
Sorry, but I have to agree with Niall on this - needs to be 2.0 with the incompatible changes - and I would like very much for us to agree once and for all on some versioning/deprecation rules. We seem to have lost the old versioning guidelines (unless I am senile, we used to have these on the commons or Jakarta pages somewhere). Apart from 0), which is a conservative but worth-considering-carefully PoV, the rules below are more or less what we have been adhering to over the last several years in commons and I would like to propose that we standardize on them. If all are OK, I will gin up a versioning page. A very good one, which is pretty much a C version of what I am proposing below, is http://apr.apache.org/versioning.html. 0) Never break backward source or binary compatibility - i.e., when you need to, change the package name. 1) 0 is going to have to fail sometimes for practical reasons. When it does, fall back to a) no source, binary or semantic incompatibilities or deprecations introduced in a x.y.z release b) no source or binary incompatibilities in an x.y release, but deprecations and semantic changes allowed c) no removals without prior deprecations, but these and other backward incompatible changes allowed in x.0 releases. This means that the [cli] release with the current changes would need to be 2.0. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CLI-21) [cli] clone method in Option should use super.clone()
[
https://issues.apache.org/jira/browse/CLI-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504139
]
Brian Egge commented on CLI-21:
---
Properly supporting Cloneable is fairly trivial. Previously I submitted a
patch which includes a proper implementation and test case. See:
https://issues.apache.org/jira/secure/attachment/12358085/Cloneable.patch
There's some other code in the patch which does not need to be included. In
practice usually the CLI library is only invoked once at startup, so it doesn't
matter that some classes aren't quite immutable. However, in unit testing, the
options may be reused.
I have some code which looks like this:
abstract class CommandLine {
protected static final Option URL = new Option(u, url, true, url);
}
I'll then share this option in various subclasses. In my unit tests, it would
be best if I don't alter the original static option. In this situation having
a clone option might be helpful. The better solution would probably just be
not to make it static and forget about cloning altogether.
I'm not opposed to removing clone, but I don't see a strong enough reason here
to break compatibility.
[cli] clone method in Option should use super.clone()
-
Key: CLI-21
URL: https://issues.apache.org/jira/browse/CLI-21
Project: Commons CLI
Issue Type: Bug
Components: CLI-1.x
Affects Versions: 1.0
Environment: Operating System: other
Platform: Other
Reporter: Nathan McDonald
Fix For: 1.1
In
org.apache.commons.cli.Option
public method clone is implemented by creating a new instance through one of
the class Constructors, and then assigning values as required through the
setter methods.
This means that any subclasses of the Option class will not return a true
clone, but a new Option instance instead.
A proper implementation of clone should use super.clone() to create a new
instance, rather than calling the class constructor. This allows shallows
clones to propogate correctly down to subclasses.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CLI-21) [cli] clone method in Option should use super.clone()
[ https://issues.apache.org/jira/browse/CLI-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504143 ] Ben Speakmon commented on CLI-21: - My comment from the mailing list thread: Implementing clone() properly is a pain and hard to get right. If someone really needs distinct copies of Option classes (why?!), I'd suggest providing a copy constructor instead. If compatibility is a really big deal, you could change clone() to call Object.clone(), which throws an exception. Think of it as a gentle hint to the user not to use the method anymore -- and the exception message could also point out the new copy constructor. [cli] clone method in Option should use super.clone() - Key: CLI-21 URL: https://issues.apache.org/jira/browse/CLI-21 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.0 Environment: Operating System: other Platform: Other Reporter: Nathan McDonald Fix For: 1.1 In org.apache.commons.cli.Option public method clone is implemented by creating a new instance through one of the class Constructors, and then assigning values as required through the setter methods. This means that any subclasses of the Option class will not return a true clone, but a new Option instance instead. A proper implementation of clone should use super.clone() to create a new instance, rather than calling the class constructor. This allows shallows clones to propogate correctly down to subclasses. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: centralized KEYS file?
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. 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]
[commons-compress] a release
Hello all, I would like to know if a release is planned for this project as I'm interested. Thanks for your answers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TRANSACTIONS-16
Dennis Thrysøe dth at conscius.com writes: I am unsure how resource enlistment to the TransactionManager should work, as mentioned in a comment in jira. For now the collections enlist themselves, when created. What's the best way to go about this? I guess there must be some j2ee-mandated way of enlisting a resource? Just answering that one at the moment: http://jroller.com/page/pyrasun?entry=xa_exposed Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
- Original Message From: Phil Steitz [EMAIL PROTECTED] I would like very much for us to agree once and for all on some versioning/deprecation rules. Exactly the thread I was about to start :-) We seem to have lost the old versioning guidelines (unless I am senile, we used to have these on the commons or Jakarta pages somewhere). Apart from 0), which is a conservative but worth-considering-carefully PoV, the rules below are more or less what we have been adhering to over the last several years in commons and I would like to propose that we standardize on them. If all are OK, I will gin up a versioning page. A very good one, which is pretty much a C version of what I am proposing below, is http://apr.apache.org/versioning.html. 0) Never break backward source or binary compatibility - i.e., when you need to, change the package name. 1) 0 is going to have to fail sometimes for practical reasons. When it does, fall back to a) no source, binary or semantic incompatibilities or deprecations introduced in a x.y.z release b) no source or binary incompatibilities in an x.y release, but deprecations and semantic changes allowed c) no removals without prior deprecations, but these and other backward incompatible changes allowed in x.0 releases. This is pretty much my thinking, except that I want to tighten 1c - no removals without prior deprecations allowed in x.0 releases. Source and binary backward incompatible changes may be considered at the edges of the API, but not the core. (We have to be strict as many, many other open source projects rely on commons, and they can't be re-compiled just because of commons. Commons has to act and behave close to the JDK on incompatibilities). Commons needs clarity on this subject, and having it should speed up releases and voting. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
- Original Message From: Phil Steitz [EMAIL PROTECTED] I would like very much for us to agree once and for all on some versioning/deprecation rules. Exactly the thread I was about to start :-) We seem to have lost the old versioning guidelines (unless I am senile, we used to have these on the commons or Jakarta pages somewhere). Apart from 0), which is a conservative but worth-considering-carefully PoV, the rules below are more or less what we have been adhering to over the last several years in commons and I would like to propose that we standardize on them. If all are OK, I will gin up a versioning page. A very good one, which is pretty much a C version of what I am proposing below, is http://apr.apache.org/versioning.html. 0) Never break backward source or binary compatibility - i.e., when you need to, change the package name. 1) 0 is going to have to fail sometimes for practical reasons. When it does, fall back to a) no source, binary or semantic incompatibilities or deprecations introduced in a x.y.z release b) no source or binary incompatibilities in an x.y release, but deprecations and semantic changes allowed c) no removals without prior deprecations, but these and other backward incompatible changes allowed in x.0 releases. This is pretty much my thinking, except that I want to tighten 1c - no removals without prior deprecations allowed in x.0 releases. Source and binary backward incompatible changes may be considered at the edges of the API, but not the core. (We have to be strict as many, many other open source projects rely on commons, and they can't be re-compiled just because of commons. Commons has to act and behave close to the JDK on incompatibilities). Commons needs clarity on this subject, and having it should speed up releases and voting. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1
- Original Message From: Henri Yandell [EMAIL PROTECTED] Theres too much on the CLIRR report IMO for this to be a bug fix release - I'm not that familiar with CLI but most (all?) don't seem necessary for this 1.1 release It is a minor, rather than bugfix. So I think it's fair to say Please recompile. However, also good to keep backwards compat when it's not too painful. -1 to the principle, and thus -1 to the release as is. See the versioning thread for more details. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Still no votes! (WAS: [VOTE] 3rd attempt: Release commons-io 1.3.2)
Following subsequent discussions on other threads (and the new versioning thread) I feel I must take a tougher line on this. My vote for the release of 1.3.2 changes to -1. Deprecating a class and adding a new one is inappropriate for a x.x.x release. This should either be 1.4, or the deprecated markers removed from the static class in 1.3.2 (adding comments instead). Stephen - Original Message From: Jochen Wiedmann [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Tuesday, 12 June, 2007 8:26:42 PM Subject: Still no votes! (WAS: [VOTE] 3rd attempt: Release commons-io 1.3.2) We still do not have the required three votes by PMC members for a release. See http://www.nabble.com/-VOTE--3rd-attempt:-Release-commons-io-1.3.2-t3880798.html for details. 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]
[nightly build] email logging finder pipeline failed.
Failed build logs: http://vmbuild.apache.org/~commons/nightly/logs//20070613/email.log http://vmbuild.apache.org/~commons/nightly/logs//20070613/logging.log http://vmbuild.apache.org/~commons/nightly/logs//20070613/finder.log http://vmbuild.apache.org/~commons/nightly/logs//20070613/pipeline.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r546859 - /jakarta/commons/proper/commons-nightly/trunk/commons_nightly.sh
Author: psteitz Date: Wed Jun 13 06:10:47 2007 New Revision: 546859 URL: http://svn.apache.org/viewvc?view=revrev=546859 Log: Lets try this again. Fixing m2 failing test. Modified: jakarta/commons/proper/commons-nightly/trunk/commons_nightly.sh Modified: jakarta/commons/proper/commons-nightly/trunk/commons_nightly.sh URL: http://svn.apache.org/viewvc/jakarta/commons/proper/commons-nightly/trunk/commons_nightly.sh?view=diffrev=546859r1=546858r2=546859 == --- jakarta/commons/proper/commons-nightly/trunk/commons_nightly.sh (original) +++ jakarta/commons/proper/commons-nightly/trunk/commons_nightly.sh Wed Jun 13 06:10:47 2007 @@ -277,7 +277,7 @@ fi # Deploy dated jar to maven 2 snapshot repo (configured in apache pom) -if [ `ls -1 commons-$component*.jar | wc -l` -gt 0 ] # build succeeded +if [ `ls -1 target/commons-$component*.jar | wc -l` -gt 0 ] # build succeeded then if [ $MAVEN_DEPLOY ] then - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
Phil Steitz phil.steitz at gmail.com writes: a) no source, binary or semantic incompatibilities or deprecations introduced in a x.y.z release I really wonder what's the problem with deprecations since they don't have any influence on compatibility. I'd guess there is always a reason for deprecating something. Not doing so despite that reason is most careless IMO since you encourage users to use that commons' code despite knowing better that it is a bad choice regarding future compatibility of the user's code. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] email logging finder pipeline failed.
Ignore this. All builds actually succeeded. Error in script made worse last night :-(. Should be fixed now. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
On 6/13/07, Phil Steitz [EMAIL PROTECTED] wrote: Sorry, but I have to agree with Niall on this - needs to be 2.0 with the incompatible changes - and I would like very much for us to agree once and for all on some versioning/deprecation rules. We seem to have lost the old versioning guidelines (unless I am senile, we used to have these on the commons or Jakarta pages somewhere). snip/ We still do: http://jakarta.apache.org/commons/releases/versioning.html -Rahul Apart from 0), which is a conservative but worth-considering-carefully PoV, the rules below are more or less what we have been adhering to over the last several years in commons and I would like to propose that we standardize on them. If all are OK, I will gin up a versioning page. A very good one, which is pretty much a C version of what I am proposing below, is http://apr.apache.org/versioning.html. 0) Never break backward source or binary compatibility - i.e., when you need to, change the package name. 1) 0 is going to have to fail sometimes for practical reasons. When it does, fall back to a) no source, binary or semantic incompatibilities or deprecations introduced in a x.y.z release b) no source or binary incompatibilities in an x.y release, but deprecations and semantic changes allowed c) no removals without prior deprecations, but these and other backward incompatible changes allowed in x.0 releases. This means that the [cli] release with the current changes would need to be 2.0. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-compress] a release
On 6/13/07, Cyril [EMAIL PROTECTED] wrote: Hello all, I would like to know if a release is planned for this project as I'm interested. Thanks for your answers. snip/ Not to my knowledge. How to help [1]. -Rahul [1] http://jakarta.apache.org/site/getinvolved.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
+1, I would also like to see commons project releases say with each release if they adhere to this charter (as an extra checks and balances thing) Thank you, Gary -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 12, 2007 11:19 PM To: Jakarta Commons Developers List Subject: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1 Sorry, but I have to agree with Niall on this - needs to be 2.0 with the incompatible changes - and I would like very much for us to agree once and for all on some versioning/deprecation rules. We seem to have lost the old versioning guidelines (unless I am senile, we used to have these on the commons or Jakarta pages somewhere). Apart from 0), which is a conservative but worth-considering-carefully PoV, the rules below are more or less what we have been adhering to over the last several years in commons and I would like to propose that we standardize on them. If all are OK, I will gin up a versioning page. A very good one, which is pretty much a C version of what I am proposing below, is http://apr.apache.org/versioning.html. 0) Never break backward source or binary compatibility - i.e., when you need to, change the package name. 1) 0 is going to have to fail sometimes for practical reasons. When it does, fall back to a) no source, binary or semantic incompatibilities or deprecations introduced in a x.y.z release b) no source or binary incompatibilities in an x.y release, but deprecations and semantic changes allowed c) no removals without prior deprecations, but these and other backward incompatible changes allowed in x.0 releases. This means that the [cli] release with the current changes would need to be 2.0. 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: centralized KEYS file?
I think we'd just delete them. There'd be a KEYS file one higher in the hierarchy, and the downloads.xml page can be changed to link to that top one. Also need to check there are no links to KEYS within the commons space. Hen 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 6/12/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? Means I ran verify_archive_equivalence.sh :) 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. Sounds like you need to reroll then :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (CLI-21) [cli] clone method in Option should use super.clone()
[ https://issues.apache.org/jira/browse/CLI-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell reopened CLI-21: -- [cli] clone method in Option should use super.clone() - Key: CLI-21 URL: https://issues.apache.org/jira/browse/CLI-21 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.0 Environment: Operating System: other Platform: Other Reporter: Nathan McDonald Fix For: 1.1 In org.apache.commons.cli.Option public method clone is implemented by creating a new instance through one of the class Constructors, and then assigning values as required through the setter methods. This means that any subclasses of the Option class will not return a true clone, but a new Option instance instead. A proper implementation of clone should use super.clone() to create a new instance, rather than calling the class constructor. This allows shallows clones to propogate correctly down to subclasses. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (EL-2) [el] Properties with second letter upper case are not resolved
[ https://issues.apache.org/jira/browse/EL-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504356 ] Henri Yandell commented on EL-2: Sorry for never replying on this one - and it's not much of a reply now :) I've no idea whether it would counter the spec or not. [el] Properties with second letter upper case are not resolved -- Key: EL-2 URL: https://issues.apache.org/jira/browse/EL-2 Project: Commons EL Issue Type: Bug Environment: Operating System: other Platform: Other Reporter: navid vahdat Using JavaServer Faces (MyFaces implementation), it is not possible to access backing bean properties like xTest. This bug seems to have been filed with MyFaces before (see http://issues.apache.org/jira/browse/MYFACES-31) My application is generated by user input. I can't influence the naming of properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (EL-2) [el] Properties with second letter upper case are not resolved
[ https://issues.apache.org/jira/browse/EL-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated EL-2: --- Description: Using JavaServer Faces (MyFaces implementation), it is not possible to access backing bean properties like xTest. This bug seems to have been filed with MyFaces before (see MYFACES-31 ) My application is generated by user input. I can't influence the naming of properties. was: Using JavaServer Faces (MyFaces implementation), it is not possible to access backing bean properties like xTest. This bug seems to have been filed with MyFaces before (see http://issues.apache.org/jira/browse/MYFACES-31) My application is generated by user input. I can't influence the naming of properties. [el] Properties with second letter upper case are not resolved -- Key: EL-2 URL: https://issues.apache.org/jira/browse/EL-2 Project: Commons EL Issue Type: Bug Environment: Operating System: other Platform: Other Reporter: navid vahdat Using JavaServer Faces (MyFaces implementation), it is not possible to access backing bean properties like xTest. This bug seems to have been filed with MyFaces before (see MYFACES-31 ) My application is generated by user input. I can't influence the naming of properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (EL-2) [el] Properties with second letter upper case are not resolved
[ https://issues.apache.org/jira/browse/EL-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated EL-2: --- Comment: was deleted [el] Properties with second letter upper case are not resolved -- Key: EL-2 URL: https://issues.apache.org/jira/browse/EL-2 Project: Commons EL Issue Type: Bug Environment: Operating System: other Platform: Other Reporter: navid vahdat Using JavaServer Faces (MyFaces implementation), it is not possible to access backing bean properties like xTest. This bug seems to have been filed with MyFaces before (see MYFACES-31 ) My application is generated by user input. I can't influence the naming of properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JXPATH-88) Add getPrefix(String namespaceURI) to JXPathContext
[ https://issues.apache.org/jira/browse/JXPATH-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504358 ] Matt Benson commented on JXPATH-88: --- Seems harmless... the needed code to implement in RI is already there. Add getPrefix(String namespaceURI) to JXPathContext --- Key: JXPATH-88 URL: https://issues.apache.org/jira/browse/JXPATH-88 Project: Commons JXPath Issue Type: Improvement Affects Versions: 1.2 Final Reporter: Sergey Vladimirov Priority: Minor There is function getNamespaceURI(String prefix), but there is no inverted one. Need this in following case: - reading XML - check, if prefix for particular namespace is defined (using getPrefix) - if defined - using prefix, specified in XML - if not defined - define prefix and using it Usual way - to define prefix always - is not good, since prefix can already be used in XML file with another namespace. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1
On 6/13/07, Stephen Colebourne [EMAIL PROTECTED] wrote: - Original Message From: Henri Yandell [EMAIL PROTECTED] Theres too much on the CLIRR report IMO for this to be a bug fix release - I'm not that familiar with CLI but most (all?) don't seem necessary for this 1.1 release It is a minor, rather than bugfix. So I think it's fair to say Please recompile. However, also good to keep backwards compat when it's not too painful. -1 to the principle, and thus -1 to the release as is. See the versioning thread for more details. Given all the agreement on the other thread *sulks like a 2 year old* Time to figure out the history of these changes then. Looks like Brian and Ben have got the clone one moving along. Fields will be easy to put back. The interface will be weird. However the addValue is still one that I think needs to be considered as a special case. People should NOT use that method. It screws things up. We could keep the public method and change it to throw a RuntimeException of some kind; and then use a package private method with a different name. How does that sound? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r546989 - /jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/JXPathContext.java
Author: mbenson
Date: Wed Jun 13 11:21:30 2007
New Revision: 546989
URL: http://svn.apache.org/viewvc?view=revrev=546989
Log:
align javadoc
Modified:
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/JXPathContext.java
Modified:
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/JXPathContext.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/JXPathContext.java?view=diffrev=546989r1=546988r2=546989
==
---
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/JXPathContext.java
(original)
+++
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/JXPathContext.java
Wed Jun 13 11:21:30 2007
@@ -622,15 +622,15 @@
protected abstract CompiledExpression compilePath(String xpath);
/**
-* Finds the first object that matches the specified XPath. It is
equivalent
-* to codegetPointer(xpath).getNode()/code. Note, that this method
-* produces the same result as codegetValue()/code on object models
-* like JavaBeans, but a different result for DOM/JDOM etc., because it
-* returns the Node itself, rather than its textual contents.
-*
-* @param xpath the xpath to be evaluated
-* @return the found object
-*/
+ * Finds the first object that matches the specified XPath. It is
equivalent
+ * to codegetPointer(xpath).getNode()/code. Note that this method
+ * produces the same result as codegetValue()/code on object models
+ * like JavaBeans, but a different result for DOM/JDOM etc., because it
+ * returns the Node itself, rather than its textual contents.
+ *
+ * @param xpath the xpath to be evaluated
+ * @return the found object
+ */
public Object selectSingleNode(String xpath) {
Pointer pointer = getPointer(xpath);
return pointer == null ? null : pointer.getNode();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r546990 - in /jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath: JXPathContext.java ri/JXPathContextReferenceImpl.java
Author: mbenson
Date: Wed Jun 13 11:23:34 2007
New Revision: 546990
URL: http://svn.apache.org/viewvc?view=revrev=546990
Log:
[JXPATH-88] add getPrefix(String namespaceURI) to JXPathContext, RI
Modified:
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/JXPathContext.java
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/JXPathContextReferenceImpl.java
Modified:
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/JXPathContext.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/JXPathContext.java?view=diffrev=546990r1=546989r2=546990
==
---
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/JXPathContext.java
(original)
+++
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/JXPathContext.java
Wed Jun 13 11:23:34 2007
@@ -825,6 +825,17 @@
}
/**
+ * Get the prefix associated with the specifed namespace URI.
+ * @param namespaceURI the ns URI to check.
+ * @return String prefix
+ * @since JXPath 1.3
+ */
+public String getPrefix(String namespaceURI) {
+throw new UnsupportedOperationException(
+Namespace registration is not implemented by + getClass());
+}
+
+/**
* Namespace prefixes can be defined implicitly by specifying a pointer to
a
* context where the namespaces are defined. By default,
* NamespaceContextPointer is the same as the Context Pointer, see
Modified:
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/JXPathContextReferenceImpl.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/JXPathContextReferenceImpl.java?view=diffrev=546990r1=546989r2=546990
==
---
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/JXPathContextReferenceImpl.java
(original)
+++
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/JXPathContextReferenceImpl.java
Wed Jun 13 11:23:34 2007
@@ -671,7 +671,15 @@
public String getNamespaceURI(String prefix) {
return namespaceResolver.getNamespaceURI(prefix);
}
-
+
+/**
+ * [EMAIL PROTECTED]
+ * @see org.apache.commons.jxpath.JXPathContext#getPrefix(java.lang.String)
+ */
+public String getPrefix(String namespaceURI) {
+return namespaceResolver.getPrefix(namespaceURI);
+}
+
public void setNamespaceContextPointer(Pointer pointer) {
if (namespaceResolver.isSealed()) {
namespaceResolver = (NamespaceResolver) namespaceResolver.clone();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1
However the addValue is still one that I think needs to be considered as a special case. People should NOT use that method. It screws things up. We could keep the public method and change it to throw a RuntimeException of some kind; and then use a package private method with a different name. How does that sound? I like, but also deprecate the method and explain in the deprecation warning why it's evil and why it's only there for compatibility (a la the doc for Thread.stop() in the JDK). Have the RuntimeException include the deprecation warning in its message too.
[jira] Resolved: (JXPATH-88) Add getPrefix(String namespaceURI) to JXPathContext
[ https://issues.apache.org/jira/browse/JXPATH-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson resolved JXPATH-88. --- Resolution: Fixed Fix Version/s: 1.3 svn rev 546990 Add getPrefix(String namespaceURI) to JXPathContext --- Key: JXPATH-88 URL: https://issues.apache.org/jira/browse/JXPATH-88 Project: Commons JXPath Issue Type: Improvement Affects Versions: 1.2 Final Reporter: Sergey Vladimirov Priority: Minor Fix For: 1.3 There is function getNamespaceURI(String prefix), but there is no inverted one. Need this in following case: - reading XML - check, if prefix for particular namespace is defined (using getPrefix) - if defined - using prefix, specified in XML - if not defined - define prefix and using it Usual way - to define prefix always - is not good, since prefix can already be used in XML file with another namespace. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r546992 - /jakarta/commons/proper/cli/branches/cli-1.0.x/src/java/org/apache/commons/cli/HelpFormatter.java
Author: bayard Date: Wed Jun 13 11:29:45 2007 New Revision: 546992 URL: http://svn.apache.org/viewvc?view=revrev=546992 Log: Moved the attributes back to being public fields so as to maintain backwards compatibility. Each one has been deprecated, with the deprecation meaning we'll move them to private scope rather than remove them. Modified: jakarta/commons/proper/cli/branches/cli-1.0.x/src/java/org/apache/commons/cli/HelpFormatter.java Modified: jakarta/commons/proper/cli/branches/cli-1.0.x/src/java/org/apache/commons/cli/HelpFormatter.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/cli-1.0.x/src/java/org/apache/commons/cli/HelpFormatter.java?view=diffrev=546992r1=546991r2=546992 == --- jakarta/commons/proper/cli/branches/cli-1.0.x/src/java/org/apache/commons/cli/HelpFormatter.java (original) +++ jakarta/commons/proper/cli/branches/cli-1.0.x/src/java/org/apache/commons/cli/HelpFormatter.java Wed Jun 13 11:29:45 2007 @@ -40,7 +40,10 @@ /** default padding to the left of each line */ public static final int DEFAULT_LEFT_PAD = 1; -/** ?? */ +/** + * the number of characters of padding to be prefixed + * to each description line + */ public static final int DEFAULT_DESC_PAD = 3; /** the string to display at the begining of the usage statement */ @@ -57,29 +60,62 @@ // -- Attributes -/** number of characters per line */ -private int defaultWidth = DEFAULT_WIDTH; - -/** amount of padding to the left of each line */ -private int defaultLeftPad = DEFAULT_LEFT_PAD; - -/** ?? */ -private int defaultDescPad = DEFAULT_DESC_PAD; - -/** the string to display at the begining of the usage statement */ -private String defaultSyntaxPrefix = DEFAULT_SYNTAX_PREFIX; - -/** the new line character/string ?? */ -private String defaultNewLine = System.getProperty(line.separator); - -/** the shortOpt prefix */ -private String defaultOptPrefix = DEFAULT_OPT_PREFIX; - -/** the long Opt prefix */ -private String defaultLongOptPrefix = DEFAULT_LONG_OPT_PREFIX; - -/** the name of the argument */ -private String defaultArgName = DEFAULT_ARG_NAME; +/** + * number of characters per line + * + * @deprecated Scope will be made private for next major version + */ +public int defaultWidth = DEFAULT_WIDTH; + +/** + * amount of padding to the left of each line + * + * @deprecated Scope will be made private for next major version + */ +public int defaultLeftPad = DEFAULT_LEFT_PAD; + +/** + * the number of characters of padding to be prefixed + * to each description line + * + * @deprecated Scope will be made private for next major version + */ +public int defaultDescPad = DEFAULT_DESC_PAD; + +/** + * the string to display at the begining of the usage statement + * + * @deprecated Scope will be made private for next major version + */ +public String defaultSyntaxPrefix = DEFAULT_SYNTAX_PREFIX; + +/** + * the new line string + * + * @deprecated Scope will be made private for next major version + */ +public String defaultNewLine = System.getProperty(line.separator); + +/** + * the shortOpt prefix + * + * @deprecated Scope will be made private for next major version + */ +public String defaultOptPrefix = DEFAULT_OPT_PREFIX; + +/** + * the long Opt prefix + * + * @deprecated Scope will be made private for next major version + */ +public String defaultLongOptPrefix = DEFAULT_LONG_OPT_PREFIX; + +/** + * the name of the argument + * + * @deprecated Scope will be made private for next major version + */ +public String defaultArgName = DEFAULT_ARG_NAME; /** * Sets the 'width'. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r546994 - /jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/NamespaceResolver.java
Author: mbenson
Date: Wed Jun 13 11:45:43 2007
New Revision: 546994
URL: http://svn.apache.org/viewvc?view=revrev=546994
Log:
complete sealing handling
Modified:
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/NamespaceResolver.java
Modified:
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/NamespaceResolver.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/NamespaceResolver.java?view=diffrev=546994r1=546993r2=546994
==
---
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/NamespaceResolver.java
(original)
+++
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/NamespaceResolver.java
Wed Jun 13 11:45:43 2007
@@ -51,14 +51,17 @@
public NamespaceResolver(NamespaceResolver parent) {
this.parent = parent;
}
-
+
/**
* Registers a namespace prefix.
*
* @param prefix A namespace prefix
* @param namespaceURI A URI for that prefix
*/
-public void registerNamespace(String prefix, String namespaceURI) {
+public synchronized void registerNamespace(String prefix, String
namespaceURI) {
+if (isSealed()) {
+throw new IllegalStateException(Cannot register namespaces on a
sealed NamespaceResolver);
+}
namespaceMap.put(prefix, namespaceURI);
reverseMap = null;
}
@@ -92,7 +95,7 @@
* @param prefix The namespace prefix to look up
* @return namespace URI or null if the prefix is undefined.
*/
-public String getNamespaceURI(String prefix) {
+public synchronized String getNamespaceURI(String prefix) {
String uri = (String) namespaceMap.get(prefix);
if (uri == null pointer != null) {
uri = pointer.getNamespaceURI(prefix);
@@ -108,7 +111,7 @@
* @param namespaceURI the ns URI to check.
* @return String prefix
*/
-public String getPrefix(String namespaceURI) {
+public synchronized String getPrefix(String namespaceURI) {
if (reverseMap == null) {
reverseMap = new HashMap();
NodeIterator ni = pointer.namespaceIterator();
@@ -159,7 +162,9 @@
*/
public Object clone() {
try {
-return super.clone();
+NamespaceResolver result = (NamespaceResolver) super.clone();
+result.sealed = false;
+return result;
}
catch (CloneNotSupportedException e) {
// Of course, it's supported.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[cli] Fixing backwards compatabilities
4 items to fix: 1) Make the fields in HelpFormatter public. DONE. 2) Make the Option class cloneable again. See: https://issues.apache.org/jira/browse/CLI-21 3) Deal with the public boolean addValue-package private void addValue. Current thinking is to move the new one to a new name and have the old method throw an UnsupportedOperationException. One other thought - should the package private new method be protected instead? It seems to make sense that if Parsers in CLI had to talk to it, then ones outside CLI might too. It's the abstract class that talks to it, so people extending that wouldn't have a problem. So, protected? 4) Deal with the new methods on the CommandLineParser interface. I'm tempted to just delete them from the interface and leave them on the abstract Parser class. Thoughts? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cli] Fixing backwards compatabilities
On 6/13/07, Henri Yandell [EMAIL PROTECTED] wrote: 3) Deal with the public boolean addValue-package private void addValue. Current thinking is to move the new one to a new name and have the old method throw an UnsupportedOperationException. One other thought - should the package private new method be protected instead? It seems to make sense that if Parsers in CLI had to talk to it, then ones outside CLI might too. It's the abstract class that talks to it, so people extending that wouldn't have a problem. So, protected? Of course, that's crap too. People extending Parser would have to extend Option too, which would suck. The conversation, lost to history and not recorded in svn log, goes much like this I suspect: * People shouldn't use addValue unless they're a parser. We should restrict it. * Our Parser needs it. * Package private then. * Other Parsers might need it. * Arrgh. Crappy API. Let's make a CLI2. So ignore the protected suggestion. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vote] releasing jci RC4 as 1.0
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/ The website is live http://jakarta.apache.org/commons/jci/ 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]
Re: [vote] releasing jci RC3 as 1.0 ...maybe this time?
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? 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. 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 cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] releasing jci RC3 as 1.0 ...maybe this time?
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 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. Well, this is only my view and it is probably distorted, you can ignore it. regards, Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r547061 - /jakarta/commons/proper/cli/branches/cli-1.0.x/src/java/org/apache/commons/cli/HelpFormatter.java
Author: niallp Date: Wed Jun 13 16:13:04 2007 New Revision: 547061 URL: http://svn.apache.org/viewvc?view=revrev=547061 Log: JavaDoc only - indicate alternative methods to switch to in deprecation messages Modified: jakarta/commons/proper/cli/branches/cli-1.0.x/src/java/org/apache/commons/cli/HelpFormatter.java Modified: jakarta/commons/proper/cli/branches/cli-1.0.x/src/java/org/apache/commons/cli/HelpFormatter.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/cli-1.0.x/src/java/org/apache/commons/cli/HelpFormatter.java?view=diffrev=547061r1=547060r2=547061 == --- jakarta/commons/proper/cli/branches/cli-1.0.x/src/java/org/apache/commons/cli/HelpFormatter.java (original) +++ jakarta/commons/proper/cli/branches/cli-1.0.x/src/java/org/apache/commons/cli/HelpFormatter.java Wed Jun 13 16:13:04 2007 @@ -64,6 +64,7 @@ * number of characters per line * * @deprecated Scope will be made private for next major version + * - use get/setWidth methods instead. */ public int defaultWidth = DEFAULT_WIDTH; @@ -71,6 +72,7 @@ * amount of padding to the left of each line * * @deprecated Scope will be made private for next major version + * - use get/setLeftPadding methods instead. */ public int defaultLeftPad = DEFAULT_LEFT_PAD; @@ -79,6 +81,7 @@ * to each description line * * @deprecated Scope will be made private for next major version + * - use get/setDescPadding methods instead. */ public int defaultDescPad = DEFAULT_DESC_PAD; @@ -86,6 +89,7 @@ * the string to display at the begining of the usage statement * * @deprecated Scope will be made private for next major version + * - use get/setSyntaxPrefix methods instead. */ public String defaultSyntaxPrefix = DEFAULT_SYNTAX_PREFIX; @@ -93,6 +97,7 @@ * the new line string * * @deprecated Scope will be made private for next major version + * - use get/setNewLine methods instead. */ public String defaultNewLine = System.getProperty(line.separator); @@ -100,6 +105,7 @@ * the shortOpt prefix * * @deprecated Scope will be made private for next major version + * - use get/setOptPrefix methods instead. */ public String defaultOptPrefix = DEFAULT_OPT_PREFIX; @@ -107,6 +113,7 @@ * the long Opt prefix * * @deprecated Scope will be made private for next major version + * - use get/setLongOptPrefix methods instead. */ public String defaultLongOptPrefix = DEFAULT_LONG_OPT_PREFIX; @@ -114,6 +121,7 @@ * the name of the argument * * @deprecated Scope will be made private for next major version + * - use get/setArgName methods instead. */ public String defaultArgName = DEFAULT_ARG_NAME; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CLI-21) [cli] clone method in Option should use super.clone()
[ https://issues.apache.org/jira/browse/CLI-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Egge updated CLI-21: -- Attachment: bug21.patch Add clone method back to Option. Includes test case with subclass. [cli] clone method in Option should use super.clone() - Key: CLI-21 URL: https://issues.apache.org/jira/browse/CLI-21 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.0 Environment: Operating System: other Platform: Other Reporter: Nathan McDonald Fix For: 1.1 Attachments: bug21.patch In org.apache.commons.cli.Option public method clone is implemented by creating a new instance through one of the class Constructors, and then assigning values as required through the setter methods. This means that any subclasses of the Option class will not return a true clone, but a new Option instance instead. A proper implementation of clone should use super.clone() to create a new instance, rather than calling the class constructor. This allows shallows clones to propogate correctly down to subclasses. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
