You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by zoe slattery <zo...@gmail.com> on 2010/09/22 11:46:29 UTC
Re: blog and aries trader assembly
Hi
The assembly projects assemble the OSGi platform needed to run samples.
The only way to be _completely_ certain that the assembly hasn't been
broken is to is to run the sample. We introduced i-tests for Aries
Trader and the Blog Sample that mimic the behaviour of the assembly
projects, and these give a good indication of when an assembly is likely
to have been broken. So the first rule is that if you have to change a
sample i-test you almost certainly have to change the assembly project.
The place where the assembly differs from the i-test is that, to run an
eba on the platform which has been assembled, you have to copy the eba
into a load directory. This exact process is not replicated in the
i-tests so anyone making changes to application, and in particular, the
code which installs applications really should (currently) manually run
the blog sample :-)
I think we might be able to do some more sophisticated testing, but I'm
not sure how. The other option is for developers to periodically run the
blog sample. Of course, there are other samples (hello world) which
don't have i-tests and are probably broken too.
More generally - there seems to have been some significant re-factoring
'Application', thinking ahead to the next release - could someone
summarise the changes?
Zoë
> I am just wondering how to remind people (especially new joiners) to
> maintain the assembly code as the full assembly process is not part of
> build. Is it too much to make it part of build? Any thoughts?
>
> Regards
> Emily
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
>
Re: blog and aries trader assembly
Posted by Emily Jiang <EM...@uk.ibm.com>.
Thanks, Zoe. It is much clearer now. Yep. I agree we need more thinking
about the process of maintaining the assembly samples.
The recent 'Application' refactoring introduced a few more dependencies:
mavenBundle("org.apache.aries.application",
"org.apache.aries.application.modeller"),
mavenBundle("org.apache.aries.application",
"org.apache.aries.application.deployment.management"),
I will go through the samples and fix them.
Many thanks and kindest regards,
Emily
===========================
Emily Jiang
WebSphere ESB Foundation Technologies
MP 211, DE3A25, Winchester, Hampshire, England, SO21 2JN
Phone: +44 (0)1962 816278 Internal: 246278
Email: emijiang@uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@IBMGB
From: zoe slattery <zo...@gmail.com>
To: aries-dev@incubator.apache.org
Date: 22/09/2010 10:47
Subject: Re: blog and aries trader assembly
Hi
The assembly projects assemble the OSGi platform needed to run samples.
The only way to be _completely_ certain that the assembly hasn't been
broken is to is to run the sample. We introduced i-tests for Aries
Trader and the Blog Sample that mimic the behaviour of the assembly
projects, and these give a good indication of when an assembly is likely
to have been broken. So the first rule is that if you have to change a
sample i-test you almost certainly have to change the assembly project.
The place where the assembly differs from the i-test is that, to run an
eba on the platform which has been assembled, you have to copy the eba
into a load directory. This exact process is not replicated in the
i-tests so anyone making changes to application, and in particular, the
code which installs applications really should (currently) manually run
the blog sample :-)
I think we might be able to do some more sophisticated testing, but I'm
not sure how. The other option is for developers to periodically run the
blog sample. Of course, there are other samples (hello world) which
don't have i-tests and are probably broken too.
More generally - there seems to have been some significant re-factoring
'Application', thinking ahead to the next release - could someone
summarise the changes?
Zoë
> I am just wondering how to remind people (especially new joiners) to
> maintain the assembly code as the full assembly process is not part of
> build. Is it too much to make it part of build? Any thoughts?
>
> Regards
> Emily
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
>
>
>
>
>
>
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: blog and aries trader assembly
Posted by Joe Bohn <jo...@gmail.com>.
Oh yes ... one other difference between the blog-assembly and
equinox-test-harness is that for AriesTrader we copy the *.eba artifacts
into the target of the assembly so that they are easy to locate for the
actual copy to /load. We could do the same for all samples that we want
to test on a common test harness.
We could also create a felix-test-harness for even better coverage.
Joe
On 9/22/10 11:34 AM, Joe Bohn wrote:
> I agree tests that leverage the actual assembly would be nice. I've
> often found problems because I run the Blog and AriesTrader samples and
> many folks don't.
>
> One minor correction to Zoe's note is that there are not yet any itests
> for AriesTrader ... but I've created a JIRA so I don't forget to create
> some.
>
> Ideally, we should have all of the itests running on the actual sample
> assembly rather than simulating the assembly with the itests (which I
> believe is the current configuration for the Blog itests).
>
> Also, I think we should create a single test harness assembly that can
> be shared for all of our samples. AFAIK, the only difference between
> blog-assembly (for Blog) and the equinox-test-harness (for AriesTrader)
> are that each includes the respective datasource bundle for their
> particular sample. I original created (and named) the
> equinox-test-harness with the idea that it should be moved to a new
> location and enhanced to support multiple samples.
>
> Incorporating the actual assembly we create for users into the itests
> would definitely provide much better test coverage.
>
> Joe
>
> On 9/22/10 6:31 AM, Timothy Ward wrote:
>>
>> I really think that we need to run the assemblies as part of our
>> testing every build.
>>
>> We can use embedded ant to launch the assembly, and to copy the EBA
>> into the load directory, then to launch some standard JUnits that ping
>> the servlets to see if they're awake. This will give us a much more
>> reliable mechanism to show that the assemblies work.
>>
>> Tim
>>
>> ----------------------------------------
>>> Date: Wed, 22 Sep 2010 10:46:29 +0100
>>> From: zoe.slattery@gmail.com
>>> To: aries-dev@incubator.apache.org
>>> Subject: Re: blog and aries trader assembly
>>>
>>> Hi
>>>
>>> The assembly projects assemble the OSGi platform needed to run samples.
>>> The only way to be _completely_ certain that the assembly hasn't been
>>> broken is to is to run the sample. We introduced i-tests for Aries
>>> Trader and the Blog Sample that mimic the behaviour of the assembly
>>> projects, and these give a good indication of when an assembly is likely
>>> to have been broken. So the first rule is that if you have to change a
>>> sample i-test you almost certainly have to change the assembly project.
>>>
>>> The place where the assembly differs from the i-test is that, to run an
>>> eba on the platform which has been assembled, you have to copy the eba
>>> into a load directory. This exact process is not replicated in the
>>> i-tests so anyone making changes to application, and in particular, the
>>> code which installs applications really should (currently) manually run
>>> the blog sample :-)
>>>
>>> I think we might be able to do some more sophisticated testing, but I'm
>>> not sure how. The other option is for developers to periodically run the
>>> blog sample. Of course, there are other samples (hello world) which
>>> don't have i-tests and are probably broken too.
>>>
>>> More generally - there seems to have been some significant re-factoring
>>> 'Application', thinking ahead to the next release - could someone
>>> summarise the changes?
>>>
>>> Zoë
>>>
>>>
>>>> I am just wondering how to remind people (especially new joiners) to
>>>> maintain the assembly code as the full assembly process is not part of
>>>> build. Is it too much to make it part of build? Any thoughts?
>>>>
>>>> Regards
>>>> Emily
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Unless stated otherwise above:
>>>> IBM United Kingdom Limited - Registered in England and Wales with
>>>> number
>>>> 741598.
>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
>>>> PO6 3AU
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
--
Joe
Re: blog and aries trader assembly
Posted by Joe Bohn <jo...@gmail.com>.
I agree tests that leverage the actual assembly would be nice. I've
often found problems because I run the Blog and AriesTrader samples and
many folks don't.
One minor correction to Zoe's note is that there are not yet any itests
for AriesTrader ... but I've created a JIRA so I don't forget to create
some.
Ideally, we should have all of the itests running on the actual sample
assembly rather than simulating the assembly with the itests (which I
believe is the current configuration for the Blog itests).
Also, I think we should create a single test harness assembly that can
be shared for all of our samples. AFAIK, the only difference between
blog-assembly (for Blog) and the equinox-test-harness (for AriesTrader)
are that each includes the respective datasource bundle for their
particular sample. I original created (and named) the
equinox-test-harness with the idea that it should be moved to a new
location and enhanced to support multiple samples.
Incorporating the actual assembly we create for users into the itests
would definitely provide much better test coverage.
Joe
On 9/22/10 6:31 AM, Timothy Ward wrote:
>
> I really think that we need to run the assemblies as part of our testing every build.
>
> We can use embedded ant to launch the assembly, and to copy the EBA into the load directory, then to launch some standard JUnits that ping the servlets to see if they're awake. This will give us a much more reliable mechanism to show that the assemblies work.
>
> Tim
>
> ----------------------------------------
>> Date: Wed, 22 Sep 2010 10:46:29 +0100
>> From: zoe.slattery@gmail.com
>> To: aries-dev@incubator.apache.org
>> Subject: Re: blog and aries trader assembly
>>
>> Hi
>>
>> The assembly projects assemble the OSGi platform needed to run samples.
>> The only way to be _completely_ certain that the assembly hasn't been
>> broken is to is to run the sample. We introduced i-tests for Aries
>> Trader and the Blog Sample that mimic the behaviour of the assembly
>> projects, and these give a good indication of when an assembly is likely
>> to have been broken. So the first rule is that if you have to change a
>> sample i-test you almost certainly have to change the assembly project.
>>
>> The place where the assembly differs from the i-test is that, to run an
>> eba on the platform which has been assembled, you have to copy the eba
>> into a load directory. This exact process is not replicated in the
>> i-tests so anyone making changes to application, and in particular, the
>> code which installs applications really should (currently) manually run
>> the blog sample :-)
>>
>> I think we might be able to do some more sophisticated testing, but I'm
>> not sure how. The other option is for developers to periodically run the
>> blog sample. Of course, there are other samples (hello world) which
>> don't have i-tests and are probably broken too.
>>
>> More generally - there seems to have been some significant re-factoring
>> 'Application', thinking ahead to the next release - could someone
>> summarise the changes?
>>
>> Zoë
>>
>>
>>> I am just wondering how to remind people (especially new joiners) to
>>> maintain the assembly code as the full assembly process is not part of
>>> build. Is it too much to make it part of build? Any thoughts?
>>>
>>> Regards
>>> Emily
>>>
>>>
>>>
>>>
>>>
>>> Unless stated otherwise above:
>>> IBM United Kingdom Limited - Registered in England and Wales with number
>>> 741598.
>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
--
Joe
Re: blog and aries trader assembly
Posted by Alasdair Nottingham <no...@apache.org>.
I don't see why we can't copy the .eba to the load directory of target
during the pax based tests.
On 22 September 2010 03:31, Timothy Ward <ti...@hotmail.com> wrote:
>
> I really think that we need to run the assemblies as part of our testing every build.
>
> We can use embedded ant to launch the assembly, and to copy the EBA into the load directory, then to launch some standard JUnits that ping the servlets to see if they're awake. This will give us a much more reliable mechanism to show that the assemblies work.
>
> Tim
>
> ----------------------------------------
>> Date: Wed, 22 Sep 2010 10:46:29 +0100
>> From: zoe.slattery@gmail.com
>> To: aries-dev@incubator.apache.org
>> Subject: Re: blog and aries trader assembly
>>
>> Hi
>>
>> The assembly projects assemble the OSGi platform needed to run samples.
>> The only way to be _completely_ certain that the assembly hasn't been
>> broken is to is to run the sample. We introduced i-tests for Aries
>> Trader and the Blog Sample that mimic the behaviour of the assembly
>> projects, and these give a good indication of when an assembly is likely
>> to have been broken. So the first rule is that if you have to change a
>> sample i-test you almost certainly have to change the assembly project.
>>
>> The place where the assembly differs from the i-test is that, to run an
>> eba on the platform which has been assembled, you have to copy the eba
>> into a load directory. This exact process is not replicated in the
>> i-tests so anyone making changes to application, and in particular, the
>> code which installs applications really should (currently) manually run
>> the blog sample :-)
>>
>> I think we might be able to do some more sophisticated testing, but I'm
>> not sure how. The other option is for developers to periodically run the
>> blog sample. Of course, there are other samples (hello world) which
>> don't have i-tests and are probably broken too.
>>
>> More generally - there seems to have been some significant re-factoring
>> 'Application', thinking ahead to the next release - could someone
>> summarise the changes?
>>
>> Zoë
>>
>>
>>> I am just wondering how to remind people (especially new joiners) to
>>> maintain the assembly code as the full assembly process is not part of
>>> build. Is it too much to make it part of build? Any thoughts?
>>>
>>> Regards
>>> Emily
>>>
>>>
>>>
>>>
>>>
>>> Unless stated otherwise above:
>>> IBM United Kingdom Limited - Registered in England and Wales with number
>>> 741598.
>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
--
Alasdair Nottingham
not@apache.org
RE: blog and aries trader assembly
Posted by Timothy Ward <ti...@hotmail.com>.
I really think that we need to run the assemblies as part of our testing every build.
We can use embedded ant to launch the assembly, and to copy the EBA into the load directory, then to launch some standard JUnits that ping the servlets to see if they're awake. This will give us a much more reliable mechanism to show that the assemblies work.
Tim
----------------------------------------
> Date: Wed, 22 Sep 2010 10:46:29 +0100
> From: zoe.slattery@gmail.com
> To: aries-dev@incubator.apache.org
> Subject: Re: blog and aries trader assembly
>
> Hi
>
> The assembly projects assemble the OSGi platform needed to run samples.
> The only way to be _completely_ certain that the assembly hasn't been
> broken is to is to run the sample. We introduced i-tests for Aries
> Trader and the Blog Sample that mimic the behaviour of the assembly
> projects, and these give a good indication of when an assembly is likely
> to have been broken. So the first rule is that if you have to change a
> sample i-test you almost certainly have to change the assembly project.
>
> The place where the assembly differs from the i-test is that, to run an
> eba on the platform which has been assembled, you have to copy the eba
> into a load directory. This exact process is not replicated in the
> i-tests so anyone making changes to application, and in particular, the
> code which installs applications really should (currently) manually run
> the blog sample :-)
>
> I think we might be able to do some more sophisticated testing, but I'm
> not sure how. The other option is for developers to periodically run the
> blog sample. Of course, there are other samples (hello world) which
> don't have i-tests and are probably broken too.
>
> More generally - there seems to have been some significant re-factoring
> 'Application', thinking ahead to the next release - could someone
> summarise the changes?
>
> Zoë
>
>
>> I am just wondering how to remind people (especially new joiners) to
>> maintain the assembly code as the full assembly process is not part of
>> build. Is it too much to make it part of build? Any thoughts?
>>
>> Regards
>> Emily
>>
>>
>>
>>
>>
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>>
>>
>>
>>
>>
>>
>