On Tue, Jul 5, 2011 at 2:50 AM, Kasun Gajasinghe <kasu...@gmail.com> wrote:
<snip> >> On Jul 4, 2011, at 11:48 AM, Robert Burrell Donkin wrote: <snip> >> > After many problems, I've now opted to uninstall the official Maven >> > and Ant packages (and Eclipse...), and use instead a set of scripts >> > which accurately and flexibly allow me to configure exactly the >> > official bytecode I want to use (a little bit like a better eselect). >> > >> > > By official did you meant the upstream packages available as binary like > maven-bin? If that's the case, these -bins are the same as upstream build. I > guess you meant that since there's only the binary maven is available now. > What did you find wrong? I've given up wasting my time tracking them Developers need good switchable support for multiple, official versions. Ideally, Gentoo would use it's slots system to maintain the official bytecode sources used to compose the applications I'm interested in using. This would allow me to use this local repository to provision OSGI and Maven without downloading them dynamically. The Gentoo approach (hacking together replacement builds for the bytecode) means all the source bytecode is an unreliable and unmaintainable way to provision a library infrastructure for bytecode languages. <rant> >> > It has always struck me as somewhat ironic that if the Gentoo team >> > donned their clue-hats and treated bytecode as the source form then >> > they might quickly have one of the best development environments for >> > the bytecode languages... >> > > I too kind of agree to this since the point being the built jars are > platform independent. If anybody like to know the points for it - > http://www.gentoo.org/proj/en/java/why-build-from-source.xml > I'm not going to discuss why building from source is good or bad any further > and is off-topic! ;) For bytecode languages, the compressed bytecode archive (for example, a jar) is the source. I've been using Gentoo for the better part of a decade and understand the arguments about bytecode languages very well used by Java team (and others). The problem is that they are just simply and plainly factually incorrect. This systematic dissemination of disinformation has IMO been tolerated by the wider community for too long. In particular, the phrase "In the future building, native compiling from Java source code using gcj could become a serious option." would be laughable if it didn't represent such an important and fundamental misunderstanding of how virtual machines work. On reflection and after many years of consideration, I've come to the conclusion that the main reason why these rules were picked were to ensure patchy and buggy support for bytecode languages on Linux. </rant> Robert --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
