Dependency resolution in Java builds

  • Permalink
  • submit to reddit
  • Email
  • Follow


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
0
Reply Markus 2/8/2011 10:26:22 PM

See related articles to this posting


On Feb 8, 2:26=A0pm, Markus Gessner <nos...@nospam.com> wrote:
> 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
> {
> =A0 void method1();
>
> }
>
> public class FooImpl implements Foo
> {
> =A0 void method1() { ; }}
>
> ----------------------------------------------------------------------
>
> After compiling, I make the follwing change, i.e., only change the
> interface:
>
> ----------------------------------------------------------------------
> public interface Foo
> {
> =A0 void method1();
> =A0 void method2();
>
> }
>
> public class FooImpl implements Foo
> {
> =A0 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++).

I've been looking for the same thing.

In short, all commonly available build systems suck. It's just a
difference of degree. That includes the idiomatic solution of
"Recursive Make Considered Harmful" with gnu make and gcc -M on c++
code. Ex: Try removing a cpp file, and see if your link output gets
rebuilt. See what happens when you add a new header file which hides
another header file on an include search path.

So, the modern commonly available Java build systems handle even less
of these dependencies than the common "Recursive Make Considered
Harmful" handles. I've been working on my actually incrementally
correct build system on the side which does /correct/ incremental
Java, but don't expect anything soon. (It also relies on Sun JVM's
compiler interface, which isn't Java standard but Sun standard, so
don't expect it to work on other platforms which don't have the Sun
JVM. However, the output bytecode is portable and can run
everywhere.)

I think you'll just have to make do with full clean builds. That's
also the advice I've heard from basically all Java people to whom I've
talked on this subject.

Builds is one of the most under-appreciated aspects of programming.
0
Reply Joshua 2/9/2011 1:28:50 AM

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
0
Reply ISO 2/9/2011 2:03:03 AM

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.

0
Reply markspace 2/9/2011 2:10:12 AM

Joshua Maurice wrote:
> Builds is one of the most under-appreciated aspects of programming.

Second to deployment, which is subordinate to operations, which subsumes the 
aforementioned.

Generally, programmers as a class are woefully ignorant of 
build/deployment/ops matters.  I've seen this repeatedly in 
multi-million-dollar projects.  One such had radically different builds on 
developer machines from those on test/production machines.  You could pass all 
unit tests on the developer machine and fail on the test box, for example.

Another symptom is framework plethora.  Let's just throw our 
RichFaces/Acegi/Echo2/Spring/Spring-JDBC/Spring-Aspect/Spring-OMG!/ all over 
our XHTML over various disparate JMS scaffolds between localhost processes. 
No, that's not a rant, that's a prototypic description of more than one 
real-world scenario, both large and small projects.  The exact frameworks in 
question vary (I mentioned ones I've encountered in various combination) but 
the arity is similar.  I forbore to mention the classloader and library 
incompatibilities between JARS loaded by unchecked programmers and versions 
provided by the application server.

On a recent project I had the opportunity to get elbow-deep into Maven builds, 
Hudson continuous integration and deployments to a Java EE server.  Boy howdy!

On a less recent project, I worked for about six months with the ops guys, in 
a town I'll call Deploymentville. Their opinion of the project's programming 
team, about twenty miles up the highway in Programmerton?  "We like to get 
those Programmerton guys over here for about six months," one ops guru told 
me, grinning wickedly.  "They go back ... /changed/."

-- 
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|
0
Reply Lew 2/9/2011 3:14:02 AM

Hello!

First of all, please excuse my typos of yesterday, it was a bit late
here in Europe.

On Tue, 8 Feb 2011 17:28:50 -0800 (PST), Joshua Maurice wrote:

> In short, all commonly available build systems suck. It's just a
> difference of degree. That includes the idiomatic solution of
> "Recursive Make Considered Harmful" with gnu make and gcc -M on c++
> code. Ex: Try removing a cpp file, and see if your link output gets
> rebuilt. See what happens when you add a new header file which hides
> another header file on an include search path.

This may happen, but in my everyday work I never came across such
situations. We even had a medley of metacompilers (moc, proc ...), and
the handling of the additional dependencies introduced by them also
always worked. You only had to explicitly add source files to some
*.pro-files, the makefiles were generated from, but that I happily
submitted to, everything else just working.

To sum it up -- this setup, devised a lot of years ago and never
changed, just worked, I almost never noticed it, which unobtrusiveness
IMHO is the best one can say about a tool. It was just "issue a command
and sit back".

> So, the modern commonly available Java build systems handle even less
> of these dependencies than the common "Recursive Make Considered
> Harmful" handles. I've been working on my actually incrementally
> correct build system on the side which does /correct/ incremental
> Java, but don't expect anything soon. (It also relies on Sun JVM's
> compiler interface, which isn't Java standard but Sun standard, so
> don't expect it to work on other platforms which don't have the Sun
> JVM. However, the output bytecode is portable and can run everywhere.)

This is a very laudable undertaking, but the fact of its necessity says
a lot about the common regard of this complex, as you note further
below.

> I think you'll just have to make do with full clean builds. That's
> also the advice I've heard from basically all Java people to whom I've
> talked on this subject.

At least now I won't do too much digging, although in this thread
markspace wrote about a different experience, which he made with Ant
(not Maven, I am stuck with, alas).

> Builds is one of the most under-appreciated aspects of programming.

Having just begun working with Java, I of course cannot really
appreciate its merits, but it seems, that it would be impossible to
implement the needs of a lot of business oriented applications without
its standards (Java EE), and some frameworks do have a certain charme
(e.g., JAXB and Hibernate). Nevertheless, the build environment I
experience gives me the overall impression of a car, nicely fitted with
teak panels, a GPS system and a minibar, but which has to be cranked
every mile or so. Says a somewhat frustrated mind, who prefers the
tramway :-)

Markus
0
Reply Markus 2/9/2011 7:06:54 AM

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
0
Reply Markus 2/9/2011 7:18:19 AM

Markus Gessner wrote:
> Having just begun working with Java, I of course cannot really
> appreciate its merits, but it seems, that it would be impossible to
> implement the needs of a lot of business oriented applications without
> its standards (Java EE), and some frameworks do have a certain charme
> (e.g., JAXB and Hibernate). Nevertheless, the build environment I
> experience gives me the overall impression of a car, nicely fitted with
> teak panels, a GPS system and a minibar, but which has to be cranked
> every mile or so. Says a somewhat frustrated mind, who prefers the
> tramway :-)

OH, come on!  Really?

I've worked on some hairy large projects and smaller ones, too.  The time to 
build an application as affected by this issue is never a factor, unless you 
have improperly factored the dependencies, and that would be a problem in any 
language.

Java's dependencies, at least when using Ant (I agree Maven is a bitch), are 
usually resolvable for incremental builds without issue.  When they aren't, 
it's because of the unique features of Java (it compiles taking 
already-compiled libraries into account, sort of combining compilation and 
linking if you're thinking C[++]-ishly).  In those situations, you do a clean 
build and wait an extra minute.  Big effing deal!

If your clean builds take hours, that's not Java's fault, that's yours.

-- 
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|
0
Reply Lew 2/9/2011 1:02:26 PM

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|
|_____|_____|
|===========|
0
Reply Lew 2/9/2011 1:11:33 PM

On Feb 8, 11:18=A0pm, 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. =A0ant detected
> > that the subclass file needed to be recompiled. =A0Javac 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.
0
Reply Joshua 2/9/2011 10:52:35 PM

On Feb 8, 11:06=A0pm, Markus Gessner <nos...@nospam.com> wrote:
> Hello!
>
> First of all, please excuse my typos of yesterday, it was a bit late
> here in Europe.
>
> On Tue, 8 Feb 2011 17:28:50 -0800 (PST), Joshua Maurice wrote:
> > In short, all commonly available build systems suck. It's just a
> > difference of degree. That includes the idiomatic solution of
> > "Recursive Make Considered Harmful" with gnu make and gcc -M on c++
> > code. Ex: Try removing a cpp file, and see if your link output gets
> > rebuilt. See what happens when you add a new header file which hides
> > another header file on an include search path.
>
> This may happen, but in my everyday work I never came across such
> situations. We even had a medley of metacompilers (moc, proc ...), and
> the handling of the additional dependencies introduced by them also
> always worked. You only had to explicitly add source files to some
> *.pro-files, the makefiles were generated from, but that I happily
> submitted to, everything else just working.
>
> To sum it up -- this setup, devised a lot of years ago and never
> changed, just worked, I almost never noticed it, which unobtrusiveness
> IMHO is the best one can say about a tool. It was just "issue a command
> and sit back".

I think I'll stick with what I said - it's just a difference of
degree. Once in a blue moon, you could have a new header file which
hides another header file on an include search path, and an
incremental build will produce different results than a full clean
build. Also, as I said, (or perhaps meant to say?), the solution
advocated in "Recursive Make Considered Harmful" is still one of the
best solutions publicly available for C and C++.

Moreover, many of the ideas and concepts presented in that paper are
invaluable. It's what kicked off my quest to become a build expert.

I merely feel that the paper doesn't go far enough. I want a build
system so that, given the correctness of the build system executable,
it is impossible to make source code deltas /or build code/ deltas so
that the incremental build will produce different results than a full
clean rebuild. That, I think, is the critical difference between what
I want and all commonly available build systems. A pom.xml, a
makefile, an ant file, etc., are all executable code, written in an
interpreted domain specific language. I want a build language where
it's impossible to code the wrong thing. As this language is
restricted entirely to builds, I think that such a thing is quite
feasible and practicable. I'm working on it on and off in my spare
time.
0
Reply Joshua 2/9/2011 10:59:48 PM

On Feb 9, 5:11=A0am, 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. =A0Add the pom.xm=
l
> 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. =A0I've been part of an effort that's so far taken eight mo=
nths to
> resolve the build issues. =A0It's a combination of bad project organizati=
on and
> Maven abuse (with a liberal dose of framework [Spring, et al.] abuse). =
=A0The
> trouble is you change something in one module (with its own pom.xml) and =
it
> breaks something in another related module. =A0And 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.
0
Reply Joshua 2/9/2011 11:03:16 PM

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!
0
Reply Tom 2/9/2011 11:26:23 PM

On Tue, 8 Feb 2011, Joshua Maurice wrote:

> Builds is one of the most under-appreciated aspects of programming.

I'll drink to that. Indeed, when working on build stuff, i often get the 
urge to do so before lunch.

tom

-- 
.... but when you spin it it looks like a dancing foetus!
0
Reply Tom 2/9/2011 11:28:31 PM

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|
|_____|_____|
|===========|
0
Reply Lew 2/9/2011 11:43:46 PM

On Feb 9, 3:43=A0pm, 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. =A0I'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.
0
Reply Joshua 2/9/2011 11:50:57 PM

On Tue, 8 Feb 2011, Lew wrote:

> Joshua Maurice wrote:
>> Builds is one of the most under-appreciated aspects of programming.
>
> Second to deployment, which is subordinate to operations, which subsumes 
> the aforementioned.
>
> Generally, programmers as a class are woefully ignorant of 
> build/deployment/ops matters.  I've seen this repeatedly in 
> multi-million-dollar projects.  One such had radically different builds 
> on developer machines from those on test/production machines.  You could 
> pass all unit tests on the developer machine and fail on the test box, 
> for example.

It's simply stunning that people let this happen in this day and age.

Even more stunning, we did it on our current project. There are some 
necessary differences between the dev and server builds (exploded vs 
packed EARs, for example), but the differences between the build processes 
for them are far greater than that difference requires. I didn't make the 
decision to make them so different; someone else did a long time ago. But 
that difference has persisted and grown on my watch, so there's blood on 
my hands.

Perhaps all that is required for bad builds to triumph is for good 
programmers to do nothing.

> Another symptom is framework plethora.  Let's just throw our 
> RichFaces/Acegi/Echo2/Spring/Spring-JDBC/Spring-Aspect/Spring-OMG!/ all 
> over our XHTML over various disparate JMS scaffolds between localhost 
> processes. No, that's not a rant, that's a prototypic description of 
> more than one real-world scenario, both large and small projects.  The 
> exact frameworks in question vary (I mentioned ones I've encountered in 
> various combination) but the arity is similar.

Isn't that just a question of shovelling JARs onto the classpath and then 
jarring up the right things? Or do these frameworks have more involved 
build requirements?

> I forbore to mention the classloader and library incompatibilities 
> between JARS loaded by unchecked programmers and versions provided by 
> the application server.

There is that.

> On a less recent project, I worked for about six months with the ops 
> guys, in a town I'll call Deploymentville. Their opinion of the 
> project's programming team, about twenty miles up the highway in 
> Programmerton?  "We like to get those Programmerton guys over here for 
> about six months," one ops guru told me, grinning wickedly.  "They go 
> back ... /changed/."

There is this very nebulous thing called The Devops Movement, which is not 
an antagonist from a James Bond novel, but some sort of theory that people 
with experience of operations should be involved in development:

http://en.wikipedia.org/wiki/DevOps

Seems lke a good idea.

tom

-- 
.... but when you spin it it looks like a dancing foetus!
0
Reply Tom 2/9/2011 11:56:56 PM

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
0
Reply UTF 2/10/2011 12:39:33 AM


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

0
Reply Mike 2/10/2011 4:51:47 AM

Lew wrote:
>> Another symptom is framework plethora. Let's just throw our
>> RichFaces/Acegi/Echo2/Spring/Spring-JDBC/Spring-Aspect/Spring-OMG!/ all over
>> our XHTML over various disparate JMS scaffolds between localhost processes.
>> No, that's not a rant, that's a prototypic description of more than one
>> real-world scenario, both large and small projects. The exact frameworks in
>> question vary (I mentioned ones I've encountered in various combination) but
>> the arity is similar.

Tom Anderson wrote:
> Isn't that just a question of shovelling JARs onto the classpath and then
> jarring up the right things? Or do these frameworks have more involved build
> requirements?

I wish it was that easy.  There are at least two orders of problem.  The first 
is that the frameworks often pull in different versions of the same libraries. 
  The other is that the frameworks interact with each other in, ahem, emergent 
and unexpected ways.  On top of those, sometimes different frameworks have 
overlapping functionality, such as Spring/JDBC and Hibernate, making it 
difficult to implement a coherent strategy for such functionality.

On a recent project with Maven builds, we had a parent build ("foomain") and 
several subsidiary modules ("foofrontend", "foologic", "foopersistence", ...). 
  Historically different versions of the same frameworks were specified for 
the different modules.  Yet when you pulled the dependencies into the 
"foomain" pom.xml in common the build broke.  Turns out some of the 
dependencies transitively depend on the same libraries, but different versions 
also, some of which are transitive dependencies for other stuff, also 
different versions.

I tried "shoveling JARs".  Nope.  It's subtler than that.

-- 
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|
0
Reply Lew 2/10/2011 1:09:05 PM

Lew wrote:
>> The highly-touted features of Maven, namely the auto-resolution of
>> dependencies across the Internet, are confusing enough.

Arne Vajhøj wrote:
> You can set it up to use your own repository.

Of course, then it still reaches across the 'net every time something asks for 
a more (or less) version that's not in the local repository.  Without asking, 
and barely telling.

You don't think we tried that?  Thanks for the awesome advice, though!

Lew wrote:
>> 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.

Arne Vajhøj wrote:
> 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.

Since real-world projects are nearly never simple, I challenge your "90%" 
claim.  I'd be surprised if the number were 10%.  Do you have any evidence for 
that statistic?

The project I'm on isn't even especially complicated, except for the Maven 
builds.  I wish it were based on Ant, but converting back once it's tangled up 
in Maven is not straightforward.  None of us, not even my management (!), is 
happy with Maven.

-- 
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|
0
Reply Lew 2/10/2011 1:16:36 PM

On Thu, 10 Feb 2011 08:09:23 -0500, Lew wrote:

> Lew wrote:
> 
> On a recent project with Maven builds, we had a parent build ("foomain")
> and several subsidiary modules ("foofrontend", "foologic",
> "foopersistence", ...).
>   Historically different versions of the same frameworks were specified
>   for
> the different modules.  Yet when you pulled the dependencies into the
> "foomain" pom.xml in common the build broke.  Turns out some of the
> dependencies transitively depend on the same libraries, but different
> versions also, some of which are transitive dependencies for other
> stuff, also different versions.
> 

So it wasn't really Maven problem but dependency management problem.
From my experience Maven just makes dependency management issues explicit 
and visible. I would argue it is a good thing.

-- 
Michal
0
Reply Michal 2/10/2011 2:17:28 PM

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
0
Reply Jim 2/10/2011 9:59:24 PM

Lew wrote:
>> On a recent project with Maven builds, we had a parent build ("foomain")
>> and several subsidiary modules ("foofrontend", "foologic",
>> "foopersistence", ...).
>>    Historically different versions of the same frameworks were specified
>>    for
>> the different modules.  Yet when you pulled the dependencies into the
>> "foomain" pom.xml in common the build broke.  Turns out some of the
>> dependencies transitively depend on the same libraries, but different
>> versions also, some of which are transitive dependencies for other
>> stuff, also different versions.

Michal Kleczek wrote:
> So it wasn't really Maven problem but dependency management problem.
>  From my experience Maven just makes dependency management issues explicit
> and visible. I would argue it is a good thing.

My experience is that Maven quietly ignores your desire to keep things in the 
local repository and messes up your dependencies.  I would argue that 
invisibly making changes is NOT a good thing.

Part of the problem I described is due to Maven's quiet retrieval of different 
transitive dependencies.  If it had instead crashed the build with a message 
about an unresolved dependency, it would have been better.  That certainly was 
not a good thing, and it's laid right at Maven's feet.

Sometimes even a bad tool can be used effectively, if a person is aware of all 
the kinks and quirks and is willing to take the effort to work around them. 
Such tool's effectiveness under those conditions is not evidence of its goodness.

Maven sucks.

-- 
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|
0
Reply Lew 2/11/2011 12:07:41 AM

On Feb 10, 4:08=A0pm, Lew <no...@lewscanon.com> wrote:
> Lew wrote:
> >> On a recent project with Maven builds, we had a parent build ("foomain=
")
> >> and several subsidiary modules ("foofrontend", "foologic",
> >> "foopersistence", ...).
> >> =A0 =A0Historically different versions of the same frameworks were spe=
cified
> >> =A0 =A0for
> >> the different modules. =A0Yet when you pulled the dependencies into th=
e
> >> "foomain" pom.xml in common the build broke. =A0Turns out some of the
> >> dependencies transitively depend on the same libraries, but different
> >> versions also, some of which are transitive dependencies for other
> >> stuff, also different versions.
> Michal Kleczek wrote:
> > So it wasn't really Maven problem but dependency management problem.
> > =A0From my experience Maven just makes dependency management issues exp=
licit
> > and visible. I would argue it is a good thing.
>
> My experience is that Maven quietly ignores your desire to keep things in=
 the
> local repository and messes up your dependencies. =A0I would argue that
> invisibly making changes is NOT a good thing.
>
> Part of the problem I described is due to Maven's quiet retrieval of diff=
erent
> transitive dependencies. =A0If it had instead crashed the build with a me=
ssage
> about an unresolved dependency, it would have been better. =A0That certai=
nly was
> not a good thing, and it's laid right at Maven's feet.
>
> Sometimes even a bad tool can be used effectively, if a person is aware o=
f all
> the kinks and quirks and is willing to take the effort to work around the=
m.
> Such tool's effectiveness under those conditions is not evidence of its g=
oodness.
>
> Maven sucks.

I've one of the resident build experts in my company for my product
team. I wrote half the stuff in use, including some home grown C++
Maven plugins which are working decently well when compared to the
Maven standard plugins.

One of my first pieces of advice is to do a full online (re)build up
front, then never ever do an online build ever again until your next
full clean rebuild. I've seen so many build failures that happened due
to Maven's curious and silent downloads of artifacts because the
developer accidentally forgot to specify the "-o" flag one time. I
tell them to use canned scripts where each script has "-o" hardcoded
in, but some don't listen.

Maven is a tolerable dependency management system, that is getting
various things online, automatically downloading them, version
mismatch resolution for different transitive dependencies, etc.,
especially for the toy example. However, it is a miserable failure
when it comes to a the /build/ part of a build system.
0
Reply Joshua 2/11/2011 12:37:46 AM

On 10-02-2011 08:16, Lew wrote:
> Arne Vajhøj wrote:
>> 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.
>
> Since real-world projects are nearly never simple, I challenge your
> "90%" claim. I'd be surprised if the number were 10%. Do you have any
> evidence for that statistic?

The 90-10 were not statistical information but magnitude indication.
Like in 10% of the code use 90% of the time, 90% of the project takes
90% of the time and the 10% also takes 90% of the time.

Maven is pretty widely used.

And I know of several projects that are happy using it.

Real world projects can be relative simple in build. I would even
say that they should be relative simple in build. Complex builds
are usually a symptom of a bigger problem in the app.

Of course projects with problems, complex builds and Maven not
working properly is still common.

> The project I'm on isn't even especially complicated, except for the
> Maven builds. I wish it were based on Ant, but converting back once it's
> tangled up in Maven is not straightforward. None of us, not even my
> management (!), is happy with Maven.

Personally I prefer ant over Maven - I like the ability to code
my build. But from a project perspective coding the build
is just extra cost.

Arne

0
Reply UTF 2/11/2011 3:02:24 AM

Arne Vajhøj wrote:
> The 90-10 were not statistical information but magnitude indication.
> Like in 10% of the code use 90% of the time, 90% of the project takes
> 90% of the time and the 10% also takes 90% of the time.
>
> Maven is pretty widely used.
>
> And I know of several projects that are happy using it.
>
> Real world projects can be relative simple in build. I would even
> say that they should be relative simple in build. Complex builds
> are usually a symptom of a bigger problem in the app.
>
> Of course projects with problems, complex builds and Maven not
> working properly is still common.
>
>> The project I'm on isn't even especially complicated, except for the
>> Maven builds. I wish it were based on Ant, but converting back once it's
>> tangled up in Maven is not straightforward. None of us, not even my
>> management (!), is happy with Maven.
>
> Personally I prefer ant over Maven - I like the ability to code
> my build. But from a project perspective coding the build
> is just extra cost.

I'll take a fresh look.

-- 
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|
0
Reply Lew 2/11/2011 4:33:11 AM
comp.lang.java.programmer 51880 articles. 38 followers. Post

26 Replies
120 Views

Similar Articles

[PageSpeed] 14


  • Permalink
  • submit to reddit
  • Email
  • Follow


Reply:

Similar Artilces:

build dependencies in part of a java library (jar file) ...?
~ I need to handle standard unix tar and tar.gz files in java and apache ant comes with it. ~ Now, I don't the whole ant library I just need the tar handling section of it. You could always go the monkey way and start trying to compile single files and such things, but I am sure someone has run into such problems before. ~ How can you just extract part of a library with the functionality you need? ~ Thanks lbrtchx On 19 Dec 2010 23:26:03 GMT, lbrt chx _ g(e)mail kom wrote, quoted or indirectly quoted someone who said : > How can you just extract part of a library ...

how to build gem whose dependencies depend of the platform?
Hi! I need to build a gem whose dependencies are dependent of the platform itself. For example when `gem install my_gem` is issued under Windows, then in gemspec i have to have spec.add_dependency("gemX"), but if the command is executed under linux then i need to have spec.add_dependency("gemY"). Is there any easy way to do this or should i just do it like this instead: 1) remove all platform specific dependencies from gemspec 2) when loading the gem, then use RUBY_PLATFORM to decide what gems to load and rescue Gem::LoadError to print out friendly messages li...

Dependency resolution
At what point exactly are the dependencies among different modules resolved, when compiling or linking? Thank you in advance ... On Fri, 1 Feb 2008 12:28:09 -0800 (PST), "williammaw@aol.com" <williammaw@aol.com> wrote in comp.software-eng: > At what point exactly are the dependencies among different modules > resolved, when compiling or linking? On what platform, in which programming language, with which compiler? Some languages are never compiled or linked, you know. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://c-faq.com/ comp.lang.c++ ...

[News] VMware Builds Fog Computing with Java (GPL) and Terracotta (Java/GPL) Gets Faster
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 VMware target Springs to open-source cloud management ,----[ Quote ] | Cloud Foundry expands SpringSource's product line to building, deploying and | managing applications based on Java, Spring, and Grails on a cloud | environment. Clearly VMware had an idea of service when it announced the | intention to purchase SpringSource for $362m to get its vSphere hypervisor | cooperating with cloud applications. `---- http://www.theregister.co.uk/2009/08/19/springsource_cloud_foundry/ Ehcache caching solution goes to Terracotta ,----[ Quot...

build a browser in java
does ne1 hav any clue as to how to go about building a browser using java..im lost On Sun, 24 Sep 2006 22:57:02 +0100, isha <isha.myname@gmail.com> wrote: > does ne1 hav any clue as to how to go about building a browser using > java..im lost As with any software project, start with the requirements. Until you know exactly what you want to achieve, you can't really plan to achieve it. Are you talking about a fully-featured web-browser for veiwing any page on the public Internet with full JavaScript and CSS support? That's a huge task (look how long it took the M...

java build path
when we do "add external jar" in eclipse's build path ....does theexternal jar files comes into my web application project ? Forexample, i have my web application (jsp+servlet etc ) in c:\mywebproject ......i have added some external jar files in eclipse "javabuild path" for compilation .does these external jar files becomes a part of my application ? dothey copied into my application automatically when i "add externaljar" in eclipse "java build path" ? gk wrote: > when we do "add external jar" in eclipse's build path ....d...

dependency-detection in java
Say, I've got two classes A and B, one of which (A)contains "static final" fields, the other (B)references these fields. Now the compiler doesn'tuse references, but includes the values from A directly in B.Now suppose some of these fields in A are changed.What is the usual "trick" to make sure that all"B"-type classes are recompiled, when an "A"-typeclass has changed?Is the only sensible way really to remove *all*..class files and have *all* files recompiled, ordoes there exist some trick to let the compilerknow these dependencies, and do the r...

building linklist in java
Hi i want to do insertion sort, merge sort and quick sort on my linkList of ints.. do anyone have an idea how to do it?? these are the codes. And i also need to define a lifo fifo class.. class UTGLLElement { public int myData; // data item public UTGLLElement next; // next link in list // ------------------------------------------------------------ public UTGLLElement(int data) // constructor { myData = data; } // ------------------------------------------------------------ public void displayLink() // display this link { System.out.print(myData + " "); } // -...

ISE build dependencies
In ISE 6.2i, I compile a design off a mapped drive at a foreign site(ie I did not install the software and do not have administrative privileges). For example, I try to run Map, sometimes it completes with a green check mark, and sometimes it completes with no green check mark. Sometimes when it compiles with a green check mark, and I hit the Map Report, it reruns all the tools again (like xst, ngcbuild, map) as though a source hdl file had been changed. but no source files have been changed. Its maybe like the filesystems are running off two different timestamp clocks? Any ideas? -...

Building GUI with dependencies
Hi , I need to generate a dynamic GUI, with textboxes & listboxes. But i need to place some dependency on some of the fields. i.e if the Listbox value of listboxA is "Option A", then display a few set of textboxes, if the listbox option is "Option B" then display another set of parameters. how do i do this dependency using STRUTS. Are there any libraries/tools to do this. Appreciate you inputs ...

How do I build a Java Application
How do I make a .jar file I can run by just clicking on it? I need to know how to do this in JBuilder or possibly Eclipse. "Big Daddy" <sahbdkfsahkjfh@msn.com> wrote in message news:sahbdkfsahkjfh-9E3016.11430028042006@unlimited.newshosting.com... > How do I make a .jar file I can run by just clicking on it? I need to > know how to do this in JBuilder or possibly Eclipse. In Eclipse, right click on the project, and choose "Export". You'll have a list of formats to export to. Select "JAR". From there, just follow the wizard, answering all ...

java custom build
I am using java's jvm inside an application to run custom scripts, however the load time of the jvm is too slow.. I'm guessing this is from all of the libraries being loaded etc. Does anyone know of any existing projects that either provide a slimmed down java jvm which only loads necessary libraries? Or does anyone know of a micro jvm that provides JNI? Or does anyone have any ideas on speeding up the jvm load time? (I cannot pre-load stuff) I need it to be under a half second, better under a quarter second. -- Also, while I'm wishing for the moon, I'd like a jvm that...

Java Version Dependency
Hi Gang: Consider this example scenerio. Suppose I compile a .class file in JDK 1.4 and deploy it in JDK 1.2 environment. Now my application/applet was using a new method introduced in 1.4. What will happen in this case for applet and for application?? TIA Manu Anand B'lore, India Manu Anand wrote: > Consider this example scenerio. > Suppose I compile a .class file in JDK 1.4 and deploy it in JDK 1.2 > environment. Now my application/applet was using a new method > introduced in 1.4. > > What will happen in this case for applet and for application?? One of two thi...

Build and runtime dependencies
--047d7bdc1a86406e6304d150040a Content-Type: text/plain; charset=ISO-8859-1 I have two Linux From Scratch machine. On the first one (the server), I want to build install python 3.3.0 in a shared filesystem and access it from the second one (the client). These machines are fairly minimal in term of the number of software installed. I just want to install python on this filesystem and anything else. I would like to know what are the build and runtime dependencies that are needed on both machine. My understanding is that the core CPython interpreter only needs a C compiler to be...

Overload Resolution in Java
Can someone explain me how overload resolution works in Java? For example if I have function void f(int, float); and I will call f(1.5F, 3.1F) what would be the result? Thanks In article <cfd5cfdb-3118-4f34-9e4e-059651043158@j22g2000hsf.googlegroups.com>, zbigniew@szymczyk.eu wrote: > Can someone explain me how overload resolution works in Java? > > For example if I have function void f(int, float); and I will call > f(1.5F, 3.1F) what would be the result? This will result in the loss of information. See section 5.1.3, Narrowing Primitive Conversions: <http://jav...

Build order and dependencies
Hello all, Does anyone know whether it is possible (or how) to tell MSVC in what order it should build in batch build mode? I am trying to build the wxWidgets2.5.1 DLL libraries, and even though the wx_dll.dsw file lists the dependencies, it will compile them in the wrong order. Thanks in advance, Arpad =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --------------------------------------------------------------------- To unsubscri...

Building P2P system in Java
Hi Guys . As a part of my college project, i have to build a Peer ToPeer file sharing system in Java. Can anyone tell me how should istart. I tried studying the source code of Limewire but it was quitedifficult.Madhur On 2007-12-18 12:34:35 -0500, mako <madhur.kapoor@gmail.com> said:> Hi Guys . As a part of my college project, i have to build a Peer To> Peer file sharing system in Java. Can anyone tell me how should i> start. I tried studying the source code of Limewire but it was quite> difficult.You can start by defining1) the functionalities of your P2P application, and2) ...

Dependence of GUI appearance on resolution
Greetings, I developed a GUI using the GUIDE tool on my laptop when it was in its docking station and connected to a 1600x1200 display. When I take the laptop off the docking station and use the 1920x1200 resolution screen laptop, the GUI looks markedly different from the way it looks on the seperate display. The overall size of the GUI in pixels is markedly increased from 587x563 to 819x851, and there seems to be a lot of unncessary empty space. My question is: Is there a way I can have better control of how the GUI looks on different displays? For example, can I mandate its size in pix...

building a library with an external dependancy
Hi, I want to put some of my object files together in a library. They are all Windows controls, although that doesn't really matter. Problem is that these controls have dependancies on components from other libraries, in specific a function called InitCommonControlsEx from the comctl32 library, which causes linking to fail. I have tried to extract the appropriate object out of the appropriate library (dyis00092.o out of libcomctl32.a to be precise) and add it in into my library, but either way the linking fails (and it in turn may depend on yet another object). This is what I get: ...

Build slices in Java and Eclipse
I've been away from Java for a few years and have lost track of some of the more recent developments. Is there now an easy way to do the following: I'm experimenting with Eclipse - which I like, and have developed a test project which contains "client specific", "server specific" and "general code." How do I go about building different slices from this one project i.e. producing a server jar, a client jar and a general jar, each containing only the branches of the package hierarchy relevant. If Eclipse cannot do this, is there a plug-in that can - prefer...

Building a slideshow software in Java
Hi people! I'm building a photo slideshow software with synchronized music. I've done lots of server-side java but I'm new in the client area, so a little help is needed. My question is, is possible to read and show jpeg, gif, etc... files with the classes that come with j2se 1.4 ? Is JAI or JIMI needed for these tasks ? I'd like to do transitions with effects (like in powerpoint files) between photos, too. Is possible to read and play MP3 files in java with the j2se 1.4 classes ? A external lib is necessary ? Can you give me some advice or point me to a website with useful i...

Java building automation framework
I work for Tridium, a company that designs and manufactures internet enabled building automation controls and software. The real value of our product is the open software framework, called Niagara, which helps manufacturers develop Internet-enabled equipment systems and device-to-enterprise applications. Niagara resolves the challenges associated with open systems, integration, connectivity, and interoperability by integrating diverse systems and devices - regardless of manufacturer, or communication protocol - into a unified platform that can be easily managed and controlled in real-time ove...

Time depended java program
folks I have 3 java files 1) Parser ( parse xml files) 2) converter ( converts xml into lucene docs) 3) Searcher ( searches lucene docs) I want to run this three programs in sequential order after every 2 minutes on my laptop( of course when i switched it on) Is there any way to do this?? thanks I would say that this is in no way a java question, but a general "how do I run programs at a given (scheduled) time in my operation system?" question. In an UNIX environment you might use cron to to that... as for Windows: AFAIK there's a "run scheduled tasks" utilit...

How to build a dependency injection framework by myself?
Hi, I am using a factory class to build instances. the factory method looks like: <code> class MyFactory{ Item getItem(String key){ ...} } </code> and the key and class are configured in a file key=com.abcd.ClassA b=com.abcd.B <code>Item</code> is an interface implemented by some of the above classes mentioned inside the cofiguration file. I want the factory class to read the configuration file and then instantiate the given class and as a return value. But I have no idea how to instantiate the class. I tried Class.forName() and seesm it is not a good solution to th...