Re: [ANNOUNCEMENT] Maven Beta-8 Release

[Colin Sampaleanu]

After your commit, the build does break. The code still needs work, in that aside from the build breakage and message about that, now there is an error displayed even for file not found (for remote repos that are accessed through http, but not through 'file:' ), which is not appropriate. I will try to spend a bit of time on this code on the weekend to clean things up...


[EMAIL PROTECTED] wrote:

Was this before or after my commit an hour or two back?
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au


"Peter Lynch" <[EMAIL PROTECTED]> wrote on 14/02/2003 06:10:28 PM:

I can also verify that with maven HEAD today builds does not fail when
dependencies can't be found.

I use Win 2000 JDK 1.4.1_01 also.

-Peter


----- Original Message -----
From: "Colin Sampaleanu" <[EMAIL PROTECTED]>
To: "Turbine Maven Users List" <[EMAIL PROTECTED]>
Sent: Thursday, February 13, 2003 8:34 AM
Subject: Re: [ANNOUNCEMENT] Maven Beta-8 Release

Jason van Zyl wrote:

On Thu, 2003-02-13 at 11:02, Colin Sampaleanu wrote:

Jason van Zyl wrote:

On Thu, 2003-02-13 at 09:40, Colin Sampaleanu wrote:

This is quite possible, since the current code doesn't break the

build

when a dependency is not found...

Ok, I just tried what you described with HEAD and got:

-----
__ __
| \/ |__ Jakarta _ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0-beta-9


Attempting to download crapola-1.0.jar.
WARNING: Failed to download crapola-1.0.jar.
The build cannot continue because of the following unsatisfied
dependency:

crapola-1.0.jar

Total time: 4 seconds

-----

Where do we have the mismatch?

Maybe it's an OS thing. I am running Win2k, and I think you are

running

Linux?

Yes, I have Linux. Do you have multiple repositories set? Maybe

that's

it.

The other thing I just verified is that while dIon had said he
was going to change the ignoreErrors flag to false (in
DependencyVerifier), it's still true. So actually, I understand why

it's

not failing for me, I don't understand why it's failing for you.

We should probably change the logic to just let the downloads occur

and

then check again afterward which artifacts are present. That way it

wil

always depend on what is actually present in the local repository.

I think
in my case what is happening is that an expected error happens (in
HttpUtils), and because of the ignoreErrors that doesn't get

returned as

an error. In your case, an exception of another sort gets thrown,

which

doesn't get filtered by the ignoreErrors flag but comes through to
DependencyVerifier, so the artifact is not treated as downloaded.

Will try to figure this out in more depth.

Ok, thanks. Things are in better shape now so patches can be applied

a

little faster now.

Here is some more info, after stepping through the code again in a
debugger. In my case, everything is behaving exactly as expected,

given

the code that is there. I don't understand why it's failing for you.

getRemoteArtifact() calls HttpUtils.getFile() with ignoreErrors set to
true. getfile does a connection, gets past the point where it checks

the

headers for HTTP_NOT_MODIFIED and HTTP_UNAUTHORIZED, and arrives at

the

loop where it tries 3 times to get the inputstream. At that point, it
catches any IOException (in this case, FileNotFoundException) and

always

ignores it. Immediately afterwards, because ignoreErrors is true, it
doesn't treat the fact that the inputstream is null as an error, but
simply returns.

So everything works exactly as it should, given the code in CVS. The
real question is why the build is failing for you. I think in your

case

possibly something else other than an IOException is being thrown, so

is

not being caught in getFile(), or maybe an exception is thrown before
that point even...

What would _probably_ resolve things is to set ignoreErrors to false,

as

dIon had wanted to, but I would still figure out why stuff is working
for you with the present code, since it just doesn't make sense.

Colin

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]