<p dir="auto"><strong><a href="https://jira.spring.io/secure/ViewProfile.jspa?name=kyrill007" rel="nofollow">Kyrill Alyoshin</a></strong> opened <strong><a href="https://jira.spring.io/browse/SPR-9170?redirect=false" rel="nofollow">SPR-9170</a></strong> and commented</p>
<p dir="auto">I think it would be a really-really good idea to move <em>org.springframework.batch.retry</em> into <em>org.springframework.core.retry</em>. It is really well-thought out and useful API, a true gem. I can't believe I haven't noticed it in all these years of using Spring. The API contain no conceptual dependencies on batch infrastructure and they should really be moved into the core.</p>
<hr>
<p dir="auto"><strong>Affects:</strong> 3.1.1</p>
<p dir="auto"><strong>Issue Links:</strong></p>
<ul dir="auto">
<li><a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="398088670" data-permission-text="Title is private" data-url="https://github.com/spring-projects/spring-framework/issues/9531" data-hovercard-type="issue" data-hovercard-url="/spring-projects/spring-framework/issues/9531/hovercard" href="https://github.com/spring-projects/spring-framework/issues/9531">#9531</a> Migrate Repeat and Retry from Spring Batch (<em><strong>"duplicates"</strong></em>)</li>
</ul>
<p dir="auto">1 votes, 4 watchers</p>
<p dir="auto"><strong><a href="https://jira.spring.io/secure/ViewProfile.jspa?name=david_syer" rel="nofollow">Dave Syer</a></strong> opened <strong><a href="https://jira.spring.io/browse/SPR-4855?redirect=false" rel="nofollow">SPR-4855</a></strong> and commented</p>
<p dir="auto">Migrate Repeat and Retry from Spring Batch.  They are almost completely self-contained now (on trunk), so it shouldn't be a tough job - just need to decide where to put them.  Maybe the tests might have some batch dependencies, but they would be easily factored out.  There is also a dependency on some utility stuff in org.springframework.batch.support which would need to be moved over or equivalents provided in core.</p>
<p dir="auto">The only real work will be migrating the StatefulRetryOperationsInterceptor (very useful).  It currently depends on ItemKeyGenerator and NewItemIdentifier, for good reasons, so equivalents will have to be provided.  When this is refactored it might also be a good idea to revisit the whole stateful retry concept - it could be implemented as an extension of the RetryOperations interface instead of through a callback / policy pairing as it is now.</p>
<hr>
<p dir="auto"><strong>Affects:</strong> 2.5.4</p>
<p dir="auto"><strong>Issue Links:</strong></p>
<ul dir="auto">
<li><a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="398117592" data-permission-text="Title is private" data-url="https://github.com/spring-projects/spring-framework/issues/13808" data-hovercard-type="issue" data-hovercard-url="/spring-projects/spring-framework/issues/13808/hovercard" href="https://github.com/spring-projects/spring-framework/issues/13808">#13808</a> Consider moving Spring Batch Retry package into Spring Core (<em><strong>"is duplicated by"</strong></em>)</li>
</ul>
<p dir="auto">1 votes, 3 watchers</p>