Hey Oleg, On Thu, 2008-09-04 at 14:00 -0700, Oleg Gusakov wrote: > I tried to create mercury-based wagon provider and got overwhelmed with > Wagon's strange architecture decisions and APIs. > > First of all - inheriting from AbstractWagon and implementing required > methods took 20 min - excellent! The rest two days (are still being) > spent trying to understand: > > - wagon-tests - I assume it's integration tests every provider has to pass? > > - why do tests requite provider to fire events, especially TRANSFER > event? What happens when provider has much higher up APIs and does not > control the transfer process? What if provider does not want to share > events - why mandate them by the tests ??
Because these are used to track download progress - if you are using a Stream based protocol then the StreamWagon abstract class will take care of this for you. What protocol are you trying to implement? > > - why tests rely on the Resource object, while it's not manipulated > anywhere in the APIs? Necessity to create on per each put or get > represents an object leak for me. Especially highly artificial sequence > of populating this object with data - set content length before > Initiated event and tests fail. > > - what is the exact combination of Resource manipulation in the get > operation? I tried several and am still missing what should be filled in > when: resource (local file, I assume?) is empty when firing > getInitialized(), but tests fail, saying they expected resource with a > content length and timestamp. ... any help is greatly appreciated! > > - where did getFileList() come from?? HTTP provider, for example, cannot > do it without scrapping a page, and if repository has different indexing > formats/options - it will not work. And tests fail I don't implement > one. After all - this is why maven-metadata.xml exists! I've never been a fan of the scraping myself either - thats one of the reasons I recommend webdav. > > - where did resourceExists() come from? In HTTP provider it is not > possible without a try-and-fail cycle, which slows everything down - bad > choice. This is why maven-metadata.xml exists! > > - why such fascination with getIfNewer() in the APIs? This notion is > external to a dumb http server and the suggested unix-like timestamp may > yield wrong results by as much as 24 hours, depending on the server and > client locations. This is why we use UTC timestamps in the metadata > files .. and that is why metadata files exist :) Oleg - HTTP 1.1 RFC2616 Section 3.3.1 specifies that the HTTP-Date type MUST be represented in GMT - so a servers last-modified header should reflect this. http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1 getIfNewer() is used to short circuit the fetching of metadata files - if the file is reported older than the one you have locally then there is no need to download it. > > Overall impression is not too favorable. I am trying to jump the hoops > in order to pass the tests. If somebody has any insights, please help! > Maybe some write ups somewhere: how to satisfy wagon-provider-tests? One thing you will learn when working with Wagon is this: its not designed - it grew with Maven. Projects like Mercury (being used in trunk soon?) are going to simply this by having a rethink about what operations work best for accessing data from repositories. Until that eventuates we are stuck with Wagon. Cheers James > > Thanks, > Oleg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
