[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-core-dev] Adding attributes in .classpath file
|
Good point, hadn't thought of that.
On Tue, 15 Feb 2005 21:51:19 +0100, Philippe P Mulet
<philippe_mulet@xxxxxxxxxx> wrote:
> 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
>
> _______________________________________________
> jdt-core-dev mailing list
> jdt-core-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/jdt-core-dev
>
