[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-core-dev] Adding attributes in .classpath file
|
Thanks to all for the feedback so far. So it looks like we're going to go
with a simple approach:
- extra attributes will be persisted along with existing attributes
- classpath entries will remain read only
- the values of attributes will be Strings (clients can serialize their
object up-front if needed)
To persist extra attributes we have 3 ways of doing it in XML. Assuming we
want to add 2 extra attributes ('javadoc' and 'vendor') to a lib classpath
entry:
1.
<classpathentry kind="lib" path="somelib.jar" javadoc="c:\\somelib\\doc"
vendor="Some company"/>
2.
<classpathentry kind="lib" path="somelib.jar">
<attributes javadoc="c:\\somelib\\doc" vendor="Some company"/>
</classpathentry>
3.
<classpathentry kind="lib" path="somelib.jar">
<attributes>
<attribute javadoc="c:\\somelib\\doc"/>
<attribute vendor="Some company"/>
</attributes>
</classpathentry>
Do you have any preferences ?
Jerome
Philippe P
Mulet/France/IBM@
IBMFR To
Sent by: jdt-core-dev@xxxxxxxxxxx
jdt-core-dev-admi cc
n@xxxxxxxxxxx
Subject
Re: [jdt-core-dev] Adding
02/09/2005 03:56 attributes in .classpath file
PM
Please respond to
jdt-core-dev
It was pretty clear in my mind that we would offer a javadoc attribute, but
wanted clients to be aware that we would not provide all elligible
attribute names.
As to retrofitting all existing attributes along the new story, I am not
convinced this is a good idea. It looks nice on the surface, but could
require to add more protection, and may prove inadequate to client usage;
i.e. you do not want to let clients omit the "path" attribute. Need to
tkink some more.
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 03:07 attributes in .classpath file
PM
Please respond to
jdt-core-dev
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: To
jdt-core-dev-admin@xxxxxxxxxx jdt-core-dev@xxxxxxxxxxx
g cc
Subject
02/09/2005 12:56 PM Re: [jdt-core-dev] Adding
attributes in .classpath file
Please respond to
jdt-core-dev@xxxxxxxxxxx
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
_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev
