Comment 1 Steffen Pingel 2010-06-03 16:09:22 EDT

How is this progressing, Markus? Let me know if you run into any blockers.

Comment 2 Markus Knittig 2010-06-03 18:45:53 EDT

Created attachment 171047 [details]
A very basic first version, not ready and for production, just to see if the Builds Plugins work.

Tried a very basic implementation (yes, this version is ugly and will be refactored asap) and got the following error:
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl$1DiagnosticWrappedException: java.io.IOException: Premature end of file.
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.handleDemandLoadException(ResourceSetImpl.java:315)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:274)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:397)
	at org.eclipse.mylyn.internal.builds.core.util.BuildModelManager.<init>(BuildModelManager.java:88)
	at org.eclipse.mylyn.internal.builds.ui.BuildsUiInternal.getModel(BuildsUiInternal.java:96)
	at org.eclipse.mylyn.builds.ui.BuildsUi.getModel(BuildsUi.java:48)
	at org.eclipse.mylyn.internal.builds.ui.BuildsUiInternal.getServer(BuildsUiInternal.java:113)
	at org.eclipse.mylyn.internal.builds.ui.tasks.BuildTaskSettingsPage.getServer(BuildTaskSettingsPage.java:360)
	...

Comment 3 Markus Knittig 2010-06-03 18:45:58 EDT

Created attachment 171048 [details]
mylyn/context/zip

Comment 4 Steffen Pingel 2010-06-04 01:21:36 EDT

Thanks for the patch and the stack trace. I have fixed the exception, apparently the resource factory was not properly registered.

The patch looks like a good start! I have a few suggestions for improvement:

* Replace Tasktop with your name in all copyright headers of classes that you create.
* If you create a class or make significant changes, add an @author tag to the class Javadoc comment.
* Always make sure that all packages are exported in the manifest. Otherwise loading of extensions can fail.
* Using Hudson as a name prefix should be sufficient, i.e. I would suggest to rename HudsonBuildConnector to HudsonConnector etc. to keep the names short.
* Right now I don't see a use case for an alternative implementation of IHudsonClient and hence I would like to avoid the extra level of abstraction. Just remove IHudsonClient for now and rename RestfulHudson... to HudsonClient.

Before we get into the details of retrieving plans I would like to finish the basic connector and repository validation first. Can you make the changes above and attach a new patch to bug 315716 that does not have the getPlans() method, yet? We can worry about that once validation works and we have a couple of tests in place.

Comment 5 Steffen Pingel 2010-06-09 21:56:56 EDT

Now that the basic infrastructure for the connector is in place, have you been able to make fetching of plans work?

Comment 6 Markus Knittig 2010-06-11 14:09:28 EDT

Created attachment 171754 [details]
Fetching plans

After fighting CVS, I tweaked my original patch a little. This is the result. The test works, I guess that's something. But yeah, it would be better if JAXB had a nicer API.

Comment 7 Markus Knittig 2010-06-11 14:09:30 EDT

Created attachment 171755 [details]
mylyn/context/zip

Comment 8 Markus Knittig 2010-06-11 16:01:54 EDT

Created attachment 171765 [details]
Fetch plans

Now wired. Checkbox label empty and "Widget is disposed" error on close, but at least some progress.

Comment 9 Markus Knittig 2010-06-11 16:01:56 EDT

Created attachment 171766 [details]
mylyn/context/zip

Comment 10 Markus Knittig 2010-06-11 16:18:01 EDT

Created attachment 171767 [details]
Fetch plans

So, only "Widget is disposed" after clicking "Cancel" left.

Comment 11 Markus Knittig 2010-06-11 16:18:03 EDT

Created attachment 171768 [details]
mylyn/context/zip

Comment 12 Steffen Pingel 2010-06-15 04:23:16 EDT

Thanks, that works! I have applied the patch and taken the liberty of making a couple of additional changes. Mylyn has some infrastructure for connection management, cancellation etc. that we can leverage for Hudson. That said, some of the existing API is complex and I want to take the Hudson connector as a driver to simplify it. Please take a look at the changes to RestfulHudsonClient and let me know if you have any questions. 

I have also changed the abstraction slightly: The basic idea is that HudsonClient provides a Hudson specific Java API with little coupling to Mylyn. This is potentially reusable in any application that wants to access a Hudson server and abstracts some of the details of remote access. HudsonServerBehavior provides a wrapper around the Hudson API that using the generic, server agnostic API specified in Mylyn Builds. This is API is intended for any client that wants to access build systems without coupling to the specifics of a particular server, e.g. the Mylyn Builds user interface.

Although it adds a bit of overhead and extra code this architecture has proven to be useful in terms of testability and reusability. Please feel free to ask any question or suggest changes.

Comment 13 Steffen Pingel 2010-06-23 20:38:48 EDT

I have fixed support for build servers that support gzip compression.