Re: Speed Up Compilation -article request
On Sun, 15 Aug 2010, Lew wrote:
schreef RedGrittyBrick:
If you can't use an IDE, then running Ant or Make etc from inside your
editor has to be the next best thing.
For certain values of "the next best". For delivery and deployment it's one
of the worst things because it potentially locks you in to a particular
version of a particular IDE.
To a particular IDE, yes. To a particular version? I've been looking at
Eclipse metadata files since 3.3, and they haven't changed much. More
specifically, the .project and .classpath haven't changed at all, as far
as i can tell (caveat: we have quite simple projects, just java projects
with the java builder). Some of the more mysterious files in the workspace
global directories (eg variablesAndContainers.dat) have, but not hugely,
and you don't share those anyway, so it's largely irrelevant.
I think there's a NetBeans plugin that lets it read Eclipse .project and
..classpath files, but i don't know how up to date it is, and i wouldn't
want to rely on it. It would be really nice if IDE vendors could
standardise on metadata files, to avoid this lockin problem, and also
enable all sorts of new tools, but i realise that's a pipe dream.
I can't comment on the stability of other IDEs' metadata files.
An Ant build forces you to have all the dependencies for the project at
hand and does not introduce additional dependencies.
Doing your build with ant introduces ant as a dependency, and nothing
else. Doing your build with Eclipse introduces Eclipse as a dependency,
and nothing else. I don't see the difference.
It consolidates the build and path information into one or a small
number of build descriptor files, not scattered among various ".project"
or ".settings" files with auto-shifting content.
I don't see this as an advantage, but rather, as a significant
disadvantage. The build information is better off stored in multiple small
files, one per module, than consolidated in one big file. This is the case
regardless of IDE, build system, etc.
Project after project where I've worked has had build and deployment
issues that arise from the seductive apparent convenience of sharing
IDE-specific metadata. These issues have included test suites that work
differently in the test environment from the developers', long hours of
manual labor translating IDE-specific project dependencies into
deployment-time build scripts, conflicting JARs, broken builds (ones
that don't compile), and huge time investment to upgrade a project to a
newer IDE version.
I'm sorry to hear that. Projects i've worked on have used IDE-specific
build processes, and that hasn't caused any pain. Indeed, we've *reduced*
the amount of pain we feel by using more of it. For instance, at one
point, we maintained Eclipse-independent classpath metadata, so we could
run code from the command line as part of the build. This was painful. We
then wrote some code to parse Eclipse's files to extract the information
automatically. This made things a lot easier and more reliable, because we
let Eclipse do the heavy lifting of keeping that data correct.
I'd be interested to hear more about the instances you mention. Why were
the development and test test suites different? Why did you have to
translate the IDE build into another form (which i can see you might need)
by hand? How would you have avoided having conflicting JARs by not sharing
IDE metadata? How was an IDE responsible for a broken build? What did you
have to do when upgrading your IDE?
IDE-specific project files should be eliminated from the project's build
protocols with extreme prejudice.
Duplication should be eliminated from the project's build protocols with
extreme prejudice. You're using an IDE, so maintaining an IDE-independent
build process is duplication.
tom
--
One horse laugh is worth a thousand syllogisms. -- H. L. Mencken