There is a problem with all this: The ant package has one big jar forYou mean that optional.jar has specific knowledge about jython?
all available tasks (the optional.jar has all the 'Task's, the
junit, jython and so are only called from that task definitions).
ThisThat should be OK if it needs a core or optional ant task.
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.
In the currentIf a package needs the jython task, it seems normal to me that it would need to Build-depend on both ant and jython.
setup, it will. With your setup, all packages, which will use a
additional task need to Build-Depends: on junit, jython or whatever.
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?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.
What you suggests is 'could beThe difference is that no 'glue' is needed for a Makefile to make use of a program.
used from make programms' Suggests: make.
Are you implying that only ant is supposed to provide ant tasks?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 :)
IMO the proper sollution for this is to split the optional.jar intoIt'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, ...)
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 :)
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 discussWhich is brain-dead, do we agree on that? Besides violating our Policy, as I explained.
the same problem: They have the problem that ant requires all
underlying programm/library/whatever be available at buildtime.
Cheers,
Daniel
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]