[GitHub] commons-io pull request #33: [IO-531] JavaDoc to describe accept-any file fi...

2017-04-20 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/commons-io/pull/33


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: [lang] new concurrency annotations

2017-04-20 Thread Gary Gregory
On Thu, Apr 20, 2017 at 2:53 PM, Gary Gregory 
wrote:

>
> On Wed, Apr 19, 2017 at 1:00 PM, Gary Gregory 
> wrote:
>
>> Related to this, is HttpCore which switch from JCIP style annotations
>> (4.x) to @Contract (5.x). I'll ask that ML for the reason/experience.
>>
>
> Acoording to Oleg:
> --
> The original JCIP style annotations had to be removed due to ASLv2
> incompatibility with the license of the original work.
>
> There is a corresponding Jira ticket in LEGAL.
> --
>

Found these two:

https://issues.apache.org/jira/browse/LEGAL-240
https://issues.apache.org/jira/browse/LEGAL-3

Gary


> Gary
>
>
>>
>> Gary
>>
>> On Wed, Apr 19, 2017 at 12:14 PM, Oliver Heger <
>> oliver.he...@oliver-heger.de> wrote:
>>
>>>
>>>
>>> Am 19.04.2017 um 14:06 schrieb Gilles:
>>> > On Wed, 19 Apr 2017 09:17:32 +0200, Emmanuel Bourg wrote:
>>> >> Le 19/04/2017 à 00:23, Gary Gregory a écrit :
>>> >>
>>> >>> I'd like to see a real example before we talk about abstract
>>> >>> arguments and
>>> >>> counter-arguments, which will never end ;-)
>>> >>
>>> >> Ok,
>>> >
>>> > Good. [If only...] ;-)
>>> >
>>> >> here is a slightly more substantial example. The following class is
>>> >> immutable but not thread-safe:
>>> >>
>>> >>   public class FileAppender {
>>> >>   private final File file;
>>> >>
>>> >>   public FileAppender(File file) {
>>> >>   this.file = file;
>>> >>   }
>>> >>
>>> >>   public void append(String message) throws IOException {
>>> >>   try (OutputStream out = new FileOutputStream(file)) {
>>> >>   out.write(message.getBytes());
>>> >>   }
>>> >>   }
>>> >>   }
>>> >>
>>> >> The point is, if the class operates on resources outside the JVM, the
>>> >> immutability doesn't ensure the thread safety. Immutability is only a
>>> >> thread safety guarantee for data structures, and not for classes with
>>> >> operations causing side effects (like writing to files, drawing on the
>>> >> screen, playing sounds, calling remote services, accessing off-heap
>>> >> memory, etc).
>>> >
>>> > The consequence should thus be that such classes should not be
>>> > documented as thread-safe _because_ such a qualifier would not
>>> > bring any actual benefit to the user.
>>> >
>>> > Documenting/annotating a class as "immutable" or "thread-safe"
>>> > must be a _promise_ to the user, and it requires more analysis
>>> > than recognizing that all the fields are final.
>>> >
>>> > To return to the question of which annotation, I'm unfazed by
>>> > the possibility of
>>> >  @ThreadSafe
>>> >  @NotThreadSafe
>>> > because it is an obvious documentation bug, with no more dire
>>> > consequences than saying
>>> >  @ThreadSafe
>>> > when, in fact, it is not.
>>> >
>>> I agree. Let's not forget that the annotations are intended as a tool
>>> for documentation. The main responsibility is on the author who is using
>>> them.
>>>
>>> We should not try to be too clever here, especially as we have no way to
>>> prevent real documentation errors: classes being marked as @ThreadSafe
>>> although they are not, or originally thread-safe classes which are later
>>> modified in a way that breaks their thread-safety.
>>>
>>> Oliver
>>>
>>> >
>>> > Gilles
>>> >
>>> >>
>>> >> Emmanuel Bourg
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > -
>>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> > For additional commands, e-mail: dev-h...@commons.apache.org
>>> >
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>>
>> 
>> JUnit in Action, Second Edition
>> 
>>
>> 
>> Spring Batch in Action
>> 
>> 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 

[NUMBERS] Proposed resolution for NUMBERS-20

2017-04-20 Thread Raymond DeCampo
I have committed a proposed resolution for NUMBERS-20 on the branch
feature-NUMBERS-20 in commons-numbers.  Feedback or comments from
interested parties are welcome.

https://issues.apache.org/jira/browse/NUMBERS-20
https://github.com/apache/commons-numbers/tree/feature-NUMBERS-20

Thanks,
Ray


[GitHub] commons-io pull request #33: [IO-531] JavaDoc to describe accept-any file fi...

2017-04-20 Thread ecki
GitHub user ecki opened a pull request:

https://github.com/apache/commons-io/pull/33

[IO-531] JavaDoc to describe accept-any file filter



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ecki/commons-io patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-io/pull/33.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #33


commit 118d673fd7f8ac9bc9e342c0a3bbea05236e4b83
Author: Bernd 
Date:   2017-04-20T20:05:48Z

[IO-531] JavaDoc to describe accept-any file filter




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: Convert RNG help wanted into generic request

2017-04-20 Thread Gilles

Hello.

On Tue, 18 Apr 2017 09:13:44 + (UTC), Eyal Allweil wrote:

Hi Gilles,
As a Jira issue, RNG-37 is OK. But for something like Help Wanted, I
would add a link to another implementation that can be used as a
template


http://commons.apache.org/proper/commons-rng/commons-rng-sampling/xref/org/apache/commons/rng/sampling/distribution/MarsagliaNormalizedGaussianSampler.html


and/or a page describing which interface to implement,


http://commons.apache.org/proper/commons-rng/commons-rng-sampling/apidocs/org/apache/commons/rng/sampling/distribution/package-summary.html

http://commons.apache.org/proper/commons-rng/commons-rng-sampling/apidocs/org/apache/commons/rng/sampling/distribution/MarsagliaNormalizedGaussianSampler.html


what
to test,


http://commons.apache.org/proper/commons-rng/commons-rng-sampling/xref-test/org/apache/commons/rng/sampling/distribution/ContinuousSamplersList.html


that sort of thing. The idea is to make it easy for someone
new to the project to feel like they can dive right into the work and
meet the project expectations.


Sure.


I'm totally unfamiliar with commons-rng
myself - but that's what, if I were looking at the page, would 
improve

the chances that I would think it's worth trying.


Feel free to include the above links.


I suspect the more
expectations and hints are there, the less work afterwards is
necessary in review and finishing.


It should also be stressed that the first thing would be to
subscribe to the ML, and post about what is proposed in order
to ensure that no problem would arise (e.g. license issues).


Thanks for your help on this,
Gilles



Regards,Eyal


On Thursday, April 13, 2017 4:18 PM, Gilles
 wrote:


 Hello.

On Thu, 13 Apr 2017 12:27:47 + (UTC), Eyal Allweil wrote:

Hi Gilles,

I looked at the issues in RNG, and I didn't find something that
seemed appropriate for a beginner. The closest, in my opinion,
are RNG-33 (adding convenience methods to UniformRandomProvider)


That one should be resolved: the convenience methods probably
do not warrant breaking compatibility (and there are other
limitations, as discussed in the comments).

However, it might be worth exploring utilities (such as
"RngStreamFactory" mentioned in one comment) to be added
in the "commons-rng-examples" module.

and RNG-37 (implementing Ziggurat). Maybe with some more 
explanations

or project expectations RNG-37 (or a similar, new issue) can work.


What do see as missing from the description?



Instead, I added a new item for Commons Text - I couldn't find a way
to get a link from Help Wanted, but it's TEXT-74. There were 
actually
a lot of issues in Commons Text that seemed good, but they all 
depend

on WordUtils being available in the main branch, which appears
pending. I guess we'll see if anyone picks it up.


Thanks,
Gilles



Cheers,Eyal




    On Thursday, April 13, 2017 12:50 PM, Gilles
 wrote:


  Hi Eyal.

On Thu, 13 Apr 2017 08:36:34 + (UTC), Eyal Allweil wrote:
I opened two "help wanted" items for Apache DataFu a few months 
ago.
Both were linked to specific Jira issues - one a generic "wish", 
and

the other a very specific, entry-level task.
Unsurprisingly, the generic one is still open, but the more 
specific
item was picked up and a new contributor wrote it. I recommend 
doing

something similar for Commons. I don't think there are enough
"beginner" tasks there, and I think it's a good way to pick up
contributors and get things done - not everyone knows how to search
Jira for something doable.


Good point.
However it is probably always the case that JIRA issues that stay
open
are not easy to fix...


If there are no objections, I can open a new issue for something in
Commons as an example.


Sure! If beginners are likely to be reading "helpwanted" rather than
the developers' web site, you are certainly welcome in evaluating 
all
the JIRA issues and copy the ones you think will fit in 
"helpwanted".


Thanks a lot,
Gilles



Regards,Eyal


    On Friday, March 24, 2017 2:48 PM, Gilles
 wrote:


  Hi.

On Fri, 24 Mar 2017 10:24:10 +, Bernd Eckenfels wrote:

Hello,

Can we replace this task. We get so many references to it, and
despite the fact we answered the offers for help there was never a
result out of it.


I've pointed at that problem several months ago already.


I am unsure why that is, and maybe we could improve
our people skills, but it is rather obvious to me that this
particular
help request does not attract the right engagement


I guess that the "helpwanted" page makes it too easy to send out
an automatic mail to this list, even thought the OP is not
subscribed;
in at least one occurrence, the OP acted as if we were spamming 
her!


Is there another "helpwanted" request that redirects here?
If not, no surprise that it happens only through the one I
created...


(besides the
wording is outdated)


Quite true but the problem 

Re: svn commit: r1792011 - in /commons/proper/configuration/trunk/src: changes/changes.xml main/java/org/apache/commons/configuration2/tree/ImmutableNode.java test/java/org/apache/commons/configuratio

2017-04-20 Thread Gary Gregory
On Apr 20, 2017 2:40 AM, "Oliver Heger" 
wrote:



Am 20.04.2017 um 05:17 schrieb ggreg...@apache.org:

> Author: ggregory
> Date: Thu Apr 20 03:17:59 2017
> New Revision: 1792011
>
> URL: http://svn.apache.org/viewvc?rev=1792011=rev
> Log:
> [CONFIGURATION-664] Add API org.apache.commons.configurati
> on2.tree.ImmutableNode.getChildren(String).
>
> Modified:
> commons/proper/configuration/trunk/src/changes/changes.xml
> commons/proper/configuration/trunk/src/main/java/org/apache/
> commons/configuration2/tree/ImmutableNode.java
> commons/proper/configuration/trunk/src/test/java/org/apache/
> commons/configuration2/tree/TestImmutableNode.java
>
> Modified: commons/proper/configuration/trunk/src/changes/changes.xml
> URL: http://svn.apache.org/viewvc/commons/proper/configuration/tr
> unk/src/changes/changes.xml?rev=1792011=1792010=1792011=diff
> 
> ==
> --- commons/proper/configuration/trunk/src/changes/changes.xml (original)
> +++ commons/proper/configuration/trunk/src/changes/changes.xml Thu Apr 20
> 03:17:59 2017
> @@ -41,6 +41,9 @@
>
>  Add API org.apache.commons.configurati
> on2.DataConfiguration.getURI(String) methods.
>
> +  
> +Add API org.apache.commons.configuration2.tree.ImmutableNode.
> getChildren(String).
> +  
>
>  Update platform requirement from Java 6 to 7.
>
>
> Modified: commons/proper/configuration/trunk/src/main/java/org/apache/
> commons/configuration2/tree/ImmutableNode.java
> URL: http://svn.apache.org/viewvc/commons/proper/configuration/tr
> unk/src/main/java/org/apache/commons/configuration2/tree/
> ImmutableNode.java?rev=1792011=1792010=1792011=diff
> 
> ==
> --- commons/proper/configuration/trunk/src/main/java/org/apache/
> commons/configuration2/tree/ImmutableNode.java (original)
> +++ commons/proper/configuration/trunk/src/main/java/org/apache/
> commons/configuration2/tree/ImmutableNode.java Thu Apr 20 03:17:59 2017
> @@ -102,6 +102,29 @@ public final class ImmutableNode
>  }
>
>  /**
> + * Returns a list with the children of this node. This list cannot be
> + * modified.
> + * @param name the node name to find
> + *
> + * @return a list with the child nodes
> + */
> +public List getChildren(final String name)
> +{
> +final List list = new ArrayList<>();
> +if (name == null) {
> +return list;
> +}
> +for (final ImmutableNode node : children)
> +{
> +if (name.equals(node.getNodeName()))
> +{
> +list.add(node);
> +}
> +}
> +return list;
> +}
>

The list does not seem to be unmodifiable. Or do you mean that modifying
the list does not impact the child nodes? I think the implementation is not
aligned with the comment.


The comment is wrong. Will fix today, thank you!

Gary


Oliver


+
> +/**
>   * Returns a map with the attributes of this node. This map cannot be
>   * modified.
>   *
>
> Modified: commons/proper/configuration/trunk/src/test/java/org/apache/
> commons/configuration2/tree/TestImmutableNode.java
> URL: http://svn.apache.org/viewvc/commons/proper/configuration/tr
> unk/src/test/java/org/apache/commons/configuration2/tree/
> TestImmutableNode.java?rev=1792011=1792010=1792011=diff
> 
> ==
> --- commons/proper/configuration/trunk/src/test/java/org/apache/
> commons/configuration2/tree/TestImmutableNode.java (original)
> +++ commons/proper/configuration/trunk/src/test/java/org/apache/
> commons/configuration2/tree/TestImmutableNode.java Thu Apr 20 03:17:59
> 2017
> @@ -30,6 +30,7 @@ import java.util.Iterator;
>  import java.util.List;
>  import java.util.Map;
>
> +import org.junit.Assert;
>  import org.junit.Test;
>
>  /**
> @@ -404,6 +405,49 @@ public class TestImmutableNode
>  }
>
>  /**
> + * Tests getting named children.
> + */
> +@Test
> +public void testGetChildrenByName()
> +{
> +ImmutableNode node = createDefaultNode(VALUE);
> +ImmutableNode child2 =
> +new ImmutableNode.Builder().name("child2").create();
> +ImmutableNode node2 = node.addChild(child2);
> +checkUpdatedNode(node, node2);
> +assertEquals("child2", node2.getChildren("child2").ge
> t(0).getNodeName());
> +assertEquals(child2, node2.getChildren("child2").get(0));
> +}
> +
> +/**
> + * Tests getting named children.
> + */
> +@Test
> +public void testGetChildrenByNullName()
> +{
> +ImmutableNode node = createDefaultNode(VALUE);
> +ImmutableNode child2 =
> +new ImmutableNode.Builder().name("child2").create();
> +ImmutableNode node2 = 

Re: svn commit: r1792011 - in /commons/proper/configuration/trunk/src: changes/changes.xml main/java/org/apache/commons/configuration2/tree/ImmutableNode.java test/java/org/apache/commons/configuratio

2017-04-20 Thread Oliver Heger



Am 20.04.2017 um 05:17 schrieb ggreg...@apache.org:

Author: ggregory
Date: Thu Apr 20 03:17:59 2017
New Revision: 1792011

URL: http://svn.apache.org/viewvc?rev=1792011=rev
Log:
[CONFIGURATION-664] Add API 
org.apache.commons.configuration2.tree.ImmutableNode.getChildren(String).

Modified:
commons/proper/configuration/trunk/src/changes/changes.xml

commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration2/tree/ImmutableNode.java

commons/proper/configuration/trunk/src/test/java/org/apache/commons/configuration2/tree/TestImmutableNode.java

Modified: commons/proper/configuration/trunk/src/changes/changes.xml
URL: 
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/changes/changes.xml?rev=1792011=1792010=1792011=diff
==
--- commons/proper/configuration/trunk/src/changes/changes.xml (original)
+++ commons/proper/configuration/trunk/src/changes/changes.xml Thu Apr 20 
03:17:59 2017
@@ -41,6 +41,9 @@
   
 Add API 
org.apache.commons.configuration2.DataConfiguration.getURI(String) methods.
   
+  
+Add API 
org.apache.commons.configuration2.tree.ImmutableNode.getChildren(String).
+  
   
 Update platform requirement from Java 6 to 7.
   

Modified: 
commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration2/tree/ImmutableNode.java
URL: 
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration2/tree/ImmutableNode.java?rev=1792011=1792010=1792011=diff
==
--- 
commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration2/tree/ImmutableNode.java
 (original)
+++ 
commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration2/tree/ImmutableNode.java
 Thu Apr 20 03:17:59 2017
@@ -102,6 +102,29 @@ public final class ImmutableNode
 }

 /**
+ * Returns a list with the children of this node. This list cannot be
+ * modified.
+ * @param name the node name to find
+ *
+ * @return a list with the child nodes
+ */
+public List getChildren(final String name)
+{
+final List list = new ArrayList<>();
+if (name == null) {
+return list;
+}
+for (final ImmutableNode node : children)
+{
+if (name.equals(node.getNodeName()))
+{
+list.add(node);
+}
+}
+return list;
+}


The list does not seem to be unmodifiable. Or do you mean that modifying 
the list does not impact the child nodes? I think the implementation is 
not aligned with the comment.


Oliver


+
+/**
  * Returns a map with the attributes of this node. This map cannot be
  * modified.
  *

Modified: 
commons/proper/configuration/trunk/src/test/java/org/apache/commons/configuration2/tree/TestImmutableNode.java
URL: 
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/test/java/org/apache/commons/configuration2/tree/TestImmutableNode.java?rev=1792011=1792010=1792011=diff
==
--- 
commons/proper/configuration/trunk/src/test/java/org/apache/commons/configuration2/tree/TestImmutableNode.java
 (original)
+++ 
commons/proper/configuration/trunk/src/test/java/org/apache/commons/configuration2/tree/TestImmutableNode.java
 Thu Apr 20 03:17:59 2017
@@ -30,6 +30,7 @@ import java.util.Iterator;
 import java.util.List;
 import java.util.Map;

+import org.junit.Assert;
 import org.junit.Test;

 /**
@@ -404,6 +405,49 @@ public class TestImmutableNode
 }

 /**
+ * Tests getting named children.
+ */
+@Test
+public void testGetChildrenByName()
+{
+ImmutableNode node = createDefaultNode(VALUE);
+ImmutableNode child2 =
+new ImmutableNode.Builder().name("child2").create();
+ImmutableNode node2 = node.addChild(child2);
+checkUpdatedNode(node, node2);
+assertEquals("child2", 
node2.getChildren("child2").get(0).getNodeName());
+assertEquals(child2, node2.getChildren("child2").get(0));
+}
+
+/**
+ * Tests getting named children.
+ */
+@Test
+public void testGetChildrenByNullName()
+{
+ImmutableNode node = createDefaultNode(VALUE);
+ImmutableNode child2 =
+new ImmutableNode.Builder().name("child2").create();
+ImmutableNode node2 = node.addChild(child2);
+checkUpdatedNode(node, node2);
+assertTrue(node2.getChildren(null).isEmpty());
+}
+
+/**
+ * Tests getting named children.
+ */
+@Test
+public void testGetChildrenByMissingName()
+{
+ImmutableNode node = createDefaultNode(VALUE);
+ImmutableNode child2 =
+new