Re: ant dependency on jython and antlr
There is a problem with all this: The ant package has one big jar for
all available tasks (the optional.jar has all the 'Task's, the
junit, jython and so are only called from that task definitions).
You mean that optional.jar has specific knowledge about jython?
This
means that if any package wants to use a task in its build, it will
Build-Depends: on ant and will think that it works.
That should be OK if it needs a core or optional ant task.
In the current
setup, it will. With your setup, all packages, which will use a
additional task need to Build-Depends: on junit, jython or whatever.
If a package needs the jython task, it seems normal to me that it would
need to Build-depend on both ant and jython.
the link in the jython and antlr packages, respectively. They should
probably suggest ant, too.
They have nothing to do with ant. Only the tasks in optional.jar does
include some glue to make them useable from ant. Jython knows nothing
about ant, Same with junit and so on.
On http://ant.apache.org/manual/optionaltasklist.html I don't see any
mention of jython. There is a antlr task, though. Does jython now belong
to the optional tasks of ant upstream?
What you suggests is 'could be
used from make programms' Suggests: make.
The difference is that no 'glue' is needed for a Makefile to make use of
a program.
Does everybody agree? Should this be made part of the Java policy? Here
is my proposal:
"If a package provides ant tasks, it should include a symlink from
/usr/share/ant/lib/<package-name><suffix>.jar to the jar file including
the task. It should also at least suggest the package ant."
This is already done: ant dows provide all tasks in optional.jar and
IMO, it shouldn't Suggests: ant :)
Are you implying that only ant is supposed to provide ant tasks?
IMO the proper sollution for this is to split the optional.jar into
bits and include one task per jar (or groups them). This packages
would then Depends: on each underlying programm/library/whatever. This
will at least happen with each additional task. Unfortunatelly this
will not be possible, because one task is probably 'encoded' in one
class file and James will not let us have that small packages :)
It's a possible design, which sounds ok to me. Alternatively, what would
be wrong with including the task in the package that provides the
underlying facility? Actually, I think both are fine, and one can decide
which one to apply based on the specifics of each package (size,
upstream source for the task, ...)
If we are looking for similar situations: packages regularly include
emacs-lisp code that provide support for the program. For instance, the
ocaml language includes the emacs mode to pretty-print ocaml source and
call the compiler.
Please note, that the gentoo guys (gentoo-java ML) currently discuss
the same problem: They have the problem that ant requires all
underlying programm/library/whatever be available at buildtime.
Which is brain-dead, do we agree on that? Besides violating our Policy,
as I explained.
Cheers,
Daniel
Reply to: