Re: dependency-detection in java - Take 2



Michael Jung <miju@xxxxxxxxxxxxx> wrote:
This isn't only about SFFs, but also about classes changing
their interface incompatibly (could be a typo of the developer,
but without compiling the dependents, it may go unnoticed for
a while!)

SFFs should only be used locally,

I'm dreaming of reliable, non-full rebuilds. They shouldn't
depend on developers following guidelines (which all have their
"accepted exceptions", anyway), and shouldn't even depend on
developers contributing correct code (but detect all errors,
even those caused only in dependent classes.)

I'm viewing this problem from a CM point of view (although I'm
rather developer than CM). Any change that gets into the repository
might have been checked in by a monkey, as well as by a senior expert.
The build process shouldn't care. It should in the end say: "yes, the
project has been built", or "it could not be built due to these errors,
and furthermore the build process should do this with minimal use of
processor-ressources (on whatever machine it is applied, be it
developer's workstation, or a dedicated compile-server).

I'm aware, that such a build-tool-chain is either not existing now,
or at least not known to anyone participating in this thread.

I'd like to discuss how this could be done. First, what is
principially possible to do - where are the theoretic limits?
Would dependency-management be necessarily more expensive than
the unconditional full compile?

Even if you get ant or some other semantic analyser to solve that problem for
you, you may still be stuck with the runtime problem, when someone in a
distributed environment compiled against an old constant.

The goal of this discussion is a build-process (but not the full one!),
which yields the same result regardless which of the java files were most
recently changed. So, in the end (almost) every developer would use
that build-process (just like almost everyone already uses ant now), and
given that they've checked out the same version, the'd get the same
jar-file (except for files' meta-information like timestamp)

.



Relevant Pages

  • Re: Multiple developers, single solution
    ... We've got VSS that we plan to use. ... can't both be compiling whenever we need to because the other developer will ... > You want to use a version control tool - VSS, CVS, etc. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: MDE? Need to destribute db to users who dont have Access
    ... You need to distribute the Access run-time, which is included with Office XP ... >I have Office XP Developer. ... >regard to compiling a distributable db app for users who ... Is it an "MDE"? ...
    (microsoft.public.access.forms)
  • Re: MDE? Need to destribute db to users who dont have Access
    ... You need to distribute the Access run-time, which is included with Office XP ... >I have Office XP Developer. ... >regard to compiling a distributable db app for users who ... Is it an "MDE"? ...
    (microsoft.public.access.security)
  • Re: MDE? Need to destribute db to users who dont have Access
    ... You need to distribute the Access run-time, which is included with Office XP ... >I have Office XP Developer. ... >regard to compiling a distributable db app for users who ... Is it an "MDE"? ...
    (microsoft.public.access.queries)
  • Re: MDE? Need to destribute db to users who dont have Access
    ... You need to distribute the Access run-time, which is included with Office XP ... >I have Office XP Developer. ... >regard to compiling a distributable db app for users who ... Is it an "MDE"? ...
    (microsoft.public.access.modulesdaovba)