Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wtp-dev] Tweaking our access rules "from above"

As I've implied, I've been doing some work to improve our use of Access Rule violation reporting.

It has been in the builds this week, but I've improved some of the summary reporting, which should
start to show up later tonight (hopefully "today" for most of you reading this :)

And, I've written up the general issue and procedures in our wiki.

Basically, the ability to tweak the dev. env. has been present for a long time ... I think I've written
about that before, but can't find it ... so, probably just dreamt it. Not sure exactly, why others haven't
used this ... but, maybe

there hasn't been much motivation to do so, since the PDE batch builds we do would not
reflect any custom tweaking we did in the IDE.

So, now that PDE batch build part has been fixed.

If you "drill down" In this weeks builds, you can see we are reporting 662 warnings, in 21 of our
code plugins. So, we need to fix these, just as much, or more, than the other 224 compiler warnings
we have. (and .. thanks to those that have reduced those compiler warnings from the 500 compiler warnings we were
having lately ... not sure who's responsible ... but you get one clown-nose-free build break for doing so ;)

There's actually access violations in one plugin ... which I think will be fixed, incidentally,  once we improve our
orbit bundle use.

To some extent, these access warnings will correspond to some of our API Scan violation reports ... so, there may
be bugs opened for many cases already, either against our own code, or for others to provide API.

The one thing the API Scan violation reports won't ever tell us, is the use of inlined constants, so, that may
be new-news for some ... and, those are both "dangerous" violations precisely because they are inlined,
and usually easy to fix. So, let's attack those for 2.0 release ... please!

Another immediate action is that plugin/component owners should "fix up" their own customized access rules, as documented
in so that way we can all turn on
discouraged use warnings in our development environments again ... and not see the infamous Christmas Tree of
50000 warnings light up our Display's.

A longer term action (over the next few weeks) ... if your plugin does not show up as having any access violations,
and does not show up in our API Violation scans ... then you should make sure you use a WIDE plugin version pre-req
pattern in your files. (You'll recall, in the past we often used conservative ranges, since we didn't know
for sure).

So ... I'm sure this note is terse .. for as long as it is ... please raise any questions, concerns, or problems here.

Thanks all.

Back to the top