Details

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

      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.patch
        22 kB
        Mark Struberg
      2. MRELEASE-457.2.patch
        22 kB
        Mark Struberg

        Activity

        Hide
        Olivier Lamy (*$^¨%`£) added a comment -

        temporary move set fix version to 2.1.

        Show
        Olivier Lamy (*$^¨%`£) added a comment - temporary move set fix version to 2.1.
        Hide
        Mark Struberg added a comment -

        This patch enables the release of child modules even with SCMs which doesn't support sparse checkout. The trick is to parse the pom to be released and search for a similar pom in the target/checkout directory. Then use this poms directory for running the release-perform goals.

        There is currently a small issue left with child modules releasing because we get the childModules relative path added to the base SCM-URL. This is needed for SVN but breaks a lot other SCMs. The workaround is to add a <scm> section to each submodule until we fixed this bug.

        Show
        Mark Struberg added a comment - This patch enables the release of child modules even with SCMs which doesn't support sparse checkout. The trick is to parse the pom to be released and search for a similar pom in the target/checkout directory. Then use this poms directory for running the release-perform goals. There is currently a small issue left with child modules releasing because we get the childModules relative path added to the base SCM-URL. This is needed for SVN but breaks a lot other SCMs. The workaround is to add a <scm> section to each submodule until we fixed this bug.
        Hide
        Mark Struberg added a comment -

        the broken <scm> URL assembling is done in the following code parts:

        • DefaultModelInheritanceAssembler#assembleModelInheritance calls
          childScm.setDeveloperConnection( appendPath( parentScm.getDeveloperConnection(), child.getArtifactId(), childPathAdjustment, appendPaths ) );
        • MavenProject#getModulePathAdjustment which actually creates the pathAdjustment
        Show
        Mark Struberg added a comment - the broken <scm> URL assembling is done in the following code parts: DefaultModelInheritanceAssembler#assembleModelInheritance calls childScm.setDeveloperConnection( appendPath( parentScm.getDeveloperConnection(), child.getArtifactId(), childPathAdjustment, appendPaths ) ); MavenProject#getModulePathAdjustment which actually creates the pathAdjustment
        Hide
        Benjamin Bentmann added a comment -

        Just to be clear, the URL inheritance is broken by design of POM 4.0.0 (MNG-2006). This is just another change that can only be safely made for a new model version.

        Show
        Benjamin Bentmann added a comment - Just to be clear, the URL inheritance is broken by design of POM 4.0.0 ( MNG-2006 ). This is just another change that can only be safely made for a new model version.
        Hide
        Mark Struberg added a comment -

        Not sure Benjamin. Is it possible that the DefaultModelInheritanceAssembler asks the respective maven-scm-provider if the URL needs any adoption at all? Or is this part too early in the lifecycle to get access to the maven-scm-provider?

        Show
        Mark Struberg added a comment - Not sure Benjamin. Is it possible that the DefaultModelInheritanceAssembler asks the respective maven-scm-provider if the URL needs any adoption at all? Or is this part too early in the lifecycle to get access to the maven-scm-provider?
        Hide
        Benjamin Bentmann added a comment -

        Or is this part too early in the lifecycle to get access to the maven-scm-provider?

        Yes. Also, how would you find this maven-scm-provider, e.g. there is no artifact id/version mentioned in the URL, add another black magic discovery? In general, I have a strong objection against the idea that construction of the effective POM requires pluggable/external components as this makes the POM depend on a specific runtime environment (e.g. Maven class loader hierarchy) and hinders its consumption in tools other than Maven. The POM should be fully declarative and be controlled by fixed/well-known rules.

        Show
        Benjamin Bentmann added a comment - Or is this part too early in the lifecycle to get access to the maven-scm-provider? Yes. Also, how would you find this maven-scm-provider, e.g. there is no artifact id/version mentioned in the URL, add another black magic discovery? In general, I have a strong objection against the idea that construction of the effective POM requires pluggable/external components as this makes the POM depend on a specific runtime environment (e.g. Maven class loader hierarchy) and hinders its consumption in tools other than Maven. The POM should be fully declarative and be controlled by fixed/well-known rules.
        Hide
        Mark Struberg added a comment -

        new version. MRELEASE-457.2.patch now closes the XmlReader + a few codestyle fixes

        Show
        Mark Struberg added a comment - new version. MRELEASE-457 .2.patch now closes the XmlReader + a few codestyle fixes
        Hide
        Jesse Glick added a comment -

        Note: Mercurial does not (yet) support sparse checkouts, but you can use hg archive --include <MODULE> target/checkout, akin to using e.g. svn export.

        Show
        Jesse Glick added a comment - Note: Mercurial does not (yet) support sparse checkouts, but you can use hg archive --include <MODULE> target/checkout , akin to using e.g. svn export .
        Hide
        Mark Struberg added a comment -

        txs Jesse, but then you'd most probably need to pimp the maven-scm-api and hack something into the hg provider. Because usually the scm-provider only gets the checkout URL. But in this case you would additionally need the path to the child module. This information is currently not available.

        Show
        Mark Struberg added a comment - txs Jesse, but then you'd most probably need to pimp the maven-scm-api and hack something into the hg provider. Because usually the scm-provider only gets the checkout URL. But in this case you would additionally need the path to the child module. This information is currently not available.
        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:

              Development