| 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