[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [mylyn-dev] How can I reduce the warnings
|
Steffen,
should we include an link to an preferences input file?
like
Attachment:
markers.epf
Description: Binary data
Frank
Am 13.06.2011 um 18:28 schrieb Steffen Pingel:
> I have added a section to the Wiki that describes the current policy
> for markers: http://wiki.eclipse.org/Mylyn/Contributor_Reference#Markers
> .
>
> Steffen
>
> On Mon, May 30, 2011 at 9:44 PM, Steffen Pingel
> <steffen.pingel@xxxxxxxxxxx> wrote:
>> Hi,
>>
>> it looks like we never documented the policy for warnings that we
>> discussed a couple years ago on a Mylyn call. Here is what I recall
>> from the discussion (unfortunately I can't edit the Wiki right now due
>> to the server outage at Eclipse.org but I'll update the Contributor
>> Reference later):
>>
>> 1. Plug-ins are allowed to use internals within the boundaries of
>> their component (e.g. o.e.m.bugzilla.ui may access internals of
>> o.e.m.bugzilla.core). We have generally allowed that through x-friends
>> relationships in plug-in manifests.
>> 2. It's generally okay to use provisional APIs. We have made these
>> accessible through classpath filters: Project Properties > Java Build
>> Path > Libraries > Plug-in Dependencies > Access rules. It's common
>> that plug-ins have a rule to make
>> org/eclipse/mylyn/internal/provisional/** accessible.
>> 3. In cases where platform internals need to be accessed due to a lack
>> of API it's okay to make the specific classes or packages accessible.
>> These cases should be documented on bug 233055.
>> 4. Test plug-ins are allowed to use all internals.
>>
>> In theory, all remaining warnings indicate potential problems or API
>> insufficiencies. In practice, we do not have the capacity to address
>> all of them or the cost outweighs the benefit or they result out of
>> intentional design decisions, e.g. usage of deprecated APIs for
>> maintaining backwards compatibility. Still, I believe it's wrong to
>> hide all discouraged access and deprecation warnings by default as
>> that can create a perception that the code base is in perfect shape or
>> that it's generally okay to use internals.
>>
>> Instead, I recommend to create custom filters in the workspace to hide
>> those warnings that will not get addressed in the short time. You can
>> do that using the view menu of the Markers view. I currently use the
>> attached filters (File > Export > Preferences > Markers View
>> Configuration) which leaves around 130 warnings in the core Mylyn
>> plug-ins that should be looked at.
>>
>> Steffen
>>
>>
>> On Mon, May 30, 2011 at 5:48 AM, Frank Becker <frank@xxxxxxxxxxxxxxx> wrote:
>>> Hi,
>>>
>>> actual I have 5942 warnings within my workspace.
>>> 3568 warning are Discouraged access:
>>>
>>> Is there a way that I now longer get this as an warning.
>>>
>>> My goal is to have none / few warnings.
>>>
>>> Thanks
>>>
>>> Frank
>>> _______________________________________________
>>> mylyn-dev mailing list
>>> mylyn-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/mylyn-dev
>>>
>>
>>
>>
>> --
>> Steffen Pingel
>> Committer, http://eclipse.org/mylyn
>> Senior Developer, http://tasktop.com
>>
>
>
>
> --
> Steffen Pingel
> Committer, http://eclipse.org/mylyn
> Senior Developer, http://tasktop.com
> _______________________________________________
> mylyn-dev mailing list
> mylyn-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mylyn-dev