Details

    • Type: New Feature New Feature
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.2
    • Component/s: perform, scm
    • Labels:
      None
    • Number of attachments :
      2

      Description

      Some SCMs like GIT, Mercurial, Bazaar, BitKeeper, Darcs, and Monotone doesn't support sparse checkouts (checkout of a single subdirectory).

      So while doing a mvn release:perform in a sub-module, we will always get the whole project checked out into target/checkout!

      For doing the clean build from this checkout, we have to implement a functionality to find the right submodule first.

      1. MRELEASE-457.2.patch
        22 kB
        Mark Struberg
      2. MRELEASE-457.patch
        22 kB
        Mark Struberg

        Activity

        Hide
        Grant Gardner added a comment - - edited

        Can this be implemented with the projectPath concept that the release plugin already understands?

        ie change the git provider to parse the additional path information into the scm repository's projectPath attribute. Then as long as you follow the convention in placing modules in a subdirectory named for the module it should just work.

        Of course it would be even better if the childPathAdjustment code was changed to use the relative path between module and parent rather than artifactId. I think even SVN modules that don't follow the convention are already broken in this regard.

        Show
        Grant Gardner added a comment - - edited Can this be implemented with the projectPath concept that the release plugin already understands? ie change the git provider to parse the additional path information into the scm repository's projectPath attribute. Then as long as you follow the convention in placing modules in a subdirectory named for the module it should just work. Of course it would be even better if the childPathAdjustment code was changed to use the relative path between module and parent rather than artifactId. I think even SVN modules that don't follow the convention are already broken in this regard.
        Hide
        Olivier Lamy added a comment -

        patch tested with this project (https://github.com/olamy/scm-git-test) to release only my-app or my-app-webapp and it works.
        Someone else wants to review ?

        Show
        Olivier Lamy added a comment - patch tested with this project ( https://github.com/olamy/scm-git-test ) to release only my-app or my-app-webapp and it works. Someone else wants to review ?
        Hide
        Mark Struberg added a comment -

        Hi Olivier!

        Please also check Grants comment with the projectPath. Hi is right that I (mis-?) used an existing parameter for passing the information about the found child pom. Otoh I think changing the project path is also not the correct way. To be completely clean, we probably need to introduce a new parameter. But not sure if this is really needed - that's why I didn't commit it myself but asked for reviews

        LieGrue,
        strub

        Show
        Mark Struberg added a comment - Hi Olivier! Please also check Grants comment with the projectPath. Hi is right that I (mis-?) used an existing parameter for passing the information about the found child pom. Otoh I think changing the project path is also not the correct way. To be completely clean, we probably need to introduce a new parameter. But not sure if this is really needed - that's why I didn't commit it myself but asked for reviews LieGrue, strub
        Hide
        Mark Struberg added a comment -

        Grant, I've looked at my patch again and it seems that the solution of passing the child modules location via the releaseDescriptors checkoutPath property is the least intrusive way. Using the projectPath would change lot of functionality and would break a few other things as far as I've seen.

        Show
        Mark Struberg added a comment - Grant, I've looked at my patch again and it seems that the solution of passing the child modules location via the releaseDescriptors checkoutPath property is the least intrusive way. Using the projectPath would change lot of functionality and would break a few other things as far as I've seen.
        Hide
        Lee Thompson added a comment -

        Trying to catch up on this as I'm hitting it to. Don't think the patch will work if there is no pom in the top directory of the source repo. In line with what Benjamin stated, I think its better to inject rather than discover.

        Injection of something like "pomSubDirectory" as a parameter into the release:perform mojo would be very unobtrusize. The release descriptor already has "ScmRelativePathProjectDirectory". Not sure if that is the right variable, but if it was, it would be a very simple non-intrusive fix of PerformReleaseMojo.java ...

        Bar.java
            /**
             * If the POM for the project you are releasing is not in the top directory of your checked
             * out source repository, then you will need to specicify this parameter.  It almost never
             * occurs with Subversion since you can specify a checkout of any directory in the 
             * repository. This is not the case for SCM systems like Git and Mercurial as you check 
             * out the whole repository and frequently, the project you want to release is not in 
             * the top directory.  If your pom is in the top directory of your source, this parameter
             * is not needed.
             *
             * @parameter expression="${pomSubDirectory}"
             * @since 2.2
             */
            private String pomSubDirectory;
        
        
        
        
        
        
                    if (pomSubDirectory != null )
                    {
                        releaseDescriptor.setScmRelativePathProjectDirectory( pomSubDirectory );
                    }
        
        Show
        Lee Thompson added a comment - Trying to catch up on this as I'm hitting it to. Don't think the patch will work if there is no pom in the top directory of the source repo. In line with what Benjamin stated, I think its better to inject rather than discover. Injection of something like "pomSubDirectory" as a parameter into the release:perform mojo would be very unobtrusize. The release descriptor already has "ScmRelativePathProjectDirectory". Not sure if that is the right variable, but if it was, it would be a very simple non-intrusive fix of PerformReleaseMojo.java ... Bar.java /** * If the POM for the project you are releasing is not in the top directory of your checked * out source repository, then you will need to specicify this parameter. It almost never * occurs with Subversion since you can specify a checkout of any directory in the * repository. This is not the case for SCM systems like Git and Mercurial as you check * out the whole repository and frequently, the project you want to release is not in * the top directory. If your pom is in the top directory of your source, this parameter * is not needed. * * @parameter expression= "${pomSubDirectory}" * @since 2.2 */ private String pomSubDirectory; if (pomSubDirectory != null ) { releaseDescriptor.setScmRelativePathProjectDirectory( pomSubDirectory ); }

          People

          • Assignee:
            Mark Struberg
            Reporter:
            Mark Struberg
          • Votes:
            1 Vote for this issue
            Watchers:
            10 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: