Re: [jdt-core-dev] Adding attributes in .classpath file

[Martin Aeschlimann <martin_aeschlimann@xxxxxxxxxx>]

About the Javadoc locations:
I was my understanding that Javadoc
location would be one of the build-in jdt.core services, not a client attribute.
It would be the jdt.core plugin defining
the attribute id and defining that it is an URL. A problem of the current
implementation of the Javadoc locations is that clients need to know jdt.ui
to use Javadoc locations even if they are non-UI plugins. We think the
concept of having Javadoc locations for libraries is proven enough (in
since 2.0) and would like to promote this to be a service of jdt.core.
It is true that jdt.core currently doesn't use Javadoc locations anywhere,
but maybe you will at some point, e.g. to show a type skeleton generated
from html if source attachment is not available. 

I think it would be nice if the existing
attributes would seamlessly fit in with the new story. Of course existing
API's should not be broken, but having getAttribute returning all classpath
attributes would be elegant and reflect how class path attributes are shown
in the build path project properties (as children of classpath entries).
It would also prove that the attributes are good enough to also used by
the compiler
That would of course force us to think
about how attributes which are of types like 'IPath[]' are to be serialized/deserialized.
I must admit that I forgot about that problem.
Using String is definitely better. An
idea is to spec the attributes like:
   'Attributes of kind 'excluding'
are valid for source entries and are represented as a list of path separated
by '|'
This is also how we do it for preference
store values.

The question is of course if deserializeing
would be a performance problem for the compiler.

Martin

Philippe P Mulet/France/IBM@IBMFR
Sent by: jdt-core-dev-admin@xxxxxxxxxxx

02/09/2005 12:56 PM

Please respond to
jdt-core-dev@xxxxxxxxxxx

To	jdt-core-dev@xxxxxxxxxxx
cc
Subject	Re: [jdt-core-dev] Adding attributes in .classpath file

I like this idea; though would suggest naming it:
IClasspathAttribute.
I think we should keep them simple and persistable. Therefore, the value
should be a string.
Also providing good names for these is likely going to be troublesome.
I
can foresee JDT/Core requiring to add new API for common names; e.g.
javadoc attachment.
I am not thinking of retrofitting our existing custom attributes into these
(source attachment, exclusion filters, ...), these would remain as is.

One way to think of these attributes is to denote things which are relevant
to clients, but not to JDT/Core. This is why offering API for common names
doesn't quite make sense. We need to be careful there; i.e. if we provide
"javadoc" attribute name, how is it that we do not leverage it
everywhere
in our services ?



                    
                     
                     
          
             Martin      
                     
                     
     
             Aeschlimann/Zuric    
                     
                  
             h/IBM@IBMCH      
                     
                   To
             Sent by:      
           jdt-core-dev@xxxxxxxxxxx  
         
             jdt-core-dev-admi    
                     
               cc 
             n@xxxxxxxxxxx    
                     
                     
                    
                     
                     
  Subject 
                    
                  Re: [jdt-core-dev]
Adding           
             02/09/2005 12:30    
     attributes in .classpath file      
             PM        
                     
                     
       
                    
                     
                     
          
                    
                     
                     
          
             Please respond to    
                     
                  
               jdt-core-dev    
                     
                     
                    
                     
                     
          
                    
                     
                     
          





Keeping CPentries read-only makes sense to me. I'm not a fan of the Map
though. This is not so common in Eclipse APIs.
I would suggest to introduce a new IClasspathEntryAttribute type:

  IClasspathEntryAttribute
      getName() : String
      getValue(): Object

  JavaCore.newXY(IPath path, boolean isExported, IClasspathEntryAttribute[]
attributes)

IClasspathEntryAttributes can be created using factory methods on JavaCore

  JavaCore.newSourceAttachmentPathAttribute(IPath sourceAttachPath)
  JavaCore.newJavadocLocationAttribute(URL javadocLocation)
  JavaCore.newExlusionFilterAttribute(IPath[] explusionPath)
  ...

Custom attributes are created with:

  JavaCore.newCustomAttribute(String name, Object value, boolean
isPersisted)

I added the idea of persistent and not persistent custom attributes here.
Only persistent attibutes would go the .classpath file.
This is just an idea, there isn't a concrete use case for that yet.

  IClasspathEntry
      getAttributes() : IClasspathEntryAttribute[]

Advantage of this is:
    - it makes it clear that CPentries are read-only
    - Factories for attributes make sure that (at least the built-in)
attribute values are of correct type

Martin


                    
                     
                     
          
 Philippe P                  
                     
                     
 
 Mulet/France/IBM@IBMFR              
                     
               
 Sent by:                  
                     
                     
To 
 jdt-core-dev-admin@xxxxxxxxxx            
jdt-core-dev@xxxxxxxxxxx        
 g                    
                     
                     
     cc 
                    
                     
                     
          
                    
                     
                     
  Subject 
 02/08/2005 02:57 PM                
      Re: [jdt-core-dev] Adding       
                    
                     
attributes in .classpath file   
                    
                     
                     
          
       Please respond to          
                     
                  
    jdt-core-dev@xxxxxxxxxxx          
                     
              
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          





Remember that CPentries are read-only objects. So this would vote against
setAttribute methods.





            Darin Wright
            <Darin_Wright@ca.
            ibm.com>      
                     
                     
To
            Sent by:      
           jdt-core-dev@xxxxxxxxxxx
            jdt-core-dev-admi    
                     
               cc
            n@xxxxxxxxxxx
                    
                     
                     
 Subject
                    
                 Re: [jdt-core-dev]
Adding
            02/08/2005 02:49    
     attributes in .classpath file
            PM


            Please respond to
              jdt-core-dev






The attribtues need to be mutable after creation of the classpath entry.
So, an optional map on creation is fine, but we would still need
set/getAttribute.

Darin




Jerome Lanneluc <jerome_lanneluc@xxxxxxxxxx>
Sent by: jdt-core-dev-admin@xxxxxxxxxxx
02/07/2005 06:30 AM
Please respond to
jdt-core-dev


To
jdt-core-dev@xxxxxxxxxxx
cc

Subject
[jdt-core-dev] Adding attributes in .classpath file






Bug 22969 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=22969) asks for
storing the javadoc attribute in the .classpath file. We want to support
this and maybe other attributes. So we're asking for your feedback on the
best way to add a new API for this.

Currently the way you create a new IClasspathEntry is using the
JavaCore#new*Entry(*) methods. One way to support the new attributes would
be to pass an extra argument of type Map. The key in the Map would be the
name of the extra attribute, and the value would be a String representing
the value of this attribute.

Has anyone a better idea for this API ?

Thanks,
Jerome

_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev


_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev


_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev


_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev