Steve Loughran

Ranch Hand
+ Follow
since Aug 06, 2002
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Steve Loughran

Ant 1.6 will have <scp> -its in CVS now if you want to download a nightly build, you will probable see an <ssh> task too, once someone writes it.
21 years ago
Its possible to use ant to install stuff, but that was never a design goal and it shows.
A good installer works out what needs to be done and does it atomically : you can cancel and it undoes everything, and at the end of the day leaves you with an uninstaller to clean up.
Ant, on the other hand, trundles along till it his a problem and then it is BUILD FAILED for the end user. Ant assumes that a failure to install is a failure of the build, and therefore a bug to fix, not something to roll back from.
That said, I use it server side all the time to install WAR files and tickle the app server.
-steve
21 years ago

Originally posted by Carl Trusiak:
Well, is my face red!
Sorry, I missed that. The 4th winner is:

Chris Reeves


Well, I guess that shows that the giveaway process is truly random. I hope all four winners enjoy their books, and enjoy working with Ant in the months to come.
For those who didnt win, better luck next time. You can grab a couple of chapters from our web site, and as the book should be in the shops next week, you can have a look at there and decide whether it merits parting with any of your local currency for.
-Steve
(who wonders of the reason that Borders doesnt let people plug laptops into their power sockets in cafes is to stop us developers working there and treating it as a big library)
-Steve
22 years ago

Originally posted by Doug Wang:

Its more and more interesting to me. Seems that these two books have many in common. I wonder whats the difference between them?


ours is pure ant, with topics (testing, ejb, web services) done with a 'how to do this with ant' theme. Also we dont mandate XP; there are a lot of places that the XP "dont plan ahead" ethos doesnt work, yet you can still use an ant based, test centric process to build, test and deploy your code.
I have a copy of the Java Tools book at work, and look at it for detail on things like HttpUnit, cactus, load testing etc. Just not the ant part
Also they cite me in it for Ant in Anger, and mention Erik too (he helped them in a Chapter), so we like them.
I dont know if they are doing an update to the book , I had heard a mention that one was planned; if so it will be updated to ant1.5 and no doubt benefit from the contents of our book too.
22 years ago
JNDI is nice for hot update of properties and replication across a cluster -though then you need a replicated directory service.
prop files are simple, but limited in what they can describe.
XML files are in-between; they have more power but are harder to work with.
The java 1.4 preferences API should nominally hide how the preferences are stored, so you could code for anything, but I aint used it yet to be sure.
The code to do this is in apache tomcat and then in ant; it is there to rename JSP pages.

the code to compare this is simply

for performance, a hash table would be better.
-steve
22 years ago
you need to get some kind of obfuscator; these are programs that make your java that much harder to understand.
Ultimately, people will be able to decompile your code if they really want to, there is nothing you can do about it but slow them down, or keep it secret by running it server side and having your clients make soap calls to it or something
22 years ago
Wierder things have happened. Take the JSTL standard taglib library. I'd never use that again after wasting a week struggling to cope with it. It's essentially impossible to debug any complex expression.
But there it is, a standard that is slowly rolling out. Me, I use velocity now
-Steve
22 years ago

Originally posted by David O'Meara:

This has always been my dislike of logging. When you do it poorly you have a performance hit whether you have logging turned on or not.
You can wrap in isDebug statements and work on lazy evaluation of debug Strings, but then debugging starts to take a significant position in the code rather than being a side issue.


Agreed.
One other issue, as soon as you start making some things conditional on debug being on, you change the behaviour of the system between debug and release modes. If the toString() operator has any side effects (very bad practise) then a log statement will change the system, so must be in the release build.
Likewise if toString() throws a null pointer exception in some circumstances ( a current issue with Apache Axis client BTW), then it is hard to log without breaking the app.
So there is a lot to be said for always having the log statements in there, taking the perf hit, and having low overhead, side effect free toString() methods for all your classes.
-Steve
(who does sometimes miss #ifdef DEBUG).
nb, Some people actually feed their java code through the cpp preprocessor for macro evaluation before compiling, using our friend Ant. I dont do this and dont like it, because I like the option of turning debug code on on a deployed system without a rebuild. Indeed, I like to do it without a restart.

Originally posted by Steve Loughran:


I should warn you: Ant does make automated deployment possible, but it can be hard work getting it right. Even with our book, it is hard, because production systems are often managed by operations people who dont trust engineers.


I almost forgot, I have a presentation on this subject online, When Web Services Go Bad, that talks about automated, integrated build, test and deploy processes. I have a theory that if you apply the development processes of use cases and testing to that of deployment and operations, server side dev is a lot easier. Ant is the basis for such a process.
22 years ago

Originally posted by Rishi Singh:
Welcome Eric ans Steve,
It would be nice if you guys explain us as to where exactly should we use Ant.
What purpose does it solves in development and
production stage
Rishi


Like everyone says, this should be a new thread. But ignoring that, and supplementing Erik's comment, I have to own up to sometimes starting up a project using my favourite IDE (currently IntelliJ IDEA) to start coding the project and a few unit tests to go with it.
But as soon as I have more than a couple of junit tests, I add an ant build file so that I can bulk execute all the tests every build, then add more stuff over time : jar of the file, execution of the jar, deployment and delivery, etc.
You dont need to write a fully complete ant build file from the outset, just evolve it as your project proceeds.
ant can also automate deployment, which is a very powerful feature, so powerful we ended up with two chapters on it. Basic deployment involves ftp, restarting tomcat, email, etc.
production side deployment involves validating datestamps, going via obscure routes (cd burns), generating different builds of your app for different target servers, etc. And once deployed, ant runs httpunit tests against my app, then generates an HTML report if it fails.
I should warn you: Ant does make automated deployment possible, but it can be hard work getting it right. Even with our book, it is hard, because production systems are often managed by operations people who dont trust engineers.
22 years ago
Ant deprecates stuff but rarely removes it. If you had something that broke between 1.4 and 1.5 you were unlucky.
more insidious is changes in behavior that dont break the build but screw things up. Example, in ant1.5 we really tightened down on any way to overwrite a property, and fixed what we felt was a bug in how properties get passed down in <ant> once you have about three levels of call.
Nobody complained in beta; after shipping we got bugreps on both issues. This is a hard problem: do we retain all bugs for 'compatibility' or do we fix glaring holes.
The ant1.x line tries to be backwards compatible. Dont worry about deprecation, nothing ever gets pulled.
The elusive Ant2.0 may break things.
22 years ago
Jikes is fantastic with ant; it really compiles fast and the new 1.16 version even understands the assert keyword of java1.4
to turn jikes on you can do it in the <javac> task or with
<property name="build.compiler" value="jikes" />
I dont like doing either as it hard codes your build file to use jikes everywhere; not everyone on the team has jikes and it is another support call when it breaks.
So instead I load in a properties file at the start of the build
<property file="build.properties" />
and in that file on *my* system, have
build.compiler=jikes
as one of the settings. Using a property file for per-user customisation of the build is a powerful technique you can use with all your projects, as it gives you great flexibility.
with two caveats
-you dont need the JDK unless you are doing jdk things (javac, rmic and others); the JRE itself goes a long way.
-'optional' tasks often need extra jars, as listed in the installation part of the ant docs. For example <ftp> and <telnet> need netcomponents.jar, and <junit> needs junit.jar.
the libraries you need are listed; you just stick them into ANT_HOME/lib and they get picked up.
22 years ago
It's hard to do AI in Java; wrong kind of language. I know, I used to do a lot of prolog stuff. Prolog is good for logic, just a maintenance nightmare. Java code gets bugs; AI code gets opinions.
That said, AI languages are good for XML work, and the semantic web is kind of AI applied to the web. So discussing semantic web stuff in the web services corner is AI of a sort.
22 years ago