Re: UI for setting up runtime classpath

Svata Dedic wrote:
> Svata Dedic wrote:
> 
>> 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 ?
> 
> 
> In fact - there's: you may add a resource to be used "for runtime", 
> which equals to all profiles in the whole project. Sadly, in version 
> 1.23 of the UI spec, there's no customizer or other UI where one could 
> review what resources were added to the default paths at the project 
> level. The corresponding customizers were removed from the project node 
> (see fig 1-3). The only supported action is to - remove the resource 
> entirely from the project. No UI for reviewing stuff.

the user can review classpaths on profiles and build targets -which is 
the place they'll be most interested in since that's where the action 
takes place.

> 
> In addition I am sure that professional developers will love the fact 
> that a junit library is added to the application launcher profiles, too 
> (when using "use in runtime" in the resource wizard), not only to 
> profiles that start classes from the testsuite (which is typically 
> produced by a special build target).

depends. in version 1.24 of the spec (up soon if not already) i've made 
a small clarification (it was always there but not clear). when adding a 
resource via the resources node the user will add the resource to one of 
several groups -everywhere, run time, compile time, boot classpath. the 
default is everywhere.

when adding a resource via a specific b.t. or profile the user will get 
a similar but more tuned choice -<bt or profile name>, compile/run time 
(depends on whether added from b.t. or profile respectively), 
everywhere. the default choice is the specific object (b.t. or profile).

this is a subtle difference but i think it will be useful. since the 
project is such a massive thing i think users are going to to find that 
they want to deal with build targets and profiles more often -and it 
makes sense bcs that is where results are gathered from.

> P.S.: still waiting for the motivation for Fig 47 from version 1.23 of 
> the UI spec and Fig 34,36 from version 1.22 of the UI spec.

fig 47 is pretty old and was the result of a conversation a long long 
time ago in a galaxy... hehe. sorry, a little humor. i don't remember 
the exact reason for having source roots there but i understand why they 
shouldn't be there so 1.24 has fixed the error.

the library portion of the spec is evolving. the decisions where based 
on my understanding at the time -often the requirements get tweaked a 
bit as we go so the spec falls on its face sometimes. speaking of 
libraries -and hopefully not face falling -i've once again made some 
updates. the library repository is basically the same though the 
property sheet is gone and an edit button that opens the same dialog as 
add has been added. i'm not sure recursive library definitions are 
necessary now -i understand that it may be useful but it's also very 
complicated so i'd rather leave that as a nice to have.

when selecting a library in the resource wiz. the user selects from the 
list and that's that. Jano and i chatted about the multi-select 
capability and it became clear to us that multi-selecting libraries was 
very close to defining libraries.

keep the feedback coming.

thanks,
cL

-- 

ui.netbeans.org
interaction designer
[email protected]