Re: UI for setting up runtime classpath

cL wrote:
> customizer section has fallen out of date and is mis-leading. the intent 
> now is that no where are there classpath tabs called runtime or 
> [implicitly] compile time. just Classpath, and Boot Classpath. whether 
> it is run time or compile time is deducible by on which object you're 
> looking at it from (b.t. or profile). i think that is consistent with 
> what you're asking for.
> 
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.

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.
Sadly, there's no other point in the UI that would represent that exact 
set of sources.

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 ? Then do the 
same when the user chooses a particular implementation of other API for 
run-time ?
This is something to automate, not leaving the user to wrestle with it.

-Svata