[buckminster-dev] Re: Executing JUnit tests with headless Buckminster

[Dann Martens <dann@xxxxxxxxxxx>]

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