[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[jdt-debug-dev] RE: [platform-debug-dev] Sharing Launch Configs: revoked
|
Please
keep them. I was way psyched when I saw them in there...
If
there are any arguments/environment settings necessary, constant
import/export would be necessary, and this information needs to be versioned and
kept close to the code to run.
If
there are config changes between users, so beit. They'd have to change after
import/export anyway... Much easier to just run and see the args to change than
have to run, see there's no args, then import args, then change them, then run
again...
A
better solution, IMHO, would be to set up a more generic variable solution.
Rather than just having CLASSPATH variables, expand them to be "eclipse
environment variables". These could be used for CLASSPATHs as well as other
settings.
For
example, here many of our apps need
-DDATA_DIR=c:\h\data -DGQAPI_HOME=c:\eclipse\workspace\GQAPI
passed
to them. What would be more useful, would be to provide variables that could be
set, like
DATA_DIR=c:\h\data
GQAPI_HOME=${ECLIPSE_HOME}\workspace\GQAPI
then
allow the user to specify
-DDATA_DIR=${DATA_DIR} -DGQAPI_HOME=${GQAPI_HOME}
for
the program vm args.
This
would allow storage of shared program arguments that don't
change, leveraging general purpose variables that could be different per
user.
--
Scott
==============================================================
Scott
Stanchfield FGM,
Inc.
scott@xxxxxxx
Home Page: http://javadude.com
scott@xxxxxxxxxxxx
Lead author of "Effective VisualAge for Java,
Version
3"
http://javadude.com/evaj
VisualAge for Java Tips and
Tricks http://javadude.com/vaj
AWT & Swing FAQ Manager,
jGuru.com
Visit for Java
Enlightenment!
http://www.jguru.com
==============================================================
The debug team is proposing to remove the ability to share lanuch
configs in the workspace as first class resources. The reason for this is that
launch configs contain much information which is generally not portable from
user to user or from workstation to workstation. For example, classpaths,
bootpaths, JRE's etc., do not share well, as they are machine specific paths.
Instead, we intend to add a facility for exporting and importing launch
configurations.
We plan to move
ahead with this proposal unless there are any wild objections. For milestone
5, we will remove the ability to share a config (API change, but not
breaking), and for milestone 6 we will have the import/export support in
place.
Darin