-
Improvement
-
Resolution: Fixed
-
Minor
Almost all functional implementations of SCMHeadObserver.observe(SCMHead,SCMRevision) perform either blocking operations or operations that involve I/O. In the absence of being able to throw either IOException or InterruptedException they have no way to expose their failure to the calling SCMSource.fetch(...) operation and hence no way to propagate out to the consumer code.
This is strictly speaking a breaking method signature change, the following is the rationale as to why we can make the change with minimal risk:
- consumers of SCM API will be implementing their own subclasses of SCMHeadObserver, they will not (outside of unit tests) be calling SCMHeadObserver.observe() thus the widening of the method signature will not affect consumers.
- SCMSource.fetch(...) (and it's matching SPI, SCMSource.retrieve(...)) already declare throwing IOException and InterruptedException so implementations of SCM API should not be affected by the signature change. At worst implementations will pick up a compiler error when they update their SCM API dependency - though a quick test revealed that git, mercurial, github and Bitbucket SCMSource implementations were all unaffected by the change.
- Running a newer SCM API with an implementation that were compiled against the older SCM API will not cause issues as:
- Checked exceptions are not enforced at runtime, only at compile time.
- The calls to SCMHeadObserver.observe(...) will all be within SCMSource.retrieve(...) which already propagates the same exceptions so consumers will be handling the exceptions anyway.
- is blocking
-
JENKINS-42511 Computed Folder API poorly designed for concurrent event processing
- Closed
- links to