Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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

Inactive hide details for João Arthur ---01/28/2014 01:13:14 PM---Hi Curtis, thanks for the references. I've been looking to thJoã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

From: João Arthur <joaoarthurbm@xxxxxxxxx>
To: "Eclipse PDE general developers list." <pde-dev@xxxxxxxxxxx>,
Date: 01/28/2014 01:13 PM
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


    Inactive hide details for João Arthur ---01/20/2014 12:23:13 PM---Hi guys, I'm interested in contributing to PDE API Tools sourJoã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

GIF image


Back to the top