ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kev Jackson <>
Subject Re: classloader for 1.7
Date Thu, 24 Aug 2006 04:25:39 GMT
On Wed, 2006-08-23 at 10:33 +0100, Steve Loughran wrote:
> Peter Reilly wrote:
> > If it is not a little too late, I would like to get a vote
> > on including classloader into ant 1.7.
> > (
> > I have been playing with it the last week or so. It really makes
> > working with antlibs, and scripting different languages very
> > nice. For example: Rather that having a lot of jar files in ~/.ant/lib, I
> > can
> > have a number of directories that contain all that is needed
> > for a particular language and load that into the build file. using a macro
> > 
> >    <macrodef name="load-lang">
> >        <attribute name="lang"/>
> >        <sequential>
> >            <classloader loader="project">
> >                <classpath>
> >                    <fileset dir="${user.home}/script-lang/@{lang}"/>
> >                </classpath>
> >            </classloader>
> >        </sequential>
> >    </macrodef>
> > 
> > This is especially true for working with JDK 1.6 scripting - one needs
> > an extra jar file for each language.
> > 
> > I have been using classloader with netbeans, and my worry before about
> > it messing up the classloader does not seem to be true. In fact, for groovy
> > and ruby the start up cost of the language is done once, and after that
> > scripts run very fast.

Ok, as you guys know, I'm interested in anything that will help
scripting in Java/Ant, so this does interest me *a lot*. My only worry
is how the classloader task is that I have very little knowledge about
all the possible effects changing classloaders can have on
builds/projects.  I know for example that the delegating classloader we
currently have causes strangeness with JUnit (hence the FAQ entry), and
I'd hate to introduce another issue with classloaders that will cause
people to think that Ant simply has classloading problems full stop.

With all my worries aside, from a user perspective, the <macrodef>
example above is about as cool as it gets w.r.t loading a bsf language -
it's exactly what the bsf guys want to be able to do - make java apps
scriptable with minimum fuss.

In netbeans, what is the startup cost?  Does it have a considerable
impact on the startup of the application to include scripting support?

For now I'm +0 - go for it as long as Antoine is happy.  We can try it
in the beta and then if people have issues we pull it from the main
release - I'm certainly not going to veto without having evidence of
widespread discontent from the users.  This will mean however that a
longer beta period would be required so that we can gather sufficient
feedback to evaluate if everything is ok or not.

Personally I want to see this in the release so that we can easily ship
scriptdef based antlibs (with dynamic language of choice :)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message