[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[buckminster-dev] Re: Executing JUnit tests with headless Buckminster
|
Hi Dann,
Thanks for your support! Fortunately, Thomas participated both passionately
and factually in the discussion in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=278844 . It seems we really
get a chance to do try this separation in the 3.6 timeframe!
I'm about to finish the first stage of the refactoring. I guess that by the
end of the week I'll be able to run some tests.
Regards,
Achim
Dann Martens wrote:
> Hi Achim,
>
> I have had exactly the same experience on a related front, and had to
> resort to exactly the same strategy: duplicating code from the internal
> code base.
>
> Unfortunately, I have already requested for a better decoupling of the
> UI and the core (more than two years ago), but my request has fallen
> onto deaf ears.
>
> I think we just need to become more vocal on the issue, as I fear their
> attitude in resisting is really starting to stifle innovation on the
> platform. I find that refusal hard to accept in the background of the
> nasty roller coaster ride the p2 component is forcing an entire
> community to sit through.
>
> Your request is reasonable on all accounts: (1) the code should be
> refactored regardless, (2) improved layering improves re-use and (3) the
> platform should welcome innovation.
>
> Still, I would not hesitate to take the difficult road already at this
> juncture, because it is only the result which counts for others relying
> on your work. Your effort in doing so is clearing the path for others to
> innovate, as well. You shouldn't abandon your effort because of the fear
> to throw stones at 'sacred houses'.
>
> My guess is that it only stands a chance to happen on the e4 track,
> since the client-server model is pivotal to the architecture.
>
> Anyone who understands diplomacy and politics enough to open doors to do
> this sooner can count on my support in terms of contributing patches.
>
> Best regards,
> Dann
>
>
>
>
>
>
> Achim Demelt wrote:
>> Hi Thomas,
>>
>> Over the weekend I have experimented with running JUnit tests from
>> headless Buckminster. I wrote a new headless command that launches tests
>> from within the workspace in a separate VM. On the positive side,
>> everything went fine and I was able to run tests defined in the
>> workspace. On the negative side, I basically duplicated code from JDT's
>> JUnit plug-in.
>>
>> I'd love to reuse jdt.junit code, but unfortunately the JDT team has
>> chosen *not* to separate the JUnit launching part from the UI part.
>> Installing a whole bunch of UI stuff into headless Buckminster didn't
>> seem like a good idea to me. So I went for copying a stripped down
>> version of the JUnit execution code because the actual amount of code
>> needed was relatively small.
>>
>> Then I started looking into PDE JUnit testing, and that's where things
>> are beginning to get ugly. Again, PDE's JUnit launching code is happily
>> coexisting with UI code in the same plug-in. Launching an equinox runtime
>> to execute JUnit plug-in tests is not exactly a walk in the park, so I
>> doubt that code duplication is a viable approach here.
>>
>> Ultimately, I would want to be able to read JUnit launch configurations
>> from a file and execute them in Buckminster headless. This way, the user
>> can specify VM args, equinox configurations, etc. for his tests. But this
>> requires Buckminster to understand all parameters of JDT's and PDE's
>> launch configurations.
>>
>> In my eyes, the only reasonable way for a solid JUnit integration in
>> headless Buckminster would be to reuse JDT's and PDE's JUnit launching
>> code. This would require the JDT and PDE teams to separate their core
>> code from their UI code and put it into separate bundles. I guess there's
>> no way this is going to happen if *I* file a bugzilla, even if I attach a
>> patch.
>>
>> Thomas, what's your view on this? Do you see alternatives? Would you be
>> able to persuade the JDT/PDE teams to do such a refactoring?
>>
>> Cheers,
>> Achim
>>
>>