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

["Luke Majewski (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IVY-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537639 ] 

Luke Majewski commented on IVY-633:
-----------------------------------

The POM for this is definitely correct.

http://cwiki.apache.org/FELIX/bundle-plugin-for-maven-bnd.html

However, the "real world" example they use of this POM does not specify the type, which is not required according to the XSD.  This will preclude using this element in determining the extension.

> 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 dependencies whose extension is not specified in the default manner.  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, however this should be explored.  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 plugins.  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.