[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-core-dev] Adding attributes in .classpath file
|
You're right. I first thought that we would not have to define attribute
names in advance. But if we decide to write a dtd for the .classpath file,
this would need to be specified. Your solution makes it easier to evolve
such dtd. Thanks for poiting this out.
Jerome
Aaron Davies
<aaron.davies@gma
il.com> To
Sent by: jdt-core-dev@xxxxxxxxxxx
jdt-core-dev-admi cc
n@xxxxxxxxxxx
Subject
Re: [jdt-core-dev] Adding
02/15/2005 05:51 attributes in .classpath file
PM
Please respond to
jdt-core-dev
Are we sure we know ahead of time all possible attributes we might
want to encode? If not, indirecting the name into an XML attribute
makes later extension much easier. Think about something like the
PList xml format.
On Tue, 15 Feb 2005 11:29:12 +0100, Jerome Lanneluc
<jerome_lanneluc@xxxxxxxxxx> wrote:
> I'm not sure to understand the value of this indirection for the
attribute
> name ...
>
> Aaron Davies
> <aaron.davies@gma
> il.com >
To
> Sent by: jdt-core-dev@xxxxxxxxxxx
> jdt-core-dev-admi
cc
> n@xxxxxxxxxxx
>
Subject
> Re: [jdt-core-dev] Adding
> 02/14/2005 09:14 attributes in .classpath file
> PM
>
> Please respond to
> jdt-core-dev
>
> 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
> >
> _______________________________________________
> 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
