Home » Eclipse Projects » Buckminster dev » Executing JUnit tests with headless Buckminster
| Executing JUnit tests with headless Buckminster [message #33229] |
Tue, 02 June 2009 11:34  |
 Achim Demelt
Messages: 160
Registered: July 2009 |
Senior Member |
|
|
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
|
|
|
| Re: Executing JUnit tests with headless Buckminster [message #33266 is a reply to message #33229] |
Tue, 02 June 2009 12:38  |
|
Hi Achim,
I've been down the same path as you regarding this and made the same conclusions. This is something that needs to be
fixed in the JDT and PDE plug-ins. I think timing wise it's good timing that you bring it up now. The 3.5.0/Galileo
release is due in a couple of weeks and the code is more or less locked down at this point which means that most teams
are now looking forward. What should be included in 3.6?
I see three major bullets for Buckminster:
1. Even deeper integration with P2
2. Unified efforts with the PDE build team
3. A good story around testing
The issues you bring up here fits very well.
Personally, I don't think it would matter much if it is your or I who files the bugzilla. The fact that a request comes
from the community of users instead of the project team can sometimes be advantageous and I will of course back you up.
If you offer to help, even better.
I'm CC'ing this mail to Chris Anizchyk and Andrew Niefer (they both work with PDE). Advice and hints from you guys on
how to progress with this are very welcome.
Kind Regards,
Thomas Hallgren
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
>
>
|
|
| | |
| Re: [buckminster-dev] Re: Executing JUnit tests with headless Buckminster [message #33370 is a reply to message #33266] |
Tue, 02 June 2009 20:07 |
Neale Upstone
Messages: 50
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
--------------060304000806030705040705
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
I think this opens up a bigger issue, and the kick off for 3.6 will be
the time, as API changes (if not entirely new plugins) will be needed.
There has been some cleaning up done to make JUnit4 a little better
supported, but the sense I got is that there is frustration around JUnit
being a moving target.
Teasing the functionality out of JDT would be a great contribution, I
think, especially having multiple "adopters" evolving the API.
On 02/06/2009 16:22, Oisin Hurley wrote:
>> Personally, I don't think it would matter much if it is your or I who files
>> the bugzilla. The fact that a request comes from the community of users
>> instead of the project team can sometimes be advantageous and I will of
>> course back you up. If you offer to help, even better.
>>
> +1 from me - if possible, I'd like to help out in some small manner
> with getting the junits sorted out.
>
> --oh
> _______________________________________________
> buckminster-dev mailing list
> buckminster-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/buckminster-dev
>
--------------060304000806030705040705
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#336666">
Hi,<br>
<br>
I think this opens up a bigger issue, and the kick off for 3.6 will be
the time, as API changes (if not entirely new plugins) will be needed.
There has been some cleaning up done to make JUnit4 a little better
supported, but the sense I got is that there is frustration around
JUnit being a moving target.<br>
<br>
Teasing the functionality out of JDT would be a great contribution, I
think, especially having multiple "adopters" evolving the API.<br>
<br>
<br>
<br>
On 02/06/2009 16:22, Oisin Hurley wrote:
<blockquote
cite="mid:e77cb25c0906020822j4c6502f3w78898b85d3ea7f56@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">Personally, I don't think it would matter much if it is your or I who files
the bugzilla. The fact that a request comes from the community of users
instead of the project team can sometimes be advantageous and I will of
course back you up. If you offer to help, even better.
</pre>
</blockquote>
<pre wrap="">
+1 from me - if possible, I'd like to help out in some small manner
with getting the junits sorted out.
--oh
_______________________________________________
buckminster-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:buckminster-dev@eclipse.org">buckminster-dev@eclipse.org</a>
<a class="moz-txt-link-freetext" href="https://dev.eclipse.org/mailman/listinfo/buckminster-dev">https://dev.eclipse.org/mailman/listinfo/buckminster-dev</a>
</pre>
</blockquote>
</body>
</html>
--------------060304000806030705040705--
|
|
|
| Re: Executing JUnit tests with headless Buckminster [message #33722 is a reply to message #33229] |
Thu, 04 June 2009 08:56 |
Dann Martens
Messages: 65
Registered: July 2009 |
Member |
|
|
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
>
>
|
|
|
| Re: Executing JUnit tests with headless Buckminster [message #33757 is a reply to message #33722] |
Thu, 04 June 2009 09:16 |
Achim Demelt
Messages: 160
Registered: July 2009 |
Senior Member |
|
|
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
>>
>>
|
|
|
| Re: Executing JUnit tests with headless Buckminster [message #33791 is a reply to message #33757] |
Thu, 04 June 2009 09:25 |
Dann Martens
Messages: 65
Registered: July 2009 |
Member |
|
|
Hi Achim,
Hope springs eternal :)
I'm currently reworking my set of Buckminster plug-ins to work with
Galileo. I hope to have them available by the end of Q3 2009.
I'd like to subscribe to your plug-ins; how can I get access to them?
How are you handling the test reports? Are there any restrictions on how
the tests are organized in the workspace? E.g. a src-test folder in the
same project, or an additional .-test project for each tested project?
Best regards,
Dann
Achim Demelt wrote:
> 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
>>>
>>>
>
>
|
|
|
| Re: Executing JUnit tests with headless Buckminster [message #33825 is a reply to message #33791] |
Thu, 04 June 2009 10:02 |
Achim Demelt
Messages: 160
Registered: July 2009 |
Senior Member |
|
|
Dann,
My goal is to execute standard JUnit launch configurations with Buckminster
headless, i.e. you define your tests in whichever way you like. If you're
able to execute them in your workspace using "Run As/JUnit Test...", you
only need to export the launch configuration and invoke Buckminster headless
like this:
buckminster -data /path/to/headless/workspace junit -config test.launch
If that works out as expected, I'd like to contribute this to the
Buckminster project. I will post appropriate patches to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=243293
That being said, it's still a long way to go. You'll stay up-to-date by
CC'ing to the bugs. I'm reading between the lines that you'd be willing to
help me with testing? ;-)
Regards,
Achim
Dann Martens wrote:
> Hi Achim,
>
> Hope springs eternal :)
>
> I'm currently reworking my set of Buckminster plug-ins to work with
> Galileo. I hope to have them available by the end of Q3 2009.
>
> I'd like to subscribe to your plug-ins; how can I get access to them?
> How are you handling the test reports? Are there any restrictions on how
> the tests are organized in the workspace? E.g. a src-test folder in the
> same project, or an additional .-test project for each tested project?
>
> Best regards,
> Dann
>
> Achim Demelt wrote:
>> 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
>>>>
>>>>
>>
>>
|
|
| |
| Re: Executing JUnit tests with headless Buckminster [message #33887 is a reply to message #33825] |
Thu, 04 June 2009 10:18 |
Dann Martens
Messages: 65
Registered: July 2009 |
Member |
|
|
Hi Achim,
I would be very much interested in helping and testing. Count me in.
Let's figure out a way to make the code available.
I like the fragment approach for plug-in projects, Oisin is talking
about; but that wouldn't work for standard java projects, though.
I don't mind Git, but perhaps the Eclipse Git integration hasn't reached
production quality yet (feedback)? If we decide on a distribution
platform, I'll be happy to make my Buckminster plug-ins available in the
same way. Personally, I was thinking about Google Code; but I'm not
married to the idea!
Best regards,
Dann
Achim Demelt wrote:
> Dann,
>
> My goal is to execute standard JUnit launch configurations with Buckminster
> headless, i.e. you define your tests in whichever way you like. If you're
> able to execute them in your workspace using "Run As/JUnit Test...", you
> only need to export the launch configuration and invoke Buckminster headless
> like this:
>
> buckminster -data /path/to/headless/workspace junit -config test.launch
>
> If that works out as expected, I'd like to contribute this to the
> Buckminster project. I will post appropriate patches to
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=243293
>
> That being said, it's still a long way to go. You'll stay up-to-date by
> CC'ing to the bugs. I'm reading between the lines that you'd be willing to
> help me with testing? ;-)
>
> Regards,
> Achim
>
> Dann Martens wrote:
>
>> Hi Achim,
>>
>> Hope springs eternal :)
>>
>> I'm currently reworking my set of Buckminster plug-ins to work with
>> Galileo. I hope to have them available by the end of Q3 2009.
>>
>> I'd like to subscribe to your plug-ins; how can I get access to them?
>> How are you handling the test reports? Are there any restrictions on how
>> the tests are organized in the workspace? E.g. a src-test folder in the
>> same project, or an additional .-test project for each tested project?
>>
>> Best regards,
>> Dann
>>
>> Achim Demelt wrote:
>>> 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
>>>>>
>>>>>
>>>
>
>
|
|
| | |
| Re: [buckminster-dev] Re: Executing JUnit tests with headless Buckminster [message #33955 is a reply to message #33917] |
Thu, 04 June 2009 12:10 |
Dann Martens
Messages: 65
Registered: July 2009 |
Member |
|
|
Hi Oisin,
I have no preferences, except for one thing: not having to fight with
the tooling while we are cooperating. Other than that, I'm keen to work
with Git.
@Achim, will you do the honors in selecting something?
Best regards,
Dann
Oisin Hurley wrote:
>> I don't mind Git, but perhaps the Eclipse Git integration hasn't reached
>> production quality yet (feedback)?
>
> Just on this topic, I haven't had any trouble with the tools, but
> my disclaimer is that I haven't yet used a Git-based project in
> any really serious fashion.
>
> I have a hunch that the 'production quality' argument is a piece
> of received wisdom that has been knocking around long enough
> for the eGit plugin to have been considerably improved :)
>
> In any case, whatever works and is the easiest to set up, I
> think. Getting the sharing started is the important piece,
> rather than the choice of initial mechanism.
>
> --oh
|
|
|
| Re: [buckminster-dev] Re: Executing JUnit tests with headless Buckminster [message #33976 is a reply to message #33955] |
Thu, 04 June 2009 12:26 |
|
I like Git but my preference would still be if Subversion was used since I know my ways around and also need it for
other apparent reasons anyway. The same is true for other Buckminster committers.
Google code sounds like a good start. IIRC, they use Subversion.
- thomas
Dann Martens wrote:
> Hi Oisin,
>
> I have no preferences, except for one thing: not having to fight with
> the tooling while we are cooperating. Other than that, I'm keen to work
> with Git.
>
> @Achim, will you do the honors in selecting something?
>
> Best regards,
> Dann
>
> Oisin Hurley wrote:
>>> I don't mind Git, but perhaps the Eclipse Git integration hasn't reached
>>> production quality yet (feedback)?
>>
>> Just on this topic, I haven't had any trouble with the tools, but
>> my disclaimer is that I haven't yet used a Git-based project in
>> any really serious fashion.
>>
>> I have a hunch that the 'production quality' argument is a piece
>> of received wisdom that has been knocking around long enough
>> for the eGit plugin to have been considerably improved :)
>>
>> In any case, whatever works and is the easiest to set up, I
>> think. Getting the sharing started is the important piece,
>> rather than the choice of initial mechanism.
>>
>> --oh
|
|
| | |
Goto Forum:
Current Time: Wed Sep 25 10:20:25 GMT 2024
Powered by FUDForum. Page generated in 0.07400 seconds |
] 
Search
Help
Register
Login
Home
