stores to implement their own policy.
This feature will not work in ant15 ( for now ).
Also changed Project to Object - and use it as a context. This makes
the callback more generic and the hooks less dependent of ant.
The only major issue on dynamic properties for me is the JNDI stuff.
I think the Context interface could be a better abstraction, but
on the other side it is much more complex. I also want to finalize
the JNDI property source and abstract the properties via JNDI
so tasks can be created without any dep on ant, but still accessing
properties and refs.
git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273434 13f79535-47bb-0310-9956-ffa450edef68
I would like to extend it a bit more in the future - to support
properties like "${property}" without a string conversion.
In other workds, if a dynamic property is used ( which return an
object ), the object should be used as such in the introspection.
That would greatly simplify tasks and allow more flexibility.
git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273433 13f79535-47bb-0310-9956-ffa450edef68
behavior and control the creation.
This will work for all code that checks instanceof, but
will obviously fail if any code explicitely looks at the class
name ( which is very unlikely - so far no code did that in the
gump run or otherwise ).
The UnknownElement2/RuntimeConfigurable2 will be further refactored
to make them more independent of the XML representation and
have a cleaner API. All behavior will be moved out of the XML
processor and into this pair. Of course, full backward compat will
be provided.
git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273432 13f79535-47bb-0310-9956-ffa450edef68
Full backward compatibility is provided - the project
is used to create tasks. The mechanism allows full
flexibility in implementing any kind of antlib policy,
and allows applications embeding ant to integrate in the
component creation process.
Probably a good improvement would be to move the 'default'
behavior in a separate plugin ( DefaultComponentFactory - to
use the project component storage ), and deprecate the use
of Project for project component management.
After more feedback is received I'll propose this for the
main branch.
git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273430 13f79535-47bb-0310-9956-ffa450edef68
It adds support for multiple values.
( I am not sure if this is the right place - I would try to
return a vector/enumeration/[] - and then have a generic solution
that would turn this into a string. Until I find a better solution
I'll leave the code unchanged )
Bug 11789
git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273269 13f79535-47bb-0310-9956-ffa450edef68
XMLDOC is a typedes that can be used in the embed proposal.
It loads an xml file as a DOM, thus making it available to jxpath.
Note:
This is different from the XML task that loads each element
as a property. Eventually we should merge the 2 - after 'embed'
is proposed for the main branch and if it is accepted.
Note2: It would be interesting to explore the other side of
jxpath, i.e. setting. And then saving the xml file.
git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273217 13f79535-47bb-0310-9956-ffa450edef68
beans are turned into tasks - it allows to specify the method name.
It'll also be extended to support mbeans or other types of tasks.
git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273177 13f79535-47bb-0310-9956-ffa450edef68
The next major step for this will be a set of hooks to allow ant to
be more JMX friendly - one very straightforward way to embed ant
is by using MBeans to represent the components.
In addition ant should be able to use MBeans as tasks and in
the build process.
git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273165 13f79535-47bb-0310-9956-ffa450edef68
AntContext.
Started the cleanup process.
The reason for 'stateless' model is not performance, but having a cleaner
model. It is very hard to track things on the stack or in different
handlers.
The next major step will be to try to reorganize the DataType/Task/UnknownTask
creation.
So far all features ( sax2, import, dynamic prop, classloader ) seem to work
fine with 1.5 - at least on all projects I'm working on.
git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273164 13f79535-47bb-0310-9956-ffa450edef68
Implement the 'projectName.target' instead of super. I'm still trying
to find a way to allow Import task to hook in and support whatever
policy it wants.
git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273141 13f79535-47bb-0310-9956-ffa450edef68
executing other targets ( which is closer to the original
behavior ).
Import started to work a bit - but it complain about
circular dep on super.mb2, still investigating.
git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273135 13f79535-47bb-0310-9956-ffa450edef68
Made few fields public - the whole thing will be refactored with
proper getter/setters after things are stable.
Added import processing ( the patch was modified a bit ).
git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273133 13f79535-47bb-0310-9956-ffa450edef68
You need to include ant-sax2.jar in ant/lib, define a <path id='foo'> that includes
all the jars that you need ( junit.jar, etc ) and then use
<systemPath pathRef='foo' /> to create the loader and reload all optional tasks.
After this step all optional tasks will work in the same way as if you have
included the jars from the <path> definition in ant/lib.
I did some basic tests and seems to work fine - note that <taskdef> will
work as before, i.e. if you explicitely define tasks that need optional
jars ( or redefine optional task ), you'll have the old behavior ( i.e.
require things in CLASSPATH ).
I'll try to find what changes are need for <import> and re-do the build
for ant-sax2, then do more testings.
git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273118 13f79535-47bb-0310-9956-ffa450edef68
TODO: Convert to the new XDoclet, start progressing this to the mainstream so that Ant 1.6 can have code-generated documentation finally.
git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273112 13f79535-47bb-0310-9956-ffa450edef68
properties.
This is not final, of course.
PropertyHelper will implement all property manipulation. Eventually in
ant1.6 the static methods in various places should just wrap and
call this. In 1.6 the property storage can also be migrated to this
class.
It should be possible by a task or embedding application to replace
the whole mechanism - no need for discovery on this one, it can be
done by a task.
The PropertyInterceptor will be used to plug different sources
for the property. I'm thinking to just have tasks/types implementing
this interface automatically get registered - it's the simpler
solution for tasks developers ( I think ).
git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273107 13f79535-47bb-0310-9956-ffa450edef68
will replace all optional tasks, using an AntClassLoader to load
( delegation disabled for the optional package ).
Next step is to add a task that adds jars to the loader for optional.
( like junit.jar, etc ).
git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273106 13f79535-47bb-0310-9956-ffa450edef68
Tag data values with a priority to support the Ant1 property menagerie
Add a policy to the mutant launch script (somewhat experimental)
Improved bootstrap
Directory reorg to facilitate policy declarations
git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273030 13f79535-47bb-0310-9956-ffa450edef68
Costin Manolache
Peter Donald
Steve Loughran
Stefan Bodewig
Erik Hatcher
Conor MacNeill
Magesh Umasankar
Stephane Bailliez