Re: Directory Structure for java
On Jun 2, 10:04 am, Thomas Pornin <por...@bolet.org> wrote:
According to Andy Dingley <ding...@codesmiths.com>:
Automated unit test?
Part of the maven machinery. Junit tests. There is a cvs server on
which code is committed, and a specialized build machine which
performs continuous integration (including running the tests,
producing the HTML from Javadoc, performing zillions of measures
and verifications of coding style, code complexity and so on...).
None of this has any relation with the IDE (or lack thereof) that I use
to write the code. The build machine accesses the cvs server. The cvs
server is filled with files. Whether the files were graphically
presented to my eyes through Eclipse, NetBeans, vim-in-xterm or whatever
else has no bearing on the cvs server and the build machine.
A very important benefit of this approach is that it keeps IDE-
specific artifacts such as Eclipse's .project files out of the build
and out of the repository trunk.
I've worked in places where they "standardized" the IDE, for example
to Rational Application Developer. They felt it was easier if all the
developers shared their project files, so those got checked in with
the source. Naturally, every developer winds up marking their project
files writable outside the version control's control, so that they
won't pollute the "standard" project files with their workstation-
specific tweaks. This did not alert project leadership to the
weakness of the approach. Nor did the six weeks of effort it took to
migrate the project files when they upgraded the IDE. Twice, within a
year. Then went back to a reduced version.
Project files can be managed on a repository branch. Given a project
"foo" I'll create, say, a branch "Lew.nb.odin" for NetBeans-specific
files that apply to workstation "odin", "Lew.eclipse.odin" for Eclipse-
specific files on that same workstation, "Lew.nb.freja" for NetBeans
project files that pertain to the working directories on workstation
"freja", and so forth. Developer Jo would substitute "Jo" for "Lew"
in those branch tags.
Naturally those branches are never merged with the trunk and do not
participate in builds.
Trunk files should appear as though edited only with vi or emacs and
contain no project-specific or workstation-specific artifacts.
Developers should be free to use whatever development environment
tools suit their work style best. Their work product should adhere to
standards, e.g., be devoid of warnings or errors when built by the
central build process. How they achieve that, be it by setting their
IDE to highlight those warnings or by running Ant at their
workstation, is tertiary at best.