Re: Need help publishing main site
Thanks sebb I've added small blurbs about the scripts - and verified it actually works the way I described it by publishing the site from my local machine :-) Stefan On 2021-07-13, sebb wrote: > I have added a script to build and update the staging site: > commons-site-build.sh > This was supposed to be done by the buildbot job, but the job is no > longer being triggered by changes to SVN. > Whilst it's possible to connect to the IRC channel and trigger the > job, it's as easy to run the commands locally... > On Tue, 13 Jul 2021 at 11:26, sebb wrote: >> Found a solution after all: the buildbot failed to trigger the site >> build, so the publish picked up the old site. >> I triggered it manually, and then republished. >> I think it's OK now. >> But we will need to fix the buildbot or create a replacement script. >> On Tue, 13 Jul 2021 at 11:04, sebb wrote: >>> On Tue, 13 Jul 2021 at 10:28, Stefan Bodewig wrote: On 2021-07-13, Bruno P. Kinoshita wrote: > I think I used this page when publishing the site? > http://commons.apache.org/site-publish.html Yes, that's what I've done for the past releases as well ;-) https://cms.apache.org/commons/publish is what it tells you to use - and this one returns an error which I assume is due to the CMS being discontinued. >>> Yes. >>> I did some work to replace this. >>> $ svn co https://svn.apache.org/repos/asf/commons/cms-site/trunk cms-site >>> $ cd cms-site >>> # build the site and checkin >>> $ ./commons-site-publish.sh # this replaces the cms publish >>> # and follow the instructions. >>> I have done this, but don't have time to check further just now. >>> Maybe later today or tomorrow. Stefan - 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[compress] long uid/gids in tests (was Re: [DISCUSS] Release Compress 1.21 based on RC1)
>> Are there any tests that actually use the uid/gid of the current user? >> Compress will no read them by itself, so the only place things could >> fail was if we used native tar to create an archive. Is there such a >> test? If so we could try to adapt the test in question. On 2021-07-10, Henri Biestro wrote: > Any test based on creating/reading a file from what I gather; Yes, you are certainly correct, please forgive me. When support for Paths has been added the code started to use NIO features to obtain the uid/gid from PosixFileAttributes if available. I must admit I haven't been aware of that. Personally I still believe we shouldn't be setting bignumbermode without users explicitly asking for it. Of course our own tests are a different beast. OS detection likely will not help, uids that big may occur on other platforms than the Mac as well, I guess. One option would be to explicitly use BIGNUMBER_POSIX in tests - except those tests where it would hurt, of course. > Another mitigation could be modifying failForBigNumbers to reset > uid/gid (aka set to 0L or nobody's id?) instead of failing when they > are problematic for the chosen TAR format. This is a crude case if not being backwards compatible, I'm afraid. 0 doesn't look like a good default and I don't believe there is an agreed upon uid for nobody. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[ANNOUCE] Apache Commons IO 2.11.0
The Apache Commons Team is pleased to announce Apache Commons IO 2.11.0. Commons IO is a package of Java 8 utility classes like java.io. Changes in this version include: Fixed Bugs: o IO-741: FileUtils.listFiles does not list matching files if File parameter is a symbolic link. Thanks to Zach Sherman. o IO-724: FileUtils#deleteDirectory(File) exception Javadoc inaccurate update #245. Thanks to liran2000. o Minor changes #243. Thanks to Arturo Bernal. o Replace construction of FileInputStream and FileOutputStream objects with Files NIO APIs. #221. Thanks to Arturo Bernal. o Fix IndexOutOfBoundsException in IOExceptionList constructors. Thanks to Gary Gregory. o Remove IOException from the method signatures that no longer throw IOException. This maintains binary compatibility but not source compatibility. - FilenameUtils directoryContains(String, String) - BoundedReader BoundedReader(java.io.Reader, int) - IOUtils lineIterator(java.io.InputStream, Charset) lineIterator(java.io.InputStream, String) toByteArray(String) toInputStream(CharSequence, String) toInputStream(String, String) toString(byte[]) toString(byte[], String) Thanks to Gary Gregory. Changes: o Add SymbolicLinkFileFilter. Thanks to Gary Gregory. o Add test to make sure the setter of AndFileFilter works correctly #244. Thanks to trncate. o Add XmlStreamReader(Path). Thanks to Gary Gregory. o Bump mockito-inline from 3.11.0 to 3.11.2 #247. Thanks to Dependabot. o Bump jmh.version from 1.27 to 1.32 #237. Thanks to Dependabot. o Bump spotbugs from 4.2.3 to 4.3.0 #249. Thanks to Dependabot. Historical list of changes: https://commons.apache.org/proper/commons-io/changes-report.html For complete information on Apache Commons IO, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Apache Commons IO website: https://commons.apache.org/proper/commons-io/ Download page: https://commons.apache.org/proper/commons-io/download_io.cgi Have fun! Gary Gregory, on behalf of the Apache Commons Team
Re: [commons-math] branch master updated: Code simplifications (suggested by "sonarcloud").
> >> > The pom would have to be >> > updated to bind the other plugins from the default goal to this phase >> with >> > executions. >> >> Is there something to be changed so [Math] is aligned with [RNG]? >> > > [RNG] also does not have executions specified for spotbugs or pmd. > apache-rat and checkstyle have the check goal bound to verify. So we update > the plugin configuration to bind to verify and drop these from the default > goal as additional targets. > > I will try this on RNG and check it works as expected. > Seems to be OK locally. I've pushed the update. The default goal still has the target 'javadoc:javadoc'. This could be bound to the verify phase as well but since it is related to documentation then it should be in the site lifecycle. Currently when you execute 'mvn site' you get a javadoc report. I checked that when entering some bad javadoc into the code the 'mvn site' goals fails as does the 'mvn javadoc:javadoc' target. The javadoc:javadoc target can be left in the default goal which is executed by the CI bulids to check the source. Alex
Re: [commons-math] branch master updated: Code simplifications (suggested by "sonarcloud").
On Wed, 14 Jul 2021 at 11:49, Gilles Sadowski wrote: > Le mer. 14 juil. 2021 à 12:29, Alex Herbert a > écrit : > > > > The default goal specifies extra targets. Currently it is: > > > > clean verify apache-rat:check checkstyle:check pmd:check spotbugs:check > > javadoc:javadoc > > > > We could change the pom to bind these targets to a lifecycle phase [1] > such > > as 'verify'. > > > > Looking at the pom for CM the checkstyle plugin is configured to use the > > default goal of check. This binds to the 'verify' phase [2]. So the > > 'checkstyle:check' goal is redundant in the default goal. But apache-rat, > > spotbugs and pmd are not configured with execution bindings. > > > > However the site lifecycle is different to the default lifecycle used to > > create and install artifacts. The site lifecycle is to build the project > > documentation. It is not meant to run tests or build a jar package. > > Somewhere in commons-parent or the pom for the project the site goal runs > > tests due to a binding of a plugin for reporting. But it does not run the > > verify phase so will miss checkstyle. > > > > IIRC checkstyle was at one point run in the validate phase. This is early > > in the default lifecycle. It meant you could not run 'mvn test' without > > triggering checkstyle and so could not use System.out for dubugging. So > it > > was moved to verify. This was for Commons RNG but the configuration is > > similar across all projects descended from Math. > > > > Anyway the summary is that using 'mvn site' should not be expected to run > > all the validation checks on the code. It is to build documentation. > > Makes sense (and we were doing it wrong before). > > > If you > > want to check the code then use 'mvn verify'. > > OK. > So now are there any redundant actions in "verify" and "site"? > If you run both phases then maven will eliminate duplicates and only execute them once, i.e. it handles redundancy. Running tests in the site phase is useful as jacoco is also configured and the site report will generate coverage. Otherwise you would have to run 'mvn test site'. At present I do not know what is making this run the test phase so could not turn it off anyway. > > > The pom would have to be > > updated to bind the other plugins from the default goal to this phase > with > > executions. > > Is there something to be changed so [Math] is aligned with [RNG]? > [RNG] also does not have executions specified for spotbugs or pmd. apache-rat and checkstyle have the check goal bound to verify. So we update the plugin configuration to bind to verify and drop these from the default goal as additional targets. I will try this on RNG and check it works as expected. > > Thanks, > Gilles > > > > > Alex > > > > > > [1] > > > https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html > > [2] > https://maven.apache.org/plugins/maven-checkstyle-plugin/check-mojo.html > > > > On Wed, 14 Jul 2021 at 10:29, Gilles Sadowski > wrote: > > > > > Le mer. 14 juil. 2021 à 11:16, sebb a écrit : > > > > > > > > On Wed, 14 Jul 2021 at 10:03, Gilles Sadowski > > > wrote: > > > > > > > > > > Hi. > > > > > > > > > > Is it correct that > > > > > $ mvn site site:stage > > > > > and > > > > > $ mvn > > > > > behave differently (i.e. that the latter would not run > "CheckStyle" or > > > > > that it generates warnings instead of errors)? > > > > > > > > Depends on what the POM defines as the default target. > > > > > > Sure; but my question was whether the change of behaviour is > > > deemed better (in some way which I've missed). [IOW, why would > > > the "mvn site site:stage" build would be allowed to succeed, while > > > the default targets would make it fail?] > > > > > > > > > > > > In CM, we were used to detect all issues by running the former. > > > > > Is it expected that it's not the case anymore? > > > > > > > > > > > > > > > [...] > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [commons-math] branch master updated: Code simplifications (suggested by "sonarcloud").
Le mer. 14 juil. 2021 à 12:29, Alex Herbert a écrit : > > The default goal specifies extra targets. Currently it is: > > clean verify apache-rat:check checkstyle:check pmd:check spotbugs:check > javadoc:javadoc > > We could change the pom to bind these targets to a lifecycle phase [1] such > as 'verify'. > > Looking at the pom for CM the checkstyle plugin is configured to use the > default goal of check. This binds to the 'verify' phase [2]. So the > 'checkstyle:check' goal is redundant in the default goal. But apache-rat, > spotbugs and pmd are not configured with execution bindings. > > However the site lifecycle is different to the default lifecycle used to > create and install artifacts. The site lifecycle is to build the project > documentation. It is not meant to run tests or build a jar package. > Somewhere in commons-parent or the pom for the project the site goal runs > tests due to a binding of a plugin for reporting. But it does not run the > verify phase so will miss checkstyle. > > IIRC checkstyle was at one point run in the validate phase. This is early > in the default lifecycle. It meant you could not run 'mvn test' without > triggering checkstyle and so could not use System.out for dubugging. So it > was moved to verify. This was for Commons RNG but the configuration is > similar across all projects descended from Math. > > Anyway the summary is that using 'mvn site' should not be expected to run > all the validation checks on the code. It is to build documentation. Makes sense (and we were doing it wrong before). > If you > want to check the code then use 'mvn verify'. OK. So now are there any redundant actions in "verify" and "site"? > The pom would have to be > updated to bind the other plugins from the default goal to this phase with > executions. Is there something to be changed so [Math] is aligned with [RNG]? Thanks, Gilles > > Alex > > > [1] > https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html > [2] https://maven.apache.org/plugins/maven-checkstyle-plugin/check-mojo.html > > On Wed, 14 Jul 2021 at 10:29, Gilles Sadowski wrote: > > > Le mer. 14 juil. 2021 à 11:16, sebb a écrit : > > > > > > On Wed, 14 Jul 2021 at 10:03, Gilles Sadowski > > wrote: > > > > > > > > Hi. > > > > > > > > Is it correct that > > > > $ mvn site site:stage > > > > and > > > > $ mvn > > > > behave differently (i.e. that the latter would not run "CheckStyle" or > > > > that it generates warnings instead of errors)? > > > > > > Depends on what the POM defines as the default target. > > > > Sure; but my question was whether the change of behaviour is > > deemed better (in some way which I've missed). [IOW, why would > > the "mvn site site:stage" build would be allowed to succeed, while > > the default targets would make it fail?] > > > > > > > > > In CM, we were used to detect all issues by running the former. > > > > Is it expected that it's not the case anymore? > > > > > > > > > > > > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-math] branch master updated: Code simplifications (suggested by "sonarcloud").
The default goal specifies extra targets. Currently it is:
clean verify apache-rat:check checkstyle:check pmd:check spotbugs:check
javadoc:javadoc
We could change the pom to bind these targets to a lifecycle phase [1] such
as 'verify'.
Looking at the pom for CM the checkstyle plugin is configured to use the
default goal of check. This binds to the 'verify' phase [2]. So the
'checkstyle:check' goal is redundant in the default goal. But apache-rat,
spotbugs and pmd are not configured with execution bindings.
However the site lifecycle is different to the default lifecycle used to
create and install artifacts. The site lifecycle is to build the project
documentation. It is not meant to run tests or build a jar package.
Somewhere in commons-parent or the pom for the project the site goal runs
tests due to a binding of a plugin for reporting. But it does not run the
verify phase so will miss checkstyle.
IIRC checkstyle was at one point run in the validate phase. This is early
in the default lifecycle. It meant you could not run 'mvn test' without
triggering checkstyle and so could not use System.out for dubugging. So it
was moved to verify. This was for Commons RNG but the configuration is
similar across all projects descended from Math.
Anyway the summary is that using 'mvn site' should not be expected to run
all the validation checks on the code. It is to build documentation. If you
want to check the code then use 'mvn verify'. The pom would have to be
updated to bind the other plugins from the default goal to this phase with
executions.
Alex
[1]
https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
[2] https://maven.apache.org/plugins/maven-checkstyle-plugin/check-mojo.html
On Wed, 14 Jul 2021 at 10:29, Gilles Sadowski wrote:
> Le mer. 14 juil. 2021 à 11:16, sebb a écrit :
> >
> > On Wed, 14 Jul 2021 at 10:03, Gilles Sadowski
> wrote:
> > >
> > > Hi.
> > >
> > > Is it correct that
> > > $ mvn site site:stage
> > > and
> > > $ mvn
> > > behave differently (i.e. that the latter would not run "CheckStyle" or
> > > that it generates warnings instead of errors)?
> >
> > Depends on what the POM defines as the default target.
>
> Sure; but my question was whether the change of behaviour is
> deemed better (in some way which I've missed). [IOW, why would
> the "mvn site site:stage" build would be allowed to succeed, while
> the default targets would make it fail?]
>
> >
> > > In CM, we were used to detect all issues by running the former.
> > > Is it expected that it's not the case anymore?
> > >
> > >
> > > Thanks,
> > > Gilles
> > >
> > > Le mer. 14 juil. 2021 à 01:01, Alex Herbert
> a écrit :
> > > >
> > > > On Tue, 13 Jul 2021 at 23:41, wrote:
> > > >
> > > > > This is an automated email from the ASF dual-hosted git repository.
> > > > >
> > > > > erans pushed a commit to branch master
> > > > > in repository https://gitbox.apache.org/repos/asf/commons-math.git
> > > > >
> > > > >
> > > > > The following commit(s) were added to refs/heads/master by this
> push:
> > > > > new 8f83827 Code simplifications (suggested by "sonarcloud").
> > > > > 8f83827 is described below
> > > > >
> > > > > commit 8f838278467c1d00ba3e9e83c4f9b963cf246984
> > > > > Author: Gilles Sadowski
> > > > > AuthorDate: Wed Jul 14 00:36:10 2021 +0200
> > > > >
> > > > > Code simplifications (suggested by "sonarcloud").
> > > > > ---
> > > > > .../nonlinear/scalar/noderiv/SimplexOptimizer.java | 31
> > > > > +-
> > > > > 1 file changed, 7 insertions(+), 24 deletions(-)
> > > > >
> > > > > diff --git
> > > > >
> a/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizer.java
> > > > >
> b/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizer.java
> > > > > index e2fb510..60a2a38 100644
> > > > > ---
> > > > >
> a/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizer.java
> > > > > +++
> > > > >
> b/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizer.java
> > > > > @@ -123,27 +123,14 @@ public class SimplexOptimizer extends
> > > > > MultivariateOptimizer {
> > > > >
> > > > > // Indirect call to "computeObjectiveValue" in order to
> update the
> > > > > // evaluations counter.
> > > > > -final MultivariateFunction evalFunc
> > > > > -= new MultivariateFunction() {
> > > > > -/** {@inheritDoc} */
> > > > > -@Override
> > > > > -public double value(double[] point) {
> > > > > -return computeObjectiveValue(point);
> > > > > -}
> > > > > -};
> > > > > +final MultivariateFunction evalFunc = (p) ->
> > > > > computeObjectiveValue(p);
> > > > >
> > > >
> > > > Note you will g
Re: [commons-math] branch master updated: Code simplifications (suggested by "sonarcloud").
Le mer. 14 juil. 2021 à 12:10, sebb a écrit : > > On Wed, 14 Jul 2021 at 10:29, Gilles Sadowski wrote: > > > > Le mer. 14 juil. 2021 à 11:16, sebb a écrit : > > > > > > On Wed, 14 Jul 2021 at 10:03, Gilles Sadowski > > > wrote: > > > > > > > > Hi. > > > > > > > > Is it correct that > > > > $ mvn site site:stage > > > > and > > > > $ mvn > > > > behave differently (i.e. that the latter would not run "CheckStyle" or > > > > that it generates warnings instead of errors)? > > > > > > Depends on what the POM defines as the default target. > > > > Sure; but my question was whether the change of behaviour is > > deemed better (in some way which I've missed). [IOW, why would > > the "mvn site site:stage" build would be allowed to succeed, while > > the default targets would make it fail?] > > Do you have a proposed patch? To do what? [I'm asking a question about current behaviour.] > > > > > > > In CM, we were used to detect all issues by running the former. > > > > Is it expected that it's not the case anymore? > > > > > > > > > > > > Thanks, > > > > Gilles > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-math] branch master updated: Code simplifications (suggested by "sonarcloud").
On Wed, 14 Jul 2021 at 10:29, Gilles Sadowski wrote:
>
> Le mer. 14 juil. 2021 à 11:16, sebb a écrit :
> >
> > On Wed, 14 Jul 2021 at 10:03, Gilles Sadowski wrote:
> > >
> > > Hi.
> > >
> > > Is it correct that
> > > $ mvn site site:stage
> > > and
> > > $ mvn
> > > behave differently (i.e. that the latter would not run "CheckStyle" or
> > > that it generates warnings instead of errors)?
> >
> > Depends on what the POM defines as the default target.
>
> Sure; but my question was whether the change of behaviour is
> deemed better (in some way which I've missed). [IOW, why would
> the "mvn site site:stage" build would be allowed to succeed, while
> the default targets would make it fail?]
Do you have a proposed patch?
> >
> > > In CM, we were used to detect all issues by running the former.
> > > Is it expected that it's not the case anymore?
> > >
> > >
> > > Thanks,
> > > Gilles
> > >
> > > Le mer. 14 juil. 2021 à 01:01, Alex Herbert a
> > > écrit :
> > > >
> > > > On Tue, 13 Jul 2021 at 23:41, wrote:
> > > >
> > > > > This is an automated email from the ASF dual-hosted git repository.
> > > > >
> > > > > erans pushed a commit to branch master
> > > > > in repository https://gitbox.apache.org/repos/asf/commons-math.git
> > > > >
> > > > >
> > > > > The following commit(s) were added to refs/heads/master by this push:
> > > > > new 8f83827 Code simplifications (suggested by "sonarcloud").
> > > > > 8f83827 is described below
> > > > >
> > > > > commit 8f838278467c1d00ba3e9e83c4f9b963cf246984
> > > > > Author: Gilles Sadowski
> > > > > AuthorDate: Wed Jul 14 00:36:10 2021 +0200
> > > > >
> > > > > Code simplifications (suggested by "sonarcloud").
> > > > > ---
> > > > > .../nonlinear/scalar/noderiv/SimplexOptimizer.java | 31
> > > > > +-
> > > > > 1 file changed, 7 insertions(+), 24 deletions(-)
> > > > >
> > > > > diff --git
> > > > > a/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizer.java
> > > > > b/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizer.java
> > > > > index e2fb510..60a2a38 100644
> > > > > ---
> > > > > a/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizer.java
> > > > > +++
> > > > > b/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizer.java
> > > > > @@ -123,27 +123,14 @@ public class SimplexOptimizer extends
> > > > > MultivariateOptimizer {
> > > > >
> > > > > // Indirect call to "computeObjectiveValue" in order to
> > > > > update the
> > > > > // evaluations counter.
> > > > > -final MultivariateFunction evalFunc
> > > > > -= new MultivariateFunction() {
> > > > > -/** {@inheritDoc} */
> > > > > -@Override
> > > > > -public double value(double[] point) {
> > > > > -return computeObjectiveValue(point);
> > > > > -}
> > > > > -};
> > > > > +final MultivariateFunction evalFunc = (p) ->
> > > > > computeObjectiveValue(p);
> > > > >
> > > >
> > > > Note you will get a checkstyle fail for using parentheses here.
> > > >
> > > > Can this be replaced with the method reference:
> > > >
> > > > final MultivariateFunction evalFunc = this::computeObjectiveValue;
> > > >
> > > > I've not checked the code so you may have to substitute this:: for a
> > > > class
> > > > name if it is a static method.
> > > >
> > > > Alex
> > >
> > > -
> > > 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
> >
>
> -
> 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: [commons-math] branch master updated: Code simplifications (suggested by "sonarcloud").
Le mer. 14 juil. 2021 à 11:16, sebb a écrit :
>
> On Wed, 14 Jul 2021 at 10:03, Gilles Sadowski wrote:
> >
> > Hi.
> >
> > Is it correct that
> > $ mvn site site:stage
> > and
> > $ mvn
> > behave differently (i.e. that the latter would not run "CheckStyle" or
> > that it generates warnings instead of errors)?
>
> Depends on what the POM defines as the default target.
Sure; but my question was whether the change of behaviour is
deemed better (in some way which I've missed). [IOW, why would
the "mvn site site:stage" build would be allowed to succeed, while
the default targets would make it fail?]
>
> > In CM, we were used to detect all issues by running the former.
> > Is it expected that it's not the case anymore?
> >
> >
> > Thanks,
> > Gilles
> >
> > Le mer. 14 juil. 2021 à 01:01, Alex Herbert a
> > écrit :
> > >
> > > On Tue, 13 Jul 2021 at 23:41, wrote:
> > >
> > > > This is an automated email from the ASF dual-hosted git repository.
> > > >
> > > > erans pushed a commit to branch master
> > > > in repository https://gitbox.apache.org/repos/asf/commons-math.git
> > > >
> > > >
> > > > The following commit(s) were added to refs/heads/master by this push:
> > > > new 8f83827 Code simplifications (suggested by "sonarcloud").
> > > > 8f83827 is described below
> > > >
> > > > commit 8f838278467c1d00ba3e9e83c4f9b963cf246984
> > > > Author: Gilles Sadowski
> > > > AuthorDate: Wed Jul 14 00:36:10 2021 +0200
> > > >
> > > > Code simplifications (suggested by "sonarcloud").
> > > > ---
> > > > .../nonlinear/scalar/noderiv/SimplexOptimizer.java | 31
> > > > +-
> > > > 1 file changed, 7 insertions(+), 24 deletions(-)
> > > >
> > > > diff --git
> > > > a/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizer.java
> > > > b/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizer.java
> > > > index e2fb510..60a2a38 100644
> > > > ---
> > > > a/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizer.java
> > > > +++
> > > > b/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizer.java
> > > > @@ -123,27 +123,14 @@ public class SimplexOptimizer extends
> > > > MultivariateOptimizer {
> > > >
> > > > // Indirect call to "computeObjectiveValue" in order to update
> > > > the
> > > > // evaluations counter.
> > > > -final MultivariateFunction evalFunc
> > > > -= new MultivariateFunction() {
> > > > -/** {@inheritDoc} */
> > > > -@Override
> > > > -public double value(double[] point) {
> > > > -return computeObjectiveValue(point);
> > > > -}
> > > > -};
> > > > +final MultivariateFunction evalFunc = (p) ->
> > > > computeObjectiveValue(p);
> > > >
> > >
> > > Note you will get a checkstyle fail for using parentheses here.
> > >
> > > Can this be replaced with the method reference:
> > >
> > > final MultivariateFunction evalFunc = this::computeObjectiveValue;
> > >
> > > I've not checked the code so you may have to substitute this:: for a class
> > > name if it is a static method.
> > >
> > > Alex
> >
> > -
> > 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
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-math] branch master updated: Code simplifications (suggested by "sonarcloud").
On Wed, 14 Jul 2021 at 10:03, Gilles Sadowski wrote:
>
> Hi.
>
> Is it correct that
> $ mvn site site:stage
> and
> $ mvn
> behave differently (i.e. that the latter would not run "CheckStyle" or
> that it generates warnings instead of errors)?
Depends on what the POM defines as the default target.
> In CM, we were used to detect all issues by running the former.
> Is it expected that it's not the case anymore?
>
>
> Thanks,
> Gilles
>
> Le mer. 14 juil. 2021 à 01:01, Alex Herbert a
> écrit :
> >
> > On Tue, 13 Jul 2021 at 23:41, wrote:
> >
> > > This is an automated email from the ASF dual-hosted git repository.
> > >
> > > erans pushed a commit to branch master
> > > in repository https://gitbox.apache.org/repos/asf/commons-math.git
> > >
> > >
> > > The following commit(s) were added to refs/heads/master by this push:
> > > new 8f83827 Code simplifications (suggested by "sonarcloud").
> > > 8f83827 is described below
> > >
> > > commit 8f838278467c1d00ba3e9e83c4f9b963cf246984
> > > Author: Gilles Sadowski
> > > AuthorDate: Wed Jul 14 00:36:10 2021 +0200
> > >
> > > Code simplifications (suggested by "sonarcloud").
> > > ---
> > > .../nonlinear/scalar/noderiv/SimplexOptimizer.java | 31
> > > +-
> > > 1 file changed, 7 insertions(+), 24 deletions(-)
> > >
> > > diff --git
> > > a/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizer.java
> > > b/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizer.java
> > > index e2fb510..60a2a38 100644
> > > ---
> > > a/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizer.java
> > > +++
> > > b/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizer.java
> > > @@ -123,27 +123,14 @@ public class SimplexOptimizer extends
> > > MultivariateOptimizer {
> > >
> > > // Indirect call to "computeObjectiveValue" in order to update
> > > the
> > > // evaluations counter.
> > > -final MultivariateFunction evalFunc
> > > -= new MultivariateFunction() {
> > > -/** {@inheritDoc} */
> > > -@Override
> > > -public double value(double[] point) {
> > > -return computeObjectiveValue(point);
> > > -}
> > > -};
> > > +final MultivariateFunction evalFunc = (p) ->
> > > computeObjectiveValue(p);
> > >
> >
> > Note you will get a checkstyle fail for using parentheses here.
> >
> > Can this be replaced with the method reference:
> >
> > final MultivariateFunction evalFunc = this::computeObjectiveValue;
> >
> > I've not checked the code so you may have to substitute this:: for a class
> > name if it is a static method.
> >
> > Alex
>
> -
> 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: [commons-math] branch master updated: Code simplifications (suggested by "sonarcloud").
Hi.
Is it correct that
$ mvn site site:stage
and
$ mvn
behave differently (i.e. that the latter would not run "CheckStyle" or
that it generates warnings instead of errors)?
In CM, we were used to detect all issues by running the former.
Is it expected that it's not the case anymore?
Thanks,
Gilles
Le mer. 14 juil. 2021 à 01:01, Alex Herbert a écrit :
>
> On Tue, 13 Jul 2021 at 23:41, wrote:
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > erans pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/commons-math.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> > new 8f83827 Code simplifications (suggested by "sonarcloud").
> > 8f83827 is described below
> >
> > commit 8f838278467c1d00ba3e9e83c4f9b963cf246984
> > Author: Gilles Sadowski
> > AuthorDate: Wed Jul 14 00:36:10 2021 +0200
> >
> > Code simplifications (suggested by "sonarcloud").
> > ---
> > .../nonlinear/scalar/noderiv/SimplexOptimizer.java | 31
> > +-
> > 1 file changed, 7 insertions(+), 24 deletions(-)
> >
> > diff --git
> > a/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizer.java
> > b/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizer.java
> > index e2fb510..60a2a38 100644
> > ---
> > a/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizer.java
> > +++
> > b/commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/optim/nonlinear/scalar/noderiv/SimplexOptimizer.java
> > @@ -123,27 +123,14 @@ public class SimplexOptimizer extends
> > MultivariateOptimizer {
> >
> > // Indirect call to "computeObjectiveValue" in order to update the
> > // evaluations counter.
> > -final MultivariateFunction evalFunc
> > -= new MultivariateFunction() {
> > -/** {@inheritDoc} */
> > -@Override
> > -public double value(double[] point) {
> > -return computeObjectiveValue(point);
> > -}
> > -};
> > +final MultivariateFunction evalFunc = (p) ->
> > computeObjectiveValue(p);
> >
>
> Note you will get a checkstyle fail for using parentheses here.
>
> Can this be replaced with the method reference:
>
> final MultivariateFunction evalFunc = this::computeObjectiveValue;
>
> I've not checked the code so you may have to substitute this:: for a class
> name if it is a static method.
>
> Alex
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
