You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Tom Cook <tc...@lisa.com.au> on 2000/05/04 01:58:30 UTC
New tasks.
Hey guys, I'm newish to ant, and new to ant development. Last night I
wrote a task to compile IDL using the Visibroker 4 idl2java tool. This
deals with all the options etc. Are you guys interested in such
product-specific tasks being added to the project?
Cheerio
--
Tom Cook - Software Engineer
"Never criticize a man until you've walked a mile in his shoes; that way,
when you criticize him, you're a mile away and have his shoes."
- A froggy bloke on a news group.
LISAcorp - www.lisa.com.au
--------------------------------------------------
38 Greenhill Rd. Level 3, 228 Pitt Street
Wayville, SA, 5034 Sydney, NSW, 2000
Phone: +61 8 8272 1555 Phone: +61 2 9283 0877
Fax: +61 8 8271 1199 Fax: +61 2 9283 0866
--------------------------------------------------
The verbose flag
Posted by Michael Saunders <mi...@amtec.com>.
To all:
I managed to get Ant to compile my sources into classes. It appears that I did
not specify my "includes" property correctly and therefore Ant did not match any
of my source files.
Thanks,
Michael
The verbose flag
Posted by Michael Saunders <mi...@amtec.com>.
To all:
For some reason my javac task does not seem to compile my classes. I am using
JDK1.2.2 on an SGI and I have the build.compiler property set to "classic". Ant
says that it is compiling (I think) but no classes are generated and no errors
are reported.
I looked at the source code for the javac taskdef and noticed that the code
outputs the command line arguments that are passed to the compiler to a log if
the verbose level is set (I this done with the -verbose flag?). However, if I
use the -verbose flag Ant doesn't output the arguments given to the compiler.
What am I doing wrong?
Following is an excerpt from my build.xml file and following that an excerpt
from Ant output using the -verbose flag.
Thanks,
Michael
<!-- Compiles the source code -->
<target name="compile" depends="prepare">
<mkdir dir="${build.classes}"/>
<javac srcdir="${src.dir}"
destdir="${build.classes}"
classpath="${classpath}"
debug="on"
deprecation="on"
optimize="on" >
<include name="amtec/io/*.java"/>
</javac>
% ant -verbose
Buildfile: build.xml
Detected Java Version: 1.2
Detected OS: Irix
...
[snip]
...
Setting project property: classpath -> .
Setting project property: build.compiler -> classic
+Target: prepare
+Task: mkdir
+Target: compile
+Task: mkdir
+Task: javac
+Target: clean
+Task: deltree
Build sequence for target `compile' is [prepare, compile]
Complete build sequence is [prepare, compile, clean]
Executing Target: prepare
Executing Target: compile
Completed in 6 seconds
Re: Taskdefs for JJTree and JavaCC?
Posted by External Lists <ex...@ManagedObjects.com>.
> Has anyone made task definitions for jjtree and javacc? I use these tools
all
> the time and would rather not use exec if someone has already made a full
> fledged taskdef for each.
Just one for javacc. Feel free to improve on it.
File taskdefs/JavaCC.java:
package taskdefs;
import COM.sun.labs.javacc.*;
import org.apache.tools.ant.*;
import java.io.*;
import java.util.StringTokenizer;
public class JavaCC extends Task {
private File srcFile;
private String [] options = new String[0];
public void setSrc( String fileName ) {
srcFile = project.resolveFile( fileName );
}
public void setOptions( String _options ) {
StringTokenizer st = new StringTokenizer( _options, "," );
options = new String[ st.countTokens() ];
for (int i = 0; st.hasMoreTokens(); i++)
options[i] = st.nextToken();
}
public void execute() throws BuildException {
try {
Options.JavaCCInit();
for (int i = 0; i < options.length; i++)
Options.setCmdLineOption( options[i] );
JavaCCParser parser = new JavaCCParser( new
FileReader( srcFile ) );
System.out.println("Generating parser for: " + srcFile );
JavaCCGlobals.fileName = JavaCCGlobals.origFileName =
srcFile.toString();
JavaCCGlobals.jjtreeGenerated =
JavaCCGlobals.isGeneratedBy("JJTree", srcFile.toString());
JavaCCGlobals.jjcovGenerated = JavaCCGlobals.isGeneratedBy("JJCov",
srcFile.toString());
JavaCCGlobals.toolNames =
JavaCCGlobals.getToolNames(srcFile.toString());
parser.javacc_input();
JavaCCGlobals.setOutputDir(); // Set the output directory
Semanticize.start();
ParseGen.start();
LexGen.start();
OtherFilesGen.start();
if ((JavaCCErrors.get_error_count() == 0) &&
(Options.B("BUILD_PARSER") || Options.B("BUILD_TOKEN_MANAGER"))) {
if (JavaCCErrors.get_warning_count() > 0) {
System.out.println("Parser generated with 0 errors and "
+ JavaCCErrors.get_warning_count() + "
warnings.");
}
// System.exit(0);
}
else {
String msg = "Detected " + JavaCCErrors.get_error_count() + "
errors and "
+ JavaCCErrors.get_warning_count() + "
warnings.";
throw new BuildException( msg );
}
}
catch (MetaParseException e) {
String msg = "Detected " + JavaCCErrors.get_error_count() + "
errors and "
+ JavaCCErrors.get_warning_count() + "
warnings.";
throw new BuildException( msg );
}
catch (ParseException e) {
String msg = "Detected " + (JavaCCErrors.get_error_count()+1) + "
errors and "
+ JavaCCErrors.get_warning_count() + "
warnings.";
throw new BuildException( msg );
}
catch (FileNotFoundException e) {
throw new BuildException( "Unable to open source file " + srcFile +
"." );
}
}
}
Taskdefs for JJTree and JavaCC?
Posted by Michael Saunders <mi...@amtec.com>.
To all:
Has anyone made task definitions for jjtree and javacc? I use these tools all
the time and would rather not use exec if someone has already made a full
fledged taskdef for each.
Thanks,
Michael
Libraries
Posted by Sean Russell <se...@germane-software.com>.
Hi there. Normally I lurk a while before posting, but I have a generic
question I haven't seen answered in the archives.
There is no globbing in the "property" task. There is also no globbing
in the "classpath" attribute of the "javac" task. So, if I have a libs
dir full of jar files that I want to have set in the classpath, how do I
do this without having to hand-code it? If this isn't possible, would
it be better to add globbing to the "classpath" attribute, or to
"property" task?
--- SER >> Deutsch | Esperanto | Linux | Java | PGP | Pegwit = OK
"When choosing between evils, I always like to take the one I've never
tried before." -- Mae West
Re: New tasks.
Posted by Stefan Bodewig <bo...@bost.de>.
Hi Tom,
take a look at spec/core.html in the CVS repository. You will see
there are some new ideas about extension task. Basically those tasks
wouldn't be built into Ant but loaded on demand.
>>>>> "TC" == Tom Cook <tc...@lisa.com.au> writes:
TC> Are you guys interested in such product-specific tasks being
TC> added to the project?
If you feel comfortable with the Apache license and can live with
other people hacking your code - maybe even Mariusz changing it to be
less Visibroker specific ;-) - why not?
We will probably need some time to figure out how to deal with
extension tasks contributed to Ant. Maybe start a jakarte-ant-tasks
project after the extension mechanism is totally clear?
Finally I'd love to see a list of known extension tasks that are not
part of the jakarta-ant project (and might not even be open sourced)
be added to the Ant distribution - as soon as such tasks are there
that is.
Stefan
Re: New tasks.
Posted by Jose Alberto Fernandez <jo...@us.oracle.com>.
External Lists wrote:
> Proposal for a new task: find
>
> It would look like this:
>
> <find basedir=... includes=... excludes...>
> <task1 ... ${find.file} ${find.dir} ... />
> <task2 ... ${find.file} ${find.dir} ... />
> ...
> </find>
>
It would also be nice to be able to add an id attribute so that
one can nest the finds and have access to the variables:
<find id="find1" basedir=... includes=... excludes...>
<task1 ... ${find1.file} ${find1.dir} ... />
<find id="find2" ... >
<task2 ... ${find1.dir} ${find2.dir} />
...
</find>
...
</find>
>
> Analogous to Unix find <dir> -name <regexp> -exec <task>
>
> Any value? I haven't coded one up yet.
>
> Also, I have a taskdef for javacc; should I post it somewhere?
>
> John
>
> ----- Original Message -----
> From: Tom Cook <tc...@lisa.com.au>
> To: <an...@jakarta.apache.org>
> Sent: Wednesday, May 03, 2000 9:34 PM
> Subject: Re: New tasks.
>
> > On Thu, 4 May 2000, Mariusz Nowostawski wrote:
> >
> > > > It seems to me that, if you just want a tag of the form,
> > > > <idl2java compiler="compilerX" options="compilerXoptions"/>
> > > > then exec is exactly what you're looking for.
> > >
> > > well, I would rather say:
> > > <idl2java compiler="compilerX" options="compilerXoptions">
> > > <include name="${foo.FullOfIDLs.dir}/*.idl">
> > > </idel2java>
> > >
> > > instead of repeating the task for each single idl source, thus exec is
> not
> > > what would do the job nicely.
> > > However, you are right, what I really want is a modified exec, sort of
> > > 'execFor' taks, which is similar to the existing one, but takes
> > > include/exclude tags as well, and effectively performs the given command
> > > with options and with list of files as last argument (with the
> > > options to do it sequentially or at once all files in single command
> > > call). What do you think?
> >
> > I think we are looking for different things in the task; our company is
> > pretty much comitted to visibroker 4, and in fact has gotten it's fingers
> > burnt with some other products, and so is unlikely to use them. If you
> > want generic capability, then I think the execFor task is what you're
> > looking for. Now we just gotta write it :-).
> >
> > > This would solve idl compilation for me just fine ;o) I would sacrify
> the
> > > beauty of having seperate arguments for each option in the task (for
> > > example for orbacus idl compiler) for having a generic mechanism here
> > > instead.
> > >
> > > ----
> > > Most idl compilers are binary executables but
> > > parser generators are usually written in Java (antlr, javacc,
> > > sablecc) and we can take advantage of it. Execing for each grammar file
> > > seperate JVM has obvious drawbacks, thus I see a point in specialized
> > > optional tasks for each of them. What do you think?
> >
> > On the other hand, visibroker's tools, which we use, are all java
> > executables, not native, so I can launch a compiler within the current
> > process; one idea I'm toying with is launching it in a separate thread,
> > although that would require some locking mechanism so you don't end up
> > compiling the implementatins and clients before generating the
> > stubs/skeletons, which would cause obvious problems.
> >
> > Some sort of threading/locking mechanism would be fairly cool, IMHO. Start
> > each task in a separate thread, but also allow locking on arbitrary
> > strings. Something like:
> >
> > <task1 ... lock="lock_a"/>
> > <task2 ... lock="lock_a"/>
> >
> > Then have the project maintain a vector of lock strings. When a tast
> > starts, it checks for a lock attribute. Then it checks to see if the
> > corresponding lock string exists in the vector. If not, it creates it. If
> > it is, then it gets a reference to it. The rest of the function is then
> > synchronized on this lock object.
> >
> > Opinions anyone? Is there any value of doing this apart from saying,
> > 'Cool! We have a multi-threaded build tool!'?
> >
> > Cheerio
> > --
> > Tom Cook - Software Engineer
> >
> > "Never criticize a man until you've walked a mile in his shoes; that way,
> > when you criticize him, you're a mile away and have his shoes."
> > - A froggy bloke on a news group.
> >
> > LISAcorp - www.lisa.com.au
> >
> > --------------------------------------------------
> > 38 Greenhill Rd. Level 3, 228 Pitt Street
> > Wayville, SA, 5034 Sydney, NSW, 2000
> >
> > Phone: +61 8 8272 1555 Phone: +61 2 9283 0877
> > Fax: +61 8 8271 1199 Fax: +61 2 9283 0866
> > --------------------------------------------------
> >
--
------------------------------------------------------------------------
Jose Alberto Fernandez 500 Oracle Parkway, M/S 9op4
Development Manager Redwood Shores, CA 94065
ORACLE Corp. Phone: (650) 506-8830
Java Products Group Fax: (650) 506-7303
Languages & Obj-Relational Tech Email: jofernan@us.oracle.com
Re: New tasks.
Posted by Michael Saunders <mi...@amtec.com>.
John,
I think the find taskdef sounds great. Also, I sure would like to have your
javacc taskdef. I hacked one up myself from the javac taskdef but I left out
most of JavaCC's options so if you have a better one I would love to have it. If
it isn't bad etiquite for this mailing list please post it so that I could use
it until (if) it is incorporated into Ant. If people would object then please
send it to me: mailto:<mi...@amtec.com>
While I'm on the topic of new taskdefs. Does anyone have a taskdef for javah?
How about for CC (I know this is the java world but lets face it sometimes we
have to interface to C through JNI).
Michael
External Lists wrote:
> Proposal for a new task: find
>
> It would look like this:
>
> <find basedir=... includes=... excludes...>
> <task1 ... ${find.file} ${find.dir} ... />
> <task2 ... ${find.file} ${find.dir} ... />
> ...
> </find>
>
> Analogous to Unix find <dir> -name <regexp> -exec <task>
>
> Any value? I haven't coded one up yet.
>
> Also, I have a taskdef for javacc; should I post it somewhere?
>
> John
Re: New tasks.
Posted by External Lists <ex...@ManagedObjects.com>.
> Good idea, I would just suggest that if the result of <find> is
> in find.file and find.dir properties, why nest <task1> and <task2>
> in <find> ? I would rather imagine something like :
>
> <find basedir=... includes=... excludes.../>
> <task1 ... ${find.file} ${find.dir} ... />
> <task2 ... ${find.file} ${find.dir} ... />
Because <taskN> would be invoked for each found file within basedir that
matched includes but did not match excludes, so it makes sense to nest them
within the find task.
John
Re: Find (was: New tasks.)
Posted by External Lists <ex...@ManagedObjects.com>.
Okay, Mariusz. I see your point. You're saying ANT only needs one "visitor
pattern" implementation, and includes/excludes is already present. For
those tasks that don't implement it, they should be extended. I can live
with that, too. It's also simpler than nesting tasks.
-1
John
----- Original Message -----
From: Mariusz Nowostawski <ma...@marni.otago.ac.nz>
To: <an...@jakarta.apache.org>
Sent: Sunday, May 07, 2000 6:34 PM
Subject: Re: Find (was: New tasks.)
>
> >> Proposal for a new task: find
> >> It would look like this:
> >>
> >> <find basedir=... includes=... excludes...>
> >> <task1 ... ${find.file} ${find.dir} ... />
> >> <task2 ... ${find.file} ${find.dir} ... />
> >> ...
> >> </find>
> >>
> >> Analogous to Unix find <dir> -name <regexp> -exec <task>
> [...]
>
> > Good idea, I would just suggest that if the result of <find> is
> > in find.file and find.dir properties, why nest <task1> and <task2>
> > in <find> ? I would rather imagine something like :
>
> > <find basedir=... includes=... excludes.../>
> > <task1 ... ${find.file} ${find.dir} ... />
> > <task2 ... ${find.file} ${find.dir} ... />
> [...]
>
> >> Any value? I haven't coded one up yet.
>
>
> I do not like personally 'find' model to be present in ANT. I like a
> lot, the way processing of my build inputs works currently in ANT - which
> is distinct from traditional 'make' and 'find'-based models.
>
> I cannot see when:
> <task1 ... ${find.file} ${find.dir} ... />
> <task2 ... ${find.file} ${find.dir} ... />
> would be of use? Everywhere the task can take a list of files, it itself
> implements include/exclude model, like javac/delete etc. With find we
> would have two ways of doing the same thing, which I feel would break
> the rule of making things simple. For example if I have to compile
> all my java source files in one directory and then copy them to the
> distribution src directory, in current ANT, with 'no-find-philosophy'
> I do:
>
> 1. compile all java files from _src.dir_
> 2. copy all java files from _src.dir_ to _dist.dir_
>
> with 'find' it usually looks like:
>
> 1. find all the java files from _src.dir_
> 2. compile all what's in ${find.file} ${find.dir}
> 3. copy all what's in ${find.file} ${find.dir} to _dist.dir_
>
> Do not tell me that you do not like the beauty, simplicity and
> the very explicit way of the first (current ANT) model. Everywhere ANT
> lacks the excludes/includes model (like in current exec) it needs
> simple to be extended. Apart from that, in Unix:
> find <dir> -name <regexp> -exec <task>
> <task> is performed sequentially one call per found item. In most cases
> (like in the one with compiling and copying) you do not want the task
> to be performed n times, once per each found item, you want it to be
> performed once with the list of items (which I suppose the propose
> find task would differ from the real
> find <dir> -name <regexp> -exec <task> ).
>
> Do not get me wrong, I love 'find', and it would be not possible to
> have 'make' without it, but I am very happy not to have find in ANT,
> and I do not feel the need for it here either. When do you need find
> task to be used? and with what tasks?
>
> -1
>
> regards
> Mariusz
>
Re: Find (was: New tasks.)
Posted by Mariusz Nowostawski <ma...@marni.otago.ac.nz>.
>> Proposal for a new task: find
>> It would look like this:
>>
>> <find basedir=... includes=... excludes...>
>> <task1 ... ${find.file} ${find.dir} ... />
>> <task2 ... ${find.file} ${find.dir} ... />
>> ...
>> </find>
>>
>> Analogous to Unix find <dir> -name <regexp> -exec <task>
[...]
> Good idea, I would just suggest that if the result of <find> is
> in find.file and find.dir properties, why nest <task1> and <task2>
> in <find> ? I would rather imagine something like :
> <find basedir=... includes=... excludes.../>
> <task1 ... ${find.file} ${find.dir} ... />
> <task2 ... ${find.file} ${find.dir} ... />
[...]
>> Any value? I haven't coded one up yet.
I do not like personally 'find' model to be present in ANT. I like a
lot, the way processing of my build inputs works currently in ANT - which
is distinct from traditional 'make' and 'find'-based models.
I cannot see when:
<task1 ... ${find.file} ${find.dir} ... />
<task2 ... ${find.file} ${find.dir} ... />
would be of use? Everywhere the task can take a list of files, it itself
implements include/exclude model, like javac/delete etc. With find we
would have two ways of doing the same thing, which I feel would break
the rule of making things simple. For example if I have to compile
all my java source files in one directory and then copy them to the
distribution src directory, in current ANT, with 'no-find-philosophy'
I do:
1. compile all java files from _src.dir_
2. copy all java files from _src.dir_ to _dist.dir_
with 'find' it usually looks like:
1. find all the java files from _src.dir_
2. compile all what's in ${find.file} ${find.dir}
3. copy all what's in ${find.file} ${find.dir} to _dist.dir_
Do not tell me that you do not like the beauty, simplicity and
the very explicit way of the first (current ANT) model. Everywhere ANT
lacks the excludes/includes model (like in current exec) it needs
simple to be extended. Apart from that, in Unix:
find <dir> -name <regexp> -exec <task>
<task> is performed sequentially one call per found item. In most cases
(like in the one with compiling and copying) you do not want the task
to be performed n times, once per each found item, you want it to be
performed once with the list of items (which I suppose the propose
find task would differ from the real
find <dir> -name <regexp> -exec <task> ).
Do not get me wrong, I love 'find', and it would be not possible to
have 'make' without it, but I am very happy not to have find in ANT,
and I do not feel the need for it here either. When do you need find
task to be used? and with what tasks?
-1
regards
Mariusz
Re: New tasks.
Posted by Michel CASABIANCA <ca...@sdv.fr>.
Hello
"External Lists" <ex...@ManagedObjects.com> writes:
> Proposal for a new task: find
>
> It would look like this:
>
> <find basedir=... includes=... excludes...>
> <task1 ... ${find.file} ${find.dir} ... />
> <task2 ... ${find.file} ${find.dir} ... />
> ...
> </find>
>
> Analogous to Unix find <dir> -name <regexp> -exec <task>
>
> Any value? I haven't coded one up yet.
>
> Also, I have a taskdef for javacc; should I post it somewhere?
Good idea, I would just suggest that if the result of <find> is
in find.file and find.dir properties, why nest <task1> and <task2>
in <find> ? I would rather imagine something like :
<find basedir=... includes=... excludes.../>
<task1 ... ${find.file} ${find.dir} ... />
<task2 ... ${find.file} ${find.dir} ... />
--
+---------------------------+--------------------------------+
| Michel CASABIANCA | http://www.sdv.fr/pages/casa |
| mailto:casa@sdv.fr | Articles sur Java et XML |
| Développement Java et XML | Applications et Applets de Jeu |
+---------------------------+--------------------------------+
Re: New tasks.
Posted by External Lists <ex...@ManagedObjects.com>.
Proposal for a new task: find
It would look like this:
<find basedir=... includes=... excludes...>
<task1 ... ${find.file} ${find.dir} ... />
<task2 ... ${find.file} ${find.dir} ... />
...
</find>
Analogous to Unix find <dir> -name <regexp> -exec <task>
Any value? I haven't coded one up yet.
Also, I have a taskdef for javacc; should I post it somewhere?
John
----- Original Message -----
From: Tom Cook <tc...@lisa.com.au>
To: <an...@jakarta.apache.org>
Sent: Wednesday, May 03, 2000 9:34 PM
Subject: Re: New tasks.
> On Thu, 4 May 2000, Mariusz Nowostawski wrote:
>
> > > It seems to me that, if you just want a tag of the form,
> > > <idl2java compiler="compilerX" options="compilerXoptions"/>
> > > then exec is exactly what you're looking for.
> >
> > well, I would rather say:
> > <idl2java compiler="compilerX" options="compilerXoptions">
> > <include name="${foo.FullOfIDLs.dir}/*.idl">
> > </idel2java>
> >
> > instead of repeating the task for each single idl source, thus exec is
not
> > what would do the job nicely.
> > However, you are right, what I really want is a modified exec, sort of
> > 'execFor' taks, which is similar to the existing one, but takes
> > include/exclude tags as well, and effectively performs the given command
> > with options and with list of files as last argument (with the
> > options to do it sequentially or at once all files in single command
> > call). What do you think?
>
> I think we are looking for different things in the task; our company is
> pretty much comitted to visibroker 4, and in fact has gotten it's fingers
> burnt with some other products, and so is unlikely to use them. If you
> want generic capability, then I think the execFor task is what you're
> looking for. Now we just gotta write it :-).
>
> > This would solve idl compilation for me just fine ;o) I would sacrify
the
> > beauty of having seperate arguments for each option in the task (for
> > example for orbacus idl compiler) for having a generic mechanism here
> > instead.
> >
> > ----
> > Most idl compilers are binary executables but
> > parser generators are usually written in Java (antlr, javacc,
> > sablecc) and we can take advantage of it. Execing for each grammar file
> > seperate JVM has obvious drawbacks, thus I see a point in specialized
> > optional tasks for each of them. What do you think?
>
> On the other hand, visibroker's tools, which we use, are all java
> executables, not native, so I can launch a compiler within the current
> process; one idea I'm toying with is launching it in a separate thread,
> although that would require some locking mechanism so you don't end up
> compiling the implementatins and clients before generating the
> stubs/skeletons, which would cause obvious problems.
>
> Some sort of threading/locking mechanism would be fairly cool, IMHO. Start
> each task in a separate thread, but also allow locking on arbitrary
> strings. Something like:
>
> <task1 ... lock="lock_a"/>
> <task2 ... lock="lock_a"/>
>
> Then have the project maintain a vector of lock strings. When a tast
> starts, it checks for a lock attribute. Then it checks to see if the
> corresponding lock string exists in the vector. If not, it creates it. If
> it is, then it gets a reference to it. The rest of the function is then
> synchronized on this lock object.
>
> Opinions anyone? Is there any value of doing this apart from saying,
> 'Cool! We have a multi-threaded build tool!'?
>
> Cheerio
> --
> Tom Cook - Software Engineer
>
> "Never criticize a man until you've walked a mile in his shoes; that way,
> when you criticize him, you're a mile away and have his shoes."
> - A froggy bloke on a news group.
>
> LISAcorp - www.lisa.com.au
>
> --------------------------------------------------
> 38 Greenhill Rd. Level 3, 228 Pitt Street
> Wayville, SA, 5034 Sydney, NSW, 2000
>
> Phone: +61 8 8272 1555 Phone: +61 2 9283 0877
> Fax: +61 8 8271 1199 Fax: +61 2 9283 0866
> --------------------------------------------------
>
Re: New tasks.
Posted by Tom Cook <tc...@lisa.com.au>.
On Thu, 4 May 2000, Mariusz Nowostawski wrote:
> > It seems to me that, if you just want a tag of the form,
> > <idl2java compiler="compilerX" options="compilerXoptions"/>
> > then exec is exactly what you're looking for.
>
> well, I would rather say:
> <idl2java compiler="compilerX" options="compilerXoptions">
> <include name="${foo.FullOfIDLs.dir}/*.idl">
> </idel2java>
>
> instead of repeating the task for each single idl source, thus exec is not
> what would do the job nicely.
> However, you are right, what I really want is a modified exec, sort of
> 'execFor' taks, which is similar to the existing one, but takes
> include/exclude tags as well, and effectively performs the given command
> with options and with list of files as last argument (with the
> options to do it sequentially or at once all files in single command
> call). What do you think?
I think we are looking for different things in the task; our company is
pretty much comitted to visibroker 4, and in fact has gotten it's fingers
burnt with some other products, and so is unlikely to use them. If you
want generic capability, then I think the execFor task is what you're
looking for. Now we just gotta write it :-).
> This would solve idl compilation for me just fine ;o) I would sacrify the
> beauty of having seperate arguments for each option in the task (for
> example for orbacus idl compiler) for having a generic mechanism here
> instead.
>
> ----
> Most idl compilers are binary executables but
> parser generators are usually written in Java (antlr, javacc,
> sablecc) and we can take advantage of it. Execing for each grammar file
> seperate JVM has obvious drawbacks, thus I see a point in specialized
> optional tasks for each of them. What do you think?
On the other hand, visibroker's tools, which we use, are all java
executables, not native, so I can launch a compiler within the current
process; one idea I'm toying with is launching it in a separate thread,
although that would require some locking mechanism so you don't end up
compiling the implementatins and clients before generating the
stubs/skeletons, which would cause obvious problems.
Some sort of threading/locking mechanism would be fairly cool, IMHO. Start
each task in a separate thread, but also allow locking on arbitrary
strings. Something like:
<task1 ... lock="lock_a"/>
<task2 ... lock="lock_a"/>
Then have the project maintain a vector of lock strings. When a tast
starts, it checks for a lock attribute. Then it checks to see if the
corresponding lock string exists in the vector. If not, it creates it. If
it is, then it gets a reference to it. The rest of the function is then
synchronized on this lock object.
Opinions anyone? Is there any value of doing this apart from saying,
'Cool! We have a multi-threaded build tool!'?
Cheerio
--
Tom Cook - Software Engineer
"Never criticize a man until you've walked a mile in his shoes; that way,
when you criticize him, you're a mile away and have his shoes."
- A froggy bloke on a news group.
LISAcorp - www.lisa.com.au
--------------------------------------------------
38 Greenhill Rd. Level 3, 228 Pitt Street
Wayville, SA, 5034 Sydney, NSW, 2000
Phone: +61 8 8272 1555 Phone: +61 2 9283 0877
Fax: +61 8 8271 1199 Fax: +61 2 9283 0866
--------------------------------------------------
Re: New tasks.
Posted by Mariusz Nowostawski <ma...@marni.otago.ac.nz>.
> It seems to me that, if you just want a tag of the form,
> <idl2java compiler="compilerX" options="compilerXoptions"/>
> then exec is exactly what you're looking for.
well, I would rather say:
<idl2java compiler="compilerX" options="compilerXoptions">
<include name="${foo.FullOfIDLs.dir}/*.idl">
</idel2java>
instead of repeating the task for each single idl source, thus exec is not
what would do the job nicely.
However, you are right, what I really want is a modified exec, sort of
'execFor' taks, which is similar to the existing one, but takes
include/exclude tags as well, and effectively performs the given command
with options and with list of files as last argument (with the
options to do it sequentially or at once all files in single command
call). What do you think?
This would solve idl compilation for me just fine ;o) I would sacrify the
beauty of having seperate arguments for each option in the task (for
example for orbacus idl compiler) for having a generic mechanism here
instead.
----
Most idl compilers are binary executables but
parser generators are usually written in Java (antlr, javacc,
sablecc) and we can take advantage of it. Execing for each grammar file
seperate JVM has obvious drawbacks, thus I see a point in specialized
optional tasks for each of them. What do you think?
thanks for feedback Tom
Mariusz
Re: New tasks.
Posted by Tom Cook <tc...@lisa.com.au>.
On Thu, 4 May 2000, Mariusz Nowostawski wrote:
> On Thu, 4 May 2000, Tom Cook wrote:
> > Hey guys, I'm newish to ant, and new to ant development. Last night I
> > wrote a task to compile IDL using the Visibroker 4 idl2java tool. This
> > deals with all the options etc. Are you guys interested in such
> > product-specific tasks being added to the project?
>
> That would be cool if that would not depend on specific idl compiler. I
> would imagine the task taking idl compiler name + compiler specific
> options as options (text) and the include/exlude list of idl files to
> work on - it was exactly on my todo list for tommorrow ;o) If your task
> takes the idl compiler as an option (and not rely on
> hardcoded visibroker specific things), I would be interested in getting it
> (as we are using orbacus here) even if blokes from ANT are
> not keen of including it as a part of ANT.
Unfortunately I went to quite a bit of effort to make it visibroker
specific - it takes all the visibroker command-line options as individual
attributes. It seems to me that, if you just want a tag of the form,
<idl2java compiler="compilerX" options="compilerXoptions"/>
then exec is exactly what you're looking for.
> To me though, idlcompile seems perfect as a task, even not an optional
> one, as it does not rely on any other stuff as such.
I disagree here. Despite CORBA 2.3 being a 'standard', there are still
some very major differences between vendors, even more so when you start
moving between only minor revisions of the CORBA spec. This is most
evident when moving between Visibroker 3.4 and 4.0 - there is
compatibility in niether direction.
> True that different
> compilers take different options, but an interoperability between idl
> compilers is not that big deal here, as projects usually depend on single
> ORB anyway.
CORBA 2.3 was designed to make that statement untrue; CORBA has always
aimed at ORB interoperability, but 2.3 is coming close to implementing it.
Besides which, the fact that one tool is imperfect is not a good reason to
make another tool imperfect; we can design in the hope that, one day, the
other tool can be perfect also.
Not that any tool is ever perfect.
> ---
>
> Yesterday I wrote a task to compile EBNF grammar files to parser/lexer
> pair using the SableCC parser generator tool. This deals with some
> options etc. Are you guys interested in such product-specific tasks being
> added to the project? To me it seems to be all right to add it as an
> optional task as it rely on specific jar (conditional compilation as
> with netrexxc). I thought that it would be nice to have it more generic,
> as for example to work with javacc (metamata) parser generator, but in
> contrast to idl compilers parser generators differ in philosophy and it is
> tricky to find a common denominator for them.
Here again, different CORBA products have very different philosophies;
compare the POA, BOA and tnameserv mechanisms, none of which are
compatible with any of the others, and all of which are present in just
two CORBA implementations.
Cheerio
--
Tom Cook - Software Engineer
"Never criticize a man until you've walked a mile in his shoes; that way,
when you criticize him, you're a mile away and have his shoes."
- A froggy bloke on a news group.
LISAcorp - www.lisa.com.au
--------------------------------------------------
38 Greenhill Rd. Level 3, 228 Pitt Street
Wayville, SA, 5034 Sydney, NSW, 2000
Phone: +61 8 8272 1555 Phone: +61 2 9283 0877
Fax: +61 8 8271 1199 Fax: +61 2 9283 0866
--------------------------------------------------
Re: New tasks.
Posted by Mariusz Nowostawski <ma...@marni.otago.ac.nz>.
On Thu, 4 May 2000, Tom Cook wrote:
> Hey guys, I'm newish to ant, and new to ant development. Last night I
> wrote a task to compile IDL using the Visibroker 4 idl2java tool. This
> deals with all the options etc. Are you guys interested in such
> product-specific tasks being added to the project?
That would be cool if that would not depend on specific idl compiler. I
would imagine the task taking idl compiler name + compiler specific
options as options (text) and the include/exlude list of idl files to
work on - it was exactly on my todo list for tommorrow ;o) If your task
takes the idl compiler as an option (and not rely on
hardcoded visibroker specific things), I would be interested in getting it
(as we are using orbacus here) even if blokes from ANT are
not keen of including it as a part of ANT.
To me though, idlcompile seems perfect as a task, even not an optional
one, as it does not rely on any other stuff as such. True that different
compilers take different options, but an interoperability between idl
compilers is not that big deal here, as projects usually depend on single
ORB anyway.
---
Yesterday I wrote a task to compile EBNF grammar files to parser/lexer
pair using the SableCC parser generator tool. This deals with some
options etc. Are you guys interested in such product-specific tasks being
added to the project? To me it seems to be all right to add it as an
optional task as it rely on specific jar (conditional compilation as
with netrexxc). I thought that it would be nice to have it more generic,
as for example to work with javacc (metamata) parser generator, but in
contrast to idl compilers parser generators differ in philosophy and it is
tricky to find a common denominator for them.
regards
Mariusz