ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Oxspring" <>
Subject RE: [DISC] details of task library concept
Date Thu, 24 May 2001 21:33:06 GMT
I'm happy with people using the Class-Path manifest entry if it achieves
what they want but this seems very restrictive since it is all relative to
the jarfile location.  The Ant-Class-Path would solve this to a certain
degree although I would like the current directory to be included in the
search.  However, we seem to be moving towards an META-INF/{..}/antlib.xml
within the .tsk where the rest of the library's configuration information is
and it seems silly to separate the dependancies from this file.

Also [thinking aloud] this may allow us to be more clever and include
version information within the the dependancy, and also to be clear about
where the dependancies lie - so in the following example if I decide to
remove mytask from the library, I can see at a glance that the java.tsk is
no longer required.  This sort of versoning would be an extra level of
failing fast as Ant finds it doesn't have the appropriate libraries,
although wouldn't help fighting standard jar versions.

<tasklib name="rjo" version="1.1">
	<depends library="core.tsk" minver="2.0" maxver="3.0">

	<taskdef name="mytask">
		<depends library="java.tsk" minver="1.0" maxver="1.0.1">

Ah well, just my 2p


> -----Original Message-----
> From: Peter Donald []
> Sent: Thursday, May 24, 2001 8:16 AM
> To:
> Subject: RE: [DISC] details of task library concept
> At 05:09 AM 5/24/01 +0100, Jose Alberto Fernandez wrote:
> >> More than likely you will have to go through strings (or strings
> >> referencing properties). Again to keep everything maintainable and
> >> low-coupling.
> >>
> >
> >And error prone. Maybe I am from an old school but Ithink strong
> typing is
> >good.
> >All these do-it-with-strings remins me of untyped languages
> which they may
> >be low copling but they can hide simple bugs preatty good.
> I prefer it but the problem is we will not be able to support it. If you
> look at the evolution of certain classes the types while remaining
> relatively the same from xml point of view often change
> implementation wise
> and with the addition of BeanInfo like constructs this will become even
> more problematic for  people who want to directly access task attributes.
> >> >> deployment != loading
> >> >>
> >> >still, why should I be mocking around with P4 is I use CVS.
> >> Why should I be
> >> >locking at weblogic if I use websphere, etc, etc.
> >>
> >> So you would prefer that all tasks be explicitly imported? I
> >> wouldn't mind
> >> that (actually I would like it) but I thought most other
> >> people didn't like
> >> that ;)
> >>
> >
> >Not all tasks, but all libraries. In particular, if you think
> that not all
> >installations will have all libraries. Like with the "import"
> statement in
> >Java, explicitly mentioning dependencies is best.
> I agree - wanna convince everyone else ? ;)
> >> namespaces.
> >
> >How are you going to assign the name spaces? I hope the writer of the
> >buildfile has a say on what names to use.
> Haven't been discussed enough but my assumption is something like.
> Namepsace+default prefix defined by library writer however
> library user can
> overide prefix (but not namespace).
> >EJB jars specify dependencies in the XML descriptor. As Sun puts it,
> >Class-Path is not really for high level dependency specification but low
> >level JVM security. When you have a container be EJB, Servlet, etc. The
> >point is that Class-Path is to close to a particular layout of the file
> >system to be any good for an open framework and multiple implementations.
> not really - it
> >So, it is not that they ignore it, it is enforced by the JVM, in
> reality it
> >is just not used. Look at TOMCAT and the way war files are
> structured. They
> >do not use Class-Path at the TOMCAT level.
> actually they do ;) (Or at least some of the jars in my wars do). The wars
> themselves may not use Class-Path: etc but that is because they are a
> deployment archive rather than a component archive (like the jars in lib
> directory). Our task libraries are component archives and should probably
> use the same mechanism.
> >I think the same applies to ANT. If it is installed in a multiuser system
> >(yes, those still exist)
> almost all my installations of ant (except those for apache projects) are
> multiuser ;)
> >one does not want to have the same set of libraries
> >for every project of every one, without any alternative but each person
> >installing and maintining its own copy of ANT.
> right - though I am not sure what your point is here. Either method will
> work in this case whether jars are sucked from ~/antlib/,
> /usr/local/ant/lib or ./antlib/ this should all work fine.
> Cheers,
> Pete
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof."                   |
> |              - John Kenneth Galbraith               |
> *-----------------------------------------------------*

View raw message