Hello Tom!
If someone wants to work with and run a nightly build set-up, a CI-server,
or just the coverage analysis, I think it is acceptable to let them check
out another project where the configuration files and tools required are
place. I consider such developers to go beyond what we require for all
developers. The argouml-gen project is that other project.
The argouml-gen project already contains cobertura and build files to run
all unit tests with coverage. Alas they are not working but I'd appreciate a
statement that it is beyond repair before we abandon it to create a new
set-up.
The build.xml file of the argouml-app "subsystem" is not the core build.xml.
It is the build.xml file for the argouml-app part of the code i.e. currently
everything that is not split into its own subsystem. In the nightly build
set-up the build.xml from the argouml-build directory (previously the src
directory) is extended with cobertura things (as well as jdepend,
checkstyle, and findbugs) most of which is not currently working.
Is the coverage contribution from the tests in the argouml-core-model-mdr
subsystem included in the report? Will it be? Can we get a coverage report
from the tests in the argouml-cpp project?
/Linus
2008/4/27, Tom Morris <[EMAIL PROTECTED]>:
>
> Since these are all build time tools, another possibility might be
> argouml-build instead of argouml-core-infra. Of course they could
> also move to src/argouml-core-tools, but I'm not sure we need all
> three projects/directories.
>
> On Sat, Apr 26, 2008 at 6:23 PM, Linus Tolke <[EMAIL PROTECTED]> wrote:
>
> > In the directories under src (as well as for the projects from other
> > projects argouml-cpp, argouml-csharp etc), the ambition is that each
> > directory is self-contained except for explicit dependencies. If such a
> > subsystem requires a tool, that tool is located in that subsystem or in
> a
> > central place (the Eclipse set-up or tools in the top directory). If
> several
> > subsystems requires a tool, that tool is located in each of these
> subsystems
> > of in a central place.
>
> That sounds reasonable. I don't think aligning the directory
> structures of our two build environments is in conflict with that. We
> can probably move FOP to the documentation project/directory since
> it's specific to that, but otherwise I think all the current tools are
> project independent.
>
> > Why was the cobertura added in this way?
>
> So that it would be available for individual developers as well as the
> CI build server. Seems like it could be useful for the nightly build
> as well. Having it in the core build.xml file makes it available to
> everyone in a central place.
>
> > Isn't there an Eclipse cobertura plug-in that works with JUnit
> configurations?
>
> I'm not sure, but there was one for jCoverage from which cobertura was
> forked, so it's certainly possible. Even if there is though, it
> wouldn't provide coverage reports for the JUnit tests which are run by
> the Ant build and it most likely would provide results in the GUI
> instead of the HTML that a developer would want or the XML that a
> build server would want.
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
