ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Murdoch <adammurd...@apache.org>
Subject Re: My itches for 1.6
Date Mon, 15 Jul 2002 21:49:21 GMT
On Tue, 16 Jul 2002 08:46, costinm@covalent.net wrote:
> On Mon, 15 Jul 2002, Steve Loughran wrote:
> > > Catalina is as follows:
> > >
> > >                       Bootstrap
> > >
> > >                        System
> > >
> > >                        Common
> > >                       /      \
> > >                  Catalina   Shared
> > >                            /     \
> > >                        Webapp1  Webapp2 ...
> > >                          /          /
> > >                       Jasper1   Jasper2
> >
> > And common/lib is marked as endorsed for java1.4, so you have to add new
> > javax. stuff (like jaxrpc.jar) to that lib, rather than in your webapp,
> > just to make installing axis harder. I'd hope we dont replicate that
> > problem, if we can avoid it.
>
> When I mentioned a tomcat-like hierarchy I certainly didn't meant the
> full tree - at least not for 1.6 :-)
>
> There are 2 things in tomcat classloader worth considering for ant:
>
> - the webapp class loader that can use Manifest entries to find
> and resolve dependencies, as well as allow 'webapps' to override some
> classes ( as required by the servlet2.3 spec - but that can be used
> in ant as well).

This is what myrmidon does.  It's a quite powerful approach, since you declare 
the dependencies in logical rather than physical terms. ie you declare 'I 
need junit' or 'I need junit version 3.7', rather than 'I need junit.jar'.  
This gives the container heaps of flexibility in how it actually finds the 
extensions (ie dependencies) that a jar needs.

In myrmidon, we've made extension resolution pluggable, and you can combine 
resolvers at runtime.  For example, we have a resolver that looks for 
extensions in $ANT_HOME/ext, another that maps the 'com.sun.tools' extension 
to the JDK's tools.jar, another that provides a JAXP parser, and one that 
makes antlibs available as extensions when they get imported.  One that 
downloaded jars as needed wouldn't be a big deal to add.
 
Another good thing that comes from using the extensions mechanism, is that you 
can use it in build files as well.  For example, in myrmidon, we have a 
<path> implementation that returns the path for an extension.  You can use 
this when compiling, packaging, and running your task/app/tests/whatever, and 
your build file does not need to know where the jars actually live. eg:

<path id="myclasspath">
  <library-path name="junit" version="3.7+"/>
  <library-path name="com.sun.tools"/>
</path>

<javac classpath="${myclasspath}" ... />

(of course, you need poymorhpic types for this to work, but you get the idea.)

> - a hierarchy that is more flexible than 'all jars in CLASSPATH' -
> I think most problems can be solved by just 3 layers ( core,
> optional + global taskdefs, taskdefs with specific loader ). If
> needed we can also use a separate loader for 'server' ( in our
> case ant ). And in time we can enhance it further.

The classloader heirarchy in myrmidon looks something like the tomcat one:

         Bootstrap

          System

          Common
         /      \
     Myrmidon  Shared
              /     \
          antlib1 antlib2 ...

Each antlib is loaded in its own classloader.  We've split Optional.jar and 
most of the core tasks, into several antlibs.


-- 
Adam

--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message