Shibboleth Developer's Meeting, December 20, 2013
...
- Requirement for Servlet 3.0 in our V3 stack.
- Cleanest option is to just say yes. This would restrict deployment platforms for the V3 IdP.
- It might be possible to fudge it somehow, though. How much effort do we think that is worth?
- Final option would be revisit the decision to move to Spring Framework 4 and stick with Spring Framework 3 for the life of IdP V3, but I don't think we want to do that.
- Use of
@Override. I haven't heard any objections to it on the list, but let's be clear about what we want to do; some selection or all of the following:- Change (reverse) the recommendation for the "insert
@Overridein new code" option in Eclipse? - Add a code style recommendation to include
@Overridewhere appropriate? - Should we do any work on any of the old code, or leave it to individual discretion?
- Should we use Checkstyle's
MissingOverridecheck: "Verifies that thejava.lang.Overrideannotation is present when the {@inheritDoc} javadoc tag is present."- Would probably involve quite a lot of warnings.
- Note that it is a purely textual check; Checkstyle doesn't seem to know when a method actually does override.
- There is also a Java compiler preference in Eclipse (settable either at workspace or project level) which defaults to ignoring missing
@Override. - We currently set this explicitly to
org.eclipse.jdt.core.compiler.problem.missingOverrideAnnotation=ignorein the parent project's preferences. - We could change this per-project setting or remove it to allow the personal (workspace) preference to take effect.
- Change (reverse) the recommendation for the "insert
Rod
Mostly busy elsewhere. I'd like to get direction on what we do about SVN resources.
Scott
Tom
Other