[jira] Created: (IVY-633) Packaging Data Parsed Incorrectly in Maven 2 POM

[Luke Majewski (JIRA)]

Packaging Data Parsed Incorrectly in Maven 2 POM
------------------------------------------------

                 Key: IVY-633
                 URL: https://issues.apache.org/jira/browse/IVY-633
             Project: Ivy
          Issue Type: Bug
          Components: Core
    Affects Versions: 2.0.0-alpha-2
            Reporter: Luke Majewski


There is still an issue with some non-JAR dependencies.  The example case is 
when trying to fetch some camel JARs.

When trying to get the camel-script-1.2.0 JAR, you see:

[ivy:retrieve]  ==== public: tried
[ivy:retrieve]    
http://repo1.maven.org/maven2/org/apache/camel/camel-script/1.2.0/camel-script-1.2.0.bundle

Ivy is trying to use the extension "bundle" and not JAR.  This is due to the 
code fetching the extension from the <packaging> element of the POM.  The 
relevant portion of the POM is here:

<parent>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-parent</artifactId>
     <version>1.2.0</version>
</parent>
<artifactId>camel-script</artifactId>
<packaging>bundle</packaging>
<name>Camel :: Script</name>
<description>Camel Script support</description>

Notice the <packaging>bundle</packaging>.  Looking at the POM XSD, it seems 
like this is a valid POM.  The other thing that might help to resolve this 
issue is to look at the <type> element.  The XSD contains this:

      <xs:element name="type" minOccurs="0" type="xs:string" default="jar">
        <xs:annotation>
          <xs:documentation source="version">4.0.0</xs:documentation>
          <xs:documentation source="description">
            The type of dependency. This defaults to 
&lt;code&gt;jar&lt;/code&gt;. While it usually represents the extension on
            the filename of the dependency, that is not always the case. A type 
can be mapped to a different
            extension and a classifier.
            The type often correspongs to the packaging used, though this is 
also not always the case.
            Some examples are &lt;code&gt;jar&lt;/code&gt;, 
&lt;code&gt;war&lt;/code&gt;, &lt;code&gt;ejb-client&lt;/code&gt; and 
&lt;code&gt;test-jar&lt;/code&gt;.
            New types can be defined by plugins that set
            &lt;code&gt;extensions&lt;/code&gt; to 
&lt;code&gt;true&lt;/code&gt;, so this is not a complete list.
          </xs:documentation>
        </xs:annotation>
      </xs:element>

Here we see that there can be different types, such as jar, war, ejb-client, 
test-jar and others defined by the plugin.  The solution to this issue is 
probably contained in correctly determining the extension type from here. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.