Re: [mylyn-dev] How can I reduce the warnings

[Steffen Pingel <steffen.pingel@xxxxxxxxxxx>]

Yes, we should check the Markers view configuration into CVS and add a
link to the Wiki.

Steffen

On Mon, Jun 13, 2011 at 8:16 PM, Frank Becker <Frank@xxxxxxxxxxxxxxx> wrote:
> Steffen,
>
> should we include an link to an preferences input file?
> like
>
>
> 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
>
>
> _______________________________________________
> 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