+ And being able to make sure that B and A use the same classLoader
+ and therefore they can use each other components.
+
+
+
+ My solution at the time was this idea of a named classloader that
+ you could define using a classpath, and then tell your antlibs use
+ this or that classloader, if you use the same classloader visibility
+ is guaranteed.
+
+
+
+ Stefan Bodewig 23.04.2003 17:11
+
+
+
+I understand that usecase (using the same class loader for 2 different antlibs)
+and think it's important. See Steve
+Loughran's comment on the .NET tasks wanting to have access to the
+datatypes defined in the cpptasks project for example.
+
+
+
+Take a look at what Costin had done to <taskdef> and <typedef> with
+the loaderref attribute. This has now (i.e. CVS HEAD) been
+generalized in ClasspathUtils, the infrastructure for named
+classloaders is there - at least the foundation for it.
+
+
+
+Stefan
+
+
+
+ Costin Manolache 29.04.2003 18:52
+
+
+The main issue is how to enforce ordering to deal with dependencies
+between the antlibs.
+
+
+Or simply do not deal with dependencies, ie antlibs must not (yet)
+depend on on the other, except for the core ones.
+
+
+Using an unified class loader ( at least as default ) - like jboss is doing,
+or like JMX loading policy - has a lot of benefits. It also has some cases
+that are not well covered - so we'll probably need to deal with both
+"unified loader" and "loader hierarchy" cases.
+
+Antlibs are special-purpose jar files containing a deployment descriptor called antlib.xml.
+These jar files contain ant tasks and types. In the near future, they will also contain custom components too able to act as filters, mappers, ...
+
+
+The precise location of the deployment descriptor is already a point of discussion. (such as com/xyz/anttasks/antlib.xml). Costin Manolache would prefer deployment descriptors to live in packages The original proposal is to put the deployment descriptor into META-INF/antlib.xml in the jar files.
+
+
+
+ loading of antlibs
+
+
+Under ant.home, a new subdirectory autolib would be created for antlibs to be loaded "spontaneously".
+
+
+antlibs can also be loaded explicitly with an <antlib/> task.
+
+This is the layout of the antlib descriptor in the proposal. In each antlib jar file, the descriptor would be found under
+META-INF/antlib.xml
+
+
+
+ concerns concerning the location of the descriptor (Costin Manolache)
+
+
+
+startup time. In order to load one library you need to process all
+of them. It can be resolved with caching the result and looking at .jar
+modifications. Most likely we'll have dozens of antlibs - and that'll only
+grow in time. The processing of (all) TLDs at startup ( for tomcat ) adds a
+very visible overhead on startup, and at least tomcat is a long-running
+process.
+
+
+
+Placing multiple antlibs in a single jar may be trickier.
+
+
+
+It may place too much emphasis on the .jars and filesystem layout.
+
+
+
+A bit harder to control ( as we know from c-logging and JAXP ),
+
+
+
Explicit control over what antlibs are to be used - versus loading
+everything. Well - I like "magic" loading, but a lot of things in ant
+are done explicitely.
+
+
+
+
+I have no problem accepting a getResources() solution ( just like I'm
+ok with using XML - but not any XML :-), but those issues should be
+considered.
+
+A lot of the "mess" in ant is the result of doing some things without
+considering all implications or just as side effect of how code happened
+to work. That's why I'm so strongly for breaking things down to individual
+problems instead of a bundle solution.
+
+Nicola Ken Barozzi wrote:
+< This seems interesting, and brings up what XML namespaces can be used for.
+
+
+XML namespaces are indented to disambiguate short local element
+and attribute names. Any sematic associated to XML namespaces
+beside this has to be weighted carefully.
+
+
+
+Lets take an example. There are two projects, Foo and Bar,
+each providing a task, lets call them <foo> and <bar>
+respectively. Both tasks take a <part> child, by coincidence.
+Of course, because the projects act uncoordinated, the <part>
+child element has a different semantic. In order to make this
+clearer, let's say the Foo <part> takes an optional <mumble>
+child while the Bar <part> takes three mandatory <xonx>
+children.
+
+
+Someone finds both the <foo> and the <bar> task exciting and
+wants to use both in an Ant build file. No problem so far:
+because ot the way Ant elements get their child elements and
+create associated Java objects, this should work.
+Now said someone got a super-duper schema directed XML editor
+and wants to use it for editing the build.xml file. He asks
+all projects for a schema (DTD, XSD, RNG, whatever) for this
+purpose and merges them in order to get a schema for his build
+file. At this point the two <part> elements are likely to clash
+(at least for DTDs, where element names are global). While
+it is possible to merge the content models so that <part> now
+takes either an optional <mumble> or three <xonx> children, this
+would allow the user to put <xonx> children into the <part> of
+the <foo> task. This is only a minor inconvenience for most
+people, but an unthinkable horror for true purists.
+
+
+Introduce namespaces: the Foo projects names its namespace
+"http://www.fooproject.org/anttask" while the Bar project uses
+"URI:bar" or whatever. For the XML parser it is only really
+important that two different strings are used. You see, the
+longer the strings the less tha chance they will clash, and
+they probably won't clash if they start with the URLs of the
+project's homepages (the intent behind the recommendation to
+use URLs, because it's the closest thing to a global registry
+you can get short of actually creating a global registry).
+Anyway, because the expanded names of the <part> elements are
+now "{http://www.fooproject.org/anttask}part" and "{URI:bar}part"
+respectively they obviously no longer clash.
+BTW you can write this as
+
+take your pick (if you think the "foo" and "bar" prefixes are too
+long, use "a" and "b" instead, it doesn't matter).
+
+
+So far, the namespace names should only be different for different
+projects, so why is it dangerous to associate some semantic with it,
+like letting them point to a jar file? The problem is again that
+general purpose XML tools, like the above mentioned super-duper XML
+editor may associate their own semantics with the namespace, like
+how to auto-format certain elements. This information will be stored
+in some config files, and it requires that the namespace name is
+the same until the semantics of the elements in it have changed
+enough that it warrants assigning a new namespace name.
+
+
+
+Summary:
+
+
+
+XML namespaces are there to facilitate aggregation of XML adhering
+ to schemas (content models) of different, uncoordinated origin.
+
+XML Namespaces should be used in a way that no end user action
+ can result in two namespace names becoming unintentionally the
+ same.
+
+XML Namespace names should preferably be assigned by the people
+ or project which specifies the semantics of the XML elemnets and
+ attributes therein.
+
+XML Namespace names should be kept unchanged until a change of
+ the semantic of the elements warrants a change.
+
+Good tools should not monopolize XML namespace syntax for its
+ own semantics.
+
+
+
+The schema directed editor should provide an example hoe tools
+can take advantage of XML namespaces: use them as a key into a
+DB/config to get it's own associated semantic.
+In particular for Ant/Antlib I can imagine that each library
+provides a factory object associated to the XML namespace for
+the library.
+
+
+The FOP parser uses such a two stage lookup: first the namespace
+is used to get a factory object from a hash table, then the factory
+is used with the local XML element name to create a Java object
+which is inserted into the FO tree. The hash table with the factories
+is initialized at startup, the associations between namespace name
+and factory class name is read from a Services file. Want to add
+a FOP extension? Get the default Services file, add a line with
+your namespace-to-factoryclassname mapping put it into the jar with
+all the classes and drop the jar as first into the classpath. If the
+user wants to use multiple extensions, well, edit the main Services
+instead, dead easy.
+
+Let me quote here Stefan Bodewig - April 24th 2003.
+
+
+Let's make a version of antlib that knows about two predefined roles,
+task and data-type. I think this is already feature complete in the
+proposal (which does even more).
+
+
+Let's move this code with the restriction to tasks and types into the
+main branch ASAP. Let's sort out the classloading requirements as
+well as the interplay of antlib with taskdef and typedef here.
+
+
+After this flies, I'd expect us to get roles sorted out. If we feel
+like removing the difference between tasks and types, we can do so
+then as well.
+
+
+
+ Roles and components in build files
+
+
+A second step : make a detailed proposal concerning roles and implement roles and components in ant core.
+
+
+
+ Roles and components in antlibs
+
+
+ Once roles and components are properly defined and implemented in ant core, we would revisit <antlib> and implement roles and components there.
+
+
+
+ Namespaces
+
+
+ After we have antlibs, roles, and components, we should specify how we are going to proceed concerning namespaces and prefixes.
+
The purpose of this document is to summarize the discussions taking
+ place concerning antlib. I will try to always give proper credit, and to represent
+ honestly different views expressed on the ant development mailing list.
+ Send comments/criticisms if you are not happy with these documents.
+
+
+
+ Overview
+
+
+ Jose Alberto Fernandez 03.04.2003 18:25
+
+
+There are the following features in the antlib proposal:
+
+
+ antlib & antjar
+
+
+ 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).
+
+
+ A scoping framework for the symbol tables needed to manage the antlib definitions (I think ANT has something on this regard)
+
+
+ A framework for managing classloaders where you can specify which classloader to use when loading an antlib.
+
+I am quoting here Jose Alberto Fernandez 26.04.2003 22:05:
+Roles allow defining families of objects (members of a role) that can be
+used by tasks or inner elements developed separately.
+The developer of the object accepting a particular role as a subelement
+has no knowledge of the implementation of the object but much more
+importantly it has no knowledge of the XML element tag used to refer
+to this subelement in the XML file.
+
+
+
+In the antlib proposal, there are two preset roles :
+
+
task
+
datatype
+
+Examples of other roles are :
+
+
mapper
+
filter
+
+
+
+What does it all mean? It means we can now write a task, well typed, which
+can be accept different XML subelements depending on the declarations of
+other objects present on the build. The vendor specific elements of
+<ejbjar>, <jspc> and others are typical examples of where this capability
+can be very useful. Other parts of core could benefit of course.
+
+
+
+
+ What do they do that is no possible in ANT
+
+
+They allow IntrospectionHelper to connect an XML subelement eventhough
+introspection cannot find a create or add/Configured method for it.
+It is a well typed methanism, the parent object will only be passed objects
+that it knows how to deal with. And the parent object does not need to have
+any knowledge of what currently available members are on the role.
+
+
+
+ roles versus DynamicConfigurator
+
+
+The closest thing in ANT today is DynamicConfigurator but its purpose
+is on the other way around. Given an elementTag with no matching method
+it is up to the parent object to try to make sense of it.
+If we were to use this mechanism to accomplish what roles try to do,
+it would require the parent object implementor to be aware of where
+to find the correct definition (remember it is a 3rd party implementation)
+and perform the creation. It will be also its responsibility to
+resolve type conflicts, name collisions, etc. This are all things
+that should be done by IntrospectionHelper directly.
+
+
+
+Also notice that Roles do not supersede DynamicConfigurator. On one hand roles
+let external implementations to be considered as possible subelements
+of a parent object, on the other hand, DynamicConfigurator allows a node
+to decide given its current state what is the meaning of a particular element.
+This cannot be done by roles in the general case, and that is good.
+
+
+
+ Implementation of roles in the proposal
+
+
this section quotes Jose Alberto Fernandez
+
+Here I may deviate from the exact code and add thoughts about where
+do I think it should go.
+
+
+
+ Usage of Roles
+
+
+The principle is very simple:
+
+
+
+
+A role is defined by an interface. This interface is the parameter
+ for a new special family of addConfigured(<interface>) methods.
+
+
+
+When IntrospectionHelper fails to find a create/add method for the
+ element, it will look at all the roles used in the addConfigured
+ methods and on each of those roles will try to find an object declared
+ with that element-tag name. If one and only one match is found then
+ the instantiation is successful and the new object will be configured;
+ otherwise it is an error and parsing stops.
+
+
+
+
+
+ The configured object may or may not implement the Role interface,
+ if it does not, an Adaptor object may be instantiated as a proxy
+ for the object. Which adaptor is used depends on how the implementation
+ was declared.
+
+
+
+
+
+The resulting object is passed as an argument to the addConfigured() method.
+
+
+
+
+
+
+ Declaration of roles
+
+
+A role definition associates a name with an (Interface,Adaptor) pair.
+The only reason for associating a name with the role is to ease notation when
+declaring members of a role.
+
+
+
+Notice that the same interface or the same Adaptor may appear in multiple
+declarations. This only means that depending on the name used the adaptor
+of choice will be different.
+
+
+
+There can only be one pair associated with each name.
+
+
+
+
+ Declaration of implementations (members)
+
+
+
+A class is declared as belonging to a role by specifying the name to be used
+when appearing in that role. The same class may belong to multiple roles
+and may specify the same or different names on each one.
+
+
+
+The name used for the role during the declaration only determines which
+Adaptor will be available, if required.
+
+
+
+
+Within a role-interface there can only be one object associated
+with each name.
+
+
+
+
+ Scoping rules
+
+
+
+This is probably the more dificult aspect since given the way
+<ant> and <antcall> work it means possible redeclarations on every
+level of recursion. Whether declarations should just supercede
+one another or be smarter is something to look into.
+
+
+
+
+ Syntax
+
+
+
+I have left out the issues of how the syntax looks like on purpose.
+
+
+
+Syntax is just that and I am sure we can reach agreement somehow.
+It is also clear that we should provide tasks to define roles
+and declare members of roles direclty on the build.
+
+
+
+
+ Making ant aware of tag/role/class associations
+
+
+The antlib proposal says :
+Let's declare explicitly that a tag can be used in a particular role and is implemented by a specific class.
+The declaration happens inside antlibs in the file META-INF/antlib.xml
+
+CM says :
+A normal typedef is enough to make ant aware of the existence of the class org.apache.tools.ant.filters.EscapeUnicode.
+Due to the fact that EscapeUnicode implements ChainableReader, the association between EscapeUnicode and the filter role does not need to be stated explicitly.
+
+
+
+ Method names in parent classes supporting roles
+
+
+There is a discussion about how methods to add nested elements of a specific roles in a parent class should be called, and what their signature should be like.
+
+
+CM :
+
+addTYPE(TYPE)
+
+for instance addChainableReader(ChainableReader a)
+
+
+PR:
+to add an element before its own attributes and nested elements are configured.
+
+void add(TYPE)
+
+to add an already configured element
+
+void addConfigured(TYPE)
+
+
+
+in the ant code of 1.6 :
+public Object createDynamicElement(String name)
+
+
+
+ Cardinality problems
+
+
+
+ One tag, several implementations
+
+
+The <weblogic> element in <ejbjar>, <jspc>, <serverdeploy>, has different meanings.
+
+
+This is an argument to introduce roles in ant, and to associate an XML tag with a role and an implementation class.
+
+
+
+ Parent classes accepting one interface in different functions
+
+
+As an example, the dependset task accepts nested filesets for two different functions :
+
+The antlib proposal mentions adapter classes, which would be connected to roles.
+Costin Manolache says that adapter classes should be tied to components, not roles.
+The reason : two different components implementing the same interface (AKA role) can require different adapters.
+
+
+
+ role proposal
+
+
+slightly modified version of something writte by Jose Alberto Fernandez
+
+
+<role name="roleName" className="...." [adapter="...."] />
+<!-- I have added the possibility to declare a specific adapter per component to take into account what Costin said -->
+<component name="elementName" role="roleName" className="....." [adapter="...."] />
+
+
+ 
+