ClassPath: Explanation requested

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