Re: [mylyn-dev] Re: hudson connector

[Steffen Pingel <steffen.pingel@xxxxxxxxxxx>]

>> I have made some progress on the build framework in the past couple of
>> days. I have committed a very simple EMF-based common build model and
>> view and also generated the Hudson model classes for JAXB.
>
> Looks great, but did you use "-target 2.0" for the JAXB generation? The
> errors with XmlSeeAlso look awful familiar...

I used JAXB 2.2 and didn't set a target since version 2.2 of the
java.xml.bindins bundle were approved for reuse in Mylyn. Please
comment on the bug if you recommend setting that. I'd be happy to
regenerate the bindings.

>> The next step is to implement the build connector extension for Hudson
>> and to put together a simple client that retrieves plans and status
>> from a Hudson server. Can you go ahead and create tasks for that and
>> provide patches? You can look at the o.e.m.builds.tests plug-in to get
>> an idea how register a build connector.
>
> Already played a bit with it yesterday (after spending like two hours
> figuring out that I have to use Helios :-/).

I admit that I didn't pay much attention to the version constraints in
the manifests or backwards compatibility since committers usually work
on the latest 3.6 milestones. I have fixed the emf dependency so it
should compile on 3.5 now. My hope is that we can release the first
version of the Hudson connector as part of Mylyn 3.5 so it probably
makes sense to keep it compatible with Eclipse 3.5 right from the
start.

>> Note that the build implementation and particularly the API is work in
>> progress and we can and probably will change it significantly to make
>> it fit for Hudson. Please don't hesitate to include changes that
>> affect the build API or build framework implementation in your
>> patches.
>
> The plan is to completely hide the task API from the Hudson plugin,
> right? So if I need access to additional APIs I change the Builds
> plugins accordingly.

Yes, my current sense is that there is nothing in the build framework
API that is inherently coupled to tasks. If necessary I don't have a
problem with coupling it to tasks since the implementation is build on
tasks either way but I would like to avoid an API dependency as long
as possible.

Steffen

-- 
Steffen Pingel
Committer, http://eclipse.org/mylyn
Senior Developer, http://tasktop.com