aspose file tools*
The moose likes Ant, Maven and Other Build Tools and the fly likes ant properties in subtask Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Ant, Maven and Other Build Tools
Bookmark "ant properties in subtask" Watch "ant properties in subtask" New topic
Author

ant properties in subtask

Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30546
    
150

Is there a way of reading a property defined in a child/subtask as called by the ant task? In the following code, the test target display the value, but the test2 target does not.



[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Tim West
Ranch Hand

Joined: Mar 15, 2004
Posts: 539
Jeanne,

I don't think this is possible - neither "ant" nor "antcall" have any properties that might help with this. 'inheritAll' won't help here, as it works the other way: it allows properties you have defined to be passed into task being called.

My Ant book ("Ant Developer's Handbook" by Williamson et al) has this semi-cryptic note on the topic:


'In "Ant in Anger," Mr. Loughran suggests that...you should define init targets [TW: targets that set up global build properties], and then use the <antcall> task to execute them. This obviously worked in a previous version on Ant, but in the current releases, any properties set in a target that is executed via <antcall> will be visible only inside the target that is being called with <antcall>.' (TW: quote edited slightly so it makes sense out-of-context)


I guess the idea is that <antcall> is like a method invocation, so the logical scope rules apply for variables. The book recommends using 'depends' for setting properties, as in your first target - but I guess, since your asking, there's a reason this won't work for you.

That isn't a definitive answer, but there ya go


-Tim West
[ July 13, 2005: Message edited by: Tim West ]
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30546
    
150

Thanks Tim. It's good to know more definitively that this won't work so I don't waste any more time on it.

What I'm really trying to accomplish:
I am working on a build script that is used by several teams. I want to allow the callers to specify how they want to include tests (run one test suite, have ant build it for them, etc.) I thought that I would have callers specify a build file in build.properties that would build a fileset of tests. Apparently, this won't work though. I can't use "depends" if I don't know the name of the target (and build file) until runtime.

My other thought is to have the specified build file assemble the fileset, run the tests and create the report. I can provide tasks that do the last two. Then the caller just has to create a fileset and call the other two tasks. I'll try this approach and see where it gets me.
Tim West
Ranch Hand

Joined: Mar 15, 2004
Posts: 539
Interesting problem...I can't think of a better way to solve it myself =). That does seem like a clean solution though - you're providing them some Ant "methods" into which they can pass "parameters". This seems more in the imperative style of programming (as much as Ant can be called programming) than the other solution. Whether or not this is a good thing, I'm not sure

I've got a lot of similar build files at the moment for different projects and my best (hackish) solution so far is simply to copy the basic build.xml for each one and alter it in the places necessary. The projects aren't *quite* similar enough to simply alter some properties...and I haven't really tried that approach anyway, I have to be honest!


-Tim
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336


you're providing them some Ant "methods" into which they can pass "parameters".

When ever I see a requirement like that I think of macrodefs, since they can accept optional attributes. You could create multiple test.xml files for each team and pass in the directories holding your tests as attributes to the master test macrodef. Of course, each team would have to maintain a build file rather than just a properties file.

Alternatively what you could do (though this is a hack) is have each team define a <team_name>_tests.xml which just contains a <fileset /> of tests to run. Then you could include a test.xml build file and use <loadproperties /> and <replace /> to change it at run time. You would get away with this if you called this hacked build file via an <ant /> task from your main build.xml. Not nice, but might work.
[ July 14, 2005: Message edited by: Paul Sturrock ]

JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30546
    
150

Tim,
I'm actually working on the department build. So I can't just cut and paste. Thanks for the verification that my solution is at least somewhat clean. To me the "imperative style of programming" made it feel wrong.

Paul,
LoadProperties loads from a property file. I don't understand how this relates to the team_test.xml you described.
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30546
    
150

Originally posted by Jeanne Boyarsky:
have the specified build file assemble the fileset, run the tests and create the report. I can provide tasks that do the last two. Then the caller just has to create a fileset and call the other two tasks. I'll try this approach and see where it gets me.

I tried this and it works. It's not that ugly as the common code is in a separate file (so it's in one place.) And this task is optional anyway, which minimizes the damage if the user doesn't call the provided tasks.
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

Originally posted by Jeanne Boyarsky:

Paul,
LoadProperties loads from a property file. I don't understand how this relates to the team_test.xml you described.


Ah yes - I meant loadfile. If you define a number of filesets in different xml files, you can import a particular one as properties, and use replace to put the fileset into you test target. Its really just a more convoluted way of doing what you have ended up doing anyway I think.
[ July 15, 2005: Message edited by: Paul Sturrock ]
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16068
    
  21

If you want to see a truly horrible way of building complex projects with optional component selection, take a look at Apache Cocoon.

Not only are there some dynamic processes going on there, but they do very scarey things using XML entity definitions as "macros".

But check the latest Ant docs - Ant recently acquired some capabilities that appear expressly intended to provide a cleaner solution.


Customer surveys are for companies who didn't pay proper attention to begin with.
Tim West
Ranch Hand

Joined: Mar 15, 2004
Posts: 539
I just came across this article which describes a new feature in Ant 1.6 - macros!


-Tim
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30546
    
150

Originally posted by Tim West:
I just came across this article which describes a new feature in Ant 1.6 - macros!


-Tim

Cool! Thanks.
Rob Williams
Greenhorn

Joined: Jul 22, 2005
Posts: 6
Is AntFetch relevant to the original issue:

http://ant-contrib.sourceforge.net/tasks/tasks/antfetch_task.html


Rob Williams
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30546
    
150

Paul,
Macrodefs are the way to go! I didn't realize until Tim posted it that those are part of Ant. I already have the name of the team's XML passed as a property. I'll see about refactoring what I did to use them.

Rob,
Welcome to JavaRanch!
Yes, antfetch is precisely what I was looking for. I'll have to download ant-contrib. This particular task is done, but I may be able to use antfetch for some of the testing I'm trying to do. Thanks!
[ July 26, 2005: Message edited by: Jeanne Boyarsky ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: ant properties in subtask