Re: [equinox-dev] [api tooling] Re: Using component.xml as a starting po

[David M Williams <david_williams@xxxxxxxxxx>]

I think another reason to have component.xml
files is to use them as "the lowest common denominator". 
That would seem to allow a path for
Java 5 source code to use (custom) annotations to refine API definitions.
 
And, while there'd be some, in the lowest
parts of the platform (i.e. equinox :) that could never take advantage
of that, 
there'd be other Eclipse projects that
could use only annotations, if they are already assuming Java 5. 

Just an idea ... I'm not volunteering
to write the Processors. :)

Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

10/29/2007 08:04 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc	equinox-dev@xxxxxxxxxxx, equinox-dev-bounces@xxxxxxxxxxx
Subject	Re: [equinox-dev] [api tooling] Re: Using component.xml as a        starting        point

Without a non-javadoc based mechanism to describe
API (not necessarily
component.xml), how will you be reasoning about what the API is for a
compiled jar?

PaScaL

equinox-dev-bounces@xxxxxxxxxxx wrote on 10/29/2007 04:54:15 PM:

>
> We are getting close the chicken and egg problem here....
>
> When it's time for developers to start using the tooling, we want
to
> make it easy - so yes, it would be handy to have a tool that inserts
> javadoc tags based on existing component XMLs. I think the tags
> "replace" component.xml - so I don't think we should have
tooling to
> keep the two in synch. I would see this as a "one off" tool
to get
> started. For that reason, I don't think we would want to create
> markers as it would require "active" tooling to keep the
two in
> synch. As well, we'd have to have some mechanism for knowing if the
> "component.xml" should be considered as the "source"
for tag
> generation, or the "target" for caching existing tags. It
feels
> awkward to have duplicated information in the IDE - when the user
> can edit both. Would it be better to have a tool/action/wizard that
> processes the component XML and generates a report for issues
> (rather than makers)?
>
> Does anyone think that we should have tooling to maintain the
> "component.xml" files? I'd rather just use the javadoc tags
as the
> "source" of the information in the workspace. At build time,
we
> could also use source to generate that part of our API description.
>
> Darin
>
>

>
> Olivier Thomann/Ottawa/IBM
> 10/29/2007 02:17 PM
>
> To
>
> Darin Wright/Ottawa/IBM@IBMCA, Michael Rennie/Ottawa/IBM@IBMCA, Jeff
> McAffer/Ottawa/IBM@IBMCA
>
> cc
>
> Subject
>
> Using component.xml as a starting point
>
>
>
> Hi,
>
> We should use the existing component.xml file for each plugin in the
> SDK to "tag" the corresponding types with the appropriate
javadoc tag.
> So the tool would take the component.xml and check all the API types
> inside the workspace.
> The existing text that describes the API usage would be replaced
> with the corresponding tag and for the API type where the existing
> text is not an exact match, the tag would be added and a marker
> created to remember that this file should be double-checked.
> The "new" API types that have been added since the component.xml
was
> created should also be marked to be double-checked.
>
> This could allow us to get a "good" baseline.
>
> What do you think?
>
> Olivier _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev