[
http://jira.codehaus.org/browse/MNG-4539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
