Bug 206129

(In reply to comment #0)
> 4. support for full path

Probably implied by #1. Note that due to requirement #1 it is not safe to switch existing absolute-only attributes to default-relative; they can only be switched to default-absolute. Otherwise as noted in bug #204174 there are potential ambiguities even assuming a compliant 269 environment, and in buggy JDK 6 javac (with searchClasspath=true) as far as I know it would be impossible to even guess which style is wanted.

> 5. nice to have: code completion for free

Interesting thought. I _think_ this would be straightforward. (Could not be completely for free - processor would need to enable it for a particular attribute - but the bulk of the implementation could be shared.)

> If the signature of the main utility method could be:
> 
> public LayerBuilder.File LayerBuilder.File.resourceValue(
>   String path, boolean preferRelative
> );

I guess I do not follow what such a method would do.

We already have validateResource and absolutizeResource which suffice for default-relative and absolute-only attributes. One more (Element,String)->String method would suffice to handle also default-absolute attributes in an analogous manner.

Note that it is important for validateResource to remain independent of the construction of the absolute path, since some processors just want to open the FileObject for its contents (or get its URI perhaps), whereas others will subsequently work with the String absolute resource path and merely want to ensure that it exists.

> > 5. nice to have: code completion for free
> 
> Interesting thought. I _think_ this would be straightforward. (Could not be
> completely for free - processor would need to enable it for a particular
> attribute - but the bulk of the implementation could be shared.)

More comfortable it would be to have @ResourceOnClassPath (meta)annotation and annotate the annotation's value with it. That is almost for free.

> > public LayerBuilder.File LayerBuilder.File.resourceValue(
> >   String path, boolean preferRelative
> > );
> 
> I guess I do not follow what such a method would do.

Because I mispelled its parameters. Another try:

public LayerBuilder.File LayerBuilder.File.resourcevalue(
  String attrName, String path, boolean preferRelative
)

would generate <attr name="${attrName}" stringvalue="${(full)path}"/>. This does not need to cover 100% of usecases, but it should be good enough for 90%. Yes, all existing annotations would have to say 'false' to preferRelative. New annotations might choose 'true' inspite it would only work reliably on JDK7.

(In reply to comment #2)
> @ResourceOnClassPath (meta)annotation

Too magical, and would interact poorly with processors wishing to implement getCompletions on other attributes. Better to provide something like

enum Mode {ABSOLUTE_ONLY, DEFAULT_ABSOLUTE, DEFAULT_RELATIVE}
Iterable<? extends Completion> resourceValueCompletions(Element element, Mode mode, boolean searchClasspath, String userText, String... fileExtensions);

that could be used if desired, possibly in combination with other things.

> public LayerBuilder.File LayerBuilder.File.resourcevalue(
>   String attrName, String path, boolean preferRelative
> )
> 
> would generate <attr name="${attrName}" stringvalue="${(full)path}"/>.

This tries to do too much and would be unusable for certain purposes. Existing methods (plus the new proposed (Element,String)->String method) accomplish the same thing in obvious combination but retain flexibility.

> all existing annotations would have to say 'false' to preferRelative. New
> annotations might choose 'true' [though] it would only work reliably on JDK7.

It is fine to _introduce_ an annotation attribute in default-relative mode, even when supporting JDK 6 (in fact several attributes in @TemplateRegistration do just that) - the presence or absence of initial slash unambiguously distinguishes relative from absolute paths. What is not compatible is _changing_ an attribute which is currently absolute-only to default-relative.

Retrospectively, perhaps all resource attributes should have been defined as default-relative to begin with, but it is too late for that now. An alternate solution to the issue would be to mark existing iconBase attributes (or any other absolute-only resource attributes) as @Deprecated and introduce new default-relative attributes ("icon"?) in their place. This would be somewhat disruptive though the change could be ameliorated with editor hints.

Sorry, did not get to this in time to file a review prior to 7.2 feature freeze. If this is, or is blocking, a DEFECT then let me know.

Who cares?