suggestion : Ant 1.8 full dist to include a 'scripting lang'

[foamdino]

Hi all,

Coming in too work today I was thinking about how although scriptdef
is a very handy way of quickly specifying tasks without having to
compile code, and how it can be used within an antlib, but that no-one
at apachecon asia had used it.

The reasons they gave was:
1 - didn't know about it
2 - normal tasks did what they wanted (or they used maven when they didn't)
3 - no script jars provided so it was a hassle

Personally I think we should at least consider including a 'script'
language with the full dist (starting from 1.8) so that scriptdef
isn't a lame duck out of the box.

I also think that a lot of the code in the current optional tasks
could be re-written using scriptdefs instead and provided as an
antlib.  This would keep the core in Java, but move the more 'scripty'
style of tasks into a more appropriate tool/lang

Examples of tasks that could be more easily written in lang X instead of Java:
- EchoProperties
- Cab
- Rpm
- Most of the source control systems (ccm, svn, vss etc)

I know it's bad form to suggest re-writes of working code, but in
certain cases I think that the amount of code will be reduced, which
in turn should ease maintenance.

Downsides are of course that the implementation language of Ant
changes (core in Java, some optional tasks implemented as scriptdefs +
a. n. other language).

Anyway, please post flames in 3..2..1

;)
Kev

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[alexeys]

+1

I think we need a scriptdef library. Having a standard scripting language
would help too.

- Alexey.

On 9/11/06, Kevin Jackson <foamdino@...> wrote:

>
> Hi all,
>
> Coming in too work today I was thinking about how although scriptdef
> is a very handy way of quickly specifying tasks without having to
> compile code, and how it can be used within an antlib, but that no-one
> at apachecon asia had used it.
>
> The reasons they gave was:
> 1 - didn't know about it
> 2 - normal tasks did what they wanted (or they used maven when they
> didn't)
> 3 - no script jars provided so it was a hassle
>
> Personally I think we should at least consider including a 'script'
> language with the full dist (starting from 1.8) so that scriptdef
> isn't a lame duck out of the box.
>
> I also think that a lot of the code in the current optional tasks
> could be re-written using scriptdefs instead and provided as an
> antlib.  This would keep the core in Java, but move the more 'scripty'
> style of tasks into a more appropriate tool/lang
>
> Examples of tasks that could be more easily written in lang X instead of
> Java:
> - EchoProperties
> - Cab
> - Rpm
> - Most of the source control systems (ccm, svn, vss etc)
>
> I know it's bad form to suggest re-writes of working code, but in
> certain cases I think that the amount of code will be reduced, which
> in turn should ease maintenance.
>
> Downsides are of course that the implementation language of Ant
> changes (core in Java, some optional tasks implemented as scriptdefs +
> a. n. other language).
>
> Anyway, please post flames in 3..2..1
>
> ;)
> Kev
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
Alexey N. Solofnenko trelony at gmail.com
home: http://trelony.cjb.net/
Pleasant Hill, CA (GMT-8 hours usually)

[Stefan Bodewig]

On Tue, 12 Sep 2006, Kevin Jackson <foamdino@...> wrote:

> Personally I think we should at least consider including a 'script'
> language with the full dist (starting from 1.8) so that scriptdef
> isn't a lame duck out of the box.

Biggest problem might be that the language needs to be license
compatible.

> I also think that a lot of the code in the current optional tasks
> could be re-written using scriptdefs instead and provided as an
> antlib.  This would keep the core in Java, but move the more
> 'scripty' style of tasks into a more appropriate tool/lang

I'm not convinced that script languages are more appropriate 8-)

> Downsides are of course that the implementation language of Ant
> changes (core in Java, some optional tasks implemented as scriptdefs
> + a. n. other language).
>
> Anyway, please post flames in 3..2..1

Not a flame.  Even though I personally don't like the idea of
replacing existing tasks, I wouldn't stand in the way.

But an observation.  Gump used to be written in Java and XSLT.  It was
re-written in Python because Python seemed to be more appropriate and
Gump might attract developers from the non-Java parts of the ASF.  The
result today is that the number of active developers has dropped from
about two to about zero.

If we chose a "standard" scripting language for Ant, it means the Ant
developer community must feel comfortable with it.  Comfortable enough
to be able to maintain and review the code.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[foamdino]

> > Personally I think we should at least consider including a 'script'
> > language with the full dist (starting from 1.8) so that scriptdef
> > isn't a lame duck out of the box.
>
> Biggest problem might be that the language needs to be license
> compatible.

Yes I can see this as a problem - sorry didn't consider it before.

>
> > I also think that a lot of the code in the current optional tasks
> > could be re-written using scriptdefs instead and provided as an
> > antlib.  This would keep the core in Java, but move the more
> > 'scripty' style of tasks into a more appropriate tool/lang
>
> I'm not convinced that script languages are more appropriate 8-)
>

fair enough - I knew that this would be the more controversial
suggestion anyway!

> > Downsides are of course that the implementation language of Ant
> > changes (core in Java, some optional tasks implemented as scriptdefs
> > + a. n. other language).
> >
> > Anyway, please post flames in 3..2..1
>
> Not a flame.  Even though I personally don't like the idea of
> replacing existing tasks, I wouldn't stand in the way.
>
> But an observation.  Gump used to be written in Java and XSLT.  It was
> re-written in Python because Python seemed to be more appropriate and
> Gump might attract developers from the non-Java parts of the ASF.  The
> result today is that the number of active developers has dropped from
> about two to about zero.
>

I also think that some Apache projects simply don't care about Gump
(Maven uses continuum for example).  As a data point it's important to
note that the python re-write didn't attract more developers - having
said that if you wanted apache developers I would have thought perl
would have been the safer language (given mod_perl et al).

> If we chose a "standard" scripting language for Ant, it means the Ant
> developer community must feel comfortable with it.  Comfortable enough
> to be able to maintain and review the code.
>

I think if the consensus is that a scripting language for vm should be
shipped with the dist of Ant, then we can have the discussion over
which one at that point - ie cross that bridge when we come to it ;)

Having just said that :

Sun hires JRuby developers :
http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/58c02b63e2c61d21/26c2b6864513c192?lnk=gst&q=Sun+JRuby&rnum=1#26c2b6864513c192

Which is obviously causing a great deal of discussion in the ruby community.

Kev

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jan.Materne]

>> I also think that a lot of the code in the current optional tasks
>> could be re-written using scriptdefs instead and provided as an
>> antlib.  This would keep the core in Java, but move the more
>'scripty'
>> style of tasks into a more appropriate tool/lang
>
>I'm not convinced that script languages are more appropriate 8-)

Me neither. IMHO its easier to do more complicated checks, e.g. if
attribute combination is ok eg.
with check*() methods.
But maybe I am not familiar enough with scripting....



>> Downsides are of course that the implementation language of Ant
>> changes (core in Java, some optional tasks implemented as scriptdefs
>> + a. n. other language).
>>
>> Anyway, please post flames in 3..2..1
>
>Not a flame.  Even though I personally don't like the idea of
>replacing existing tasks, I wouldn't stand in the way.

Thats the fine thing on this list: we dont flame :-)



>But an observation.  Gump used to be written in Java and XSLT.
> It was re-written in Python because Python seemed to be more
>appropriate and Gump might attract developers from the
>non-Java parts of the ASF.  The result today is that the
>number of active developers has dropped from about two to about zero.

Oh - Gump3 is over?


>If we chose a "standard" scripting language for Ant, it means
>the Ant developer community must feel comfortable with it.  
>Comfortable enough to be able to maintain and review the code.

And the scripting language must Ants Java-compliance-mode:
runnable+compilable on JDK1.2.


Jan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Peter Reilly-2]

For ant 1.8, we will support jdk6 javax.script.*
in some fashion.
JDK 6 has javascript (a nobbled version of
rhino) built in - so ant build files will
get that language for free if the they use JDK 6.




On 9/12/06, Jan.Materne@... <Jan.Materne@...> wrote:
>
> >> I also think that a lot of the code in the current optional tasks
> >> could be re-written using scriptdefs instead and provided as an
> >> antlib.


IKK, no!

 This would keep the core in Java, but move the more

> >'scripty'
> >> style of tasks into a more appropriate tool/lang
> >
> >I'm not convinced that script languages are more appropriate 8-)
>
> Me neither. IMHO its easier to do more complicated checks, e.g. if
> attribute combination is ok eg.
> with check*() methods.
> But maybe I am not familiar enough with scripting....
>
>
>
> >> Downsides are of course that the implementation language of Ant
> >> changes (core in Java, some optional tasks implemented as scriptdefs
> >> + a. n. other language).
> >>
> >> Anyway, please post flames in 3..2..1
> >
> >Not a flame.  Even though I personally don't like the idea of
> >replacing existing tasks, I wouldn't stand in the way.
>
> Thats the fine thing on this list: we dont flame :-)
>
>
>
> >But an observation.  Gump used to be written in Java and XSLT.
> > It was re-written in Python because Python seemed to be more
> >appropriate and Gump might attract developers from the
> >non-Java parts of the ASF.  The result today is that the
> >number of active developers has dropped from about two to about zero.

Opps!

Oh - Gump3 is over?
>
>
> >If we chose a "standard" scripting language for Ant,


Not a snowballs change in hell! ;-)



> it means
> >the Ant developer community must feel comfortable with it.
> >Comfortable enough to be able to maintain and review the code.
>
> And the scripting language must Ants Java-compliance-mode:
> runnable+compilable on JDK1.2.


Ant core has to be JDK 1.2 - at least for the moment.
(It is getting difficult to get JDK1.2 to test with....).

Some non-core optional tasks may depend on higher jdk's
- apt is an example, but the policy should be only to
do this if absolutly required.



Jan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[Matt Benson]

--- Kevin Jackson <foamdino@...> wrote:

> > > Personally I think we should at least consider
> including a 'script'
> > > language with the full dist (starting from 1.8)
> so that scriptdef
> > > isn't a lame duck out of the box.
> >
> > Biggest problem might be that the language needs
> to be license
> > compatible.
>
> Yes I can see this as a problem - sorry didn't
> consider it before.
>

Talking about flamebait, I'll toss this out there:  we
could create our own scripting language... with
domain-specific slants if/where applicable... this
would extricate us from any distribution issues, and,
dare I say it, could be fun if we could find ways to
make a DSL that is Ant-focused.  ;)

-Matt

[SNIP]

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Steve Loughran]

Matt Benson wrote:

>
> Talking about flamebait, I'll toss this out there:  we
> could create our own scripting language... with
> domain-specific slants if/where applicable... this
> would extricate us from any distribution issues, and,
> dare I say it, could be fun if we could find ways to
> make a DSL that is Ant-focused.  ;)
>


With macrodef and presetdef ant is almost a scripting language already, no?

We could certainly improve script integration with more than today;
don't know about reworking mainstream distributions. As for Java6, thats
a long way from being mainstream. In the 'enterprise', its java ee 5
that's forcing the java5 upgrade, which people feel about ready for (not
my claim, but from JBoss people)

-steve



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Matt Benson]

--- Steve Loughran <stevel@...> wrote:

> Matt Benson wrote:
>
> >
> > Talking about flamebait, I'll toss this out there:
>  we
> > could create our own scripting language... with
> > domain-specific slants if/where applicable... this
> > would extricate us from any distribution issues,
> and,
> > dare I say it, could be fun if we could find ways
> to
> > make a DSL that is Ant-focused.  ;)
> >
>
>
> With macrodef and presetdef ant is almost a
> scripting language already, no?

Surely.  I think we should reconsider global if/unless
as well.  This would improve the usability of
macrodef, for instance.

-Matt

>
> We could certainly improve script integration with
> more than today;
> don't know about reworking mainstream distributions.
> As for Java6, thats
> a long way from being mainstream. In the
> 'enterprise', its java ee 5
> that's forcing the java5 upgrade, which people feel
> about ready for (not
> my claim, but from JBoss people)
>
> -steve
>
>
>
>

---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@...
> For additional commands, e-mail:
> dev-help@...
>
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[foamdino]

> > > Talking about flamebait, I'll toss this out there:
> >  we
> > > could create our own scripting language... with
> > > domain-specific slants if/where applicable... this
> > > would extricate us from any distribution issues,
> > and,
> > > dare I say it, could be fun if we could find ways
> > to
> > > make a DSL that is Ant-focused.  ;)
> > >

build files are a dsl for Java as Java has no way of extending the language see:

http://defmacro.org/ramblings/lisp.html for the most coherent writing
I've seen on this.

Given that (I anyway) agree with the above, writing our own scripting
language would still be:

a - a lot of fun (+1)
b - probably pointless (-1)
c - unnecessary if we extend ant in other ways (see below) (-0)

> > With macrodef and presetdef ant is almost a
> > scripting language already, no?

not quite but it's getting there - the fact that someone wrote a game
in a build file suggests that it's 90% there!

>
> Surely.  I think we should reconsider global if/unless
> as well.  This would improve the usability of
> macrodef, for instance.
>

+2 (can I do that?) - for 1.8 I think this is a *must* have feature

> -Matt
>
> >
> > We could certainly improve script integration with
> > more than today;
> > don't know about reworking mainstream distributions.
> > As for Java6, thats
> > a long way from being mainstream. In the
> > 'enterprise', its java ee 5
> > that's forcing the java5 upgrade, which people feel
> > about ready for (not
> > my claim, but from JBoss people)
> >

I've just started my first Java5 project (ie before this week I've not
really had to look at the new for loops, <Generics/Template>, or
autoboxing etc).  To be honest it doesn't feel like Java anymore, it
certainly looks a lot more like C# (but then I suppose that was the
intention)

Kev

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Stefan Bodewig]

On Tue, 12 Sep 2006, Kevin Jackson <foamdino@...> wrote:

> As a data point it's important to note that the python re-write
> didn't attract more developers

I think that's because Gump still hasn't managed to prove it's not a
"those Java people" thing.

> - having said that if you wanted apache developers I would have
> thought perl would have been the safer language (given mod_perl et
> al).

http://svn.apache.org/viewvc/httpd/mod_python/

Our infrastructure people love Python as well, so did a few of the
Java developers around Gump when the re-write was decided.  Today
Python isn't as hip as it used to be, probably due to Ruby.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Stefan Bodewig]

On Tue, 12 Sep 2006, Matt Benson <gudnabrsam@...> wrote:

> dare I say it, could be fun if we could find ways to
> make a DSL that is Ant-focused.  ;)

Ant is a DSL, isn't it?

The easiest thing would be a re-implementation of Ant in Common Lisp,
we'd get real macros and a time-tested "scripting" language for free.
and we could get rid of XML:

(project :name "Ant" :default "echo"
  (target :name "echo"
    (echo :message "Hello World")))

Tasks would be functions or macros.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Stefan Bodewig]

On Tue, 12 Sep 2006, Jan Materne <Jan.Materne@...> wrote:

> Oh - Gump3 is over?

Let's call it dormant.

Large parts of Gump are stable, there isn't much need for active
development.  Maven 2 is the most pressing problem and it would either
need (more) support by the Maven community or me sitting down and
implementing an idea Steve has planted (and I wouldn't use Python for
it).

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[foamdino]

On 9/13/06, Stefan Bodewig <bodewig@...> wrote:

> On Tue, 12 Sep 2006, Matt Benson <gudnabrsam@...> wrote:
>
> > dare I say it, could be fun if we could find ways to
> > make a DSL that is Ant-focused.  ;)
>
> Ant is a DSL, isn't it?
>
> The easiest thing would be a re-implementation of Ant in Common Lisp,
> we'd get real macros and a time-tested "scripting" language for free.
> and we could get rid of XML:

+1 ;)

s-expressions are basically a 'better' xml, but implementing Ant in
Common Lisp would be:

a - cool
b - completely barmy (I doubt many Java developers would touch it)
c - a good learning experience

>
> (project :name "Ant" :default "echo"
>   (target :name "echo"
>     (echo :message "Hello World")))
>
> Tasks would be functions or macros.
>

Anyone interested in a CLISP version of Ant?  I've been thinking about
it since I read that defmacro.org article

Kev

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Stefan Bodewig]

On Wed, 13 Sep 2006, Kevin Jackson <foamdino@...> wrote:
> On 9/13/06, Stefan Bodewig <bodewig@...> wrote:
>> On Tue, 12 Sep 2006, Matt Benson <gudnabrsam@...> wrote:

>> (project :name "Ant" :default "echo"
>>   (target :name "echo"
>>     (echo :message "Hello World")))
>>
>> Tasks would be functions or macros.
>
> Anyone interested in a CLISP version of Ant?

You'd be surprised how much less lines of code you'd need when
compared to the Java version, really.

I toyed with the idea when I first read Peter Seibel's "Practical
Common Lisp (online here[1], but it's well worth of buying) and even
managed to get something like the above snippet working, actually more
like

(defparameter *project*
  (project :name "Ant" :default "echo"
    (target :name "echo"
      (echo :message "Hello World"))))
(run-targets *project*)

Will the new BSF release support any Lisp dialect?

Stefan

Footnotes:
[1]  http://www.gigamonkeys.com/book/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[foamdino]

> >> (project :name "Ant" :default "echo"
> >>   (target :name "echo"
> >>     (echo :message "Hello World")))
> >>
> >> Tasks would be functions or macros.
> >
> > Anyone interested in a CLISP version of Ant?
>
> You'd be surprised how much less lines of code you'd need when
> compared to the Java version, really.

No really I wouldn't!  Java is a *very* verbose language, Lisp is
probably one of the least verbose languages (apart from the ())

>
> I toyed with the idea when I first read Peter Seibel's "Practical
> Common Lisp (online here[1], but it's well worth of buying) and even
> managed to get something like the above snippet working, actually more
> like
>
> (defparameter *project*
>   (project :name "Ant" :default "echo"
>     (target :name "echo"
>       (echo :message "Hello World"))))
> (run-targets *project*)
>

I think a problem would be that CLISP Ant would also have to take
build files in two formats (build.xml & build.sexp) so as to be
partially bwc - of course CLISP can compile to native code and
therefore would (in some cases) be easier to install than Ant + JRE

> Will the new BSF release support any Lisp dialect?
>

Not that I know of, but some of the other languages are fairly lispy
(Ruby is sort of known as MatzLisp)

I've been looking at a couple of Lisp-on-jvm things, Kawa, and ABCL,
but Kawa is scheme not lisp, ABCL is alpha/bleeding edge and didn't
actually work (at all).

> Stefan
>
> Footnotes:
> [1]  http://www.gigamonkeys.com/book/

Great book, even if you hate lisp, the anecdotal footnotes are still
interesting & funny

Kev

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Peter Reilly-2]

On 9/13/06, Kevin Jackson <foamdino@...> wrote:

> I've been looking at a couple of Lisp-on-jvm things, Kawa, and ABCL,
> but Kawa is scheme not lisp, ABCL is alpha/bleeding edge and didn't
> actually work (at all).


According to https://scripting.dev.java.net/
SCSI (http://sisc.sourceforge.net/) a scheme implementation
is supported by JDK6 scripting via an engine provided by
https://scripting.dev.java.net/servlets/ProjectDocumentList

As a SideNote, does anyone know the state of the apache BSF
project - it seems to have gone asleep. BSF is usefull for people
that do not use JDK6+ ;-()