|
@@ -0,0 +1,18 @@ |
|
|
|
|
|
There are the following features in the antlib proposal: |
|
|
|
|
|
|
|
|
|
|
|
1) antlib & antjar |
|
|
|
|
|
2) type definitions that allow to define new implementations of mappers, selectors, paths, conditions, etc. That you can define in your antlib and a way to link this with the introspectors (I am not sure how complete this is). |
|
|
|
|
|
3) A scoping framework for the symbol tables needed to manage the antlib definitions (I think ANT has something on this regard) |
|
|
|
|
|
4) A framework for managing classloaders where you can specify which classloader to use when loading an antlib. |
|
|
|
|
|
|
|
|
|
|
|
(2) would be really nice, because it will eliminate all the need for mentioning classnames all around, antlibs will be used just like core. |
|
|
|
|
|
Also useful for tasks like <ejbjar> which has vendor specific components that should be part of the antlib of the vendor. |
|
|
|
|
|
|
|
|
|
|
|
(3) Probably should die and be replaced by whatever scoping thing comes from <import> proposal. |
|
|
|
|
|
|
|
|
|
|
|
(4) This was probably what killed <antlib> the last time around. Probably needs to be treated separately. In any case, if you load |
|
|
|
|
|
multiple antlibs with dependencies, there has t be a way to make them share the same classloader otherwise you cannot use it. |
|
|
|
|
|
|
|
|
|
|
|
So there we go, take a look at the code and let us know what you think, |
|
|
|
|
|
|
|
|
|
|
|
Jose Alberto & Antoine |