You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Matt Benson <gu...@yahoo.com> on 2007/05/17 22:14:47 UTC
applyjava
Example name for the task we've talked about before
but have not written for inclusion, the
counter-argument being that the correct thing to do
here would be write a custom task. But there are Java
programs (which shall remain nameless) that are
ridiculously complicated to call API-style due to the
fact that they are meant to be invoked by means of a
main() method, period. I can't say that I see a
reason we can't include such a task in the near
future... anyone offering a different opinion had best
speak up sooner than that. ;)
-Matt
____________________________________________________________________________________Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545433
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: applyjava
Posted by Dominique Devienne <dd...@gmail.com>.
On 5/17/07, Matt Benson <gu...@yahoo.com> wrote:
> Obviously <script> or <for> could be used, but you
Yep.
> know how it is... some orgs can't or won't accept
> dependencies in their buildfiles. Once we get
> somewhere with the auto-install stuff we've talked
> about with Ant + Ivy, that might be easier to handle
> as the user is no longer responsible for setting
> everything up. A build could simply retrieve
> ant-contrib on the fly.
I doubt these same orgs will see auto-download of AntLibs from the
world wild web with a keen eye...
> As for how the proposed <applyjava> relates to <java>,
> I imagine it would extend <java> in almost or exactly
> the same way that <apply> extends <exec>.
Why not, although I see limited need for it. I won't stop you ;-) --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: applyjava
Posted by Steve Loughran <st...@apache.org>.
Matt Benson wrote:
> As for how the proposed <applyjava> relates to <java>,
> I imagine it would extend <java> in almost or exactly
> the same way that <apply> extends <exec>.
makes sense...sometimes there is the need, and you dont always want to
write a new task.
See also <runjava>, which turns resources into arguments for java
http://antbook.cvs.sourceforge.net/antbook/examples/sections/extending/ch17_tasks/runjava/src/org/antbook/tasks/runjar/Runjava.java?view=markup
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: applyjava
Posted by Matt Benson <gu...@yahoo.com>.
--- Dominique Devienne <dd...@gmail.com> wrote:
> On 5/17/07, Matt Benson <gu...@yahoo.com>
> wrote:
> > Example name for the task we've talked about
> before
> > but have not written for inclusion, the
> > counter-argument being that the correct thing to
> do
> > here would be write a custom task. But there are
> Java
> > programs (which shall remain nameless) that are
> > ridiculously complicated to call API-style due to
> the
> > fact that they are meant to be invoked by means of
> a
> > main() method, period. I can't say that I see a
> > reason we can't include such a task in the near
> > future... anyone offering a different opinion had
> best
> > speak up sooner than that. ;)
>
> How does that relate to <java> or <script>? --DD
>
Obviously <script> or <for> could be used, but you
know how it is... some orgs can't or won't accept
dependencies in their buildfiles. Once we get
somewhere with the auto-install stuff we've talked
about with Ant + Ivy, that might be easier to handle
as the user is no longer responsible for setting
everything up. A build could simply retrieve
ant-contrib on the fly.
As for how the proposed <applyjava> relates to <java>,
I imagine it would extend <java> in almost or exactly
the same way that <apply> extends <exec>.
-Matt
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
____________________________________________________________________________________Luggage? GPS? Comic books?
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: applyjava
Posted by Dominique Devienne <dd...@gmail.com>.
On 5/17/07, Matt Benson <gu...@yahoo.com> wrote:
> Example name for the task we've talked about before
> but have not written for inclusion, the
> counter-argument being that the correct thing to do
> here would be write a custom task. But there are Java
> programs (which shall remain nameless) that are
> ridiculously complicated to call API-style due to the
> fact that they are meant to be invoked by means of a
> main() method, period. I can't say that I see a
> reason we can't include such a task in the near
> future... anyone offering a different opinion had best
> speak up sooner than that. ;)
How does that relate to <java> or <script>? --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: applyjava
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 17 May 2007, Matt Benson <gu...@yahoo.com> wrote:
> Example name for the task we've talked about before
> but have not written for inclusion,
+1 for adding one.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org