[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipselink-dev] Eclipse IDE Error/Warning Levels
|
I
agree with phase 1.
I
don't think that the deprecation warning level need ever be turned on, though,
even in phase 2. Deprecation means nothing, really, and Sun has even said that
they do not ever plan on removing deprecated API. I keep that Eclipse warning
eternally turned off in all my Eclipse projects.
I am
not sure that in phase 3 the same level of quality needs to be in place for the
tests, but as was mentioned I think we can discuss what an acceptable level is
when we reach that bridge.
EclipseLink
Developers,
During our
incubation phase I would like to propose an approach to dealing with the many
warnings we get in the Eclipse IDE for our code base. Historically these have
not been a great concern to TopLink development but I feel that the move to
Eclipse should include an effort to work on overall code quality and we should
leverage the Eclipse IDE tooling to do this.
We have
a very large number of warning across our projects that make addressing
these easily a difficult task. To make this more manageable I would like to
propose a phased approach with concrete items in the project back-log to
address them.
STEP 1: Turn down
the warning levels within the project settings to get to a manageable number
of warnings we can address.
- In all project
source projects we will turn off warnings for deprecation, serialVersionUID,
and unchecked generic type operations
- In all test case
projects we will turn off these warnings as well as the unused imports,
local variable is never read, an unused local or private member
warnings
This will get us
down to a more manageable warning level and we can add specific items to the
project back-log to get these addressed.
STEP 2: After the
above warnings have been addressed through code changes and we have addressed
the deprecated code removal we can increase the warning level to include
deprecation as well as any additional ones the developers feel are useful to
the source projects.
STEP 3: Increase
the warning levels on the test case projects as determined by the
developers.
Based on this
proposal I would like to proceed with modifying the existing project's warning
levels and checking them in. Please provide feedback on this proposal by COB
Thursday.
Doug
![Oracle Email Signature Logo]()
Doug Clarke | Principal Product Manager,
Oracle TopLink
Oracle Server
Technologies
45 O'Connor, Suite 4000 | Ottawa, ON K1P
1A4 Canada
