[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-core-dev] Adding attributes in .classpath file
|
Or even allow names with space in them...
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 09:44 attributes in .classpath file
PM
Please respond to
jdt-core-dev
Better, really--with my approach, you can simply leave the names
completely unspecified if you want, and push the logic of validating
the attributes down to whatever code reads them. Or, if you want to
limit it to a specific set of strings, you can do that too.
On Tue, 15 Feb 2005 18:24:38 +0100, Jerome Lanneluc
<jerome_lanneluc@xxxxxxxxxx> wrote:
> 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
>
> _______________________________________________
> 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
