Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
Content-Type: text/plain;
  charset="utf-8"
From: Peter Donald <donaldp@apache.org>
To: ant-dev@jakarta.apache.org
Subject: Re: Optional tasks
Date: Thu, 11 Oct 2001 19:53:18 +1000
References: <HGEEIKOHHDJKIOMBLAAEKEBOEEAA.tneward@javageeks.com>
 <20011010121538.XURA13193.mss.rdc2.nsw.optushome.com.au@there>
 <3BC455A8.4060508@cortexebusiness.com.au>
In-Reply-To: <3BC455A8.4060508@cortexebusiness.com.au>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <20011011100225.FHRP13193.mss.rdc2.nsw.optushome.com.au@there>

On Thu, 11 Oct 2001 00:05, Conor MacNeill wrote:
> Here are my random collection of thoughts on this interesting discussion
> :-)

;)

> Peter Donald wrote:
> > On Wed, 10 Oct 2001 19:59, Jose Alberto Fernandez wrote:
> >>Why is our shell/batch script putting things in the CLASPATH?
> >
> > why do we use batch scripts?
>
> IMHO, scripts started out as a convenience. Even if all the script did
> was to run
>
> java -jar $ANT_HOME/lib/ant.jar
>
> I think we would still use them. Over time much more has been heaped
> into them, but they remain, primarily, convenience launchers.

agreed. Though I would prefer they did less rather than more ;)

> >>Following this line, the correct thing to do would be to specify all the
> >>jar dependencies for ANT core in ant.jar itself and let the JVM made up
> >> the classpath. Hence we would be able to just do "java -jar
> >> $HOME/bin/ant.jar $@" or equivalent.
> >
> > The JVM does not implement that. Go read the Optional Package spec - it
> > is up to developer to do it. The new servlet and EJB APIs require
> > container implement it IIRC so we should see more vendors using it.
>
> I'm not quite sure what you mean here, Peter. The VM does use the
> ClassPath entries in the manifest without any developer intervention.
> Also, I presume you are taking about download optional packages as you
> don't seem to like installed optional packages aka extensions :-)

Naah - I am talking about Extensions - they got renamed in jdk1.3 to 
"Optional Packages" ;) However they don't have to be VM wide like old 
extensions just define libraries that can be loaded and managed any way seend 
fit. Currently the JVM does not do it magically for you though.

> What I think is needed is mechanism where these classes upon which a
> task depends are loaded through the tasklib's classloader but whose
> location is not known when the tasklib jar is put together.

Sounds like the Optional Packages/Extensions mechanism to me ;)

> We probably also need to consider the classloader hierarchy which is
> going to operate under Ant2. I'm sort of expecting a situation where
> Ant2 would be run with an empty classpath (enforced in the pesky
> scripts). 

+10000000000000000000000

> The root classloader would contain the shared class resources
> - mostly interfaces that allow the core to talk to tasks - such as the
> task interface, task context etc. The core and tasks would have separate
> loaders so nothing else would be shared. This would allow tasks to have
> their own XML parsers, for example, without bumping into the parser
> being used by the core. OTOH, some tasklibs may want to have access to
> these sorts of common resources, so we may allow a tasklib to specify
> where in the classloader hierarchy its classloader lives. In any case
> the task would not have access to the bulk of the core's classes.

I was thinking of having

system (clean) <-- common     <-- container
                              <-- each tasklib

where common includes the Task API and our "framework". We need to share the 
framework part because it is often the case where tasks will need to share 
common resources (like DataType instances) in a graceful manner.

> > I largely like it but I am comfortable with XML. As a few people (Conor?)
> > pointed out it is less intuitive and much more complex if you are forced
> > to use namespaces for tasks (aswell as for aspects, and perhaps for inter
> > build file referencing and ...).
>
> I think namespace qualifiers on all task references is probably a little
> clumsy and I prefer the java import style, with the potential addition
> of aliasing, to declare a name in the flat task namespace.

+1

-- 
Cheers,

Pete

---------------------------------------------------
Murphy's law - "Anything that can go wrong, will." 
(Actually, this is Finagle's law, which in itself 
shows that Finagle was right.)
---------------------------------------------------