ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett Randall (JIRA)" <>
Subject [jira] [Commented] (IVY-633) Packaging Data Parsed Incorrectly in Maven 2 POM
Date Fri, 25 Sep 2015 07:36:04 GMT


Brett Randall commented on IVY-633:

This issue should be reopened, or a new issue created.  Justification for reopening:

* This tripped me up in Ivy 2.4.0, and one other person before me since this was resolved.
* Maarten originally identified his fix as quick/incomplete and suggested the issue remain

The original/quick-fix was:

commit 291a576a53a0c1b4e9c3ec7c75d3a548d09847a3
Author: Maarten Coene <>
Date:   Sun May 18 22:25:23 2008 +0000

    Added quick-fix for IVY-633. I think it will solve most of the packaging problems, but
we should work on a better solution.
    git-svn-id: 13f79535-47bb-0310-9956-ffa450edef68

The key code-change is:

     public void addArtifact(String artifactId, String packaging) {
        String ext = packaging;

        // TODO: we should refactor the following code into something more configurable

        // if 'packaging == bundle' and if we use the 'maven-bundle-plugin', the
        // type must be 'jar'
        if ("bundle".equals(packaging)) {
            for (Iterator it = getPlugins(ivyModuleDescriptor).iterator(); it.hasNext();)
                PomDependencyMgt plugin = (PomDependencyMgt);
                if ("org.apache.felix".equals(plugin.getGroupId())
                        && "maven-bundle-plugin".equals(plugin.getArtifaceId())) {
                    ext = "jar";

So if the packaging is {{bundle}}, and the POM contains the exact plugin {{org.apache.felix:maven-bundle-plugin}},
then the extension is flipped to {{jar}}.

My concern is whether the entire POM hierarchy, from child-POM to parent to oldest-grandparent
is being traversed when making this assessment - it seems not.  Probably only the artifact's
own POM is inspected?  It would be very common to put this plugin into a parent POM.

Two artifacts that have "bundle" packaging and are not resolved properly:

In {{com.fasterxml.jackson.core:jackson-databind:2.5.3}}, the bundle plugin is declared in
the grandparent POM,

In {{org.apache.pdfbox:pdfbox:1.8.2}}, the bundle plugin is declared in the parent POM.


For me, I think I am able to get around this my specifying {{type="jar,bundle"}} instead of
{{type="jar"}} in my {{<ivy:retrieve>}}, but this may have drawbacks that I haven't
noticed yet.

> Packaging Data Parsed Incorrectly in Maven 2 POM
> ------------------------------------------------
>                 Key: IVY-633
>                 URL:
>             Project: Ivy
>          Issue Type: Bug
>          Components: Maven Compatibility
>    Affects Versions: 2.0.0-alpha-2
>            Reporter: Luke Majewski
>            Assignee: Maarten Coene
>             Fix For: 2.0-RC1
> 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]
> 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.

This message was sent by Atlassian JIRA

View raw message