Home » Archived » Buckminster » Automated Testing of RCP Products with Buckminster
| Automated Testing of RCP Products with Buckminster [message #467880] |
Mon, 03 August 2009 05:39  |
Eclipse User |
|
|
|
Hi,
I wondering what the best way of approaching testing with buckminster is. I
tried examining the buckminster build to find out where you run your tests
but I can't see anything.
My previous builds use the Eclipse Test Framework. They create an eclipse
environment from the recently built distribution artifacts, install the
tests and necessary dependencies and then kick-off the tests and gather
results. I'm not sure where buckminster could be leveraged in this and was
curious about the new test functionaloty you are adding. Where would this
fit in?
Thanks,
Tas
|
|
| | |
| Re: Automated Testing of RCP Products with Buckminster [message #467916 is a reply to message #467905] |
Mon, 03 August 2009 07:34  |
| Eclipse User |
|
|
|
Tas,
I published a very early demo version here: http://buckminster-
contrib.googlecode.com/files/site_1.0.0.200906052157-1--311_ 17163268.zip
This version is rather old (around the 3.5 RC timeframe), so I cannot
guarantee that it's still working. Also, please read
http://code.google.com/p/buckminster-contrib/wiki/Buckminste rJUnit before
trying it out. The most important restriction is that it's _not_ capable of
running plug-in tests. It only supports plain Java JUnit tests. This will
probably render it pretty much useless for your RCP tests...
Regards,
Achim
Tas Frangoullides wrote:
> Hi Achim,
>
> Is there an update site I can get this from to try it out?
>
> Thanks,
> Tas
>
>
> "Achim Demelt" <a.demelt@exxcellent.de> wrote in message
> news:h56du9$chm$1@build.eclipse.org...
>> Tas,
>>
>> This is work-in-progress. Please see
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=243293 for more
>> information.
>>
>> The headless build will then basically be able to run the tests in the
>> same
>> way as you would run them interactively in your IDE.
>>
>> Regards,
>> Achim
>>
>> Tas Frangoullides wrote:
>>
>>> Hi,
>>>
>>> I wondering what the best way of approaching testing with buckminster
>>> is. I tried examining the buckminster build to find out where you run
>>> your tests but I can't see anything.
>>>
>>> My previous builds use the Eclipse Test Framework. They create an
>>> eclipse environment from the recently built distribution artifacts,
>>> install the tests and necessary dependencies and then kick-off the tests
>>> and gather results. I'm not sure where buckminster could be leveraged in
>>> this and was
>>> curious about the new test functionaloty you are adding. Where would
>>> this fit in?
>>>
>>> Thanks,
>>> Tas
>>
>>
|
|
|
| Re: Automated Testing of RCP Products with Buckminster [message #467927 is a reply to message #467916] |
Mon, 03 August 2009 07:54 |
| Eclipse User |
|
|
|
Hi Achim,
Yeah. I guess this isn't going to be useful to me yet. Great to know it's in
the pipeline though.
For now I'm thinking that wrapping the eclipse.test framework with a
buckminster action is best way forward, unless anyone has a better idea.
So I'm curious: Are any tests executed during the build for buckminster
itself?
Thanks,
Tas
"Achim Demelt" <a.demelt@exxcellent.de> wrote in message
news:h56i03$ipq$1@build.eclipse.org...
> Tas,
>
> I published a very early demo version here: http://buckminster-
> contrib.googlecode.com/files/site_1.0.0.200906052157-1--311_ 17163268.zip
>
> This version is rather old (around the 3.5 RC timeframe), so I cannot
> guarantee that it's still working. Also, please read
> http://code.google.com/p/buckminster-contrib/wiki/Buckminste rJUnit before
> trying it out. The most important restriction is that it's _not_ capable
> of
> running plug-in tests. It only supports plain Java JUnit tests. This will
> probably render it pretty much useless for your RCP tests...
>
> Regards,
> Achim
>
> Tas Frangoullides wrote:
>
>> Hi Achim,
>>
>> Is there an update site I can get this from to try it out?
>>
>> Thanks,
>> Tas
>>
>>
>> "Achim Demelt" <a.demelt@exxcellent.de> wrote in message
>> news:h56du9$chm$1@build.eclipse.org...
>>> Tas,
>>>
>>> This is work-in-progress. Please see
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=243293 for more
>>> information.
>>>
>>> The headless build will then basically be able to run the tests in the
>>> same
>>> way as you would run them interactively in your IDE.
>>>
>>> Regards,
>>> Achim
>>>
>>> Tas Frangoullides wrote:
>>>
>>>> Hi,
>>>>
>>>> I wondering what the best way of approaching testing with buckminster
>>>> is. I tried examining the buckminster build to find out where you run
>>>> your tests but I can't see anything.
>>>>
>>>> My previous builds use the Eclipse Test Framework. They create an
>>>> eclipse environment from the recently built distribution artifacts,
>>>> install the tests and necessary dependencies and then kick-off the
>>>> tests
>>>> and gather results. I'm not sure where buckminster could be leveraged
>>>> in
>>>> this and was
>>>> curious about the new test functionaloty you are adding. Where would
>>>> this fit in?
>>>>
>>>> Thanks,
>>>> Tas
>>>
>>>
>
>
|
|
|
| Re: Automated Testing of RCP Products with Buckminster [message #467934 is a reply to message #467927] |
Mon, 03 August 2009 08:13 |
| Eclipse User |
|
|
|
Hi Tas,
what I am doing right now is this:
I have two different jobs in hudson
-one that just builds the RCP with buckminster
-and one that builds the RCP and executes the tests
All tests are in plugin fragments and get aggregated by an all-tests
feature.
The RCP that gets build for the test job includes the regular feature(s)
+ the tests feature and all test dependencies (like the test framework
and junit).
Once the buckminster build step is done with creating the RCP I invoke
an ant script that executes the plugin tests with the test framework and
then hudson can pick up the test results from the workspace.
Works fine for me, but of course it will be more convinient once the
buckminster junit support is in place.
Best regards,
Johannes
Tas Frangoullides schrieb:
> Hi Achim,
>
> Yeah. I guess this isn't going to be useful to me yet. Great to know
> it's in the pipeline though.
>
> For now I'm thinking that wrapping the eclipse.test framework with a
> buckminster action is best way forward, unless anyone has a better idea.
>
> So I'm curious: Are any tests executed during the build for buckminster
> itself?
>
> Thanks,
> Tas
>
> "Achim Demelt" <a.demelt@exxcellent.de> wrote in message
> news:h56i03$ipq$1@build.eclipse.org...
>> Tas,
>>
>> I published a very early demo version here: http://buckminster-
>> contrib.googlecode.com/files/site_1.0.0.200906052157-1--311_ 17163268.zip
>>
>> This version is rather old (around the 3.5 RC timeframe), so I cannot
>> guarantee that it's still working. Also, please read
>> http://code.google.com/p/buckminster-contrib/wiki/Buckminste rJUnit before
>> trying it out. The most important restriction is that it's _not_
>> capable of
>> running plug-in tests. It only supports plain Java JUnit tests. This will
>> probably render it pretty much useless for your RCP tests...
>>
>> Regards,
>> Achim
>>
>> Tas Frangoullides wrote:
>>
>>> Hi Achim,
>>>
>>> Is there an update site I can get this from to try it out?
>>>
>>> Thanks,
>>> Tas
>>>
>>>
>>> "Achim Demelt" <a.demelt@exxcellent.de> wrote in message
>>> news:h56du9$chm$1@build.eclipse.org...
>>>> Tas,
>>>>
>>>> This is work-in-progress. Please see
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=243293 for more
>>>> information.
>>>>
>>>> The headless build will then basically be able to run the tests in the
>>>> same
>>>> way as you would run them interactively in your IDE.
>>>>
>>>> Regards,
>>>> Achim
>>>>
>>>> Tas Frangoullides wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I wondering what the best way of approaching testing with buckminster
>>>>> is. I tried examining the buckminster build to find out where you run
>>>>> your tests but I can't see anything.
>>>>>
>>>>> My previous builds use the Eclipse Test Framework. They create an
>>>>> eclipse environment from the recently built distribution artifacts,
>>>>> install the tests and necessary dependencies and then kick-off the
>>>>> tests
>>>>> and gather results. I'm not sure where buckminster could be
>>>>> leveraged in
>>>>> this and was
>>>>> curious about the new test functionaloty you are adding. Where would
>>>>> this fit in?
>>>>>
>>>>> Thanks,
>>>>> Tas
>>>>
>>>>
>>
>>
>
|
|
|
| Re: Automated Testing of RCP Products with Buckminster [message #467942 is a reply to message #467934] |
Mon, 03 August 2009 08:37 |
| Eclipse User |
|
|
|
Hi Johannes,
I can see how that would work. In your approach do you consider the build
broken if the tests fail and do you use the hudson history to reflect this?
Ideally I'd want one build which includes testing so I have only one build
to monitor. So far I have created a seperate feature for the all the tests,
much like you, but instead I build a sepereate site for it including all the
dependecies. That's where I'm up to. The added complexity here (which I'm
yet to resolve) is I now need to install both my rcp product and the test
plugins to a new location so I can run the tests. I'm hoping this will work
and I was thinking I could director to do this. I notcied some code in your
ant scripts for the MailApp which can help me do this and was going to try
those.
What do you think?
Thanks,
Tas
"Johannes Utzig" <mail@jutzig.de> wrote in message
news:h56k91$9lc$1@build.eclipse.org...
> Hi Tas,
>
> what I am doing right now is this:
> I have two different jobs in hudson
> -one that just builds the RCP with buckminster
> -and one that builds the RCP and executes the tests
>
> All tests are in plugin fragments and get aggregated by an all-tests
> feature.
> The RCP that gets build for the test job includes the regular feature(s) +
> the tests feature and all test dependencies (like the test framework and
> junit).
> Once the buckminster build step is done with creating the RCP I invoke an
> ant script that executes the plugin tests with the test framework and then
> hudson can pick up the test results from the workspace.
> Works fine for me, but of course it will be more convinient once the
> buckminster junit support is in place.
>
> Best regards,
> Johannes
>
> Tas Frangoullides schrieb:
>> Hi Achim,
>>
>> Yeah. I guess this isn't going to be useful to me yet. Great to know it's
>> in the pipeline though.
>>
>> For now I'm thinking that wrapping the eclipse.test framework with a
>> buckminster action is best way forward, unless anyone has a better idea.
>>
>> So I'm curious: Are any tests executed during the build for buckminster
>> itself?
>>
>> Thanks,
>> Tas
>>
>> "Achim Demelt" <a.demelt@exxcellent.de> wrote in message
>> news:h56i03$ipq$1@build.eclipse.org...
>>> Tas,
>>>
>>> I published a very early demo version here: http://buckminster-
>>> contrib.googlecode.com/files/site_1.0.0.200906052157-1--311_ 17163268.zip
>>>
>>> This version is rather old (around the 3.5 RC timeframe), so I cannot
>>> guarantee that it's still working. Also, please read
>>> http://code.google.com/p/buckminster-contrib/wiki/Buckminste rJUnit
>>> before
>>> trying it out. The most important restriction is that it's _not_ capable
>>> of
>>> running plug-in tests. It only supports plain Java JUnit tests. This
>>> will
>>> probably render it pretty much useless for your RCP tests...
>>>
>>> Regards,
>>> Achim
>>>
>>> Tas Frangoullides wrote:
>>>
>>>> Hi Achim,
>>>>
>>>> Is there an update site I can get this from to try it out?
>>>>
>>>> Thanks,
>>>> Tas
>>>>
>>>>
>>>> "Achim Demelt" <a.demelt@exxcellent.de> wrote in message
>>>> news:h56du9$chm$1@build.eclipse.org...
>>>>> Tas,
>>>>>
>>>>> This is work-in-progress. Please see
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=243293 for more
>>>>> information.
>>>>>
>>>>> The headless build will then basically be able to run the tests in the
>>>>> same
>>>>> way as you would run them interactively in your IDE.
>>>>>
>>>>> Regards,
>>>>> Achim
>>>>>
>>>>> Tas Frangoullides wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I wondering what the best way of approaching testing with buckminster
>>>>>> is. I tried examining the buckminster build to find out where you run
>>>>>> your tests but I can't see anything.
>>>>>>
>>>>>> My previous builds use the Eclipse Test Framework. They create an
>>>>>> eclipse environment from the recently built distribution artifacts,
>>>>>> install the tests and necessary dependencies and then kick-off the
>>>>>> tests
>>>>>> and gather results. I'm not sure where buckminster could be leveraged
>>>>>> in
>>>>>> this and was
>>>>>> curious about the new test functionaloty you are adding. Where would
>>>>>> this fit in?
>>>>>>
>>>>>> Thanks,
>>>>>> Tas
>>>>>
>>>>>
>>>
>>>
>>
|
|
|
| Re: Automated Testing of RCP Products with Buckminster [message #467978 is a reply to message #467942] |
Mon, 03 August 2009 09:38 |
| Eclipse User |
|
|
|
Hi Tas,
Tas Frangoullides schrieb:
> Hi Johannes,
>
> I can see how that would work. In your approach do you consider the
> build broken if the tests fail and do you use the hudson history to
> reflect this?
>
In our case the test job gets executed regulary and is a throw-aways
product because the class files get instrumented with cobertura and
stuff while the other job gets exectuted only manual in case of a
release and only if the test job is stable, of course.
> Ideally I'd want one build which includes testing so I have only one
> build to monitor. So far I have created a seperate feature for the all
> the tests, much like you, but instead I build a sepereate site for it
> including all the dependecies. That's where I'm up to. The added
> complexity here (which I'm yet to resolve) is I now need to install both
> my rcp product and the test plugins to a new location so I can run the
> tests. I'm hoping this will work and I was thinking I could director to
> do this. I notcied some code in your ant scripts for the MailApp which
> can help me do this and was going to try those.
>
> What do you think?
>
That sounds reasonable to me. It actually shouldn't be much of a
problem. Sticking to the mailapp example you could for example have an
action similar to the create.product action (create.test.product) that
creates the RCP at a different location and uses a different installable
unit that contains the test fragments. Or you could use the same IU and
simply install the feature containing the test fragments on top of that.
On the test product you may then run your plugin tests and hudson will
make sure that the artifacts of the real product are only archived if
the build run was stable (which will depend on your unit test results).
If you have any suggestions on how the buckminster plugin for hudson can
support your workflow, please let me know.
Btw, unrelated to this topic, but since you're using hudson +
buckminster as well:
I'm currently working on a feature for better target platform support
in the hudson plugin. My idea was to have a build publisher similar to
'Archive Artifacts' that takes a directory to archive as well as a name
under which this target platform will be made available.
In all other jobs that use a buckminster build step you may then select
the available target platforms from a drop down box. That will cause the
plugin to set the buckminster targetPlatformPath to the archived target
platform and also introduces the job that creates the TP as an upstream
project. That means: if you build the target platform again, all
downstream projects (projects that reference this TP) will be build again.
Sounds useful to you? Any additional ideas for that?
Best regards,
Johannes
> Thanks,
> Tas
>
>
> "Johannes Utzig" <mail@jutzig.de> wrote in message
> news:h56k91$9lc$1@build.eclipse.org...
>> Hi Tas,
>>
>> what I am doing right now is this:
>> I have two different jobs in hudson
>> -one that just builds the RCP with buckminster
>> -and one that builds the RCP and executes the tests
>>
>> All tests are in plugin fragments and get aggregated by an all-tests
>> feature.
>> The RCP that gets build for the test job includes the regular
>> feature(s) + the tests feature and all test dependencies (like the
>> test framework and junit).
>> Once the buckminster build step is done with creating the RCP I invoke
>> an ant script that executes the plugin tests with the test framework
>> and then hudson can pick up the test results from the workspace.
>> Works fine for me, but of course it will be more convinient once the
>> buckminster junit support is in place.
>>
>> Best regards,
>> Johannes
>>
>> Tas Frangoullides schrieb:
>>> Hi Achim,
>>>
>>> Yeah. I guess this isn't going to be useful to me yet. Great to know
>>> it's in the pipeline though.
>>>
>>> For now I'm thinking that wrapping the eclipse.test framework with a
>>> buckminster action is best way forward, unless anyone has a better idea.
>>>
>>> So I'm curious: Are any tests executed during the build for
>>> buckminster itself?
>>>
>>> Thanks,
>>> Tas
>>>
>>> "Achim Demelt" <a.demelt@exxcellent.de> wrote in message
>>> news:h56i03$ipq$1@build.eclipse.org...
>>>> Tas,
>>>>
>>>> I published a very early demo version here: http://buckminster-
>>>> contrib.googlecode.com/files/site_1.0.0.200906052157-1--311_ 17163268.zip
>>>>
>>>>
>>>> This version is rather old (around the 3.5 RC timeframe), so I cannot
>>>> guarantee that it's still working. Also, please read
>>>> http://code.google.com/p/buckminster-contrib/wiki/Buckminste rJUnit
>>>> before
>>>> trying it out. The most important restriction is that it's _not_
>>>> capable of
>>>> running plug-in tests. It only supports plain Java JUnit tests. This
>>>> will
>>>> probably render it pretty much useless for your RCP tests...
>>>>
>>>> Regards,
>>>> Achim
>>>>
>>>> Tas Frangoullides wrote:
>>>>
>>>>> Hi Achim,
>>>>>
>>>>> Is there an update site I can get this from to try it out?
>>>>>
>>>>> Thanks,
>>>>> Tas
>>>>>
>>>>>
>>>>> "Achim Demelt" <a.demelt@exxcellent.de> wrote in message
>>>>> news:h56du9$chm$1@build.eclipse.org...
>>>>>> Tas,
>>>>>>
>>>>>> This is work-in-progress. Please see
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=243293 for more
>>>>>> information.
>>>>>>
>>>>>> The headless build will then basically be able to run the tests in
>>>>>> the
>>>>>> same
>>>>>> way as you would run them interactively in your IDE.
>>>>>>
>>>>>> Regards,
>>>>>> Achim
>>>>>>
>>>>>> Tas Frangoullides wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I wondering what the best way of approaching testing with
>>>>>>> buckminster
>>>>>>> is. I tried examining the buckminster build to find out where you
>>>>>>> run
>>>>>>> your tests but I can't see anything.
>>>>>>>
>>>>>>> My previous builds use the Eclipse Test Framework. They create an
>>>>>>> eclipse environment from the recently built distribution artifacts,
>>>>>>> install the tests and necessary dependencies and then kick-off
>>>>>>> the tests
>>>>>>> and gather results. I'm not sure where buckminster could be
>>>>>>> leveraged in
>>>>>>> this and was
>>>>>>> curious about the new test functionaloty you are adding. Where would
>>>>>>> this fit in?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Tas
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>
|
|
|
| Re: Automated Testing of RCP Products with Buckminster [message #467996 is a reply to message #467978] |
Mon, 03 August 2009 10:44 |
| Eclipse User |
|
|
|
Hi Johannes,
> In our case the test job gets executed regulary and is a throw-aways
> product because the class files get instrumented with cobertura and stuff
> while the other job gets exectuted only manual in case of a release and
> only if the test job is stable, of course.
Ok. That makes a lot of sense for your use case.
> That sounds reasonable to me. It actually shouldn't be much of a problem.
> Sticking to the mailapp example you could for example have an action
> similar to the create.product action (create.test.product) that creates
> the RCP at a different location and uses a different installable unit that
> contains the test fragments. Or you could use the same IU and simply
> install the feature containing the test fragments on top of that.
> On the test product you may then run your plugin tests and hudson will
> make sure that the artifacts of the real product are only archived if the
> build run was stable (which will depend on your unit test results).
I'm currently trying to get this working and hitting silly obstacles like
finding (or creating) an update site for the test framework. Shouldn't be
too hard though. I'll let you know how I get on with it.
> If you have any suggestions on how the buckminster plugin for hudson can
> support your workflow, please let me know.
Sure, I'd be happy to discuss it. Right now I am trying to get everything
working for the command line and hudson will the my last step, although I
found your article very useful in getting buckminster to do what I wanted.
> Btw, unrelated to this topic, but since you're using hudson + buckminster
> as well:
> I'm currently working on a feature for better target platform support in
> the hudson plugin. My idea was to have a build publisher similar to
> 'Archive Artifacts' that takes a directory to archive as well as a name
> under which this target platform will be made available.
>
> In all other jobs that use a buckminster build step you may then select
> the available target platforms from a drop down box. That will cause the
> plugin to set the buckminster targetPlatformPath to the archived target
> platform and also introduces the job that creates the TP as an upstream
> project. That means: if you build the target platform again, all
> downstream projects (projects that reference this TP) will be build again.
> Sounds useful to you? Any additional ideas for that?
>>
This does sounds interesting. Does this mean that the target platform would
not have to be re-created everyime? That could speed up the builds
considerably. It could be esepcially useful where a few products use the
same target platform. For example RCP+EMF is a common one for me. Do you
expect to use a seperate hudson task for creating the target platform? It
would mean that your product build is structured well so that hudson can
bypass the target platform creation, which your command line builds would
not.
Thanks,
Tas
|
|
| |
| Re: Automated Testing of RCP Products with Buckminster [message #468009 is a reply to message #468002] |
Mon, 03 August 2009 11:22 |
| Eclipse User |
|
|
|
Hi Johannes,
I didn't mean that both command line and hudson would be running at the same
time. What I meant was that it is desirable to use the same scripts during
continuous builds as you do when you release the software. If you split
target creation away from your product build you'd need to make an effort to
structure your builds scrpits so that hudson can just bypass this small test
without needing to maintain it's own initial build script. When a build in
hudson works I want it to be as good a guarantee as possible that a manual
realase build will work.
Also, I think a big issue with hudson and rcp right now is one you already
know about: the way source code is checked out!
Tas.
"Johannes Utzig" <mail@jutzig.de> wrote in message
news:h56uat$s0b$1@build.eclipse.org...
> Hi Tas,
>
> Tas Frangoullides schrieb:
>
>> This does sounds interesting. Does this mean that the target platform
>> would not have to be re-created everyime? That could speed up the builds
>> considerably. It could be esepcially useful where a few products use the
>> same target platform. For example RCP+EMF is a common one for me.
>
> Yes, that's exactly what I had in mind. Let's say a company provides one
> or more target platforms for all the eclipse products. Seperating the
> target platform creation from the actual product builds would increase
> reusablitiy and the individual builds would IMO be simplified a lot (the
> target platform is just there, you just need to select a proper one
> instead of building it from scratch).
>
>> Do you expect to use a seperate hudson task for creating the target
>> platform? It would mean that your product build is structured well so
>> that hudson can bypass the target platform creation, which your command
>> line builds would not.
>>
> Yes, the target platform creation is a separate hudson task.
> Why would I have command line builds and hudson builds at the same time?
> There's hudson on the server side and there's the developers on the
> 'client' side. Developers have their own target platform anyway I'd say
> and since products created locally on a developers machine would never be
> released, there's no point in keeping the server TP and the local TP
> perfectly in-sync I'd say (although a developer can easily download the TP
> produced by hudson and set that as their target platform, of course).
> For a developer it would simply be buckminster -> invoke action -> create
> product and the same would happen in hudson. Only difference is the target
> platform.
>
> Best regards,
> Johannes
|
|
|
| Re: Automated Testing of RCP Products with Buckminster [message #468016 is a reply to message #468009] |
Mon, 03 August 2009 11:45 |
| Eclipse User |
|
|
|
Hi Tas,
Tas Frangoullides schrieb:
> Hi Johannes,
>
> I didn't mean that both command line and hudson would be running at the
> same time. What I meant was that it is desirable to use the same scripts
> during continuous builds as you do when you release the software. If you
> split target creation away from your product build you'd need to make an
> effort to structure your builds scrpits so that hudson can just bypass
> this small test without needing to maintain it's own initial build
> script. When a build in hudson works I want it to be as good a guarantee
> as possible that a manual realase build will work.
>
In my opinion a target platform is an artifact the RCP build depends on
not a side-product of the RCP build. Therefore it seems naturally for me
to split those two apart. A command line build will have to do the exact
same thing like the hudson build:
get the target platform from somewhere (it is either already there, or
needs to be created) and make it known to buckminster (e.g. setpref
targetPlatformPath).
So I don't really know what you mean by bypassing, if you have a script
that does both tasks it is not much of a difference to having two hudson
jobs. One builds a TP, the other uses it. In the hudson setup, the TP is
referenced declarative, in the command line script it is referenced
imperative. The result will be the same.
> Also, I think a big issue with hudson and rcp right now is one you
> already know about: the way source code is checked out!
>
I don't see that much of a problem there. In my setup I do things the
following: I have an rmap with a search path for the bundles to be
built. There are two resolvers in that path, one that's using the SCM
directly, the other is a local resolver that looks relative to the
working directory. The local resolver succeeds only for the hudson build
where hudson does the checkout and buckminster's working directory is
set to the path of the workspace. On all other builds the local resolver
will fail and the CVS resolver is used instead. That way I can make use
of Hudson's SCM capabilities while still using the same queries and
rmaps locally or in shell scripts.
You can of course let buckminster always do the checkout, but I
personally like the change log generated by hudson.
As soon as I find the time to do so, I'll see what I can do to patch
buckminster in a way that it's capable of CVS/SVN update and print out
the change log, then I'll enhance the hudson plugin to use buckminster
as a 'meta-SCM' and then you get the best out of both worlds.
Best regards,
Johannes
|
|
|
| Re: Automated Testing of RCP Products with Buckminster [message #468021 is a reply to message #468016] |
Mon, 03 August 2009 12:30 |
| Eclipse User |
|
|
|
Johannes
>
> In my opinion a target platform is an artifact the RCP build depends on
> not a side-product of the RCP build. Therefore it seems naturally for me
> to split those two apart. A command line build will have to do the exact
> same thing like the hudson build:
> get the target platform from somewhere (it is either already there, or
> needs to be created) and make it known to buckminster (e.g. setpref
> targetPlatformPath).
> So I don't really know what you mean by bypassing, if you have a script
> that does both tasks it is not much of a difference to having two hudson
> jobs. One builds a TP, the other uses it. In the hudson setup, the TP is
> referenced declarative, in the command line script it is referenced
> imperative. The result will be the same.
I think we are agreeing becuase you are implying a check to see if the TP
already exists and if not then create it. This is what I mean by bypass.
Maybe where our view of target platforms differ only slightly is that
although products with common TPs can just view it as dependency, there are
many which have unique target platforms and for these products the TP
creation step will be very cusomised.
>> Also, I think a big issue with hudson and rcp right now is one you
>> already know about: the way source code is checked out!
>>
>
> I don't see that much of a problem there. In my setup I do things the
> following: I have an rmap with a search path for the bundles to be built.
> There are two resolvers in that path, one that's using the SCM directly,
> the other is a local resolver that looks relative to the working
> directory. The local resolver succeeds only for the hudson build where
> hudson does the checkout and buckminster's working directory is set to the
> path of the workspace. On all other builds the local resolver will fail
> and the CVS resolver is used instead. That way I can make use of Hudson's
> SCM capabilities while still using the same queries and rmaps locally or
> in shell scripts.
> You can of course let buckminster always do the checkout, but I personally
> like the change log generated by hudson.
> As soon as I find the time to do so, I'll see what I can do to patch
> buckminster in a way that it's capable of CVS/SVN update and print out the
> change log, then I'll enhance the hudson plugin to use buckminster as a
> 'meta-SCM' and then you get the best out of both worlds.
Yeah. I understand this solution and it will work for RCP apps where all the
code is under one location in subversion. However, if your products are
split into many compoents each with their own subversion trunk/branch/tag
then it doesn't work so well. Buckminster is able to deal with this using
rmaps but hudson just doesn't work this way. I think my workaround will be
to have seperate builds for each component which then trigger each other,
and use the approach you describe above for the component specific code and
let buckminster resolve the rest. The nasty part is maintaining the build
triggers to reflect you component dependencies.
Thanks,
Tas.
|
|
|
| Re: Automated Testing of RCP Products with Buckminster [message #468359 is a reply to message #467916] |
Wed, 05 August 2009 04:52 |
| Eclipse User |
|
|
|
Hi Achim,
While working on the testing part of my build I have been considering the
way I want it to work and have some questions about the functionality you
are adding to buckminster.
Am I right in thinking that your implementation will run the tests in
buckminsters build environment? An advantage of this is that it is very
close to what a developer executres in his IDE. However, I've always like
testing the final deployable artifacts by adding only the bare minimum
dependencies required to execute the tests. This has a benefit of testing
that all required plugins have been included in your product and that it
will work when installed. Do you imagine supporting this kind of testing?
Thanks,
Tas
"Achim Demelt" <a.demelt@exxcellent.de> wrote in message
news:h56i03$ipq$1@build.eclipse.org...
> Tas,
>
> I published a very early demo version here: http://buckminster-
> contrib.googlecode.com/files/site_1.0.0.200906052157-1--311_ 17163268.zip
>
> This version is rather old (around the 3.5 RC timeframe), so I cannot
> guarantee that it's still working. Also, please read
> http://code.google.com/p/buckminster-contrib/wiki/Buckminste rJUnit before
> trying it out. The most important restriction is that it's _not_ capable
> of
> running plug-in tests. It only supports plain Java JUnit tests. This will
> probably render it pretty much useless for your RCP tests...
>
> Regards,
> Achim
>
> Tas Frangoullides wrote:
>
>> Hi Achim,
>>
>> Is there an update site I can get this from to try it out?
>>
>> Thanks,
>> Tas
>>
>>
>> "Achim Demelt" <a.demelt@exxcellent.de> wrote in message
>> news:h56du9$chm$1@build.eclipse.org...
>>> Tas,
>>>
>>> This is work-in-progress. Please see
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=243293 for more
>>> information.
>>>
>>> The headless build will then basically be able to run the tests in the
>>> same
>>> way as you would run them interactively in your IDE.
>>>
>>> Regards,
>>> Achim
>>>
>>> Tas Frangoullides wrote:
>>>
>>>> Hi,
>>>>
>>>> I wondering what the best way of approaching testing with buckminster
>>>> is. I tried examining the buckminster build to find out where you run
>>>> your tests but I can't see anything.
>>>>
>>>> My previous builds use the Eclipse Test Framework. They create an
>>>> eclipse environment from the recently built distribution artifacts,
>>>> install the tests and necessary dependencies and then kick-off the
>>>> tests
>>>> and gather results. I'm not sure where buckminster could be leveraged
>>>> in
>>>> this and was
>>>> curious about the new test functionaloty you are adding. Where would
>>>> this fit in?
>>>>
>>>> Thanks,
>>>> Tas
>>>
>>>
>
>
|
|
|
| Re: Automated Testing of RCP Products with Buckminster [message #468369 is a reply to message #468359] |
Wed, 05 August 2009 05:58 |
| Eclipse User |
|
|
|
Hi Tas,
You can specify the set of enabled bundles for your tests in the launch
configuration. While this will probably not be exactly the same environment
as the final product, you can nonetheless get quite close to it.
Alternatively, you could first build your product and then materialize your
tests in a separate workspace. This other workspace can use the product as
its target platform. The test's launch configuration can then include all
workspace bundles (i.e. the test cases) and all target platform bundles.
HTH,
Achim
Tas Frangoullides wrote:
> Hi Achim,
>
> While working on the testing part of my build I have been considering the
> way I want it to work and have some questions about the functionality you
> are adding to buckminster.
>
> Am I right in thinking that your implementation will run the tests in
> buckminsters build environment? An advantage of this is that it is very
> close to what a developer executres in his IDE. However, I've always like
> testing the final deployable artifacts by adding only the bare minimum
> dependencies required to execute the tests. This has a benefit of testing
> that all required plugins have been included in your product and that it
> will work when installed. Do you imagine supporting this kind of testing?
>
> Thanks,
> Tas
>
> "Achim Demelt" <a.demelt@exxcellent.de> wrote in message
> news:h56i03$ipq$1@build.eclipse.org...
>> Tas,
>>
>> I published a very early demo version here: http://buckminster-
>> contrib.googlecode.com/files/site_1.0.0.200906052157-1--311_ 17163268.zip
>>
>> This version is rather old (around the 3.5 RC timeframe), so I cannot
>> guarantee that it's still working. Also, please read
>> http://code.google.com/p/buckminster-contrib/wiki/Buckminste rJUnit before
>> trying it out. The most important restriction is that it's _not_ capable
>> of
>> running plug-in tests. It only supports plain Java JUnit tests. This will
>> probably render it pretty much useless for your RCP tests...
>>
>> Regards,
>> Achim
>>
>> Tas Frangoullides wrote:
>>
>>> Hi Achim,
>>>
>>> Is there an update site I can get this from to try it out?
>>>
>>> Thanks,
>>> Tas
>>>
>>>
>>> "Achim Demelt" <a.demelt@exxcellent.de> wrote in message
>>> news:h56du9$chm$1@build.eclipse.org...
>>>> Tas,
>>>>
>>>> This is work-in-progress. Please see
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=243293 for more
>>>> information.
>>>>
>>>> The headless build will then basically be able to run the tests in the
>>>> same
>>>> way as you would run them interactively in your IDE.
>>>>
>>>> Regards,
>>>> Achim
>>>>
>>>> Tas Frangoullides wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I wondering what the best way of approaching testing with buckminster
>>>>> is. I tried examining the buckminster build to find out where you run
>>>>> your tests but I can't see anything.
>>>>>
>>>>> My previous builds use the Eclipse Test Framework. They create an
>>>>> eclipse environment from the recently built distribution artifacts,
>>>>> install the tests and necessary dependencies and then kick-off the
>>>>> tests
>>>>> and gather results. I'm not sure where buckminster could be leveraged
>>>>> in
>>>>> this and was
>>>>> curious about the new test functionaloty you are adding. Where would
>>>>> this fit in?
>>>>>
>>>>> Thanks,
>>>>> Tas
>>>>
>>>>
>>
>>
|
|
|
| Re: Automated Testing of RCP Products with Buckminster [message #468383 is a reply to message #468369] |
Wed, 05 August 2009 06:32 |
| Eclipse User |
|
|
|
Hi Achim,
I forgot about the ability to configure which plugins you want in the launch
configurations. This helps.
You alternative approach is also interesting. I guess it's not too different
to what I am doing now but it will be much more convenient.
Thanks,
Tas
"Achim Demelt" <a.demelt@exxcellent.de> wrote in message
news:h5bl4n$us6$1@build.eclipse.org...
> Hi Tas,
>
> You can specify the set of enabled bundles for your tests in the launch
> configuration. While this will probably not be exactly the same
> environment
> as the final product, you can nonetheless get quite close to it.
>
> Alternatively, you could first build your product and then materialize
> your
> tests in a separate workspace. This other workspace can use the product as
> its target platform. The test's launch configuration can then include all
> workspace bundles (i.e. the test cases) and all target platform bundles.
>
> HTH,
> Achim
>
> Tas Frangoullides wrote:
>
>> Hi Achim,
>>
>> While working on the testing part of my build I have been considering the
>> way I want it to work and have some questions about the functionality you
>> are adding to buckminster.
>>
>> Am I right in thinking that your implementation will run the tests in
>> buckminsters build environment? An advantage of this is that it is very
>> close to what a developer executres in his IDE. However, I've always like
>> testing the final deployable artifacts by adding only the bare minimum
>> dependencies required to execute the tests. This has a benefit of testing
>> that all required plugins have been included in your product and that it
>> will work when installed. Do you imagine supporting this kind of testing?
>>
>> Thanks,
>> Tas
>>
>> "Achim Demelt" <a.demelt@exxcellent.de> wrote in message
>> news:h56i03$ipq$1@build.eclipse.org...
>>> Tas,
>>>
>>> I published a very early demo version here: http://buckminster-
>>> contrib.googlecode.com/files/site_1.0.0.200906052157-1--311_ 17163268.zip
>>>
>>> This version is rather old (around the 3.5 RC timeframe), so I cannot
>>> guarantee that it's still working. Also, please read
>>> http://code.google.com/p/buckminster-contrib/wiki/Buckminste rJUnit
>>> before
>>> trying it out. The most important restriction is that it's _not_ capable
>>> of
>>> running plug-in tests. It only supports plain Java JUnit tests. This
>>> will
>>> probably render it pretty much useless for your RCP tests...
>>>
>>> Regards,
>>> Achim
>>>
>>> Tas Frangoullides wrote:
>>>
>>>> Hi Achim,
>>>>
>>>> Is there an update site I can get this from to try it out?
>>>>
>>>> Thanks,
>>>> Tas
>>>>
>>>>
>>>> "Achim Demelt" <a.demelt@exxcellent.de> wrote in message
>>>> news:h56du9$chm$1@build.eclipse.org...
>>>>> Tas,
>>>>>
>>>>> This is work-in-progress. Please see
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=243293 for more
>>>>> information.
>>>>>
>>>>> The headless build will then basically be able to run the tests in the
>>>>> same
>>>>> way as you would run them interactively in your IDE.
>>>>>
>>>>> Regards,
>>>>> Achim
>>>>>
>>>>> Tas Frangoullides wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I wondering what the best way of approaching testing with buckminster
>>>>>> is. I tried examining the buckminster build to find out where you run
>>>>>> your tests but I can't see anything.
>>>>>>
>>>>>> My previous builds use the Eclipse Test Framework. They create an
>>>>>> eclipse environment from the recently built distribution artifacts,
>>>>>> install the tests and necessary dependencies and then kick-off the
>>>>>> tests
>>>>>> and gather results. I'm not sure where buckminster could be leveraged
>>>>>> in
>>>>>> this and was
>>>>>> curious about the new test functionaloty you are adding. Where would
>>>>>> this fit in?
>>>>>>
>>>>>> Thanks,
>>>>>> Tas
>>>>>
>>>>>
>>>
>>>
>
|
|
|
Goto Forum:
Current Time: Thu Jul 17 00:00:52 EDT 2025
Powered by FUDForum. Page generated in 0.10724 seconds |
Home