Maven
  1. Maven
  2. MNG-1911

Building plugins with extensions in a reactor fails

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Won't Fix
    • Affects Version/s: 2.0.1
    • Fix Version/s: None
    • Component/s: Plugins and Lifecycle
    • Labels:
      None

      Description

      I have the following in my main pom

      <build>
       <pluginManagement>
        <plugins>
         <plugin>
          <groupId>org.apache.servicemix.plugins</groupId>
          <artifactId>maven2-jbi-plugin</artifactId>
          <version>1.0-SNAPSHOT</version>
          <extensions>true</extensions>
         </plugin>
        </plugins>
       </pluginManagement>
      </build>
      

      If i try to add it to the modules, the first time, maven complains that it can not download the plugin.
      If i remove the <extensions> tag, all works, but i need it

      1. MNG-1911.zip
        6 kB
        Brett Porter

        Issue Links

          Activity

          Hide
          John Casey added a comment -

          so, how is the pluginManagement item getting triggered? Do you have the plugin referenced in the main part of your build in the main POM or something?

          Show
          John Casey added a comment - so, how is the pluginManagement item getting triggered? Do you have the plugin referenced in the main part of your build in the main POM or something?
          Hide
          Brett Porter added a comment -

          The current Geronimo build has the same problem. Order of build doesn't matter - it just needs to be used somewhere as the extensions are pre-loaded.

          Workaround is to deploy a snapshot of the plugin so that Maven downloads the snapshot, uses that to load the extensions, builds the plugin, then reloads the new plugin when it is used.

          Show
          Brett Porter added a comment - The current Geronimo build has the same problem. Order of build doesn't matter - it just needs to be used somewhere as the extensions are pre-loaded. Workaround is to deploy a snapshot of the plugin so that Maven downloads the snapshot, uses that to load the extensions, builds the plugin, then reloads the new plugin when it is used.
          Hide
          Jason Dillon added a comment -

          Any status on when this will make it into a m2 release?

          Show
          Jason Dillon added a comment - Any status on when this will make it into a m2 release?
          Hide
          Jason van Zyl added a comment -

          John is this fixed now in trunk with your most recent build plan work?

          Show
          Jason van Zyl added a comment - John is this fixed now in trunk with your most recent build plan work?
          Hide
          John Casey added a comment -

          no, i haven't tested this use case with the new build plan. It may work, but I haven't tried yet.

          Show
          John Casey added a comment - no, i haven't tested this use case with the new build plan. It may work, but I haven't tried yet.
          Hide
          velo added a comment -

          Hi John,

          Do you have any news on that?

          Flex-mojos is suffering with this too.

          VELO

          Show
          velo added a comment - Hi John, Do you have any news on that? Flex-mojos is suffering with this too. VELO
          Hide
          Brett Porter added a comment -

          This actually works on Maven 2.2.1, but seems to have regressed in 3.0-SNAPSHOT. Attaching the test program (artifacts must not be in the local repository for failure to appear), as I do not currently have time for a full IT/investigation.

          Show
          Brett Porter added a comment - This actually works on Maven 2.2.1, but seems to have regressed in 3.0-SNAPSHOT. Attaching the test program (artifacts must not be in the local repository for failure to appear), as I do not currently have time for a full IT/investigation.
          Hide
          Benjamin Bentmann added a comment -

          Until we extend the POM to allow to distinguish between different types of extensions in order to tell which of them can loaded sometime later during the build, there is no path forward.

          Show
          Benjamin Bentmann added a comment - Until we extend the POM to allow to distinguish between different types of extensions in order to tell which of them can loaded sometime later during the build, there is no path forward.
          Hide
          Brett Porter added a comment -

          putting into 3.1 so that such an extension to the POM can be made so that this can be made to work again

          Show
          Brett Porter added a comment - putting into 3.1 so that such an extension to the POM can be made so that this can be made to work again
          Hide
          Brett Porter added a comment -

          I didn't investigate enough originally, and the attached IT isn't complete to test this. This wasn't fixed in 2.2.1 - it doesn't actually load the extension, as it never ended up in the effective POM. Maven 3 now does that, and attempts to load the extension, which is not built.

          The workaround to this, if suitable, is to use an older version of the plugin to use throughout the build.

          Show
          Brett Porter added a comment - I didn't investigate enough originally, and the attached IT isn't complete to test this. This wasn't fixed in 2.2.1 - it doesn't actually load the extension, as it never ended up in the effective POM. Maven 3 now does that, and attempts to load the extension, which is not built. The workaround to this, if suitable, is to use an older version of the plugin to use throughout the build.
          Hide
          Lars Corneliussen added a comment -

          Does anybody know what the concrete work would be to solve this issue? We struggle with this in NPanday...

          Show
          Lars Corneliussen added a comment - Does anybody know what the concrete work would be to solve this issue? We struggle with this in NPanday...
          Hide
          Vincent Massol added a comment -

          We really need this on the xwiki project too. Using an older version is not really a solution since when you make a change you need to use the latest version. We have some automated script to release XWiki which uses the maven release plugin and doing a 2 step release with the release plugin is really difficult (and probably impossible actually).

          Show
          Vincent Massol added a comment - We really need this on the xwiki project too. Using an older version is not really a solution since when you make a change you need to use the latest version. We have some automated script to release XWiki which uses the maven release plugin and doing a 2 step release with the release plugin is really difficult (and probably impossible actually).
          Hide
          Robert Munteanu added a comment -

          This also affects the Apache Sling build.

          Show
          Robert Munteanu added a comment - This also affects the Apache Sling build.
          Hide
          Jason van Zyl added a comment -

          Anyone else thought about this from the discussion on the mailing list? I would like to close this as won't fix.

          Show
          Jason van Zyl added a comment - Anyone else thought about this from the discussion on the mailing list? I would like to close this as won't fix.
          Hide
          Jason van Zyl added a comment -

          Trying to build plugins that have extensions that are to be used in the same build is just a complication in the core we're not going to accommodate. This is in part because extensions are ill defined and can be used for many things but trying to make extensions work generally where transport is provided is very difficult. If, in the future, we define different types of extensions some of these can likely be accommodated.

          Show
          Jason van Zyl added a comment - Trying to build plugins that have extensions that are to be used in the same build is just a complication in the core we're not going to accommodate. This is in part because extensions are ill defined and can be used for many things but trying to make extensions work generally where transport is provided is very difficult. If, in the future, we define different types of extensions some of these can likely be accommodated.
          Hide
          Paul Benedict added a comment -

          Removed specified fixed version.

          Show
          Paul Benedict added a comment - Removed specified fixed version.
          Hide
          Vincent Massol added a comment -

          Very disappointed that issues reported by users are just discarded without any plan to fix them This is not the first one I see like this. Closing invalid issues is ok but closing valid issues with a won't fix is not a good signal sent to users... Especially when no workaround is provided...

          Show
          Vincent Massol added a comment - Very disappointed that issues reported by users are just discarded without any plan to fix them This is not the first one I see like this. Closing invalid issues is ok but closing valid issues with a won't fix is not a good signal sent to users... Especially when no workaround is provided...
          Hide
          Arnaud HERITIER added a comment -

          The only existing workaround is to extract your extension (or the plugin defining it) in another independent project (which I agree, is often overkill).
          I don't know if jason lane and others who worked on the core recently have an idea how to fix it but the root cause of the problem is that an extension can extend an existing lifecycle or add a new one and thus Maven may require it to read poms).

          Show
          Arnaud HERITIER added a comment - The only existing workaround is to extract your extension (or the plugin defining it) in another independent project (which I agree, is often overkill). I don't know if jason lane and others who worked on the core recently have an idea how to fix it but the root cause of the problem is that an extension can extend an existing lifecycle or add a new one and thus Maven may require it to read poms).

            People

            • Assignee:
              Jason van Zyl
              Reporter:
              Guillaume Nodet
            • Votes:
              10 Vote for this issue
              Watchers:
              15 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development