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 2006/11/28 19:39:47 UTC
Re: classloader for 1.7
--- Peter Reilly <pe...@gmail.com> wrote:
> On 10/14/06, Matt Benson <gu...@yahoo.com>
> wrote:
> > --- Peter Reilly <pe...@gmail.com>
> wrote:
> > the uber-antlib could be called ant-contrib!,
> > > I think that this task could belong to
> ant-contrib,
> > > along with some of Rainer's other classloader
> code.
> >
> > Are you volunteering to put it in ac?
>
> I think so, I will need to backport it to
> ant 1.6 (using addPath), or maybe ant 1.5
> (using createPath).
>
Resurrecting this... as Rainer mentioned in his
enhancement request
http://issues.apache.org/bugzilla/show_bug.cgi?id=28228#c0
the purpose of this kind of classloader task is to
allow the inclusion of libraries NOT in $ANT_HOME/lib.
It seems a little funny that in order to avoid
putting things in $ANT_HOME/lib (or .ant/lib, or use
-lib, okay) you must first do the very thing you seek
to avoid in order to make the task accessible that
allows everything else to be accessible (re-read it a
few times if you didn't understand that). By this
logic it seems reasonable to include this task in Ant
core after all; I believe this is where we were headed
before I diverted the conversation with my random
comment about the self-containedness of this task
making it possible to run it as an antlib.
I would like to add the task, with Peter's suggested
refactorings of reusable Resource and Reference
manipulations, for 1.7.0. Are there still objections
before I do this with lazy consensus?
-Matt
> Peter
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
____________________________________________________________________________________
Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: classloader for 1.7
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 28 Nov 2006, Matt Benson <gu...@yahoo.com> wrote:
> manipulations, for 1.7.0. Are there still objections
> before I do this with lazy consensus?
like Peter I recall we decided against oing this for 1.7.0.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: classloader for 1.7
Posted by Peter Reilly <pe...@gmail.com>.
On 11/28/06, Matt Benson <gu...@yahoo.com> wrote:
> --- Peter Reilly <pe...@gmail.com> wrote:
>
> > On 10/14/06, Matt Benson <gu...@yahoo.com>
> > wrote:
> > > --- Peter Reilly <pe...@gmail.com>
> > wrote:
> > > the uber-antlib could be called ant-contrib!,
> > > > I think that this task could belong to
> > ant-contrib,
> > > > along with some of Rainer's other classloader
> > code.
> > >
> > > Are you volunteering to put it in ac?
> >
> > I think so, I will need to backport it to
> > ant 1.6 (using addPath), or maybe ant 1.5
> > (using createPath).
> >
>
> Resurrecting this... as Rainer mentioned in his
> enhancement request
> http://issues.apache.org/bugzilla/show_bug.cgi?id=28228#c0
> the purpose of this kind of classloader task is to
> allow the inclusion of libraries NOT in $ANT_HOME/lib.
> It seems a little funny that in order to avoid
> putting things in $ANT_HOME/lib (or .ant/lib, or use
> -lib, okay) you must first do the very thing you seek
> to avoid in order to make the task accessible that
> allows everything else to be accessible (re-read it a
> few times if you didn't understand that). By this
> logic it seems reasonable to include this task in Ant
> core after all; I believe this is where we were headed
> before I diverted the conversation with my random
> comment about the self-containedness of this task
> making it possible to run it as an antlib.
>
> I would like to add the task, with Peter's suggested
> refactorings of reusable Resource and Reference
> manipulations, for 1.7.0. Are there still objections
> before I do this with lazy consensus?
It was decided not to do this for ant 1.7.0.
My perferred way would be:
1) fix the coreloader code (see
http://issues.apache.org/bugzilla/attachment.cgi?id=18870)
This modifies the ant code so the the original intention of coreloader
actually works. I think that Costin left the ant group before completing
the mods to complete this of ant 1.6.
The effect of this patch would be to have a seperate classloader
that would be used to load tasks/types. By default the loader
is the Project loader, but this can be changed by a build script
using the classloader task.
This could be done in a 1.7.1 timeframe. - it could also be
done for 1.7.0, but as it does change the classloading code
a little, it may be a little risky.
2) modify the classloader task to use the Resource refactoring.
3) later add in Rainer's modifications to allow the classloader task to
modify other classload loaders - the project loader, system loader
and boot loader.
This is a little bit more problematic as modifying these classloaders may
not be desirable - especially if used in the context of an IDE.
Peter
>
> -Matt
>
> > Peter
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail:
> > dev-help@ant.apache.org
> >
> >
>
>
>
>
> ____________________________________________________________________________________
> Want to start your own business?
> Learn how on Yahoo! Small Business.
> http://smallbusiness.yahoo.com/r-index
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org