On 01/06/2015 10:08 PM, Gilles wrote: > On Tue, 06 Jan 2015 20:41:26 +0100, Thomas Neidhart wrote: >> On 01/06/2015 07:28 PM, Gilles wrote: >>> On Tue, 06 Jan 2015 17:49:35 +0100, Thomas Neidhart wrote: >>>> On 01/06/2015 12:58 PM, Gilles wrote: >>>>> On Tue, 06 Jan 2015 08:51:32 +0100, Thomas Neidhart wrote: >>>>>> On 01/05/2015 11:58 PM, Gilles wrote: >>>>>>> On Mon, 5 Jan 2015 23:48:43 +0100, Bernd Eckenfels wrote: >>>>>>>> Am Mon, 05 Jan 2015 23:35:49 +0100 >>>>>>>> schrieb Gilles <gil...@harfang.homelinux.org>: >>>>>>>> >>>>>>>>> Which docs? >>>>>>>>> I didn't intend to move the "userguide" document; only the Java >>>>>>>>> examples currently under "src/userguide/java" would be moved to >>>>>>>>> "src/main" >>>>>>>> >>>>>>>> I wont mention multiple modules (also this might be a case where it >>>>>>>> makes sense, especially if you want to create a dedicated >>>>>>>> example jar >>>>>>>> file with its own set of dependencies and as it might avoid calling >>>>>>>> ant scripts for it), but I would keep the source separated and >>>>>>>> rather >>>>>>>> add an additional source directory (with the buildhelper). >>>>>>>> >>>>>>>> <plugin> >>>>>>>> <groupId>org.codehaus.mojo</groupId> >>>>>>>> <artifactId>build-helper-maven-plugin</artifactId> >>>>>>>> <executions> >>>>>>>> <execution> >>>>>>>> <phase>initialize</phase> >>>>>>>> <goals><goal>add-source</goal></goals> >>>>>>>> <configuration> >>>>>>>> <sources> >>>>>>>> <source>src/userguide/java</source> >>>>>>>> </sources> >>>>>>>> </configuration> >>>>>>>> </execution> >>>>>>>> </executions> >>>>>>>> </plugin> >>>>>>>> >>>>>>>> NB: this will produce classes on target/classes so you need to >>>>>>>> exclude >>>>>>>> them in the JAR. >>>>>>>> >>>>>>> >>>>>>> Thanks. >>>>>>> I find it cleaner to keep the examples separated from the "main" >>>>>>> code; >>>>>>> so if this does the trick, I'd prefer it that way. >>>>>>> We'd nevertheless need that separate JAR that contains the examples, >>>>>>> and a mean to select which of the examples must be run, as proposed >>>>>>> by Sebb. >>>>>> >>>>>> The examples can not be added to the main code as there is an >>>>>> additional >>>>>> dependency (xchart) that we do not want to add to commons-math in >>>>>> general. >>>>> >>>>> It was never intended to ship the examples as part of the CM >>>>> library. [There are provisions in the "pom.xml" to prevent it (IIUC).] >>>>> IIUC, Sebb proposed that the source code be moved solely for >>>>> the purpose that maven would compile it with the default config. >>>> >>>> I was not talking about packaging. >>>> >>>>> IIUC, with Bernd's proposal, this move is thus not necessary. >>>> >>>> Neither will work, unless you add the relevant dependencies to the main >>>> pom.xml which we certainly do not want. >>>> >>>> I just wanted to point this out before anybody is doing a change. >>> >>> As long as the CM library have no dependencies, is it a problem >>> that non-packaged (or separately packaged) code does have dependencies? >>> >>> Or is it that it will be more complicated to ensure that there is no >>> such dependencies for CM itself once the "pom" file refers to them? >>> >>> Or is it that really the "pom" file is not allowed to contain such >>> references? >> >> The userguide has dependencies and in order to compile it as part of the >> "normal" commons-math codebase, e.g. using mvn compile, these >> dependencies have to be specified in the pom.xml. Afaik the only way to >> exclude these dependencies would be to use the scope "provided", but it >> is certainly a solution I would not suggest as it wrongly implies that >> commons-math has a reference to them, while in fact it hasn't, only the >> userguide part. >> >> Normally, you solve this situations by using a multi-module setup, as >> said below. >> >>>> The best option would certainly be a multi-module project, with the >>>> examples / userguide a separate module, but this would require some >>>> changes and a few months ago when we started doing this there was no >>>> consensus about it. >>>> >>>>> The original issue was: How do we run the examples? >>>>> Phil proposed an "ant" script, which I would have happily produced. >>>>> But then if "maven" can do it (with the suggested changes to the >>>>> "pom.xml"), it's IMO simpler to not have to run a different program. >>>> >>>> Right now, you can only run them directly in eclipse by adding a >>>> project >>>> for them, but we could easily do the same as NET does. >>> >>> The original request is: How do we run the examples? >>> To be more specific: how to run a specific example from the command >>> line? >>> >>> I'm perfectly fine with only modifying the "pom.xml" located in >>> src/userguide >>> >>> Would that work? >>> Do you readily know what needs to be added? >> >> yes, but as sebb suggested, the easiest solution is certainly as follows: >> >> * create a commons-math-userguide.jar package using mvn package > > Thus, copying the relevant from the "main" pom (that creates the > "tools" JAR) over to the pom in the userguide directory? > >> * copy this jar together with necessary dependencies (xchart, >> commons-math) into a directory >> * run java -cp . ExampleXXX parameters > > That would be good enough, I guess. > >> The whole thing could be further simplified by creating a userguide jar >> that already contains all dependencies in one jar. >> >> There could even be scripts in the userguide that can be executed by a >> user for this purpose. > > That's what I meant, if "maven" can be considered as a script.
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 Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
