> >I'm not asking for this dependency, but out of interest: what policy
> >violation?
> >
> >
> Section 7.2, the definition of Depends and Suggests:
Okay, I thought you had some other policy violation in mind beyond just
"depends is inappropriate here", which we both already agree it clearly is
What do you mean "build files for jython projects"? Do you just mean it
provides an editor with jython syntax highlighting/etc? Or do you mean
it compiles jython files?
The second one.
Note that jython is an implentation of python, and so most jython scripts
are run directly (with no compila
> I'm not familiar with jython either. What I am assuming is the
> following: that the jython ant task provides a way to write build files
> for jython projects.
What do you mean "build files for jython projects"? Do you just mean it
provides an editor with jython syntax highlighting/etc? Or do
[I posted this on Dec 22nd, but it seems it never got through, so I
repost it.
Since then I found bug #211560, which raises a similar concern with ant.
It was sent in mid September, and did not get any answer. We really need
to address this issue.]
Ben Burton wrote:
Let me preface this by sta
Let me preface this by stating that I know very little about ant, and I
have no idea how ant specifically interacts with jython.
Jython itself is an implementation of the python scripting language.
The python package does not suggest every package that uses python
scripting, nor does it suggest e
Hallo Daniel,
* Daniel Bonniot wrote:
>>AFAIK the junit task is in the optional.jar.
>Agreed with that. The change concerned jython and antlr.
Ok, after some more thought I've finaly understood, why there were
'dangling symlinks'. The jython.jar had to be symlinked into
/usr/share/ant/libs too.
On the other hand, having jython depend on (or recommend or suggest) ant
is quite nonsensical as well, since ant is not really a tool for script
writers - in fact jython is not enhanced by ant at all.
The way I see things, it is: ant provides a different interface to call
the jython interpreter.
> I think the dependency on junit sort of makes sense since it can be
> considered a basic tool for java developers. The same cannot be said of
> jython and antlr.
On the other hand, having jython depend on (or recommend or suggest) ant
is quite nonsensical as well, since ant is not really a to
I'm not sure about jython (haven't looked), but optional.jar has the
glue for junit (->junit task). Junit knows nothing about ant.
I think the dependency on junit sort of makes sense since it can be
considered a basic tool for java developers. The same cannot be said of
jython and antlr.
AFA
Hallo Daniel,
* Daniel Bonniot wrote:
>You mean that optional.jar has specific knowledge about jython?
I'm not sure about jython (haven't looked), but optional.jar has the
glue for junit (->junit task). Junit knows nothing about ant.
>>This
>>means that if any package wants to use a task in its
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 w
Hallo Daniel,
* Daniel Bonniot wrote:
>Since version 1.5.3-2, the package ant depends on jython and antlr. The
>justification was:
>* Depend on the previously suggested packages jython and antlr to avoid
>dangling symlinks in /usr/share/ant/lib
[...Policy...]
>It seems pretty clear that ant d
Hi java maintainers,
Since version 1.5.3-2, the package ant depends on jython and antlr. The
justification was:
* Depend on the previously suggested packages jython and antlr to avoid
dangling symlinks in /usr/share/ant/lib
The Debian policy, section 7.2, says:
* Depends
This declares an ab
13 matches
Mail list logo
