[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Restricted Access warnings?

I had to double check but they were Discouraged Access warnings, not Access restriction warnings.

Thanks for the clarification.

Lawrence Mandel

Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814   Fax: 905 - 413 - 4920
lmandel@xxxxxxxxxx


David M Williams <david_williams@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

04/04/2006 12:14 PM

Please respond to
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
To
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
Subject
[wtp-dev] Restricted Access warnings?






Lawrence, you asked about "restricted access warnings" ... are you seeing
Access restriction: ...
or
Discouraged Access: .... ?


Access restriction:

This is a worse warning, and a sign of run-time trouble.  I know M5 had some bugs that caused us to have some spurious ones (related to 3rd party jars), but believe these should be fixed in M6, but have not checked. So, if you still see these, point me to a few, or open a bugzilla, and we'll investigate. (I do not see any in my workspace, so .. if you do, might be a set up problem? Or ... some other bug?).

Discouraged Access

Yes, there are 15,000 of these, and they are normal (and should be turned off or filtered out, , if  causing clutter for you).



To summarize policy: speaking as PMC member and Architecture Group Lead,
our policy is the same as the Eclipse Project policy:
expose everything by listing all packages in the manifest.mf files, but
use x-internal to mark any packages which are not official, complete,  and binary compatible API
(which includes all packages with 'internal' in the name).

We realize this causes lots of warnings, (if you don't change the default settings or filters).
but, our policy is its best to be conservative (yet accurate) on what we imply is API,
rather than risk adopters being surprised later. Adopters can turn off the warnings, once they "accept the risk"
of using non-API, if they do in fact extend WTP in those ways.

Also, our architectural goal is to have clean component-subsystems (eventually) so the "x-freinds" relationship
can not span the component-subsystem boundary. (so for example, dtd or xsd can use xml internals,
but something in HTML or JSP should not .. and while it currently has to, again, its best to have accurate manifests now).

Hope this helps,





Lawrence Mandel <lmandel@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

04/04/2006 10:20 AM

Please respond to
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
To
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
Subject
Re: [wtp-dev] Any body using M6 yet? See "breakages" in our dev. env.?








I've also noticed a lot of restricted access warnings in my workspace. Is our policy at this time to expose all functionality to extenders or to restrict some packages so these warnings show up?

Lawrence Mandel

Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814   Fax: 905 - 413 - 4920
lmandel@xxxxxxxxxx
David M Williams <david_williams@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

04/04/2006 03:34 AM

Please respond to
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
To
wtp-dev@xxxxxxxxxxx
cc
Subject
[wtp-dev] Any body using M6 yet? See "breakages" in our dev. env.?







I sure hope you are using M6! :)  Especially since we are building with it now!  

If so, and if you have all/most of our WTP plugins loaded, have you noticed there's a ton of new errors?  similar to

    "The type org.eclipse.core.resources.IResource cannot be resolved. It is indirectly referenced from required .class files"

Which results in nothing much building (in the workspace, builds fine in batch mode, and runs fine).

I'm not sure what changed to cause this change, or what "right" solution is.
But, the easiest solution is to add things like core.resoruces to the manifest.mf file.
core.resources is probably easy and obvious ... everyone needs that, right?
but emf.ecore was another that will have to be added to some... that's less desirable to "require", I'd guess.

See also for some similar issues and pros and cons.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=92117
https://bugs.eclipse.org/bugs/show_bug.cgi?id=73957

Anyone else want to propose a solution?
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev