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 t4rockets <t4...@gmail.com> on 2018/08/13 14:51:20 UTC
retrieve fails to download updated/replaced JAR from a filesystem resolver
Using the dependence example, it has been updated so that build time (new
and equal to now via <tstamp> task) and version number properties are
written to the dependee version file. The dependee Java code was also
updated to print the build time and version number. The Java code was
update to see what build time property was in the downloaded JAR.
The issue seen is that if the dependee JAR is updated/replaced (compiled
again with a new build time property) but no version change using the
publish overwrite="true" option, the depender Ivy retrieve will not
downloaded the updated JAR (same version, different build time and
therefore a different check sum). It appears that Ivy knows there is an
update based on the debug information, but the download does not happen.
The filesystem repository is being used to support local build so that
developer can build and test the code changes locally without a repository
manager (i.e, Nexus).
If the version number is updated, the depender Ivy retrieve will download
the updated dependee JAR as expected.
This issue has been recreated against 2.4.0 and 2.5.0-rc1 and show both the
same behavior.
Code added to the dependee "jar" target using the ant-contrib if task
<tstamp>
<format property="build.time" pattern="dd-MMMM-yyyy+HH:mm:ss"/>
</tstamp>
<propertyfile file="${classes.dir}/version.properties">
<entry key="build.time" value="${build.time}"/>
</propertyfile>
<ac:if>
<equals arg1="${option.include.version}" arg2="true"/>
<ac:then>
<propertyfile file="${classes.dir}/version.properties">
<entry key="version" type="int" operation="+" default="0"/>
</propertyfile>
</ac:then>
</ac:if>
Code update for the Main.java source code:
String buildTime = p.getProperty("build.time");
if (version != null && buildTime != null ) {
return version + "-" + buildTime;
}
The sequence of events to create:
- cd dependence
- ant
- ant all
- Note the build time and version from the depender task
- cd dependee
- ant publish
- ant publish
- Note the new build time and version for each publish
- cd ../depender
- ant
- Note the build time and version for the run task (should be the
same as the last dependee publish task)
- cd ../dependee
- ant publish -Doption.include.version=false
- ant publish -Doption.include.version=false
- Note the new build time and but the version did not update
- cd ../depender
- ant
- Note the build time does not match the latest dependee JAR (updated
build time, same version). The build time is from the JAR the last time
the version was updated.
Several options have been tried on the depender ivy:resolve task without
success. Is there some way to get the retrieve to download the updated
dependee JAR when it is only updated/replaced (no new version)?
Thanks,
Re: retrieve fails to download updated/replaced JAR from a filesystem resolver
Posted by t4rockets <t4...@gmail.com>.
Here is the entire stacktrace. Based on a little bit of research, this
exception might occur if the URL does not have a protocol prefixed to the
filename (i.e., file:...) and on the Linux this would match the signature
(no protocol) where on window "c:..." would be interpreted as a "c"
protocol as the exception mentions.
[ivy:retrieve] java.net.MalformedURLException: unknown protocol: c
[ivy:retrieve] at java.net.URL.<init>(URL.java:593)
[ivy:retrieve] at java.net.URL.<init>(URL.java:483)
[ivy:retrieve] at java.net.URL.<init>(URL.java:432)
[ivy:retrieve] at
org.apache.ivy.core.cache.DefaultRepositoryCacheManager.getSavedArtifactOrigin(DefaultRepositoryCacheManager.java:542)
[ivy:retrieve] at
org.apache.ivy.core.cache.DefaultRepositoryCacheManager.getArchiveFileInCache(DefaultRepositoryCacheManager.java:371)
[ivy:retrieve] at
org.apache.ivy.core.cache.DefaultRepositoryCacheManager.originalToCachedModuleDescriptor(DefaultRepositoryCacheManager.java:1244)
[ivy:retrieve] at
org.apache.ivy.plugins.resolver.BasicResolver.cacheModuleDescriptor(BasicResolver.java:369)
[ivy:retrieve] at
org.apache.ivy.plugins.resolver.BasicResolver.getDependency(BasicResolver.java:315)
[ivy:retrieve] at
org.apache.ivy.core.resolve.IvyNode.loadData(IvyNode.java:183)
[ivy:retrieve] at
org.apache.ivy.core.resolve.VisitNode.loadData(VisitNode.java:284)
[ivy:retrieve] at
org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:724)
[ivy:retrieve] at
org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:803)
[ivy:retrieve] at
org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:731)
[ivy:retrieve] at
org.apache.ivy.core.resolve.ResolveEngine.getDependencies(ResolveEngine.java:608)
[ivy:retrieve] at
org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:252)
[ivy:retrieve] at
org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:208)
[ivy:retrieve] at org.apache.ivy.Ivy.resolve(Ivy.java:507)
[ivy:retrieve] at
org.apache.ivy.ant.IvyResolve.doExecute(IvyResolve.java:328)
[ivy:retrieve] at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:259)
[ivy:retrieve] at
org.apache.ivy.ant.IvyPostResolveTask.ensureResolved(IvyPostResolveTask.java:229)
[ivy:retrieve] at
org.apache.ivy.ant.IvyPostResolveTask.prepareAndCheck(IvyPostResolveTask.java:183)
[ivy:retrieve] at
org.apache.ivy.ant.IvyRetrieve.doExecute(IvyRetrieve.java:92)
[ivy:retrieve] at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:259)
[ivy:retrieve] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
[ivy:retrieve] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown
Source)
[ivy:retrieve] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ivy:retrieve] at java.lang.reflect.Method.invoke(Method.java:497)
[ivy:retrieve] at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
[ivy:retrieve] at org.apache.tools.ant.Task.perform(Task.java:350)
[ivy:retrieve] at org.apache.tools.ant.Target.execute(Target.java:449)
[ivy:retrieve] at
org.apache.tools.ant.Target.performTasks(Target.java:470)
[ivy:retrieve] at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1388)
[ivy:retrieve] at
org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:36)
[ivy:retrieve] at
org.apache.tools.ant.Project.executeTargets(Project.java:1251)
[ivy:retrieve] at
org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:437)
[ivy:retrieve] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
[ivy:retrieve] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown
Source)
[ivy:retrieve] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ivy:retrieve] at java.lang.reflect.Method.invoke(Method.java:497)
[ivy:retrieve] at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
[ivy:retrieve] at org.apache.tools.ant.Task.perform(Task.java:350)
[ivy:retrieve] at org.apache.tools.ant.Target.execute(Target.java:449)
[ivy:retrieve] at
org.apache.tools.ant.Target.performTasks(Target.java:470)
[ivy:retrieve] at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1388)
[ivy:retrieve] at
org.apache.tools.ant.Project.executeTarget(Project.java:1361)
[ivy:retrieve] at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
[ivy:retrieve] at
org.apache.tools.ant.Project.executeTargets(Project.java:1251)
[ivy:retrieve] at org.apache.tools.ant.Main.runBuild(Main.java:834)
[ivy:retrieve] at org.apache.tools.ant.Main.startAnt(Main.java:223)
[ivy:retrieve] at
org.apache.tools.ant.launch.Launcher.run(Launcher.java:284)
[ivy:retrieve] at
org.apache.tools.ant.launch.Launcher.main(Launcher.java:101)
On Tue, Aug 14, 2018 at 10:30 PM, Jaikiran Pai <ja...@apache.org> wrote:
> Hi t4rockets,
>
>
> On 14/08/18 8:46 PM, t4rockets wrote:
> > The issue with downloading a replaced artifact in a filesystem repository
> > was solved using the "changing=true" attribute in the Ivy file for
> dependee
> > dependency. However, the MalformedURLException is still happening.
> >
> > On Mon, Aug 13, 2018 at 10:54 AM, t4rockets <t4...@gmail.com> wrote:
> >
> >> In debug mode, the following exception during the retrieved was observed
> >> when trying to read the Ivy.xml file:
> >>
> >> [ivy:retrieve] java.net.MalformedURLException: unknown protocol:
> windows
> >> message is "c" or Linux message is "cache path/ivy-[version].xml
> >> [ivy:retrieve] at java.net.URL.<init>(URL.java:593)
>
>
> Is that the exact exception stacktrace and message?
>
> -Jaikiran
>
Re: retrieve fails to download updated/replaced JAR from a filesystem
resolver
Posted by Jaikiran Pai <ja...@apache.org>.
Hi t4rockets,
On 14/08/18 8:46 PM, t4rockets wrote:
> The issue with downloading a replaced artifact in a filesystem repository
> was solved using the "changing=true" attribute in the Ivy file for dependee
> dependency. However, the MalformedURLException is still happening.
>
> On Mon, Aug 13, 2018 at 10:54 AM, t4rockets <t4...@gmail.com> wrote:
>
>> In debug mode, the following exception during the retrieved was observed
>> when trying to read the Ivy.xml file:
>>
>> [ivy:retrieve] java.net.MalformedURLException: unknown protocol: windows
>> message is "c" or Linux message is "cache path/ivy-[version].xml
>> [ivy:retrieve] at java.net.URL.<init>(URL.java:593)
Is that the exact exception stacktrace and message?
-Jaikiran
Re: retrieve fails to download updated/replaced JAR from a filesystem resolver
Posted by t4rockets <t4...@gmail.com>.
The issue with downloading a replaced artifact in a filesystem repository
was solved using the "changing=true" attribute in the Ivy file for dependee
dependency. However, the MalformedURLException is still happening.
On Mon, Aug 13, 2018 at 10:54 AM, t4rockets <t4...@gmail.com> wrote:
> In debug mode, the following exception during the retrieved was observed
> when trying to read the Ivy.xml file:
>
> [ivy:retrieve] java.net.MalformedURLException: unknown protocol: windows
> message is "c" or Linux message is "cache path/ivy-[version].xml
> [ivy:retrieve] at java.net.URL.<init>(URL.java:593)
> [ivy:retrieve] at java.net.URL.<init>(URL.java:483)
> [ivy:retrieve] at java.net.URL.<init>(URL.java:432)
> [ivy:retrieve] at org.apache.ivy.core.cache.
> DefaultRepositoryCacheManager.getSavedArtifactOrigin(
> DefaultRepositoryCacheManager.java:542)
> [ivy:retrieve] at org.apache.ivy.core.cache.
> DefaultRepositoryCacheManager.doFindModuleInCache(
> DefaultRepositoryCacheManager.java:779)
> [ivy:retrieve] at org.apache.ivy.core.cache.
> DefaultRepositoryCacheManager.cacheModuleDescriptor(
> DefaultRepositoryCacheManager.java:1310)
> [ivy:retrieve] at org.apache.ivy.plugins.resolver.BasicResolver.parse(
> BasicResolver.java:541)
> [ivy:retrieve] at org.apache.ivy.plugins.resolver.BasicResolver.
> getDependency(BasicResolver.java:278)
> [ivy:retrieve] at org.apache.ivy.core.resolve.
> IvyNode.loadData(IvyNode.java:183)
> [ivy:retrieve] at org.apache.ivy.core.resolve.
> VisitNode.loadData(VisitNode.java:284)
> [ivy:retrieve] at org.apache.ivy.core.resolve.ResolveEngine.
> fetchDependencies(ResolveEngine.java:724)
> [ivy:retrieve] at org.apache.ivy.core.resolve.ResolveEngine.
> doFetchDependencies(ResolveEngine.java:803)
> [ivy:retrieve] at org.apache.ivy.core.resolve.ResolveEngine.
> fetchDependencies(ResolveEngine.java:731)
> [ivy:retrieve] at org.apache.ivy.core.resolve.
> ResolveEngine.getDependencies(ResolveEngine.java:608)
> [ivy:retrieve] at org.apache.ivy.core.resolve.ResolveEngine.resolve(
> ResolveEngine.java:252)
> [ivy:retrieve] at org.apache.ivy.core.resolve.ResolveEngine.resolve(
> ResolveEngine.java:208)
> [ivy:retrieve] at org.apache.ivy.Ivy.resolve(Ivy.java:507)
>
> The exception looks like issue, IVY-1566, which is resolved in 2.5.0-rc1.
> However, the exception still exists in this example which is using the
> 2.5.0-rc1 version.
>
> On Mon, Aug 13, 2018 at 8:51 AM, t4rockets <t4...@gmail.com> wrote:
>
>> Using the dependence example, it has been updated so that build time (new
>> and equal to now via <tstamp> task) and version number properties are
>> written to the dependee version file. The dependee Java code was also
>> updated to print the build time and version number. The Java code was
>> update to see what build time property was in the downloaded JAR.
>>
>> The issue seen is that if the dependee JAR is updated/replaced (compiled
>> again with a new build time property) but no version change using the
>> publish overwrite="true" option, the depender Ivy retrieve will not
>> downloaded the updated JAR (same version, different build time and
>> therefore a different check sum). It appears that Ivy knows there is an
>> update based on the debug information, but the download does not happen.
>>
>> The filesystem repository is being used to support local build so that
>> developer can build and test the code changes locally without a repository
>> manager (i.e, Nexus).
>>
>> If the version number is updated, the depender Ivy retrieve will download
>> the updated dependee JAR as expected.
>>
>> This issue has been recreated against 2.4.0 and 2.5.0-rc1 and show both
>> the same behavior.
>>
>> Code added to the dependee "jar" target using the ant-contrib if task
>> <tstamp>
>> <format property="build.time" pattern="dd-MMMM-yyyy+HH:mm:ss
>> "/>
>> </tstamp>
>> <propertyfile file="${classes.dir}/version.properties">
>> <entry key="build.time" value="${build.time}"/>
>> </propertyfile>
>> <ac:if>
>> <equals arg1="${option.include.version}" arg2="true"/>
>> <ac:then>
>> <propertyfile file="${classes.dir}/version.properties">
>> <entry key="version" type="int" operation="+"
>> default="0"/>
>> </propertyfile>
>> </ac:then>
>> </ac:if>
>> Code update for the Main.java source code:
>> String buildTime = p.getProperty("build.time");
>> if (version != null && buildTime != null ) {
>> return version + "-" + buildTime;
>> }
>>
>> The sequence of events to create:
>>
>> - cd dependence
>> - ant
>> - ant all
>> - Note the build time and version from the depender task
>> - cd dependee
>> - ant publish
>> - ant publish
>> - Note the new build time and version for each publish
>> - cd ../depender
>> - ant
>> - Note the build time and version for the run task (should be the
>> same as the last dependee publish task)
>> - cd ../dependee
>> - ant publish -Doption.include.version=false
>> - ant publish -Doption.include.version=false
>> - Note the new build time and but the version did not update
>> - cd ../depender
>> - ant
>> - Note the build time does not match the latest dependee JAR
>> (updated build time, same version). The build time is from the JAR the
>> last time the version was updated.
>>
>>
>> Several options have been tried on the depender ivy:resolve task without
>> success. Is there some way to get the retrieve to download the updated
>> dependee JAR when it is only updated/replaced (no new version)?
>>
>> Thanks,
>>
>
>
Re: retrieve fails to download updated/replaced JAR from a filesystem resolver
Posted by t4rockets <t4...@gmail.com>.
In debug mode, the following exception during the retrieved was observed
when trying to read the Ivy.xml file:
[ivy:retrieve] java.net.MalformedURLException: unknown protocol: windows
message is "c" or Linux message is "cache path/ivy-[version].xml
[ivy:retrieve] at java.net.URL.<init>(URL.java:593)
[ivy:retrieve] at java.net.URL.<init>(URL.java:483)
[ivy:retrieve] at java.net.URL.<init>(URL.java:432)
[ivy:retrieve] at
org.apache.ivy.core.cache.DefaultRepositoryCacheManager.getSavedArtifactOrigin(DefaultRepositoryCacheManager.java:542)
[ivy:retrieve] at
org.apache.ivy.core.cache.DefaultRepositoryCacheManager.doFindModuleInCache(DefaultRepositoryCacheManager.java:779)
[ivy:retrieve] at
org.apache.ivy.core.cache.DefaultRepositoryCacheManager.cacheModuleDescriptor(DefaultRepositoryCacheManager.java:1310)
[ivy:retrieve] at
org.apache.ivy.plugins.resolver.BasicResolver.parse(BasicResolver.java:541)
[ivy:retrieve] at
org.apache.ivy.plugins.resolver.BasicResolver.getDependency(BasicResolver.java:278)
[ivy:retrieve] at
org.apache.ivy.core.resolve.IvyNode.loadData(IvyNode.java:183)
[ivy:retrieve] at
org.apache.ivy.core.resolve.VisitNode.loadData(VisitNode.java:284)
[ivy:retrieve] at
org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:724)
[ivy:retrieve] at
org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:803)
[ivy:retrieve] at
org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:731)
[ivy:retrieve] at
org.apache.ivy.core.resolve.ResolveEngine.getDependencies(ResolveEngine.java:608)
[ivy:retrieve] at
org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:252)
[ivy:retrieve] at
org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:208)
[ivy:retrieve] at org.apache.ivy.Ivy.resolve(Ivy.java:507)
The exception looks like issue, IVY-1566, which is resolved in 2.5.0-rc1.
However, the exception still exists in this example which is using the
2.5.0-rc1 version.
On Mon, Aug 13, 2018 at 8:51 AM, t4rockets <t4...@gmail.com> wrote:
> Using the dependence example, it has been updated so that build time (new
> and equal to now via <tstamp> task) and version number properties are
> written to the dependee version file. The dependee Java code was also
> updated to print the build time and version number. The Java code was
> update to see what build time property was in the downloaded JAR.
>
> The issue seen is that if the dependee JAR is updated/replaced (compiled
> again with a new build time property) but no version change using the
> publish overwrite="true" option, the depender Ivy retrieve will not
> downloaded the updated JAR (same version, different build time and
> therefore a different check sum). It appears that Ivy knows there is an
> update based on the debug information, but the download does not happen.
>
> The filesystem repository is being used to support local build so that
> developer can build and test the code changes locally without a repository
> manager (i.e, Nexus).
>
> If the version number is updated, the depender Ivy retrieve will download
> the updated dependee JAR as expected.
>
> This issue has been recreated against 2.4.0 and 2.5.0-rc1 and show both
> the same behavior.
>
> Code added to the dependee "jar" target using the ant-contrib if task
> <tstamp>
> <format property="build.time" pattern="dd-MMMM-yyyy+HH:mm:
> ss"/>
> </tstamp>
> <propertyfile file="${classes.dir}/version.properties">
> <entry key="build.time" value="${build.time}"/>
> </propertyfile>
> <ac:if>
> <equals arg1="${option.include.version}" arg2="true"/>
> <ac:then>
> <propertyfile file="${classes.dir}/version.properties">
> <entry key="version" type="int" operation="+" default="0"/>
> </propertyfile>
> </ac:then>
> </ac:if>
> Code update for the Main.java source code:
> String buildTime = p.getProperty("build.time");
> if (version != null && buildTime != null ) {
> return version + "-" + buildTime;
> }
>
> The sequence of events to create:
>
> - cd dependence
> - ant
> - ant all
> - Note the build time and version from the depender task
> - cd dependee
> - ant publish
> - ant publish
> - Note the new build time and version for each publish
> - cd ../depender
> - ant
> - Note the build time and version for the run task (should be the
> same as the last dependee publish task)
> - cd ../dependee
> - ant publish -Doption.include.version=false
> - ant publish -Doption.include.version=false
> - Note the new build time and but the version did not update
> - cd ../depender
> - ant
> - Note the build time does not match the latest dependee JAR
> (updated build time, same version). The build time is from the JAR the
> last time the version was updated.
>
>
> Several options have been tried on the depender ivy:resolve task without
> success. Is there some way to get the retrieve to download the updated
> dependee JAR when it is only updated/replaced (no new version)?
>
> Thanks,
>