Sorry to post to this list but I'm currently dealing with this issue in
my own project and thought it would be appropriate to comment. Also,
I'm not sure where to post any buildmagic related questions or if there
is such a place to do so.
We've recently switched to buildmagic. I've more recently been setting
up testsuites just as you are suggesting here (where specific modules
have their own testsuite sub-module). We are currently intending to
implement a master testsuite module to run the other testsuites and to
perhaps contain cross module tests. So far, things are going ok but
there are some issues I'm trying to figure out.
Probably the biggest annoyance I have with using a sub-module is that
the ${project.root} property within the sub-module ends up including the
module above it instead of being the actual project root, so I have to
define my own local ${project.root.local} property in each sub-module.
To illustrate:
from a first level module:
${project.root}="/home/ssayles/src/myProject"
from within a sub-module:
${project.root}="/home/ssayles/src/myProject/myModule"
Is it possible to get this value to remain the real project root?
Perhaps I'm missing something?
Also, one of my thoughts is that we should raise developer awareness
about the associated tests for a module. In other words, if they change
something in the code which breaks the tests for that module, this
should be readily apparent. Of course, this will happen when you
execute the main build if you have your "module/testsuite" listsed as a
module. But I find that I will build often from within a specific
module that I'm working on and don't want to execute the main build
because it takes too long. I'm pretty new to buildmagic, so please
correct me if I'm mistaken in my approach. Based on this, I see two
probable scenarios for structuring the build for the sub-module
testsuites:
1. Add them as modules in the main build and continue to use the main
build.
e.g. modules="moduleFoo/testsuite"
This seems to fit appropriately within buildmagic
2. Force the integration of the module build with the associated
testsuite. In other words, have build targets within the module call
correlating targets in the testsuite sub-module. This does not seem to
fit within the buildmagic way of doing things (to me), but it could
work.
I like option 2 because when I run moduleFoo/build.sh, I know
immediately if I've broken a test compilation. But I'm not sure if we
should set things up like this. Any suggestions?
Thanks.
Scott
On Thu, 2002-09-19 at 20:48, Jason Dillon wrote:
> > So are you suggesting that there be, more or less, a build file per
> > testsuite directory (e.g. org/jboss/test/jmx gets a build.xml)? Then
> the
> > testsuite/build.xml calls each of them?
>
> No, I am suggesting there be a testsuite in each module.
> build/build.xml would be configured to recurse into them & collect the
> results for a final report. Or you could just run the module testsuite
> for the bits you are working on.
>
> Or if you are just interested in the integration tests, you can run
> jboss/testsuite. Or if you just care about how jboss/cluster works, you
> might run the cluster and testsuite module's tests target.
>
>
> > I think that would accomplish essentially the same thing I was
> suggesting
> > with the generic targets for "run xdoclet in one directory" and "build
> > jars from one directory" suggestion.
>
> Hrm, you gonna have to explain this again... I don't understand what ya
> mean here. Sorry =]
>
> --jason
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
