On 7 January 2015 at 17:12, Thomas Neidhart <thomas.neidh...@gmail.com> wrote: > On 01/07/2015 06:00 PM, sebb wrote: >> On 7 January 2015 at 16:29, Thomas Neidhart <thomas.neidh...@gmail.com> >> wrote: >>> On 01/07/2015 04:50 PM, sebb wrote: >>>> On 7 January 2015 at 13:59, Gilles <gil...@harfang.homelinux.org> wrote: >>>>>>> [...] >>>>>> >>>>>> >>>>>> I have pushed the change to the userguide. To execute the example you do >>>>>> the following: >>>>>> >>>>>> * go to commons-math folder, type mvn clean install >>>>>> this step is only needed if your local maven repository does not yet >>>>>> contain the latest commons-math snapshot >>>>>> * go to userguide folder (src/userguide), type mvn clean package >>>>>> * now you can run the examples like that: >>>>>> >>>>>> java -cp target/commons-math3-examples-uber-3.5-SNAPSHOT.jar >>>>>> org.apache.commons.math3.userguide.LowDiscrepancyGeneratorComparison >>>>> >>>>> >>>>> Very nice. >>>> >>>> Yes, however there is a caveat. >>>> The uber jar must not be published, at least in its current form. >>>> - it contains un-shaded classes that have different Maven coords (=> jar >>>> hell) >>>> - it does not have N&L files >>>> - are the 3rd party jars AL compatible? >>> >>> there is no intention to publish the uber jar. >> >> OK. >> >>>> There is another way to run the code without needing to generate the jars: >>>> >>>> cd src/userguide >>>> >>>> mvn -q exec:java >>>> -Dexec.mainClass=org.apache.commons.math3.userguide.LowDiscrepancyGeneratorComparison >>> >>> nice, did not know this trick before. >>> >>>> This uses Maven to resolve the dependencies. >>>> >>>> Works very well for developer testing of examples. >>>> However it is not so useful for end users as they would need Maven and >>>> the Math source. >>>> >>>> The NET jar method works well because there are no external >>>> dependencies, and the example jar is created in the same directory as >>>> the core jar it depends on. >>>> >>>> The same approach would work for Math, but the user would have to >>>> download the additional dependencies somehow. >>> >>> the approach with exec:java is good enough imho, as >90% of the users >>> will have maven installed. >> >> But they won't necessarily have the Math source. >> >> On a whim I just tried creating a basic pom with only the dependencies. >> I added examples as another dependency. >> >> This works fine with exec:java from any directory provided only that >> the examples have been installed (or can be found from a repo) >> >> A minor disadvantage of exec:java is one has to use properties for the >> main class and arguments - the syntax is a bit awkward. > > the examples are also not published (yet), thus there is no way to run > the examples without downloading the source distribution (or checkout > the git repo).
Yes, but the code we are discussing is for the next release. I think it would make sense to include the compiled examples in the release as a separate jar. > Thomas > > --------------------------------------------------------------------- > 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
