maven-wagon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Maczka <>
Subject Re: New interfaces in Wagon
Date Thu, 01 Apr 2004 07:35:27 GMT
Jason van Zyl wrote:

>On Thu, 2004-04-01 at 01:05, Michal Maczka wrote:
>>Jason van Zyl wrote:
>>I don't agree that everything was that badly tested! Wagon API  module 
>>was tested in 98% (clover)  and that's where all those things were 
>>You can hardly do any better!!!
>>In there I  defined interfaces like WagonSource  WagonResult  and 
>>provided fully tested implementation of them like for example 
>>MemoryResult which I wanted to use for transfering "to memory". Only 
>>thing which was abolutly not tested were Wagon Providers.
>>But I completly agree that some intention which I had weren't that 
>>obvious and clear and still that many thing could be simplified. E.g 
>>instead of WagonResult probably just OutputStream might be used. That's 
>>why  I am trying to explain some things now and I am glad that finally I 
>>have to defend my vison.
>>For example the exmplanaion why such "artificial" things like event in 
>>Wagon exists is simple. 
>>I wanted to use events for informing transfer observers like those which 
>>can compute message digests of input stream. Other use case I wanted to 
>>support  is to display progress bars once Maven with Wagon will be 
>>integrated with GUI/IDE.  I hoped that this would make it even more 
>>All other liblaries I know of simply do not support such feature.
>>>I also believe the Wagon interface is a
>>>balance between simplicity and functionality. It's easy to make simple
>>>stream based wagons and the interface in the WagonManager/Conducter will
>>>eventually be. Let me do the round trip with integrating Wagon into
>>>Maven first.
>>OK. I  still belive that too much of useful functinality was removed. I 
>>also belive that we could build on top of  that what it was
>>the  layer  which could be even simpler to use then what we have now. I 
>>think that I know well what you want to achive as i feel that you are 
>>my early ideas. I spent couple weeks implementing and during those few weeks
>>wagon was oscilting between something very easy and something horribly 
>>complicated. I change my mind couple of times reagrding the API but I 
>>tried to implement something simple and extendible.
>It was still too complicated, and there were too many places where
>simple mistakes could be made in creating wagons that yielded a
>non-functional wagon. It happened to me twice and if it happened to me
>it will happen to others. 

I know that it had some complicity. I just thought and still think that 
this complexity could be completly removed
by the introduction of one more layer on top of Wagon.

interface ArtifactDownloader

>If you have knowledge of the client library all you have to do is know
>how to get an InputStream and an OutputStream. That's it. It doesn't get
>much simpler than that. And if you need to go down to the bare metal you
>can as you have to in the scp wagon.
I completly agree.  

>Adding streaming capabilities might possibly be desirable but the bottom
>line is you haven't had time to touch the code in months and there were
>no visible tests for the wagons 
The lack of time was not at all the reason why devlopment was stopped. 
It was stopped as it was nothing with what wagon could be integrated
and some feature in plexus were missing. But first of all I waited for 
that moment which come just now when somebody finally will give me some 

>and the wagons themselves just too
>complicated as examples for people to follow. 

I never designed Wagon to be the liblary used by the crowd of people. I 
always thought about Maven as the only client of Wagon and people
using Wagon only with conjuction with the API which will be decided by 
needs of Maven and exposed in Maven Components.

>This week I will finish a more exhaustive test suite, finish off some
>docs, alter the verifiers to work with streams and release 0.9 and
>integrate it into Maven. 
>It's all stream-based underneath so it wouldn't be hard at all to expose
>those again but I'm willing to bet the vast majority of usage will be
>moving files around.
I might agree with that.   But I did't want to predict what are the 
possible use cases we might have and to leave some more possibilities open.
Coming back to my example when you want to transfer a war file which has 
20 MB, MD5 and SHA1 files to the repository
What I wanted to support with Wagon is that you can have just one disk 
I/O operation and the rest will happen on the fly.
So MD5 and SHA1 will be constructed in the memory and  they will be 
never written to disk.

Other scenrio just looks like:

1. Read war (20 MB) and send it to the repository
2. Read war (20 MB) and compute SHA1 message digiest
3. Save it to the file
4. Read that file and send it to the repository
5. Read war (20 MB) and compute MD5 message digest
6. Save it to the file
7. Read that file and send it to the repository

So totaly you have 7 I/O operations. And that's exactly what I am doing 
now in maven-artifact plugin.
I just think that we can do way better then that!


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

View raw message