Re: UI for setting up runtime classpath

Vitezslav Stejskal wrote:

> 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?


I agree with this for NB 4.0. This is the right balance between 
flexibility for power users and simplicity for beginners.

There are still some minor problems, which I don't think need to be 
addressed for 4.0:

- The Runtime classpath is irrelevant for projects which deploy the 
application in the container (web server, app server) - in this case the 
container decides about the classpath. So the Runtime classpath should 
not be present in the project-wide settings, only in the "execute main 
class" exec. profile (this profile will not be in enterprise projects by 
default, the user would have to create it manually).

- I think the idea of multi-level settings and overriding settings as 
such is unintuitive, especially if we are talking about a list of values 
(not a single value). I think if the UI is designed properly, even 
single-level settings can be easy and convenient to use. And anyhow, 
settings inheritance will not help you if the IDE forces you to break up 
your work into a zillion of small projects, and settings can not be 
inherited across projects.

Petr


> -vita
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>