Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jdt-debug-dev] Milestone 6 plan


A tab group can do whatever it wants to set the default boot and class path...
* I am looking at the 20020423 integration build and I noticed that there is a launch configuration attribute that named ATTR_DEFAULT_CLASSPATH.  The javadoc on this field says that it should be a boolean value.  If the value is true then the classpath will be computed at runtime.  I was hoping that this attribute would allow the tab group to define what it wanted the default classpath to be.  Is there some other way to specify what the default classpath is?

There is no commitment to make the tabs public API at this point.
* So, other tab groups will not be able to use the Java tabs without breaking the rules?



Darin_Wright@xxxxxxx
Sent by: jdt-debug-dev-admin@xxxxxxxxxxx

04/24/2002 10:47 AM
Please respond to jdt-debug-dev

       
        To:        jdt-debug-dev@xxxxxxxxxxx
        cc:        
        Subject:        Re: [jdt-debug-dev] Milestone 6 plan



Classpath & bootpath:

*We are working out requirements with WSDD. A tab group can do whatever it wants to set the default boot and class path, but we are adding support to the VMInstalls to specify default bootpath and classpaths that the tabs can use (if desired). The tabs are then used to override/edit the default settings. We are also adding support for VMInstalls to have more than one library - that is, a class or system library may be split among several jars, rather than the traditional (single) "rt.jar".


Remote connection:

*The API to IVMConnector will be changing. Since different connetors accept different connection attributes/arguments, we are going to allow a Map of arguments to be passed to the connector. This map will reflect the "com.dun.jdi.connector.Connector" argument map format. A connector will be able to specify its default arguments in a Map (which will be displayed/edited in a tab), and the connector will be passed the argument map that the user has modified to perform the launch/connection.


Reorganize tabs:

* The java tabs are not API, and are not yet stabalized. We will be moving the JRE to its own tab, moving environment variables to its own tab, etc. As well, the way in which the attributes are specified will be changing. Rather than specifying class/boot path in terms of absolute paths, the user will specify in terms of projects, libraries, etc. This API is not yet finalized, but is intended to prompte launch config sharing. As well, a source lookup tab will be added. There is no commitment to make the tabs public API at this point.


Darin




Matt_Lavin@xxxxxxx
Sent by: jdt-debug-dev-admin@xxxxxxxxxxx

04/24/2002 08:58 AM
Please respond to jdt-debug-dev

       
       To:        jdt-debug-dev@xxxxxxxxxxx
       cc:        
       Subject:        [jdt-debug-dev] Milestone 6 plan




I have a couple of questions about the changes to be made for milestone 6.

Improved support for default classpath & bootpath (delegate to VM installs)
Would it be possible for the allow the default classpath and bootpath to be set by the TabGroup instead of the vm install?  If the java tab group delegates its responsibility for setting the defaults back to the vm install that is fine.  However, it would be nice if the tab group could set its own defaults.

Enhanced remote connection - support a dynamic set of launch arguments
What exactly does that mean?  What sort of launch arguements would be dynamic?

Re-organization of launch config tabs
Could somebody explain a little more about what this means.

Something that wasn't mentioned on the plan but I was expecting was to make the java launch tabs public.  I thought that somebody had mentioned that they would be moved to API some time.

"The Java tabs will be promoted to API, but they are not intended to be subclassed - only instantiated.  The classes will have public constructors, but all implementation will be considered internal and non-public. The reason for this is that the tabs are expected to change dramatically in the near term, as we receive user feedback. It is not possible to consider the tabs as stable API. Currently, the only inter-tab dependency is the notion of a "project" which is used to set default values (i.e. classpath). The tabs will use the launch configuration working copy mechanism to perform this communication. Creating a "java tab" framework is not something that we have time to do in the 2.0 release. "




Back to the top