maven-wagon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: wagon changes
Date Tue, 07 Dec 2004 09:50:34 GMT

>I have added initial support such functionality it to m2 Artifact Resolver but it is currently
commented out or it was removed.
>We can revert it quickly.
What exactly is the scope of wagon? I understand that it is repository 
independant transport mechanism. I don't see why the last-modified, if 
supported, would not be part of wagon as it is part of the transport 
mechanism. Is this right?

>I think that for release process it will be nice to have the information when this any
snapshot artifact was built also in local repository
>so we can easily  resolve snapshot dependencies and replaces them with ones with the timestamp
in their version without ever hitting remote repository.
What if the remote repository changed?

>The other important point when we must make a decision is if local repository will be
100% symmetrical to remote repository.
Personally I believe it should be.

>Why not?!  We just need to agree what we will attempt to do in relation to snapshots (and
possibly other type of pointer files) in m2
>and compare it  with requirements of m1.
I'd rather not talk about pointer files. I think repository metadata is 
a good thing, and it should be aggregated as much as possible. I tend to 
think of yum as an example. I'd like to investigate how it works more 
(espeically how they publish and update metadata) as not only does it 
have metadata, but signing which I'm very keen to implement.

>Not  sure what you mean by that. Observers are not created in get/put transfers.
>They are created outside of wagon and before any activity is started.
>We are sending events to observers and Wagon API defines base classes for Events.
>Wagons can send  Child classes of that bases classes/
I'm referring to line 168 of:

I imagine the transfer event should contain all information about what 
is being transferred according to your design. To get the length there 
from a non-AbstractWagon means passing it through a set of functions. I 
was going to replace the in/output streams on that function with 
something that represented a local/remote file with timestamp, length 
etc rather than just a stream.

>HTTP wagon is using commons-httpclient and there are some things in their api which makes
it practically impossible.
>You might be the third one to try (after Jason and me ) :-)
I haven't looked at the put, but AFAIK the get just returned a stream. 
I'll look, but I guess its not that important.

>There were some other issues with SSH wagon but I don't exactly remember now (I can check).
Probably the fact that ssh wagon cannot just  handle  the InputStream 
>to StreamWagon as some additional pieces of information must be send after the data was
>Probably in this case we could extend stream wagon api and add methods like prePutTransfer,
postPutTransfer etc ordo it  via using some kind of stream decorator 
>but I am not sure if this will make the code simpler. But any good  ideas are more welcomed!
I was thinking this would be a substitute InputStream actually, but it's 
not that important.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message