Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #25653

Dependency resolution in Java builds

Path csiph.com!eeepc.pasdenom.info!news.pasdenom.info!news.dougwise.org!nntpfeed.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
From Markus Gessner <nospam@nospam.com>
Newsgroups comp.lang.java.programmer
Subject Dependency resolution in Java builds
Date Tue, 08 Feb 2011 23:26:22 +0100
Message-ID <87oc6mi2nl.fsf@web.de> (permalink)
User-Agent Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
Cancel-Lock sha1:FEN2LfDBp54ey15sZegmPfu7n+w=
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Lines 55
Organization Arcor
NNTP-Posting-Date 08 Feb 2011 23:26:03 CET
NNTP-Posting-Host 2ec2cbd0.newsspool2.arcor-online.net
X-Trace DXC=4B^keiBcggk[F<50eo:0knA9EHlD;3Ycb4Fo<]lROoRa8kF<OcfhCOkKT2bh9G8HhhNV846hVml5hQ>B4BFjnACcZ@iRR=KndGfhe6d2;dIafn
X-Complaints-To usenet-abuse@arcor.de
Xref csiph.com comp.lang.java.programmer:25653

Show key headers only | View raw


Hello all!

Having recently started working with Java, coming from C++, I am now
taking part in a Java project, the build of which is managed by Maven.

I frequently run into a very basic situation exemplified by the two
follwing classes, each of which is implemented in its own file:

----------------------------------------------------------------------
public interface Foo
{
  void method1();
}

public class FooImpl implements Foo
{
  void method1() { ; }
}
----------------------------------------------------------------------

After compiling, I make the follwing change, i.e., only change the
interface:

----------------------------------------------------------------------
public interface Foo
{
  void method1();
  void method2();
}

public class FooImpl implements Foo
{
  void method1() { ; }
}
----------------------------------------------------------------------

When building, I see only a recompilation of Foo.java, which
indicates, that only a simple comparison of the respective timestamps
of *.java and *.class files is undertaken. From my C++-work, based on
gcc/make, I am accustomed to a setup, which in the analogous scenario
for C++ detects the dependence of FooImpl on Foo and initiates a
recompilation of FooImpl as well (in this example leading to a compile
time error).

Moreover, from the Java guys i frequently here something like "when in
doubt, clean the project and rebuild".

Although this is a matter of the build tools rather than the language, I
would like to ask the experienced Java developers out here: is this to
be put up with, or are there build mechanisms obviating this, concisely
taking into account the interdependence of classes (like "gcc -M" in a
make-based build system for C++).

Greetings
Markus

Back to comp.lang.java.programmer | Previous | NextNext in thread | Find similar


Thread

Dependency resolution in Java builds Markus Gessner <nospam@nospam.com> - 2011-02-08 23:26 +0100
  Re: Dependency resolution in Java builds Joshua Maurice <joshuamaurice@gmail.com> - 2011-02-09 14:52 -0800
  Re: Dependency resolution in Java builds Arne Vajhøj <arne@vajhoej.dk> - 2011-02-09 19:39 -0500
  Re: Dependency resolution in Java builds Jim Janney <jjanney@shell.xmission.com> - 2011-02-10 14:59 -0700
  Re: Dependency resolution in Java builds Markus Gessner <nospam@nospam.com> - 2011-02-09 08:18 +0100
    Re: Dependency resolution in Java builds Lew <noone@lewscanon.com> - 2011-02-09 18:43 -0500
      Re: Dependency resolution in Java builds Joshua Maurice <joshuamaurice@gmail.com> - 2011-02-09 15:50 -0800
    Re: Dependency resolution in Java builds Lew <noone@lewscanon.com> - 2011-02-09 08:11 -0500
      Re: Dependency resolution in Java builds Joshua Maurice <joshuamaurice@gmail.com> - 2011-02-09 15:03 -0800
  Re: Dependency resolution in Java builds "Mike Schilling" <mscottschilling@hotmail.com> - 2011-02-09 20:51 -0800
  Re: Dependency resolution in Java builds Arne Vajhøj <arne@vajhoej.dk> - 2011-02-08 21:03 -0500

csiph-web