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 Mon, 06 Dec 2004 19:52:19 GMT

> We will need to add the functionality which can access file size for 
> every protocol.
> I am not 100% sure if this is doable for all of them  but we can try 
> to do this.

I'll look at this then. If it is not possible, a known value such as -1 
can indicate it is not known and be handled appropriately.

>> - no last-modified handling - this should be in abstract wagon
> It is needed only for snapshot artifacts, right?


> If I remember we have decided that we will have pointer files  
> containing the timestamp of the last deployed
> artifact. 

in the local repository?

> Not every protocol supports last-modified flag ( e.g I am not sure 
> about ftp, sftp) - and we need to use "the lowest common denominator". 

sure, although in some cases the LCD can be raised by special handling 
the functionality in some cases.

> Also we will need to handle timezones properly and we will need to 
> take into
> account that server's time zone might be different then user's 
> timezone. And stuff like that.

This is all handled correctly already.

So now I'm remembering a brief comment by Jason that snapshot handling 
wasn't going to be in Wagon. Can we sort this out so we know the way 
forward? It may be that it is not practical to use wagon in Maven 1.1 
for dependency downloading after all.

>> - change input/output stream to input/output source wrapper class 
>> that contains
>> timestamp & length (& checksum?)
> Sorry but I don't understand this point :(

I think having abstract wagon deal with input and output streams isn't 
rich enough. I'd like to be able to attach properties to the source and 
destination for comparison. Timestamps are for the above. Length can be 
for reporting how long a download will take exactly. And then you could 
add some optional extra-paranoid checking: check remote dependencies for 
the same size as local, compare checksums or even signatures again. This 
could be run occasionally to verify the integrity of the local/remote 
repo without just redownloading everything.

> we can easly add one. I think that scp is used much more frequently 
> and my private benchmarks have shown that
> transfers are much  faster with scp (at least wihout any compression) 
> . For anybody using ssh2 there  is no differnce if he uses scp or sftp 
> as both protocols
> must be supported by ssh2 server. As scp seems to be faster (my 
> bechmarks are not unltimate refernce here :) I guess that scp will be 
> preferable one.
ok. We might need to consult the users to see who is using it and why.

>> - is there any problem adding an ext wagon?
>> ^ I'm not convinced we need an ext wagon, but it can definitely be 
>> used and it's easy to do. I feel it's easier to give than to try and 
>> handhold people through sshagent changes etc.
> I think it is doable to add "ext" wagon. One of the reason (and in 
> fact the only reason which I can see) to  use such  wagon
> is becouse it can give more security.
> I figured out myself that passwords can be provided in a secure way to 
> long living applications like continuum (wen interface)
> or injected via call back method by observers which are displaying 
> dialogboxes
> I had an implementation of "password storage" which can be used in 
> continum/eclipse/idea etc.

Sorry, not sure why an ext wagon helps here, except maybe for doing ftp 
without a password - but you'd think anyone that security conscious 
would be using SSH with a private key anyway.

I was thinking it was for using SSH agents.

> I am testing ssh wagon inside the continuum. It will be quite hard to 
> find improment here and I am not sure if it is worthed it.

These seem like integration tests best run in continuum but not day to 
day. Is it best we pull them all out? ie wagon-provider-test could 
contain all the tests and depend on each provider. Continuum would run 
those tests when any provider changed, right?


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

View raw message