You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by "Moritz Baumann (Jira)" <ji...@apache.org> on 2024/02/12 16:27:00 UTC

[jira] [Created] (IVY-1650) Caching is broken when using custom attributes from the http://ant.apache.org/ivy/extra namespace

Moritz Baumann created IVY-1650:
-----------------------------------

             Summary: Caching is broken when using custom attributes from the http://ant.apache.org/ivy/extra namespace
                 Key: IVY-1650
                 URL: https://issues.apache.org/jira/browse/IVY-1650
             Project: Ivy
          Issue Type: Bug
    Affects Versions: 2.5.2
            Reporter: Moritz Baumann


This bug is similar to IVY-1649.

I'm trying to use Ivy as a standalone tool from a custom build system. While most of the artifacts I want to download are located in Maven repositories, I also need to download some npm artifacts. To avoid having to invoke npm just for those few artifacts, I defined a url resolver for npm artifacts, similar to the following:
{code:xml}
<ivysettings>
    <resolvers>
        <ibiblio name="maven2" m2compatible="true" root="https://repo1.maven.org/maven2/"/>
        <url name="npm">
            <artifact pattern="https://registry.npmjs.org/([organisation]/)[module]/-/[artifact]-[revision].[ext]"/>
        </url>
    </resolvers>
    <settings defaultResolver="maven2"/>
    <modules>
        <module repotype="npm" resolver="npm"/>
    </modules>
</ivysettings>
{code}
For npm artifacts, I specify the custom repotype attribute to make sure the correct resolver is chosen:
{code:xml}
<ivy-module version="2.0"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:noNamespaceSchemaLocation="http://ant.apache.org/ivy/schemas/ivy.xsd"
            xmlns:e="http://ant.apache.org/ivy/extra">
    <info module="demo" organisation="mb-sc"/>
    <dependencies>
        <dependency org="@cap-js" name="cds-types" rev="0.2.0" e:repotype="npm">
            <artifact name="cds-types" type="tgz"/>
        </dependency>
    </dependencies>
</ivy-module>
{code}
Like in IVY-1649, the first execution of ivy looks okay, but subsequent invocations still access the repository:
{noformat}
❯ java -jar apache-ivy-2.5.2/ivy-2.5.2.jar -settings ivysettings.xml
:: loading settings :: file = /home/mb-sc/ivy-test/ivysettings.xml
:: resolving dependencies :: mb-sc#demo;working@W-GNV1FB3
        confs: [default]
        found @cap-js#cds-types;0.2.0 in npm
downloading https://registry.npmjs.org/@cap-js/cds-types/-/cds-types-0.2.0.tgz ...
.................. (22kB)
        [SUCCESSFUL ] @cap-js#cds-types;0.2.0!cds-types.tgz (444ms)
:: resolution report :: resolve 1132ms :: artifacts dl 447ms
        ---------------------------------------------------------------------
        |                  |            modules            ||   artifacts   |
        |       conf       | number| search|dwnlded|evicted|| number|dwnlded|
        ---------------------------------------------------------------------
        |      default     |   1   |   1   |   0   |   0   ||   1   |   1   |
        ---------------------------------------------------------------------
❯ java -jar apache-ivy-2.5.2/ivy-2.5.2.jar -settings ivysettings.xml
:: loading settings :: file = /home/mb-sc/ivy-test/ivysettings.xml
:: resolving dependencies :: mb-sc#demo;working@W-GNV1FB3
        confs: [default]
        found @cap-js#cds-types;0.2.0 in npm
:: resolution report :: resolve 423ms :: artifacts dl 2ms
        ---------------------------------------------------------------------
        |                  |            modules            ||   artifacts   |
        |       conf       | number| search|dwnlded|evicted|| number|dwnlded|
        ---------------------------------------------------------------------
        |      default     |   1   |   1   |   0   |   0   ||   1   |   0   |
        ---------------------------------------------------------------------
{noformat}
Offline builds fail even with a populated cache. The root cause is very similar to the one in IVY-1649:
{noformat}
❯ java -jar apache-ivy-2.5.2/ivy-2.5.2.jar -settings ivysettings.xml -debug
[…]
No entry is found in the ModuleDescriptorCache : /home/mb-sc/.ivy2/cache/@cap-js/cds-types/ivy-0.2.0.xml
post 1.3 ivy file: using exact as default matcher
        problem while parsing cached ivy file for: @cap-js#cds-types;0.2.0 (java.text.ParseException: [[Fatal Error] ivy-0.2.0.xml:10:4: The prefix "e" for attribute "e:repotype" associated with an element type "info" is not bound. in file:/home/mb-sc/.ivy2/cache/@cap-js/cds-types/ivy-0.2.0.xml
])
java.text.ParseException: [[Fatal Error] ivy-0.2.0.xml:10:4: The prefix "e" for attribute "e:repotype" associated with an element type "info" is not bound. in file:/home/mb-sc/.ivy2/cache/@cap-js/cds-types/ivy-0.2.0.xml
]
        at org.apache.ivy.plugins.parser.AbstractModuleDescriptorParser$AbstractParser.checkErrors(AbstractModuleDescriptorParser.java:90)
        at org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.parse(XmlModuleDescriptorParser.java:337)
        at org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser.parseDescriptor(XmlModuleDescriptorParser.java:128)
        at org.apache.ivy.plugins.parser.AbstractModuleDescriptorParser.parseDescriptor(AbstractModuleDescriptorParser.java:50)
        at org.apache.ivy.core.cache.DefaultRepositoryCacheManager$MyModuleDescriptorProvider.provideModule(DefaultRepositoryCacheManager.java:846)
        at org.apache.ivy.core.cache.ModuleDescriptorMemoryCache.getStale(ModuleDescriptorMemoryCache.java:68)
        at org.apache.ivy.core.cache.ModuleDescriptorMemoryCache.get(ModuleDescriptorMemoryCache.java:57)
        at org.apache.ivy.core.cache.DefaultRepositoryCacheManager.getMdFromCache(DefaultRepositoryCacheManager.java:854)
        at org.apache.ivy.core.cache.DefaultRepositoryCacheManager.doFindModuleInCache(DefaultRepositoryCacheManager.java:756)
        at org.apache.ivy.core.cache.DefaultRepositoryCacheManager.findModuleInCache(DefaultRepositoryCacheManager.java:715)
        at org.apache.ivy.plugins.resolver.AbstractResolver.findModuleInCache(AbstractResolver.java:369)
        at org.apache.ivy.plugins.resolver.AbstractResolver.findModuleInCache(AbstractResolver.java:364)
        at org.apache.ivy.plugins.resolver.BasicResolver.getDependency(BasicResolver.java:211)
        at org.apache.ivy.core.resolve.IvyNode.loadData(IvyNode.java:192)
        at org.apache.ivy.core.resolve.VisitNode.loadData(VisitNode.java:284)
        at org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:722)
        at org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:801)
        at org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:729)
        at org.apache.ivy.core.resolve.ResolveEngine.getDependencies(ResolveEngine.java:607)
        at org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:250)
        at org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:206)
        at org.apache.ivy.Ivy.resolve(Ivy.java:507)
        at org.apache.ivy.Main.run(Main.java:363)
        at org.apache.ivy.Main.run(Main.java:284)
        at org.apache.ivy.Main.main(Main.java:233)
[…]
{noformat}
Fortunately, there is an ugly workaround: If I declare the [http://ant.apache.org/ivy/extra] namespace locally for each dependency, the cache works as expected:
{code:xml}
<ivy-module version="2.0"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:noNamespaceSchemaLocation="http://ant.apache.org/ivy/schemas/ivy.xsd">
    <info module="demo" organisation="mb-sc"/>
    <dependencies>
        <dependency org="@cap-js" name="cds-types" rev="0.2.0" xmlns:e="http://ant.apache.org/ivy/extra" e:repotype="npm">
            <artifact name="cds-types" type="tgz"/>
        </dependency>
    </dependencies>
</ivy-module>
{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)