Path: csiph.com!eeepc.pasdenom.info!news.pasdenom.info!news.dougwise.org!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!newsfeed.straub-nv.de!noris.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: Markus Gessner Newsgroups: comp.lang.java.programmer Subject: Re: Dependency resolution in Java builds References: <87oc6mi2nl.fsf@web.de> Date: Wed, 09 Feb 2011 08:06:54 +0100 Message-ID: <87ei7hk7ox.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Cancel-Lock: sha1:MFLKId+g4gK6djjc1pjJLybCk7g= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 60 Organization: Arcor NNTP-Posting-Date: 09 Feb 2011 08:06:36 CET NNTP-Posting-Host: c6f044e2.newsspool4.arcor-online.net X-Trace: DXC=OUKEDi4^7?2gP]QSEBQ^d44IUKB4BFjnAC3YVL6_nk3I<4W 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