| Re: [pde-dev] Contribution to PDE API Tools |
Hi Joao, sorry for the slow reply.
I can't think of a scenario that I have experienced where package level annotations would be helpful. What is API is defined using the OSGi manifest at the package level. Marking an entire @noextend/@noimplement doesn't make sense, marking a package as @noreference would be better enforced by not adding the package as API at all.
I wouldn't expect an API to change it's restrictions very often. @noreference could be used to exclude parts of the API that are not fully formed, but once they are API, the annotation should be removed on a permanent basis.
Curtis
João Arthur ---01/28/2014 01:13:14 PM---Hi Curtis, thanks for the references. I've been looking to these bug reports and past data. It seems
Date: 01/28/2014 01:13 PM
From: João Arthur <joaoarthurbm@xxxxxxxxx>
To: "Eclipse PDE general developers list." <pde-dev@xxxxxxxxxxx>,
Subject: Re: [pde-dev] Contribution to PDE API Tools
Sent by: pde-dev-bounces@xxxxxxxxxxx
Hi Curtis, thanks for the references. I've been looking to these bug reports and past data. It seems to me that one of the biggest problem is to maintain the annotations as the code evolves. Some people complain about having to update annotations spread through the code.
Do you think that expanding the usage of annotations to the package level could help that? It would be less code to update when rules/code change.
João
On Mon, Jan 20, 2014 at 11:35 AM, Curtis Windatt <Curtis_Windatt@xxxxxxxxxx> wrote:http://wiki.eclipse.org/PDE/API_Tools/Javadoc_Tags
_______________________________________________
This page lists the current annotations.
I wasn't aware of any annotations that were being requested, but doing a search I did see Bug 298377 - @maychange suggestion for auto-generated integers. Currently the Eclipse teams use package names containing *.provisional.* to indicate it may become API in the future, but it is not guaranteed. Having the ability to specify some existing API as provisional, or maychange could be useful. The Platform UI team used the @noreference tag (which we recently expanded support for) to add classes to the API packages, but restrict their use until a formal API was chosen.
Here is a quick bugzilla query listing bug reports relating to the annotations: http://goo.gl/s5c0o9
Curtis Windatt
João Arthur ---01/20/2014 12:23:13 PM---Hi guys, I'm interested in contributing to PDE API Tools source code. In particular, I would like to
From: João Arthur <joaoarthurbm@xxxxxxxxx>
To: "Eclipse PDE general developers list." <pde-dev@xxxxxxxxxxx>,
Date: 01/20/2014 12:23 PM
Subject: [pde-dev] Contribution to PDE API Tools
Sent by: pde-dev-bounces@xxxxxxxxxxx
Hi guys, I'm interested in contributing to PDE API Tools source code. In particular, I would like to extend the set of rules that API Tools can detect regarding the API Usage. So far, as far as I know, these are the current annotations:
@noimplement
@noextend
@noinstantiate
@nooverride
@noreference
I would like to hear from you what other kind of constraints the team would like to express? or how the existent constraints can be improved?
Thank you in advance,
João _______________________________________________
pde-dev mailing list
pde-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-dev
_______________________________________________
pde-dev mailing list
pde-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-dev
pde-dev mailing list
pde-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-dev
_______________________________________________
pde-dev mailing list
pde-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-dev
