Kill build.properties.sample
Why oh why oh why must so many projects work so hard at alienating so many users? What is it about open sores that, more often than not, behaves as if it’s some plague ridden leper that does its utmost to convince you to walk far far away as quickly as possible?
I’ve ranted about this before, but running into it day after day still gets my blood boiling. What the poo is the obsession with shit like a build.properties.sample file? How hard can it possibly be to create a build.xml that does NOT require tweaking or customising?
For fuck’s sake, even maven, a tool for spastics, by spastics, a tool that’s so badly written it would make any number of holy figures break down and cry like little girls, a tool so horrifically incompetent that it’d make the baby jeebus attempt to gnaw off his own family jewels, manages to actually get this right.
Of course, unsurprisingly, the biggest culprit here is jakarta projects. That grand repository that is almost satirical in nature. The consummate ease with which it demonstrates all sorts of ‘this is the kind of code that the average moron develops, welcome to the real world’ principles is truly a work of art.
It’s not even worth enumerating all the projects in jakarta that do this, the ones that don’t are few and far between. Lucene is a worthy exception; how those lucene devs sleep at night while being part of such an embarrassingly incompetent organisation is fast becoming a modern day mystery of epic proportions.
Of course, when you’re used to this level of pain, having to cp build.properties.sample build.properties and maybe add in a path to your favourite servlet.jar might seem trivial. Projects like slide and taglibs however go out of their way to make the experience unique and memorable.
It is insufficient in this case for example to merely specify that. You will often have to also specify an xml parser implementation (sometimes even separate sax and dom jars!), the path to jaxp.jar, maybe a jmx jar, the clogging jar, xalan, and often paths to multiple versions of said API’s.
In some rare cases (never, in the case of jakarta projects), there is actually a legitimate reason for not including some of these jars for legal reasons. In this case, ant’s <get> task will do nicely. Even if it fails, it wouldn’t kill you, asshole rumpranging chozgobbling shirtlifting developer, to avail yourself of the delightful <available> task in ant to check for your idiot jars and maybe, just maybe, provide some kind of useful feedback as to what shapes the poor overworked potential user needs to contort into in order to get your worthless sorry project building.
So please, please, stop hurting us poor users. There’s enough other stuff that defecates on us from great enough heights that this last touch seems just a bit excessive.
December 27th, 2004 at 1:10 am
Didn’t exactly get what you were ranting about but you are 100% correct about Lucene. For the past couple of months or so, I have been working on a simple app that uses Lucene and it’s good to see that it DOES NOT use any of the crappy Jakarta commons JARs.
Lucene is an exception probably because, Doug Cutting was the only developer that was actively involved in “architecting” this toolkit. More over, Lucene was first hosted on SF.net before it was “adopted” by Apache. Let’s hope the elite Lucene developer community continues keep this toolkit as a toolkit and not make it another “framework” that can solve world’s problems.
And with regards to “custom” XML JARs, I am guessing that it has to do with issues such as the ones you face when dealing with IBM’s piece of crap app servers such as WebSphere. I need to look into it when the time permits.
December 27th, 2004 at 1:24 am
>>
How hard can it possibly be to create a build.xml that does NOT require tweaking or customising?
<<
How could you create a ‘build.properties’ which would not require customizing depending on the particular user environment?
I have a ‘build.properties.sample’ for my project but would love to yank it if possible.
December 27th, 2004 at 1:49 am
This is one area where projects that use Maven shine. Maven keeps a list of jar files and versions of said jar files in its project.xml, along with a the URL where you can find said jar files. Your team can setup a Maven repo. If you download a project that can’t find the jar file at least you know where to look. Also, Maven can generate an Ant script that uses the
Also Maven creates a pom.xml file (which contains a list of dependencies needed to build an artifact) and stores it in the Maven repo with jar files. This way you can get a list of what jar files a jar file that you are using depends on (with all of the needed version info).
There are other advantages to using Maven. Check out Carlos Sanchez weblog. It has several entries declaring the joy of Maven (http://www.jroller.com/page/carlossg).
I dig Maven. It is not perfect, but it helps manage jarmageddon. I’ve written a few things about it in my blog as well.
I think it suffered from maturity issues early on. It gave a lot of people a bad taste. You had to be a real die hard to get it up and going, and the docs were not that great. It is stable now. There are plenty of wiki tutorials on getting started. It is still not perfect. Also, looking at jelly scripts can cause blindness. It is a step in the right directions. The plugin architecture is really nice.
http://jroller.com/page/RickHigh/home?catname=/Maven
December 27th, 2004 at 7:30 am
It’s amazing how many products do this, too. Even some that DID drink the Maven kool-aid use sample build properties – nothing quite so fun as checking out a CVS repository, noting a build.xml, executing ant – only to see a brand new “/home/foobar/F\:/projects/UselessCrap/dist” directory used for output, and likewise having the build fail because it can’t find “/home/foobar/F\:/jakarta-tomcat-4.1.27″ around.
It boggles the mind what these people were thinking. Maybe it was cowardice at the mere thought of distributing a servlet-api.jar or something, or maybe they think CVS magically adds directory trees to the repository on commit. (Oddly enough, the project I’m thinking of here included the maven-generated web site – with eight versions of the distribution artifacts – in the CVS tree.)
December 27th, 2004 at 10:02 am
Well, on behalf of the Lucene developers, I thank you for your highest praise! ;)
December 27th, 2004 at 11:18 am
How about a pointer to an open source project that is doing it right?
December 27th, 2004 at 11:46 am
>How about a pointer to an open source project that is doing it right?
you’re new here aren’t you?
December 27th, 2004 at 1:55 pm
I know one way you can end build.properties.sample torture: contribute patches.
December 27th, 2004 at 2:36 pm
“How about a pointer to an open source project that is doing it right?”
Lucene was mentioned. Isn’t that good enough for you? What more do you want?
In fact, Lucene has been mentioned positively so many times, that it’s just sickening.
December 27th, 2004 at 4:21 pm
Just stick the jars in a /lib directory in your svn/cvs repository and be done with it. No build.properties or Maven.
And, yes, for projects depending on Sun jars with nonsensical licensing Ant’s get task is your friend.
December 27th, 2004 at 5:37 pm
You may be interested in reading the PHP And MySQL blog if you have a seething hatred for open sores zealots. Pretty damned funny thus far.
http://www.livejournal.com/users/phpandmysql/
December 28th, 2004 at 1:53 am
Lucene sucks! Its dog slow and written in that crappy verbose object oriented style. Try reading the code, there’s 10 abstract interfaces for every line of actual code.
December 28th, 2004 at 8:48 am
build.properties sometimes is necessary to cater for different developer environments and to avoid a lot of duplicated jar files lying around.
December 29th, 2004 at 3:24 am
Muthu, what is so special about your user’s enviroments? Pardon my ignorance, but isn’t all any project really needs to do in a build is drop a jar/war/ear in a lib/ or dist/ directory under the source tree?
Sure, the actual program may need a config file to run (ie: where do I place my temp files, what DB to use, etc) but those strictly belong in that runtime config file, not in any build. There should only ever be one build.
Write once, run anywhere, remember?
December 29th, 2004 at 6:25 am
Talking about “asshole rumpranging chozgobbling shirtlifting developer”… here is something for your fancy:
http://alt.textdrive.com/pl/
December 29th, 2004 at 4:12 pm
Considering that projects I work on uses emmea, aurigadoclet, and few other different home-grown tools (a full build is doing unit testing, produces coverage report and creates pdf javadoc documentation; of course you can fire ‘ant dist’ without those tools, but it doesn’t change the fact of build-env.properties existance). IMHO it is better to have paths for them in some build-env.properties than to assume that they are in some ../../../blah/ place. (please don’t tell me that I should bundle them up with the codebase ;-))
just my 2 cents.
Cheers,
a.
December 29th, 2004 at 11:02 pm
:: —————————————————————————————————-
:: $Header: \BPMS/ProjectRoot/Phase1/Development/build.properties.sample,v 1.1 2004/12/17 07:51:11 muthu Exp $
:: —————————————————————————————————-
:: —————————————————————————————————-
:: ************ NOTE: Directory Path MUST Contain Forward Slash ‘/’ ***********
:: —————————————————————————————————-
:: —————————————————————————————————-
:: Base Directory.
:: —————————————————————————————————-
BASE_DIR=C:/home/projects/BPMS/ProjectRoot/Phase1/Development
:: —————————————————————————————————-
:: The JAVA Home directory.
:: —————————————————————————————————-
JAVA_HOME=C:/Program Files/Java/jdk1.5.0
:: —————————————————————————————————-
:: The ANT Home directory.
:: —————————————————————————————————-
ANT_HOME=C:/home/tools/apache-ant-1.6.2
:: —————————————————————————————————-
:: BPMS RELATED
:: —————————————————————————————————-
BPMS_DEPLOY_HOME=C:/home/projects/BPMS/ProjectRoot/Phase1/Deployment
WORKFLOW_DEPLOYED_DIR=${BPMS_DEPLOY_HOME}/workflow_deployed
WORKFLOW_REPOSITORY_DIR=${BPMS_DEPLOY_HOME}/Repository_Local
EXEC_BPMS_CLIENT=${BPMS_DEPLOY_HOME}/bin/bpms.bat
:: —————————————————————————————————-
:: APPLICATION SERVER RELATED
:: —————————————————————————————————-
EAR_DEPLOY_HOME=C:/home/tools/jboss-4.0.0/server/default/deploy
:: —————————————————————————————————-
:: END END END END END END END END END END END END END END END END END END END END END END END END END
:: —————————————————————————————————-
:: —————————————————————————————————-
:: $Log: build.properties.sample,v $
:: Revision 1.1 2004/12/17 07:51:11 muthu
:: Moving Build files from ‘build’ to base ‘Development’ folder.
:: —————————————————————————————————-
Bas & All,
Given the above build.properties file, How can this be genercized for all users.
Note ANT_HOME, JAVA_HOME, EAR_DEPLOY_HOME etc., Users might have them in their preferred directories.
December 30th, 2004 at 4:08 am
I don’t mind the odd build.properties.sample. What I hate is build files that don’t provide a sample but expect you to know which properties you should define and what they should point to.
February 4th, 2005 at 4:21 pm
==
There should only ever be one build.
==
Bas, have you ever worked on an application that is deployed on multiple servers?
February 17th, 2005 at 6:02 am
Lucene used to have the stupid build.properties.sample thing going on but when I became a commiter I quickly eradicated it.
March 4th, 2005 at 8:06 pm
Not sure what the rant is with maven, the build.properties.sample is needed because its not really known where and what your J2EE container is.
December 3rd, 2006 at 1:42 pm
If you want to manage MySQL you should check MySQL Turbo Manager.
Product page:
http://www.mentattech.com
Regards,
Teksure