[jira] [Resolved] (CLI-231) Remove DoubleCheckedLocking from checkstyle configuration
[
https://issues.apache.org/jira/browse/CLI-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved CLI-231.
-
Resolution: Fixed
Fix Version/s: 1.3
Applied in r1447004.
Remove DoubleCheckedLocking from checkstyle configuration
-
Key: CLI-231
URL: https://issues.apache.org/jira/browse/CLI-231
Project: Commons CLI
Issue Type: Improvement
Components: CLI-1.x
Reporter: Duncan Jones
Priority: Minor
Labels: checkstyle
Fix For: 1.3
Attachments: cli-231.patch
Checkstyle v5.6 removed the DoubleCheckedLocking test (see [release
notes|http://checkstyle.sourceforge.net/releasenotes.html]). Consequently,
the {{checkstyle.xml}} configuration file now fails to process with v5.6
(which is used by the Eclipse checkstyle plugin).
Could we remove this check?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLI-224) OptionBuilder only has static methods, yet many return an OptionBuilder instance
[ https://issues.apache.org/jira/browse/CLI-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580160#comment-13580160 ] Thomas Neidhart commented on CLI-224: - Yes, I think the Builder ctors should be private. OptionBuilder only has static methods, yet many return an OptionBuilder instance Key: CLI-224 URL: https://issues.apache.org/jira/browse/CLI-224 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.2 Reporter: Brian Blount Fix For: 1.3 Attachments: commons-cli-CLI-224.patch, DefaultOptionBuilder.java, DefaultOptionBuilderTest.java CLI-83 was closed as fixed in 2.0, but it seems that there is no current plan to release CLI 2.0. Could this fix be rolled into the 1.x line? I'm attaching a new version of option builder that addresses the issue (named DefaultOptionBuilder to maintain backwards compatability) and a unit test for it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLI-224) OptionBuilder only has static methods, yet many return an OptionBuilder instance
[ https://issues.apache.org/jira/browse/CLI-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580165#comment-13580165 ] Thomas Neidhart commented on CLI-224: - Applied changes as discussed on ml in r1447005. OptionBuilder only has static methods, yet many return an OptionBuilder instance Key: CLI-224 URL: https://issues.apache.org/jira/browse/CLI-224 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.2 Reporter: Brian Blount Fix For: 1.3 Attachments: commons-cli-CLI-224.patch, DefaultOptionBuilder.java, DefaultOptionBuilderTest.java CLI-83 was closed as fixed in 2.0, but it seems that there is no current plan to release CLI 2.0. Could this fix be rolled into the 1.x line? I'm attaching a new version of option builder that addresses the issue (named DefaultOptionBuilder to maintain backwards compatability) and a unit test for it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLI-219) Allow to specify options with a single argument that will be split into multiple arguments
[
https://issues.apache.org/jira/browse/CLI-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580185#comment-13580185
]
Thomas Neidhart commented on CLI-219:
-
As Emmanuel already outlined, there should already be the possibility to
specify such behavior.
For your example you could would specify the option as follows:
{noformat}
Options options = new Options();
options.addOption(OptionBuilder.withLongOpt(foo)
.hasArgs()
.withValueSeparator(' ')
.create(f));
{noformat}
This parses the input from above correctly.
Allow to specify options with a single argument that will be split into
multiple arguments
--
Key: CLI-219
URL: https://issues.apache.org/jira/browse/CLI-219
Project: Commons CLI
Issue Type: New Feature
Components: CLI-1.x
Affects Versions: 1.2
Reporter: Gilles
Labels: features
Fix For: 1.4
Attachments: svn_diff.txt
I've explained the issue in that thread:
http://www.mail-archive.com/user@commons.apache.org/msg06483.html
As hinted there, a solution might be to allow that the (single) argument of
an Option (cf. hasArg()) be split according to a user-defined regexp
pattern. If given a split pattern, the code would convert a single-arg
Option into a multiple-args one (where the arguments are the result of
splitting the single-arg string with the pattern).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (BEANUTILS-422) getPropertyType return null on second descendant class
Alex Crown created BEANUTILS-422:
Summary: getPropertyType return null on second descendant class
Key: BEANUTILS-422
URL: https://issues.apache.org/jira/browse/BEANUTILS-422
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Affects Versions: 1.8.3
Environment: Oracle JDK 1.7.0.10 and later.
Reporter: Alex Crown
PropertyUtils.getPropertyType() for IndexedProperty works only for first
invoked descendant class.
Bug reproduced in JDK 1.7.0.10 - 13. In JDK 1.7.0.9 it works fine. As I see, in
JDK 1.7.0.10 java.beans.Introspector was changed, but I don't understand how it
works.
*Example*
*file* is IndexedProperty of the RootBean (attachend to issue) with type
ArrayListString.
RoootBean has two empty descendans: *FirstChildBean* and *SecondChildBean*.
{code}
RootBean bean = new FirstChildBean();
Class propertyType = PropertyUtils.getPropertyType(bean, file[0]);
System.out.println(propertyType != null ? propertyType.getName() : null);
-- Expected: java.lang.String, Actual: java.lang.String
bean = new SecondChildBean();
propertyType = PropertyUtils.getPropertyType(bean, file[0]);
System.out.println(propertyType != null ? propertyType.getName() : null);
-- Expected: java.lang.String, Actual: null
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (BEANUTILS-422) getPropertyType return null on second descendant class
[
https://issues.apache.org/jira/browse/BEANUTILS-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Crown updated BEANUTILS-422:
-
Attachment: test.zip
Example for reproduce the bug
getPropertyType return null on second descendant class
--
Key: BEANUTILS-422
URL: https://issues.apache.org/jira/browse/BEANUTILS-422
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Affects Versions: 1.8.3
Environment: Oracle JDK 1.7.0.10 and later.
Reporter: Alex Crown
Attachments: test.zip
PropertyUtils.getPropertyType() for IndexedProperty works only for first
invoked descendant class.
Bug reproduced in JDK 1.7.0.10 - 13. In JDK 1.7.0.9 it works fine. As I see,
in JDK 1.7.0.10 java.beans.Introspector was changed, but I don't understand
how it works.
*Example*
*file* is IndexedProperty of the RootBean (attachend to issue) with type
ArrayListString.
RoootBean has two empty descendans: *FirstChildBean* and *SecondChildBean*.
{code}
RootBean bean = new FirstChildBean();
Class propertyType = PropertyUtils.getPropertyType(bean, file[0]);
System.out.println(propertyType != null ? propertyType.getName() : null);
-- Expected: java.lang.String, Actual: java.lang.String
bean = new SecondChildBean();
propertyType = PropertyUtils.getPropertyType(bean, file[0]);
System.out.println(propertyType != null ? propertyType.getName() : null);
-- Expected: java.lang.String, Actual: null
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-440) [BeanUtils2] Configure Checkstyle to allow undeclared unchecked Exceptions in JavaDoc
[ https://issues.apache.org/jira/browse/SANDBOX-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter resolved SANDBOX-440. - Resolution: Fixed Fixed in r1447056. I had to copy the maven-checks from the maven checkstyle plugin, because it is not possible to overwrite single properties of check modules. I also copied the header so that all relevant checkstyle config is located in the project dir. [BeanUtils2] Configure Checkstyle to allow undeclared unchecked Exceptions in JavaDoc - Key: SANDBOX-440 URL: https://issues.apache.org/jira/browse/SANDBOX-440 Project: Commons Sandbox Issue Type: Improvement Components: BeanUtils2 Affects Versions: Nightly Builds Reporter: Benedikt Ritter Assignee: Benedikt Ritter Priority: Minor Fix For: Nightly Builds As discussed on the ML (http://markmail.org/message/oiz4tvzrq3hlc5lv), checkstyle configuration should be changed so that unchecked exception can be documented in JavaDoc. For this the allowUndeclaredRTE property of the JavadocMethod Module has to be set to true (http://checkstyle.sourceforge.net/config_javadoc.html). Examples can be found in the checkstyle files of configuration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (BEANUTILS-416) Multiple calls to a property/method can result in a NPE
[ https://issues.apache.org/jira/browse/BEANUTILS-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter resolved BEANUTILS-416. --- Resolution: Not A Problem As I commented, BeanUtils1 is not affected. Multiple calls to a property/method can result in a NPE --- Key: BEANUTILS-416 URL: https://issues.apache.org/jira/browse/BEANUTILS-416 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.8.3 Reporter: Benedikt Ritter While working on BeanUtils2 we have found out, that the caching mechanism of BeanUtils can lead to NullPointerExceptions. Details can be found in SANDBOX-433. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLI-219) Allow to specify options with a single argument that will be split into multiple arguments
[ https://issues.apache.org/jira/browse/CLI-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580264#comment-13580264 ] Gilles commented on CLI-219: This parses the input from above correctly. But this was _not_ the original problem. See the whole context please: http://www.mail-archive.com/user@commons.apache.org/msg06523.html Allow to specify options with a single argument that will be split into multiple arguments -- Key: CLI-219 URL: https://issues.apache.org/jira/browse/CLI-219 Project: Commons CLI Issue Type: New Feature Components: CLI-1.x Affects Versions: 1.2 Reporter: Gilles Labels: features Fix For: 1.4 Attachments: svn_diff.txt I've explained the issue in that thread: http://www.mail-archive.com/user@commons.apache.org/msg06483.html As hinted there, a solution might be to allow that the (single) argument of an Option (cf. hasArg()) be split according to a user-defined regexp pattern. If given a split pattern, the code would convert a single-arg Option into a multiple-args one (where the arguments are the result of splitting the single-arg string with the pattern). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list
[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vahrst updated COLLECTIONS-310:
--
Attachment: SetUniqueListTest.patch
Many new testcases for sublists.
Modifications of a SetUniqueList.subList() invalidate the parent list
-
Key: COLLECTIONS-310
URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
Project: Commons Collections
Issue Type: Bug
Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
Fix For: 4.0
Attachments: SetUniqueListTest.patch
The List returned by SetUniqueList.subList() is again a SetUniqueList. The
contract for List.subList() says that the returned list supports all the
operations of the parent list, and it is backed by the parent list.
We have a SetUniqueList uniqueList equal to {Hello, World}. We get a
subList containing the last element. Now we add the element Hello,
contained in the uniqueList but not in the subList, to the subList.
What should happen?
Should the subList behave like a SetUniqueList and add the element - meaning
that it changes position in the uniqueList because at the old place it gets
removed, so now uniqueList equals {World, Hello} (which fails)?
Or should the element not be added, because it is already contained in the
parent list, thereby violating the SetUniqueList-ness of the subList (which
fails)?
I prefer the former behaviour, because modifications should only be made
through the subList and not through the parent list (as explained in
List.subList()).
What should happen if we replace (using set) the subList element World with
Hello instead of adding an element?
The subList should contain only Hello, and for the parent list, the old
element 0 (now a duplicate of the just set element 1) should be removed
(which fails).
And of course the parent list should know what happens to it (specifically,
its uniqueness Set) (which fails in the current snapshot).
public void testSubListAddNew() {
List uniqueList = SetUniqueList.decorate(new ArrayList());
uniqueList.add(Hello);
uniqueList.add(World);
List subList = uniqueList.subList(1, 2);
subList.add(Goodbye);
List expectedSubList = Arrays.asList(new Object[] { World,
Goodbye });
List expectedParentList = Arrays.asList(new Object[] { Hello,
World, Goodbye });
assertEquals(expectedSubList, subList);
assertEquals(expectedParentList, uniqueList);
assertTrue(uniqueList.contains(Goodbye)); // fails
}
public void testSubListAddDuplicate() {
List uniqueList = SetUniqueList.decorate(new ArrayList());
uniqueList.add(Hello);
uniqueList.add(World);
List subList = uniqueList.subList(1, 2);
subList.add(Hello);
List expectedSubList = Arrays.asList(new Object[] { World,
Hello });
List expectedParentList = Arrays.asList(new Object[] { World,
Hello });
assertEquals(expectedSubList, subList);
assertEquals(expectedParentList, uniqueList); // fails
}
public void testSubListSetDuplicate() {
List uniqueList = SetUniqueList.decorate(new ArrayList());
uniqueList.add(Hello);
uniqueList.add(World);
List subList = uniqueList.subList(1, 2);
subList.set(0, Hello);
List expectedSubList = Arrays.asList(new Object[] { Hello });
List expectedParentList = Arrays.asList(new Object[] { Hello
});
assertEquals(expectedSubList, subList);
assertEquals(expectedParentList, uniqueList); // fails
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLI-219) Allow to specify options with a single argument that will be split into multiple arguments
[ https://issues.apache.org/jira/browse/CLI-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580281#comment-13580281 ] Thomas Neidhart commented on CLI-219: - Yes, I understand that, but could you please then attach the full context to the issue? This would make it much easier to work on it. All I see here are examples that can be solved using _existing_ techniques. Allow to specify options with a single argument that will be split into multiple arguments -- Key: CLI-219 URL: https://issues.apache.org/jira/browse/CLI-219 Project: Commons CLI Issue Type: New Feature Components: CLI-1.x Affects Versions: 1.2 Reporter: Gilles Labels: features Fix For: 1.4 Attachments: svn_diff.txt I've explained the issue in that thread: http://www.mail-archive.com/user@commons.apache.org/msg06483.html As hinted there, a solution might be to allow that the (single) argument of an Option (cf. hasArg()) be split according to a user-defined regexp pattern. If given a split pattern, the code would convert a single-arg Option into a multiple-args one (where the arguments are the result of splitting the single-arg string with the pattern). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list
[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580284#comment-13580284
]
Thomas Vahrst commented on COLLECTIONS-310:
---
I am trying to create a sublist implementation which conforms to the required
functions. The first attachement (SetUniqueListTest.patch) contains many new
testcases for sublist, checking this functions.
I implemented two possible solutions, more of that in the next posts. During
the coding I realized a further problem concerning ListIterator. ListIterator
supports add/set/remove functionality, which means, that a ListIterator based
on a sublist needs the corresponding sublist behavior. And ListIterator may
start at a specified index, so this means, that a ListIterator with index 0
based on a SetUniqueList itself is a subList of the underlying SetUniqueList -
with all the necessary behavior.
So for the first iteration on this issue, I ommited these tests. I will
provided them later...
Modifications of a SetUniqueList.subList() invalidate the parent list
-
Key: COLLECTIONS-310
URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
Project: Commons Collections
Issue Type: Bug
Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
Fix For: 4.0
Attachments: SetUniqueListTest.patch
The List returned by SetUniqueList.subList() is again a SetUniqueList. The
contract for List.subList() says that the returned list supports all the
operations of the parent list, and it is backed by the parent list.
We have a SetUniqueList uniqueList equal to {Hello, World}. We get a
subList containing the last element. Now we add the element Hello,
contained in the uniqueList but not in the subList, to the subList.
What should happen?
Should the subList behave like a SetUniqueList and add the element - meaning
that it changes position in the uniqueList because at the old place it gets
removed, so now uniqueList equals {World, Hello} (which fails)?
Or should the element not be added, because it is already contained in the
parent list, thereby violating the SetUniqueList-ness of the subList (which
fails)?
I prefer the former behaviour, because modifications should only be made
through the subList and not through the parent list (as explained in
List.subList()).
What should happen if we replace (using set) the subList element World with
Hello instead of adding an element?
The subList should contain only Hello, and for the parent list, the old
element 0 (now a duplicate of the just set element 1) should be removed
(which fails).
And of course the parent list should know what happens to it (specifically,
its uniqueness Set) (which fails in the current snapshot).
public void testSubListAddNew() {
List uniqueList = SetUniqueList.decorate(new ArrayList());
uniqueList.add(Hello);
uniqueList.add(World);
List subList = uniqueList.subList(1, 2);
subList.add(Goodbye);
List expectedSubList = Arrays.asList(new Object[] { World,
Goodbye });
List expectedParentList = Arrays.asList(new Object[] { Hello,
World, Goodbye });
assertEquals(expectedSubList, subList);
assertEquals(expectedParentList, uniqueList);
assertTrue(uniqueList.contains(Goodbye)); // fails
}
public void testSubListAddDuplicate() {
List uniqueList = SetUniqueList.decorate(new ArrayList());
uniqueList.add(Hello);
uniqueList.add(World);
List subList = uniqueList.subList(1, 2);
subList.add(Hello);
List expectedSubList = Arrays.asList(new Object[] { World,
Hello });
List expectedParentList = Arrays.asList(new Object[] { World,
Hello });
assertEquals(expectedSubList, subList);
assertEquals(expectedParentList, uniqueList); // fails
}
public void testSubListSetDuplicate() {
List uniqueList = SetUniqueList.decorate(new ArrayList());
uniqueList.add(Hello);
uniqueList.add(World);
List subList = uniqueList.subList(1, 2);
subList.set(0, Hello);
List expectedSubList = Arrays.asList(new Object[] { Hello });
List expectedParentList = Arrays.asList(new Object[] { Hello
});
assertEquals(expectedSubList, subList);
assertEquals(expectedParentList, uniqueList); // fails
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact
[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list
[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580284#comment-13580284
]
Thomas Vahrst edited comment on COLLECTIONS-310 at 2/17/13 8:53 PM:
I am trying to create a sublist implementation which conforms to the required
functions. The first attachement (SetUniqueListTest.patch) contains many new
testcases for sublist, checking this functions.
I implemented two possible solutions, more of that in the following posts (in
the next days). During the coding I realized a further problem concerning
ListIterator. ListIterator supports add/set/remove functionality, which means,
that a ListIterator based on a sublist needs the corresponding sublist
behavior. And ListIterator may start at a specified index, so this means, that
a ListIterator with index 0 based on a SetUniqueList itself is a subList of
the underlying SetUniqueList - with all the necessary behavior.
So for the first iteration on this issue, I ommited these tests. I will
provided them later...
was (Author: t.vahrst):
I am trying to create a sublist implementation which conforms to the
required functions. The first attachement (SetUniqueListTest.patch) contains
many new testcases for sublist, checking this functions.
I implemented two possible solutions, more of that in the next posts. During
the coding I realized a further problem concerning ListIterator. ListIterator
supports add/set/remove functionality, which means, that a ListIterator based
on a sublist needs the corresponding sublist behavior. And ListIterator may
start at a specified index, so this means, that a ListIterator with index 0
based on a SetUniqueList itself is a subList of the underlying SetUniqueList -
with all the necessary behavior.
So for the first iteration on this issue, I ommited these tests. I will
provided them later...
Modifications of a SetUniqueList.subList() invalidate the parent list
-
Key: COLLECTIONS-310
URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
Project: Commons Collections
Issue Type: Bug
Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
Fix For: 4.0
Attachments: SetUniqueListTest.patch
The List returned by SetUniqueList.subList() is again a SetUniqueList. The
contract for List.subList() says that the returned list supports all the
operations of the parent list, and it is backed by the parent list.
We have a SetUniqueList uniqueList equal to {Hello, World}. We get a
subList containing the last element. Now we add the element Hello,
contained in the uniqueList but not in the subList, to the subList.
What should happen?
Should the subList behave like a SetUniqueList and add the element - meaning
that it changes position in the uniqueList because at the old place it gets
removed, so now uniqueList equals {World, Hello} (which fails)?
Or should the element not be added, because it is already contained in the
parent list, thereby violating the SetUniqueList-ness of the subList (which
fails)?
I prefer the former behaviour, because modifications should only be made
through the subList and not through the parent list (as explained in
List.subList()).
What should happen if we replace (using set) the subList element World with
Hello instead of adding an element?
The subList should contain only Hello, and for the parent list, the old
element 0 (now a duplicate of the just set element 1) should be removed
(which fails).
And of course the parent list should know what happens to it (specifically,
its uniqueness Set) (which fails in the current snapshot).
public void testSubListAddNew() {
List uniqueList = SetUniqueList.decorate(new ArrayList());
uniqueList.add(Hello);
uniqueList.add(World);
List subList = uniqueList.subList(1, 2);
subList.add(Goodbye);
List expectedSubList = Arrays.asList(new Object[] { World,
Goodbye });
List expectedParentList = Arrays.asList(new Object[] { Hello,
World, Goodbye });
assertEquals(expectedSubList, subList);
assertEquals(expectedParentList, uniqueList);
assertTrue(uniqueList.contains(Goodbye)); // fails
}
public void testSubListAddDuplicate() {
List uniqueList = SetUniqueList.decorate(new ArrayList());
uniqueList.add(Hello);
uniqueList.add(World);
List subList = uniqueList.subList(1, 2);
subList.add(Hello);
List expectedSubList = Arrays.asList(new Object[]
[jira] [Created] (DAEMON-277) 1.0.3 POM on search.maven.org is broken
Sebastiano Vigna created DAEMON-277:
---
Summary: 1.0.3 POM on search.maven.org is broken
Key: DAEMON-277
URL: https://issues.apache.org/jira/browse/DAEMON-277
Project: Commons Daemon
Issue Type: Bug
Reporter: Sebastiano Vigna
The groupId should be commons-daemon. This breaks anything trying to use hadoop
0.23.6. I tried everything, but couldn't find a way to make it work. Please fix
this.
[ivy:retrieve]
[ivy:retrieve] :: problems summary ::
[ivy:retrieve] WARNINGS
[ivy:retrieve] ::
[ivy:retrieve] :: UNRESOLVED DEPENDENCIES ::
[ivy:retrieve] ::
[ivy:retrieve] :: commons-daemon#commons-daemon;1.0.3: several
problems occurred while resolving dependency:
commons-daemon#commons-daemon;1.0.3 {compile=[compile(*), master(*)],
runtime=[runtime(*)]}:
[ivy:retrieve] java.text.ParseException: inconsistent module descriptor file
found in
'http://jars.law.di.unimi.it/content/repositories/public/commons-daemon/commons-daemon/1.0.3/commons-daemon-1.0.3.pom':
bad organisation: expected='commons-daemon' found='org.apache.commons';
[ivy:retrieve] java.text.ParseException: inconsistent module descriptor file
found in
'http://repo1.maven.org/maven2/commons-daemon/commons-daemon/1.0.3/commons-daemon-1.0.3.pom':
bad organisation: expected='commons-daemon' found='org.apache.commons';
[ivy:retrieve] ::
[ivy:retrieve] ERRORS
[ivy:retrieve] law: bad organisation found in
http://jars.law.di.unimi.it/content/repositories/public/commons-daemon/commons-daemon/1.0.3/commons-daemon-1.0.3.pom:
expected='commons-daemon' found='org.apache.commons'
[ivy:retrieve] public: bad organisation found in
http://repo1.maven.org/maven2/commons-daemon/commons-daemon/1.0.3/commons-daemon-1.0.3.pom:
expected='commons-daemon' found='org.apache.commons'
[ivy:retrieve]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-277) 1.0.3 POM on search.maven.org is broken
[
https://issues.apache.org/jira/browse/DAEMON-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Schaible updated DAEMON-277:
--
Fix Version/s: 1.0.4
Affects Version/s: 1.0.3
1.0.3 POM on search.maven.org is broken
---
Key: DAEMON-277
URL: https://issues.apache.org/jira/browse/DAEMON-277
Project: Commons Daemon
Issue Type: Bug
Affects Versions: 1.0.3
Reporter: Sebastiano Vigna
Fix For: 1.0.4
The groupId should be commons-daemon. This breaks anything trying to use
hadoop 0.23.6. I tried everything, but couldn't find a way to make it work.
Please fix this.
[ivy:retrieve]
[ivy:retrieve] :: problems summary ::
[ivy:retrieve] WARNINGS
[ivy:retrieve]::
[ivy:retrieve]:: UNRESOLVED DEPENDENCIES ::
[ivy:retrieve]::
[ivy:retrieve]:: commons-daemon#commons-daemon;1.0.3: several
problems occurred while resolving dependency:
commons-daemon#commons-daemon;1.0.3 {compile=[compile(*), master(*)],
runtime=[runtime(*)]}:
[ivy:retrieve]java.text.ParseException: inconsistent module
descriptor file found in
'http://jars.law.di.unimi.it/content/repositories/public/commons-daemon/commons-daemon/1.0.3/commons-daemon-1.0.3.pom':
bad organisation: expected='commons-daemon' found='org.apache.commons';
[ivy:retrieve]java.text.ParseException: inconsistent module
descriptor file found in
'http://repo1.maven.org/maven2/commons-daemon/commons-daemon/1.0.3/commons-daemon-1.0.3.pom':
bad organisation: expected='commons-daemon' found='org.apache.commons';
[ivy:retrieve]::
[ivy:retrieve] ERRORS
[ivy:retrieve]law: bad organisation found in
http://jars.law.di.unimi.it/content/repositories/public/commons-daemon/commons-daemon/1.0.3/commons-daemon-1.0.3.pom:
expected='commons-daemon' found='org.apache.commons'
[ivy:retrieve]public: bad organisation found in
http://repo1.maven.org/maven2/commons-daemon/commons-daemon/1.0.3/commons-daemon-1.0.3.pom:
expected='commons-daemon' found='org.apache.commons'
[ivy:retrieve]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DAEMON-277) 1.0.3 POM on search.maven.org is broken
[
https://issues.apache.org/jira/browse/DAEMON-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Schaible closed DAEMON-277.
-
Resolution: Won't Fix
Current release is 1.0.13 and neither do we change released versions nor are we
able to change anything on Maven central - that repository is read-only for any
published stuff.
1.0.3 POM on search.maven.org is broken
---
Key: DAEMON-277
URL: https://issues.apache.org/jira/browse/DAEMON-277
Project: Commons Daemon
Issue Type: Bug
Affects Versions: 1.0.3
Reporter: Sebastiano Vigna
Fix For: 1.0.4
The groupId should be commons-daemon. This breaks anything trying to use
hadoop 0.23.6. I tried everything, but couldn't find a way to make it work.
Please fix this.
[ivy:retrieve]
[ivy:retrieve] :: problems summary ::
[ivy:retrieve] WARNINGS
[ivy:retrieve]::
[ivy:retrieve]:: UNRESOLVED DEPENDENCIES ::
[ivy:retrieve]::
[ivy:retrieve]:: commons-daemon#commons-daemon;1.0.3: several
problems occurred while resolving dependency:
commons-daemon#commons-daemon;1.0.3 {compile=[compile(*), master(*)],
runtime=[runtime(*)]}:
[ivy:retrieve]java.text.ParseException: inconsistent module
descriptor file found in
'http://jars.law.di.unimi.it/content/repositories/public/commons-daemon/commons-daemon/1.0.3/commons-daemon-1.0.3.pom':
bad organisation: expected='commons-daemon' found='org.apache.commons';
[ivy:retrieve]java.text.ParseException: inconsistent module
descriptor file found in
'http://repo1.maven.org/maven2/commons-daemon/commons-daemon/1.0.3/commons-daemon-1.0.3.pom':
bad organisation: expected='commons-daemon' found='org.apache.commons';
[ivy:retrieve]::
[ivy:retrieve] ERRORS
[ivy:retrieve]law: bad organisation found in
http://jars.law.di.unimi.it/content/repositories/public/commons-daemon/commons-daemon/1.0.3/commons-daemon-1.0.3.pom:
expected='commons-daemon' found='org.apache.commons'
[ivy:retrieve]public: bad organisation found in
http://repo1.maven.org/maven2/commons-daemon/commons-daemon/1.0.3/commons-daemon-1.0.3.pom:
expected='commons-daemon' found='org.apache.commons'
[ivy:retrieve]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
