You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Tom Widmer <to...@googlemail.com> on 2008/09/09 14:32:25 UTC

POM packaging problems

I'm trying to install Axis2 and all its dependencies into my company IVY 
repo from public maven repos. I'm now down to just a few errors, all 
relating to the packaging element in the POM not matching the file 
extension of the main artifact. For example:

<packaging>maven-plugin</packaging>
and
<packaging>bundle</packaging>

is actually a .jar in each case. I notice that trunk has attempted to 
fix this for bundles with this hack in 
PomModuleDescriptorBuilder.getMainArtifact:

	String ext;
         if ("pom".equals(packaging)) {
             // no artifact defined!
             return;
         } else if ("ejb".equals(packaging)) {
             ext = "jar";
         } else {
             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) it.next();
                 if ("org.apache.felix".equals(plugin.getGroupId())
                         && 
"maven-bundle-plugin".equals(plugin.getArtifactId())) {
                     ext = "jar";
                     break;
                 }
             }
         }


That fixes the problem for a grand total of one case, which isn't the 
case I have a problem with (my problems are in:
WARN: 	:: 
org.apache.axis2#axis2-ant-plugin;1.4.1!axis2-ant-plugin.maven-plugin
WARN: 	:: 
org.apache.geronimo.specs#geronimo-activation_1.1_spec;1.0.1!geronimo-activation_1.1_spec.bundle
WARN: 	:: 
org.apache.geronimo.specs#geronimo-javamail_1.4_spec;1.2!geronimo-javamail_1.4_spec.bundle
WARN: 	:: 
org.apache.geronimo.specs#geronimo-stax-api_1.0_spec;1.0.1!geronimo-stax-api_1.0_spec.bundle
)

The TODO is therefore pretty urgent for me and anyone else wanting to 
use Axis2 (or any of the above). I think a better fix than the current 
hack would be perhaps to check for the existence of the artifact in the 
repo (e.g. .bundle or .maven-plugin), and if that fails, fall back to 
.jar. Or even have a mapping for fall back extensions (e.g. bundle and 
maven-plugin fall back to jar, other types might have other fallbacks). 
According to the maven docs, these are the standard types:
pom, jar, maven-plugin, ejb, war, ear, rar, par

Of those, presumably maven-plugin and ejb both have .jar extensions (the 
code already handles ejb, adding maven-plugin is trivial).

Perhaps there should be a way of configuring these kinds of 
transformations in the ivy settings, maybe as an extension to namespaces 
(allow type and extension mappings, etc.).

Anyway, I could try to find some time to do a patch of some kind (the 
maven-plugin patch is obviously trivial, adding better support for 
<packaging>bundle</packaging> is trickier), but someone already set up 
with commit access could obviously do this much more quickly...

Tom


Re: POM packaging problems

Posted by Xavier Hanin <xa...@gmail.com>.
On Tue, Sep 9, 2008 at 2:32 PM, Tom Widmer <to...@googlemail.com>wrote:

> I'm trying to install Axis2 and all its dependencies into my company IVY
> repo from public maven repos. I'm now down to just a few errors, all
> relating to the packaging element in the POM not matching the file extension
> of the main artifact. For example:
>
> <packaging>maven-plugin</packaging>
> and
> <packaging>bundle</packaging>
>
> is actually a .jar in each case. I notice that trunk has attempted to fix
> this for bundles with this hack in
> PomModuleDescriptorBuilder.getMainArtifact:
>
>        String ext;
>        if ("pom".equals(packaging)) {
>            // no artifact defined!
>            return;
>        } else if ("ejb".equals(packaging)) {
>            ext = "jar";
>        } else {
>            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) it.next();
>                if ("org.apache.felix".equals(plugin.getGroupId())
>                        &&
> "maven-bundle-plugin".equals(plugin.getArtifactId())) {
>                    ext = "jar";
>                    break;
>                }
>            }
>        }
>
>
> That fixes the problem for a grand total of one case, which isn't the case
> I have a problem with (my problems are in:
> WARN:   ::
> org.apache.axis2#axis2-ant-plugin;1.4.1!axis2-ant-plugin.maven-plugin
> WARN:   ::
> org.apache.geronimo.specs#geronimo-activation_1.1_spec;1.0.1!geronimo-activation_1.1_spec.bundle
> WARN:   ::
> org.apache.geronimo.specs#geronimo-javamail_1.4_spec;1.2!geronimo-javamail_1.4_spec.bundle
> WARN:   ::
> org.apache.geronimo.specs#geronimo-stax-api_1.0_spec;1.0.1!geronimo-stax-api_1.0_spec.bundle
> )
>
> The TODO is therefore pretty urgent for me and anyone else wanting to use
> Axis2 (or any of the above). I think a better fix than the current hack
> would be perhaps to check for the existence of the artifact in the repo
> (e.g. .bundle or .maven-plugin), and if that fails, fall back to .jar. Or
> even have a mapping for fall back extensions (e.g. bundle and maven-plugin
> fall back to jar, other types might have other fallbacks). According to the
> maven docs, these are the standard types:
> pom, jar, maven-plugin, ejb, war, ear, rar, par
>
> Of those, presumably maven-plugin and ejb both have .jar extensions (the
> code already handles ejb, adding maven-plugin is trivial).
>
> Perhaps there should be a way of configuring these kinds of transformations
> in the ivy settings, maybe as an extension to namespaces (allow type and
> extension mappings, etc.).
>
> Anyway, I could try to find some time to do a patch of some kind (the
> maven-plugin patch is obviously trivial, adding better support for
> <packaging>bundle</packaging> is trickier), but someone already set up with
> commit access could obviously do this much more quickly...
>
Could you please open an issue in JIRA? I agree that the packaging to ext
mapping is still weak in Ivy, this really need to be improved. The problem
is that AFAIU maven plugins can contribute new packaging with different
extensions, so it's pretty difficult to address all cases. Maybe something
configurable in the settings (mapping packaging to ext) as you suggest would
be the best solution. But this requires more time to implement, test and
document.

Xavier


> Tom
>
>


-- 
Xavier Hanin - Independent Java Consultant
BordeauxJUG co leader - http://www.bordeauxjug.org/
Blogger - http://xhab.blogspot.com/
Apache Ivy Creator - http://ant.apache.org/ivy/

Re: POM packaging problems

Posted by Xavier Hanin <xa...@gmail.com>.
On Tue, Sep 9, 2008 at 5:19 PM, Tom Widmer <to...@googlemail.com>wrote:

> Xavier Hanin wrote:
>
>> Could you please open an issue in JIRA? I agree that the packaging to ext
>> mapping is still weak in Ivy, this really need to be improved. The problem
>> is that AFAIU maven plugins can contribute new packaging with different
>> extensions, so it's pretty difficult to address all cases. Maybe something
>> configurable in the settings (mapping packaging to ext) as you suggest
>> would
>> be the best solution. But this requires more time to implement, test and
>> document.
>>
>
> https://issues.apache.org/jira/browse/IVY-899
>
> Can anything be done in time for 2.0? Or is 2.0RC1 about to happen?

I've just checked in a quick fix for this, now Ivy will use jar ext for
maven-plugin and bundle packaging (I don't think using 'bundle' ext make any
sense anyway). I let IVY-899 open because this is something that still need
to be improved.

Could you let me know if current trunk works for you?

Xavier



>
> Thanks,
>
> Tom
>
>


-- 
Xavier Hanin - Independent Java Consultant
BordeauxJUG co leader - http://www.bordeauxjug.org/
Blogger - http://xhab.blogspot.com/
Apache Ivy Creator - http://ant.apache.org/ivy/

Re: POM packaging problems

Posted by Tom Widmer <to...@googlemail.com>.
Xavier Hanin wrote:
> On Tue, Sep 9, 2008 at 5:19 PM, Tom Widmer <to...@googlemail.com>wrote:
> 
>> Xavier Hanin wrote:
>>
>>> Could you please open an issue in JIRA? I agree that the packaging to ext
>>> mapping is still weak in Ivy, this really need to be improved. The problem
>>> is that AFAIU maven plugins can contribute new packaging with different
>>> extensions, so it's pretty difficult to address all cases. Maybe something
>>> configurable in the settings (mapping packaging to ext) as you suggest
>>> would
>>> be the best solution. But this requires more time to implement, test and
>>> document.
>>>
>> https://issues.apache.org/jira/browse/IVY-899
>>
>> Can anything be done in time for 2.0? Or is 2.0RC1 about to happen?
> 
> I've just checked in a quick fix for this, now Ivy will use jar ext for
> maven-plugin and bundle packaging (I don't think using 'bundle' ext make any
> sense anyway). I let IVY-899 open because this is something that still need
> to be improved.
> 
> Could you let me know if current trunk works for you?
> 
> Xavier

I should be able to check it on Thursday if not tomorrow.

Thanks very much,

Tom


Re: POM packaging problems

Posted by Tom Widmer <to...@googlemail.com>.
Xavier Hanin wrote:
> Could you please open an issue in JIRA? I agree that the packaging to ext
> mapping is still weak in Ivy, this really need to be improved. The problem
> is that AFAIU maven plugins can contribute new packaging with different
> extensions, so it's pretty difficult to address all cases. Maybe something
> configurable in the settings (mapping packaging to ext) as you suggest would
> be the best solution. But this requires more time to implement, test and
> document.

https://issues.apache.org/jira/browse/IVY-899

Can anything be done in time for 2.0? Or is 2.0RC1 about to happen?

Thanks,

Tom