[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [xtext-dev] API Tooling
|
So, than no extra dependencies. That's nice.
+1 for using these tags.
On Feb 10, 2009, at 8:47 AM, Bernd Kolb wrote:
AFAIK these are not annotations but Javadoc comments
Bernd
Zitat von Sven Efftinge <sven@xxxxxxxxxxx>:
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
_______________________________________________
xtext-dev mailing list
xtext-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/xtext-dev
Mit freundlichen Grüßen
B.Kolb
_______________________
KolbW@re
Beratung und Coaching
Franz-Marc Str. 35
89520 Heideinheim
_______________________________________________
xtext-dev mailing list
xtext-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/xtext-dev