Menu
▾
▴
Re: [Repast-developer] PGM files in the demo jars but not in the repast.jar
|
From: Thomas R. H. <th...@sr...> - 2002-12-26 18:02:47
|
I agree. This seems like a fairly unobtrusive change. Both Nick and I would like to do a massive package restructuring at some point, also. Probably not until 3.0, though. I'll look into making these changes. -Tom On Thu, 2002-12-26 at 11:45, Mark R. Diggory wrote: > Just a suggestion, but wouldn't it be better to consolidate the demos > into their own directory separate of the "sim" directory? > > uchicago.src.sim.engine > uchicago.src.sim... > > uchicago.src.demo.hexaBugs > uchicago.src.demo... > > then you wouldn't need complex "exclude" ant rules that needed to be > updated whenever a new demo is added. > > In fact, if you look at distributions like jakarta commons, you find > that there is an even greater separation between demos/tests and the > core package similar to the following: > > / = cvs directory > . = java package > > /repast/src/uchicago.src.sim.engine > /repast/src/uchicago.src.sim... > /repast/build.xml > > /repast/demo/HeatBugs/src/uchicago.src.demo.heatBugs > /repast/demo/HeatBugs/build.xml > > /repast/demo/HexaBugs/src/uchicago.src.demo.hexaBugs > /repast/demo/HexaBugs/build.xml > /repast/demo/build.xml > > by dividing the core and demos into separate cvs directories with > separate build scripts, you can inherently enforce the rule that the > core build success is never be dependent on any of the demo build. Using > "fail on error/don't fail on error" switches in ant makes it so a build > failure in a demo never breaks the entire build of the core. > > You also get the benifit that separate build.xml scripts for each demo > can be kept small. In the end it's kindof like a "make" environment > where build.xml scripts in lower directories get called by those in > higher directories. This way its always easy to create new demos and > include them with thier own build.xml files. The "core" build files > never really would have to be modified to add a demo in the future. > > 2cents, > Mark > > Thomas R. Howe wrote: > > Yeah, none of the demos are supposed to be included in the repast.jar. > > This is what happened: > > I wrote these two demos. Nick usually builds the distribution from an > > ant build.xml file. The build file excludes the demo directories from > > the output, but these two weren't added to the build file, so they ended > > up getting added to repast.jar. > > > > I'll go ahead and make the changes in the build.xml file, so that these > > won't be included in the repast.jar of future releases. > > > > -Tom > > > > > > On Wed, 2002-12-25 at 18:36, Mark R. Diggory wrote: > > > >>Actually, It looks like its only hexaBugs and gisModel that are > >>replicated inside repast.jar. > >> > >> > >>Mark R. Diggory wrote: > >> > >>>Nick and Repast Team, > >>> > >>>I was playing around in the 2.0 repast jar and I came to a little mess > >>>you might want to know about. > >>> > >>>I recognize that in the available binary distribution of repast that the > >>> individual demo examples each are contained in their own jars (and > >>>that some of these jars also contain the "pgm" files required by those > >>>simulations, which get loaded as resources off the classloader). > >>> > >>>I was also noticing that the "repast.jar" also contains these classes > >>>for all the demos as well. Is this a replication of compiled classes > >>>that could be done away with? > >>> > >>>It is the case that the repast.jar, while having the classes for the > >>>examples, does not contain the non-class files, like "pgm" files > >>>required by the demo to execute properly, these files appear to be > >>>loaded as resources in the same namespace as each demo package so these > >>>demos break when you try to run them straight out of repast.jar. > >>> > >>>I might recommend either: > >>>1.) removing the demo classes from the repast.jar or > >>>2.) including the support files for each demo into the repast.jar. > >>> > >>>As its probibly the case that the number of demos will grow over time. I > >>>would suggest (1) just removing the demos from the repast.jar as a more > >>>logical solution. > >>> > >>>Happy Holidays, > >>>Mark > >>> > >>> > >>> > >>>------------------------------------------------------- > >>>This sf.net email is sponsored by:ThinkGeek > >>>Welcome to geek heaven. > >>>http://thinkgeek.com/sf > >>>_______________________________________________ > >>>Repast-developer mailing list > >>>Rep...@li... > >>>https://lists.sourceforge.net/lists/listinfo/repast-developer > >> > >> > >> > >>------------------------------------------------------- > >>This sf.net email is sponsored by:ThinkGeek > >>Welcome to geek heaven. > >>http://thinkgeek.com/sf > >>_______________________________________________ > >>Repast-developer mailing list > >>Rep...@li... > >>https://lists.sourceforge.net/lists/listinfo/repast-developer > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Repast-developer mailing list > Rep...@li... > https://lists.sourceforge.net/lists/listinfo/repast-developer -- Tom Howe Social Science Research Computing University of Chicago |
