«

I am doing a research project on development environments
using the Unix philosophy of development (see for instance
http://www.faqs.org/docs/artu/ch01s06.html) with the hypothesis
that an environment of small, simple, exchangable tools
might outperform the use of heavyweight IDEs.

I am setting up a test environment and am planning to do
performance measurments (in terms of # keystrokes, time, robustness)
on typical development scenarios like check-outs, bug-report-fix-test-
deploy-cycles, create development area for new user etc, management
reporting etc.

An initial task includes defining the term "development environment"
and exactly what it covers (operating system, version control system,
programming language, editor, compiler, debugger, test environment,
build system, bug tracking, document handling, project control and
so on).

The environment must be scalable to 10+ developers and at least a
million lines of code. The current state of my setup is as follows
(including short rationale for each choice):

OS: Linux - fast, secure, availability of development tools, free.

VCS: Subversion - State of the art, simple, robust, free.

Language: Java&JDK - Versatile, multi-platform, well-documented,
easy to use, free.

Compiler: Jikes - Fast.

Deployment: JavaWebStart - Simple, fast, user-friendly.

Tools scripting: Python - Simple, well suited, state of the art, free.

Code documentation: Doxygen - Feature-rich, high quality documents, good
error reporting.

Editor: Whatever the developer prefers - Efficient, developer
satisfaction.

Unit testing: JUnit - State or the art.

Bug tracking: Flyspray - Simple, good quality, free.

Building: Make - Simple, versatile, free.

Coverage: Cobertura - Simple, fast, report quality, free.

Document collaboration: twiki - Simple, free.

I'd like feedback on the selection, and experience with these and
alternative tools.

I do miss tools for code metrics, debugging, profiling, and
project management (hours, calendar, resources, time estimates
etc) among others. Also, no particluar project process (like RUP)
w/tools, has been chosen. Suggestions and experience appreciated.

Thanks.

PS: Excuse me for being slightly off topic.

On Wed, 08 Feb 2006 22:31:38 -0000, Jacob <> wrote:

> OS: Linux - fast, secure, availability of development tools, free.
>
> VCS: Subversion - State of the art, simple, robust, free.

Agreed.

> Language: Java&JDK - Versatile, multi-platform, well-documented,
> easy to use, free.
>
> Compiler: Jikes - Fast.

Fast, but not up-to-date. Development stagnated for a while, and even now
there hasn't been a release in 16 months. If you want Java 5 support you
will probably have to settle for javac. Previous versions that I used
were fast but often buggy, and there seems to be a lot of unresolved
issues with the last release.

> Tools scripting: Python - Simple, well suited, state of the art, free.

What are you using the scripting language for?

> Code documentation: Doxygen - Feature-rich, high quality documents, good
> error reporting.

Why not Javadoc?

> Unit testing: JUnit - State or the art.

I'd argue that TestNG is much more state of the art. JUnit 4.0 might not
be so bad when it gets released.

> Building: Make - Simple, versatile, free.

Apache Ant is the de facto standard in Java land, though some people will
tell you that it is evil (see the thread "make not needed" from last week).

> PS: Excuse me for being slightly off topic.

You could also try comp.lang.java.softwaretools.

Dan.


--
Daniel Dyer
http://www.dandyer.co.uk

On Wed, 08 Feb 2006 23:39:13 -0000, "Daniel Dyer"
<> wrote, quoted or indirectly
quoted someone who said :

>
>> Unit testing: JUnit - State or the art.
>
>I'd argue that TestNG is much more state of the art. JUnit 4.0 might not
>be so bad when it gets released.

for other possibilities, see http://mindprod.com/jgloss/testing.html
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Daniel Dyer wrote:

>> Compiler: Jikes - Fast.
>
> Fast, but not up-to-date.

I am developing on 1.5 and rely on a robust compiler, and at the moment
I am actually using javac. I used to use jikes, and thought it were
finally up to speed on 1.5. If that's not the case I'll stick with
javac. Are there other alternatives? What about the the gcj?

>> Tools scripting: Python - Simple, well suited, state of the art, free.
>
> What are you using the scripting language for?

Simple administration tasks, like extracting a clean version from
the VCS and build everything from scratch every hour. Make does the
bulk of the job, but it needs to be kicked from somewhere.

>> Code documentation: Doxygen - Feature-rich, high quality documents, good
>> error reporting.
>
> Why not Javadoc?

I prefer the layout of Javadoc and it simplifies a lot to have
it as part of the language tools, but when comparing features
Doxygen seems far ahead (class hierarchy diagrams being one).
Check the rich options set of the Doxyfile and compare it to the
rather limited options of javadoc.

>> Unit testing: JUnit - State or the art.
>
> I'd argue that TestNG is much more state of the art. JUnit 4.0 might
> not be so bad when it gets released.

I'll check TestNG as I don't really like JUnit that much.
The API is wide and documentation is bad; Both hints of
a badly structured project.

>> Building: Make - Simple, versatile, free.
>
> Apache Ant is the de facto standard in Java land, though some people
> will tell you that it is evil (see the thread "make not needed" from
> last week).

Ant is not evil, but perhaps a bit to complex to fit my philiosophy,
and make is far more versatile. In short: For all the tasks
a development environment consists of you'll need make anyway.
So then you might as well use it for building too.

Jacob wrote:
> I am doing a research project on development environments
> using the Unix philosophy of development (see for instance
> http://www.faqs.org/docs/artu/ch01s06.html) with the hypothesis
> that an environment of small, simple, exchangable tools
> might outperform the use of heavyweight IDEs.

If done right, and if given to the right people, yes.

> Tools scripting: Python - Simple, well suited, state of the art, free.

State of the art is not an argument. Particular not in your scenario.
Because, IDEs are officially the "state of the art", but you have
explicitly set out to do it differently, because state of the art is not
what you want.

Admit it, you want Python, because you know Python.

I would consider more of the classic Unix tools. The whole bunch of awk,
sed, m4, etc. If that isn't to your (or your user's) liking, Perl.

> Code documentation: Doxygen - Feature-rich, high quality documents, good
> error reporting.

Ok, Doxygen is more powerful than e.g. JavaDoc, but JavaDoc is the
standard tool, comes with the JDK, and is simply the thing most Java
programmers use. Doxygen is largely compatible with JavaDoc (Doxygen
treats JavaDoc markup as a subset of its markup syntax). So if it later
turns out that JavaDoc is really not up to the task, you can still
change to Doxygen later.

> Editor: Whatever the developer prefers - Efficient, developer
> satisfaction.

Still, for the novices, provide a "standard" one for your environment,
and provide the necessary integration (check out, check in from the
editor, start of the build system, on-error got-to, etc.).

> Unit testing: JUnit - State or the art.

Again, I would not use the term "state of the art" Regarding
testing, see also my remarks for the Wiki below.

> Building: Make - Simple, versatile, free.

Good, but not without some problems when it comes to Java. Prepare for
some extra work. The big problem is dependency declarations. java source
code often has circular dependencies, but make doesn't like if you
declare circular dependencies. You have to group your source code into
clusters, where each cluster has internal dependencies, but the clusters
form a DAG. Or you rely on javac's feature to find and compile
dependencies by itself (up to a certain limit), if set up right.

> Document collaboration: twiki - Simple, free.

Hmm, do you mean "project collaboration", or how do you want to link
that to Doxygen/JavaDoc documentation?

If you want to link testing and a wiki, maybe FitNess is for you
http://fitnesse.org/

> I do miss tools for code metrics, debugging,

http://www.lambdacs.com/debugger/debugger.html

Last time I looked at it very interesting debugging concept, but not
complete. Probably complete now.

> I do miss tools for code metrics, debugging, profiling, and
> project management (hours, calendar, resources, time estimates
> etc) among others. Also, no particluar project process (like RUP)
> w/tools, has been chosen. Suggestions and experience appreciated.

The usefulness of a particular project management tools depends very
much on the management process you apply. Maybe dotProject (written in
PHP for a LAMP environment, not in some .NET stuff) is useful for you:
http://www.dotproject.net

> PS: Excuse me for being slightly off topic.

IMHO you are very much on topic.

/Thomas
--
The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/...g/java/gui/faq
http://www.uni-giessen.de/faq/archiv....java.gui.faq/

On Thu, 09 Feb 2006 08:19:20 +0100, Jacob <> wrote,
quoted or indirectly quoted someone who said :

>I am developing on 1.5 and rely on a robust compiler, and at the moment
>I am actually using javac. I used to use jikes, and thought it were
>finally up to speed on 1.5. If that's not the case I'll stick with
>javac.

the key for speed with JavaC is to use Ant so it loads once and
recompiles the universe.

For debugging there is the compiler internal to Eclipse which is
blinding fast.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Jacob wrote:

> I am doing a research project on development environments
> using the Unix philosophy of development (see for instance
> http://www.faqs.org/docs/artu/ch01s06.html) with the hypothesis
> that an environment of small, simple, exchangable tools
> might outperform the use of heavyweight IDEs.
[...]
> I do miss tools for [...]

One important thing that strikes me as missing from your list of tools (and
also from your list of programmer activities), is anything which will aid code
browsing. Something that can answer questions like, "where is this class
referred to?", "what overrides are there of this method?", "where is this
method called?", "what code uses this constant?", "which classes implement this
interface", etc. Answering such questions (with or without tool support) is a
major part of programming; it's central to code /reading/ and comprehension,
so if you don't have support then it'll skew your results.

Unfortunately, the only browsing tools I know of for Java are the rather clunky
search features built into some IDEs. I know of nothing that will work as a
standalone tool or will integrate into an editor ("which editor?" one asks .
That doesn't mean there aren't any, though. Maybe someone can suggest
something.

-- chris

On Thu, 9 Feb 2006 12:32:56 -0000, "Chris Uppal"
<> wrote, quoted or indirectly
quoted someone who said :

>Unfortunately, the only browsing tools I know of for Java are the rather clunky
>search features built into some IDEs. I know of nothing that will work as a
>standalone tool or will integrate into an editor ("which editor?" one asks .
>That doesn't mean there aren't any, though. Maybe someone can suggest
>something.

I have see two such tools, Juliet and JGuru

Both left me wanting to rewrite them, extending the basic idea.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Chris Uppal wrote:
> Unfortunately, the only browsing tools I know of for Java are the rather clunky
> search features built into some IDEs. I know of nothing that will work as a
> standalone tool or will integrate into an editor ("which editor?" one asks .
> That doesn't mean there aren't any, though. Maybe someone can suggest
> something.

There is ctags and it integrates e.g. into TextPad. It can be used to jump to
methods and classes. I'm not really familiar with ctags, but I assume its output
could also be used for the other "queries"

Thomas

On Thu, 09 Feb 2006 12:32:56 +0000, Chris Uppal wrote:

>
> Unfortunately, the only browsing tools I know of for Java are the rather clunky
> search features built into some IDEs. I know of nothing that will work as a
> standalone tool or will integrate into an editor ("which editor?" one asks .
> That doesn't mean there aren't any, though. Maybe someone can suggest
> something.

http://sourcenav.sourceforge.net/
I find Source Navigator very useful. I use it for code browsing only, but
technically it is an IDE, so that may disqualify it for your purposes
The UI is probably not too intuitive by today's standards, it takes some
time to learn it, but it is fast and effective. It is included in some
Linux distributions and available for windows.

Imre