You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by co...@covalent.net on 2002/05/23 18:43:20 UTC
[PATCH] Definer to allow types/tasks from the same jar to work
This patch is essential for me ( in jakarta-tomcat-connectors project, I
suspect other jakarta projects are affected as well ). I'm willing to make
changes - but I need this functionality in ant1.5 in a form or another.
For a use-case, look at the cpp-tasks on sourceforge or any other
user-tasks that uses both types and tasks.
In ant1.4, this only works if the code is in the CLASSPATH ( or
ant/lib ). It is possible to load multiple tasks that will work togheter,
or multiple types - but it is not possible to have the tasks ant types.
This is because different class loaders are used. A <taskdef> can load
multiple tasks with the same loader if file or resource attribute is
used.
With this fix, we allow the user to specify that he wants different
<taskdefs> and <typedefs> to use the same classloader instance, so the
tasks/types can use each other. It is backward and forward compatible -
unless the user explicitely specify he wants the new behavior, the
old behavior will be used with absolutely no change.
It is possible to use the same build.xml with both ant1.4 and ant1.5,
as long as in 1.4 you put the .jar in ant/lib ( that's the
only solution in 1.4 to solve this problem ). Asking for loader reuse
can also be done with an explicit attribute.
Costin
Index: taskdefs/Definer.java
===================================================================
RCS file: /home/cvs/jakarta-ant/src/main/org/apache/tools/ant/taskdefs/Definer.java,v
retrieving revision 1.15
diff -u -r1.15 Definer.java
--- taskdefs/Definer.java 18 Apr 2002 06:54:54 -0000 1.15
+++ taskdefs/Definer.java 23 May 2002 16:36:33 -0000
@@ -84,7 +84,9 @@
private File file;
private String resource;
private boolean reverseLoader = false;
-
+ private String reuseLoader=null;
+ private String reference;
+
public void setReverseLoader(boolean reverseLoader) {
this.reverseLoader = reverseLoader;
log("The reverseloader attribute is DEPRECATED. It will be removed",
@@ -112,9 +114,18 @@
}
public void setClasspathRef(Reference r) {
+ reference=r.getRefId();
createClasspath().setRefid(r);
}
+ /** Allow multiple taskdef/typedef to use the same class loader,
+ * so they can be used togheter. This eliminate the need to
+ * put them in the CLASSPATH.
+ */
+ public void setReuseLoader( String s ) {
+ reuseLoader=s;
+ }
+
public void execute() throws BuildException {
AntClassLoader al = createLoader();
@@ -205,8 +216,27 @@
}
}
-
+ static final String REUSE_LOADER_REF="ant.reuse.loader";
+
private AntClassLoader createLoader() {
+ if( project.getProperty( REUSE_LOADER_REF ) != null ) {
+ // Generate the 'reuse' name automatically from the reference.
+ // This allows <taskdefs> that work on both ant1.4 and ant1.5.
+ // ( in 1.4 it'll require the task/type to be in classpath if they
+ // are used togheter ).
+ if( reference!=null ) {
+ reuseLoader="ant.loader." + reference;
+ }
+ }
+ if( reuseLoader != null ) {
+ // We could use a local hashtable - but the references are cleaner.
+ Object reusedLoader=project.getReference( reuseLoader );
+ if( reusedLoader != null &&
+ reusedLoader instanceof AntClassLoader ) {
+ return (AntClassLoader)reusedLoader;
+ }
+ }
+
AntClassLoader al = null;
if (classpath != null) {
al = new AntClassLoader(project, classpath, !reverseLoader);
@@ -218,6 +248,13 @@
// task we want to define will never be a Task but always
// be wrapped into a TaskAdapter.
al.addSystemPackageRoot("org.apache.tools.ant");
+
+
+ if( reuseLoader != null ) {
+ if( project.getReference( reuseLoader ) == null )
+ project.addReference( reuseLoader, al );
+ }
+
return al;
}
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Definer to allow types/tasks from the same jar to work
Posted by Peter Donald <pe...@apache.org>.
On Fri, 24 May 2002 19:08, Stefan Bodewig wrote:
> On Fri, 24 May 2002, Peter Donald <pe...@apache.org> wrote:
> > However I am not sure this works anymore because of changes that
> > Stefan made wrt overiding tasks etc? I dunno - Stefan ?
>
> I'm not aware of such a case.
>
> Class old = (Class) taskClassDefinitions.get(taskName);
> if (null != old) {
> if (old.equals(taskClass)) {
> log("Ignoring override for task " + taskName
>
> would still override the old definition if taskClass and oldClass have
> been loaded from different classloaders.
>
> Are you aware of any problems?
Nope - just haven't tried it for a while ;)
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Definer to allow types/tasks from the same jar to work
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 24 May 2002, Peter Donald <pe...@apache.org> wrote:
> However I am not sure this works anymore because of changes that
> Stefan made wrt overiding tasks etc? I dunno - Stefan ?
I'm not aware of such a case.
Class old = (Class) taskClassDefinitions.get(taskName);
if (null != old) {
if (old.equals(taskClass)) {
log("Ignoring override for task " + taskName
would still override the old definition if taskClass and oldClass have
been loaded from different classloaders.
Are you aware of any problems?
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Definer to allow types/tasks from the same jar to work
Posted by co...@covalent.net.
On Fri, 24 May 2002, Peter Donald wrote:
> On Fri, 24 May 2002 12:36, costinm@covalent.net wrote:
> > Also, making separate loader
> > a feature would mean we require taskdef to create a classloader
> > on each invocation - which is a dubious behavior ( at least for
> > default ).
>
> does not really matter if it is an ugly hack (which I think it is too) but
> backwards compatability does matter. Theres plenty of things that I consider
> ugly hacks in ant (ie if/unless on targets) but are here to stay.
This is a backward compatibility case if we're talking about a
feature or behavior that was expected to work this way.
I never saw any documentation or code comment implying that taskdef is
required to create new classloaders on each invocation. In older versions
of ant it didn't even create a classloader.
It is true, there is no documentation specifying that tasks and types
should be useable togheter or even 2 different tasks loaded with
different <taskdef> will be able to see each other.
But it seems to me we have to choose one or the other, at least
for the default ( with a magic property or explicit attribute we
can support the other ).
Maintaining backward compatibilty for the DTD and for the
documented behavior is essential. Preserving undocumented
behaviors may be good in most cases, but I don't think this
is one.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Definer to allow types/tasks from the same jar to work
Posted by Peter Donald <pe...@apache.org>.
On Fri, 24 May 2002 12:36, costinm@covalent.net wrote:
> Also, making separate loader
> a feature would mean we require taskdef to create a classloader
> on each invocation - which is a dubious behavior ( at least for
> default ).
does not really matter if it is an ugly hack (which I think it is too) but
backwards compatability does matter. Theres plenty of things that I consider
ugly hacks in ant (ie if/unless on targets) but are here to stay.
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Definer to allow types/tasks from the same jar to work
Posted by co...@covalent.net.
On Fri, 24 May 2002, Peter Donald wrote:
> On Fri, 24 May 2002 09:23, costinm@covalent.net wrote:
> > The big question is - can we agree to make the default
> > behavior 'reuse' - i.e. taskdef will allways use the same
> > loader for the same classpath ? If we do, then I can remove
> > the magic property and the attribute. Is it possible that someone is
> > actually using the fact that <taskdef> will create a different class
> > loader for each task ? I think it is a bug, but if it is considered a
> > feature we'll have to preserve it.
>
> It is a feature not a bug unfortunately ;( Some people who have written tasks
> that use statics used to re taskdef tasks to get a "clean" task prior to each
> invocation. However I am not sure this works anymore because of changes that
> Stefan made wrt overiding tasks etc? I dunno - Stefan ?
If this is indeed a feature, it should be documented as such. Nothing in
the taskdef documentation implies it is going to create a new classloader
for each task, and relying on this is bad.
I think it's reasonable to expect from the docs that if you define a task
and a type, you'll be able to use them togheter, and the fact that it
doesn't can be considered bug. Supporting that ( even if not explicitely
documented/specified ) is more imporant ( IMHO ) than supporting
the separate loader ( also undocumented feature, and very likely
to fail if files are in the CLASSPATH ). Also, making separate loader
a feature would mean we require taskdef to create a classloader
on each invocation - which is a dubious behavior ( at least for
default ).
Anyway - that's a different issue. The patch would preserve the
old behavior by default. If we decide it was a bug, I'll just reverse
it to support the old way if explicitely requested and default to loader
reuse.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Definer to allow types/tasks from the same jar to work
Posted by Peter Donald <pe...@apache.org>.
On Fri, 24 May 2002 09:23, costinm@covalent.net wrote:
> The big question is - can we agree to make the default
> behavior 'reuse' - i.e. taskdef will allways use the same
> loader for the same classpath ? If we do, then I can remove
> the magic property and the attribute. Is it possible that someone is
> actually using the fact that <taskdef> will create a different class
> loader for each task ? I think it is a bug, but if it is considered a
> feature we'll have to preserve it.
It is a feature not a bug unfortunately ;( Some people who have written tasks
that use statics used to re taskdef tasks to get a "clean" task prior to each
invocation. However I am not sure this works anymore because of changes that
Stefan made wrt overiding tasks etc? I dunno - Stefan ?
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Definer to allow types/tasks from the same jar to work
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 23 May 2002, <co...@covalent.net> wrote:
> Regarding 'magic' properties - the main reason is to allow
> a single build.xml file that works with both ant1.4 and ant1.5.
> I don't think the next release of tomcat can require ant1.5
> and not work with 1.4.
<typedef> doesn't really work in 1.4.x at all, so maybe it would be
better to move that out to a "requires Ant 1.5" build file?
> Is it possible that someone is actually using the fact that
> <taskdef> will create a different class loader for each task ?
Yes. <anakia> used to when Velocity used some singletons to hold
state. This is fixed now, but there will certainly be others holding
state in statics.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Definer to allow types/tasks from the same jar to work
Posted by co...@covalent.net.
On Fri, 24 May 2002, Conor MacNeill wrote:
> I guess Magesh needs to make a call on whether this should go into the release.
Sure, but everyone else can -1 - and that's what I'm worried about :-)
> Why not create a datatype for the loader
>
> <loader id="tomcat.loader">
> <classpath ...
> </loader>
>
> and then ref in the taskdef/typedefs
>
> <taskdef>
> <loader refid="tomcat.loader"/>
> </taskdef>
>
> No need for magic properties or implicit sharing of loaders.
Regarding 'magic' properties - the main reason is to allow
a single build.xml file that works with both ant1.4 and ant1.5.
I don't think the next release of tomcat can require ant1.5
and not work with 1.4.
My main concern was to create the minimal ammount of change,
both in build.xml ( for backward compat ) and as code. I think
it's more of a bugfix, using tasks and types should work in
any case.
The big question is - can we agree to make the default
behavior 'reuse' - i.e. taskdef will allways use the same
loader for the same classpath ? If we do, then I can remove
the magic property and the attribute. Is it possible that someone is
actually using the fact that <taskdef> will create a different class
loader for each task ? I think it is a bug, but if it is considered a
feature we'll have to preserve it.
Regarding your sugestion - a <loader> type will work without
any change with taskdef ( since we use the object referenced
by the id, if it is an AntClassLoader ).
I will rename the attribute from
reuseLoader="loader-id"
to
loaderRef="loader-id"
to make it clear what it means, but creating the inner <loader>
for taskdef seems like too bigger code change.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Definer to allow types/tasks from the same jar to work
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
costinm@covalent.net wrote:
> This patch is essential for me ( in jakarta-tomcat-connectors project, I
> suspect other jakarta projects are affected as well ). I'm willing to make
> changes - but I need this functionality in ant1.5 in a form or another.
> For a use-case, look at the cpp-tasks on sourceforge or any other
> user-tasks that uses both types and tasks.
>
I guess Magesh needs to make a call on whether this should go into the release.
> In ant1.4, this only works if the code is in the CLASSPATH ( or
> ant/lib ). It is possible to load multiple tasks that will work togheter,
> or multiple types - but it is not possible to have the tasks ant types.
> This is because different class loaders are used. A <taskdef> can load
> multiple tasks with the same loader if file or resource attribute is
> used.
>
> With this fix, we allow the user to specify that he wants different
> <taskdefs> and <typedefs> to use the same classloader instance, so the
> tasks/types can use each other. It is backward and forward compatible -
> unless the user explicitely specify he wants the new behavior, the
> old behavior will be used with absolutely no change.
>
> It is possible to use the same build.xml with both ant1.4 and ant1.5,
> as long as in 1.4 you put the .jar in ant/lib ( that's the
> only solution in 1.4 to solve this problem ). Asking for loader reuse
> can also be done with an explicit attribute.
>
> Costin
>
Costin,
Why not create a datatype for the loader
<loader id="tomcat.loader">
<classpath ...
</loader>
and then ref in the taskdef/typedefs
<taskdef>
<loader refid="tomcat.loader"/>
</taskdef>
No need for magic properties or implicit sharing of loaders.
Conor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Definer to allow types/tasks from the same jar to work
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: <co...@covalent.net>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Friday, May 24, 2002 6:49 AM
Subject: Re: [PATCH] Definer to allow types/tasks from the same jar to work
> On Fri, 24 May 2002, Magesh Umasankar wrote:
>
> > It is a nice-to-have, yes, but I don't see it as a bug
> > in 1.5. At least I would need some convincing to call
> > it a bug ;-). Depending upon that, it may or may not
> > go into 1.5 branch.
>
> Acording to ant 1.5 docs, you can define custom tasks and types
> with <taskdef> and <typedef>. It is also a documented feature that
> both taskdef and typedef can use a user-defined classpath to
> load the implementation classes.
>
> If a user-defined task uses a user-defined type you get a
> ClassCastException.
>
> To me that means that <taskdef>/<typedef> with user-defined
> classpath is broken.
>
> Please take a look at jakarta-tomcat-connectors/jk/native2/build.xml
> and apache2-cpptasks target as an example. It won't work with ant1.5
> without the patch.
ahh, that explains one of my problems; why I couldnt use references to <lib>
datatypes in the <cc> task without putting them all into the ANT_HOME\lib
before declaring them.
As far as I am concerned, this is a bug
-stve
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Definer to allow types/tasks from the same jar to work
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
costinm@covalent.net wrote:
>
> Would adding 2 attribute, one to force a new classloader and one to
> force a specific loader disambiguate the problem ?
I'd prefer to keep it simple.
Let's just document that fact that turning on the property is global in
nature. Someone who does this is at least choosing to get that behaviour.
Later we can introduce the <loader> type and give more fine-grained and user
controlled reuse of class loaders.
Conor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Definer to allow types/tasks from the same jar to work
Posted by co...@covalent.net.
On 27 May 2002, Stefan Bodewig wrote:
> > Would adding 2 attribute, one to force a new classloader and one to
> > force a specific loader disambiguate the problem ?
>
> It would, if you long for 1.5+ only build files.
>
> You've introduced the magic property to make it possible to write
> build files that are compatible with 1.4.1 and 1.5 at the same time,
> right? If you use new attributes, you can't do that any longer.
Actually, the attributes are for 1.5+ build files, and I'll use them
in build files after 1.5 significantly replace 1.4 ( probably ~ 6 months).
Until then - the 'magic' property and no attributes, so the build
files will work with 1.4.1 ( unmodified - but with the old restriction
that cpptasks.jar must be copied in ant/lib ).
> We better advice people that they should not use the magic property at
> all but use the loaderref attribute instead - if they can live with
> Ant 1.5 build files. I see this magic property as something that
> should be deprecated (but we don't do that any longer) right now.
I partially agree. Explicit attributes are cleaner than magic properties.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Definer to allow types/tasks from the same jar to work
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 24 May 2002, <co...@covalent.net> wrote:
> On 24 May 2002, Stefan Bodewig wrote:
>> The biggest problem I see with a magic property approach is its
>> global nature.
>
> Would adding 2 attribute, one to force a new classloader and one to
> force a specific loader disambiguate the problem ?
It would, if you long for 1.5+ only build files.
You've introduced the magic property to make it possible to write
build files that are compatible with 1.4.1 and 1.5 at the same time,
right? If you use new attributes, you can't do that any longer.
We better advice people that they should not use the magic property at
all but use the loaderref attribute instead - if they can live with
Ant 1.5 build files. I see this magic property as something that
should be deprecated (but we don't do that any longer) right now.
No changes necessary.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Definer to allow types/tasks from the same jar to work
Posted by co...@covalent.net.
On 24 May 2002, Stefan Bodewig wrote:
> On Fri, 24 May 2002, <co...@covalent.net> wrote:
>
> > Also for Conor - I really want to keep the magic property
> > for backward compatibility ( so a build.xml for 1.5 can
> > be used with 1.4 ).
>
> (Even though I'm not Conor 8-)
:-)
> The biggest problem I see with a magic property approach is its global
> nature. It will be applied for all taskdefs and typedefs of your
> project (and those you call with <ant*>), you loose the choice.
Would adding 2 attribute, one to force a new classloader and one to
force a specific loader disambiguate the problem ?
If someone _wants_ a new class loader ( to get around statics ), it
should be clear from the build.xml. If someone _wants_ to use
a specific loader for the taskdef, it should also be explicit.
The default behavior was never specified or documented - and the
situation is symetrical. The magic property will just change the
default behavior, and again - it is just a way to allow an easy
transition from 1.4 to 1.5.
We have enough headache with the transition from JDK1.3 to JDK1.4.
Luckily ant1.5 doesn't require changes in an ant1.4 build.xml,
so this particular transition should be easier.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Definer to allow types/tasks from the same jar to work
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 24 May 2002, <co...@covalent.net> wrote:
> Also for Conor - I really want to keep the magic property
> for backward compatibility ( so a build.xml for 1.5 can
> be used with 1.4 ).
(Even though I'm not Conor 8-)
The biggest problem I see with a magic property approach is its global
nature. It will be applied for all taskdefs and typedefs of your
project (and those you call with <ant*>), you loose the choice.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Definer to allow types/tasks from the same jar to work
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
costinm@covalent.net wrote:
> Thanks!
>
> Based on the feedback I got so far from Peter and Conor,
> I'll leave the default behavior unchanged ( i.e. different
> class loaders ).
+1
>
> I'll also change the name of the attribute to
> 'loaderId' - and make sure this would work with a
> <loader> type.
+1
>
> Conor - I'm not sure we should add the <loader> type.
> Let me know if you think it's required, it's quite
> easy to implement.
I like this approach but I think perhaps we should add that in 1.6 (MAIN).
>
> Also for Conor - I really want to keep the magic property
> for backward compatibility ( so a build.xml for 1.5 can
> be used with 1.4 ).
+1
There is a section in the docs where some of the magic properties are
discussed - please document it there.
Just FYI, in the past we have had a situation where a task could be compiled
under 1.3 and 1.4 OK, but if compiled under 1.4 it would not work under 1.3.
The other way was OK (compiling under 1.3 and deploying under 1.4).
In this particular case, when compiled under 1.4, the resulting task class
file would have references to ProjectComponent (even though there were no
source references). Since this class did not exist in 1.3 it would fail.
Anyway my point is that forward compatability is harder to achieve than it
looks. If you are going to distribute a binary version of this task it may
be necessary to compile under 1.4 rather than 1.5. You'll have to test it
out, I guess.
> After I commit the patch I'll update
> the docs for taskdef/typedef - if you want I can only include
> the new attribute and leave the magic property undocumented.
Everything should be documented, IMHO.
Conor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Definer to allow types/tasks from the same jar to work
Posted by co...@covalent.net.
Thanks!
Based on the feedback I got so far from Peter and Conor,
I'll leave the default behavior unchanged ( i.e. different
class loaders ).
I'll also change the name of the attribute to
'loaderId' - and make sure this would work with a
<loader> type.
Conor - I'm not sure we should add the <loader> type.
Let me know if you think it's required, it's quite
easy to implement.
Also for Conor - I really want to keep the magic property
for backward compatibility ( so a build.xml for 1.5 can
be used with 1.4 ). After I commit the patch I'll update
the docs for taskdef/typedef - if you want I can only include
the new attribute and leave the magic property undocumented.
Costin
On Fri, 24 May 2002, Magesh Umasankar wrote:
> ok, you have convinced me it is a bug :-)
> +1 to patch a fix. wrt the actual patch that
> you have provided, I will leave it to others
> to make the call whether it can go in, in its
> current avatar. I am +0 on it as I have not
> taken a close look at it yet and I realize
> it must get in in short order, if it is gonna
> make it to Beta 2.
>
> Cheers,
> Magesh
>
> ************************************************
> * Criminal: A guy no different from the rest *
> * ...except that he got caught. *
> ************************************************
> ----- Original Message -----
> From: <co...@covalent.net>
> To: "Ant Developers List" <an...@jakarta.apache.org>
> Sent: Friday, May 24, 2002 9:49 AM
> Subject: Re: [PATCH] Definer to allow types/tasks from the same jar to work
>
>
> > On Fri, 24 May 2002, Magesh Umasankar wrote:
> >
> > > It is a nice-to-have, yes, but I don't see it as a bug
> > > in 1.5. At least I would need some convincing to call
> > > it a bug ;-). Depending upon that, it may or may not
> > > go into 1.5 branch.
> >
> > Acording to ant 1.5 docs, you can define custom tasks and types
> > with <taskdef> and <typedef>. It is also a documented feature that
> > both taskdef and typedef can use a user-defined classpath to
> > load the implementation classes.
> >
> > If a user-defined task uses a user-defined type you get a
> > ClassCastException.
> >
> > To me that means that <taskdef>/<typedef> with user-defined
> > classpath is broken.
> >
> > Please take a look at jakarta-tomcat-connectors/jk/native2/build.xml
> > and apache2-cpptasks target as an example. It won't work with ant1.5
> > without the patch.
> >
> > Costin
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Definer to allow types/tasks from the same jar to work
Posted by Magesh Umasankar <um...@apache.org>.
ok, you have convinced me it is a bug :-)
+1 to patch a fix. wrt the actual patch that
you have provided, I will leave it to others
to make the call whether it can go in, in its
current avatar. I am +0 on it as I have not
taken a close look at it yet and I realize
it must get in in short order, if it is gonna
make it to Beta 2.
Cheers,
Magesh
************************************************
* Criminal: A guy no different from the rest *
* ...except that he got caught. *
************************************************
----- Original Message -----
From: <co...@covalent.net>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Friday, May 24, 2002 9:49 AM
Subject: Re: [PATCH] Definer to allow types/tasks from the same jar to work
> On Fri, 24 May 2002, Magesh Umasankar wrote:
>
> > It is a nice-to-have, yes, but I don't see it as a bug
> > in 1.5. At least I would need some convincing to call
> > it a bug ;-). Depending upon that, it may or may not
> > go into 1.5 branch.
>
> Acording to ant 1.5 docs, you can define custom tasks and types
> with <taskdef> and <typedef>. It is also a documented feature that
> both taskdef and typedef can use a user-defined classpath to
> load the implementation classes.
>
> If a user-defined task uses a user-defined type you get a
> ClassCastException.
>
> To me that means that <taskdef>/<typedef> with user-defined
> classpath is broken.
>
> Please take a look at jakarta-tomcat-connectors/jk/native2/build.xml
> and apache2-cpptasks target as an example. It won't work with ant1.5
> without the patch.
>
> Costin
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Definer to allow types/tasks from the same jar to work
Posted by co...@covalent.net.
On Fri, 24 May 2002, Magesh Umasankar wrote:
> It is a nice-to-have, yes, but I don't see it as a bug
> in 1.5. At least I would need some convincing to call
> it a bug ;-). Depending upon that, it may or may not
> go into 1.5 branch.
Acording to ant 1.5 docs, you can define custom tasks and types
with <taskdef> and <typedef>. It is also a documented feature that
both taskdef and typedef can use a user-defined classpath to
load the implementation classes.
If a user-defined task uses a user-defined type you get a
ClassCastException.
To me that means that <taskdef>/<typedef> with user-defined
classpath is broken.
Please take a look at jakarta-tomcat-connectors/jk/native2/build.xml
and apache2-cpptasks target as an example. It won't work with ant1.5
without the patch.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Definer to allow types/tasks from the same jar to work
Posted by Magesh Umasankar <um...@apache.org>.
It is a nice-to-have, yes, but I don't see it as a bug
in 1.5. At least I would need some convincing to call
it a bug ;-). Depending upon that, it may or may not
go into 1.5 branch.
Cheers,
Magesh
***********************************************************
* Classic: A book which people praise, but do not read. *
***********************************************************
----- Original Message -----
From: <co...@covalent.net>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Thursday, May 23, 2002 12:43 PM
Subject: [PATCH] Definer to allow types/tasks from the same jar to work
> This patch is essential for me ( in jakarta-tomcat-connectors project, I
> suspect other jakarta projects are affected as well ). I'm willing to make
> changes - but I need this functionality in ant1.5 in a form or another.
> For a use-case, look at the cpp-tasks on sourceforge or any other
> user-tasks that uses both types and tasks.
>
> In ant1.4, this only works if the code is in the CLASSPATH ( or
> ant/lib ). It is possible to load multiple tasks that will work togheter,
> or multiple types - but it is not possible to have the tasks ant types.
> This is because different class loaders are used. A <taskdef> can load
> multiple tasks with the same loader if file or resource attribute is
> used.
>
> With this fix, we allow the user to specify that he wants different
> <taskdefs> and <typedefs> to use the same classloader instance, so the
> tasks/types can use each other. It is backward and forward compatible -
> unless the user explicitely specify he wants the new behavior, the
> old behavior will be used with absolutely no change.
>
> It is possible to use the same build.xml with both ant1.4 and ant1.5,
> as long as in 1.4 you put the .jar in ant/lib ( that's the
> only solution in 1.4 to solve this problem ). Asking for loader reuse
> can also be done with an explicit attribute.
>
> Costin
>
> Index: taskdefs/Definer.java
> ===================================================================
> RCS file:
/home/cvs/jakarta-ant/src/main/org/apache/tools/ant/taskdefs/Definer.java,v
> retrieving revision 1.15
> diff -u -r1.15 Definer.java
> --- taskdefs/Definer.java 18 Apr 2002 06:54:54 -0000 1.15
> +++ taskdefs/Definer.java 23 May 2002 16:36:33 -0000
> @@ -84,7 +84,9 @@
> private File file;
> private String resource;
> private boolean reverseLoader = false;
> -
> + private String reuseLoader=null;
> + private String reference;
> +
> public void setReverseLoader(boolean reverseLoader) {
> this.reverseLoader = reverseLoader;
> log("The reverseloader attribute is DEPRECATED. It will be
removed",
> @@ -112,9 +114,18 @@
> }
>
> public void setClasspathRef(Reference r) {
> + reference=r.getRefId();
> createClasspath().setRefid(r);
> }
>
> + /** Allow multiple taskdef/typedef to use the same class loader,
> + * so they can be used togheter. This eliminate the need to
> + * put them in the CLASSPATH.
> + */
> + public void setReuseLoader( String s ) {
> + reuseLoader=s;
> + }
> +
> public void execute() throws BuildException {
> AntClassLoader al = createLoader();
>
> @@ -205,8 +216,27 @@
> }
> }
>
> -
> + static final String REUSE_LOADER_REF="ant.reuse.loader";
> +
> private AntClassLoader createLoader() {
> + if( project.getProperty( REUSE_LOADER_REF ) != null ) {
> + // Generate the 'reuse' name automatically from the
reference.
> + // This allows <taskdefs> that work on both ant1.4 and
ant1.5.
> + // ( in 1.4 it'll require the task/type to be in classpath if
they
> + // are used togheter ).
> + if( reference!=null ) {
> + reuseLoader="ant.loader." + reference;
> + }
> + }
> + if( reuseLoader != null ) {
> + // We could use a local hashtable - but the references are
cleaner.
> + Object reusedLoader=project.getReference( reuseLoader );
> + if( reusedLoader != null &&
> + reusedLoader instanceof AntClassLoader ) {
> + return (AntClassLoader)reusedLoader;
> + }
> + }
> +
> AntClassLoader al = null;
> if (classpath != null) {
> al = new AntClassLoader(project, classpath, !reverseLoader);
> @@ -218,6 +248,13 @@
> // task we want to define will never be a Task but always
> // be wrapped into a TaskAdapter.
> al.addSystemPackageRoot("org.apache.tools.ant");
> +
> +
> + if( reuseLoader != null ) {
> + if( project.getReference( reuseLoader ) == null )
> + project.addReference( reuseLoader, al );
> + }
> +
> return al;
> }
>
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>