[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[pde-dev] [api tools] Extensibility proposals and questions
|
Hi,
first of all, if
there is a mailing list better suited for PDE Incubator API Tools,
please point me there.
I see some potential
to introduce extensibility to the api tools:
1.
SourceContainer
What classes have
to be taken into account?
Currently this is done for bundles, jars and directories
by scanning the provided URL for .class files. And then filtering out what
is not considered
API.
For bundles using PDE code and thus relying on plugin
metadata (Exported-Packages), for jars and directories .internal in the
package name is used to determine non-API.
Just for PDE use cases I would see more than one Container
implementation, e.g. target (analyse a full installation), updatesite (it
may be neccessary to analyse jars contained in jars) and
bundle.
Other technologies may have other metadata to describe api
elements.
I would propose
to establish an extension point to provide SourceContainers for a type that
can be set in the control.xml like
<container
type="type-id" location="location-of-sources"/>. Additionally I would
allow container elements to have arbitrary child nodes so one can add type
specific data.
Another question
would be what else has to be considered API?
Shouldn't a
plugin api report contain extension points as api
elements?
Other
technologies may have other non-java elements to be considered
api.
To allow
technology specific non-java api elements
one possibility may be to allow SourceContainers to provide
special ApiReaders that produce IApiElements, the default one being a java
class analyser. Of course one would also have to provide compare and report
handling for those elements.
2. Api
definition
What is Api
breakage?
For example if an
interface is not designed to be implemented by clients, addition of methods is
no breakage.
Such an extension
would have to plug into both IApiElement creation and comparison. For example
one might define an annotation @DoNotImplement and annotate an interface with
it and add a method in the next version. During IApiElement creation this
additional information has to be stored, during comparison the Diff found by
the Comparator can be deleted before being passed to the
reporter.
What do you think?
Any comments are welcome.
Why is there a
ClassFileReader implemented in the api tools? Why not use the one in
JDT?
As far as a I
understood the DevGuide the reason is performance. Is the special parser
significantly faster than the JDT parser?
To allow extenders
to analyse additional data (like annotations) more information may be neccessary
than currently provided by the specialized parser.
Kind
regards,
Jan
Jan
Lohre
Developer
SAP
AG
Dietmar-Hopp-Allee
69190 Walldorf
Germany
T +49 6227 7
43017
F +49 6227
78-43856
Sitz der
Gesellschaft/Registered Office: Walldorf, Germany
Vorstand/SAP Executive
Board:
Henning
Kagermann(Sprecher/CEO), Shai Agassi, Léo Apotheker, Werner Brandt, Claus
Heinrich, Gerhard Oswald, Peter Zencke
Vorsitzender des
Aufsichtsrats/Chairperson of the SAP Supervisory Board: Hasso
Plattner
Registergericht/Commercial
Register: Mannheim
No HRB 350269
Diese E-Mail kann
Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen
enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine
Kenntnissnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail
ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die
empfangene E-Mail.
Vielen Dank.
This e-mail may contain
trade secrets or privileged, undisclosed, or otherwise confidential information.
If you have received this e-mail in error, you are hereby notified that any
review, copying, or distribution of it is strictly prohibited. Please inform us
immediatly and destroy the original transmittal.
Thank you for your
cooperation
