• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Jar-making ants

 
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello JavaRanch,
. At Mr. Holloway's suggestion, I've started delving into Ant. Successful installation, "Ant -version" tells me its version and date!
. At first I had a smidge of trouble with writing "Build.xml", but I realized that WordPad was adding unseen characters and have switched to notepad (yes, I'm on a Windows machine, XP if it matters).
. This is the complete content of my Build.xml:

Typing "ant" on the command line results in the following output:
Buildfile: C:\Documents and Settings\zanders\build.xml

BUILD FAILED
C:\Documents and Settings\zanders\build.xml:3: Unexpected element "{}jar" {antlib:org.apache.tools.ant}jar

Total time: 0 seconds.

. Because it says it's breaking on line 3, which is the end of the file, I expect there are other elements it wants to see along with the <jar> block. However, this is almost identical to their sample simple jar build. Did I miss a part where it said, "You have to add this to these other lines in the build file", or "every build file has to start with X"?
. An other consideration that might be important is that I'm using the java.class files constructed by an IDE (JDeveloper, if it matters). There's some oddity in that there are more .class files in that folder than I started with, i.e. I wrote "moduleA.java" and the class folder contains "moduleA.class" and "moduleA$randomOrganization.class", and I don't ever remember writing something called "Huffman.java" but there's a "Huffman.class". Would you recommend I use Ant to classify my java code as well? (It would be an ugly process, as there are dozens of files, but I think I can figure it out.)
. I will, of course, be reading on my own to solve this problem (as well as the problem of "I haven't formally studied this stuff in a decade"), but I'd appreciate any non-null pointers you're willing to lend.
Thanks for your brains,
Zachary Anderson
 
Zachary Anderson
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Silly smileys: That emoticon should be translated to a colon followed by a lowercase "o".
 
Zachary Anderson
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Found it, it did, indeed need to be part of a larger file.
<project><task><jar/></task></project>
BUILD SUCCESSFUL

Of course, now the .jar can't find its main-class attribute, but as per my "Programmer's definition of progress: A new error message."
 
author
Posts: 5856
7
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A few tips that will prevent future problems:

a) Avoid "Program Files". Ditto for "Documents and Settings". First, spaces in path names cause some Java code fits. Second, if you ever upgrade to Win 7 (or heaven forbid, Vista), then "Program Files" is a lot more locked down than what it was on XP.

b) Don't use back-slashes when describing Windows paths, use forward slashes instead. Under some circumstances back slashes are treated as escape characters, which can lead to some really interesting debugging sessions.

c) Don't use full paths. Instead, use relative paths, in what case the location of the build.xml file is assumed as the base directory. Or use ${basedir} instead, which is the location of the build.xml file (by default). And for this to work, the build.xml should be part of your project's files. For example, you might have a directory structure like this:

C:/Documents and Settings/xanders/My Documents/Game 2.x/build.xml
C:/Documents and Settings/xanders/My Documents/Game 2.x/src/... (java files are here)
C:/Documents and Settings/xanders/My Documents/Game 2.x/classes/... (class files are here)
C:/Documents and Settings/xanders/My Documents/Game 2.x/dist/... (jar goes here)

Then you would have:




And actually, I recommend you look look into Maven. Even if you don't end up using Maven, adopting its directory structure will help.
 
Zachary Anderson
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Mr. Johnson,
a and b: I wasn't aware of the " " and "\" issues. Thanks for the brains, will copy everything over to a C:/GameProject (or somesuch) folder and alter references appropriate to such.
c: Right now, because I only have the source directory named in one place in a very small build file, it's shorter to list it explicitly (and having it on a lower rung will make it shorter still). If I use a reference three or more times, (maybe two if it was complicated,) it makes more sense to me to have it as such. Is there a reason other than style to do so?
d: Will check out Maven.
Thanks again,
Zachary Anderson
 
Peter Johnson
author
Posts: 5856
7
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
c: Doing it the way I mentioned makes the project portable. You can zip up the project and give it to someone else who might place it in a different location, and it should still work. And maybe it is not even another person - I have 3 computers and use different drives on each one, and some are running Linux. I can easily move my project from computer to computer and still have everything work.

Another side benefit is that when you create you next project, you can very easily update the build script to handle the new project. If you do it right, the only thing you will need to change is the name of the JAR file.

So if this is truly a one-off project that only you are concerned about, and you will never do any other Java development, then your approach of hard-coding full paths is fine. Otherwise, by taking a little more time now you can save yourself a lot of time in the future.
 
Zachary Anderson
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ah, that makes sense. Yes, I should implement good practice in general, and do want the .jars to play nicely on other people's machines.

Thanks again!
 
reply
    Bookmark Topic Watch Topic
  • New Topic