Closed riccardocossu closed 10 years ago
I have never configured it with HTTP URLs. Try using SSH-based ones (like here), instead. Those work with Bitbucket for sure.
I also tried with ssh and I have the same problem; the issue seems to be there when you need to download certain files from git (github, bitbucket, whatever) and some from other repositories. I guess that, if you have you whole repository on git, it would work fine, but I don't really think this would be an option.
What do you mean with not having the whole repository on git? git modules? SVN?
on git we only have the jars which are not available in public or accessible repositories; for the rest we rely on standard public repositories.
I don't see your point. Wagon-git can work with (even) private Bitbucket repositories using SSH URLs.
We have some internal jars (not publicly available) we want to distribute (to colleagues) through our bitbucket repo; as long as we only use those jar everything is fine, we can publish and recover artifacts with no problem. The issues starts when we try to download a jar which is not in our repository, for example httpclient-4.3 which is available through maven standard public repositories; we don't wanna put that in our repository for many reasons I won't list for brevity. Wagon-git tries to download httpclient from bitbucket (but it's not there), but, instead of managing the error and letting the next repo do it (eventually maven central will be called), it writes a zero-length placeholder so that maven believes that file has been downloaded; the build fails later when it finds the zero-length jar.
The patch looks good. Thank you. I'll merge and release 0.2.4 ASAP.
Well, I can't see it anymore...
sorry I made a mess; just give me a minute :-) it's a bit cleaner now
this will do, just tried; thank you.
I think that removing
if (remote.exists())
from the original source should be enough. new FileInputStream(remote)
will throw the adequate exception.
Would you please try and tell me if that works for you?
It works, but why was it there in the first place then?
Looks like a bug to me :) I'll test further and then commit and release. Thanks.
Done. 0.2.4 is out.
thanks, have a nice day
We are using version 0.2.3 and we are using wagon-git in the same build as other repositories. Basically we only want to put a few jars on git (the ones which are not available in public repositories), but let all the rest to be downloaded from usual sources (repo.maven.org and such). The problem is that if wagon-git is called before standard http wagon and doesn't find what it's looking for in the git repo, instead of failing and passing the download to the next wagon it downloads a zero length file, which later results in a build error. I think the problem is that the file not found error is misread as a zero length file and wagon-git tells that everything went fine (so no other wagon kicks in after that).
Here's an extract of the debug log (the git repo is private, so please just trust me that the file isn't there):
[DEBUG] RAN: git pull origin releases / $? = 0 git:releases://git@bitbucket.org/ - Session: Opened/.m2/repository/org/apache/httpcomponents/httpclient/4.3/httpclient-4.3.jar.tmp32d4207243a74453)
Downloading: org/apache/httpcomponents/httpclient/4.3/httpclient-4.3.jar from git:releases://https://riccardocossu@bitbucket.org/<our repo bitbucket).
Transfer finished. 0 bytes copied in 0.0 seconds
[DEBUG] Invoked get(org/apache/httpcomponents/httpclient/4.3/httpclient-4.3.jar, /