Community
Participate
Working Groups
Following up on Scott's comments on http://torkildr.blogspot.com/2010/09/joining-in-on-mylynbuilds-project.html: The Hudson query syntax is not on the normal form but rather similar to a XPath query which makes use of the ECF REST support a bit awkward. See http://wiki.hudson-ci.org/display/HUDSON/Remote+access+API.
Torkild...I would like to make progress on this...i.e. better support than currently exists. Do you have any ideas of how to make the API less awkward for this use case? Could you possibly describe what is awkward about it given the Hudson query syntax? I'm not familiar with that syntax, so need some education here.
Hi Scott. Say for instance you want to get information about the last sucessful build of a job called "trunk". The URL will look something like this: http://deadlock.netbeans.org/hudson/job/trunk/lastSuccessfulBuild/api/xml. So to indicate you want to query a job, you specify "job", then the name of the job followed by an instance. Then "api/xml" to indicate that you want to use the XML API. So basically it is like navigating a hierarchy using '/' as the element separator. You'll find more information following the second link of the initial description.
(In reply to comment #2) > Hi Scott. > > Say for instance you want to get information about the last sucessful build of > a job called "trunk". The URL will look something like this: > http://deadlock.netbeans.org/hudson/job/trunk/lastSuccessfulBuild/api/xml. So > to indicate you want to query a job, you specify "job", then the name of the > job followed by an instance. Then "api/xml" to indicate that you want to use > the XML API. > > So basically it is like navigating a hierarchy using '/' as the element > separator. You'll find more information following the second link of the > initial description. Ok...thanks for the description. Do you have any thoughts/ideas of how we could better handle this style of rest invocation in our REST API? Hmmm...one thought...we could allow some callback to be called to construct the URL path...i.e. at the time of the invocation...so the code for constructing the URL path could be associated with the entire container. Something like a 'custom path builder'...to make this easy. In the mean time...just fyi...it is possible to create a new provider...by subclassing RestClientContainer and RestClientService...and overriding org.eclipse.ecf.remoteservice.rest.client.RestClientService.invokeRemoteCall(IRemoteCall, IRemoteCallable), and/or org.eclipse.ecf.remoteservice.rest.client.RestClientService.createAndPrepareHttpMethod(String, IRemoteCall, IRemoteCallable) to construct the HttpMethod with the appropriate path (e.g. from params in IRemoteCall and/or IRemoteCallable). I'm not saying this answers this bug...I'm just saying that some flexibility is there/possible.
Thanks Scott. I think your idea about using a callback mechanism and an IURLQueryBuilder instance (or something like that) is a good idea and I think it would provide sufficient flexibility.
Need resources to address this change...if still needed.
