You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@commons.apache.org by Alex Herbert <al...@gmail.com> on 2021/07/13 23:00:43 UTC

Re: [commons-math] branch master updated: Code simplifications (suggested by "sonarcloud").

On Tue, 13 Jul 2021 at 23:41, <er...@apache.org> 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 <gi...@gmail.com>
> 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

Re: [All] Exclude a module from released binaries (Was: Issue in POM [...])

Posted by Gilles Sadowski <gi...@gmail.com>.

Le mer. 21 juil. 2021 à 16:27, Alex Herbert <al...@gmail.com> a écrit :
>
> On Wed, 21 Jul 2021 at 13:16, Gary Gregory <ga...@gmail.com> wrote:
>
> > FWIW, Commons VFS does not publish its Sandox module.
> >
> > One reason to not publish a binaray version of a module is to lessen the
> > chance of complaints of breaking changes. This might not happen for
> > examples but you never know what people do with code we put out there.
> >
>
> In [RNG] the examples are not subject to binary compatibility checks. So if
> we continue to release them then there is no guarantee of BC.

Same for all the math-related components.

> >
> > Gary
> >
> > On Wed, Jul 21, 2021, 08:06 Gilles Sadowski <gi...@gmail.com> wrote:
> >
> > > Hi.
> > >
> > > Le mer. 21 juil. 2021 à 05:09, Matt Juntunen
> > > <ma...@gmail.com> a écrit :
> > > >
> > > > Even though I've included the example module binaries in releases for
> > > > commons-numbers and commons-geometry, I would vote that we only
> > > > include them in source form in the future.
> > >
> > > Well the question is whether *this* is an acceptable option for a
> > > "Commons" component.
> > > Currently: Whatever is officially released (i.e. as source) is also
> > > provided as (convenience) binaries.
> > >
> > > IIUC departing from that needs a *vote*.
> > > [What we can readily do is (entirely) exclude a module from the
> > > release (as was done for [Numbers] v1.0).]
> > > If the rest of the message is not convincing, feel free to start a
> > > [Vote] thread.
> > >
> > > PersonalIy I don't mind either way, but I'm not sure that special
> > > handling of the "examples" is worth the trouble.
> > >
> > > > For these particular
> > > > projects, they do not seem to be worthwhile to have as binaries.
> > >
> > > Well, the benchmarks are in the "examples" module, and for one
> > > thing, it would be nice if they can be run without maven installed
> > > (I don't know whether it already works).
> > >
> > > The rest are usually toy applications but they are also meant as
> > > a "Get Started" user guide; having them part of the release ensures
> > > that they are up-to-date.
> > >
> > > Also the "examples" module sometimes contain non-trivial applications
> > > (see e.g. [RNG] thanks to Alex), and having some component exclude
> > > it while others don't will be a potential source of confusion (for the RM
> > > and the reviewers).
> >
>
> In [RNG] the examples are released but as jar files that contain only the
> classes in the examples module. We have not released the shaded jar file
> that allows you to run the example applications using only a JVM and the
> single uber jar. To run them you would have to put all the dependencies on
> the class path.
>
> There is documentation in the examples module that shows you how to build
> the uber jar and how to run it. I think this should be the way forward with
> example applications.

+1

> I do not have an issue with releasing the source and
> class files of the examples, aside from the caveat that no BC check is
> made. But if these are just the example classes then they cannot be run as
> a program without extra dependencies. I think that releasing a standalone
> uber jar to run a program may be helpful but so far we have not done it.

Given that all JAR files can be easily downloaded from the ASF mirrors,
simply documenting command-line usage should be fine.

> Licences of all the dependencies would have to be checked before doing this.
>
> I am more inclined to favour the option of the examples as being extended
> documentation on the particular release. They can be referenced in the
> documentation for the project and CI builds should ensure they compile to
> keep them current. Adding tests to run the command line programs to
> exercise all the functionality is a lot of work and I would not recommend
> it.

Sure, the additional utilities should not entail additional burden for us.

> The jars can be released just so they can be included as a
> dependency for a reference of the state at the time of the release.
>
>
> > >
> > > > I have not looked at the commons-math examples, though.
> > >
> > > Those that illustrate usage of the "neuralnet" codes are some kind of
> > > validation tests; without them, unit tests are not sufficient to
> > > demonstrate
> > > that the code works as expected (cf. the relatively low coverage).
> >
>
> This sounds like an integration test.

Indeed, they need to combine several classes (thus not a "unit" test).

> Can the current example that is run
> as a command-line application be invoked with the various parameters and
> the output tested that it appears as expected?

I suppose it could; but the toy applications are not worth the trouble.
For the "Traveling Salesman Problem" example, the output is less
interesting (the "problem" is hard-coded) than the source displaying
concurrent usage of the classes.

Regards,
Gilles

>>> [....]

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

Re: [All] Exclude a module from released binaries (Was: Issue in POM [...])

Posted by Alex Herbert <al...@gmail.com>.

On Wed, 21 Jul 2021 at 13:16, Gary Gregory <ga...@gmail.com> wrote:

> FWIW, Commons VFS does not publish its Sandox module.
>
> One reason to not publish a binaray version of a module is to lessen the
> chance of complaints of breaking changes. This might not happen for
> examples but you never know what people do with code we put out there.
>

In [RNG] the examples are not subject to binary compatibility checks. So if
we continue to release them then there is no guarantee of BC.

>
> Gary
>
> On Wed, Jul 21, 2021, 08:06 Gilles Sadowski <gi...@gmail.com> wrote:
>
> > Hi.
> >
> > Le mer. 21 juil. 2021 à 05:09, Matt Juntunen
> > <ma...@gmail.com> a écrit :
> > >
> > > Even though I've included the example module binaries in releases for
> > > commons-numbers and commons-geometry, I would vote that we only
> > > include them in source form in the future.
> >
> > Well the question is whether *this* is an acceptable option for a
> > "Commons" component.
> > Currently: Whatever is officially released (i.e. as source) is also
> > provided as (convenience) binaries.
> >
> > IIUC departing from that needs a *vote*.
> > [What we can readily do is (entirely) exclude a module from the
> > release (as was done for [Numbers] v1.0).]
> > If the rest of the message is not convincing, feel free to start a
> > [Vote] thread.
> >
> > PersonalIy I don't mind either way, but I'm not sure that special
> > handling of the "examples" is worth the trouble.
> >
> > > For these particular
> > > projects, they do not seem to be worthwhile to have as binaries.
> >
> > Well, the benchmarks are in the "examples" module, and for one
> > thing, it would be nice if they can be run without maven installed
> > (I don't know whether it already works).
> >
> > The rest are usually toy applications but they are also meant as
> > a "Get Started" user guide; having them part of the release ensures
> > that they are up-to-date.
> >
> > Also the "examples" module sometimes contain non-trivial applications
> > (see e.g. [RNG] thanks to Alex), and having some component exclude
> > it while others don't will be a potential source of confusion (for the RM
> > and the reviewers).
>

In [RNG] the examples are released but as jar files that contain only the
classes in the examples module. We have not released the shaded jar file
that allows you to run the example applications using only a JVM and the
single uber jar. To run them you would have to put all the dependencies on
the class path.

There is documentation in the examples module that shows you how to build
the uber jar and how to run it. I think this should be the way forward with
example applications. I do not have an issue with releasing the source and
class files of the examples, aside from the caveat that no BC check is
made. But if these are just the example classes then they cannot be run as
a program without extra dependencies. I think that releasing a standalone
uber jar to run a program may be helpful but so far we have not done it.
Licences of all the dependencies would have to be checked before doing this.

I am more inclined to favour the option of the examples as being extended
documentation on the particular release. They can be referenced in the
documentation for the project and CI builds should ensure they compile to
keep them current. Adding tests to run the command line programs to
exercise all the functionality is a lot of work and I would not recommend
it. The jars can be released just so they can be included as a
dependency for a reference of the state at the time of the release.

> >
> > > I have not looked at the commons-math examples, though.
> >
> > Those that illustrate usage of the "neuralnet" codes are some kind of
> > validation tests; without them, unit tests are not sufficient to
> > demonstrate
> > that the code works as expected (cf. the relatively low coverage).
>

This sounds like an integration test. Can the current example that is run
as a command-line application be invoked with the various parameters and
the output tested that it appears as expected?

> >
> > Regards,
> > Gilles
> >
> > >>> [....]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>

Re: [All] Exclude a module from released binaries (Was: Issue in POM [...])

Posted by Gary Gregory <ga...@gmail.com>.

FWIW, Commons VFS does not publish its Sandox module.

One reason to not publish a binaray version of a module is to lessen the
chance of complaints of breaking changes. This might not happen for
examples but you never know what people do with code we put out there.

Gary

On Wed, Jul 21, 2021, 08:06 Gilles Sadowski <gi...@gmail.com> wrote:

> Hi.
>
> Le mer. 21 juil. 2021 à 05:09, Matt Juntunen
> <ma...@gmail.com> a écrit :
> >
> > Even though I've included the example module binaries in releases for
> > commons-numbers and commons-geometry, I would vote that we only
> > include them in source form in the future.
>
> Well the question is whether *this* is an acceptable option for a
> "Commons" component.
> Currently: Whatever is officially released (i.e. as source) is also
> provided as (convenience) binaries.
>
> IIUC departing from that needs a *vote*.
> [What we can readily do is (entirely) exclude a module from the
> release (as was done for [Numbers] v1.0).]
> If the rest of the message is not convincing, feel free to start a
> [Vote] thread.
>
> PersonalIy I don't mind either way, but I'm not sure that special
> handling of the "examples" is worth the trouble.
>
> > For these particular
> > projects, they do not seem to be worthwhile to have as binaries.
>
> Well, the benchmarks are in the "examples" module, and for one
> thing, it would be nice if they can be run without maven installed
> (I don't know whether it already works).
>
> The rest are usually toy applications but they are also meant as
> a "Get Started" user guide; having them part of the release ensures
> that they are up-to-date.
>
> Also the "examples" module sometimes contain non-trivial applications
> (see e.g. [RNG] thanks to Alex), and having some component exclude
> it while others don't will be a potential source of confusion (for the RM
> and the reviewers).
>
> > I have not looked at the commons-math examples, though.
>
> Those that illustrate usage of the "neuralnet" codes are some kind of
> validation tests; without them, unit tests are not sufficient to
> demonstrate
> that the code works as expected (cf. the relatively low coverage).
>
> Regards,
> Gilles
>
> >>> [....]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

[All] Exclude a module from released binaries (Was: Issue in POM [...])

Posted by Gilles Sadowski <gi...@gmail.com>.

Hi.

Le mer. 21 juil. 2021 à 05:09, Matt Juntunen
<ma...@gmail.com> a écrit :
>
> Even though I've included the example module binaries in releases for
> commons-numbers and commons-geometry, I would vote that we only
> include them in source form in the future.

Well the question is whether *this* is an acceptable option for a
"Commons" component.
Currently: Whatever is officially released (i.e. as source) is also
provided as (convenience) binaries.

IIUC departing from that needs a *vote*.
[What we can readily do is (entirely) exclude a module from the
release (as was done for [Numbers] v1.0).]
If the rest of the message is not convincing, feel free to start a
[Vote] thread.

PersonalIy I don't mind either way, but I'm not sure that special
handling of the "examples" is worth the trouble.

> For these particular
> projects, they do not seem to be worthwhile to have as binaries.

Well, the benchmarks are in the "examples" module, and for one
thing, it would be nice if they can be run without maven installed
(I don't know whether it already works).

The rest are usually toy applications but they are also meant as
a "Get Started" user guide; having them part of the release ensures
that they are up-to-date.

Also the "examples" module sometimes contain non-trivial applications
(see e.g. [RNG] thanks to Alex), and having some component exclude
it while others don't will be a potential source of confusion (for the RM
and the reviewers).

> I have not looked at the commons-math examples, though.

Those that illustrate usage of the "neuralnet" codes are some kind of
validation tests; without them, unit tests are not sufficient to demonstrate
that the code works as expected (cf. the relatively low coverage).

Regards,
Gilles

>>> [....]

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

Re: [Math] Issue in POM (?)

Posted by Matt Juntunen <ma...@gmail.com>.

Even though I've included the example module binaries in releases for
commons-numbers and commons-geometry, I would vote that we only
include them in source form in the future. For these particular
projects, they do not seem to be worthwhile to have as binaries. I
have not looked at the commons-math examples, though.

-Matt J

On Tue, Jul 20, 2021 at 7:17 PM Gilles Sadowski <gi...@gmail.com> wrote:
>
> Le mer. 21 juil. 2021 à 00:32, Matt Juntunen
> <ma...@gmail.com> a écrit :
> >
> > > I completely agree.  But how can we release (some official version of)
> > > the project as source without also releasing the (convenience) binaries
> > > for everything?
> >
> > I don't understand the question here. Wouldn't we just include all
> > example code in the source distribution but only create binaries for
> > the primary API? Is there some requirement related to what binaries
> > are produced?
>
> In practice, all sources are handled in the same way and the
> question has to be raised so that an answer can be given...
>
> >
> > -Matt J
> >
> > On Sun, Jul 18, 2021 at 5:14 PM Gilles Sadowski <gi...@gmail.com> wrote:
> > >
> > > > > > > [...]
> > > > > > Building from the project root I get the same error you reported.
> > > > > >
> > > > > > This post of StackOverflow [1] indicates that this is a problem with
> > > > > > running the shade plugin within a multi-phase command. It is related to
> > > > > > dependency resolution when the shade plugin tried to incorporate all the
> > > > > > classes in the final jar. If building all the classes it the same phase
> > > > > > then it appears to break. If left to download them (as in my first
> > > > > example)
> > > > > > then it works.
> > > > >
> > > > > $ mvn verify
> > > > > --> SUCCESS
> > > > >
> > > > > $ mvn verify site
> > > > > --> SUCCESS
> > > > >
> > > > > $ mvn verify test site
> > > > > --> FAILURE
> > > > >
> > > > > $ mvn test package verify site
> > > > > --> SUCCESS
> > > > >
> > > >
> > > > This is inconsistent to say the least. The bug MSHADE-215 [1] appears to
> > > > indicate that running 'test package' will fail and running 'package' will
> > > > succeed. Anyway it may be the same thing where adding the 'test' target
> > > > somewhere in the set of targets causes the shade plugin to include classes
> > > > using a directory but label them as a jar.
> > > >
> > > >
> > > > [1] https://issues.apache.org/jira/browse/MSHADE-215
> > > >
> > > >
> > > > >
> > > > > I notice that junit runs in the "verify" phase; so, is the "test" phase
> > > > > always redundant (before a commit)?
> > > > >
> > > >
> > > > If running a target that is after 'test' in the lifecycle then yes, 'test'
> > > > is redundant. If you use 'verify' you do not need 'test'. Adding 'test'
> > > > appears to trigger a bug in the shade plugin using some combinations of
> > > > targets later than 'test' from the default lifecycle.
> > > >
> > > >
> > > > >
> > > > > > I suggest the shaded jar is added within a profile and not on the default
> > > > > > build. Thus you need to explicitly build the shaded jar.
> > > > > >
> > > > > > Is it the intention to release this artifact? Otherwise build on-demand
> > > > > via
> > > > > > a profile should solve this.
> > > > >
> > > > > Do you propose that the "commons-math-examples" not be part of the
> > > > > official release?
> > > > >
> > > >
> > > > Are they of value as a dependency to be used by others? If we release the
> > > > standard jars from the examples modules then they can be included as a
> > > > dependency and that will bring everything upstream with it to a project.
> > > >
> > > > The question is whether the shaded jar has value as a released artifact. I
> > > > always considered them proof-of-application demos rather than programs that
> > > > had far reaching utility.
> > >
> > > I completely agree.  But how can we release (some official version of)
> > > the project as source without also releasing the (convenience) binaries
> > > for everything?
> > >
> > > Regards,
> > > Gilles
> > >
> > > > > >
> > > > > > [1] https://stackoverflow.com/questions/37942689/maven-shade-plugin-reports-error-creating-shaded-jar-target-classes-is-a-d
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

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

Re: [Math] Issue in POM (?)

Posted by Gilles Sadowski <gi...@gmail.com>.

Le mer. 21 juil. 2021 à 00:32, Matt Juntunen
<ma...@gmail.com> a écrit :
>
> > I completely agree.  But how can we release (some official version of)
> > the project as source without also releasing the (convenience) binaries
> > for everything?
>
> I don't understand the question here. Wouldn't we just include all
> example code in the source distribution but only create binaries for
> the primary API? Is there some requirement related to what binaries
> are produced?

In practice, all sources are handled in the same way and the
question has to be raised so that an answer can be given...

>
> -Matt J
>
> On Sun, Jul 18, 2021 at 5:14 PM Gilles Sadowski <gi...@gmail.com> wrote:
> >
> > > > > > [...]
> > > > > Building from the project root I get the same error you reported.
> > > > >
> > > > > This post of StackOverflow [1] indicates that this is a problem with
> > > > > running the shade plugin within a multi-phase command. It is related to
> > > > > dependency resolution when the shade plugin tried to incorporate all the
> > > > > classes in the final jar. If building all the classes it the same phase
> > > > > then it appears to break. If left to download them (as in my first
> > > > example)
> > > > > then it works.
> > > >
> > > > $ mvn verify
> > > > --> SUCCESS
> > > >
> > > > $ mvn verify site
> > > > --> SUCCESS
> > > >
> > > > $ mvn verify test site
> > > > --> FAILURE
> > > >
> > > > $ mvn test package verify site
> > > > --> SUCCESS
> > > >
> > >
> > > This is inconsistent to say the least. The bug MSHADE-215 [1] appears to
> > > indicate that running 'test package' will fail and running 'package' will
> > > succeed. Anyway it may be the same thing where adding the 'test' target
> > > somewhere in the set of targets causes the shade plugin to include classes
> > > using a directory but label them as a jar.
> > >
> > >
> > > [1] https://issues.apache.org/jira/browse/MSHADE-215
> > >
> > >
> > > >
> > > > I notice that junit runs in the "verify" phase; so, is the "test" phase
> > > > always redundant (before a commit)?
> > > >
> > >
> > > If running a target that is after 'test' in the lifecycle then yes, 'test'
> > > is redundant. If you use 'verify' you do not need 'test'. Adding 'test'
> > > appears to trigger a bug in the shade plugin using some combinations of
> > > targets later than 'test' from the default lifecycle.
> > >
> > >
> > > >
> > > > > I suggest the shaded jar is added within a profile and not on the default
> > > > > build. Thus you need to explicitly build the shaded jar.
> > > > >
> > > > > Is it the intention to release this artifact? Otherwise build on-demand
> > > > via
> > > > > a profile should solve this.
> > > >
> > > > Do you propose that the "commons-math-examples" not be part of the
> > > > official release?
> > > >
> > >
> > > Are they of value as a dependency to be used by others? If we release the
> > > standard jars from the examples modules then they can be included as a
> > > dependency and that will bring everything upstream with it to a project.
> > >
> > > The question is whether the shaded jar has value as a released artifact. I
> > > always considered them proof-of-application demos rather than programs that
> > > had far reaching utility.
> >
> > I completely agree.  But how can we release (some official version of)
> > the project as source without also releasing the (convenience) binaries
> > for everything?
> >
> > Regards,
> > Gilles
> >
> > > > >
> > > > > [1] https://stackoverflow.com/questions/37942689/maven-shade-plugin-reports-error-creating-shaded-jar-target-classes-is-a-d

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

Re: [Math] Issue in POM (?)

Posted by Matt Juntunen <ma...@gmail.com>.

> I completely agree.  But how can we release (some official version of)
> the project as source without also releasing the (convenience) binaries
> for everything?

I don't understand the question here. Wouldn't we just include all
example code in the source distribution but only create binaries for
the primary API? Is there some requirement related to what binaries
are produced?

-Matt J

On Sun, Jul 18, 2021 at 5:14 PM Gilles Sadowski <gi...@gmail.com> wrote:
>
> > > > > [...]
> > > > Building from the project root I get the same error you reported.
> > > >
> > > > This post of StackOverflow [1] indicates that this is a problem with
> > > > running the shade plugin within a multi-phase command. It is related to
> > > > dependency resolution when the shade plugin tried to incorporate all the
> > > > classes in the final jar. If building all the classes it the same phase
> > > > then it appears to break. If left to download them (as in my first
> > > example)
> > > > then it works.
> > >
> > > $ mvn verify
> > > --> SUCCESS
> > >
> > > $ mvn verify site
> > > --> SUCCESS
> > >
> > > $ mvn verify test site
> > > --> FAILURE
> > >
> > > $ mvn test package verify site
> > > --> SUCCESS
> > >
> >
> > This is inconsistent to say the least. The bug MSHADE-215 [1] appears to
> > indicate that running 'test package' will fail and running 'package' will
> > succeed. Anyway it may be the same thing where adding the 'test' target
> > somewhere in the set of targets causes the shade plugin to include classes
> > using a directory but label them as a jar.
> >
> >
> > [1] https://issues.apache.org/jira/browse/MSHADE-215
> >
> >
> > >
> > > I notice that junit runs in the "verify" phase; so, is the "test" phase
> > > always redundant (before a commit)?
> > >
> >
> > If running a target that is after 'test' in the lifecycle then yes, 'test'
> > is redundant. If you use 'verify' you do not need 'test'. Adding 'test'
> > appears to trigger a bug in the shade plugin using some combinations of
> > targets later than 'test' from the default lifecycle.
> >
> >
> > >
> > > > I suggest the shaded jar is added within a profile and not on the default
> > > > build. Thus you need to explicitly build the shaded jar.
> > > >
> > > > Is it the intention to release this artifact? Otherwise build on-demand
> > > via
> > > > a profile should solve this.
> > >
> > > Do you propose that the "commons-math-examples" not be part of the
> > > official release?
> > >
> >
> > Are they of value as a dependency to be used by others? If we release the
> > standard jars from the examples modules then they can be included as a
> > dependency and that will bring everything upstream with it to a project.
> >
> > The question is whether the shaded jar has value as a released artifact. I
> > always considered them proof-of-application demos rather than programs that
> > had far reaching utility.
>
> I completely agree.  But how can we release (some official version of)
> the project as source without also releasing the (convenience) binaries
> for everything?
>
> Regards,
> Gilles
>
> > > >
> > > > [1] https://stackoverflow.com/questions/37942689/maven-shade-plugin-reports-error-creating-shaded-jar-target-classes-is-a-d
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

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

Re: [Math] Issue in POM (?)

Posted by Gilles Sadowski <gi...@gmail.com>.

> > > > [...]
> > > Building from the project root I get the same error you reported.
> > >
> > > This post of StackOverflow [1] indicates that this is a problem with
> > > running the shade plugin within a multi-phase command. It is related to
> > > dependency resolution when the shade plugin tried to incorporate all the
> > > classes in the final jar. If building all the classes it the same phase
> > > then it appears to break. If left to download them (as in my first
> > example)
> > > then it works.
> >
> > $ mvn verify
> > --> SUCCESS
> >
> > $ mvn verify site
> > --> SUCCESS
> >
> > $ mvn verify test site
> > --> FAILURE
> >
> > $ mvn test package verify site
> > --> SUCCESS
> >
>
> This is inconsistent to say the least. The bug MSHADE-215 [1] appears to
> indicate that running 'test package' will fail and running 'package' will
> succeed. Anyway it may be the same thing where adding the 'test' target
> somewhere in the set of targets causes the shade plugin to include classes
> using a directory but label them as a jar.
>
>
> [1] https://issues.apache.org/jira/browse/MSHADE-215
>
>
> >
> > I notice that junit runs in the "verify" phase; so, is the "test" phase
> > always redundant (before a commit)?
> >
>
> If running a target that is after 'test' in the lifecycle then yes, 'test'
> is redundant. If you use 'verify' you do not need 'test'. Adding 'test'
> appears to trigger a bug in the shade plugin using some combinations of
> targets later than 'test' from the default lifecycle.
>
>
> >
> > > I suggest the shaded jar is added within a profile and not on the default
> > > build. Thus you need to explicitly build the shaded jar.
> > >
> > > Is it the intention to release this artifact? Otherwise build on-demand
> > via
> > > a profile should solve this.
> >
> > Do you propose that the "commons-math-examples" not be part of the
> > official release?
> >
>
> Are they of value as a dependency to be used by others? If we release the
> standard jars from the examples modules then they can be included as a
> dependency and that will bring everything upstream with it to a project.
>
> The question is whether the shaded jar has value as a released artifact. I
> always considered them proof-of-application demos rather than programs that
> had far reaching utility.

I completely agree.  But how can we release (some official version of)
the project as source without also releasing the (convenience) binaries
for everything?

Regards,
Gilles

> > >
> > > [1] https://stackoverflow.com/questions/37942689/maven-shade-plugin-reports-error-creating-shaded-jar-target-classes-is-a-d

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

Re: [Math] Issue in POM (?)

Posted by Alex Herbert <al...@gmail.com>.

On Sun, 18 Jul 2021 at 10:19, Gilles Sadowski <gi...@gmail.com> wrote:

> Hi.
>
> Le sam. 17 juil. 2021 à 18:17, Alex Herbert <al...@gmail.com> a
> écrit :
> >
> > On Sat, 17 Jul 2021 at 15:59, Alex Herbert <al...@gmail.com>
> wrote:
> >
> > >
> > >
> > > On Sat, 17 Jul 2021 at 14:17, Gilles Sadowski <gi...@gmail.com>
> > > wrote:
> > >
> > >> Hi.
> > >>
> > >> Le mer. 14 juil. 2021 à 13:02, Alex Herbert <al...@gmail.com>
> a
> > >> écrit :
> > >> >
> > >> >>> [...]
> > >> > > > 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'.
> > >>
> > >> Command
> > >>   $ JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn clean verify test
> > >> site
> > >> currently results in the build failing:
> > >> ---CUT---
> > >> [ERROR] Failed to execute goal
> > >> org.apache.maven.plugins:maven-shade-plugin:3.1.1:shade (default) on
> > >> project examples-sofm: Error creating shaded jar:
> > >>
> > >>
> /home/gilles/devel/java/apache/commons-math/trunk/commons-math-neuralnet/target/classes
> > >> (Is a directory) -> [Help 1]
> > >> ---CUT---
> > >>
> > >> Any idea?
> > >>
> > >
> > > This works for me (have JAVA_HOME already set):
> > >
> > > mvn -v
> > >
> > > *Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)*
> > >
> > > Maven home: /usr/local/apache-maven-3.6.3
> > >
> > > Java version: 1.8.0_241, vendor: Oracle Corporation, runtime:
> > > /Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/jre
> > >
> > > Default locale: en_US, platform encoding: UTF-8
> > >
> > > OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
> > >
> > > cd commons-math-examples/
> > >
> > > touch site-content
> > >
> > > touch chinese-rings/site-content
> > >
> > > touch tsp/site-content
> > >
> > > mvn clean verify test site
> > >
> > >
> > >
> > Building from the project root I get the same error you reported.
> >
> > This post of StackOverflow [1] indicates that this is a problem with
> > running the shade plugin within a multi-phase command. It is related to
> > dependency resolution when the shade plugin tried to incorporate all the
> > classes in the final jar. If building all the classes it the same phase
> > then it appears to break. If left to download them (as in my first
> example)
> > then it works.
>
> $ mvn verify
> --> SUCCESS
>
> $ mvn verify site
> --> SUCCESS
>
> $ mvn verify test site
> --> FAILURE
>
> $ mvn test package verify site
> --> SUCCESS
>

This is inconsistent to say the least. The bug MSHADE-215 [1] appears to
indicate that running 'test package' will fail and running 'package' will
succeed. Anyway it may be the same thing where adding the 'test' target
somewhere in the set of targets causes the shade plugin to include classes
using a directory but label them as a jar.


[1] https://issues.apache.org/jira/browse/MSHADE-215


>
> I notice that junit runs in the "verify" phase; so, is the "test" phase
> always redundant (before a commit)?
>

If running a target that is after 'test' in the lifecycle then yes, 'test'
is redundant. If you use 'verify' you do not need 'test'. Adding 'test'
appears to trigger a bug in the shade plugin using some combinations of
targets later than 'test' from the default lifecycle.


>
> > I suggest the shaded jar is added within a profile and not on the default
> > build. Thus you need to explicitly build the shaded jar.
> >
> > Is it the intention to release this artifact? Otherwise build on-demand
> via
> > a profile should solve this.
>
> Do you propose that the "commons-math-examples" not be part of the
> official release?
>

Are they of value as a dependency to be used by others? If we release the
standard jars from the examples modules then they can be included as a
dependency and that will bring everything upstream with it to a project.

The question is whether the shaded jar has value as a released artifact. I
always considered them proof-of-application demos rather than programs that
had far reaching utility.


>
> Regards,
> Gilles
>
> >
> > [1]
> >
> https://stackoverflow.com/questions/37942689/maven-shade-plugin-reports-error-creating-shaded-jar-target-classes-is-a-d
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [Math] Issue in POM (?)

Posted by Gilles Sadowski <gi...@gmail.com>.

Hi.

Le sam. 17 juil. 2021 à 18:17, Alex Herbert <al...@gmail.com> a écrit :
>
> On Sat, 17 Jul 2021 at 15:59, Alex Herbert <al...@gmail.com> wrote:
>
> >
> >
> > On Sat, 17 Jul 2021 at 14:17, Gilles Sadowski <gi...@gmail.com>
> > wrote:
> >
> >> Hi.
> >>
> >> Le mer. 14 juil. 2021 à 13:02, Alex Herbert <al...@gmail.com> a
> >> écrit :
> >> >
> >> >>> [...]
> >> > > > 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'.
> >>
> >> Command
> >>   $ JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn clean verify test
> >> site
> >> currently results in the build failing:
> >> ---CUT---
> >> [ERROR] Failed to execute goal
> >> org.apache.maven.plugins:maven-shade-plugin:3.1.1:shade (default) on
> >> project examples-sofm: Error creating shaded jar:
> >>
> >> /home/gilles/devel/java/apache/commons-math/trunk/commons-math-neuralnet/target/classes
> >> (Is a directory) -> [Help 1]
> >> ---CUT---
> >>
> >> Any idea?
> >>
> >
> > This works for me (have JAVA_HOME already set):
> >
> > mvn -v
> >
> > *Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)*
> >
> > Maven home: /usr/local/apache-maven-3.6.3
> >
> > Java version: 1.8.0_241, vendor: Oracle Corporation, runtime:
> > /Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/jre
> >
> > Default locale: en_US, platform encoding: UTF-8
> >
> > OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
> >
> > cd commons-math-examples/
> >
> > touch site-content
> >
> > touch chinese-rings/site-content
> >
> > touch tsp/site-content
> >
> > mvn clean verify test site
> >
> >
> >
> Building from the project root I get the same error you reported.
>
> This post of StackOverflow [1] indicates that this is a problem with
> running the shade plugin within a multi-phase command. It is related to
> dependency resolution when the shade plugin tried to incorporate all the
> classes in the final jar. If building all the classes it the same phase
> then it appears to break. If left to download them (as in my first example)
> then it works.

$ mvn verify
--> SUCCESS

$ mvn verify site
--> SUCCESS

$ mvn verify test site
--> FAILURE

$ mvn test package verify site
--> SUCCESS

I notice that junit runs in the "verify" phase; so, is the "test" phase
always redundant (before a commit)?

> I suggest the shaded jar is added within a profile and not on the default
> build. Thus you need to explicitly build the shaded jar.
>
> Is it the intention to release this artifact? Otherwise build on-demand via
> a profile should solve this.

Do you propose that the "commons-math-examples" not be part of the
official release?

Regards,
Gilles

>
> [1]
> https://stackoverflow.com/questions/37942689/maven-shade-plugin-reports-error-creating-shaded-jar-target-classes-is-a-d

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

Re: [Math] Issue in POM (?)

Posted by Alex Herbert <al...@gmail.com>.

On Sat, 17 Jul 2021 at 15:59, Alex Herbert <al...@gmail.com> wrote:

>
>
> On Sat, 17 Jul 2021 at 14:17, Gilles Sadowski <gi...@gmail.com>
> wrote:
>
>> Hi.
>>
>> Le mer. 14 juil. 2021 à 13:02, Alex Herbert <al...@gmail.com> a
>> écrit :
>> >
>> >>> [...]
>> > > > 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'.
>>
>> Command
>>   $ JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn clean verify test
>> site
>> currently results in the build failing:
>> ---CUT---
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-shade-plugin:3.1.1:shade (default) on
>> project examples-sofm: Error creating shaded jar:
>>
>> /home/gilles/devel/java/apache/commons-math/trunk/commons-math-neuralnet/target/classes
>> (Is a directory) -> [Help 1]
>> ---CUT---
>>
>> Any idea?
>>
>
> This works for me (have JAVA_HOME already set):
>
> mvn -v
>
> *Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)*
>
> Maven home: /usr/local/apache-maven-3.6.3
>
> Java version: 1.8.0_241, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/jre
>
> Default locale: en_US, platform encoding: UTF-8
>
> OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
>
> cd commons-math-examples/
>
> touch site-content
>
> touch chinese-rings/site-content
>
> touch tsp/site-content
>
> mvn clean verify test site
>
>
>
Building from the project root I get the same error you reported.

This post of StackOverflow [1] indicates that this is a problem with
running the shade plugin within a multi-phase command. It is related to
dependency resolution when the shade plugin tried to incorporate all the
classes in the final jar. If building all the classes it the same phase
then it appears to break. If left to download them (as in my first example)
then it works.

I suggest the shaded jar is added within a profile and not on the default
build. Thus you need to explicitly build the shaded jar.

Is it the intention to release this artifact? Otherwise build on-demand via
a profile should solve this.

Alex


[1]
https://stackoverflow.com/questions/37942689/maven-shade-plugin-reports-error-creating-shaded-jar-target-classes-is-a-d

Re: [Math] Issue in POM (?)

Posted by Alex Herbert <al...@gmail.com>.

On Sat, 17 Jul 2021 at 14:17, Gilles Sadowski <gi...@gmail.com> wrote:

> Hi.
>
> Le mer. 14 juil. 2021 à 13:02, Alex Herbert <al...@gmail.com> a
> écrit :
> >
> >>> [...]
> > > > 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'.
>
> Command
>   $ JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn clean verify test site
> currently results in the build failing:
> ---CUT---
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-shade-plugin:3.1.1:shade (default) on
> project examples-sofm: Error creating shaded jar:
>
> /home/gilles/devel/java/apache/commons-math/trunk/commons-math-neuralnet/target/classes
> (Is a directory) -> [Help 1]
> ---CUT---
>
> Any idea?
>

This works for me (have JAVA_HOME already set):

mvn -v

*Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)*

Maven home: /usr/local/apache-maven-3.6.3

Java version: 1.8.0_241, vendor: Oracle Corporation, runtime:
/Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/jre

Default locale: en_US, platform encoding: UTF-8

OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"

cd commons-math-examples/

touch site-content

touch chinese-rings/site-content

touch tsp/site-content

mvn clean verify test site



> Thanks,
> Gilles
>
> >>> [...]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

[Math] Issue in POM (?)

Posted by Gilles Sadowski <gi...@gmail.com>.

Hi.

Le mer. 14 juil. 2021 à 13:02, Alex Herbert <al...@gmail.com> a écrit :
>
>>> [...]
> > > 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'.

Command
  $ JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn clean verify test site
currently results in the build failing:
---CUT---
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-shade-plugin:3.1.1:shade (default) on
project examples-sofm: Error creating shaded jar:
/home/gilles/devel/java/apache/commons-math/trunk/commons-math-neuralnet/target/classes
(Is a directory) -> [Help 1]
---CUT---

Any idea?

Thanks,
Gilles

>>> [...]

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