Re: UI for setting up runtime classpath

Hi Svato,

Svata Dedic wrote:

> To answer Peter's question:
>
> The "runtime" tab was there for functional reasons: when a profile is 
> established or main class selected, it is not sufficient. The 
> appropriate classpath must be somehow guessed and pre-configured for 
> the user (otherwise the profile is simply useless).
> It is done by:
> - collecting java-related items from build targets in the depedency 
> tree of the build target which should be built prior to execution.
> - digging the classpath out of the build target which builds the 
> "main" class.

Yes, this is ok, the profile needs to collect 'products' of build 
targets and put them on runtime classpath otherwise the app can't execute.

>
> The "runtime" flavour of ClassPath was there to provide a common point 
> to define an environment for all classes compiled by the build target, 
> since it is typically the same as the compile classpath, possibly + 
> some entries, which are also typically specific for the compilation unit. 

Right, this is correct requirement.

>
> Sadly, there's no other point in the UI that would represent that 
> exact set of sources.

IMO the project should have the same classpath customizer as it is used 
on other objects which inherit the classpath from the project and add 
their own pieces. It seems to me pretty natural to use the same UI for 
customizing the same setting on all places which contribute to the 
inheritance hierarchy of this setting. In this sense the classpath is 
like any other setting and should be handled similar.

>
> The fact that there's no central UI to manipulate with classpath items 
> common for all execution profiles at once in the UI spec seems somehow 
> irrelevant, isn't it ?
> So it seems that you want to call "well designed interaction" when the 
> user needs to add xerces to the app's runtime and have to adjust the 
> classpath on *all 5 profiles* to get them working again ? 

No, this definitely isn't the 'well designed interaction'. Your 
requirement of having the way how user can influence the 'inherited' 
part of runtime classpath is perfectly valid. On the other hand the 
Runtime Classpath on the CCBT seems a bit weird. I would stick with the 
two-level settings hierarchies we decided some time ago and apply it for 
the classpath as well. So, what about following proposal:

a. define following project-wide classpath types: general, runtime, boot
b. inherit and redefine the general classpath on Compiled Classes BT
c. inherit and redefine the runtime and boot classpath on Exec/Debug 
Profiles
d. use the same classpath customizer for managing classpaths on all 
above objects (project, CCBT, profiles)

What do you and others think about this?
-vita