[
https://issues.apache.org/jira/browse/IVY-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494995
]
Gilles Scokart commented on IVY-492:
------------------------------------
Add an additional attribute to the FileResolver seems indeed better than using
a different resolver. It will be simpler for the user.
However, if we have this attribute set to true, I think we should raise an
error if the dependency is not there. And if it is set to false, we should not
not use the library even if it is there. So I think the transactional aspect
should be driven by the value of the attribute only, and not by the presence of
the dependency.
Concerning the usage of a separated interface that add the transactional
aspects, I don't know what is better.
Adding the 3 methods directly in the resolver interface will force all
interface to decide explicitly how they handle transaction. It can be seen as
a good thing and as a bad thing.
So I would say :
-0 to add the transaction methods directly in the resolver interface
+0 to use a separated interface implemented only by the resolvers that are
transaction aware (if their attribute transactional is false, they are still
transaction aware)
> support atomic publish operation
> --------------------------------
>
> Key: IVY-492
> URL: https://issues.apache.org/jira/browse/IVY-492
> Project: Ivy
> Issue Type: New Feature
> Components: Core
> Reporter: Geoff Reedy
>
> Some resolver types (e.g. one that uses subversion) could benefit from
> publishing a module as a single atomic transaction. Currently, each artifact
> (and it's checksums) are published as separate operations, if one of the
> artifact uploads fail (perhaps an artifact is missing or another user is
> trying to publish the same version at the same time) the ivy repository can
> be in an inconsistent state with a half published module. In addition, if
> uploads are logged many entries in the log are generated for a single logical
> operation.
> A possible implementation strategy is to add three new methods to the
> resolver interface:
> beginPublish(ModuleRevisionId)
> abortPublish()
> commitPublish()
> beginPublish would be called before publishing the artifacts of the module,
> abortPublish would be called if there is an error while publishing the
> module, commitPublish would be called if all artifacts were successfully
> published. Existing resolvers could simple implement these methods as no-ops
> to retain the present behavior.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
