Ivy
  1. Ivy
  2. IVY-899

POM packaging not always mapped to main artifact file extension correctly

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0.0-beta-2
    • Fix Version/s: None
    • Component/s: Maven Compatibility
    • Labels:
      None

      Description

      POM files contain a packaging element that Ivy attempts to map to an extension for the main artifact of the module in question. In 2.0.0beta2, it maps as follows:

      ejb->jar
      bundle->jar only for org.apache.felix#maven-bundle-plugin
      [other]->[other]

      That mapping is not sufficient to cover common POM files. For a start:

      1. maven-plugin is a standard packaging type, which should map to the extension jar.

      • e.g. Ivy erroneously searches for
        org.apache.axis2#axis2-ant-plugin;1.4.1!axis2-ant-plugin.maven-plugin
        rather than:
        org.apache.axis2#axis2-ant-plugin;1.4.1!axis2-ant-plugin.jar
        2. bundle seems to be used by various things, and is a jar in the cases I've seen:
        org.apache.geronimo.specs#geronimo-activation_1.1_spec;1.0.1!geronimo-activation_1.1_spec.bundle
        should be
        org.apache.geronimo.specs#geronimo-activation_1.1_spec;1.0.1!geronimo-activation_1.1_spec.jar

      Also, apparently POMs can have custom packaging which might need to map to some other arbitrary file extension, or possibly potentially to multiple files?

      The ideal solution is to provide customisable mapping of POM packaging to file extensions that can be specified somewhere in the Ivy settings (it is somewhat similar to namespaces).

      An interim solution is to change the mapping as follows:

      ejb->jar
      ejb[N]>jar?? e.g. ejb3>jar
      maven-plugin->jar
      bundle->jar if and only if .bundle does not exist but .jar does (it may not be easy to check for file existence in the relevant code - I'd be happy to always map bundle to jar, but others might not be - might be fine for an interim solution though?).
      [other]->[other]

      The interim solution could perhaps be done for 2.0 (it is only a few minutes work I think), though the properly customisable solution might take longer than that.

        Activity

        Hide
        Tom Widmer added a comment -

        The interim solution appears to work - I tried out trunk r693844 and the issues I had were resolved. The code now does:

        ejb->jar
        maven-plugin->jar
        bundle->jar
        [other]->[other]

        Show
        Tom Widmer added a comment - The interim solution appears to work - I tried out trunk r693844 and the issues I had were resolved. The code now does: ejb->jar maven-plugin->jar bundle->jar [other] -> [other]
        Hide
        Joachim Hofer added a comment -

        Another rather standard mapping that seems to be missing is:
        eclipse-plugin->jar

        I had the problem described in the bug with a dependency to the JaCoCo library, which is packaged as "eclipse-plugin" (for example: "org.jacoco" / "org.jacoco.core" / "0.5.3.201107060350").

        A fix would be greatly appreciated. Thanks!

        Show
        Joachim Hofer added a comment - Another rather standard mapping that seems to be missing is: eclipse-plugin->jar I had the problem described in the bug with a dependency to the JaCoCo library, which is packaged as "eclipse-plugin" (for example: "org.jacoco" / "org.jacoco.core" / "0.5.3.201107060350"). A fix would be greatly appreciated. Thanks!
        Hide
        Maarten Coene added a comment -

        elcipse-plugin->jar mapping has been added to SVN trunk.
        Could you give it a try?

        Show
        Maarten Coene added a comment - elcipse-plugin->jar mapping has been added to SVN trunk. Could you give it a try?
        Hide
        Jean-Louis Jouannic added a comment -

        I face exactly the same issue when I try to add a dependency to an Apache ServiceMix component in a grails project

        dependencies{
           runtime(group: 'org.apache.servicemix', name: 'servicemix-cxf-se', version: '2010.01')
        }
        

        The pom file associated with this artifact contains a jbi-component packaging element, but the resulting artifact is a jar file. Ivy erroneously searches for
        org.apache.servicemix#servicemix-cxf-se;2010.01!servicemix-cxf-se.jbi-component
        rather than
        org.apache.servicemix#servicemix-cxf-se;2010.01!servicemix-cxf-se.jar

        The following packaging->extension mappings should be also considered :

        • jbi-component -> jar
        • jbi-shared-library -> jar
        Show
        Jean-Louis Jouannic added a comment - I face exactly the same issue when I try to add a dependency to an Apache ServiceMix component in a grails project dependencies{ runtime(group: 'org.apache.servicemix', name: 'servicemix-cxf-se', version: '2010.01') } The pom file associated with this artifact contains a jbi-component packaging element, but the resulting artifact is a jar file. Ivy erroneously searches for org.apache.servicemix#servicemix-cxf-se;2010.01!servicemix-cxf-se.jbi-component rather than org.apache.servicemix#servicemix-cxf-se;2010.01!servicemix-cxf-se.jar The following packaging->extension mappings should be also considered : jbi-component -> jar jbi-shared-library -> jar
        Hide
        Maarten Coene added a comment -

        These extra mappings have been added to SVN trunk.

        Show
        Maarten Coene added a comment - These extra mappings have been added to SVN trunk.
        Hide
        Andreas Mandel added a comment -

        I can confirm that resolving the JaCoCo library (<dependency org="org.jacoco" name="org.jacoco.ant" rev="0.5.6.201201232323"/>) works fine with the latest snapshot build 2.2.x-local-20120123003859 - 20120123003859.

        Show
        Andreas Mandel added a comment - I can confirm that resolving the JaCoCo library ( <dependency org="org.jacoco" name="org.jacoco.ant" rev="0.5.6.201201232323"/> ) works fine with the latest snapshot build 2.2.x-local-20120123003859 - 20120123003859 .
        Hide
        Andre Ben Hamou added a comment -

        Further potential fallout from this issue?...

        https://jira.codehaus.org/browse/JETTY-1493

        Show
        Andre Ben Hamou added a comment - Further potential fallout from this issue?... https://jira.codehaus.org/browse/JETTY-1493
        Hide
        Martin Renner added a comment -

        Yes, it looks like it is not possible to download Jetty 7 with Ivy because Ivy doesn't handle "orbit" correctly.

        Show
        Martin Renner added a comment - Yes, it looks like it is not possible to download Jetty 7 with Ivy because Ivy doesn't handle "orbit" correctly.
        Hide
        Martin Renner added a comment -

        ivy.xml for downloading Jetty 7 and 8. Both fail:

            <dependencies>
                <dependency org="org.eclipse.jetty" name="jetty-server" rev="7.6.3.v20120416" conf="default->master,runtime" />
                <!--
                <dependency org="org.eclipse.jetty" name="jetty-server" rev="8.1.3.v20120416" conf="default->master,runtime" />
                -->
            </dependencies>
        
        Show
        Martin Renner added a comment - ivy.xml for downloading Jetty 7 and 8. Both fail: <dependencies> <dependency org= "org.eclipse.jetty" name= "jetty-server" rev= "7.6.3.v20120416" conf= " default ->master,runtime" /> <!-- <dependency org= "org.eclipse.jetty" name= "jetty-server" rev= "8.1.3.v20120416" conf= " default ->master,runtime" /> --> </dependencies>
        Hide
        Jon Reeve added a comment -

        It seems that the Jetty problem isn't really through any fault of Ivy, and more to do with Jetty abusing the packaging type and putting in some new unknown one when their end result is in fact a jar.

        At the moment it is possible to work around this if one goes through every jar that fails to download one at a time and adds an explicit dependency for it with an artifact element specified to map type="orbit" to ext="jar". But our project doesn't have a real direct dependency on that jar - it's indirect. If we add one it means we have to keep it up to date to match whatever one is pulled in by something else we do depend on - whenever we change the version of that dependency that depends on Jetty, there is a risk that all the orbit->jar fixing dependency entries are now pointing at the wrong versions.

        With that in mind, I think a feature to specify custom mappings would be incredibly useful, so users of Ivy would be able to quickly work around these simple cases with a mapping to tell Ivy that "orbit->jar", i.e. packaging type orbit should be considered as jar, for all dependencies. Would a patch for that be considered?

        Show
        Jon Reeve added a comment - It seems that the Jetty problem isn't really through any fault of Ivy, and more to do with Jetty abusing the packaging type and putting in some new unknown one when their end result is in fact a jar. At the moment it is possible to work around this if one goes through every jar that fails to download one at a time and adds an explicit dependency for it with an artifact element specified to map type="orbit" to ext="jar". But our project doesn't have a real direct dependency on that jar - it's indirect. If we add one it means we have to keep it up to date to match whatever one is pulled in by something else we do depend on - whenever we change the version of that dependency that depends on Jetty, there is a risk that all the orbit->jar fixing dependency entries are now pointing at the wrong versions. With that in mind, I think a feature to specify custom mappings would be incredibly useful, so users of Ivy would be able to quickly work around these simple cases with a mapping to tell Ivy that "orbit->jar", i.e. packaging type orbit should be considered as jar, for all dependencies. Would a patch for that be considered?
        Hide
        VTCiaccio added a comment -

        I am also affected by the Jetty 7 "orbit" packaging type as well, and resorted to hack work around mentioned above (i.e., adding an explicit dependency for each orbit artifact). As mentioned, this will break the build when the top level Jetty7 artifact is updated to a new version, as the orbit artifacts will not be updated. Given the growing list of packaging exceptions mentioned in this thread, I hope that a more general solution is found to be worthwhile (e.g., a feature to specify custom mappings of packaging->extension).

        Show
        VTCiaccio added a comment - I am also affected by the Jetty 7 "orbit" packaging type as well, and resorted to hack work around mentioned above (i.e., adding an explicit dependency for each orbit artifact). As mentioned, this will break the build when the top level Jetty7 artifact is updated to a new version, as the orbit artifacts will not be updated. Given the growing list of packaging exceptions mentioned in this thread, I hope that a more general solution is found to be worthwhile (e.g., a feature to specify custom mappings of packaging->extension).
        Hide
        Matthias Mann added a comment -

        I want to use ivy for resloving dependencies of php application. It is possible to include pear packages provided by the php-maven.org project. Php-maven publishes most pear packagen in a maven2 repository. The pear packages are packaged as phar files but the pom packaging type is pear. So mapping pear -> phar is required to retrive all needed dependencies.

        Show
        Matthias Mann added a comment - I want to use ivy for resloving dependencies of php application. It is possible to include pear packages provided by the php-maven.org project. Php-maven publishes most pear packagen in a maven2 repository. The pear packages are packaged as phar files but the pom packaging type is pear. So mapping pear -> phar is required to retrive all needed dependencies.
        Hide
        Maarten Coene added a comment -

        Mapping for 'orbit' and 'pear' has been added.
        Patches for a more general solution are always welcome

        Show
        Maarten Coene added a comment - Mapping for 'orbit' and 'pear' has been added. Patches for a more general solution are always welcome

          People

          • Assignee:
            Unassigned
            Reporter:
            Tom Widmer
          • Votes:
            8 Vote for this issue
            Watchers:
            13 Start watching this issue

            Dates

            • Created:
              Updated:

              Development