Closed GoogleCodeExporter closed 9 years ago
Getting Ivy to display it will probably be tricky.
Outputting the paths at WARN level is an option but I have had other requests
for
hiding that information as, when it is all working, you don't really want all
that
extra logging output. This is why the levels were changed down to debug.
Unfortunately there is no easy way to tell Ivy at what level to log messages,
so the
choice boils down to either outputting everything everytime it is run via
INFO/WARN
level, or using the debug level. My preference is to keep it as it is, on debug
level, and the advice for people running into problems with IvySvn is to always
run
it in debug to see exactly what is going on.
Original comment by massdosage
on 9 Oct 2008 at 3:07
Ok - so you mean you do not know when an operation has failed at the ivy-svn
level?
Makes sense since I guess ivy will try multiple times with different paths...
However, how come the path ivysvn tries is not the same as the one outputted by
ivy
itself?
Original comment by christof...@gmail.com
on 9 Oct 2008 at 4:13
Indeed.
The Ivy documentation for writing one's own resolver is pretty much
non-existent so
it's a bit tricky figuring this all out. What I am guessing is that Ivy outputs
what
it thinks the path is, based on patterns etc. but this obviously doesn't know
anything about the SVN side of things. Having said that, this is the output I
see (in
normal use, not debug) when Ivy is retrieving a file using IvySvn:
[ivy:resolve] downloading
svn+ssh://somehost.last.fm/svn/java/repository/apache/hadoop/0.17.2-custom1/hado
op-core.jar
Which is indeed the correct full path to the file. What do you see that looks
incorrect?
Original comment by massdosage
on 9 Oct 2008 at 4:38
Well, I see the correct path.
Prior to fix 99, if you use the complete URL in the artifact and ivy pattern,
e.g.
<artifact pattern="http://dom.com/svn/Binaries/[organisation]/[module]...
... and specify a repositoryURL of "http://dom.com/svn/Binaries"
ivysvn will look for the ivy.xml and artifact files at
http://dom.com/svn/Binaries/http://dom.com/svn/Binaries/[organisation]/[module]...
as evidenced in the DEBUG level output. The main ivy code will fail with a
message
similar to
Cannot locate the artifact...
http://dom.com/svn/Binaries/org/module/module.jar
(this I take from memory, so the wording is completely screwed up)
It would be helpful if the real path was outputted witout having to turn on
DEBUG
level output.
Original comment by christof...@gmail.com
on 9 Oct 2008 at 5:40
NOTE: This problem is also present when publishing files - ivy outputs the
correct
path but ivysvn really tries to publish to the repository root, please refer to
issue #2
Original comment by christof...@gmail.com
on 9 Oct 2008 at 5:43
OK, I see what you are saying, I will try to reproduce locally and see if that
error
message can be improved but I've got a feeling that it may be out of my hands
and
comes from Ivy itself.
Original comment by massdosage
on 9 Oct 2008 at 5:45
OK, for retrieve/resolve/list operations I can detect error cases and now
output the
full path for the resource in question on error level. For publish it's not
trivial
as publish takes place in a transaction and at that point we don't know which
of the
file paths in the transaction causes the error. So I have changed the publish
logging
around so that it outputs the full "publishing to" path for each file on info
level,
and changed the "adding/updating file" messages from info to debug.
All in all this should now display full svn paths on at least info level for all
operations so that errors can be spotted easier without having to run ant in
debug mode.
Original comment by massdosage
on 10 Oct 2008 at 11:47
Great!
Original comment by christof...@gmail.com
on 13 Oct 2008 at 7:36
Original issue reported on code.google.com by
christof...@gmail.com
on 9 Oct 2008 at 2:47