[kepler-dev] configs/ directory
ludaesch at sdsc.edu
Mon Apr 5 19:15:04 PDT 2004
Since I'm not "down in the trenches" (and least not in all ones), the
following suggestions should be taken with a grain of salt.
First, this looks like a clean proposal to me. But as I said, I'm not
down in the trenches, so we need to hear back from the main Kepler
developers. Don't know whether an actual vote is necessary (my
understanding is that it's done only rarely), but maybe it would help.
As for the timetable of the suggested changes: I think given that
there may be many people who are affected, we could do these changes
incrementally, one directory at a time or so. Maybe after discussing
with the other KEpler developers Ilkay and you could do this
Note that there is a kepler irc channel were folks meet and chat about
these things with quick turnaround times (the irc info should be on
the Kepler site -- and if not, should go there).
just my $0.02
>>>>> "XX" == Xiaowen Xin <xin2 at llnl.gov> writes:
XX> Hi Everyone,
XX> Following up on a couple of my emails from last week, I would like to
XX> propose that Kepler creates a separate configuration profile rather than
XX> overwriting Ptolemy II's files for that effect.
XX> Ptolemy II uses the "full" configuration by default, and Kepler deletes
XX> a few files referenced by that configuration from the Ptolemy II
XX> directory, and replaces them with its own.
XX> Rather than doing that, it would be much cleaner to create a separate
XX> profile for Kepler, and put all its changes in there. This way, Kepler
XX> doesn't need to touch Ptolemy II's installation.
XX> More specifically, I would like to create this directory hierarchy:
XX> where Kepler, and all its member groups can have its own configuration
XX> A user can run the kepler profile by doing:
XX> java -classpath "..." ptolemy.vergil.VergilApplication -kepler
XX> while a user who's more interested in running only geon can do:
XX> java -classpath "..." ptolemy.vergil.VergilApplication -geon
XX> This mechanism is already built into Ptolemy II, so it would be much
XX> cleaner for us to take advantage of it.
XX> The major benefits of this is that we wouldn't have to muck around in
XX> Ptolemy II's installation any more. Also we can organize our
XX> configuration files more cleanly.
XX> The only downside is that it would be a change that would affect all
XX> Kepler developers.
XX> I'm not sure whether I should propse a vote on this. Ideally, I'd like
XX> to go ahead and implement this by the end of this week, if there are no
XX> objections. What do you all think?
XX> kepler-dev mailing list
XX> kepler-dev at ecoinformatics.org
More information about the Kepler-dev