You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by Andreas Veithen <an...@gmail.com> on 2009/03/01 15:28:17 UTC
Re: Transports tests
The tests are in a separate module to avoid circular dependencies. See
[1] for the relevant discussion.
Andreas
[1] http://markmail.org/message/f5u53wueyymfsk7t
On Sat, Feb 28, 2009 at 21:22, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hey devs:
>
> Why are all the tests for all the transports under a separate "tests"
> module?
>
> I would expect that building the JMS transport, by itself, would both
> assemble and test the JMS code. Likewise for HTTP, TCP, etc. As it
> stands it would appear you have to build the whole project just to
> update and test a single transport...
>
> Can someone explain why the current state of things is better than just
> having tests in each module? Otherwise, can we please fix it?
>
> Thanks,
> --Glen
>
Re: Transports tests
Posted by Andreas Veithen <an...@gmail.com>.
If we can break the circular dependencies like that, I'm +1 for for
moving the tests to the individual modules. Who is volunteering to do
this?
Andreas
On Sun, Mar 1, 2009 at 17:54, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi Andreas, all:
>
> (axis-dev'ers who aren't on commons-dev - this conversation is about the
> fact that the transport tests for ALL the transports are in a separate
> "tests" module in the transports project. This means that when you
> build an individual transport, no functional tests are actually run,
> which seems quite bad to me.)
>
> Andreas Veithen wrote:
>> The tests are in a separate module to avoid circular dependencies. See
>> [1] for the relevant discussion.
>>
>> Andreas
>>
>> [1] http://markmail.org/message/f5u53wueyymfsk7t
>
> OK, I read the discussion thread, and I'm not sure that this was the
> best solution to the problem....
>
> Wouldn't another, better, approach be to break the dependency from the
> addressing module to the (non-essential) transports?
>
> I just took a look, and the only reason those dependencies were there
> was because there were a ton of calls to
> ConfigurationContextFactory.createDefaultConfigurationContext() speckled
> about the addressing tests - the default axis2.xml has http, tcp, and
> local transports baked in. The addressing tests are all unit tests, and
> none of them in fact actually *use* any of the transports.
>
> I've changed all the above calls to call
> createEmptyConfigurationContext() instead, and the addressing module
> builds and tests just fine. As such I've removed the dependencies to
> the transports, and am just doing a clean rebuild to make sure
> everything works ok.
>
> NOW can we get rid of the transports test module please? :)
>
> Thanks,
> --Glen
>
Re: Transports tests
Posted by Andreas Veithen <an...@gmail.com>.
If we can break the circular dependencies like that, I'm +1 for for
moving the tests to the individual modules. Who is volunteering to do
this?
Andreas
On Sun, Mar 1, 2009 at 17:54, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi Andreas, all:
>
> (axis-dev'ers who aren't on commons-dev - this conversation is about the
> fact that the transport tests for ALL the transports are in a separate
> "tests" module in the transports project. This means that when you
> build an individual transport, no functional tests are actually run,
> which seems quite bad to me.)
>
> Andreas Veithen wrote:
>> The tests are in a separate module to avoid circular dependencies. See
>> [1] for the relevant discussion.
>>
>> Andreas
>>
>> [1] http://markmail.org/message/f5u53wueyymfsk7t
>
> OK, I read the discussion thread, and I'm not sure that this was the
> best solution to the problem....
>
> Wouldn't another, better, approach be to break the dependency from the
> addressing module to the (non-essential) transports?
>
> I just took a look, and the only reason those dependencies were there
> was because there were a ton of calls to
> ConfigurationContextFactory.createDefaultConfigurationContext() speckled
> about the addressing tests - the default axis2.xml has http, tcp, and
> local transports baked in. The addressing tests are all unit tests, and
> none of them in fact actually *use* any of the transports.
>
> I've changed all the above calls to call
> createEmptyConfigurationContext() instead, and the addressing module
> builds and tests just fine. As such I've removed the dependencies to
> the transports, and am just doing a clean rebuild to make sure
> everything works ok.
>
> NOW can we get rid of the transports test module please? :)
>
> Thanks,
> --Glen
>
Re: Transports tests
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Andreas, all:
(axis-dev'ers who aren't on commons-dev - this conversation is about the
fact that the transport tests for ALL the transports are in a separate
"tests" module in the transports project. This means that when you
build an individual transport, no functional tests are actually run,
which seems quite bad to me.)
Andreas Veithen wrote:
> The tests are in a separate module to avoid circular dependencies. See
> [1] for the relevant discussion.
>
> Andreas
>
> [1] http://markmail.org/message/f5u53wueyymfsk7t
OK, I read the discussion thread, and I'm not sure that this was the
best solution to the problem....
Wouldn't another, better, approach be to break the dependency from the
addressing module to the (non-essential) transports?
I just took a look, and the only reason those dependencies were there
was because there were a ton of calls to
ConfigurationContextFactory.createDefaultConfigurationContext() speckled
about the addressing tests - the default axis2.xml has http, tcp, and
local transports baked in. The addressing tests are all unit tests, and
none of them in fact actually *use* any of the transports.
I've changed all the above calls to call
createEmptyConfigurationContext() instead, and the addressing module
builds and tests just fine. As such I've removed the dependencies to
the transports, and am just doing a clean rebuild to make sure
everything works ok.
NOW can we get rid of the transports test module please? :)
Thanks,
--Glen
Re: Transports tests
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Andreas, all:
(axis-dev'ers who aren't on commons-dev - this conversation is about the
fact that the transport tests for ALL the transports are in a separate
"tests" module in the transports project. This means that when you
build an individual transport, no functional tests are actually run,
which seems quite bad to me.)
Andreas Veithen wrote:
> The tests are in a separate module to avoid circular dependencies. See
> [1] for the relevant discussion.
>
> Andreas
>
> [1] http://markmail.org/message/f5u53wueyymfsk7t
OK, I read the discussion thread, and I'm not sure that this was the
best solution to the problem....
Wouldn't another, better, approach be to break the dependency from the
addressing module to the (non-essential) transports?
I just took a look, and the only reason those dependencies were there
was because there were a ton of calls to
ConfigurationContextFactory.createDefaultConfigurationContext() speckled
about the addressing tests - the default axis2.xml has http, tcp, and
local transports baked in. The addressing tests are all unit tests, and
none of them in fact actually *use* any of the transports.
I've changed all the above calls to call
createEmptyConfigurationContext() instead, and the addressing module
builds and tests just fine. As such I've removed the dependencies to
the transports, and am just doing a clean rebuild to make sure
everything works ok.
NOW can we get rid of the transports test module please? :)
Thanks,
--Glen