You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@bost.de> on 2000/05/18 13:31:07 UTC
Generic tasks for idl2java, javac ... (was Re: A question about "available" ...)
>>>>> "VS" == Vitaly Stulsky <vi...@yahoo.com> writes:
>> There have been idl2java tasks (two of them IIRC) sent to this
>> list during the last two weeks but I recall them to be vendor
>> specific.
VS> It is possible to combine all tasks for different vendors into
VS> one task.
This is what I wanted to hear 8^).
What needs to be thought about is how to handle options that are only
available in specific implementations.
I see several ways to work with them
1. Neglect all options not available in the "standard" which would
probably be the idl2java from Sun's SDK. Those using other vendors
tools won't like this.
2. Add all options possibly there. A maintenance nightmare.
4. Have only one option at all - for the command line.
5. Invent magic properties to trigger some options. This is what the
current jikes implementation does to get additional warnings or error
messages in emacs compatible format. I would rather not use properties
at all.
6. Have individual attributes for all common options and a single
attribute (additionaloptions or so) to be parsed (or ignored) by the
specific implementation.
As it stands I prefer number 6 but maybe others can come up with a
better solution. If we could find consensus on this, I'd love to see
the javac task to use the same mechanism.
Stefan
RE: Generic tasks for idl2java, javac ... (was Re: A question about "available" ...)
Posted by Vitaly Stulsky <vi...@yahoo.com>.
> My personal take is that there are so many ways to go
> here that finding common ground may be hard. I'm perfectly
> happy to have the standard Ant tasks handle 80% of the work,
> and then handle the messy stuff on a one-on-one basis. For
> example, I'm happy to use the "java" task to invoke the
> particular vendor's idl2java tool that we use.
> Perhaps with time the numerous ways to do idl2java will
> be thinned out to a manageable set. Until then, is it
> worth the effort to try to have an all encompassing
> idl2java task? I think not. Each Ant user is probably
> using only one idl2java tool, so for his/her site,
> they can handle it with either the 'java' task, or
> 'exec', or defining a new task.
Okay, but every programmer, who wants to compile IDL
using his compiler has to write his own taskdef. This work
will be performed by multiple ANT users and demands a lot
of efforts and resources. Yes, I understand, it is simple to write
my own taskdef, and when I need other to write other. But
I prefer to reuse software and I don't want to perform work,
which was already done.
IMHO if we'll follow your words, we'll have to remove JIKES
compilation from javac taskdef. It is possible to run JIKES
from EXEC taskdef. But it isn't good way cause we need
to switch between the compilers. What we have to do if
on the market we will see one more compiler?
With the suggested approach I tried to propose set of taskdefs
which will be:
1) Reusable
2) Maintainable
3) Extendable
Current approach with javac taskdef looks good for two or three
compilers, but as I think, we have to be ready for extending
this task for supporting 10+ compilers. idlToJava taskdef could
be good enough to evaluate some approaches for tasks like this.
Thank you in advance,
Vitaly
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Re: Generic tasks for idl2java, javac ... (was Re: A question about
"available" ...)
Posted by Ken Wood <kw...@i2.com>.
And, to add fuel to the fire, in JDK 1.3, Sun's idl2java
has been replaced with "idlj". See their web page for
details.
My personal take is that there are so many ways to go
here that finding common ground may be hard. I'm perfectly
happy to have the standard Ant tasks handle 80% of the work,
and then handle the messy stuff on a one-on-one basis. For
example, I'm happy to use the "java" task to invoke the
particular vendor's idl2java tool that we use.
Perhaps with time the numerous ways to do idl2java will
be thinned out to a manageable set. Until then, is it
worth the effort to try to have an all encompassing
idl2java task? I think not. Each Ant user is probably
using only one idl2java tool, so for his/her site,
they can handle it with either the 'java' task, or
'exec', or defining a new task.
RE: Generic tasks for idl2java, javac ... (was Re: A question about "available" ...)
Posted by Vitaly Stulsky <vi...@yahoo.com>.
> We could use a delegation model instead. The IdlToJava task constructor
> will
> just inspect the corresponding build.compiler.idl property and create
> a corresponding subclass of itself. then it will delegate to it all entry
> point invocations.
> Probably the delegation needs to be designed a little more, but it should
> work.
And what do you think about introspection? All taskdef options mapped to
java class via introspection mechanism. We need to introspect values not
in created class, but in class created in it's constructor. This model
doesn't fit current implementation.
Alternative way will be specifying factory classes in defaults.properties
instead
of direct taskdef classes. This approach can give us flexibility to extend the
taskdef family (taskdefs which shares one name) with new implementations.
Vitaly
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Re: Generic tasks for idl2java, javac ... (was Re: A question about
"available" ...)
Posted by Jose Alberto Fernandez <jo...@us.oracle.com>.
Stefan Bodewig wrote:
> >>>>> "VS" == Vitaly Stulsky <vi...@yahoo.com> writes:
>
> VS> BTW where is third bullet? :o)
>
> Oh well, I should better write an enumeration minor-mode to catch
> these 8^).
>
> >> 4. Have only one option at all - for the command line.
>
> VS> I don't like this one ....
>
> Neither do I.
>
> VS> I see this approach like abstract idlToJava task which has to be
> VS> extended by specific implementation.
>
> The way tasks are handeled right now - and are expected to be handeled
> in the future - would not allow abstract task classes. The static
> factory method you propose doesn't fit into the way Ant works either.
>
> I do agree your approach seems to be the most flexible one but would
> need some changes to the Ant core.
>
We could use a delegation model instead. The IdlToJava task constructor
will
just inspect the corresponding build.compiler.idl property and create
a corresponding subclass of itself. then it will delegate to it all entry
point invocations.
Probably the delegation needs to be designed a little more, but it should
work.
And with that pattern stablish one could do the same for others like
<javac>.
Finally, one could allow in this task to specify something like vendor
options:
<idltojava ... general options ....>
<vendor class="...." option="literal options">
</idltojava>
Meaning that the attribute option will only be set if build.compiler.idl
has the same
value as attribute class.
What do you guys think?
>
> Stefan
--
------------------------------------------------------------------------
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: Generic tasks for idl2java, javac ... (was Re: A question about "available" ...)
Posted by Vitaly Stulsky <vi...@yahoo.com>.
>
> The way tasks are handeled right now - and are expected to be handeled
> in the future - would not allow abstract task classes. The static
> factory method you propose doesn't fit into the way Ant works either.
I kept in mind where writing this that this approach doesn't completely
fit to the current model. We can split this approach to the following
points:
1) Behavior
2) Realization
I think that proposed behavior better than current. Also this approach fits
good for the tasks with multiple possible realizations.
And task realization. It can be selected after behavior approval. I tried
to avoid myself from bicycle reinventing and proposed the way like
ORB class works.
Yes, I do not want to argue about current taskdef realization. I found
it very original and well thought-out. But for idlToJava-like taskdefs may
be better to review the initial behavior and approaches?
> I do agree your approach seems to be the most flexible one but would
> need some changes to the Ant core.
Thank you.
Vitaly
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Re: Generic tasks for idl2java, javac ... (was Re: A question about "available" ...)
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "VS" == Vitaly Stulsky <vi...@yahoo.com> writes:
VS> BTW where is third bullet? :o)
Oh well, I should better write an enumeration minor-mode to catch
these 8^).
>> 4. Have only one option at all - for the command line.
VS> I don't like this one ....
Neither do I.
VS> I see this approach like abstract idlToJava task which has to be
VS> extended by specific implementation.
The way tasks are handeled right now - and are expected to be handeled
in the future - would not allow abstract task classes. The static
factory method you propose doesn't fit into the way Ant works either.
I do agree your approach seems to be the most flexible one but would
need some changes to the Ant core.
Stefan
RE: Generic tasks for idl2java, javac ... (was Re: A question about
"available" ...)
Posted by Tom Cook <tc...@ardec.com.au>.
This is a significant improvement on the method I just proposed...
On Thu, 18 May 2000, Vitaly Stulsky wrote:
[snip]
> I see this approach like abstract idlToJava task which has to be extended by
> specific implementation. It has basic common options and parameters:
> - source idl file
> - destination directory
> - turn on/off the generation POA stubs and skeletons
> - define the symbol
> - include path
> - turn on/off warning
> - verbose mode switch
> - version
> and, of course, virtual launching facility:
> - execute
>
> If specific ORB doesn't support some of this switches - simply ignore them.
> If developer will decide to make his IDL compilation vendor independent he or
> she
> will has to use only standard options.
>
> All realizations has to extend abstract idlToJava. In every realization can be
> realized
> its specific options. But if we use non-standard option by one idl compiler
> option
> and then try to switch compilers we have no guaranties to compile it without
> build errors (this is the price - build parsing error which indicate unsupported
> by ORB
> or incorrect option).
>
> Selected idl compiler is recognized from java 'build.compiler.idl' option.
[snip]
--
Tom Cook - Software Engineer
"The brain is a wonderful organ. It starts functioning the moment you get
up in the morning, and does not stop until you get into the office."
- Robert Frost
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: Generic tasks for idl2java, javac ... (was Re: A question about "available" ...)
Posted by Vitaly Stulsky <vi...@yahoo.com>.
> 1. Neglect all options not available in the "standard" which would
> probably be the idl2java from Sun's SDK. Those using other vendors
> tools won't like this.
I don't like this approach, cause it doesn't allow to use specific ORB features,
which can be critical for developers.
> 2. Add all options possibly there. A maintenance nightmare.
I agree, maintenance cost is not acceptable.
BTW where is third bullet? :o)
> 4. Have only one option at all - for the command line.
I don't like this one ....
> 5. Invent magic properties to trigger some options. This is what the
> current jikes implementation does to get additional warnings or error
> messages in emacs compatible format. I would rather not use properties
> at all.
All compiler specific features resides inside the code and cannot be configured
during the compile time.
> 6. Have individual attributes for all common options and a single
> attribute (additionaloptions or so) to be parsed (or ignored) by the
> specific implementation.
I see this approach like abstract idlToJava task which has to be extended by
specific implementation. It has basic common options and parameters:
- source idl file
- destination directory
- turn on/off the generation POA stubs and skeletons
- define the symbol
- include path
- turn on/off warning
- verbose mode switch
- version
and, of course, virtual launching facility:
- execute
If specific ORB doesn't support some of this switches - simply ignore them.
If developer will decide to make his IDL compilation vendor independent he or
she
will has to use only standard options.
All realizations has to extend abstract idlToJava. In every realization can be
realized
its specific options. But if we use non-standard option by one idl compiler
option
and then try to switch compilers we have no guaranties to compile it without
build errors (this is the price - build parsing error which indicate unsupported
by ORB
or incorrect option).
Selected idl compiler is recognized from java 'build.compiler.idl' option.
The run-time schema seems to me like:
1) idlToJava static constructor recognize selected implementation by examining
property and
instantiate proper descendant class.
2) pass all options from idlToJava task directly to instance of class received
on step 1.
3) if everything okay it is time to execute the idl compiler
Described solution can be interesting approach for the Javac task too.
That's all I wanted to say at the moment.
Thanks,
Vitaly
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Re: Generic tasks for idl2java, javac ... (was Re: A question about
"available" ...)
Posted by Tom Cook <tc...@ardec.com.au>.
On 18 May 2000, Stefan Bodewig wrote:
> >>>>> "VS" == Vitaly Stulsky <vi...@yahoo.com> writes:
>
> >> There have been idl2java tasks (two of them IIRC) sent to this
> >> list during the last two weeks but I recall them to be vendor
> >> specific.
>
> VS> It is possible to combine all tasks for different vendors into
> VS> one task.
I disagree on the practicality of this, but more on that later...
> This is what I wanted to hear 8^).
>
> What needs to be thought about is how to handle options that are only
> available in specific implementations.
>
> I see several ways to work with them
>
> 1. Neglect all options not available in the "standard" which would
> probably be the idl2java from Sun's SDK. Those using other vendors
> tools won't like this.
Choosing your 'standard' tool is not going to be easy. Sun's version is,
IMHO, a bad choice, because it is nothing like compliant with the CORBA
standard, particularly not the current standard. About the only product I
know of which is compliant with the current standard is Visibroker 4.
This, however, is almost completely incompatible with Sun's version and
previous versions of Visibroker, since it now implements the CORBA 2.3
spec, complete with POAs and TIEs, and ditching BOAs. You may still use
BOAs, but what I'm trying to get at is that the command-line syntax is
pretty much entirely different between different versions of one product,
let alone different products, so I don't think this is a feasible
approach, since it will reduce the functionality of every other idl2java
to naught.
> 2. Add all options possibly there. A maintenance nightmare.
I agree. Doing this is bad news.
> 4. Have only one option at all - for the command line.
Possible, but not elegant.
> 5. Invent magic properties to trigger some options. This is what the
> current jikes implementation does to get additional warnings or error
> messages in emacs compatible format. I would rather not use properties
> at all.
Again, doable, and similar to an approach I will propose below, but I'm
not really happy with either of them.
> 6. Have individual attributes for all common options and a single
> attribute (additionaloptions or so) to be parsed (or ignored) by the
> specific implementation.
Again, doable, but the common options are so few and far between that this
option just reduces to being identical to option 4.
> As it stands I prefer number 6 but maybe others can come up with a
> better solution. If we could find consensus on this, I'd love to see
> the javac task to use the same mechanism.
This is one of the better ways of doing it, but let me put up a number 7.
Please remember, as you read this, that I'm not happy about it, but that
it is, I think, a way of dealing with a proliferation of products.
There are many CORBA implementations, all of which have tools with
different command-line syntax, none of which (to my knowledge) are
interoperable (despite the idealism of the standard) and most of which use
different Java mappings of the IDL language. I think, for these reasons,
that, although these products all fall into the general enterprise
infrastructure domain, they are not really all the same technology. They
all have similarities, but they are not readlly compliant to a standard,
certainly not compliant to the same version of that standard (and minor
revisions of this standard are incompatible), and therefore are not the
same technology. It seems to me, then, that there is not a good reason to
have a Task derivative which attempts to provide an interface to all of
them. There is nothing to be gained by such an attempt, excepting that it
reduces the overall complexity of the build tool. It does, however, have
the potential to make one class incredibly more complex, if an attempt is
made to deal with the features of every product. For these reasons, I
propose a task for each idl2java implementation someone happens to want to
use (ie. when you want to use it, you write it and hopefully contribute it
back to the project) and it goes in some optional package.
Like I said, I'm not happy with the proliferation of code this generates,
but I think it's a way of dealing with the mass of incompatible tools out
there.
Sorry 'bout the essay...
--
Tom Cook - Software Engineer
"The brain is a wonderful organ. It starts functioning the moment you get
up in the morning, and does not stop until you get into the office."
- Robert Frost
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
--------------------------------------------------