Re: wagon's resourceExists() call efficiency ?
I apologize for dragging this out. I looked at AbstractWagon and do see that it implements resourceExists by throwing the UnsupportedOperationException. For clarity this really should be declared in the Wagon interface even though it is a RuntimeException. I also looked at all the existing Wagon providers and noticed that they all seem to implement the method - meaning the method provided by AbstractWagon was previously never used by anything. I then looked at Google and Krugle to see what might be calling resourceExists. I can see that if your Wagon implementation is used by the maven-project-info-reports-plugin that when it calls the dependencyExistsInRepo method of the RepositoryUtils class the UnsupportedOperationException will not be handled. I also notice that Spring seems to have implemented at least one Wagon of its own - to access the Amazon S3 service. I wonder how this gets used? I wonder why they don't just use Maven's implementation? It might also be useful to look at http://jira.codehaus.org/browse/WAGON-58 which documents why the resourceExists method was added. From what I can tell resourceExists was added to support the maven-project-info-reports-plugin. You wanted a case where HEAD is not followed by GET? Here it is. Ralph Oleg Gusakov wrote: Man, I did not want to talk about this any more .. but cannot help it, as this is about a second half of the issue. Ralph Goers wrote: Perhaps. Except that resourceExists is still NOT an optional method. If developer follows a stable dev. pattern, in this case: create a new wagon provider by extending AbstractWagon - and is not mandated by the language to implement a method, this to me constitutes an optional method. If I would not try to pass ITs, I'd never suspect that method even exists! We are out of the woods, we use a language that allows us to express what we want. And I dare say that knowledge and experience of any single individual on this list goes far beyond a simple task of mandating something deemed not optional - in this case declare an abstract method in abstract class. And let's stop this thread, too much about nothing :) Thanks, Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: wagon's resourceExists() call efficiency ?
We should just put it into the abstract class and make it required. If the goal of the mercury wagon is to replace the http one, then it should implement the same methods and be completely drop-in capable (sounds like you did implement it already). And since it's so confusing by having this sort-of optional method, let's just make it clear and make it required. -Original Message- From: Ralph Goers [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 3:33 AM To: Maven Developers List Subject: Re: wagon's resourceExists() call efficiency ? I apologize for dragging this out. I looked at AbstractWagon and do see that it implements resourceExists by throwing the UnsupportedOperationException. For clarity this really should be declared in the Wagon interface even though it is a RuntimeException. I also looked at all the existing Wagon providers and noticed that they all seem to implement the method - meaning the method provided by AbstractWagon was previously never used by anything. I then looked at Google and Krugle to see what might be calling resourceExists. I can see that if your Wagon implementation is used by the maven-project-info-reports-plugin that when it calls the dependencyExistsInRepo method of the RepositoryUtils class the UnsupportedOperationException will not be handled. I also notice that Spring seems to have implemented at least one Wagon of its own - to access the Amazon S3 service. I wonder how this gets used? I wonder why they don't just use Maven's implementation? It might also be useful to look at http://jira.codehaus.org/browse/WAGON-58 which documents why the resourceExists method was added. From what I can tell resourceExists was added to support the maven-project-info-reports-plugin. You wanted a case where HEAD is not followed by GET? Here it is. Ralph Oleg Gusakov wrote: Man, I did not want to talk about this any more .. but cannot help it, as this is about a second half of the issue. Ralph Goers wrote: Perhaps. Except that resourceExists is still NOT an optional method. If developer follows a stable dev. pattern, in this case: create a new wagon provider by extending AbstractWagon - and is not mandated by the language to implement a method, this to me constitutes an optional method. If I would not try to pass ITs, I'd never suspect that method even exists! We are out of the woods, we use a language that allows us to express what we want. And I dare say that knowledge and experience of any single individual on this list goes far beyond a simple task of mandating something deemed not optional - in this case declare an abstract method in abstract class. And let's stop this thread, too much about nothing :) Thanks, Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wagon's resourceExists() call efficiency ?
I'm not sure I understand. If I was to implement this I would imagine that the deployer would want to call resourceExists() to find out whether to deploy or not. The fact that resourceExists() can check the metadata vs the actual file would seem to me to be an implementation choice for the author of the resourceExists method, not the author of the deployer code. Next, I admit, I haven't looked much at the Wagon classes. But I glanced at https://svn.apache.org/repos/asf/maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/Wagon.java. I don't see anything in the javadoc indicating the method is optional. A search for wagon site:maven.apache.org didn't yield anything either. In fact, it is hard to imagine how it could be since it returns a boolean and the only documented Exceptions are TransferFailedException and AuthorizationException. I would expect to see UnsupportedOperationException at least mentioned if it was optional. So please tell me where this method is described as optional. Finally, Yes, I use Nexus and I would also want it to be able to enforce this, but it should really be built into Maven. I'm a little unclear why you are saying Maven should update the metadata for an already deployed artifact. Ralph Oleg Gusakov wrote: But this information comes from repository metadata, not from probing the actual file. If it does - repository integrity is broken, isn't it? Deploy should read the metadata anyway as it is supposed to update [in a dumb http/dav repository, Nexus can do it for us], so if version is not in metadata, or metadata read failed it's equivalent to resource does not exist, but now you have much more information to act upon. Ralph Goers wrote: Yes. I would actually like the deploy plugin to NOT deploy a non-SNAPSHOT artifact if it is already there. Oleg Gusakov wrote: I cannot imagine a use case where you would check that artifact exists in the remote repository and then don't download it. Can you? - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wagon's resourceExists() call efficiency ?
Ralph Goers wrote: I'm not sure I understand. If I was to implement this I would imagine that the deployer would want to call resourceExists() to find out whether to deploy or not. The fact that resourceExists() can check the metadata vs the actual file would seem to me to be an implementation choice for the author of the resourceExists method, not the author of the deployer code. Think how resourceExists() could be implemented by http provider: 1. send HEAD and look for 404 2. send GET and look for 404 If resource does not exist, you get one network roundtrip in both. If resource exists and you want it 1. you have to send a GET request - second network trip to get contents 2. you already are receiving the contents So in reality - there is no benefit in separating the resourceExists() and resourceGet() on transport level. I don't argue it's existence in above transport layers: implement it as transport's getResource() and wait for failure. But wagon IS our transport layer, and it tries to impose higher level call to lower level protocol. It should stay in the Wagon APIs, and if wagon provider does not implement it - integration tests should not fail. This is what this argument is about. Next, I admit, I haven't looked much at the Wagon classes. But I glanced at https://svn.apache.org/repos/asf/maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/Wagon.java. I don't see anything in the javadoc indicating the method is optional. A search for wagon site:maven.apache.org didn't yield anything either. In fact, it is hard to imagine how it could be since it returns a boolean and the only documented Exceptions are TransferFailedException and AuthorizationException. I would expect to see UnsupportedOperationException at least mentioned if it was optional. You'll be surprised to learn, that another optional method setHttpHeaders() is discovered via reflection, and cause 2 or 3 tests fail if it does not exists! I found it so obviously wrong that I did not mention it in the discussion. So please tell me where this method is described as optional. If you use Wagon way of writing providers and inherit from AbstractWagon, you are good to go without too much trouble. To me - it's optional. Although in AbstractWagon there are several methods like this - they throw Unsupported... exception if called. ITs only call this one. Normally - if you want to mandate something - declare it abstract, right? But then suddenly you hit an IT that fails, complaining that resourceExists() is not implemented by wagon. That is wrong. Finally, Yes, I use Nexus and I would also want it to be able to enforce this, but it should really be built into Maven. I'm a little unclear why you are saying Maven should update the metadata for an already deployed artifact. You don't have to update metadata for a deployed release, but you should check it's existence in the metadata. Because if it exists, you don't have to do anything, if it does not - you already have metadata and can modify it and send back, together with the artifact. Thanks, Oleg Ralph Oleg Gusakov wrote: But this information comes from repository metadata, not from probing the actual file. If it does - repository integrity is broken, isn't it? Deploy should read the metadata anyway as it is supposed to update [in a dumb http/dav repository, Nexus can do it for us], so if version is not in metadata, or metadata read failed it's equivalent to resource does not exist, but now you have much more information to act upon. Ralph Goers wrote: Yes. I would actually like the deploy plugin to NOT deploy a non-SNAPSHOT artifact if it is already there. Oleg Gusakov wrote: I cannot imagine a use case where you would check that artifact exists in the remote repository and then don't download it. Can you? - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wagon's resourceExists() call efficiency ?
See below. Oleg Gusakov wrote: Think how resourceExists() could be implemented by http provider: 1. send HEAD and look for 404 2. send GET and look for 404 If resource does not exist, you get one network roundtrip in both. Yes, but HEAD doesn't return the data so will be more efficient on larger sized objects. If resource exists and you want it 1. you have to send a GET request - second network trip to get contents 2. you already are receiving the contents Not necessarily. I can envision other ways to do this, but this is probably the way I would do it. So in reality - there is no benefit in separating the resourceExists() and resourceGet() on transport level. I don't argue it's existence in above transport layers: implement it as transport's getResource() and wait for failure. You are assuming that GET is the only thing you ever want to do. The use case I am concerned about is PUT. If I do mvn deploy I want to do a request to see if it exists and then do a PUT if it doesn't. Since HEAD is cheaper than GET in this case that would be preferable. But wagon IS our transport layer, and it tries to impose higher level call to lower level protocol. It should stay in the Wagon APIs, and if wagon provider does not implement it - integration tests should not fail. This is what this argument is about. I understand the argument about why ITs shouldn't fail if a Wagon provider doesn't implement something. I'm just saying I see no evidence that resourceExists is actually optional. I have also demonstrated a use case where resourceExists using HEAD makes more sense than doing a GET. Next, I admit, I haven't looked much at the Wagon classes. But I glanced at https://svn.apache.org/repos/asf/maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/Wagon.java. I don't see anything in the javadoc indicating the method is optional. A search for wagon site:maven.apache.org didn't yield anything either. In fact, it is hard to imagine how it could be since it returns a boolean and the only documented Exceptions are TransferFailedException and AuthorizationException. I would expect to see UnsupportedOperationException at least mentioned if it was optional. You'll be surprised to learn, that another optional method setHttpHeaders() is discovered via reflection, and cause 2 or 3 tests fail if it does not exists! I found it so obviously wrong that I did not mention it in the discussion. No, I'm not surprised. setHttpHeaders isn't defined in the Wagon interface and so is truly optional. resourceExists IS defined there and is therefore NOT optional. So please tell me where this method is described as optional. If you use Wagon way of writing providers and inherit from AbstractWagon, you are good to go without too much trouble. To me - it's optional. Although in AbstractWagon there are several methods like this - they throw Unsupported... exception if called. ITs only call this one. Normally - if you want to mandate something - declare it abstract, right? No. If a method is defined in an interface it is NOT optional. Something must eventually define the method. Even an abstract method must eventually being implemented. The only ways a method can be optional is for it NOT to be declared in an interface or for it to be defined as throwing an exception that indicates to the caller that it is not always implemented. But then suddenly you hit an IT that fails, complaining that resourceExists() is not implemented by wagon. That is wrong. No, that is correct for a non-optional method. Finally, Yes, I use Nexus and I would also want it to be able to enforce this, but it should really be built into Maven. I'm a little unclear why you are saying Maven should update the metadata for an already deployed artifact. You don't have to update metadata for a deployed release, but you should check it's existence in the metadata. Because if it exists, you don't have to do anything, if it does not - you already have metadata and can modify it and send back, together with the artifact. My understanding is that the metadata should exist along with the artifact. Either both should exist or neither. If any of them exist I shouldn't have to do anything. If any of them do not then the deploy didn't succeed. Ideally all these items should be deployed to the repository as one atomic operation. I realize that that is not the case today (and is precisely why I've heard proposals to replace the repository with a database). Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wagon's resourceExists() call efficiency ?
Oleg you are mixing the use of this method with the method being inefficient. Executing head is not ineficient so there's no reason to exclude it in the new wagon. Taking it away simply because someone could be dumb doesn't sense, especially since we already have on valid use case for it. Sent from my iPhone On Sep 29, 2008, at 12:12 PM, Oleg Gusakov [EMAIL PROTECTED] wrote: Ralph Goers wrote: I'm not sure I understand. If I was to implement this I would imagine that the deployer would want to call resourceExists() to find out whether to deploy or not. The fact that resourceExists() can check the metadata vs the actual file would seem to me to be an implementation choice for the author of the resourceExists method, not the author of the deployer code. Think how resourceExists() could be implemented by http provider: 1. send HEAD and look for 404 2. send GET and look for 404 If resource does not exist, you get one network roundtrip in both. If resource exists and you want it 1. you have to send a GET request - second network trip to get contents 2. you already are receiving the contents So in reality - there is no benefit in separating the resourceExists() and resourceGet() on transport level. I don't argue it's existence in above transport layers: implement it as transport's getResource() and wait for failure. But wagon IS our transport layer, and it tries to impose higher level call to lower level protocol. It should stay in the Wagon APIs, and if wagon provider does not implement it - integration tests should not fail. This is what this argument is about. Next, I admit, I haven't looked much at the Wagon classes. But I glanced at https://svn.apache.org/repos/asf/maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/Wagon.java . I don't see anything in the javadoc indicating the method is optional. A search for wagon site:maven.apache.org didn't yield anything either. In fact, it is hard to imagine how it could be since it returns a boolean and the only documented Exceptions are TransferFailedException and AuthorizationException. I would expect to see UnsupportedOperationException at least mentioned if it was optional. You'll be surprised to learn, that another optional method setHttpHeaders() is discovered via reflection, and cause 2 or 3 tests fail if it does not exists! I found it so obviously wrong that I did not mention it in the discussion. So please tell me where this method is described as optional. If you use Wagon way of writing providers and inherit from AbstractWagon, you are good to go without too much trouble. To me - it's optional. Although in AbstractWagon there are several methods like this - they throw Unsupported... exception if called. ITs only call this one. Normally - if you want to mandate something - declare it abstract, right? But then suddenly you hit an IT that fails, complaining that resourceExists() is not implemented by wagon. That is wrong. Finally, Yes, I use Nexus and I would also want it to be able to enforce this, but it should really be built into Maven. I'm a little unclear why you are saying Maven should update the metadata for an already deployed artifact. You don't have to update metadata for a deployed release, but you should check it's existence in the metadata. Because if it exists, you don't have to do anything, if it does not - you already have metadata and can modify it and send back, together with the artifact. Thanks, Oleg Ralph Oleg Gusakov wrote: But this information comes from repository metadata, not from probing the actual file. If it does - repository integrity is broken, isn't it? Deploy should read the metadata anyway as it is supposed to update [in a dumb http/dav repository, Nexus can do it for us], so if version is not in metadata, or metadata read failed it's equivalent to resource does not exist, but now you have much more information to act upon. Ralph Goers wrote: Yes. I would actually like the deploy plugin to NOT deploy a non- SNAPSHOT artifact if it is already there. Oleg Gusakov wrote: I cannot imagine a use case where you would check that artifact exists in the remote repository and then don't download it. Can you? --- -- 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] - 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]
Re: wagon's resourceExists() call efficiency ?
I implemented this method to pass ITs, it's existence is off the table. Brian Fox wrote: Oleg you are mixing the use of this method with the method being inefficient. Executing head is not ineficient Agree so there's no reason to exclude it in the new wagon. Don't agree - as there still is no a valid use case of HEAD, not followed by GET. The deploy plugin checking for a released artifact present in a remote repo, does not stand, in my opinion, as HEAD A-V.jar should instead be GET a maven-metadata.xml and check for V there. It's more efficient because: * if V is not in metadata, deploy plugin will have to read metadata anyway * if V is already in metadata, we did not loose too much. If in 50% cases artifact is not present - we save a lot of network rountrips (GET that will follow that HEAD). Even if it's ot present in, say 20% cases - we by far compensated for the difference between HEAD and GET metadata.xml. Additional consideration: metadata.xml is relatively small, and will fit in the same ip packet as response for HEAD thus producing no difference at all. On average - not having HEAD improves efficiency of repository lookup. Thanks, Oleg Taking it away simply because someone could be dumb doesn't sense, especially since we already have on valid use case for it. Sent from my iPhone On Sep 29, 2008, at 12:12 PM, Oleg Gusakov [EMAIL PROTECTED] wrote: Ralph Goers wrote: I'm not sure I understand. If I was to implement this I would imagine that the deployer would want to call resourceExists() to find out whether to deploy or not. The fact that resourceExists() can check the metadata vs the actual file would seem to me to be an implementation choice for the author of the resourceExists method, not the author of the deployer code. Think how resourceExists() could be implemented by http provider: 1. send HEAD and look for 404 2. send GET and look for 404 If resource does not exist, you get one network roundtrip in both. If resource exists and you want it 1. you have to send a GET request - second network trip to get contents 2. you already are receiving the contents So in reality - there is no benefit in separating the resourceExists() and resourceGet() on transport level. I don't argue it's existence in above transport layers: implement it as transport's getResource() and wait for failure. But wagon IS our transport layer, and it tries to impose higher level call to lower level protocol. It should stay in the Wagon APIs, and if wagon provider does not implement it - integration tests should not fail. This is what this argument is about. Next, I admit, I haven't looked much at the Wagon classes. But I glanced at https://svn.apache.org/repos/asf/maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/Wagon.java. I don't see anything in the javadoc indicating the method is optional. A search for wagon site:maven.apache.org didn't yield anything either. In fact, it is hard to imagine how it could be since it returns a boolean and the only documented Exceptions are TransferFailedException and AuthorizationException. I would expect to see UnsupportedOperationException at least mentioned if it was optional. You'll be surprised to learn, that another optional method setHttpHeaders() is discovered via reflection, and cause 2 or 3 tests fail if it does not exists! I found it so obviously wrong that I did not mention it in the discussion. So please tell me where this method is described as optional. If you use Wagon way of writing providers and inherit from AbstractWagon, you are good to go without too much trouble. To me - it's optional. Although in AbstractWagon there are several methods like this - they throw Unsupported... exception if called. ITs only call this one. Normally - if you want to mandate something - declare it abstract, right? But then suddenly you hit an IT that fails, complaining that resourceExists() is not implemented by wagon. That is wrong. Finally, Yes, I use Nexus and I would also want it to be able to enforce this, but it should really be built into Maven. I'm a little unclear why you are saying Maven should update the metadata for an already deployed artifact. You don't have to update metadata for a deployed release, but you should check it's existence in the metadata. Because if it exists, you don't have to do anything, if it does not - you already have metadata and can modify it and send back, together with the artifact. Thanks, Oleg Ralph Oleg Gusakov wrote: But this information comes from repository metadata, not from probing the actual file. If it does - repository integrity is broken, isn't it? Deploy should read the metadata anyway as it is supposed to update [in a dumb http/dav repository, Nexus can do it for us], so if version is not in metadata, or metadata read failed it's equivalent to resource does not exist, but now you have much more information
Re: wagon's resourceExists() call efficiency ?
Not all artifacts can be discovered via metadata so it's not safe to assume you can always check there. Sent from my iPhone On Sep 29, 2008, at 10:08 PM, Oleg Gusakov [EMAIL PROTECTED] wrote: I implemented this method to pass ITs, it's existence is off the table. Brian Fox wrote: Oleg you are mixing the use of this method with the method being inefficient. Executing head is not ineficient Agree so there's no reason to exclude it in the new wagon. Don't agree - as there still is no a valid use case of HEAD, not followed by GET. The deploy plugin checking for a released artifact present in a remote repo, does not stand, in my opinion, as HEAD A-V.jar should instead be GET a maven-metadata.xml and check for V there. It's more efficient because: * if V is not in metadata, deploy plugin will have to read metadata anyway * if V is already in metadata, we did not loose too much. If in 50% cases artifact is not present - we save a lot of network rountrips (GET that will follow that HEAD). Even if it's ot present in, say 20% cases - we by far compensated for the difference between HEAD and GET metadata.xml. Additional consideration: metadata.xml is relatively small, and will fit in the same ip packet as response for HEAD thus producing no difference at all. On average - not having HEAD improves efficiency of repository lookup. Thanks, Oleg Taking it away simply because someone could be dumb doesn't sense, especially since we already have on valid use case for it. Sent from my iPhone On Sep 29, 2008, at 12:12 PM, Oleg Gusakov [EMAIL PROTECTED] wrote: Ralph Goers wrote: I'm not sure I understand. If I was to implement this I would imagine that the deployer would want to call resourceExists() to find out whether to deploy or not. The fact that resourceExists() can check the metadata vs the actual file would seem to me to be an implementation choice for the author of the resourceExists method, not the author of the deployer code. Think how resourceExists() could be implemented by http provider: 1. send HEAD and look for 404 2. send GET and look for 404 If resource does not exist, you get one network roundtrip in both. If resource exists and you want it 1. you have to send a GET request - second network trip to get contents 2. you already are receiving the contents So in reality - there is no benefit in separating the resourceExists() and resourceGet() on transport level. I don't argue it's existence in above transport layers: implement it as transport's getResource() and wait for failure. But wagon IS our transport layer, and it tries to impose higher level call to lower level protocol. It should stay in the Wagon APIs, and if wagon provider does not implement it - integration tests should not fail. This is what this argument is about. Next, I admit, I haven't looked much at the Wagon classes. But I glanced at https://svn.apache.org/repos/asf/maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/Wagon.java . I don't see anything in the javadoc indicating the method is optional. A search for wagon site:maven.apache.org didn't yield anything either. In fact, it is hard to imagine how it could be since it returns a boolean and the only documented Exceptions are TransferFailedException and AuthorizationException. I would expect to see UnsupportedOperationException at least mentioned if it was optional. You'll be surprised to learn, that another optional method setHttpHeaders() is discovered via reflection, and cause 2 or 3 tests fail if it does not exists! I found it so obviously wrong that I did not mention it in the discussion. So please tell me where this method is described as optional. If you use Wagon way of writing providers and inherit from AbstractWagon, you are good to go without too much trouble. To me - it's optional. Although in AbstractWagon there are several methods like this - they throw Unsupported... exception if called. ITs only call this one. Normally - if you want to mandate something - declare it abstract, right? But then suddenly you hit an IT that fails, complaining that resourceExists() is not implemented by wagon. That is wrong. Finally, Yes, I use Nexus and I would also want it to be able to enforce this, but it should really be built into Maven. I'm a little unclear why you are saying Maven should update the metadata for an already deployed artifact. You don't have to update metadata for a deployed release, but you should check it's existence in the metadata. Because if it exists, you don't have to do anything, if it does not - you already have metadata and can modify it and send back, together with the artifact. Thanks, Oleg Ralph Oleg Gusakov wrote: But this information comes from repository metadata, not from probing the actual file. If it does - repository integrity is broken, isn't it? Deploy should read
Re: wagon's resourceExists() call efficiency ?
Brian Fox wrote: Not all artifacts can be discovered via metadata so it's not safe to assume you can always check there. Classifiers? Same argument: GET vs. HEAD, followed by GET. I cannot imagine a use case where one would check that -sources.jar exists in the remote repo without downloading it. Poorly maintained repository - yes. Overall - I think we exhauted the topic :) This discussion does not make sense without a solid use case of HEAD not followed by GET, don't you agree? Thanks, Oleg Sent from my iPhone On Sep 29, 2008, at 10:08 PM, Oleg Gusakov [EMAIL PROTECTED] wrote: I implemented this method to pass ITs, it's existence is off the table. Brian Fox wrote: Oleg you are mixing the use of this method with the method being inefficient. Executing head is not ineficient Agree so there's no reason to exclude it in the new wagon. Don't agree - as there still is no a valid use case of HEAD, not followed by GET. The deploy plugin checking for a released artifact present in a remote repo, does not stand, in my opinion, as HEAD A-V.jar should instead be GET a maven-metadata.xml and check for V there. It's more efficient because: * if V is not in metadata, deploy plugin will have to read metadata anyway * if V is already in metadata, we did not loose too much. If in 50% cases artifact is not present - we save a lot of network rountrips (GET that will follow that HEAD). Even if it's ot present in, say 20% cases - we by far compensated for the difference between HEAD and GET metadata.xml. Additional consideration: metadata.xml is relatively small, and will fit in the same ip packet as response for HEAD thus producing no difference at all. On average - not having HEAD improves efficiency of repository lookup. Thanks, Oleg Taking it away simply because someone could be dumb doesn't sense, especially since we already have on valid use case for it. Sent from my iPhone On Sep 29, 2008, at 12:12 PM, Oleg Gusakov [EMAIL PROTECTED] wrote: Ralph Goers wrote: I'm not sure I understand. If I was to implement this I would imagine that the deployer would want to call resourceExists() to find out whether to deploy or not. The fact that resourceExists() can check the metadata vs the actual file would seem to me to be an implementation choice for the author of the resourceExists method, not the author of the deployer code. Think how resourceExists() could be implemented by http provider: 1. send HEAD and look for 404 2. send GET and look for 404 If resource does not exist, you get one network roundtrip in both. If resource exists and you want it 1. you have to send a GET request - second network trip to get contents 2. you already are receiving the contents So in reality - there is no benefit in separating the resourceExists() and resourceGet() on transport level. I don't argue it's existence in above transport layers: implement it as transport's getResource() and wait for failure. But wagon IS our transport layer, and it tries to impose higher level call to lower level protocol. It should stay in the Wagon APIs, and if wagon provider does not implement it - integration tests should not fail. This is what this argument is about. Next, I admit, I haven't looked much at the Wagon classes. But I glanced at https://svn.apache.org/repos/asf/maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/Wagon.java. I don't see anything in the javadoc indicating the method is optional. A search for wagon site:maven.apache.org didn't yield anything either. In fact, it is hard to imagine how it could be since it returns a boolean and the only documented Exceptions are TransferFailedException and AuthorizationException. I would expect to see UnsupportedOperationException at least mentioned if it was optional. You'll be surprised to learn, that another optional method setHttpHeaders() is discovered via reflection, and cause 2 or 3 tests fail if it does not exists! I found it so obviously wrong that I did not mention it in the discussion. So please tell me where this method is described as optional. If you use Wagon way of writing providers and inherit from AbstractWagon, you are good to go without too much trouble. To me - it's optional. Although in AbstractWagon there are several methods like this - they throw Unsupported... exception if called. ITs only call this one. Normally - if you want to mandate something - declare it abstract, right? But then suddenly you hit an IT that fails, complaining that resourceExists() is not implemented by wagon. That is wrong. Finally, Yes, I use Nexus and I would also want it to be able to enforce this, but it should really be built into Maven. I'm a little unclear why you are saying Maven should update the metadata for an already deployed artifact. You don't have to update metadata for a deployed release, but you should check it's existence in the metadata. Because if it exists,
Re: wagon's resourceExists() call efficiency ?
Perhaps. Except that resourceExists is still NOT an optional method. If you change it so that it is you might as well just remove it entirely. The whole point of the method is to use a less expensive method to check if the resource exists. By allowing it to through an exception and force the caller to revert to actually getting the resource you will be making it so unusuable that no one ever will. Oleg Gusakov wrote: Brian Fox wrote: Not all artifacts can be discovered via metadata so it's not safe to assume you can always check there. Classifiers? Same argument: GET vs. HEAD, followed by GET. I cannot imagine a use case where one would check that -sources.jar exists in the remote repo without downloading it. Poorly maintained repository - yes. Overall - I think we exhauted the topic :) This discussion does not make sense without a solid use case of HEAD not followed by GET, don't you agree? Thanks, Oleg Sent from my iPhone On Sep 29, 2008, at 10:08 PM, Oleg Gusakov [EMAIL PROTECTED] wrote: I implemented this method to pass ITs, it's existence is off the table. Brian Fox wrote: Oleg you are mixing the use of this method with the method being inefficient. Executing head is not ineficient Agree so there's no reason to exclude it in the new wagon. Don't agree - as there still is no a valid use case of HEAD, not followed by GET. The deploy plugin checking for a released artifact present in a remote repo, does not stand, in my opinion, as HEAD A-V.jar should instead be GET a maven-metadata.xml and check for V there. It's more efficient because: * if V is not in metadata, deploy plugin will have to read metadata anyway * if V is already in metadata, we did not loose too much. If in 50% cases artifact is not present - we save a lot of network rountrips (GET that will follow that HEAD). Even if it's ot present in, say 20% cases - we by far compensated for the difference between HEAD and GET metadata.xml. Additional consideration: metadata.xml is relatively small, and will fit in the same ip packet as response for HEAD thus producing no difference at all. On average - not having HEAD improves efficiency of repository lookup. Thanks, Oleg Taking it away simply because someone could be dumb doesn't sense, especially since we already have on valid use case for it. Sent from my iPhone On Sep 29, 2008, at 12:12 PM, Oleg Gusakov [EMAIL PROTECTED] wrote: Ralph Goers wrote: I'm not sure I understand. If I was to implement this I would imagine that the deployer would want to call resourceExists() to find out whether to deploy or not. The fact that resourceExists() can check the metadata vs the actual file would seem to me to be an implementation choice for the author of the resourceExists method, not the author of the deployer code. Think how resourceExists() could be implemented by http provider: 1. send HEAD and look for 404 2. send GET and look for 404 If resource does not exist, you get one network roundtrip in both. If resource exists and you want it 1. you have to send a GET request - second network trip to get contents 2. you already are receiving the contents So in reality - there is no benefit in separating the resourceExists() and resourceGet() on transport level. I don't argue it's existence in above transport layers: implement it as transport's getResource() and wait for failure. But wagon IS our transport layer, and it tries to impose higher level call to lower level protocol. It should stay in the Wagon APIs, and if wagon provider does not implement it - integration tests should not fail. This is what this argument is about. Next, I admit, I haven't looked much at the Wagon classes. But I glanced at https://svn.apache.org/repos/asf/maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/Wagon.java. I don't see anything in the javadoc indicating the method is optional. A search for wagon site:maven.apache.org didn't yield anything either. In fact, it is hard to imagine how it could be since it returns a boolean and the only documented Exceptions are TransferFailedException and AuthorizationException. I would expect to see UnsupportedOperationException at least mentioned if it was optional. You'll be surprised to learn, that another optional method setHttpHeaders() is discovered via reflection, and cause 2 or 3 tests fail if it does not exists! I found it so obviously wrong that I did not mention it in the discussion. So please tell me where this method is described as optional. If you use Wagon way of writing providers and inherit from AbstractWagon, you are good to go without too much trouble. To me - it's optional. Although in AbstractWagon there are several methods like this - they throw Unsupported... exception if called. ITs only call this one. Normally - if you want to mandate something - declare it abstract, right? But then suddenly you hit an IT that fails, complaining
Re: wagon's resourceExists() call efficiency ?
Man, I did not want to talk about this any more .. but cannot help it, as this is about a second half of the issue. Ralph Goers wrote: Perhaps. Except that resourceExists is still NOT an optional method. If developer follows a stable dev. pattern, in this case: create a new wagon provider by extending AbstractWagon - and is not mandated by the language to implement a method, this to me constitutes an optional method. If I would not try to pass ITs, I'd never suspect that method even exists! We are out of the woods, we use a language that allows us to express what we want. And I dare say that knowledge and experience of any single individual on this list goes far beyond a simple task of mandating something deemed not optional - in this case declare an abstract method in abstract class. And let's stop this thread, too much about nothing :) Thanks, Oleg If you change it so that it is you might as well just remove it entirely. The whole point of the method is to use a less expensive method to check if the resource exists. By allowing it to through an exception and force the caller to revert to actually getting the resource you will be making it so unusuable that no one ever will. Oleg Gusakov wrote: Brian Fox wrote: Not all artifacts can be discovered via metadata so it's not safe to assume you can always check there. Classifiers? Same argument: GET vs. HEAD, followed by GET. I cannot imagine a use case where one would check that -sources.jar exists in the remote repo without downloading it. Poorly maintained repository - yes. Overall - I think we exhauted the topic :) This discussion does not make sense without a solid use case of HEAD not followed by GET, don't you agree? Thanks, Oleg Sent from my iPhone On Sep 29, 2008, at 10:08 PM, Oleg Gusakov [EMAIL PROTECTED] wrote: I implemented this method to pass ITs, it's existence is off the table. Brian Fox wrote: Oleg you are mixing the use of this method with the method being inefficient. Executing head is not ineficient Agree so there's no reason to exclude it in the new wagon. Don't agree - as there still is no a valid use case of HEAD, not followed by GET. The deploy plugin checking for a released artifact present in a remote repo, does not stand, in my opinion, as HEAD A-V.jar should instead be GET a maven-metadata.xml and check for V there. It's more efficient because: * if V is not in metadata, deploy plugin will have to read metadata anyway * if V is already in metadata, we did not loose too much. If in 50% cases artifact is not present - we save a lot of network rountrips (GET that will follow that HEAD). Even if it's ot present in, say 20% cases - we by far compensated for the difference between HEAD and GET metadata.xml. Additional consideration: metadata.xml is relatively small, and will fit in the same ip packet as response for HEAD thus producing no difference at all. On average - not having HEAD improves efficiency of repository lookup. Thanks, Oleg Taking it away simply because someone could be dumb doesn't sense, especially since we already have on valid use case for it. Sent from my iPhone On Sep 29, 2008, at 12:12 PM, Oleg Gusakov [EMAIL PROTECTED] wrote: Ralph Goers wrote: I'm not sure I understand. If I was to implement this I would imagine that the deployer would want to call resourceExists() to find out whether to deploy or not. The fact that resourceExists() can check the metadata vs the actual file would seem to me to be an implementation choice for the author of the resourceExists method, not the author of the deployer code. Think how resourceExists() could be implemented by http provider: 1. send HEAD and look for 404 2. send GET and look for 404 If resource does not exist, you get one network roundtrip in both. If resource exists and you want it 1. you have to send a GET request - second network trip to get contents 2. you already are receiving the contents So in reality - there is no benefit in separating the resourceExists() and resourceGet() on transport level. I don't argue it's existence in above transport layers: implement it as transport's getResource() and wait for failure. But wagon IS our transport layer, and it tries to impose higher level call to lower level protocol. It should stay in the Wagon APIs, and if wagon provider does not implement it - integration tests should not fail. This is what this argument is about. Next, I admit, I haven't looked much at the Wagon classes. But I glanced at https://svn.apache.org/repos/asf/maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/Wagon.java. I don't see anything in the javadoc indicating the method is optional. A search for wagon site:maven.apache.org didn't yield anything either. In fact, it is hard to imagine how it could be since it returns a boolean and the only documented Exceptions are TransferFailedException and AuthorizationException. I
Re: wagon's resourceExists() call efficiency ?
what about preventing redeployment of non-snapshots? Sent from my iPod On 27 Sep 2008, at 23:57, Oleg Gusakov [EMAIL PROTECTED] wrote: I cannot imagine a use case where you would check that artifact exists in the remote repository and then don't download it. Can you? Brian E. Fox wrote: Is there never a case that you care if it's there but don't want to download it? It seems like the efficiency is in how it's used, rather than the fact that it exists. -Original Message- From: Oleg Gusakov [mailto:[EMAIL PROTECTED] Sent: Saturday, September 27, 2008 6:33 PM To: Maven Developers List Subject: wagon's resourceExists() call efficiency ? wagon API has a very strange method in it: resourceExists(). And although it is optional - org. apache. maven. integrationtests. MavenITmng3703ExecutionProjectWithRelativePathsTest. testForkFromReport() fails if that method is not present. Jan and I have been weighting pro and contra of this method in the Mercury transport API and decided against it as we cannot see where it gives any advantage over direct GET resource. Indeed - if read resource fails, it's that same as resourceExists() fails. If read succeeds, then it's equivalent to sequence: resourceExists(); readResource(); But the latter has a way more network roundtrips compared to just readResource(). I propose to rewrite the integration test so that it does not fail, if (optional!) Wagon.resourceExists() is not present. Thus we can avoid rather costly resourceExists(). 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wagon's resourceExists() call efficiency ?
But this information comes from repository metadata, not from probing the actual file. If it does - repository integrity is broken, isn't it? Deploy should read the metadata anyway as it is supposed to update [in a dumb http/dav repository, Nexus can do it for us], so if version is not in metadata, or metadata read failed it's equivalent to resource does not exist, but now you have much more information to act upon. Ralph Goers wrote: Yes. I would actually like the deploy plugin to NOT deploy a non-SNAPSHOT artifact if it is already there. Oleg Gusakov wrote: I cannot imagine a use case where you would check that artifact exists in the remote repository and then don't download it. Can you? - 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]
Re: wagon's resourceExists() call efficiency ?
Stephen - please see my reply to Ralph's question; same use case. Stephen Connolly wrote: what about preventing redeployment of non-snapshots? Sent from my iPod On 27 Sep 2008, at 23:57, Oleg Gusakov [EMAIL PROTECTED] wrote: I cannot imagine a use case where you would check that artifact exists in the remote repository and then don't download it. Can you? Brian E. Fox wrote: Is there never a case that you care if it's there but don't want to download it? It seems like the efficiency is in how it's used, rather than the fact that it exists. -Original Message- From: Oleg Gusakov [mailto:[EMAIL PROTECTED] Sent: Saturday, September 27, 2008 6:33 PM To: Maven Developers List Subject: wagon's resourceExists() call efficiency ? wagon API has a very strange method in it: resourceExists(). And although it is optional - org.apache.maven.integrationtests.MavenITmng3703ExecutionProjectWithRelativePathsTest.testForkFromReport() fails if that method is not present. Jan and I have been weighting pro and contra of this method in the Mercury transport API and decided against it as we cannot see where it gives any advantage over direct GET resource. Indeed - if read resource fails, it's that same as resourceExists() fails. If read succeeds, then it's equivalent to sequence: resourceExists(); readResource(); But the latter has a way more network roundtrips compared to just readResource(). I propose to rewrite the integration test so that it does not fail, if (optional!) Wagon.resourceExists() is not present. Thus we can avoid rather costly resourceExists(). 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] - 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]
RE: wagon's resourceExists() call efficiency ?
That's implementation specific, we're talking about an interface here. I don't see why we should take out this method. If someone wants to use it, fine. If not, also fine. -Original Message- From: Oleg Gusakov [mailto:[EMAIL PROTECTED] Sent: Sunday, September 28, 2008 12:04 PM To: Maven Developers List Subject: Re: wagon's resourceExists() call efficiency ? But this information comes from repository metadata, not from probing the actual file. If it does - repository integrity is broken, isn't it? Deploy should read the metadata anyway as it is supposed to update [in a dumb http/dav repository, Nexus can do it for us], so if version is not in metadata, or metadata read failed it's equivalent to resource does not exist, but now you have much more information to act upon. Ralph Goers wrote: Yes. I would actually like the deploy plugin to NOT deploy a non-SNAPSHOT artifact if it is already there. Oleg Gusakov wrote: I cannot imagine a use case where you would check that artifact exists in the remote repository and then don't download it. Can you? - 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]
Re: wagon's resourceExists() call efficiency ?
Was anyone suggesting taking the method out, or just using an alternative in an unrelated test case? It was only the latter I was in favour of, it seemed to have little to do with ExecutionProjectWithRelativePathsTest. - Brett On 29/09/2008, at 6:58 AM, Brian E. Fox wrote: That's implementation specific, we're talking about an interface here. I don't see why we should take out this method. If someone wants to use it, fine. If not, also fine. -Original Message- From: Oleg Gusakov [mailto:[EMAIL PROTECTED] Sent: Sunday, September 28, 2008 12:04 PM To: Maven Developers List Subject: Re: wagon's resourceExists() call efficiency ? But this information comes from repository metadata, not from probing the actual file. If it does - repository integrity is broken, isn't it? Deploy should read the metadata anyway as it is supposed to update [in a dumb http/dav repository, Nexus can do it for us], so if version is not in metadata, or metadata read failed it's equivalent to resource does not exist, but now you have much more information to act upon. Ralph Goers wrote: Yes. I would actually like the deploy plugin to NOT deploy a non-SNAPSHOT artifact if it is already there. Oleg Gusakov wrote: I cannot imagine a use case where you would check that artifact exists in the remote repository and then don't download it. Can you? - 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] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wagon's resourceExists() call efficiency ?
Let me clarify what spawned this thread: I am running ITs against 2.2.0-M1 branch with mercury wagon in it, and found an IT that fails, unless wagon implements optional resourceExists(). I argue here that absence of an optional method should not make an IT fail - this is all ! As a side effect - debating whether to implement this method in Mercury transport, we came to the conclusion that it is not efficient and should be avoided. Next I decided to share this conclusion here, to check if it stands. So far - it does :) Brian E. Fox wrote: That's implementation specific, we're talking about an interface here. I don't see why we should take out this method. If someone wants to use it, fine. If not, also fine. -Original Message- From: Oleg Gusakov [mailto:[EMAIL PROTECTED] Sent: Sunday, September 28, 2008 12:04 PM To: Maven Developers List Subject: Re: wagon's resourceExists() call efficiency ? But this information comes from repository metadata, not from probing the actual file. If it does - repository integrity is broken, isn't it? Deploy should read the metadata anyway as it is supposed to update [in a dumb http/dav repository, Nexus can do it for us], so if version is not in metadata, or metadata read failed it's equivalent to resource does not exist, but now you have much more information to act upon. Ralph Goers wrote: Yes. I would actually like the deploy plugin to NOT deploy a non-SNAPSHOT artifact if it is already there. Oleg Gusakov wrote: I cannot imagine a use case where you would check that artifact exists in the remote repository and then don't download it. Can you? - 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]
Re: wagon's resourceExists() call efficiency ?
+1 On 27-Sep-08, at 6:33 PM, Oleg Gusakov wrote: wagon API has a very strange method in it: resourceExists(). And although it is optional - org .apache .maven .integrationtests .MavenITmng3703ExecutionProjectWithRelativePathsTest .testForkFromReport() fails if that method is not present. Jan and I have been weighting pro and contra of this method in the Mercury transport API and decided against it as we cannot see where it gives any advantage over direct GET resource. Indeed - if read resource fails, it's that same as resourceExists() fails. If read succeeds, then it's equivalent to sequence: resourceExists(); readResource(); But the latter has a way more network roundtrips compared to just readResource(). I propose to rewrite the integration test so that it does not fail, if (optional!) Wagon.resourceExists() is not present. Thus we can avoid rather costly resourceExists(). Thanks, Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: wagon's resourceExists() call efficiency ?
Is there never a case that you care if it's there but don't want to download it? It seems like the efficiency is in how it's used, rather than the fact that it exists. -Original Message- From: Oleg Gusakov [mailto:[EMAIL PROTECTED] Sent: Saturday, September 27, 2008 6:33 PM To: Maven Developers List Subject: wagon's resourceExists() call efficiency ? wagon API has a very strange method in it: resourceExists(). And although it is optional - org.apache.maven.integrationtests.MavenITmng3703ExecutionProjectWithRelativePathsTest.testForkFromReport() fails if that method is not present. Jan and I have been weighting pro and contra of this method in the Mercury transport API and decided against it as we cannot see where it gives any advantage over direct GET resource. Indeed - if read resource fails, it's that same as resourceExists() fails. If read succeeds, then it's equivalent to sequence: resourceExists(); readResource(); But the latter has a way more network roundtrips compared to just readResource(). I propose to rewrite the integration test so that it does not fail, if (optional!) Wagon.resourceExists() is not present. Thus we can avoid rather costly resourceExists(). Thanks, Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wagon's resourceExists() call efficiency ?
I cannot imagine a use case where you would check that artifact exists in the remote repository and then don't download it. Can you? Brian E. Fox wrote: Is there never a case that you care if it's there but don't want to download it? It seems like the efficiency is in how it's used, rather than the fact that it exists. -Original Message- From: Oleg Gusakov [mailto:[EMAIL PROTECTED] Sent: Saturday, September 27, 2008 6:33 PM To: Maven Developers List Subject: wagon's resourceExists() call efficiency ? wagon API has a very strange method in it: resourceExists(). And although it is optional - org.apache.maven.integrationtests.MavenITmng3703ExecutionProjectWithRelativePathsTest.testForkFromReport() fails if that method is not present. Jan and I have been weighting pro and contra of this method in the Mercury transport API and decided against it as we cannot see where it gives any advantage over direct GET resource. Indeed - if read resource fails, it's that same as resourceExists() fails. If read succeeds, then it's equivalent to sequence: resourceExists(); readResource(); But the latter has a way more network roundtrips compared to just readResource(). I propose to rewrite the integration test so that it does not fail, if (optional!) Wagon.resourceExists() is not present. Thus we can avoid rather costly resourceExists(). 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]
Re: wagon's resourceExists() call efficiency ?
Wagon is resource oriented, rather than artifact oriented - this is more equivalent to HEAD in HTTP. I don't see a need for it in artifact handling as it would be determined by metadata. I can't think of anywhere immediately that it would be used. I think it makes sense to remove from the integration test as from the title I can't see any reason it would be related to testing that specifically. - Brett On 28/09/2008, at 8:57 AM, Oleg Gusakov wrote: I cannot imagine a use case where you would check that artifact exists in the remote repository and then don't download it. Can you? Brian E. Fox wrote: Is there never a case that you care if it's there but don't want to download it? It seems like the efficiency is in how it's used, rather than the fact that it exists. -Original Message- From: Oleg Gusakov [mailto:[EMAIL PROTECTED] Sent: Saturday, September 27, 2008 6:33 PM To: Maven Developers List Subject: wagon's resourceExists() call efficiency ? wagon API has a very strange method in it: resourceExists(). And although it is optional - org .apache .maven .integrationtests .MavenITmng3703ExecutionProjectWithRelativePathsTest .testForkFromReport() fails if that method is not present. Jan and I have been weighting pro and contra of this method in the Mercury transport API and decided against it as we cannot see where it gives any advantage over direct GET resource. Indeed - if read resource fails, it's that same as resourceExists() fails. If read succeeds, then it's equivalent to sequence: resourceExists(); readResource(); But the latter has a way more network roundtrips compared to just readResource(). I propose to rewrite the integration test so that it does not fail, if (optional!) Wagon.resourceExists() is not present. Thus we can avoid rather costly resourceExists(). 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] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wagon's resourceExists() call efficiency ?
I will rewrite the test to not depend on this method. Thanks everyone replying! Brett Porter wrote: Wagon is resource oriented, rather than artifact oriented - this is more equivalent to HEAD in HTTP. I don't see a need for it in artifact handling as it would be determined by metadata. I can't think of anywhere immediately that it would be used. I think it makes sense to remove from the integration test as from the title I can't see any reason it would be related to testing that specifically. - Brett On 28/09/2008, at 8:57 AM, Oleg Gusakov wrote: I cannot imagine a use case where you would check that artifact exists in the remote repository and then don't download it. Can you? Brian E. Fox wrote: Is there never a case that you care if it's there but don't want to download it? It seems like the efficiency is in how it's used, rather than the fact that it exists. -Original Message- From: Oleg Gusakov [mailto:[EMAIL PROTECTED] Sent: Saturday, September 27, 2008 6:33 PM To: Maven Developers List Subject: wagon's resourceExists() call efficiency ? wagon API has a very strange method in it: resourceExists(). And although it is optional - org.apache.maven.integrationtests.MavenITmng3703ExecutionProjectWithRelativePathsTest.testForkFromReport() fails if that method is not present. Jan and I have been weighting pro and contra of this method in the Mercury transport API and decided against it as we cannot see where it gives any advantage over direct GET resource. Indeed - if read resource fails, it's that same as resourceExists() fails. If read succeeds, then it's equivalent to sequence: resourceExists(); readResource(); But the latter has a way more network roundtrips compared to just readResource(). I propose to rewrite the integration test so that it does not fail, if (optional!) Wagon.resourceExists() is not present. Thus we can avoid rather costly resourceExists(). 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] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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]
Re: wagon's resourceExists() call efficiency ?
Yes. I would actually like the deploy plugin to NOT deploy a non-SNAPSHOT artifact if it is already there. Oleg Gusakov wrote: I cannot imagine a use case where you would check that artifact exists in the remote repository and then don't download it. Can you? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
