[TEXT] Review of the code base

[Benedikt Ritter]

Hi all,

I've looked through the code base of [text] and I already did some clean
up. However there are a few things, that need more work IMHO:

1. IP clearance! There are several comments talking about code adapted from
PHP libraries. This needs to be listed in NOTICE.txt. For an example see
the NOTICE.txt in [lang].

2. The names package needs work. Currently the HumanNameParser takes a Name
object (which is just a wrapper around a String) as parameter. The parse
result is then saved in fields (e.g. firstName). This makes the parser
unusable after it has parsed a name. I think the API should be reworked
such as:
- The constructor of the parser takes configuration options which can be
reused for several names to parse
- the parse method takes a string as parameter, containing a name
- the parse method returns an immutable Name objects which has getters for
firstName, lastName etc.

3. There are a some useless JavaDocs, which can be dropped. For example:
/**
 * Middle name.
 */
private String middle;

Better rename the variable to middleName and drop the comment.

4. Several classes have no tests. The overall test coverage looks good, so
this may not be a problem.

5. I don't think the shade configuration is correct. To me it looks like
commons-text depends on [lang] and also shades some classes. Do we really
need the explicit dependency? Furthermore, why do we need to shade so many
classes? Why do we need anything beside StringUtils?

Nevertheless, this library looks very good. Kudos to Bruno for pushing this
forward!

Regards,
Benedikt






-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [TEXT] Review of the code base

[Bruno P. Kinoshita]

Thanks for the thorough code review Benedikt! Comments inline.

> 1. IP clearance! There are several comments talking about code adapted from
>PHP libraries. This needs to be listed in NOTICE.txt. For an example see
>the NOTICE.txt in [lang].
Filed https://issues.apache.org/jira/browse/SANDBOX-497
And first try to fix it: 

https://git1-us-west.apache.org/repos/asf?p=commons-text.git;a=commitdiff;h=refs/heads/SANDBOX-497
Does that look correct? I also checked with the author before porting it to the 
initial Java version, and told him about the [text] component - 
https://github.com/jasonpriem/HumanNameParser.php/issues/11
> 2. The names package needs work.
Completely agree. We can try to make it thread safe too. This will take a 
little longer.
File new issue for tracking it https://issues.apache.org/jira/browse/SANDBOX-498

> 3. There are a some useless JavaDocs, which can be dropped. For example:
> (...)> Better rename the variable to middleName and drop the comment.
What about renaming the variables but leaving the comments? 

> 4. Several classes have no tests. The overall test coverage looks good, so
>this may not be a problem.
Before the initial release I can start a development cycle just to add new 
tests for parts that seem important - like code with somewhat high [+5] 
cyclomatic complexity and uncovered branches. Just to make sure that the 
initial release will have an acceptable quality and less hidden bugs :-)
> 5. I don't think the shade configuration is correct. To me it looks like
>commons-text depends on [lang] and also shades some classes. Do we really
>need the explicit dependency? Furthermore, why do we need to shade so many
>classes? Why do we need anything beside StringUtils?
My mistake. I copied the [functor] configuration without much thinking. IIRC, 
this dependency was added because of the names package. But it shouldn't be too 
complicate to replace it. It is mainly used for checking empty/blank values. 

So let's drop the [lang] dependency and use something like `$VAR != null && ! 
"".equals($VAR)` instead?
Thanks again for reviewing the code!

All the best,Bruno

 
  From: Benedikt Ritter 
 To: Commons Developers List  
 Sent: Sunday, April 19, 2015 9:01 PM
 Subject: [TEXT] Review of the code base
   
Hi all,

I've looked through the code base of [text] and I already did some clean
up. However there are a few things, that need more work IMHO:

1. IP clearance! There are several comments talking about code adapted from
PHP libraries. This needs to be listed in NOTICE.txt. For an example see
the NOTICE.txt in [lang].

2. The names package needs work. Currently the HumanNameParser takes a Name
object (which is just a wrapper around a String) as parameter. The parse
result is then saved in fields (e.g. firstName). This makes the parser
unusable after it has parsed a name. I think the API should be reworked
such as:
- The constructor of the parser takes configuration options which can be
reused for several names to parse
- the parse method takes a string as parameter, containing a name
- the parse method returns an immutable Name objects which has getters for
firstName, lastName etc.

3. There are a some useless JavaDocs, which can be dropped. For example:
/**
 * Middle name.
 */
private String middle;

Better rename the variable to middleName and drop the comment.

4. Several classes have no tests. The overall test coverage looks good, so
this may not be a problem.

5. I don't think the shade configuration is correct. To me it looks like
commons-text depends on [lang] and also shades some classes. Do we really
need the explicit dependency? Furthermore, why do we need to shade so many
classes? Why do we need anything beside StringUtils?

Nevertheless, this library looks very good. Kudos to Bruno for pushing this
forward!

Regards,
Benedikt






-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter


   
 

Re: [math] threading redux

[Gilles]

Hello.

On Sat, 18 Apr 2015 22:25:20 -0400, James Carman wrote:
I think I got sidetracked when typing that email.  I was trying to 
say that

we need an abstraction layer above raw threads in order to allow for
different types of parallelism.   The Future abstraction is there in 
order

to support remote execution where side effects aren't good enough.


I don't know what
 "remote execution where side effects aren't good enough"
means.

I'll describe my example of "prototype" (see quoted message below[1])
and what *I* mean when I suggest that (some of) the CM code should 
allow

to take advantage of multi-threading.

I committed the first set of classes in "o.a.c.m.ml.neuralnet".[2]
Here is the idea of "parallelism" that drove the design of those
classes: The training of an artificial neural network (ANN) is 
performed
by almost[3] independent updates of each of ANN's cells.  You 
_cannot_[4]

however chop the network into independent parts to be sent for remote
processing: each update must be visible ASAP by all the training 
tasks.[5]


"Future" instances do not appear in the "main" code, but the idea was,
indeed, to be able to use that JDK abstraction: see the unit test[6]
  testTravellerSalesmanSquareTourParallelSolver()
defined in class
  org.apache.commons.math4.ml.neuralnet.sofm.KohonenTrainingTaskTest
in the "test" part of the repository.

As for a concrete example, you can try Phil's idea of the genetic 
algorithm

stuff I suppose.


I hope that with the above I made myself clear that I was not asking
for a pointer to code that could be parallelized[7], but rather that
people make it explicit what _they_ mean by parallelism[8].  What I 
mean

is multithread safe code that can take advantage of the multiple core
machines through the readily available classes in the JDK: namely the
"Executor" framework which you also mentioned.
Of course, I do not preclude other approaches (I don't know them, as
mentioned previously) that may (or may not) be more appropriate for the
example I gave or to other algorithms; but I truly believe that this
discussion should be more precise, unless we deepen the 
misunderstanding

of what we think we are talking about.


Regards,
Gilles

[1] As a side note: Shall we agree that top-posting is bad? ;-)
[2] With the purpose to implement a version of a specific algorithm 
(SOFM) so
that the data structures might not be generally useful for any kind 
of

artificial neural network.
[3] The update should of course be thread-safe: two parallel tasks 
might try

to update the same cell at the same time.
[4] At least, it's instinctively obvious that for a SOFM network of 
"relatively

small", you'd _loose_ performance through I/O.
[5] In later phases of the training, "regions" will have formed in the 
ANN, so
that at that point, it might be possible to continue the updates of 
those
regions on different computation nodes (with the necessary 
synchronization

of the region's boundaries).
[6] It's more of an example usage that could probably go to the "user 
guide".
[7] The GA perfectly lend itself to the same kind of "readiness to 
parallelism"

code which I implemented for the SOFM.
[8] As applied concretely to a specific algorithm in CM.

On Saturday, April 18, 2015, Gilles  
wrote:



On Fri, 17 Apr 2015 16:53:56 -0500, James Carman wrote:


Do you have any pointers to code for this ForkJoin mechanism?  I'm
curious to see it.

The key thing you will need in order to support parallelization in 
a

generic way



What do you mean by "generic way"?

I'm afraid that we may be trying to compare apples and oranges;
each of us probably has in mind a "prototype" algorithm and an idea
of how to implement it to make it run in parallel.

I think that it would focus the discussion if we could
1. tell what the "prototype" is,
2. show a sort of pseudo-code of the difference between a sequential
   and a parallel run of this "prototype" (i.e. what is the data, 
how

   the (sub)tasks operate on them).

Regards,
Gilles

 is to not tie it directly to threads, but use some

abstraction layer above threads, since that may not be the "worker"
method you're using at the time.

On Fri, Apr 17, 2015 at 2:57 PM, Thomas Neidhart
 wrote:


On 04/17/2015 05:35 PM, Phil Steitz wrote:


On 4/17/15 3:14 AM, Gilles wrote:


Hello.

On Thu, 16 Apr 2015 17:06:21 -0500, James Carman wrote:


Consider me poked!

So, the Java answer to "how do I run things in multiple 
threads"

is to
use an Executor (java.util).  This doesn't necessarily mean 
that you
*have* to use a separate thread (the implementation could 
execute
inline).  However, in order to accommodate the separate thread 
case,
you would need to code to a Future-like API.  Now, I'm not 
saying to
use Executors directly, but I'd provide some abstraction layer 
above

them or in lieu of them, something like:

public interface ExecutorThingy {
  Future execute(Function fn);
}

One could imagine implementing different ExecutorT

Re: [TEXT] Review of the code base

[Benedikt Ritter]

Hello Bruno,

2015-04-19 12:15 GMT+02:00 Bruno P. Kinoshita :

> Thanks for the thorough code review Benedikt! Comments inline.
>
> > 1. IP clearance! There are several comments talking about code adapted
> from
> >PHP libraries. This needs to be listed in NOTICE.txt. For an example see
> >the NOTICE.txt in [lang].
> Filed https://issues.apache.org/jira/browse/SANDBOX-497
> And first try to fix it:
>
>
> https://git1-us-west.apache.org/repos/asf?p=commons-text.git;a=commitdiff;h=refs/heads/SANDBOX-497
> Does that look correct? I also checked with the author before porting it
> to the initial Java version, and told him about the [text] component -
> https://github.com/jasonpriem/HumanNameParser.php/issues/11


I've adjusted the changes a bit and merged it into master.


>
> > 2. The names package needs work.
> Completely agree. We can try to make it thread safe too. This will take a
> little longer.
> File new issue for tracking it
> https://issues.apache.org/jira/browse/SANDBOX-498


I've pushed a new branch containing a proposal how to fix this. Please
review.


>
>
> > 3. There are a some useless JavaDocs, which can be dropped. For example:
> > (...)> Better rename the variable to middleName and drop the comment.
> What about renaming the variables but leaving the comments?
>

For I've corrected this for the names package in the SANDBOX-498 branch.


>
> > 4. Several classes have no tests. The overall test coverage looks good,
> so
> >this may not be a problem.
> Before the initial release I can start a development cycle just to add new
> tests for parts that seem important - like code with somewhat high [+5]
> cyclomatic complexity and uncovered branches. Just to make sure that the
> initial release will have an acceptable quality and less hidden bugs :-)
>

Nice!


> > 5. I don't think the shade configuration is correct. To me it looks like
> >commons-text depends on [lang] and also shades some classes. Do we really
> >need the explicit dependency? Furthermore, why do we need to shade so many
> >classes? Why do we need anything beside StringUtils?
> My mistake. I copied the [functor] configuration without much thinking.
> IIRC, this dependency was added because of the names package. But it
> shouldn't be too complicate to replace it. It is mainly used for checking
> empty/blank values.
>
> So let's drop the [lang] dependency and use something like `$VAR != null
> && ! "".equals($VAR)` instead?
>

I think we also need StringUtils in the similarity package. We should
handle this after we have merged the changes made to the names package.


> Thanks again for reviewing the code!
>

No problem, thanks for pushing this forward.

Here are some more things we need to take care of before 1.0:
- JIRA project
- Rename similarity package to distance package? We have five Distance
implementations but only one Similarity. Furthermore we have FuzzyScore. Is
it a distance or a similarity? It should be renamed accordingly.
- ConsineSimilariy uses Vectors modeled as Map. Does
it make sense to introduce a new class called Vector?

Benedikt


>
> All the best,Bruno
>
>
>   From: Benedikt Ritter 
>  To: Commons Developers List 
>  Sent: Sunday, April 19, 2015 9:01 PM
>  Subject: [TEXT] Review of the code base
>
> Hi all,
>
> I've looked through the code base of [text] and I already did some clean
> up. However there are a few things, that need more work IMHO:
>
> 1. IP clearance! There are several comments talking about code adapted from
> PHP libraries. This needs to be listed in NOTICE.txt. For an example see
> the NOTICE.txt in [lang].
>
> 2. The names package needs work. Currently the HumanNameParser takes a Name
> object (which is just a wrapper around a String) as parameter. The parse
> result is then saved in fields (e.g. firstName). This makes the parser
> unusable after it has parsed a name. I think the API should be reworked
> such as:
> - The constructor of the parser takes configuration options which can be
> reused for several names to parse
> - the parse method takes a string as parameter, containing a name
> - the parse method returns an immutable Name objects which has getters for
> firstName, lastName etc.
>
> 3. There are a some useless JavaDocs, which can be dropped. For example:
> /**
>  * Middle name.
>  */
> private String middle;
>
> Better rename the variable to middleName and drop the comment.
>
> 4. Several classes have no tests. The overall test coverage looks good, so
> this may not be a problem.
>
> 5. I don't think the shade configuration is correct. To me it looks like
> commons-text depends on [lang] and also shades some classes. Do we really
> need the explicit dependency? Furthermore, why do we need to shade so many
> classes? Why do we need anything beside StringUtils?
>
> Nevertheless, this library looks very good. Kudos to Bruno for pushing this
> forward!
>
> Regards,
> Benedikt
>
>
>
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitte

Re: [TEXT] Review of the code base

[Benedikt Ritter]

2015-04-19 17:24 GMT+02:00 Benedikt Ritter :

> Hello Bruno,
>
> 2015-04-19 12:15 GMT+02:00 Bruno P. Kinoshita 
> :
>
>> Thanks for the thorough code review Benedikt! Comments inline.
>>
>> > 1. IP clearance! There are several comments talking about code adapted
>> from
>> >PHP libraries. This needs to be listed in NOTICE.txt. For an example see
>> >the NOTICE.txt in [lang].
>> Filed https://issues.apache.org/jira/browse/SANDBOX-497
>> And first try to fix it:
>>
>>
>> https://git1-us-west.apache.org/repos/asf?p=commons-text.git;a=commitdiff;h=refs/heads/SANDBOX-497
>> Does that look correct? I also checked with the author before porting it
>> to the initial Java version, and told him about the [text] component -
>> https://github.com/jasonpriem/HumanNameParser.php/issues/11
>
>
> I've adjusted the changes a bit and merged it into master.
>
>
>>
>> > 2. The names package needs work.
>> Completely agree. We can try to make it thread safe too. This will take a
>> little longer.
>> File new issue for tracking it
>> https://issues.apache.org/jira/browse/SANDBOX-498
>
>
> I've pushed a new branch containing a proposal how to fix this. Please
> review.
>
>
>>
>>
>> > 3. There are a some useless JavaDocs, which can be dropped. For example:
>> > (...)> Better rename the variable to middleName and drop the comment.
>> What about renaming the variables but leaving the comments?
>>
>
> For I've corrected this for the names package in the SANDBOX-498 branch.
>
>
>>
>> > 4. Several classes have no tests. The overall test coverage looks good,
>> so
>> >this may not be a problem.
>> Before the initial release I can start a development cycle just to add
>> new tests for parts that seem important - like code with somewhat high [+5]
>> cyclomatic complexity and uncovered branches. Just to make sure that the
>> initial release will have an acceptable quality and less hidden bugs :-)
>>
>
> Nice!
>
>
>> > 5. I don't think the shade configuration is correct. To me it looks like
>> >commons-text depends on [lang] and also shades some classes. Do we really
>> >need the explicit dependency? Furthermore, why do we need to shade so
>> many
>> >classes? Why do we need anything beside StringUtils?
>> My mistake. I copied the [functor] configuration without much thinking.
>> IIRC, this dependency was added because of the names package. But it
>> shouldn't be too complicate to replace it. It is mainly used for checking
>> empty/blank values.
>>
>> So let's drop the [lang] dependency and use something like `$VAR != null
>> && ! "".equals($VAR)` instead?
>>
>
> I think we also need StringUtils in the similarity package. We should
> handle this after we have merged the changes made to the names package.
>
>
>> Thanks again for reviewing the code!
>>
>
> No problem, thanks for pushing this forward.
>
> Here are some more things we need to take care of before 1.0:
> - JIRA project
>

Requested a JIRA project:
https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-9477


> - Rename similarity package to distance package? We have five Distance
> implementations but only one Similarity. Furthermore we have FuzzyScore. Is
> it a distance or a similarity? It should be renamed accordingly.
> - ConsineSimilariy uses Vectors modeled as Map.
> Does it make sense to introduce a new class called Vector?
>
> Benedikt
>
>
>>
>> All the best,Bruno
>>
>>
>>   From: Benedikt Ritter 
>>  To: Commons Developers List 
>>  Sent: Sunday, April 19, 2015 9:01 PM
>>  Subject: [TEXT] Review of the code base
>>
>> Hi all,
>>
>> I've looked through the code base of [text] and I already did some clean
>> up. However there are a few things, that need more work IMHO:
>>
>> 1. IP clearance! There are several comments talking about code adapted
>> from
>> PHP libraries. This needs to be listed in NOTICE.txt. For an example see
>> the NOTICE.txt in [lang].
>>
>> 2. The names package needs work. Currently the HumanNameParser takes a
>> Name
>> object (which is just a wrapper around a String) as parameter. The parse
>> result is then saved in fields (e.g. firstName). This makes the parser
>> unusable after it has parsed a name. I think the API should be reworked
>> such as:
>> - The constructor of the parser takes configuration options which can be
>> reused for several names to parse
>> - the parse method takes a string as parameter, containing a name
>> - the parse method returns an immutable Name objects which has getters for
>> firstName, lastName etc.
>>
>> 3. There are a some useless JavaDocs, which can be dropped. For example:
>> /**
>>  * Middle name.
>>  */
>> private String middle;
>>
>> Better rename the variable to middleName and drop the comment.
>>
>> 4. Several classes have no tests. The overall test coverage looks good, so
>> this may not be a problem.
>>
>> 5. I don't think the shade configuration is correct. To me it looks like
>> commons-text depends on [lang] and also shades some classes. Do we really
>> need the explicit dependency? Furth

Re: [TEXT] Review of the code base

[Benedikt Ritter]

2015-04-19 17:29 GMT+02:00 Benedikt Ritter :

>
>
> 2015-04-19 17:24 GMT+02:00 Benedikt Ritter :
>
>> Hello Bruno,
>>
>> 2015-04-19 12:15 GMT+02:00 Bruno P. Kinoshita > >:
>>
>>> Thanks for the thorough code review Benedikt! Comments inline.
>>>
>>> > 1. IP clearance! There are several comments talking about code adapted
>>> from
>>> >PHP libraries. This needs to be listed in NOTICE.txt. For an example see
>>> >the NOTICE.txt in [lang].
>>> Filed https://issues.apache.org/jira/browse/SANDBOX-497
>>> And first try to fix it:
>>>
>>>
>>> https://git1-us-west.apache.org/repos/asf?p=commons-text.git;a=commitdiff;h=refs/heads/SANDBOX-497
>>> Does that look correct? I also checked with the author before porting it
>>> to the initial Java version, and told him about the [text] component -
>>> https://github.com/jasonpriem/HumanNameParser.php/issues/11
>>
>>
>> I've adjusted the changes a bit and merged it into master.
>>
>>
>>>
>>> > 2. The names package needs work.
>>> Completely agree. We can try to make it thread safe too. This will take
>>> a little longer.
>>> File new issue for tracking it
>>> https://issues.apache.org/jira/browse/SANDBOX-498
>>
>>
>> I've pushed a new branch containing a proposal how to fix this. Please
>> review.
>>
>>
>>>
>>>
>>> > 3. There are a some useless JavaDocs, which can be dropped. For
>>> example:
>>> > (...)> Better rename the variable to middleName and drop the comment.
>>> What about renaming the variables but leaving the comments?
>>>
>>
>> For I've corrected this for the names package in the SANDBOX-498 branch.
>>
>>
>>>
>>> > 4. Several classes have no tests. The overall test coverage looks
>>> good, so
>>> >this may not be a problem.
>>> Before the initial release I can start a development cycle just to add
>>> new tests for parts that seem important - like code with somewhat high [+5]
>>> cyclomatic complexity and uncovered branches. Just to make sure that the
>>> initial release will have an acceptable quality and less hidden bugs :-)
>>>
>>
>> Nice!
>>
>>
>>> > 5. I don't think the shade configuration is correct. To me it looks
>>> like
>>> >commons-text depends on [lang] and also shades some classes. Do we
>>> really
>>> >need the explicit dependency? Furthermore, why do we need to shade so
>>> many
>>> >classes? Why do we need anything beside StringUtils?
>>> My mistake. I copied the [functor] configuration without much thinking.
>>> IIRC, this dependency was added because of the names package. But it
>>> shouldn't be too complicate to replace it. It is mainly used for checking
>>> empty/blank values.
>>>
>>> So let's drop the [lang] dependency and use something like `$VAR != null
>>> && ! "".equals($VAR)` instead?
>>>
>>
>> I think we also need StringUtils in the similarity package. We should
>> handle this after we have merged the changes made to the names package.
>>
>>
>>> Thanks again for reviewing the code!
>>>
>>
>> No problem, thanks for pushing this forward.
>>
>> Here are some more things we need to take care of before 1.0:
>> - JIRA project
>>
>
> Requested a JIRA project:
> https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-9477
>
>
>> - Rename similarity package to distance package? We have five Distance
>> implementations but only one Similarity. Furthermore we have FuzzyScore. Is
>> it a distance or a similarity? It should be renamed accordingly.
>> - ConsineSimilariy uses Vectors modeled as Map.
>> Does it make sense to introduce a new class called Vector?
>>
>
We also need a logo! [1] Anybody creative enough to do that? :-)

Benedikt

[1] https://issues.apache.org/jira/browse/SANDBOX-499


>
>> Benedikt
>>
>>
>>>
>>> All the best,Bruno
>>>
>>>
>>>   From: Benedikt Ritter 
>>>  To: Commons Developers List 
>>>  Sent: Sunday, April 19, 2015 9:01 PM
>>>  Subject: [TEXT] Review of the code base
>>>
>>> Hi all,
>>>
>>> I've looked through the code base of [text] and I already did some clean
>>> up. However there are a few things, that need more work IMHO:
>>>
>>> 1. IP clearance! There are several comments talking about code adapted
>>> from
>>> PHP libraries. This needs to be listed in NOTICE.txt. For an example see
>>> the NOTICE.txt in [lang].
>>>
>>> 2. The names package needs work. Currently the HumanNameParser takes a
>>> Name
>>> object (which is just a wrapper around a String) as parameter. The parse
>>> result is then saved in fields (e.g. firstName). This makes the parser
>>> unusable after it has parsed a name. I think the API should be reworked
>>> such as:
>>> - The constructor of the parser takes configuration options which can be
>>> reused for several names to parse
>>> - the parse method takes a string as parameter, containing a name
>>> - the parse method returns an immutable Name objects which has getters
>>> for
>>> firstName, lastName etc.
>>>
>>> 3. There are a some useless JavaDocs, which can be dropped. For example:
>>> /**
>>>  * Middle name.
>>>  */
>>> private String middle;
>>>
>>> Better rename the variabl

Re: [LANG] Next steps

[Benedikt Ritter]

Hi,

3.4 has been released. GitHub badges have been activated. Now we can start
the migration to git. Here is the Infra ticket [1]

Regards,
Benedikt

[1] https://issues.apache.org/jira/browse/INFRA-9478

2015-03-13 20:21 GMT+01:00 Gary Gregory :

> I like you'd plan!
>
> Gary :-)
>
>  Original message From: Benedikt Ritter <
> brit...@apache.org> Date:03/13/2015  11:17  (GMT-08:00)
> To: Commons Developers List 
> Cc:  Subject: [LANG] Next steps 
> Hi all,
>
> I just want to give you an update on what I'm planning next for [lang].
>
> - I'll review the pending patches and commit what is ready to be committed.
> - After that I'll cut 3.4 RC1
> - After that I'll start the git migration (I hope that I have information
> about the github badges [1] until then, so that I can request INFRA to
> activate the corresponding services)
>
> Regards,
> Benedikt
>
> [1] http://markmail.org/message/umscsixafxy3rpnp
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>



-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: svn commit: r1674710 - /commons/proper/io/trunk/src/main/java/org/apache/commons/io/output/CloseShieldOutputStream.java

[Bernd Eckenfels]

Hello,

Am Mon, 20 Apr 2015 00:25:55 -
schrieb ggreg...@apache.org:
> commons/proper/io/trunk/src/main/java/org/apache/commons/io/output/CloseShieldOutputStream.java
> (original) +++
> commons/proper/io/trunk/src/main/java/org/apache/commons/io/output/CloseShieldOutputStream.java
> Mon Apr 20 00:25:55 2015 @@ -24,7 +24,7 @@ import
> java.io.OutputStream;
>   * This class is typically used in cases where an output stream
> needs to be
>   * passed to a component that wants to explicitly close the stream
> even if
>   * other components would still use the stream for output.
> - *
> + * 
>   * @version $Id$
>   * @since 1.4
>   */

Uhm... is that really an improvement? If you use html tags (like it is
specified by javadoc) you dont need ending tags.

Gruss
Bernd

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

Re: svn commit: r1674710 - /commons/proper/io/trunk/src/main/java/org/apache/commons/io/output/CloseShieldOutputStream.java

[Gary Gregory]

On Sun, Apr 19, 2015 at 6:05 PM, Bernd Eckenfels 
wrote:

> Hello,
>
> Am Mon, 20 Apr 2015 00:25:55 -
> schrieb ggreg...@apache.org:
> >
> commons/proper/io/trunk/src/main/java/org/apache/commons/io/output/CloseShieldOutputStream.java
> > (original) +++
> >
> commons/proper/io/trunk/src/main/java/org/apache/commons/io/output/CloseShieldOutputStream.java
> > Mon Apr 20 00:25:55 2015 @@ -24,7 +24,7 @@ import
> > java.io.OutputStream;
> >   * This class is typically used in cases where an output stream
> > needs to be
> >   * passed to a component that wants to explicitly close the stream
> > even if
> >   * other components would still use the stream for output.
> > - *
> > + * 
> >   * @version $Id$
> >   * @since 1.4
> >   */
>
> Uhm... is that really an improvement? If you use html tags (like it is
> specified by javadoc) you dont need ending tags.
>

Try building with Java 8 and see what happens... ;-)

Gary

>
> Gruss
> Bernd
>
> -
> 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

Re: svn commit: r1674710 - /commons/proper/io/trunk/src/main/java/org/apache/commons/io/output/CloseShieldOutputStream.java

[Bernd Eckenfels]

Hello,

commons-io has multiple Java 8 doclint warnings and errors 
(mostly missing references and self closing  and @inheritDoc) in
the current revision, but "CloseShieldOutputStream without the
closing  tag is not in that list. What command did
you run and what error it is reporting? I tried javadoc:javadoc.

Gruss
Bernd

Am Sun, 19 Apr 2015 18:35:13 -0700
schrieb Gary Gregory :

> On Sun, Apr 19, 2015 at 6:05 PM, Bernd Eckenfels
>  wrote:
> 
> > Hello,
> >
> > Am Mon, 20 Apr 2015 00:25:55 -
> > schrieb ggreg...@apache.org:
> > >
> > commons/proper/io/trunk/src/main/java/org/apache/commons/io/output/CloseShieldOutputStream.java
> > > (original) +++
> > >
> > commons/proper/io/trunk/src/main/java/org/apache/commons/io/output/CloseShieldOutputStream.java
> > > Mon Apr 20 00:25:55 2015 @@ -24,7 +24,7 @@ import
> > > java.io.OutputStream;
> > >   * This class is typically used in cases where an output stream
> > > needs to be
> > >   * passed to a component that wants to explicitly close the
> > > stream even if
> > >   * other components would still use the stream for output.
> > > - *
> > > + * 
> > >   * @version $Id$
> > >   * @since 1.4
> > >   */
> >
> > Uhm... is that really an improvement? If you use html tags (like it
> > is specified by javadoc) you dont need ending tags.
> >
> 
> Try building with Java 8 and see what happens... ;-)
> 
> Gary
> 
> >
> > Gruss
> > Bernd
> >
> > -
> > 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

Re: [2/3] [text] SANDBOX-497 IP clearance for the names package

[Phil Steitz]

On 4/19/15 6:52 AM, brit...@apache.org wrote:
> SANDBOX-497 IP clearance for the names package
>
> Make clear that Commons Text only includes ported code from the
> HumanNameParser PHP library.
> HumanNameParser library is licensed under MIT.
>
>
> Project: http://git-wip-us.apache.org/repos/asf/commons-text/repo
> Commit: http://git-wip-us.apache.org/repos/asf/commons-text/commit/db197ab1
> Tree: http://git-wip-us.apache.org/repos/asf/commons-text/tree/db197ab1
> Diff: http://git-wip-us.apache.org/repos/asf/commons-text/diff/db197ab1
>
> Branch: refs/heads/master
> Commit: db197ab199281d65ca338f8f47b6099223a9cf8b
> Parents: be2bcda
> Author: Benedikt Ritter 
> Authored: Sun Apr 19 15:49:54 2015 +0200
> Committer: Benedikt Ritter 
> Committed: Sun Apr 19 15:49:54 2015 +0200
>
> --
>  NOTICE.txt | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/commons-text/blob/db197ab1/NOTICE.txt
> --
> diff --git a/NOTICE.txt b/NOTICE.txt
> index f6f4633..80d91a0 100644
> --- a/NOTICE.txt
> +++ b/NOTICE.txt
> @@ -4,6 +4,6 @@ Copyright 2001-2015 The Apache Software Foundation
>  This product includes software developed at
>  The Apache Software Foundation (http://www.apache.org/).
>  
> -This product includes software from the HumanNameParser.php
> -(https://github.com/jasonpriem/HumanNameParser.php) library,
> -under the Apache License 2.0 (see: the o.a.c.t.names package).
> +This product includes software ported from the HumanNameParser PHP library
> +(https://github.com/jasonpriem/HumanNameParser.php), which is licensed under
> +the MIT License (MIT) (see: the o.a.c.t.names package).

Sebb or some other license/notice expert can chime in here; but I
suspect this is either not necessary or misplaced.  We were asked to
rip out a lot of stuff like this from [math] NOTICE based on the
argument that only legally required things should be in there.  If
this is a legal requirement, the MIT license asks that you include
the license, which should (IIUC) go in LICENSE, not NOTICE.  Given
that this is a port and not inclusion, though; I am not sure it is
needed.

Phil
>
> .
>


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

Re: svn commit: r1674710 - /commons/proper/io/trunk/src/main/java/org/apache/commons/io/output/CloseShieldOutputStream.java

[Gary Gregory]

Javadoc 8 does not allow for XHTML tags to not be closed (in the default
mode).

When I run 'mvn clean site', I get, more of these errors and others:

9 errors
6 warnings
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 07:16 min
[INFO] Finished at: 2015-04-19T20:33:23-07:00
[INFO] Final Memory: 57M/386M
[INFO]

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on
project commons-io: Error during page generation: Error rendering Maven
report:
[ERROR] Exit code: 1 -
C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\CopyUtils.java:309:
warning: no @param for encoding
[ERROR] public static void copy(
[ERROR] ^
[ERROR]
C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\CopyUtils.java:358:
warning: no @param for encoding
[ERROR] public static void copy(
[ERROR] ^
[ERROR]
C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\FileCleaner.java:140:
error: reference not found
[ERROR] * {@link
javax.servlet.ServletContextListener#contextDestroyed(javax.servlet.ServletContextEvent)}.
[ERROR] ^
[ERROR]
C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\FileCleaner.java:33:
error: reference not found
[ERROR] * {@link
javax.servlet.ServletContextListener#contextDestroyed(javax.servlet.ServletContextEvent)}
or similar.
[ERROR] ^
[ERROR]
C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\FileCleaningTracker.java:186:
error: reference not found
[ERROR] * {@link
javax.servlet.ServletContextListener#contextDestroyed(javax.servlet.ServletContextEvent)}.
[ERROR] ^
[ERROR]
C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\FileCleaningTracker.java:40:
error: reference not found
[ERROR] * {@link javax.servlet.ServletContextListener#contextDestroyed} or
similar.
[ERROR] ^
[ERROR]
C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\IOUtils.java:3069:
warning: no @return
[ERROR] public static byte[] readFully(final InputStream input, final int
length) throws IOException {
[ERROR] ^
[ERROR]
C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\input\BoundedReader.java:66:
warning: no description for @throws
[ERROR] * @throws IOException
[ERROR] ^
[ERROR]
C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\input\BoundedReader.java:76:
warning: no description for @throws
[ERROR] * @throws IOException
[ERROR] ^
[ERROR]
C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\input\BoundedReader.java:130:
warning: no description for @throws
[ERROR] * @throws IOException
[ERROR] ^
[ERROR]
C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\input\BoundedReader.java:28:
error: self-closing element not allowed
[ERROR] * 
[ERROR] ^
[ERROR]
C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\input\UnixLineEndingInputStream.java:60:
error: incorrect use of inline tag
[ERROR] * @inheritDoc
[ERROR] ^
[ERROR]
C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\input\UnixLineEndingInputStream.java:102:
error: incorrect use of inline tag
[ERROR] * @inheritDoc
[ERROR] ^
[ERROR]
C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\input\WindowsLineEndingInputStream.java:62:
error: incorrect use of inline tag
[ERROR] * @inheritDoc
[ERROR] ^
[ERROR]
C:\vcs\svn\apache\commons\trunks-proper\io\src\main\java\org\apache\commons\io\input\WindowsLineEndingInputStream.java:115:
error: incorrect use of inline tag
[ERROR] * @inheritDoc
[ERROR] ^
[ERROR]
[ERROR] Command line was: "C:\Program
Files\Java\jdk1.8.0_45\jre\..\bin\javadoc.exe" @options @packages
[ERROR]
[ERROR] Refer to the generated Javadoc files in
'C:\vcs\svn\apache\commons\trunks-proper\io\target\site\apidocs' dir.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

Using:

Apache Maven 3.3.1 (cab6659f9874fa96462afef40fcf6bc033d58c1c;
2015-03-13T13:10:27-07:00)
Maven home: C:\Java\apache-maven-3.3.1
Java version: 1.8.0_45, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_45\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"

Gary

On Sun, Apr 19, 2015 at 7:10 PM, Bernd Eckenfels 
wrote:

> Hello,
>
> commons-io has multiple Java 8 doclint warnings a