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

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

Dependency resolution in Java builds

Back to article view | Back to comp.lang.java.programmer

Contents

  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
    Re: Dependency resolution in Java builds Tom Anderson <twic@urchin.earth.li> - 2011-02-09 23:26 +0000
    Re: Dependency resolution in Java builds markspace <nospam@nowhere.com> - 2011-02-08 18:10 -0800

#25653 — Dependency resolution in Java builds

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

[toc] | [next] | [standalone]

#25852

On Feb 8, 11:18 pm, Markus Gessner <nos...@nospam.com> wrote:
> Hello markspace!
>
> On Tue, 08 Feb 2011 18:10:12 -0800, markspace wrote:
> > I have it a quick test here, and it worked fine for me.  ant detected
> > that the subclass file needed to be recompiled.  Javac told me the
> > subclass did not implement the interface, and everything stopped
> > there.
>
> Thank you for your input and the work done for it! This sounds
> encouraging, although it seems to contradict the experiences given by
> the other posters.

Ant's dependency analysis will handle a lot more cases than javac, but
it will still miss a large and important set of incremental changes.
Do not trust it.

[toc] | [prev] | [next] | [standalone]

#25857

On 09-02-2011 08:11, Lew wrote:
> Markus Gessner wrote:
>> It is a host of pom.xml-files, so this would not be feasible, but I
>> greatly appreciate your kind offer!
>
> The highly-touted features of Maven, namely the auto-resolution of
> dependencies across the Internet, are confusing enough.

You can set it up to use your own repository.

>                                                        Add the pom.xml
> spaghetti perpetrated by the same numb-nuts who write spaghetti code and
> your situation gets pathetic indeed.
>
> I'm on a project now with Maven builds that we inherited from such
> incompetents.

It is my impression that Maven is a 90% tool. It make life easier for
the 90% easiest cases - cases where it is possible to have
the project follow the Maven philosophy. For the remaining
10% the same features that make it easier for the normal cases
make it real hard. So if the project is tricky, then you
are probably better of with Ant that is intended as
a custom build script tool.

Arne

[toc] | [prev] | [next] | [standalone]

#25872

Tom Anderson <twic@urchin.earth.li> writes:

> On Tue, 8 Feb 2011, Markus Gessner wrote:
>
>> Moreover, from the Java guys i frequently here something like "when
>> in doubt, clean the project and rebuild".
>
> A process which, for most people, is pretty fast - seconds to
> minutes. Much faster than in C, certainly. I suspect that the speed of
> clean builds has meant that there isn't much demand for incremental
> ones, and hence we don't have any ability to do them.

On the project I work on, every build is followed by a set of automated
tests (first unit, then integration).  Compiling takes a few minutes,
and running the tests normally takes about an hour.  So we do a clean
build every time.

When I'm working at my desk, I just save and Eclipse handles the rest,
usually in less than a second.

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

#25884

Hello markspace!

On Tue, 08 Feb 2011 18:10:12 -0800, markspace wrote:

> I have it a quick test here, and it worked fine for me.  ant detected
> that the subclass file needed to be recompiled.  Javac told me the
> subclass did not implement the interface, and everything stopped
> there.

Thank you for your input and the work done for it! This sounds
encouraging, although it seems to contradict the experiences given by
the other posters.

> Maybe something with your build.xml file?  Perhaps if you showed us
> exactly what was happening, we could help you.

It is a host of pom.xml-files, so this would not be feasible, but I
greatly appreciate your kind offer!

My question was aimed at getting an overall appreciation of the
situation and the feasibility of looking for solutions.

Cheers
Markus

[toc] | [prev] | [next] | [standalone]

#25922

Joshua Maurice wrote:
> I've been experiencing Maven hell for a couple years now. I think
> we're over 1000 poms in a build which developers are expected to do
> before each checkin. The automated build machine does that 1000 pom
> build daily (or more) as well. Maven is the main driver of the build.
> The build includes Java, C++, various in-house code generators, /and/
> some Eclipse plugin build stuff which is cobbled together with some
> rather poor scripts. Feel my pain.

That would be much easier if your project were organized into independent 
libraries with some smaller portion dependent thereupon.  I'm sure you know 
that, and it's likely impossible with such a large fubared code base, but 
others reading this might take a lesson.

-- 
Lew
Ceci n'est pas une fenêtre.
.___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

[toc] | [prev] | [next] | [standalone]

#25939

On Feb 9, 3:43 pm, Lew <no...@lewscanon.com> wrote:
> Joshua Maurice wrote:
> > I've been experiencing Maven hell for a couple years now. I think
> > we're over 1000 poms in a build which developers are expected to do
> > before each checkin. The automated build machine does that 1000 pom
> > build daily (or more) as well. Maven is the main driver of the build.
> > The build includes Java, C++, various in-house code generators, /and/
> > some Eclipse plugin build stuff which is cobbled together with some
> > rather poor scripts. Feel my pain.
>
> That would be much easier if your project were organized into independent
> libraries with some smaller portion dependent thereupon.  I'm sure you know
> that, and it's likely impossible with such a large fubared code base, but
> others reading this might take a lesson.

Correct on every count.

They're still going to try to un-fubar it by componentizing it. Guess
I'll see how that goes.

[toc] | [prev] | [next] | [standalone]

#25973

Markus Gessner wrote:
> It is a host of pom.xml-files, so this would not be feasible, but I
> greatly appreciate your kind offer!

The highly-touted features of Maven, namely the auto-resolution of 
dependencies across the Internet, are confusing enough.  Add the pom.xml 
spaghetti perpetrated by the same numb-nuts who write spaghetti code and your 
situation gets pathetic indeed.

I'm on a project now with Maven builds that we inherited from such 
incompetents.  I've been part of an effort that's so far taken eight months to 
resolve the build issues.  It's a combination of bad project organization and 
Maven abuse (with a liberal dose of framework [Spring, et al.] abuse).  The 
trouble is you change something in one module (with its own pom.xml) and it 
breaks something in another related module.  And that one only had ten 
pom.xmls at its peak, down to seven thanks to our efforts.

Best of luck.

-- 
Lew
Ceci n'est pas une fenêtre.
.___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

[toc] | [prev] | [next] | [standalone]

#26012

On Feb 9, 5:11 am, Lew <no...@lewscanon.com> wrote:
> Markus Gessner wrote:
> > It is a host of pom.xml-files, so this would not be feasible, but I
> > greatly appreciate your kind offer!
>
> The highly-touted features of Maven, namely the auto-resolution of
> dependencies across the Internet, are confusing enough.  Add the pom.xml
> spaghetti perpetrated by the same numb-nuts who write spaghetti code and your
> situation gets pathetic indeed.
>
> I'm on a project now with Maven builds that we inherited from such
> incompetents.  I've been part of an effort that's so far taken eight months to
> resolve the build issues.  It's a combination of bad project organization and
> Maven abuse (with a liberal dose of framework [Spring, et al.] abuse).  The
> trouble is you change something in one module (with its own pom.xml) and it
> breaks something in another related module.  And that one only had ten
> pom.xmls at its peak, down to seven thanks to our efforts.

I've been experiencing Maven hell for a couple years now. I think
we're over 1000 poms in a build which developers are expected to do
before each checkin. The automated build machine does that 1000 pom
build daily (or more) as well. Maven is the main driver of the build.
The build includes Java, C++, various in-house code generators, /and/
some Eclipse plugin build stuff which is cobbled together with some
rather poor scripts. Feel my pain.

[toc] | [prev] | [next] | [standalone]

#25998

"Tom Anderson" <twic@urchin.earth.li> wrote in message 
news:alpine.DEB.1.10.1102092321530.18846@urchin.earth.li...
> On Tue, 8 Feb 2011, Markus Gessner wrote:
>
>> Moreover, from the Java guys i frequently here something like "when in 
>> doubt, clean the project and rebuild".
>
> A process which, for most people, is pretty fast - seconds to minutes. 
> Much faster than in C, certainly. I suspect that the speed of clean builds 
> has meant that there isn't much demand for incremental ones, and hence we 
> don't have any ability to do them.

I'd guess you're right. 

[toc] | [prev] | [next] | [standalone]

#26057

On 08-02-2011 17:26, Markus Gessner wrote:
> 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++).

The clean and rebuild is the standard solution.

Arne

[toc] | [prev] | [next] | [standalone]

#26216

On Tue, 8 Feb 2011, Markus Gessner wrote:

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

A process which, for most people, is pretty fast - seconds to minutes. 
Much faster than in C, certainly. I suspect that the speed of clean builds 
has meant that there isn't much demand for incremental ones, and hence we 
don't have any ability to do them.

tom

-- 
... but when you spin it it looks like a dancing foetus!

[toc] | [prev] | [next] | [standalone]

#26218

On 2/8/2011 2:26 PM, Markus Gessner wrote:

> 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.


I have it a quick test here, and it worked fine for me.  ant detected 
that the subclass file needed to be recompiled.  Javac told me the 
subclass did not implement the interface, and everything stopped there.

Maybe something with your build.xml file?  Perhaps if you showed us 
exactly what was happening, we could help you.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web