ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Cook <tc...@lisa.com.au>
Subject Re: New tasks.
Date Thu, 04 May 2000 00:46:29 GMT
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
--------------------------------------------------


Mime
View raw message