[
https://issues.apache.org/jira/browse/IVY-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luke Majewski updated IVY-633:
------------------------------
Description:
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
<code>jar</code>. 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 <code>jar</code>,
<code>war</code>, <code>ejb-client</code> and
<code>test-jar</code>.
New types can be defined by plugins that set
<code>extensions</code> to
<code>true</code>, 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.
was:
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
<code>jar</code>. 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 <code>jar</code>,
<code>war</code>, <code>ejb-client</code> and
<code>test-jar</code>.
New types can be defined by plugins that set
<code>extensions</code> to
<code>true</code>, 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.
> 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
> <code>jar</code>. 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 <code>jar</code>,
> <code>war</code>, <code>ejb-client</code> and
> <code>test-jar</code>.
> New types can be defined by plugins that set
> <code>extensions</code> to
> <code>true</code>, 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.
