Friday, March 31, 2006

Textpad and ant

Did you know that you could get textpad to easily call ant for you? This allows you to compile your code from inside of textpad and jumpt to errors.

Why you want to do this? Well, in cases where installing Eclipse would be more of a hassle (both in time to install, setup and train), textpad is a nice middle ground. Especially, because the folks around here have textpad handily available.

A quick search for textpad ant compile in google found me the perfect page. Except for one small detail, the link was dead. Thanks to Google's cache though, this was no problem.

So, here are the recommended instructions. Thanks to Tom Wilczak (whover he is) for suggesting the following:


  • First get all your environment variables set--if you are able to run Ant from the command line you should be fine.
  • In TextPad, select Configure -> Preferences then highlight Tools
  • Click the add button, and select DOS command
  • Enter "ant -find" in the Command field
  • Click the apply button.
  • In the left pane, expand "Tools" and highlight "ant -find"
  • Make sure that the 'capture output' and 'save all documents first' options are selected. You may also want to select 'Prompt for parameters', as this will allow you to run the other ant targets besides the default project build (ie: Ant clean, ant test, etc.)
  • Enter the following in the 'Regular Expression to Match Output' field:
         ^[ \t]+\[javac\] \([A-Za-z]:[^:]+\):\([0-9]+\):
    
  • Set the File Register to 1, and the Line Register to 2.
  • Click the apply button.

To run Ant, select it from the "Tools" menu while editing any project source file. The build.xml file may be in the same directory, or any ancestor directory.

To jump to the offending line on a compiler error, double click the second line of the error message. This works only for compiler errors and not for failed tests.

You can also configure the tools to run from your choice of keyboard shortcuts by selecting the Keyboard option in the preferences box, and selecting tools. The rest should be self explanatory.

6 comments:

  1. Dude, even being a long time TextPad user, I can't even read this. If you're not using Eclipse -- you are just wasting time and productivity.

    It's easy to use, and Ant support works out of the box. You just have to try it, and you'll never, ever go back.

    ReplyDelete
  2. It's not for me...it's for a "friend."

    Seriously - I thought that downloading eclipse and getting it configured for someone who doesn't do development, but alread has textpad, was a bit of overkill.

    Maybe I'm not giving eclipse enough credit as a lighweight option.

    Me, I'm still an emacs man myself.

    ReplyDelete
  3. I strongly believe that software teams should standardize on a toolset and mandate that toolset. While this may seem unfair, I think that in the end it is better for everyone and will lead to a more productive and unified team.

    One good argument for this is the XP practice of pair programming. If you're an Emacs guy and I'm an Eclipse guy that makes life pretty difficult for us to take turns at the keyboard.

    This will also allow the team to support each other with the toolset and the development process. Let's take source control for example. If you have some developers using CVS via command line, some using it via Eclipse, some using it via IDEA, and some using it via WinCVS, how hard is it when you need to send email out the team regarding a new branch or merge? When I do this or when something changes about our project configuration, I send email out to the team once, either including specific instructions on what they need to do or directing them to the wiki.

    OK, one last thing and I'll leave you alone. If you were to survey 100 Java developers about their development tools, I'd bet that 95% of them would be accustomed to some sort of modern IDE. Even diehard vim and emacs people have seen the light and moved to a real IDE (read: Eclipse).

    In the last year, I've probably interviewed 50 Java developers, and I always ask what IDE a developer uses. As unfair as it may sound, a developer that doesn't use a real IDE had better seem to walk on water in other respects :-) I can that most of the developers (probably 40) were Eclipse users, and about 8 more were IDEA users, and the last 4% were vim/emacs/SomeOtherIDE users.

    If you still think that you can do everything that Eclipse can do with emacs, let's sit down sometime and refactor some code. :-)

    ReplyDelete
  4. Oh, so the line of questioning has changed :-). Emacs vs. Eclipse.

    The current way this has shaken out at my work place is that all of team members use Eclipse, while I use emacs. This has turned out to be a pretty good thing because most of what I do is review code, not write new code.

    Having a different view of the code in different tools helps me to see things that the developer may not have (and of course it goes the other way).

    They all use CVS through eclipse, which most of the time is good. Yet when eclipse gets confused, I can still use the command line version of CVS to "fix" the problem.

    So, this only shows that a team with all standard tools, and someone to review code with a different set of tools can be a good thing.

    As to whether I'm using emacs out of habit, or because it's so powerful, is another question. It's one that I've been thinking a lot about. I guess the only way I'm going to learn if it's out of habit is to really try to give it up and embrace eclipse. I guess that way I'd be able to truly say: "Here are the 10 things that I like about emacs that eclipse doesn't do."

    The problem with switching to eclipse from emacs is that I use emacs for just about everything - from reading email, to running shell commands, to writing all kinds of code. So sure, I may be able to write java code in eclipse nicely, but what about other activities?

    And yes, emacs has some code generation facilities, but isn't nearly as nice when it comes to refactoring. Yet, my gut is that there are other things that I can do that eclipse users can't as easily. One example that comes to mind is the way I do code reviews. I've got emacs tuned really well for that.

    Yeah, I'm going to need to try eclipse for a month or something like that before we can really answer this thread (unless you want to learn emacs? Should only take about a year to get good at it?).

    ReplyDelete
  5. Anonymous1:55 PM

    1) I am Tom Wilczak :-)
    I wrote this up for a class I was taking at the begining of my graduate career. We just started using ant, and text pad was the defacto 'IDE' for most of the students there.

    2) Eclipse, if it did exist at that time (Im not positive it did) was not in wide use, and while definitely useful, didn't have the 'lowest common denominator' appeal of something like textpad. As for setup...I dont know, even with eclipse 3, I find the ant support to be somewhat lacking and to this day, more often than not end up running my builds in cmd.exe (or terminal.app) just to make sure the t's and i's are crossed and dotted. This may be due to the divergence between the default java builders that run in eclipse, and ant.

    Perhaps Im only showing my Eclipse ignorance here, but personally, I'd like to be able to create full eclipse projects straight from an ant file (classpath, src and bin folders, you name it) rather than having to set all that up and then circumvent it when I run the real build with ant. This is leaving aside the whole question of configuring all that in two different places/interfaces...

    ReplyDelete
  6. Anonymous6:10 PM

    Eclipse is nice, but I still use Emacs as my default "IDE". I have since 1989 or so, and I'm not about to change anytime soon unless forced.

    I did try Eclipse, with an open mind and the notion that it was the next great thing. I've used IDEs extensively in the past, so I knew I could be OK in a non-Emacs world. My Eclipse was crashy, and it just had some 'you should do it this way and only this way' stuff, basically getting in my way when it came to Ant and classpaths and such... rather than argue with it, I went back to Emacs.

    Mandating the use of a single tool in a development team is just a way of working around the non-standardized, problematic features of that tool. Ant is supposed to be the kind of tool which, leveraged by IDEs, can allow anyone, even without an IDE, to build your project. Frankly, Eclipse kind of misses the boat because the Ant files it generates hard-code all sorts of user-specific ( not just project-specific ) stuff in the Ant files it generates... that coupled with the other problems I had led me back to Eclipse. Could I have made Eclipse work if I'd really had to? Sure, but at the cost of productivity in the near-term.

    Thanks for this article, Ben and Tom. It's gained a high google score, and is useful for a friend of mine, who also saw Eclipse as too complex but is liking TextPad. I'm going to push him towards Eclipse, actually, but... for a simple, small Java project, or someone just learning a programming language... Eclipse has quite a learning curve... being able to use TextPad to drive Ant is a nice thing.

    I like Eclipse, but I don't think folks like Mark here appreciate the steep learning curve it has, especially in situations where you want custom Ant scripts and maybe a slightly different project structure than Eclipse will give you by default.

    I have the same complaints about Eclipse that Tom seems to have... if you're not doing things "the Eclpse way", it's very hard to work with. Unlike Tom, I do not do anything with Emacs other than edit text files and occasionally run shell commands. The reasons I went back to Emacs instead of sticking with Eclipse were all to do with it's default treatment of Ant files, learning curve around configuring projects, stability issues, and general text-editing features ( emacs is better general-purpose, Eclipse is a refactoring & code-completion machine ). I probably would have stuck with it had my install not started crashing.

    ReplyDelete

LinkWithin

Related Posts with Thumbnails