Re: J2SDK question
Hallo Jerry, * Jerry Haltom wrote: >What is the chance of having mpkg-j2sdk in main? Almost none: If we upload it (or it successor), it will go to contrib due to unfreeness of JDKs. If Sun derived JDKs switch to a Licence, we can use in main, it will be packaged and uploaded to main and mpkg-j2sdk will not be needed anymore. So the answer is: We can have it in contrib. Actually now. Takashi, didn't you want to do the upload? Jan -- Jan Schulz [EMAIL PROTECTED] "Wer nicht fragt, bleibt dumm." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ant dependency on jython and antlr
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 absolute dependency. A package will not be configured unless all of the packages listed in its Depends field have been correctly configured. The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality. [...] * Suggests This is used to declare that one package may be more useful with one or more others. Using this field tells the packaging system and the user that the listed packages are related to this one and can perhaps enhance its usefulness, but that installing this one without them is perfectly reasonable. It seems pretty clear that ant does not *depend* on jython or antlr, since those are not required for ant to "provide a significant amount of functionality." The Suggests was probably right. Now I understand the technical problem there was with the dangling symlink. However, I think the propoer solution for this would be to have the link in the jython and antlr packages, respectively. They should probably suggest ant, too. Note that this is what the eclipse-javac package does: it includes the ant link: $ dpkg -L eclipse-javac|grep ant/lib /usr/share/ant/lib /usr/share/ant/lib/jdtCompilerAdapter.jar /usr/share/ant/lib/jdtcore.jar $ ls -l /usr/share/ant/lib/jdtcore.jar lrwxrwxrwx1 root root 60 Aug 3 15:28 /usr/share/ant/lib/jdtcore.jar -> ../../eclipse/plugins/org.eclipse.jdt.core_2.1.1/jdtcore.jar Eclipse-javac should additionally at least suggest ant, I think. 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/.jar to the jar file including the task. It should also at least suggest the package ant." Cheers, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ant dependency on jython and antlr
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 does not *depend* on jython or antlr, >since those are not required for ant to "provide a significant amount of >functionality." The Suggests was probably right. 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). 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. 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. >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 be used from make programms' Suggests: make. >Note that this is what the eclipse-javac package does: it includes the >ant link: [...] >Eclipse-javac should additionally at least suggest ant, I think. I'm not sure about this. I put the jars into that dir as it provides 'JavaCompilerAdapter', which can be used with the build.compiler property. The main functionality is actually in /usr/bin/jdtc. >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/.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 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 :) 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. Jan -- Jan Schulz [EMAIL PROTECTED] "Wer nicht fragt, bleibt dumm." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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/.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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ant dependency on jython and antlr
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 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. AFAIK the junit task is in the optional.jar. >>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. If thats consensus (sp?), so it be :) >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? I'm not sure, but if ant Depends on jython, it seem so... >>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. Yes, thats true. Only that a user won't know the difference... >>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? No, but all other packages will have mostly one purpose: adding a task. For them to Depends: on ant would be kind of natural. [splitting optional.jar] >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? Nothing, but it's quite a task to coordinate that or even provide pacthes for upstream and telling apache ants people to stop including that tak in there distribution... >>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. We have the same problem (optional.jar surely will not compile without junit installed), but we distribute binary packages, so we could add only suggests and the actual packages, which use the task could Depends: on the 'functionality' package. gentoo doesn't have that option, as they build from source... Anyway, the more I have to do with java packaging, the more braindead it seems to me... Jan -- Jan Schulz [EMAIL PROTECTED] "Wer nicht fragt, bleibt dumm." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: J2SDK question
make-j2sdk itself depends on having non-free stuff installed? I thought it was just a little script to create a .deb from a Sun provided SDK. On Sat, 2003-12-20 at 04:47, Jan Schulz wrote: > Hallo Jerry, > > * Jerry Haltom wrote: > >What is the chance of having mpkg-j2sdk in main? > > Almost none: > If we upload it (or it successor), it will go to contrib due to > unfreeness of JDKs. If Sun derived JDKs switch to a Licence, we can > use in main, it will be packaged and uploaded to main and mpkg-j2sdk > will not be needed anymore. > > So the answer is: We can have it in contrib. Actually now. Takashi, > didn't you want to do the upload? > > Jan > -- > Jan Schulz [EMAIL PROTECTED] > "Wer nicht fragt, bleibt dumm." > signature.asc Description: This is a digitally signed message part
Re: ant dependency on jython and antlr
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. AFAIK the junit task is in the optional.jar. Agreed with that. The change concerned jython and antlr. 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. Yes, thats true. Only that a user won't know the difference... I don't see the problem from the user's point of view. If he wants to use ant for development, he will 'apt-get install 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? No, but all other packages will have mostly one purpose: adding a task. For them to Depends: on ant would be kind of natural. Not necessarily. For instance, I am packaging a compiler, that happens to include a ant task. It's not its main purpose, just a additional feature. [splitting optional.jar] 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? Nothing, but it's quite a task to coordinate that or even provide pacthes for upstream and telling apache ants people to stop including that tak in there distribution... I'm not asking for the upstream ant to be broken into pieces, because I agree it would be lots of work. if somebody wants to do it, fine! We have the same problem (optional.jar surely will not compile without junit installed), but we distribute binary packages, so we could add only suggests and the actual packages, which use the task could Depends: on the 'functionality' package. gentoo doesn't have that option, as they build from source... I'm fine with ant Depends junit, but not jython or antlr. Ant could Build-depend on them, of course. Regarding the symlinks, I think they rather belong to jyton and antlr, as this makes sure they are not dangling. However I'm fine with the original solution too (have them in ant). Dangling symlinks are not a policy violation or Anyway, the more I have to do with java packaging, the more braindead it seems to me... Now, don't be pessimistic! There _has_ to be a way to do things right ;-) Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: J2SDK question
On Sat, Dec 20, 2003 at 11:41:56AM -0600, Jerry Haltom wrote: > make-j2sdk itself depends on having non-free stuff installed? I thought > it was just a little script to create a .deb from a Sun provided SDK. If you don't have the sdk, it is useless. Therefore, it depends on non-free software and does not belong in main. -- .''`. Mark Howard : :' : `. `' http://www.tildemh.com `- [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: ant dependency on jython and antlr
> 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 tool for script writers - in fact jython is not enhanced by ant at all. The relationship works the other way around: jython enhances the functionality of ant. So from a purely semantic point of view it seems that ant should provide the suggests/recommends/depends. > I'm fine with ant Depends junit, but not jython or antlr. Ant could > Build-depend on them, of course. Indeed there is no problem with ant build-depending on lots and lots of stuff. This will not affect the everyday user, who'll just be installing it. As for dangling symlinks, I'd be inclined to say don't worry about it. I have this situation in one of my own packages: kdbg provides a symlink to the KDE common directory for each of its translated languages. So (for instance) if kde-i18n-fr is not installed then kdbg has a dangling symlink. I can't possibly require every user to install the (very large) kde-i18n packages for each language that the kdbg docs are translated into. It's also not feasible for kde-i18n-fr to provide this symlink for every app that has French translations (for instance). So the symlink is just left dangling, and if a user is reading the French docs then they almost certainly have kde-i18n-fr installed so there is not actually a problem. > >Anyway, the more I have to do with java packaging, the more braindead > >it seems to me... > > Now, don't be pessimistic! There _has_ to be a way to do things right ;-) hehe.. I must say I also reached Jan's state of mind some time ago. :) b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ant dependency on 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 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. Look at it this way: if I need to use jython (I have jython source i'd like to compile or execute), I might find ant a useful tool, as a way to specify the compilation options. On the other hand, if I need to use ant (say, to write a build script for a complex Java project), how would jython be a tool to help me in that? It's the same relationship as between a compiler and an editor: the editor helps me use the compiler, the compiler does not help me use the editor. The relationship works the other way around: jython enhances the functionality of ant. Is the point that you can write python code inside your build.xml? If so, then I agree. From what I saw, the task is more like glue to call the jython compiler, and then I disagree. (for antlr, it's even more obscure how it could enhance ant) Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ant dependency on jython and antlr
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. This will not happen anymore, if we could agree on the proposed policy: You would just add a DEPENDS="..." line, which would give you the jars via 'java-config --all ant' (omitting any package, which it can't find). No symlinks nessesary. Tasks could actually be added via a $HOME/.antrc file, giving the user the possibilty to choose from different implementations. >Regarding the symlinks, I think they rather belong to jyton and antlr, >as this makes sure they are not dangling. However I'm fine with the >original solution too (have them in ant). Dangling symlinks are not a >policy violation or As said above: if we agree on java-config to sort out the CLASSPATH, we don't need any symlinks anymore. >>Anyway, the more I have to do with java packaging, the more braindead >>it seems to me... >Now, don't be pessimistic! There _has_ to be a way to do things right ;-) Of course. But mostly it is something which the upstream author hasn't even thought about. Just think about the whole 'not sun-derived' JVM mess... For example the javadoc task, which is IMO a very essetial task, will not work with pure 'main' packages). [EMAIL PROTECTED]:~/psgr$ /usr/lib/kaffe/bin/javadoc java.lang.ClassNotFoundException: sun.tools.javadoc.Main at kaffe.lang.AppClassLoader.findClass (AppClassLoader.java:296) at java.lang.ClassLoader.loadClass (ClassLoader.java:142) Or packaging all dependencies in one package, like most java apps do... Jan -- Jan Schulz [EMAIL PROTECTED] "Wer nicht fragt, bleibt dumm." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: J2SDK question
Hallo Jerry, * Jerry Haltom wrote: >make-j2sdk itself depends on having non-free stuff installed? I thought >it was just a little script to create a .deb from a Sun provided SDK. It depends on a *-bin download, which is unfree (and not even packaged). In general, install for unfree things ar ein contrib. Jan -- Jan Schulz [EMAIL PROTECTED] "Wer nicht fragt, bleibt dumm." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ant dependency on jython and antlr
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 every package that provides a simple interface for editing python scripts. The relationship works the other way around: packages that use python scripting will need to depend on python, and packages that provide script writing facilities will probably suggest python also. In a similar way, it does not seem sensible for the jython maintainer to hunt down every package that might use python scripting or offer a fancy interface for writing python scripts. > Look at it this way: if I need to use jython (I have jython source i'd > like to compile or execute), I might find ant a useful tool, as a way to > specify the compilation options. You might also find bash a useful tool (for the same purpose). Or make. You might find vim a useful editor. Or emacs, or kate. Or anything else with python-specific support. You might find idle a useful IDE (this is python after all). I could go on. > It's the same relationship as between a compiler and an editor: the > editor helps me use the compiler, the compiler does not help me use the > editor. But neither suggests the other. > On the other hand, if I need to use ant (say, to write a build script > for a complex Java project), how would jython be a tool to help me in that? Can you please write a more detailed account of how ant relates to jython? This would probably be a helpful addition to this discussion. :) Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
