[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [xtext-dev] API Tooling
|
That would mean to introduce a dependency to the annotations.
What's the bundle's name the annotations are included in?
Cheers,
Sven
On Feb 9, 2009, at 9:38 PM, Peter Friese wrote:
Guys,
I just had a look at the API tooling. To me, the API tooling looks
very powerful, but we do not need to use everything of it.
So here's what we would need to do to use it:
1) Add an API Tooling Nature and the API tooling Builder to each
Xtext project. This is actually quite easy, there is a UI action to
do this (project context menu -> PDE Tools -> API Tooling Setup,
then select all Xtext projects).
2) Next, add JavaDoc Annotations to all public, yet not-to-be-
extended classes, interfaces and methods. We only need to annotate
classes and interfaces that are located in exported packages, as non-
exported classes and interfaces will not be visible to downstream
bundles anyway.
Here is a list of the relevant tags:
@noimplement (Interfaces) - Indicates that clients must not
implement this interface. Any class using the implements or extends
keyword for the associated interface will be flagged with problem.
@noextend (Classes) - Indicates that clients must not extend this
class. Any class using the extends keyword for the associated class
will be flagged with a problem.
@noinstantiate (Classes) - Indicates that clients must not
instantiate this class. Any code that instantiates the associated
class with any constructor will be flagged with a problem.
@nooverride (Methods) - Indicates that clients must not redeclare
this method. Any subclass that defines a method that overrides the
associated method will be flagged with a problem.
@noreference (Methods, constructors and fields (nonfinal)) -
Indicates that clients must not reference this method, constructor,
or nonfinal field. Any code that directly invokes the associated
method or constructor or references the associated nonfinal field
will be flagged with a problem.
That's it.
Additionally, we can later
3) Define a shipped version of Xtext to be a so-called API Baseline.
Eclipse will then scan the bundles in this version and make sure we
do not break API by removing or renaming public classes, interfaces
and methods.
Here is a nice developerWorks article that gives a good overview of
what can be achieved with the API tooling: http://www.ibm.com/developerworks/opensource/library/os-eclipse-api-tools/index.html
. Even more information can be found here: http://wiki.eclipse.org/PDE/API_Tools
In the above mentioned developerWorks article it is mentioned that
API tooling can be used headless, which is very nice as well.
As API tooling seems to be quite mature and since we will not get
any additional dependencies to PDE (besides the additional nature
and builder), I suggest using API tooling.
Cheers,
Peter
_______________________________________________
xtext-dev mailing list
xtext-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/xtext-dev