[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-core-dev] Adding attributes in .classpath file
|
What about
<classpathentry kind="lib" path="somelib.jar">
<attributes>
<attribute key="javadoc" value="c:\\somelib\\doc"/>
<attribute key="vendor" value="Some company"/>
</attributes>
</classpathentry>
? Isn't that the most extensible format?
On Fri, 11 Feb 2005 17:21:30 +0100, Jerome Lanneluc
<jerome_lanneluc@xxxxxxxxxx> wrote:
> 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
>
> _______________________________________________
> jdt-core-dev mailing list
> jdt-core-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/jdt-core-dev
>
