[
http://jira.codehaus.org/browse/MNG-4539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207706#action_207706
]
Johannes Schneider commented on MNG-4539:
-----------------------------------------
@Karl-Heinz:
> If you are deploying/installing a multimodule project you should first check
> if the install works fine before
> you deploy it...
Of course I could. And probably I should. But those lazy guys out there...
Stupid analogy: "Why need transactions in databases? They just should try the
statement before."
> If a module fails during the deployment phase what is usually wrong ?
Well, differnt things. Maybe a test case that fails sometimes (race condition).
Or maybe a network failure? Or permissions problem. Run out of disk space...
There are many things that may happen.
> If you are releasing artifacts you should first check your release cylce by
> using
> mvn -DdryRun=true release:prepare
> after this is working well you could do a a mvn release:prepare and mvn
> release:perform.
I think Maven should do that. I don't want to sit here, wait several hours to
verify that the release seemed to work (as dry run), then release it and run
into some (random) problems...
A successfull dry run is just a hint, that the release *should* work. But no
guarantees here, too.
SVN issues: SVN has disadvantages. Some other VCS don't have them. But that is
another issue. And polluting the history *is* a problem. At least for me.
Of course it is possible to work around nearly every issue most of the time.
But Maven is made to make the life easier. I don't want to learn complex
workflows that take a lot of time, are complicated, hard to remember and error
prone. If I'd prefer that type of work, I used Ant...
> Transactions support
> --------------------
>
> Key: MNG-4539
> URL: http://jira.codehaus.org/browse/MNG-4539
> Project: Maven 2 & 3
> Issue Type: New Feature
> Reporter: Johannes Schneider
>
> In an ideal world, every action Maven takes had transaction support.
> Some problems I run into regularly:
> - Deploying/installing a multi module project:
> - But one module fails (of course one of the last) and I end up with an
> inconsistent repository.
> - Deployment takes ages: Inconsistent repository for a couple of minutes
> (or hours).
> - Release:
> - Tagging of the central source repository and upload of the artifacts are
> not done synchronously.
> - If anything fails (typically site generation/deployment), the source and
> artifacts repositories are inconsistent.
> - Cleaning up after a failed release is not easy (or not possible -->
> Subversion).
> Of course a staging repository could solve some of the issues. But I suggest
> to go one step further:
> Create some sort of transaction support where actions may be added to. Once
> the transaction is finished, it is commited and all the actions are executed
> (e.g. uploading to the repository / tagging).
> If one of the actions fails, a rollback is executed.
> I think this should be possible for many cases. Subversion repositories won't
> support a "perfect" rollback mechanism. But the distributed VCS (e.g. Git)
> would.
> Uploading to the repository could support rollback either through cheap
> delete-on-rollback or better some special handling in relation to repository
> managers like Nexus. Maybe WebDAV supports transactions?
> --> For many use cases at least some sort of "cheap" transaction support with
> faked rollback stuff could work. But for other environments (DCVS + Nexus)
> there could be first class support...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
