Lew wrote:
>> 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.
Tom Anderson wrote:
> To a particular IDE, yes. To a particular version? I've been looking at
Yep. Upgrading from Rational Application Developer (Eclipse based, BTW) from
version 6 to version 7 for a team was a nightmare of metadata-file editing on
a large team a few years ago.
> Eclipse metadata files since 3.3, and they haven't changed much. More
It doesn't take "much" if the "not much" is involved in your particular case.
> specifically, the .project and .classpath haven't changed at all, as far
> as i can tell (caveat: we have quite simple projects, just java [sic] projects
> with the java [sic] 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.
"You don't share those anyway" - making my point that IDE-specific files can
be very bad to share.
> 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.
Nice but unnecessary. Just have the metadata files be irrelevant. Besides,
even standardizing on the format doesn't solve the problem - these files
contain hard-coded path information and the like that is specific to each
developer, not just the project or the brand of IDE.
Lew:
>> An Ant build forces you to have all the dependencies for the project
>> at hand and does not introduce additional dependencies.
tom:
> 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.
Eclipse (or whatever) adds a lot more complexity in its dependency. Ant does
not introduce under-the-hood changes to your metadata files automagically.
Eclipse does. Ant does not require multiple entries for dependencies into
multiple configuration files. Eclipse does. Ant doesn't assume the presence
of an entire infrastructure of JARs (org.eclipse.blahdiblah.packagestuff.jar).
Eclipse does. Ant is invoked from the command line and is independent of
the IDE used to build them. Eclipse is not. Ant dependencies are limited
pretty much to "use the tool". Eclipse dependencies are pernicious and
pervasive. Ant is upwardly compatible. Eclipse is not. Ant is
user-extensible with simplicity. Eclipse is not. Ant is geared specifically
to deployment. Eclipse is geared to construction and is more general. Ant is
the standard build tool. Eclipse is not.
The differences are myriad.
Lew:
>> 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.
tom:
> 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.
All right. Use multiple build files then. Advantage: Ant. Regardless of
IDE, project structure, etc.
> ... 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.
Except that you still have things like class paths specified in up to four
places per project with Eclipse - "build path", "project dependencies", "EAR
dependencies" and "aspects". There may be others. Eclipse, like Ant, doesn't
do the heavy lifting; it captures the decisions made by humans.
> 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
God knows. For some reason instead of using the JUnit test framework they
invoked test code via 'main()'. I didn't create the process. Excuse me, the
"process".
> 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
Because we didn't have custom tools to translate the IDE files into Ant files.
> sharing IDE metadata? How was an IDE responsible for a broken build?
> What did you have to do when upgrading your IDE?
I forget the details, but it involved replacing lines in certain configuration
files to reflect new features in the newer IDE version.
Since IDE metadata was formed project by project by different developers in
isolation from each other, often they each would choose JAR versions
independently and thus occasionally conflictingly. With a centralized build
process those conflicts are noticed earlier in the process, and listed in the
build.xml file(s) where they're far more visible. Emergently this gives Ant
an edge for conflict resolution.
Lew:
>> IDE-specific project files should be eliminated from the project's
>> build protocols with extreme prejudice.
tom:
> 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.
Is it your argument that having more than one developer is duplication, since
each have a separate working copy of the project?
Since I don't favor an IDE-based build process, an IDE-independent build
process would have nothing to duplicate, so therefore it is not duplication.
--
Lew