Re: [wtp-dev] Too few Internal non-API use bugs?

[David M Williams <david_williams@xxxxxxxxxx>]

> Is it expected to have plugins
that do not appear in api violations 
> report but have discouraged access warnings, like for example 
> org.eclipse.wst.web? Are there reasons to consider discouraged access
> API compliant?

Yes, in some cases. In the API Violations
Report we are looking for violations coming from completely outside WTP.
Those are the worst. 

The ones you still see in org.eclipse.wst.web
are coming from "within" WTP itself. Long term, we want to improve
on those too, but, 
since we have more control over what
"ships together" they are more ugly than breaking. 

So ... tough to tell, eh? how to see
the ones from completely outside WTP vs. those inside WTP? 
Here's how, There are some settings
in the development environment you can override so the normal rules so,
no matter 
if another plugins marked something
as "discouraged", you can set a property to say, "oh, go
ahead and count it as accessible". 

Below is a quick picture of how to do
this. 
pick your project  org.eclipse.wst.web
in this case. 
get its properties, pick the build path,
expand the "Plugin Dependancies". 
pick the "access rules" and
select edit (or add?). 
In that add dialog, you can put rules
of various types and degrees. 
The type I put in was to force all org/eclipse/wst
 classes to be considered accessible. 
Doing that, the 100 or so discouraged
accesses all go away ... BUT, if there were some from, say org.eclipse.jdt.internal,

then they would have still shown up.


This is all in "help" btw,
just take this as your late-night "how to use Eclipse" show :)


But, seriously, we'll soon have some
"standards" in place, so all WTP developers can see the bad from
the ugly 
violations. Rumor has it, there's some
magic ways to do this in the build too, whereas now we just turn them all
off, since there's 
too many.