DO NOT REPLY [Bug 24122] - Other Compilers

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24122

Other Compilers





--- Additional Comments From [EMAIL PROTECTED]  2003-10-27 05:47 ---
go to ant-contrib.sf.net site. download the cpp tasks (or build them from CVS),
taskdef them and then use them.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

ejbclientjar task - separate project?

[Per Olesen]

Hi,

The bugzilla bug 23396 (enhancement) with a new "ejbclientjar" task has not 
been touched by anyone yet.

I've been wondering if I instead should do what many others have done, namely 
creating a project at sf.net and place the new task there, and then simply 
get it referenced from "External Tools and Tasks" ?

I still do think the task should be a integrated part of ant (though optional 
task) because it is a part of J2EE/EJB-development, which ant already 
contains some tasks for.

But I'm having trouble keeping up with the dev-ant-list. This is a *very* high 
traffic list (you are working hard guys :-), and currently I'm only following 
the list to see if anyone should start looking at the task.

What do you committers say? Would you rather like the task inside ant, or 
should I just take it to sf.net instead?

Regards, Per

-- 
Per Olesen @ Nordija A/S - www.nordija.com - main#: +45 70 20 25 10
email: [EMAIL PROTECTED] - cell#: +45 23 38 95 81


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24143] New: - ejbjar verify not working with borland appserver 5.2.1

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24143

ejbjar verify not working with borland appserver 5.2.1

   Summary: ejbjar verify not working with borland appserver 5.2.1
   Product: Ant
   Version: 1.5.4
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


the optional task for ejbs with appserver 5.2.1 in class BorlandDeploymentTool 
in method verifyBorlandJarV5 sets a parameter -VBJclasspath that is not valid. 
in this version of the borland iastool the parameter has to be -classpath.
Else verify wont work correctly.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tale from the front: macrodef nesting

[Jose Alberto Fernandez]

> From: Steve Cohen [mailto:[EMAIL PROTECTED] 
> 
> I am now trying to experiment with some of the new features 
> of ant 1.6.  Here's a real-world example of the difficulties 
> of trying to replace antcalls with macrodefs.
> 
> Given the following definitions, notice that I am trying to 
> nest a call to the macrodef make.precompiled.web.xml inside a 
> call to the macrodef make.se.war.
> 
> This is failing because I am trying to use the ATTRIBUTE 
> war.webxml inside the ELEMENT precompile which contains a 
> call to the nested macrodef make.precompiled.web.xml.
> 

The issue is not that you are calling make.precompile.web.xml,
the issue is that you are using ${war.webxml} at a point where
there is no property (nor attribute) called war.webxml defined.
If you look at your target make.admin.war there is no property
or defined called war.webxml at that point, so you cannot just
look inside the task implementation and assume that it may exist
be the time is half way executing (that is too late, you need it
at the point of the call to make.se.war.

> I could easily fix this by substituting the actual value of 
> the war.webxml attribute for the ${war.webxml} token.  But 
> then I lose the advantage of defining this in a single place.
> 
> Or I can create properties in the macrodef and pass them 
> around, but that feels wrong too.  
> 

What you should do is define this in a property on the target
and they use that property to expand the value in all the
places that is needed.

> Maybe there should be some mechanism for allowing inner 
> macrodefs for inheriting attributes from an outer macrodef.  
> Maybe elements should be able to be defined with nested 
> attributes.  Or something.
> 

This will not solve your problem. Your problem is that you
are using ${war.webxml} on target make.admin.war and there
is no property defined at that point in time.

Jose Alberto

> But this experience with trying to use this feature leads me 
> to the feeling that using the same notation for macrodef 
> attributes and ant properties is not a good thing.  It will 
> definitely cause confusion.  At a minimum more documentation 
> of this is required.
> 
> 
> 
> 
> 
> 
>   target="create.precompiled.web.xml">
> 
>  value="${dest.web.xml}"/>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
>  
>  
> 
> 
> 
>   token="#build#"   
> value="${project.version}.${project.maintenance.build}.${proje
ct.fix.build}"/>
>   webxml="${war.webxml}"
>  basedir="${war.basedir}">
> 
> 
> 
>  
> 
> 
>depends="make.precompilation"
>work.dir="${dir.admin.ear}"
>
> war.webxml="${dir.build.precomp.webxml}/${admin.web.xml}"
>war.basedir="${dir.admin.ear}/temp"
>war.destfile="${dir.admin.ear}/war/${admin.war}">
>
>
> src.web.xml="${dir.src.web.xmls}/${admin.web.xml}"
>dest.web.xml="${war.webxml}"
>/>
>
>
>
>
>
>
>
>
> 
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tale from the front: macrodef nesting

[Steve Cohen]

You're correct about working around this problem.  However, I think it's
still a problem that the same
${identifier} notation can either indicate a macrodef attribute or an
ant property with completely different times of resolution.

In other words, the line of warning in the ant manual --

"This attribute is placed in the body of the templated task using the
ant property notation - ${attribute name}. Note that is not an actual
ant property"

--will certainly confuse users and may therefore indicate a problem in
design.



-Original Message-
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 27, 2003 5:37 AM
To: Ant Developers List
Subject: RE: Tale from the front: macrodef nesting


> From: Steve Cohen [mailto:[EMAIL PROTECTED]
> 
> I am now trying to experiment with some of the new features
> of ant 1.6.  Here's a real-world example of the difficulties 
> of trying to replace antcalls with macrodefs.
> 
> Given the following definitions, notice that I am trying to
> nest a call to the macrodef make.precompiled.web.xml inside a 
> call to the macrodef make.se.war.
> 
> This is failing because I am trying to use the ATTRIBUTE
> war.webxml inside the ELEMENT precompile which contains a 
> call to the nested macrodef make.precompiled.web.xml.
> 

The issue is not that you are calling make.precompile.web.xml,
the issue is that you are using ${war.webxml} at a point where
there is no property (nor attribute) called war.webxml defined.
If you look at your target make.admin.war there is no property
or defined called war.webxml at that point, so you cannot just
look inside the task implementation and assume that it may exist
be the time is half way executing (that is too late, you need it
at the point of the call to make.se.war.

> I could easily fix this by substituting the actual value of 
> the war.webxml attribute for the ${war.webxml} token.  But 
> then I lose the advantage of defining this in a single place.
> 
> Or I can create properties in the macrodef and pass them 
> around, but that feels wrong too.  
> 

What you should do is define this in a property on the target
and they use that property to expand the value in all the
places that is needed.

> Maybe there should be some mechanism for allowing inner 
> macrodefs for inheriting attributes from an outer macrodef.  
> Maybe elements should be able to be defined with nested 
> attributes.  Or something.
> 

This will not solve your problem. Your problem is that you
are using ${war.webxml} on target make.admin.war and there
is no property defined at that point in time.

Jose Alberto

> But this experience with trying to use this feature leads me 
> to the feeling that using the same notation for macrodef 
> attributes and ant properties is not a good thing.  It will 
> definitely cause confusion.  At a minimum more documentation 
> of this is required.
> 
> 
> 
> 
> 
> 
>   target="create.precompiled.web.xml">
> 
>  value="${dest.web.xml}"/>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
>  
>  
> 
> 
> 
>   token="#build#"   
> value="${project.version}.${project.maintenance.build}.${proje
ct.fix.build}"/>
>   webxml="${war.webxml}"
>  basedir="${war.basedir}">
> 
> 
> 
>  
> 
> 
>depends="make.precompilation"
>work.dir="${dir.admin.ear}"
>
> war.webxml="${dir.build.precomp.webxml}/${admin.web.xml}"
>war.basedir="${dir.admin.ear}/temp"
>war.destfile="${dir.admin.ear}/war/${admin.war}">
>
>
> src.web.xml="${dir.src.web.xmls}/${admin.web.xml}"
>dest.web.xml="${war.webxml}"
>/>
>
>
>
>
>
>
>
>
> 
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tale from the front: macrodef nesting

[Dominique Devienne]

> From: Steve Cohen [mailto:[EMAIL PROTECTED]
> 
> You're correct about working around this problem.  However, I think it's
> still a problem that the same
> ${identifier} notation can either indicate a macrodef attribute or an
> ant property with completely different times of resolution.
> 
> In other words, the line of warning in the ant manual --
> 
> "This attribute is placed in the body of the templated task using the
> ant property notation - ${attribute name}. Note that is not an actual
> ant property"
> 
> --will certainly confuse users and may therefore indicate a problem in
> design.

I argued long and hard on Ant-dev against this overloading of the meaning of
${name}, to no avail. Glad to see I'm not alone in this thinking. But then
again, 's subtleties might just be showing the limits of my own
abilities to grasp context-dependent behavior, when sharper people
apparently have no such limitations. --DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tale from the front: macrodef nesting

[Steve Cohen]

Sorry to say I wasn't involved in the discussion at that time.  What
were the arguments against using an alternative notation?

-Original Message-
From: Dominique Devienne [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 27, 2003 9:33 AM
To: 'Ant Developers List'
Subject: RE: Tale from the front: macrodef nesting


> From: Steve Cohen [mailto:[EMAIL PROTECTED]
> 
> You're correct about working around this problem.  However, I think 
> it's still a problem that the same ${identifier} notation can either 
> indicate a macrodef attribute or an ant property with completely 
> different times of resolution.
> 
> In other words, the line of warning in the ant manual --
> 
> "This attribute is placed in the body of the templated task using the 
> ant property notation - ${attribute name}. Note that is not an actual 
> ant property"
> 
> --will certainly confuse users and may therefore indicate a problem in

> design.

I argued long and hard on Ant-dev against this overloading of the
meaning of ${name}, to no avail. Glad to see I'm not alone in this
thinking. But then again, 's subtleties might just be showing
the limits of my own abilities to grasp context-dependent behavior, when
sharper people apparently have no such limitations. --DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional/sitraka ClassFileTest.java

[antoine]

antoine 2003/10/27 10:29:53

  Modified:src/testcases/org/apache/tools/ant/taskdefs/optional/sitraka
ClassFileTest.java
  Log:
  Make org.apache.tools.ant.taskdefs.optional.sitraka.ClassFileTest pass under
  JDK 1.2
  PR: 23919
  Submitted by: Martijn Kruithof (ant at kruithof dot xs4all dot nl)
  
  Revision  ChangesPath
  1.8   +6 -1  
ant/src/testcases/org/apache/tools/ant/taskdefs/optional/sitraka/ClassFileTest.java
  
  Index: ClassFileTest.java
  ===
  RCS file: 
/home/cvs/ant/src/testcases/org/apache/tools/ant/taskdefs/optional/sitraka/ClassFileTest.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- ClassFileTest.java10 Feb 2003 14:14:54 -  1.7
  +++ ClassFileTest.java27 Oct 2003 18:29:53 -  1.8
  @@ -65,6 +65,7 @@
* Nothing special about this testcase...
*
* @author mailto:[EMAIL PROTECTED]">Stephane Bailliez
  + * @author mailto:[EMAIL PROTECTED]">Martijn Kruithof
*/
   public class ClassFileTest extends TestCase {
   public ClassFileTest(String s) {
  @@ -80,7 +81,11 @@
   assertEquals("ClassFileTest.java", clazzfile.getSourceFile());
   MethodInfo[] methods = clazzfile.getMethods();
   assertEquals(3, methods.length);
  -assertHasMethod("void ()", 2, methods);
  +if (JavaEnvUtils.isJavaVersion(JavaEnvUtils.JAVA_1_2)) {
  +assertHasMethod("void ()", 1, methods);
  +} else {
  +assertHasMethod("void ()", 2, methods);
  +}
   assertHasMethod("void testTwoLines()", 2, methods);
   assertHasMethod("void testOneLine()", 3, methods);
   }
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional/sitraka ClassFileTest.java

[antoine]

antoine 2003/10/27 10:32:13

  Modified:src/testcases/org/apache/tools/ant/taskdefs/optional/sitraka
Tag: ANT_16_BRANCH ClassFileTest.java
  Log:
  Merge from HEAD
  Prevent ClassFileTest from failing under JDK 1.2
  PR: 23919
  Submitted by: Martijn Kruithof
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.7.2.1   +6 -1  
ant/src/testcases/org/apache/tools/ant/taskdefs/optional/sitraka/ClassFileTest.java
  
  Index: ClassFileTest.java
  ===
  RCS file: 
/home/cvs/ant/src/testcases/org/apache/tools/ant/taskdefs/optional/sitraka/ClassFileTest.java,v
  retrieving revision 1.7
  retrieving revision 1.7.2.1
  diff -u -r1.7 -r1.7.2.1
  --- ClassFileTest.java10 Feb 2003 14:14:54 -  1.7
  +++ ClassFileTest.java27 Oct 2003 18:32:13 -  1.7.2.1
  @@ -65,6 +65,7 @@
* Nothing special about this testcase...
*
* @author mailto:[EMAIL PROTECTED]">Stephane Bailliez
  + * @author mailto:[EMAIL PROTECTED]">Martijn Kruithof
*/
   public class ClassFileTest extends TestCase {
   public ClassFileTest(String s) {
  @@ -80,7 +81,11 @@
   assertEquals("ClassFileTest.java", clazzfile.getSourceFile());
   MethodInfo[] methods = clazzfile.getMethods();
   assertEquals(3, methods.length);
  -assertHasMethod("void ()", 2, methods);
  +if (JavaEnvUtils.isJavaVersion(JavaEnvUtils.JAVA_1_2)) {
  +assertHasMethod("void ()", 1, methods);
  +} else {
  +assertHasMethod("void ()", 2, methods);
  +}
   assertHasMethod("void testTwoLines()", 2, methods);
   assertHasMethod("void testOneLine()", 3, methods);
   }
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23919] - [PATCH] ClassFileTest with jdk 1.2.2

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23919

[PATCH] ClassFileTest with jdk 1.2.2

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |1.6



--- Additional Comments From [EMAIL PROTECTED]  2003-10-27 18:36 ---
ClassFileTest change also submitted with a slight variation so that it does not
fail under JDK 1.4. Thanks Martijn.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional/sitraka ClassFileTest.java

[Martijn Kruithof]

Hi
I also verified my patch against jdk 1.4.2 and IBM jdk 1.4.1 and am sure 
it keeps running.
The numerals in assertHasMethod are lower limits according to the test 
case, so the if is not necessery and furthermore makes in necessary to 
also verify again against jdk 1.3 and ibm jdk's. Furthermore it may 
become lower with future java versions again. When looking at the code 
one would not necessarily expect more than one line in the method (empty 
constructor). Therefore I had not put the if statement in there.

Kind Regards, Martijn
[EMAIL PROTECTED] wrote:
antoine 2003/10/27 10:32:13
 Modified:src/testcases/org/apache/tools/ant/taskdefs/optional/sitraka
   Tag: ANT_16_BRANCH ClassFileTest.java
 Log:
 Merge from HEAD
 Prevent ClassFileTest from failing under JDK 1.2
 PR: 23919
 Submitted by: Martijn Kruithof
 
 Revision  ChangesPath
 No   revision
 No   revision
 1.7.2.1   +6 -1  ant/src/testcases/org/apache/tools/ant/taskdefs/optional/sitraka/ClassFileTest.java
 
 Index: ClassFileTest.java
 ===
 RCS file: /home/cvs/ant/src/testcases/org/apache/tools/ant/taskdefs/optional/sitraka/ClassFileTest.java,v
 retrieving revision 1.7
 retrieving revision 1.7.2.1
 diff -u -r1.7 -r1.7.2.1
 --- ClassFileTest.java	10 Feb 2003 14:14:54 -	1.7
 +++ ClassFileTest.java	27 Oct 2003 18:32:13 -	1.7.2.1
 @@ -65,6 +65,7 @@
   * Nothing special about this testcase...
   *
   * @author mailto:[EMAIL PROTECTED]">Stephane Bailliez
 + * @author mailto:[EMAIL PROTECTED]">Martijn Kruithof
   */
  public class ClassFileTest extends TestCase {
  public ClassFileTest(String s) {
 @@ -80,7 +81,11 @@
  assertEquals("ClassFileTest.java", clazzfile.getSourceFile());
  MethodInfo[] methods = clazzfile.getMethods();
  assertEquals(3, methods.length);
 -assertHasMethod("void ()", 2, methods);
 +if (JavaEnvUtils.isJavaVersion(JavaEnvUtils.JAVA_1_2)) {
 +assertHasMethod("void ()", 1, methods);
 +} else {
 +assertHasMethod("void ()", 2, methods);
 +}
  assertHasMethod("void testTwoLines()", 2, methods);
  assertHasMethod("void testOneLine()", 3, methods);
  }
 
 
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional/sitraka ClassFileTest.java

[Antoine Levy-Lambert]

You are right Martijn, I will revert to your original patch.
Cheers,
Antoine

-Ursprungliche Nachricht-
Von: Martijn Kruithof [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 27. Oktober 2003 20:05
An: Ant Developers List
Betreff: Re: cvs commit:
ant/src/testcases/org/apache/tools/ant/taskdefs/optional/sitraka
ClassFileTest.java


Hi

I also verified my patch against jdk 1.4.2 and IBM jdk 1.4.1 and am sure
it keeps running.
The numerals in assertHasMethod are lower limits according to the test
case, so the if is not necessery and furthermore makes in necessary to
also verify again against jdk 1.3 and ibm jdk's. Furthermore it may
become lower with future java versions again. When looking at the code
one would not necessarily expect more than one line in the method (empty
constructor). Therefore I had not put the if statement in there.

Kind Regards, Martijn

[EMAIL PROTECTED] wrote:

>antoine 2003/10/27 10:32:13
>
>  Modified:src/testcases/org/apache/tools/ant/taskdefs/optional/sitraka
>Tag: ANT_16_BRANCH ClassFileTest.java
>  Log:
>  Merge from HEAD
>  Prevent ClassFileTest from failing under JDK 1.2
>  PR: 23919
>  Submitted by: Martijn Kruithof
>
>  Revision  ChangesPath
>  No   revision
>  No   revision
>  1.7.2.1   +6 -1
ant/src/testcases/org/apache/tools/ant/taskdefs/optional/sitraka/ClassFileTe
st.java
>
>  Index: ClassFileTest.java
>  ===
>  RCS file:
/home/cvs/ant/src/testcases/org/apache/tools/ant/taskdefs/optional/sitraka/C
lassFileTest.java,v
>  retrieving revision 1.7
>  retrieving revision 1.7.2.1
>  diff -u -r1.7 -r1.7.2.1
>  --- ClassFileTest.java   10 Feb 2003 14:14:54 -  1.7
>  +++ ClassFileTest.java   27 Oct 2003 18:32:13 -  1.7.2.1
>  @@ -65,6 +65,7 @@
>* Nothing special about this testcase...
>*
>* @author mailto:[EMAIL PROTECTED]">Stephane Bailliez
>  + * @author mailto:[EMAIL PROTECTED]">Martijn
Kruithof
>*/
>   public class ClassFileTest extends TestCase {
>   public ClassFileTest(String s) {
>  @@ -80,7 +81,11 @@
>   assertEquals("ClassFileTest.java", clazzfile.getSourceFile());
>   MethodInfo[] methods = clazzfile.getMethods();
>   assertEquals(3, methods.length);
>  -assertHasMethod("void ()", 2, methods);
>  +if (JavaEnvUtils.isJavaVersion(JavaEnvUtils.JAVA_1_2)) {
>  +assertHasMethod("void ()", 1, methods);
>  +} else {
>  +assertHasMethod("void ()", 2, methods);
>  +}
>   assertHasMethod("void testTwoLines()", 2, methods);
>   assertHasMethod("void testOneLine()", 3, methods);
>   }
>
>
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AL task anyone?

[Alexey N. Solofnenko]

There seems one task missing from .Net tasks -  any plans to add it? 
Should I file a bug report?

- Alexey.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24162] New: - Add option to prevent Ant from blocking on exec task process

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24162

Add option to prevent Ant from blocking on exec task process

   Summary: Add option to prevent Ant from blocking on exec task
process
   Product: Ant
   Version: 1.5.3
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I'm in need of a way to launch an O.S. specific script (via exec or similar
task) and have Ant continue to run to completion without blocking for the
process to complete. This is becoming problematic as we use exec to start our
EJB server (and our web server). When Ant hangs around as a separate process and
waits for the server to finish. It becomes a problem seeing a stack trace from
the launched process without Ant's stack trace getting in the way among other
things. Ultimately what I'm looking for is a way to  and forget it
whithout Ant intercepting in/out streams.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AL task anyone?

[Steve Loughran]

Alexey N. Solofnenko wrote:
There seems one task missing from .Net tasks -  any plans to add it? 
Should I file a bug report?
the process is that the .net tasks are being written on demand, as and 
when the authors need them. So if you need an AL task, now would be a 
good time to write it.

I do agree, it would help round off the set, that and ...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24162] - Add option to prevent Ant from blocking on exec task process

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24162

Add option to prevent Ant from blocking on exec task process

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2003-10-27 20:08 ---
You need Ant1.6 and its spawn option.

Remember, always update your code before filing enhancement or bug reports, as
the problems may already have been addressed :)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24166] New: - CCUpdate.java should use -force parameter to 'cleartool update'

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24166

CCUpdate.java should use -force parameter to 'cleartool update'

   Summary: CCUpdate.java should use -force parameter to 'cleartool
update'
   Product: Ant
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Currently, the CCUpdate.java doesn't add '-force' as a parameter to the 
cleartool update command. This may result in the ccupdate-task waiting 
(forever) for user input. The -force parameter is meant to suppress 
confirmation prompts, which is appropiate for an automated task. I think it 
should be added as a default parameter to cleartool update. This would mean 
adding a variable m_Force = true to the CCUpdate-class and adding the necessary 
code (setForce-method and adapting checkOptions). Or maybe it should even be 
standard and non-overridable, since confirmation by the user is impossible 
anyway...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]