[jira] Commented: (IVY-1152) Ivy does not close URL connection to ivy-report.xsl properly
[
https://issues.apache.org/jira/browse/IVY-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12793573#action_12793573
]
Pavel Sher commented on IVY-1152:
-
Well, I tried to fix this issue in the same way, however this does not seem to
work.
The opened input stream seems to be left after the getLastModified() call
inside void download(URL src, File dest, CopyProgressListener l) method:
long lastModified = srcConn.getLastModified();
if (lastModified 0) {
dest.setLastModified(lastModified);
}
if I add additional check to this code:
if (!(srcConn instanceof java.net.JarURLConnection)) {
long lastModified = srcConn.getLastModified();
if (lastModified 0) {
dest.setLastModified(lastModified);
}
}
The stream is not open anymore, and everything looks fine. On Windows you can
check it with help of SysInternals Process Explorer. On Unix you can probably
use lsof utility (however I did not try it).
Basically it looks like a bug in JVM, and it is not critical for those who use
Ivy inside short lived processes. I've reproduced this problem in our tests
which start artifacts resolution process via Ivy API, however I am not sure
whether these not closed input streams do any harm. I also tried different
versions of JVM and it looks like in Java 1.5 this bug is not so easy
reproducable as it in Java 1.6. In Java 1.5 I see 2 streams open and this
number is not increasing, while in Java 1.6 I see about 20 streams and it seems
their number grows if I run more tests.
Maybe it is safer to use Class.getResourceAsStream instead of URLs.
Ivy does not close URL connection to ivy-report.xsl properly
Key: IVY-1152
URL: https://issues.apache.org/jira/browse/IVY-1152
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.0, 2.1.0
Reporter: Pavel Sher
Assignee: Maarten Coene
Fix For: trunk
It seems BasicURLHanlder.disconnect() does not properly close URL connection
to ivy-report.xsl file. In my case URL looks like:
jar:file:/path/ivy-2.0.jar!/org/apache/ivy/plugins/report/ivy-report.xsl
In disconnect() method there is a check for URL connection class:
sun.net.www.protocol.file.FileURLConnection.equals(con.getClass().getName())
However in runtime this check does not work because instead of
FileURLConnection there is JarURLConnection:
sun.net.www.protocol.jar.JarURLConnection
This leads to leaked input streams if Ivy is used programmatically within the
same JVM.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-1152) Ivy does not close URL connection to ivy-report.xsl properly
Ivy does not close URL connection to ivy-report.xsl properly Key: IVY-1152 URL: https://issues.apache.org/jira/browse/IVY-1152 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.1.0, 2.0 Reporter: Pavel Sher It seems BasicURLHanlder.disconnect() does not properly close URL connection to ivy-report.xsl file. In my case URL looks like: jar:file:/path/ivy-2.0.jar!/org/apache/ivy/plugins/report/ivy-report.xsl In disconnect() method there is a check for URL connection class: sun.net.www.protocol.file.FileURLConnection.equals(con.getClass().getName()) However in runtime this check does not work because instead of FileURLConnection there is JarURLConnection: sun.net.www.protocol.jar.JarURLConnection This leads to leaked input streams if Ivy is used programmatically within the same JVM. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-1070) Ivy is unable to download artifact if revision contains #
Ivy is unable to download artifact if revision contains # - Key: IVY-1070 URL: https://issues.apache.org/jira/browse/IVY-1070 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.1.0-RC1, 2.0 Reporter: Pavel Sher It seems Ivy does not properly escape URL when tries to download artifact by HTTP. This causes problems if specified revision contains some characters which need to be escaped in the URL, like #. So if revision is like: 1.0.1 (change #111) Ivy fails to download such artifact. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-881) Ivy incorrectly searches for an artifact if it contains / in the name
[
https://issues.apache.org/jira/browse/IVY-881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Sher resolved IVY-881.
Resolution: Invalid
This issue seems to be invalid, we had a problem in our own code. I am sorry
for bothering you.
Ivy incorrectly searches for an artifact if it contains / in the name
-
Key: IVY-881
URL: https://issues.apache.org/jira/browse/IVY-881
Project: Ivy
Issue Type: Bug
Components: Core
Reporter: Pavel Sher
Assignee: Xavier Hanin
Yesterday (2008-Aug-11) I've build Ivy from the sources and found that Ivy
cannot download artifact with / in its name. It seems the bug can be
reproduced on windows only.
I have the following ivy.xml:
?xml version=1.0 encoding=UTF-8?
ivy-module version=2.0
info organisation=org module=module /
dependencies
dependency org=org name=dep rev=rev changing=true
include name=dir/path-to-artifact type=zip ext=zip
matcher=glob /
/dependency
/dependencies
/ivy-module
I tried to debug Ivy source code, and it looks like the problem is somewhere
near this code (IvyNode.java):
789: Map allArtifacts = new HashMap();
for (int i = 0; i confs.length; i++) {
Artifact[] arts = md.getArtifacts(confs[i]);
for (int j = 0; j arts.length; j++) {
allArtifacts.put(arts[j].getId().getArtifactId(),
arts[j]);
}
}
The produced Map of all artifacts contains dir\path-to-artifact instead of
dir/path-to-artifact. And because of this matcher cannot find the required
artifact. In Ivy-2.0-beta2 such artifacts were downloaded without problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-881) Ivy incorrectly searches for an artifact if it contains / in the name
[
https://issues.apache.org/jira/browse/IVY-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639796#action_12639796
]
Pavel Sher commented on IVY-881:
Is there any progress on this? Do you need any help to reproduce this bug? This
bug is a show stopper for us because we can't upgrade to Ivy 2.0. If you do not
have time to fix it I can try to fix it by myself and send you a patch.
Ivy incorrectly searches for an artifact if it contains / in the name
-
Key: IVY-881
URL: https://issues.apache.org/jira/browse/IVY-881
Project: Ivy
Issue Type: Bug
Components: Core
Reporter: Pavel Sher
Assignee: Xavier Hanin
Yesterday (2008-Aug-11) I've build Ivy from the sources and found that Ivy
cannot download artifact with / in its name. It seems the bug can be
reproduced on windows only.
I have the following ivy.xml:
?xml version=1.0 encoding=UTF-8?
ivy-module version=2.0
info organisation=org module=module /
dependencies
dependency org=org name=dep rev=rev changing=true
include name=dir/path-to-artifact type=zip ext=zip
matcher=glob /
/dependency
/dependencies
/ivy-module
I tried to debug Ivy source code, and it looks like the problem is somewhere
near this code (IvyNode.java):
789: Map allArtifacts = new HashMap();
for (int i = 0; i confs.length; i++) {
Artifact[] arts = md.getArtifacts(confs[i]);
for (int j = 0; j arts.length; j++) {
allArtifacts.put(arts[j].getId().getArtifactId(),
arts[j]);
}
}
The produced Map of all artifacts contains dir\path-to-artifact instead of
dir/path-to-artifact. And because of this matcher cannot find the required
artifact. In Ivy-2.0-beta2 such artifacts were downloaded without problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-923) Can't download files containing space or + in their names by HTTP
[ https://issues.apache.org/jira/browse/IVY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637415#action_12637415 ] Pavel Sher commented on IVY-923: Just checked it with the latest sources and it works! Thanks again Maarten! Can't download files containing space or + in their names by HTTP - Key: IVY-923 URL: https://issues.apache.org/jira/browse/IVY-923 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.0-RC1 Reporter: Pavel Sher Assignee: Maarten Coene Fix For: trunk I have an artifact with space in it's name, such artifact can't be downloaded by Ivy 2.0 RC1. The problem is somewhere near the doHead() method of the org.apache.ivy.util.url.HttpClientHandler class. This method receives url but this url contains spaces and when HttpClient HeadMethod is constructed an exception is thrown (which is silently ignored by the way). It seems that URL parts must be properly escaped before sent to HTTP client, since URL.toExternalForm() does not do this. The same problem seems to occur if file name contains +. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (IVY-881) Ivy incorrectly searches for an artifact if it contains / in the name
[
https://issues.apache.org/jira/browse/IVY-881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Sher reopened IVY-881:
Ivy incorrectly searches for an artifact if it contains / in the name
-
Key: IVY-881
URL: https://issues.apache.org/jira/browse/IVY-881
Project: Ivy
Issue Type: Bug
Components: Core
Reporter: Pavel Sher
Assignee: Xavier Hanin
Yesterday (2008-Aug-11) I've build Ivy from the sources and found that Ivy
cannot download artifact with / in its name. It seems the bug can be
reproduced on windows only.
I have the following ivy.xml:
?xml version=1.0 encoding=UTF-8?
ivy-module version=2.0
info organisation=org module=module /
dependencies
dependency org=org name=dep rev=rev changing=true
include name=dir/path-to-artifact type=zip ext=zip
matcher=glob /
/dependency
/dependencies
/ivy-module
I tried to debug Ivy source code, and it looks like the problem is somewhere
near this code (IvyNode.java):
789: Map allArtifacts = new HashMap();
for (int i = 0; i confs.length; i++) {
Artifact[] arts = md.getArtifacts(confs[i]);
for (int j = 0; j arts.length; j++) {
allArtifacts.put(arts[j].getId().getArtifactId(),
arts[j]);
}
}
The produced Map of all artifacts contains dir\path-to-artifact instead of
dir/path-to-artifact. And because of this matcher cannot find the required
artifact. In Ivy-2.0-beta2 such artifacts were downloaded without problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-923) Can't download files containing space or + in their names by HTTP
Can't download files containing space or + in their names by HTTP - Key: IVY-923 URL: https://issues.apache.org/jira/browse/IVY-923 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.0-RC1 Reporter: Pavel Sher I have an artifact with space in it's name, such artifact can't be downloaded by Ivy 2.0 RC1. The problem is somewhere near the doHead() method of the org.apache.ivy.util.url.HttpClientHandler class. This method receives url but this url contains spaces and when HttpClient HeadMethod is constructed an exception is thrown (which is silently ignored by the way). It seems that URL parts must be properly escaped before sent to HTTP client, since URL.toExternalForm() does not do this. The same problem seems to occur if file name contains +. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-923) Can't download files containing space or + in their names by HTTP
[ https://issues.apache.org/jira/browse/IVY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635424#action_12635424 ] Pavel Sher commented on IVY-923: Unfortunately BasicUrlHandler does not support HTTP authentication and it is not so easy to check with another server on my side. Can't download files containing space or + in their names by HTTP - Key: IVY-923 URL: https://issues.apache.org/jira/browse/IVY-923 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.0-RC1 Reporter: Pavel Sher I have an artifact with space in it's name, such artifact can't be downloaded by Ivy 2.0 RC1. The problem is somewhere near the doHead() method of the org.apache.ivy.util.url.HttpClientHandler class. This method receives url but this url contains spaces and when HttpClient HeadMethod is constructed an exception is thrown (which is silently ignored by the way). It seems that URL parts must be properly escaped before sent to HTTP client, since URL.toExternalForm() does not do this. The same problem seems to occur if file name contains +. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-923) Can't download files containing space or + in their names by HTTP
[ https://issues.apache.org/jira/browse/IVY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635432#action_12635432 ] Pavel Sher commented on IVY-923: I made a quick and dirty hack in HttpClientHandler: in methods doGet, doHead and upload I changed argument url to: BasicURLHandler.normalize(dest).toExternalForm() This solved problem with names with spaces but names with plus sign still do not work. Can't download files containing space or + in their names by HTTP - Key: IVY-923 URL: https://issues.apache.org/jira/browse/IVY-923 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.0-RC1 Reporter: Pavel Sher I have an artifact with space in it's name, such artifact can't be downloaded by Ivy 2.0 RC1. The problem is somewhere near the doHead() method of the org.apache.ivy.util.url.HttpClientHandler class. This method receives url but this url contains spaces and when HttpClient HeadMethod is constructed an exception is thrown (which is silently ignored by the way). It seems that URL parts must be properly escaped before sent to HTTP client, since URL.toExternalForm() does not do this. The same problem seems to occur if file name contains +. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-881) Ivy incorrectly searches for an artifact if it contains / in the name
[
https://issues.apache.org/jira/browse/IVY-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635527#action_12635527
]
Pavel Sher commented on IVY-881:
The bug still exists in Ivy-2.0 RC1. I have the following ivy.xml on server:
?xml version=1.0 encoding=UTF-8?
ivy-module version=1.4
info .../
publications
...
artifact name=javadoc/index type=html ext=html /
...
/publications
/ivy-module
Then I am trying to download it with help of the following ivy.xml on the
client side:
ivy-module version=2.0
info ...
dependencies
dependency ...
include name=javadoc/* type=html ext=html matcher=glob /
/dependency
/dependencies
/ivy-module
And Ivy fails to do that because it tries to match pattern javadoc/* to name
javadoc\index.html (note the difference in slash and back slash). I had to
debug through Ivy sources to understand why it happens.
These dependencies work just fine in Ivy-1.4.1
Ivy incorrectly searches for an artifact if it contains / in the name
-
Key: IVY-881
URL: https://issues.apache.org/jira/browse/IVY-881
Project: Ivy
Issue Type: Bug
Components: Core
Reporter: Pavel Sher
Assignee: Xavier Hanin
Yesterday (2008-Aug-11) I've build Ivy from the sources and found that Ivy
cannot download artifact with / in its name. It seems the bug can be
reproduced on windows only.
I have the following ivy.xml:
?xml version=1.0 encoding=UTF-8?
ivy-module version=2.0
info organisation=org module=module /
dependencies
dependency org=org name=dep rev=rev changing=true
include name=dir/path-to-artifact type=zip ext=zip
matcher=glob /
/dependency
/dependencies
/ivy-module
I tried to debug Ivy source code, and it looks like the problem is somewhere
near this code (IvyNode.java):
789: Map allArtifacts = new HashMap();
for (int i = 0; i confs.length; i++) {
Artifact[] arts = md.getArtifacts(confs[i]);
for (int j = 0; j arts.length; j++) {
allArtifacts.put(arts[j].getId().getArtifactId(),
arts[j]);
}
}
The produced Map of all artifacts contains dir\path-to-artifact instead of
dir/path-to-artifact. And because of this matcher cannot find the required
artifact. In Ivy-2.0-beta2 such artifacts were downloaded without problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-923) Can't download files containing space or + in their names by HTTP
[ https://issues.apache.org/jira/browse/IVY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635560#action_12635560 ] Pavel Sher commented on IVY-923: My problem is that + character is converted to space by servlet container. However I need it to be + otherwise I won't be able to find file. I am not sure about RFC, indeed it seems that it does not require + to be encoded. However I also found this document: http://www.blooberry.com/indexdot/html/topics/urlencoding.htm and it says that + character must be encoded if it does not have special meaning in the URL. BTW Java URLEncoder also treats + as unsafe character and converts it to %2B. Can't download files containing space or + in their names by HTTP - Key: IVY-923 URL: https://issues.apache.org/jira/browse/IVY-923 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.0-RC1 Reporter: Pavel Sher I have an artifact with space in it's name, such artifact can't be downloaded by Ivy 2.0 RC1. The problem is somewhere near the doHead() method of the org.apache.ivy.util.url.HttpClientHandler class. This method receives url but this url contains spaces and when HttpClient HeadMethod is constructed an exception is thrown (which is silently ignored by the way). It seems that URL parts must be properly escaped before sent to HTTP client, since URL.toExternalForm() does not do this. The same problem seems to occur if file name contains +. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-652) Ivy constructs incorrect URL if artifact path contains spaces
[ https://issues.apache.org/jira/browse/IVY-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12620567#action_12620567 ] Pavel Sher commented on IVY-652: I need this version on the server side when Ivy downloads artifacts, I submitted another feature request: IVY-878 Ivy constructs incorrect URL if artifact path contains spaces - Key: IVY-652 URL: https://issues.apache.org/jira/browse/IVY-652 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 1.4.1 Reporter: Pavel Sher Assignee: Maarten Coene Fix For: 2.0-RC1 I have the following publication in my ivy.xml file: publications artifact name=artifacts/sub folder/file type=txt ext=txt / /publications When Ivy tries to download this artifact it constructs wrong URL with non escaped spaces. I can provide escaped path in ivy.xml (however I do not think it is correct to do so), but in this case Ivy do not unescape path and stores files on disk with %20 in their names. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-652) Ivy constructs incorrect URL if artifact path contains spaces
[ https://issues.apache.org/jira/browse/IVY-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12620202#action_12620202 ] Pavel Sher commented on IVY-652: It looks like the fix is working, thank you Maarten! Since we have a workaround (which is not always working though) for current Ivy version (1.4.1) do you know of any way to determine what version of Ivy is downloading artifacts or asking for ivy.xml? Ivy constructs incorrect URL if artifact path contains spaces - Key: IVY-652 URL: https://issues.apache.org/jira/browse/IVY-652 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 1.4.1 Reporter: Pavel Sher Assignee: Maarten Coene Fix For: 2.0-RC1 I have the following publication in my ivy.xml file: publications artifact name=artifacts/sub folder/file type=txt ext=txt / /publications When Ivy tries to download this artifact it constructs wrong URL with non escaped spaces. I can provide escaped path in ivy.xml (however I do not think it is correct to do so), but in this case Ivy do not unescape path and stores files on disk with %20 in their names. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-652) Ivy constructs incorrect URL if artifact path contains spaces
[ https://issues.apache.org/jira/browse/IVY-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12618252#action_12618252 ] Pavel Sher commented on IVY-652: I've built ivy from sources in SVN and the problem still exists. Take a look at the log produced by Ivy: :: loading settings :: file = C:\Perforce\BuildServer\tools\tomcat\temp\ivysettings67395.xml :: resolving dependencies :: org#bt378;[EMAIL PROTECTED] confs: [default] found org#bt377;4 in teamcity-rep [4] org#bt377;latest.lastFinished :: resolution report :: resolve 15522ms :: artifacts dl 15ms - | |modules|| artifacts | | conf | number| search|dwnlded|evicted|| number|dwnlded| - | default | 1 | 1 | 1 | 0 || 1 | 0 | - :: problems summary :: WARNINGS [NOT FOUND ] org#bt377;4!agent openapi.jar (0ms) teamcity-rep: tried http://localhost:8111/bs/httpAuth/repository/download/bt377/4/agent openapi.jar :: :: FAILED DOWNLOADS:: :: ^ see resolution messages for details ^ :: :: :: org#bt377;4!agent openapi.jar :: :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS :: retrieving :: org#bt378 confs: [default] 0 artifacts copied, 0 already retrieved (0kB/0ms) My ivy.xml has the following content: ?xml version=1.0 encoding=UTF-8? ivy-module version=1.4 info organisation=org module=bt377 revision=4 status=lastFinished publication=20080729162455/ publications artifact name=agent openapi type=jar ext=jar/ /publications /ivy-module On the server I did not see request to download agent openapi.jar, so I do not know why Ivy decided that file was not found, probably it failed to create HTTP request. Ivy constructs incorrect URL if artifact path contains spaces - Key: IVY-652 URL: https://issues.apache.org/jira/browse/IVY-652 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 1.4.1 Reporter: Pavel Sher Fix For: 2.0-RC1 I have the following publication in my ivy.xml file: publications artifact name=artifacts/sub folder/file type=txt ext=txt / /publications When Ivy tries to download this artifact it constructs wrong URL with non escaped spaces. I can provide escaped path in ivy.xml (however I do not think it is correct to do so), but in this case Ivy do not unescape path and stores files on disk with %20 in their names. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-652) Ivy constructs incorrect URL if artifact path contains spaces
[ https://issues.apache.org/jira/browse/IVY-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12618295#action_12618295 ] Pavel Sher commented on IVY-652: My ivy settings: ivysettings property name='ivy.checksums' value=''/ caches defaultCacheDir=C:/Perforce/BuildServer/tools/tomcat/temp/ivy67396cache/ statuses status name='lastPinned' integration='false'/ status name='lastSuccessful' integration='false'/ status name='lastFinished' integration='false'/ status name='integration' integration='true'/ /statuses resolvers url name='teamcity-rep' latest='latest-time' ivy pattern='http://localhost:8111/bs/httpAuth/repository/download/[module]/[revision]/teamcity-ivy.xml' / artifact pattern='http://localhost:8111/bs/httpAuth/repository/download/[module]/[revision]/[artifact](.[ext])' / /url /resolvers modules module organisation='.*' name='.*' matcher='regexp' resolver='teamcity-rep' / /modules /ivysettings Ivy constructs incorrect URL if artifact path contains spaces - Key: IVY-652 URL: https://issues.apache.org/jira/browse/IVY-652 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 1.4.1 Reporter: Pavel Sher Assignee: Maarten Coene Fix For: 2.0-RC1 I have the following publication in my ivy.xml file: publications artifact name=artifacts/sub folder/file type=txt ext=txt / /publications When Ivy tries to download this artifact it constructs wrong URL with non escaped spaces. I can provide escaped path in ivy.xml (however I do not think it is correct to do so), but in this case Ivy do not unescape path and stores files on disk with %20 in their names. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-597) dependency @changing attribute has no effect (url resolver)
[ https://issues.apache.org/jira/browse/IVY-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12592569#action_12592569 ] Pavel Sher commented on IVY-597: I experience the similar problems but with Ivy 2.0-beta2. I tried to specify changing=true for dependency, as well as checkmodified=true changingPattern=.* changingMatcher=regexp for resolvers/url tag in ivyconf.xml. But in either cases it looks like Ivy does not do any attempt to check last modified date. I expected that URL resolver will send HEAD request to check last modified date, but if Ivy cache contains necessary files I never see such requests. dependency @changing attribute has no effect (url resolver) --- Key: IVY-597 URL: https://issues.apache.org/jira/browse/IVY-597 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 1.4.1 Reporter: Eric Jain Fix For: 2.0 I have a config where the changing=true works as expected (artifact re-retrieved if changed, even if version number unchanged) with the file system resolver, but when I switch to the url resolver, I always get the artifact from the ivy cache (even though it has been updated on the web server)... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-878) Report version of Ivy in HTTP headers (user-agent?) when Ivy downloads artifacts
ng, dari Madiun Simbah dapat tumpangan sampai Surabaya. Alhamdulillah, setelah kerja jadi kuli bangunan sekitar dua tahun, tabungannya cukup untuk ikut kapal laut menuju Singapura. Ditemani strup anget dan parota, makanan khas India yang sempat saya beli sebelumnya, Simbah melanjutkan kembali kisahnya. Kalih tahun kulo nguli teng perkebunan sawit, terus pindah teng Malaysia sekitar sekawan tahun. Berbekal tabungan, dengan kapal laut simbah yang kemudian mempunyai nama KTP Muhammad al Malayu, berlayar melanjutkan perjalanannya ke tanah suci. Sampai kota Mekkah, seingatnya tahun 1954, Simbah langsung kembali bekerja sambil menunggu musim haji tiba. Keahliannya bertukang membuat ia memperoleh pekerjaan dengan cepat. Dari tukang kayu sampai tukang besi pernah beliau tandangi. Menjadi tukang ledeng juga bukan hal aneh. Laiknya seorang warok sejati, tubuhnya yang tinggi kekar menunjangnya untuk menaklukkan alam yang panas dan keras. Simbah sungguh sosok yang pantang menyerah. Simbah riyin nggih mpun biasa tilem sarungan langit, Le ..., lanjut Simbah lagi kepada saya dan beberapa teman muttawif asal Ponorogo yang juga ikut nimbrung menemani ngobrol. Tak ada saudara. Tak ada juga teman yang bisa menampung, Simbah bersama sohibnya yang berasal dari Malaysia tidur dan tinggal untuk sementara di lokasi proyek. Maklum, kabarnya dari dulu masjid-masjid di kota ini memang melarang orang untuk tidur, tak seperti masjid - masjid di tempat kita. Puluhan tahun hidup seperti ini, dan tentunya setelah menjalankan ritual ibadah haji dan umroh berkali-kali, Simbah pun menambah tujuan hidupnya: ingin hidup lebih mulia. Tanah kelahirannya, Ponorogo, saat itu menurutnya memang sudah tak mampu memberikan apa-apa lagi. Orang tuanya buruh tani. Saudara-saudaranya setali tiga uang. Miskin. Bertahun-tahun mengejar impiannya, Simbah masih istiqomah. Namun setelah sahabat seperantauannya menyerah dan menyatakan akan kembali ke Malaysia, Mbah Cengkeh pun sedikit gamang. Ia sempat menangis dan bersedih atas keputusan sahabatnya ini. Untung beliau segera mendapat jodoh, seorang perempuan pribumi penyedia makanan buruh bangunan dari berbagai bangsa. Pernikahan membuat hidupnya tak sendiri lagi dalam menghadapi segala rintangan. Dan berkahnya adalah beliau memperoleh status kewarganegaraan dari pemerintah Saudi. Ryal demi ryal dikumpulkan untuk membeli tanah di kampung Syamiah, sekitar duapuluh menit jalan kaki dari pintu as Salam, Masjiddil Harram yang ditengahnya terletak Ka'bah. Bertahun-tahun dengan sepenuh hati dikerjakannya sendiri rumah bersama istrinya. Dan, nggak usah pakai sim salabim, rumah tersebut sekarang menjadi flat yang jadi rebutan setiap tahunnya bagi para jamaah haji. Ingkang nyewo paling sering nggih rombongan bule Islam saking Perancis, lanjut Mbah Cengkeh tanpa menunjukkan rasa sombong sedikitpun. Sayang, pernikahannya tak kunjung menghasilkan keturunan. Mbah Cengkeh pun kembali bersedih. Umi, wanita pendaping Simbah yang berhati mulia ini pun menawarkan diri untuk mencarikan perempuan lain agar Simbah memperoleh keturunan. Tentu pendapat ini ditolaknya. Namun setelah Umi memintanya berkali-kali, Simbah pun bersedia asal yang meminang adalah Umi sendiri. Bersama Umi lelaki perkasa ini kembali ke Ponorogo. Tepatnya di Mlilir, di rumah kakak perempuannya, Simbah disodori beberapa alternatif. Setelah ketemu yang cocok, Simbah pun berangkat melamar bersama Umi. Jane nggih melas kalih Umi. Wong wekdal nyiapke pakaian kulo piyambakke mbrebes mili ajeng nangis. Nanging ajeng kulo batalaken piyambakke nggih mboten angsal, tuturnya serius. (Biar singkat, akhirnya Simbah jadi nikah lagi. Kalau tidak salah dengan perempuan asal Trenggalek dan mendapat keturunan. Tak lama kemudian Umi wafat setelah sakit cukup lama. Sekarang salah seorang putra Simbah juga sudah menjadi warga Saudi dan meneruskan mengelola flat. Mbok kapan-kapan kalau ada warga MC yang ke Mekkah mencari beliau dan mampir. Asyik lo. Ins by HTTP. We had workarounds made on the server side for older versions of Ivy, but these workarounds are incorrect for upcoming Ivy 2.0. It would be helpful to provide information about Ivy version in HTTP headers when it downloads files by HTTP. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
