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 23:09:04 GMT
> >> If I remember we have decided that we will have pointer files  
> >> containing the timestamp of the last deployed
> >> artifact. 
> >
> >
> > in the local repository?
> for accessing the file in the local repository you don't need wagon :)

that's not what I meant, but I see what you mean now. So we effectively write
last-modified to a file rather than using a header.

For compatibility with m1, is there any reason not to use last-modified if that
file doesn't exist (as nothing, including wagon, is attempting to create it now).

> >> 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.
> Is this a case of every type of the server?

Every type of server that currently uses last-modified, yes. We only support
http and file in m1.

> We planned to change bit in which snapshot artifact will be resolved but 
> it could be that we can still use it in m1...
> That is something which we really have to disuss to have a clear  vison  
> how it will work  in  m2 and compare
> it with the way in which works  in m1.

ok, so what do we need to sort out? should we start a separate thread?

> We have (or better say I have)  planned to put any extra metadata to 
> repository as set of extra files
> (like we do with .md5 files) and in wagon have a support for really dumb 
> get/put operations
> so we will be able to support any repository in uniform way.

ok, let's start getting this happening then.

> Such functionality can be already provided by Observers.
> They were really created from ultra fast processing so number of i/o 
> operation is limited to absolute maximum
> (e..g md5 cheksum is computed on the fly when artifact is transfered)
> but they were also supposed to be used for cases like progress bars in 
> guis like eclipse/idea.

ok, I'll take another look - I understand how the observers work, but IIRC the
oberver is created in get/putTransfer. What I'm proposing is that we modify that
(and the SSH one that doesn't use it) to take a richer definition of the
source/dest so it can construct the observers rather than continually appending

I think it just needs an input/output def like get/put do themselves, with the
additional info populated by get/put.

This morning I removed one of the parameters to get/putTransfer (the local
FileInputStream/LazyFileOutputStream) because it was always created the same and
some of the handling was duplicated and unnecessarily different.

Actually, thinking about it, I'm not sure why SSH/HTTP wagon shouldn't just be a
stream wagon with a customised stream. That way more shared handling could be in
the core.


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

View raw message