[...]
It uses a separate minimal POM, see the JIRA.
The suggested POM is optional, and assumes the examples jar has
been
released to Maven.
-1 to release examples jar
It was not meant to be the current discussion (cf. earlier posts).
[It might become relevant when the examples are more than...
examples.]
What about my other proposal, about setting up code that generates
reports (to be included in the "user guide" document)?
That belongs in a new thread with a new title ...
Then, so does the part about publishing the examples.
The original issue was to _run_ them for checking that the examples
are compilable and produce the expected output.
Namely, for the purpose of creating examples that output informative
reports (see above).
Users of CM that don't use maven, would be forced to install it,
if
they want to run the examples.
No, there is no need to install Maven if CM releases the examples
as a
jar.
[However obviously the MATH-1187 POM would be no use to them.]
But if CM does not release the examples jar then a CM user that
does
not want to install Maven may have a problem.
The standard way to build CM Math from source is to use Maven.
So unless CM provides a separate build method (Ant, or setup files
for
different IDEs, or shell scripts for different OSes)
Math has a working Ant build.
the user is going
to have to work out how to build the examples for themselves.
[CM can provide written build instructions, but the user would
have to
translate those into their own build tools]
And (to state the obvious) if a CM user only has runtime Java and
does
not want to install a JDK, then their only hope is if CM Math
releases
the examples as a compiled jar.
In the case of a CM user without Maven, the user needs to be told
what
dependencies are needed by the examples.
They then need to download all the dependencies and ensure that
they
are available on the classpath when running the examples.
One way to do this is to ensure that the jars are all in the same
directory.
The examples jar manifest can include a Classpath entry which can
list
the jars; there is then no need to list them on the java command
line
(and possibly not in the pom dependency section either)
And if the manifest has a Main-Class entry, it can be invoked as
follows:
Or use an Ant get-deps task like the math build itself does. Ant
is
a way better tool for this kind of thing than maven, IMO.
I'd prefer the minimum number of ways to achieve the goal.
To optimise a solution, one generally needs to know what all the
possible solutions are.
Or at least a few, in order to pick the least worst.
I don't mind your experimenting; the remark was about having one
final choice (which could be changed over time if necessary).
If we don't release the examples, ever, then the "maven -q
exec:java"
way is fine (since the developers most likely have maven installed).
Yes, but there are still options here.
Having to quote the full name of the class is tedious, so perhaps
need
to look at options for simplifying that.
If there are several choices, one has to "tell" the JVM what one wants;
one way or another, it won't get any significantly shorter.
If we release something (e.g. part of the examples), it looks like
the simplest and safest way (license-wise) is to write down the list
of dependencies and let the users use "whatever" to collect the
dependencies and run the code...
In that case, adding the dependencies to the manifest as Class-Path
entries makes it very easy for the end-user.
No need to create a shell script to set up the class path.
Maybe, maybe; but didn't we say it won't be published for now?
I think that we are good with "mvn -q exec ..."
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
