ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: [DISC] details of task library concept
Date Thu, 24 May 2001 04:09:39 GMT
> From: Peter Donald []
> >> >Others need to manufacture or fill-in parameter types to
> >> pass to other
> >> >classes and those parmameters have different custom types
> (not just
> >> >strings).
> >>
> >> That is nothing that can't be done with proposed solution.
> >>
> >
> >The question os how easy will all that be. Are going to have typed
> >attributes as we have today or are you thinking on moving
> away from that due
> >to TOM?
> >
> >If we keep them, which I hope we will since I like the use
> of strong typing
> >as oppose to loose interfaces, can I pass my file attribute
> to another task
> >requiring files, or do I need to go through strings due to this TOM.
> 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
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.

> >A pattern I use alot, is for out tasks to extend the <java>
> task. With that,
> >we only need to add attributes reflecting the different
> options and you can
> >quickly have a task that interfaces a command-line tool.
> >
> >Will I be able to do that or will I need to write only
> delegation patterns.
> >The advantage of extending is that you get for free all the
> features of
> ><java>: fork, -Doptions, etc, etc. Which they are needed in
> many cases or
> >for certain runs.
> Me too - not sure how to handle this specifically. In a sense
> having all
> the extra features for "free" is a bad thing as it can
> complicate derived
> tasks. We may have to define some inheritance friendly
> abstract tasks in
> framework to get around some of these issues or we may not.
> >> 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.

> >> Thats not something I would ever wish on anybody. Having just
> >> gone through
> >> .so hell and having much expereince with .dll and .jar hell I
> >> would pity
> >> anyone who has to do this for anything great size.
> >>
> >
> >So how are you going to resolve having the same task name
> being used by two
> >different .tsk files? A classloader is not going to help you
> with that.
> 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.

> >Yet another feature that does not exists, with a syntax
> different from XML.
> >What does having this in the manifest entry gives you that
> having it in the
> >XML descriptor does not.
> It is closer to standard Java syntax and it can be sucked in
> without having
> to read descriptor which means certain operations are easier
> to perform
> (getting all resources with same name etc) before get to
> descriptor. We can
> also build it into classLoader to get around the various
> issues that arise
> when doing things in a SecurityManager.
> >BTW, ejbs do not use Class-Path for dependencies they use
> XML. so I am not
> >comming up with something never heard before. We do I need
> to maintain two
> >files when I can do with just one.
> They don't - didn't know that. So ejb jars ignore Class-Path
> manifest entry
> and get all classpath data from their descriptors? Seems to
> go against most
> of the other APIs - kinda odd choice for them I guess.

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.

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.

I think the same applies to ANT. If it is installed in a multiuser system
(yes, those still exist) 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.

Jose Alberto

View raw message