You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Ken Wood <kw...@i2.com> on 2000/05/12 19:25:47 UTC
a question about the jar task and the javac task...
I've read the documentation, and tried to fetched the FAQ
(with no luck) and can't find the answer. Since I'm new to the list,
forgive me if this has been hashed to death already.
You're welcome to just point me to the right place to look...
1. The jar task doesn't have the '0' option
that 'jar' has, i.e.
jar cvf0 x.jar *.class
creates a jar file "store only; use no ZIP compression."
When I use the Ant jar task, it creates the
jar with the right content, but it's smaller.
Is it compressed? If so, how can I suppress
compression? My understanding is that JDK1.1.x
based apps don't like compressed jar files.
2. While it's not an issue, I wonder if there
is a simple way to suppress the "copying of
support files" that the javac task does.
I suppose enough 'excludes' would do it,
but I'm looking for something simplier...
3. Hey, while I'm at it... Is there a property
that has the CURRENT time? Not the stuff set
with "tstamp" but a continous running value?
When we build, each time we start and end
a step we emit the time. Then as the build
progresses, we have a web page that shows
the progress of the build, including the
elapsed time for each step, and the total
elapsed time...
Re: a question about the jar task and the javac task...
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "KW" == Ken Wood <kw...@i2.com> writes:
KW> Problem is, if we decide to adopt this for all our builds, then I
KW> don't want to be in a mode of maintaining local changes to
KW> software unless it becomes critical...
I fully understand your problem, same here. I'm sorry I cannot offer
a better solution.
Stefan
Re: a question about the jar task and the javac task...
Posted by Ken Wood <kw...@i2.com>.
Stefan Bodewig wrote:
>
> >>>>> "KW" == Ken Wood <kw...@i2.com> writes:
>
> KW> As for the compressed/uncompressed, well, yes, I would like such
> KW> a patch, although if it's going to be in the product pretty soon,
> KW> I could wait.
>
> As I'm not a commiter the functionality doesn't have to show up in the
> distribution at all - even if I sent a patch here.
>
> If this one is really causing a problem for you (I've never had any
> problems with Ant generated JAR files using Blackdown's JDK 1.1.7v3 on
> Linux) and you don't want to "fix" it yourself I can provide you with
> the changes needed.
>
Well, since you pointed me to the right place, I could probably fix
it myself. Problem is, if we decide to adopt this for all our
builds, then I don't want to be in a mode of maintaining local
changes to software unless it becomes critical... We release our
software on multiple OS's (solaris, hpux, aix, NT, etc, etc) so
we have to hit the lowest common demoninator in terms of runtime
compatability.
Thanks again for your feedback.
-ken
Re: a question about the jar task and the javac task...
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "KW" == Ken Wood <kw...@i2.com> writes:
KW> As for the compressed/uncompressed, well, yes, I would like such
KW> a patch, although if it's going to be in the product pretty soon,
KW> I could wait.
As I'm not a commiter the functionality doesn't have to show up in the
distribution at all - even if I sent a patch here.
If this one is really causing a problem for you (I've never had any
problems with Ant generated JAR files using Blackdown's JDK 1.1.7v3 on
Linux) and you don't want to "fix" it yourself I can provide you with
the changes needed.
KW> Is there a particular list I should subscribe to for
KW> announcements about releases and features, or does that happen
KW> here?
This is the right place. All commits get anounced here.
Stefan
Re: a question about the jar task and the javac task...
Posted by Ken Wood <kw...@i2.com>.
Thanks so much!
Yes, a CopyFiles task would make sense,
it would separate two functionalities currently mashed
together.
As for the compressed/uncompressed, well, yes, I would
like such a patch, although if it's going to be
in the product pretty soon, I could wait. I'm going through
some tests and evaluation, and want to move our
organization away from a nightmare of Imakefiles
all the processing necessary to create makefiles
from Imakefiles and then all the overhead of building
with them... But, we still have several products that
are JDK 1.1.7 and JDK 1.1.8 based, so we need that
uncompressed jar capability if we are going to be
adopt 'Ant'.
Is there a particular list I should subscribe to for
announcements about releases and features, or does
that happen here?
Thanks again!
-ken
Stefan Bodewig wrote:
>
> >>>>> "KW" == Ken Wood <kw...@i2.com> writes:
>
> KW> 1. The jar task doesn't have the '0' option that 'jar' has, i.e.
>
> You are right. Both zip and jar will create compressed files.
>
> I propose to add a boolean "compress" attribute to the zip task (jar
> would inherit it from zip) that defaults to true and set the
> OutputStream to ZipOutputStream.DEFLATED or ZipOutputStream.STORED
> according to this option.
>
> This is quite straight forward and I could supply a patch for it.
>
> KW> 2. While it's not an issue, I wonder if there is a simple way to
> KW> suppress the "copying of support files" that the javac task does.
>
Thanks!! Re: A question about "available" and doing conditionals in a
build xml file.
Posted by Ken Wood <kw...@i2.com>.
Yes! Thanks! I did:
<copydir src="common/bin" dest="ishield/scp_df_common/classes_bin/bin"
>
<include name="userreg.*"/>
<exclude name="*.bat" unless="os.is.windows" />
<exclude name="*.sh" if="os.is.windows" />
</copydir>
Stefan Bodewig wrote:
> copydir is derived from MatchingTask, maybe you can use something like
>
> <available file="C:\AUTOEXEC.BAT" property="os.is.windows" />
>
> <copy src="src/bin" dest="dest/bin">
> <exclude name="**/*.bat" unless="os.is.windows" />
> <exclude name="**/*.sh" if="os.is.windows" />
> </copy>
>
Re: A question about "available" and doing conditionals in a build xml file.
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "KW" == Ken Wood <kw...@i2.com> writes:
KW> I don't seem to find much in the documentation on the use of
KW> properties set by 'available' to do conditional things in the
KW> ".xml" file.
Actually the documentation is missing some more of the newer changes
to Ant (for some value of newer). You won't find the nested <exclude>
element inside the <javac> element at all.
The best documentation you can get is the source and the build files
of the Jakarta projects I'm afraid. Contributions to the documentation
are welcome.
KW> Well, I never saw "unless" in any of the documentation....
Neither did I. AFAIK the only things supporting unless are the sub elements
named include and exclude inside tasks derived from
org.apache.tools.ant.taskdefs.MatchingTask - all(?) tasks working on
multiple files that is.
This is the current situation and I don't know whether an unless will
be added to Target or whether it will be dropped from MatchingTask
again because a better way to achieve the same has been found.
KW> For example, I'm building a target to bundle up the files for a
KW> distribution, and on Unix I need to copy some "sh" files into the
KW> 'bin' directory, but on windows I need to copy some "bat" files
KW> into the bin directory.
copydir is derived from MatchingTask, maybe you can use something like
<available file="C:\AUTOEXEC.BAT" property="os.is.windows" />
<copy src="src/bin" dest="dest/bin">
<exclude name="**/*.bat" unless="os.is.windows" />
<exclude name="**/*.sh" if="os.is.windows" />
</copy>
Or you could use exec tasks and set the os attribute - which would
mean an exec task for every flavour of Unix you want to support.
HTH
Stefan
Re: A question about "available" and doing conditionals in a build xml
file.
Posted by Ken Wood <kw...@i2.com>.
Conor MacNeill wrote:
>
> Yes, this is not currently documented. Indeed, the ability to define
> includes and excludes as nested elements rather than attributes is not
> included in the documentation either. It often surprises people. Would you
> like to submit a patch to the documentation :-)?
Once I become more knowledgeable about all the ant facilities
and usage, yes, I might well submit some documentation updates
for consideration.
-ken
Re: A question about "available" and doing conditionals in a build xml file.
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "JDD" == James Duncan Davidson <ja...@eng.sun.com> writes:
JDD> Nit: properties aren't tasks
Somebody should change docs/index.html#tasks then ;-)
JDD> on 5/18/00 2:18 AM, Stefan Bodewig at bodewig@bost.de wrote:
>> Most (all?) people involved agree that some way of conditional
>> compilation - or more generally conditional task execution - is
>> needed, but there are different opinions about how to do this.
JDD> I still think that conditional compilation can be handled inside
JDD> the javac task. :)
If you're talking about include/exclude tags I'm almost convinced they
are sufficient - this means that my projects get along with them quite
well without a need for further logic support from Ant.
What I still really need is a way to specify the include/exclude lists
in an external file to get build files that are more readable.
This doesn't help with the more general problem of conditional task
execution. I get away with conditional target execution (and have
added an unless attribute to target in my private version of Ant).
Stefan
Re: A question about "available" and doing conditionals in a
build xml file.
Posted by James Duncan Davidson <ja...@eng.sun.com>.
on 5/18/00 2:18 AM, Stefan Bodewig at bodewig@bost.de wrote:
> The responses I did get boiled down to "we agree that properties are
> confusing, that there should be some changes and that we don't want to
> make Ant a new programming language".
>
> Let me address the first two points separately.
>
> "properties are confusing":
>
> The property tasks are evaluated in the same order they appear inside
> the XML-File. It doesn't matter whether they are inside targets or not -
> they are executed by the parser before anything else happens.
Nit: properties aren't tasks -- they are just XML tags that happen...
> The main changes are that tasks get instantiated at runtime, just
> before they are actually executed, and are expected to access
> properties through the project. Note there is no mention of the ${}
> construct at all.
Yes, the ${} need to die die die and go away. Or at least the way that they
behaive today.
> Most (all?) people involved agree that some way of conditional
> compilation - or more generally conditional task execution - is
> needed, but there are different opinions about how to do this.
I still think that conditional compilation can be handled inside the javac
task. :)
.duncan
Re: A question about "available" and doing conditionals in a build xml file.
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "KW" == Ken Wood <kw...@i2.com> writes:
KW> Conor MacNeill wrote:
>> Conditional execution of tasks is a topic of considerable debate
>> on the ant list. Many people have a strong desire to avoid
>> creating within ant a new programming language.
>>
>> Conor
KW> I agree 100%. And, I'm new to this arena, so I'm not up to speed
KW> on what's been proposed, debated, etc.
Be prepared to read a rather longish summary of the current
state. Everything should be read with an "if Stefan recalled
correctly" in mind.
I've entered this list by proposing setif and setunless tasks that
should be a more general approach to properties than available about
two month ago.
The proposal has been ignored by most people - probably because
they've been tired to discuss the same issues over and over again,
maybe because of my attitude.
The responses I did get boiled down to "we agree that properties are
confusing, that there should be some changes and that we don't want to
make Ant a new programming language".
Let me address the first two points separately.
"properties are confusing":
The property tasks are evaluated in the same order they appear inside
the XML-File. It doesn't matter whether they are inside targets or not -
they are executed by the parser before anything else happens.
The ${property} thingies get replaced by the parser, there is no
runtime evaluation of these constructs. The if and unless attributes
found in several places work because they get passed the name of an
property not a ${} construct.
"there should be some changes":
Take a look at spec/core.html to see a first cut on the current
discussions state.
The main changes are that tasks get instantiated at runtime, just
before they are actually executed, and are expected to access
properties through the project. Note there is no mention of the ${}
construct at all.
Some things you don't find there:
Most (all?) people involved agree that some way of conditional
compilation - or more generally conditional task execution - is
needed, but there are different opinions about how to do this.
One way is to use properties as flags - this is the way Ant works
right now. If we stick to this, I agree an unless attribute should be
added to Target to complement the if attribute. Sometimes it is easier
to check for the condition you don't want to see.
Another way would be to use an external scripting language and allow
it to modify tasks. The - optional - script task would be a starting
point. This would make Ant depend on the presence of some external
scripting language parser.
The other uses of properties:
Define pathnames or other "constants". This could be done with a
property implementation like the one currently present, it could be
done using a "better" property implementation (where you would have a
File instance for directories ...) or it could be done with XML
entities (which would mean they were immutable).
Define "constants" who's value can only be determined at build time
(current time, CVS revision numbers, ...). I cannot remember anybody
addressing this.
Flags of all kinds like build.compiler to specify which compiler to
use in the javac task. There is a proposal by Sam Ruby to replace
those with some kind of style sheet.
There has been a very active discussion period for two or three weeks
around easter but most of the participants vanished soon
thereafter. Guess their main focus has switched to Tomcat or their
lives again 8^).
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
--------------------------------------------------
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:
>> 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: A question about "available" and doing conditionals in a build xml file.
Posted by Vitaly Stulsky <vi...@yahoo.com>.
> I think tasks that generate files from other files like javac, copy,
> rmic and the not yet available idl2java or javacc should all check
> whether they need to do anything themselves.
I share this point of view. I've written idl2java task for my ORB which
checks whether it needs to recompile IDL. The following after JAVAC
automatically excludes stubs and skeletons from compile list,
cause the file timestamps doesn't change from previous compile.
> 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. I've never been using CORBA myself and don't know whether a
> generic idl2java task with vendor specific implementations (like javac
> is the generic interface to javac and jikes) could be feasible.
It is possible to combine all tasks for different vendors into one task.
As I imagine it will be something like javac-jikes differences in
javac task now. After creating this task for one ORB (idl2java from standard
JDK distribution) users of different ORBs will post their ORB specific code.
As I think this way we can receive good idltojava task for different ORBs.
Vitaly
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Re: A question about "available" and doing conditionals in a build xml file.
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "KW" == Ken Wood <kw...@i2.com> writes:
KW> If I make the compile target depend on the idl2java target, then
KW> every time I compile, the idl2java processing occurs and the
KW> generated java files' time stamps change,
KW> If I could set and TEST a property to see if one of the generated
KW> files was present, I could suppress the idl2java processing, and
KW> solve this problem.
This is where you would need an unless attribute on your target,
right?
I'd prefer another approach where idl2java would be a task of its own
that could check whether it needs to recompile anything at all. What
would you do if one of the generated files still lingered around but
you had changed you IDL files?
I think tasks that generate files from other files like javac, copy,
rmic and the not yet available idl2java or javacc should all check
whether they need to do anything themselves.
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. I've never been using CORBA myself and don't know whether a
generic idl2java task with vendor specific implementations (like javac
is the generic interface to javac and jikes) could be feasible.
As long as there is no unless attribute to targets and there is no
smart idl2java task, let's see what we can do:
1. Make your idl2java target depend on a property that can only be set
on the command line. This way idl2java wouldn't be run unless you
explicitly say so. Not nice but should work.
2. exclude the idl2java generated files from compilation if you know
they've been there before. This way idl2java would be run every time
but the generated files wouldn't be compiled unless needed.
Stefan
Re: A question about "available" and doing conditionals in a build xml
file.
Posted by Ken Wood <kw...@i2.com>.
Conor MacNeill wrote:
>
> Conditional execution of tasks is a topic of considerable debate on the ant
> list. Many people have a strong desire to avoid creating within ant a new
> programming language.
>
> Conor
I agree 100%. And, I'm new to this arena, so
I'm not up to speed on what's been proposed, debated,
etc.
I'm trying to move from an Imakefile / Makefile
universe, and that stuff is a MESS. Full of fragments of
shell script, etc, etc. I have been able to do 95% of what
those Imakefiles did without anything special, and the build
xml file is more more readable.
But, there's the remaining 5%. And that 5% are the tasks
that have some conditional processing. If the build
universe were perfect, we could live without it. But,
I've never encountered a perfect world yet.
When I read about the "available" task,
it made sense that I could set a property to check
to see if something is available. But, if there isn't any
facility to use those properties to conditionally
perform some other task, then what's the point?
For example, we use CORBA. Before the java sources can
be compiled, we need to run a program that does idl to java
processing, creating additional java sources to be compiled.
If I make the compile target depend on the idl2java target,
then every time I compile, the idl2java processing occurs
and the generated java files' time stamps change, so now
ant thinks there are a bunch of files that need to be
recompiled. But the content of those generated files
really didn't change, so there is no reason to
re-compile. If I could set and TEST a property to see if one
of the generated files was present, I could suppress
the idl2java processing, and solve this problem. Next
time I do a "clean", the generated java files would
disappear, the corresponding 'available' property would be false,
and so I'd do the idl2java processing, then the compile.
I can't be the only one with this kind of situation in
a build. But right now, since I can't conditionally
run a java program based on the value of a property,
I have to live with having the idl to java processing happen
every build, causing extra compilation.
Or am I being dumb in this area, and not catching on to
some capability that would do what I want???
Thanks!
-ken
RE: A question about "available" and doing conditionals in a build xml file.
Posted by Conor MacNeill <co...@m64.com>.
> -----Original Message-----
> From: Ken Wood [mailto:kwood@i2.com]
> Sent: Thursday, 18 May 2000 0:53
> To: ant-dev@jakarta.apache.org
> Subject: A question about "available" and doing conditionals in a build
> xml file.
>
>
> I don't seem to find much in the documentation
> on the use of properties set by 'available' to
> do conditional things in the ".xml" file.
>
> For example, while it's not in the documentation I've
> read, I see in the ant build.xml (browsing the repository...)
> that there is an 'exclude unless="xxx.present"' . Well, I never
> saw "unless" in any of the documentation....
Yes, this is not currently documented. Indeed, the ability to define
includes and excludes as nested elements rather than attributes is not
included in the documentation either. It often surprises people. Would you
like to submit a patch to the documentation :-)?
> I wanted to run a java application via the "java" task,
> conditional upon a property that checks to see
> if a file is present. So I tried adding "unless"
> in my call to the java task. Ant didn't like it.
>
> So, I guess my question becomes this - for which tasks
> is "unless" recognized? Is there a plan to add
> "unless" to all the tasks?
"unless" is part of the MatchingTask class and controls the inclusion or
exculsion of files from a directory scan. Thus it can control, for example,
which files in a directory will be included in a compile or which files will
be excluded from a jar file operation.
This facility is not intended to conditionally control the execution of ant
tasks.
I am not aware of any plans to add "unless" attributes to other tasks.
>
> Is there some other way of doing conditionals within
> a build xml file? For example, I'm building a
> target to bundle up the files for a distribution,
> and on Unix I need to copy some "sh" files into
> the 'bin' directory, but on windows I need to
> copy some "bat" files into the bin directory.
> So, I want to have two copies, each conditional
> on the operating system...
>
>
Conditional execution of tasks is a topic of considerable debate on the ant
list. Many people have a strong desire to avoid creating within ant a new
programming language.
Conor
A question about "available" and doing conditionals in a build xml file.
Posted by Ken Wood <kw...@i2.com>.
I don't seem to find much in the documentation
on the use of properties set by 'available' to
do conditional things in the ".xml" file.
For example, while it's not in the documentation I've
read, I see in the ant build.xml (browsing the repository...)
that there is an 'exclude unless="xxx.present"' . Well, I never
saw "unless" in any of the documentation....
I wanted to run a java application via the "java" task,
conditional upon a property that checks to see
if a file is present. So I tried adding "unless"
in my call to the java task. Ant didn't like it.
So, I guess my question becomes this - for which tasks
is "unless" recognized? Is there a plan to add
"unless" to all the tasks?
Is there some other way of doing conditionals within
a build xml file? For example, I'm building a
target to bundle up the files for a distribution,
and on Unix I need to copy some "sh" files into
the 'bin' directory, but on windows I need to
copy some "bat" files into the bin directory.
So, I want to have two copies, each conditional
on the operating system...
Thanks!
-ken
Re: a question about the jar task and the javac task...
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "KW" == Ken Wood <kw...@i2.com> writes:
KW> 1. The jar task doesn't have the '0' option that 'jar' has, i.e.
You are right. Both zip and jar will create compressed files.
I propose to add a boolean "compress" attribute to the zip task (jar
would inherit it from zip) that defaults to true and set the
OutputStream to ZipOutputStream.DEFLATED or ZipOutputStream.STORED
according to this option.
This is quite straight forward and I could supply a patch for it.
KW> 2. While it's not an issue, I wonder if there is a simple way to
KW> suppress the "copying of support files" that the javac task does.
This will disappear rather soon. Most of the current Apache build files
already include an explicit copyfile task where it is needed.
KW> 3. Hey, while I'm at it... Is there a property that has the
KW> CURRENT time?
None I'm aware of. You could always use an exec task to call date
(on Unix that is) or some similar magic.
Stefan