You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Johannes Schneider (JIRA)" <ji...@codehaus.org> on 2010/01/20 19:09:55 UTC

[jira] Created: (MNG-4539) Transactions support

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

        

[jira] Commented: (MNG-4539) Transactions support

Posted by "Johannes Schneider (JIRA)" <ji...@codehaus.org>.
    [ 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

        

[jira] Commented: (MNG-4539) Transactions support

Posted by "Karl Heinz Marbaise (JIRA)" <ji...@codehaus.org>.
    [ http://jira.codehaus.org/browse/MNG-4539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207648#action_207648 ] 

Karl Heinz Marbaise commented on MNG-4539:
------------------------------------------

If you are deploying/installing a multimodule project you should first check if the install works fine before you deploy it...
If a module fails during the deployment phase what is usually wrong ?
That you have "inconsistent" repository for a couple of minutes/hours could be..ok...

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. 

On the other hand why is it not possible to clean Subversion in case of a real problem? Just simple svn rm the created tag ..that's it...

What you've written about the rollback of SVN: If a commit/tag is done it's in the repository...you can delete it...but it's left in the history...

May be it could be possible to make the tags of the release action at the end of the operation, but AFAIK this isn't that simple...



> 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