Re: ClassPath: Explanation requested

Hi all,
    I agree with Svata, that the current location of ClassPath 
customizer is not
very obvious for user. Nearly none (if any) of UI study participants has
even touched the Compiled Classes node or realized the Resources<->ClassPath
relation.
What I think is that for projects with Java nature, the ClassPath customizer
should go back to the Project customizer when it was before.
As far as I remember it was removed because of "big amunt" of tabs in the
project customizer, but this can be solved in different way (e.g. Single 
CP tab,
with combo box switching the customizers).

Tomas

Svata Dedic wrote:

> Hello, group,
>
> as a background for the recent classpath-related discussion, I would
> like to request that reasons for removing classpath-related tabs from
> the Project node between rev. 1.23 and 1.24 are clearly explained at 
> length.
>
> Please note, that at least from rev. 1.11 (9 Dec 2002), the "Managing
> ClassPath" section said that there are classpath controls on the
> Projects node, but ASCII art for the Projects node did not show any.
> The Managing ClassPath section is consistent with what was posted on the
> mailing list: message dated 12 Dec 2002 ("Java UI Spec updates") says,
> "2. i've clarified that there really isn't a classpath customizer as a
> standalone thing. it's used in three other customizers and the spec now
> says that" -- so I assume the ASCII art was not updated at that time.
>
> As Tim's message from 3 Mar 2003 indicates, there were customizers for
> Classpath embedded into the Project's node customizer, according to that
> paragraph.
>
> I searched through the mailing list, and was able to find this (31 Mar
> 2003) in Chris' answer to my and Tim's messages:
> "as Svata said, this is a bug. there will not be a classpath customizer
> on the project node itself [...]"
>
> This response misinterpreted words I wrote and put other ones in my
> mouth. *I* did not say that "Classpath" and "Bootclasspath" tabs on
> Project node are relict. I said that:
> "... if you are talking about "Customize Classpath" action on the
> Project's context menu, then it is probably a relict [...] All paths
> should be accessible from the project customizer.".
> Note that there was "Customize..." and "Customize Classpath..." action
> (both of them) on the Project node at that time.
>
> It was my mistake not reacting on such obvious error in appropriately
> short time.
>
> In rev. 1.11 - 1.23 (2 Apr 2003), the section "Managing Classpath" said:
> "The Classpath customizer tabs show up as a part of these three
> customizers: project customizer, compiled classes Build Target
> customizer..."
>
> In rev. 1.24 (10 Apr 2003), it says: "The Classpath customizer tabs show
> up as a part of the compiled classes Build Target customizer, and
> execution/debug Profile".
>
> In the current version of project branch, customizers are gone from the
> Project node, precisely according the UI spec change.
>
> Chri's explanation continued (see below); it can be easily proved 
> misguided and not paying attention to implications as it is shown 
> below the quotation. In addition, it - as seems usual - did not go to 
> enough details about how the UI replacement will look like and how it 
> will interact with the rest of the project.
>
> My questions:
> - What was the primary motivation for removing *both* ways how to 
> customize Classpath and view on the project level ?
> - Given the implications for the UI implementation (see below for 
> analysis) developers should be consulted about impl feasibility. They 
> were not. Why ?
> - How is it possible to replace a control present in the UI spec 
> (classpath tabs with the "usage" UI on resource customizer), without 
> providing a specification for the replacement ?
>
> Note that since UI spec and relevant code actually changed according 
> to the posted message, it was not no longer a proposal, but a decision.
>
> Chris, you are the author of the change, please answer the questions 
> above.
>
> ---------%<----- Comments to the little explanation note -----%<--------
>
> <quote>
> "the project classpath is made up of the contents of the resources node
> and the specified rolls of each of the resources present there. to
> change where/how a resource is used one would use either the resource
> node customizer or individual resource customizers."
> </quote>
>
> A resource may be used at multiple places (e.g. at project level, at a
> build target or in several build targets) or for multiple purposes (a
> classpath is not an exclusive owner of a resource, so it can be present
> on several of them).
> UI that says "where Foo.jar is used" may be helpful for tracking
> configuration bugs, but is very confusing for the configuration itself,
> since:
> - the user does not see the "whole picture" (entire classpath)
> - the UI does not correspond to the "classpath" concept, which is an
> ordered list
> - such UI does not handle order of resources in that particular usage
> path (specific path type on specific place - project, b.t.)
>
> In addition, it would require an additional code contract so that all
> project artifacts that could potentially accept the resource can tell
> that and could specify the supported usages (classpath, bootclasspath),
> and that all artifacts which use resources must register and manifest
> which resources and how they do currently use.
>
> Of course that it could be hacked in _specifically_ for Java Classes
> resource, Compiled Classes-type build target; and then for JarPackager,
> and other officially supported modules.
> However some resource customizers (the hacked ones) would contain "Where
> am I used and how" information and some (the other ones) would not. If
> some module decided to process resources, it could not manifest that
> information on the resource's customizer without such a contract (or a
> hack) => incomplete  information would be provided with inconsistent UI.
>
> Since we do not have such code contract in neither Java or Projects, I
> have to assume that the design decision was made without consulting
> developers about possibilities.
>
> -Svata
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>