Ebay Finding Service API for Java / Maven

I’ve just finished a project which regularly queries the ebay finding API and does something good with the results. It’s in Java, so I downloaded the “Finding Kit for Java” zip file from the ebay Developer’s Program Finding API page. I struggled at first to integrate it with my Java / Maven / One-JAR project. A look through the code included in the zip revealed stuff that didn’t inspire me with confidence (for example the hard-coded Windows path (“C:/william_dev/eBaySDK/715/findingkit/FindingService.wsdl” in FindingService.java) so I decided to make my own Maven findingkit project.

I’m allergic to XML so no expert on SOAP but it seems that the zip-included com.ebay.services.finding package should be automatically generated by some WSDL. I deleted that directory first. The Developer’s Program zip includes the WSDL to generate the deleted source, but my expectation from a public API is that the WSDL should be publicly hosted by the API-owner, so I deleted that too.

It remained only to specify an URL for the Finding Service WSDL which describes the generated source and a maven plugin (I used JAX-WS) to generate the sources (with the maven goal jaxws:wsimport) and I was good to go to generate the Finding java sources. The first time you do this, there’s a package naming issue in the zip-included com.ebay.services.client.FindingServiceClientFactory. Replace the import lines with ones including package names that match the generated code. In NetBeans IDE, I just delete the imports and choose the default suggestions in the ‘Cannot find symbol’ tooltips. The generated package I have to import from is “com.ebay.marketplace.search.v1.services”.

One last clean and build should give you a com.ebay.findingkit artefact in your local maven repository.

Here’s a zip file of the maven project I use in my ebay Finding Service projects. The usual caveats regarding gifts from strangers should apply. At least it has no Windows file path string literals in it.

findingkit.zip

My one remaining concern is the ‘v1’ in the package names. I’d be happier if I had a ‘v1’ URL for the WSDL. A ‘latest’ URL that generates ‘v1’ names seems wrong.

Leave a Reply

Your email address will not be published. Required fields are marked *