[GitHub] commons-io pull request #60: Minor fix in method doc

[koraytugay]

GitHub user koraytugay opened a pull request:

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

Minor fix in method doc

Minor fix in method doc

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

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

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

https://github.com/apache/commons-io/pull/60.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 #60


commit 906c5faec23d83d9f0febd6979c026e5cc805462
Author: Koray Tugay 
Date:   2018-05-18T01:36:53Z

Minor fix in method doc

Minor fix in method doc




---

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

Re: [Statistics] Port codes from Commons Math

[Gilles]

Hi Gimhana.

On Fri, 18 May 2018 00:16:04 +0530, Gimhana Nadeeshan wrote:

Hi all,

We might want to create a public branch for that work in order to

merge PRs more quickly without risk of breaking "master".
What do you think?  Eric?



I ported the Statistics Interval Module and would like to get your 
reviews.

How should I make the Pull request ?


I've just created a new branch on the repository; please make
all PR refer to "task_STATISTICS-5".
I also suggest that you create finer-grained "sub-tasks" of
  https://issues.apache.org/jira/browse/STATISTICS-5

Thanks,
Gilles



Best Regards,
Gimhana


On 5 May 2018 at 18:50, Gilles  wrote:


Hi Gimhana.

On Sat, 5 May 2018 15:50:43 +0530, Gimhana Nadeeshan wrote:


Hello all,

As I proposed early I would like to begin port code from 
Commons-math

 to Commons-statistics
.
(For further details refer my  GSoC Proposal


though I'm not selected this year)

This is my proposed architecture in brief

   1. Commons-Statistics-Core => Frequency and StatUtils classes 
(Can add

   more common classes while implementing)
   2. Commons-Statistics-Correlation
   3. Commons-Statistics-Descriptive
   4. Commons-Statistics-Inference
   5. Commons-Statistics-Interval
   6. Commons-Statistics-Ranking
   7. Commons-Statistics-Regression



Nit-pick: module names have no capital in them (just a convention).
So: "commons-statistics-core" rather than "Commons-Statistics-Core", 
etc.


While I referring Commons-Geometry




No need to refer to that project since "Commons Statistics" has been
set up:
  http://commons.apache.org/proper/commons-statistics/

The code repository is here:
  https://git1-us-west.apache.org/repos/asf?p=commons-statisti
cs.git;a=tree
It already contains a "commons-statistics-distribution" module whose
layout can be duplicated in the modules which you are proposing 
above

(with appropriate changes of course).

ported code to get a head start , I

found that each module inside, contain a pox.xml file. Are they
implemented
as separate projects and then group in the same package? I'm asking
because
Since I'm new to code porting :-).



A requirement is that no package should be shared between different
modules; by convention, the top-level package of module
  commons-statistics-descriptive
would be
  org.apache.commons.statistics.descriptive

[And so on for the other modules. But I'd suggest you start with 
one.]


If so in here should I create all 7 projects and then group those in 
same

project.



No, the project is "Commons Statisitics" and it would contain 
several
_maven_ modules, each of which should ultimately map to a _JPMS_ 
(JDK9)

module).

Firstly I suppose to start port Ranking Module as it has less

dependencies comparing to others.



Fine. But don't forget to browse through the JIRA issues of Commons
Math (CM) for things that would need fixing.  Whenever it's the 
case,

please open a report in the new JIRA project (linking to the CM
report), and post here your proposed solution (or questions).

We might want to create a public branch for that work in order to
merge PRs more quickly without risk of breaking "master".
What do you think?  Eric?

Would someone help me to get a head start ??




What else do you need?

Best regards,
Gilles

Best Regards,

Gimhana.


[...]








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

Re: [Numbers] "Experimental" release?

[Gilles]

Hi.

On Thu, 17 May 2018 10:28:05 -0600, Gary Gregory wrote:

Hi All,

Note that strictly speaking, we only publish source code. Binary 
files like

jar files are only provided as a convenience. Apache Subversion, for
example, leaves binary production and distribution to third parties.

So a "partial release" would mean a "partial release" of sources, as
opposed to a full release of sources and a partial release of 
binaries. I
am sure you could rejigger the POM and assemblies to produce the a 
source
zip that would amount to a "partial release." I am not sure it is 
worth the

complication though, YMMV.


Sorry, but I'm missing something if there is any complication
involved in what I called "partial release":  It is dead simple to
delete, from the *release branch*, all sources not to be released!

The KISS approach would be to release it all with an alpha or beta 
label.


No, that is actually more complicated from the marketing POV: we'd
have to explain why some of the codes are "not really beta" while
others are "almost stable" and still others are "alpha"...
Many false impressions will be conveyed.

It will also be a pain with the CLIRR/japicmp reports.

You could go as far as repackaging the code with a "0" package name 
post

fix for an alpha or beta if BC is a real concern.


"0" or "experimental"?
I'd rather have the latter.

Note that I asked about BC of all pre-1.0 releases; if they must be
BC compatible, then I don't see the gain (of going "experimental"):
It will be a PITA for users who'd want to help by trying the code,
since they would need to change their code at every 0.x release!

So IMO it's either
 * release everything (RERO) with no BC constraints in 0.x, or
 * release only issue-free codes as 1.0

Which one will it be?

Gilles


Gary

On Thu, May 17, 2018 at 6:02 AM, Gilles 


wrote:


Hi.

I only got one response to my previous question about
a "partial" release of the code currently in [Numbers],
which was to make a "beta" release.
I guess that it meant an "experimental" release of
*everything* even of code with known issues (big or
small).
The first release would be e.g. version 0.5 and all
releases below 1.0 could be BC-breaking.
Then in each release above 1.0, we'd decide which codes
would be lifted from the "experimental" package.

Is that correct?

If not, please state exactly what you'd want to be done
for getting your vote on a release candidate.

If we go the "experimental" way, I'd like other useful
modules to be added to [Numbers]:
 * commons-numbers-rootsolver (with codes from package
   "org.apache.commons.math4.analysis.solver")
 * commons-numbers-quadrature (with codes from package
   "org.apache.commons.math4.analysis.integration")
 * commons-numbers-interpolator (with codes from package
   "org.apache.commons.math4.analysis.interpolation")
 * commons-numbers-polynomial (with codes from package
   "org.apache.commons.math4.analysis.polynomials")

Regards,
Gilles






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

Re: [io] Black Duck apparently sees vulnerability in 2.5

[Gary Gregory]

WRT releasing, the new file system class needs to be finished/cleanup or
removed.

Gary

On Thu, May 17, 2018 at 1:27 PM, Stefan Bodewig  wrote:

> On 2018-05-17, Pascal Schumacher wrote:
>
> > Am 16.05.2018 um 08:24 schrieb Stefan Bodewig:
>
> >> Also, would there be any reason to not cut a new release from master? I
> >> mean is there any work in progress that needs to be finished?
>
> > I think a new release from master can be done any time.
>
> Thanks, I also looked through the commits. To me it looks as if master
> contained commits that address
> https://issues.apache.org/jira/browse/IO-567 but the ticket says "in
> progress".
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [io] Black Duck apparently sees vulnerability in 2.5

[Stefan Bodewig]

On 2018-05-17, Pascal Schumacher wrote:

> Am 16.05.2018 um 08:24 schrieb Stefan Bodewig:

>> Also, would there be any reason to not cut a new release from master? I
>> mean is there any work in progress that needs to be finished?

> I think a new release from master can be done any time.

Thanks, I also looked through the commits. To me it looks as if master
contained commits that address
https://issues.apache.org/jira/browse/IO-567 but the ticket says "in
progress".

Stefan

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

Re: [Statistics] Port codes from Commons Math

[Gimhana Nadeeshan]

Hi all,

We might want to create a public branch for that work in order to
> merge PRs more quickly without risk of breaking "master".
> What do you think?  Eric?
>

I ported the Statistics Interval Module and would like to get your reviews.
How should I make the Pull request ?

Best Regards,
Gimhana


On 5 May 2018 at 18:50, Gilles  wrote:

> Hi Gimhana.
>
> On Sat, 5 May 2018 15:50:43 +0530, Gimhana Nadeeshan wrote:
>
>> Hello all,
>>
>> As I proposed early I would like to begin port code from Commons-math
>>  to Commons-statistics
>> .
>> (For further details refer my  GSoC Proposal
>>
>> > OBOqTOeMnPaBsE9U5YhU/edit?usp=sharing>
>> though I'm not selected this year)
>>
>> This is my proposed architecture in brief
>>
>>1. Commons-Statistics-Core => Frequency and StatUtils classes (Can add
>>more common classes while implementing)
>>2. Commons-Statistics-Correlation
>>3. Commons-Statistics-Descriptive
>>4. Commons-Statistics-Inference
>>5. Commons-Statistics-Interval
>>6. Commons-Statistics-Ranking
>>7. Commons-Statistics-Regression
>>
>
> Nit-pick: module names have no capital in them (just a convention).
> So: "commons-statistics-core" rather than "Commons-Statistics-Core", etc.
>
> While I referring Commons-Geometry
>>
>
> No need to refer to that project since "Commons Statistics" has been
> set up:
>   http://commons.apache.org/proper/commons-statistics/
>
> The code repository is here:
>   https://git1-us-west.apache.org/repos/asf?p=commons-statisti
> cs.git;a=tree
> It already contains a "commons-statistics-distribution" module whose
> layout can be duplicated in the modules which you are proposing above
> (with appropriate changes of course).
>
> ported code to get a head start , I
>> found that each module inside, contain a pox.xml file. Are they
>> implemented
>> as separate projects and then group in the same package? I'm asking
>> because
>> Since I'm new to code porting :-).
>>
>
> A requirement is that no package should be shared between different
> modules; by convention, the top-level package of module
>   commons-statistics-descriptive
> would be
>   org.apache.commons.statistics.descriptive
>
> [And so on for the other modules. But I'd suggest you start with one.]
>
> If so in here should I create all 7 projects and then group those in same
>> project.
>>
>
> No, the project is "Commons Statisitics" and it would contain several
> _maven_ modules, each of which should ultimately map to a _JPMS_ (JDK9)
> module).
>
> Firstly I suppose to start port Ranking Module as it has less
>> dependencies comparing to others.
>>
>
> Fine. But don't forget to browse through the JIRA issues of Commons
> Math (CM) for things that would need fixing.  Whenever it's the case,
> please open a report in the new JIRA project (linking to the CM
> report), and post here your proposed solution (or questions).
>
> We might want to create a public branch for that work in order to
> merge PRs more quickly without risk of breaking "master".
> What do you think?  Eric?
>
> Would someone help me to get a head start ??
>>
>
> What else do you need?
>
> Best regards,
> Gilles
>
> Best Regards,
>> Gimhana.
>>
>>
>> [...]

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

Re: [io] Black Duck apparently sees vulnerability in 2.5

[Pascal Schumacher]

Am 16.05.2018 um 08:24 schrieb Stefan Bodewig:

Also, would there be any reason to not cut a new release from master? I
mean is there any work in progress that needs to be finished?


I think a new release from master can be done any time.

-Pascal

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

Re: [Numbers] "Experimental" release?

[Gary Gregory]

Hi All,

Note that strictly speaking, we only publish source code. Binary files like
jar files are only provided as a convenience. Apache Subversion, for
example, leaves binary production and distribution to third parties.

So a "partial release" would mean a "partial release" of sources, as
opposed to a full release of sources and a partial release of binaries. I
am sure you could rejigger the POM and assemblies to produce the a source
zip that would amount to a "partial release." I am not sure it is worth the
complication though, YMMV.

The KISS approach would be to release it all with an alpha or beta label.
You could go as far as repackaging the code with a "0" package name post
fix for an alpha or beta if BC is a real concern.

Gary

On Thu, May 17, 2018 at 6:02 AM, Gilles 
wrote:

> Hi.
>
> I only got one response to my previous question about
> a "partial" release of the code currently in [Numbers],
> which was to make a "beta" release.
> I guess that it meant an "experimental" release of
> *everything* even of code with known issues (big or
> small).
> The first release would be e.g. version 0.5 and all
> releases below 1.0 could be BC-breaking.
> Then in each release above 1.0, we'd decide which codes
> would be lifted from the "experimental" package.
>
> Is that correct?
>
> If not, please state exactly what you'd want to be done
> for getting your vote on a release candidate.
>
> If we go the "experimental" way, I'd like other useful
> modules to be added to [Numbers]:
>  * commons-numbers-rootsolver (with codes from package
>"org.apache.commons.math4.analysis.solver")
>  * commons-numbers-quadrature (with codes from package
>"org.apache.commons.math4.analysis.integration")
>  * commons-numbers-interpolator (with codes from package
>"org.apache.commons.math4.analysis.interpolation")
>  * commons-numbers-polynomial (with codes from package
>"org.apache.commons.math4.analysis.polynomials")
>
> Regards,
> Gilles
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[release-plugin] The type package-info is already defined

[Gary Gregory]

Is this a valid warning?

Description Resource Path Location Type
The type package-info is already defined package-info.java
/commons-release-plugin/src/test/java/org/apache/commons/release/plugin line
1 Java Problem
The type package-info is already defined package-info.java
/commons-release-plugin/src/test/java/org/apache/commons/release/plugin/mojos
line
1 Java Problem

Gary

Re: [maven-scm-api] Looking to perform svn remote move

[Gary Gregory]

Could we also just do an Ant Mojo that executes SVN's svnmucc directly?

Gary

On Thu, May 17, 2018 at 7:12 AM, Rob Tompkins  wrote:

> Hello maven guys,
>
> Over on commons we’ve been writing our own release-plugin, and have the
> idea to do the release promotion using a mojo. The goal here would be do do
> something analogous to svn mv  . Is that available in the
> [maven-scm-api]? At first read it doesn’t look like it. Would you instead
> just use the local file system?j Curious what your thoughts are on the
> matter.
>
> Many thanks and all the best,
> -Rob
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[maven-scm-api] Looking to perform svn remote move

[Rob Tompkins]

Hello maven guys,

Over on commons we’ve been writing our own release-plugin, and have the idea to 
do the release promotion using a mojo. The goal here would be do do something 
analogous to svn mv  . Is that available in the [maven-scm-api]? 
At first read it doesn’t look like it. Would you instead just use the local 
file system?j Curious what your thoughts are on the matter.

Many thanks and all the best,
-Rob
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[Numbers] "Experimental" release?

[Gilles]

Hi.

I only got one response to my previous question about
a "partial" release of the code currently in [Numbers],
which was to make a "beta" release.
I guess that it meant an "experimental" release of
*everything* even of code with known issues (big or
small).
The first release would be e.g. version 0.5 and all
releases below 1.0 could be BC-breaking.
Then in each release above 1.0, we'd decide which codes
would be lifted from the "experimental" package.

Is that correct?

If not, please state exactly what you'd want to be done
for getting your vote on a release candidate.

If we go the "experimental" way, I'd like other useful
modules to be added to [Numbers]:
 * commons-numbers-rootsolver (with codes from package
   "org.apache.commons.math4.analysis.solver")
 * commons-numbers-quadrature (with codes from package
   "org.apache.commons.math4.analysis.integration")
 * commons-numbers-interpolator (with codes from package
   "org.apache.commons.math4.analysis.interpolation")
 * commons-numbers-polynomial (with codes from package
   "org.apache.commons.math4.analysis.polynomials")

Regards,
Gilles


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

[GitHub] commons-io pull request #6: Introduce threadlocal buffers to avoid memory al...

[berndhopp]

Github user berndhopp closed the pull request at:

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


---

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