... upstream release [1]. That advice is plain wrong. (And it's not part of the actual Java policy as the page says.) No, it's not. It's a good idea to remove generated javadoc and jar files and classes. Very much so. Unless you build from source, you have no way to know that the binaries correspond to that source code. You can't even guarantee that you're ...

On 12/12/06, Marcus Better <marcus@better.se> wrote: Arnaud Vandyck wrote: It's a good idea to remove generated javadoc and jar files and classes. Well, let's agree to disagree. :) ;-) They can be removed to use less space and be sure not to include code that has been build with non free dependencies. The space argument is rather weak IMHO, and certainly shouldn'...

Marcus Better wrote: Arnaud Vandyck wrote: It's a good idea to remove generated javadoc and jar files and classes. Well, let's agree to disagree. :) They can be removed to use less space and be sure not to include code that has been build with non free dependencies. The space argument is rather weak IMHO, and certainly shouldn't warrant rebuilding a source ...

Andrew Haley wrote: It's a good idea to remove generated javadoc and jar files and classes. Very much so. Unless you build from source, you have no way to know that the binaries correspond to that source code. You can't even guarantee that you're not violating the GPL, which requires you to provide source code on demand. That may be a valid argument, but there are more ...

On Wed, 13 Dec 2006, Marcus Better wrote: Andrew Haley wrote: It's a good idea to remove generated javadoc and jar files and classes. Very much so. Unless you build from source, you have no way to know that the binaries correspond to that source code. You can't even guarantee that you're not violating the GPL, which requires you to provide source code on demand. ...

Marcus Better <marcus <at> better.se> writes: Andrew Haley wrote: It's a good idea to remove generated javadoc and jar files and classes. Very much so. Unless you build from source, you have no way to know that the binaries correspond to that source code. You can't even guarantee that you're not violating the GPL, which requires you to provide source ...

... quality issue. Can you please be more specific, Yes, I can give examples, but not until next week though. It has to do with bugs, even important ones, not getting attention. For a quick idea, look at the history of mysql-connector-java which was recently pushed through to etch, after a being nearly unusable for a long time. 2. perhaps a step to make those issues visible and more ...

Hi Matthias, On Thu, 2007-01-11 at 21:11 +0100, Matthias Klose wrote: The idea was to make the -doc packages depend on other -doc packages so that references to other packages can be resolved; unfortunately gjdoc doesn't support that yet. What would you need from gjdoc to support 'that'? Could you give an example, I am afraid I was unable to follow the discussion to see what is ...

Mark Wielaard writes: Hi Matthias, On Thu, 2007-01-11 at 21:11 +0100, Matthias Klose wrote: The idea was to make the -doc packages depend on other -doc packages so that references to other packages can be resolved; unfortunately gjdoc doesn't support that yet. What would you need from gjdoc to support 'that'? Could you give an example, I am afraid I was unable to...

... java.util.Map), should I link to http://java.sun.com/j2se/1.5.0/docs/api/ or what? No, please depend on classpath-doc and use these. We dont wanna link to resources on the net. The idea is to have all on your hard disk when you install the *-doc packages. Michael -- .''`. | Michael Koch <konqueror@gmx.de> : :' : | Free Java Developer <http://www.classpath.org> `. `' | `-...