Re: Re: Java policy draft; a road map proposal...
Pierre Métras writes: > > Wolfgang Baer wrote: > > [...] > > > Beside that I recognize the value a Java Developer Guide could have. > > > I definitely agree, many thanks Pierre for volunteer :-D > > OK, I volunteer but I'll start small, improving the wiki content when I find > some time... > > Perhaps my thought has been mis-interpreted. I don't think that we > need to write a Developer Guide now, as it will spread our too > limited resources on too many goals. Maybe such a Developer Guide would also be useful for other GNU/Linux distributions. OK, there are a few Debian-speciic issues, but surely most of the problems a developer might encounter are more general than that. I'm aware from the questions we get asked on the gcj list that we need some proper user documentation. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Java policy draft; a road map proposal...
> Wolfgang Baer wrote: > [...] > > Beside that I recognize the value a Java Developer Guide could have. > I definitely agree, many thanks Pierre for volunteer :-D OK, I volunteer but I'll start small, improving the wiki content when I find some time... Perhaps my thought has been mis-interpreted. I don't think that we need to write a Developer Guide now, as it will spread our too limited resources on too many goals. But the way I see the other Debian Policy documents is that they can be read from two sides: first as packaging rules for the maintainer, but also from an external Java developper as guidelines to write Debian friendly applications. For instance, let's peek _at random_ paragraph 10.7 on Configuration files from the Debian Policy (http://www.us.debian.org/doc/debian-policy/ch-files.html#s-config-files). From a maintainer point of view, it tells you where to put the configuration files if the upstream developer has not put them in standard places. But it can also be used to educate upstream authors, as development recommendations: "if you don't know how to name your configuration files and where to put them, just follow the policy and put them into /etc/..." Another example, if I ask, as a Java developer, "where should I put language resource .properties files?". If I can find the answer to this question in the Policy, it would help me in my development. Now, as a packager, the Policy should tell me if language resource files must be considered as configuration files or not and where I should put them. But enough on this subject! Let's drop another idea. What's about "a question a week" posted on the list to make clear some fuzzy points of the Policy. When a consensus is reached, we keep the conclusion and the rationale for it and include it in the Draft. Many points have already been discussed and kept in the wiki, but it seems either no decision has been taken to include the conclusions in the Policy, either no consensus has been reached and everybody has decided to wait for a better idea, some day... -- Pierre Métras
Re: Java policy draft; a road map proposal...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wolfgang Baer wrote: [...] > Beside that I recognize the value a Java Developer Guide could have. I definitely agree, many thanks Pierre for volunteer :-D - -- .''`. : :' :rnaud `. `' `- Java Trap: http://www.gnu.org/philosophy/java-trap.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEEU+d4vzFZu62tMIRAvqxAKCrgekyikKKqnDgv3Dg57Ua9KTxVACcDj4e Yitnij6fQsoj5qFx1xPAGQY= =kjXd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java policy draft; a road map proposal...
Hi, Arnaud Vandyck wrote: > Pierre Métras wrote: > >>>Hello list, > > > Salut Pierre, > > >>>Having read the new Draft page, read again another time many pages on the >>>wiki, in the Java FAQ and in the Java Policy, the java-common bugs, I still >>>stay with the feeling that there is no clear roadmap for Java in Debian, >>>beginning with the Java Policy. You are right that there is a lot to do. However as you wrote only few people care about java and these already do a hard work to keep things going. Help in improving documentation is it updating the Java FAQ, writing a Java Developers Guide or working on the wiki stuff would be greatly appreciated. As well as packagers are welcome :-) > You are right, there is not yet clear roadmap for Java in Debian. The > Debian-Java policy will fix some gaps, but I'm not in for a Debian-Java > Developer's guide in the Debian-Java policy! ;-) > > IMHO, the Debian Java Policy must say that you have to tag a package, > not how to do it. Where to put the api documentation, not how to do it, etc. Right. > But I completely agree with you, we need a Debian Java Developer's guide > or something equivalent. The wiki could be a starting point and a lot of > the topics in your mail MUST be solved. Many thanks for pointing them. > Also (maybe you already know), there are some points that are not easy > to fix :-D > > I'll think about a way to achieve your goal but I *personnaly* don't > want to put the howto's in the policy. That has nothing to do with a personal opinion - it just doesn't belong there. Beside that I recognize the value a Java Developer Guide could have. Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java policy draft; a road map proposal...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pierre Métras wrote: > Hello list, Salut Pierre, > Having read the new Draft page, read again another time many pages on the > wiki, in the Java FAQ and in the Java Policy, the java-common bugs, I still > stay with the feeling that there is no clear roadmap for Java in Debian, > beginning with the Java Policy. You are right, there is not yet clear roadmap for Java in Debian. The Debian-Java policy will fix some gaps, but I'm not in for a Debian-Java Developer's guide in the Debian-Java policy! ;-) IMHO, the Debian Java Policy must say that you have to tag a package, not how to do it. Where to put the api documentation, not how to do it, etc. But I completely agree with you, we need a Debian Java Developer's guide or something equivalent. The wiki could be a starting point and a lot of the topics in your mail MUST be solved. Many thanks for pointing them. Also (maybe you already know), there are some points that are not easy to fix :-D I'll think about a way to achieve your goal but I *personnaly* don't want to put the howto's in the policy. Thanks for your suggestions, - -- .''`. : :' :rnaud `. `' `- Java Trap: http://www.gnu.org/philosophy/java-trap.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEEJJV4vzFZu62tMIRAqAsAJ0XZwP8BG/dn/LsOr+mqllMCWn9CACffYE5 bY9R3K2gjBGjF0yB8re/JQ0= =GdnL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java policy draft; a road map proposal...
Hello list, Having read the new Draft page, read again another time many pages on the wiki, in the Java FAQ and in the Java Policy, the java-common bugs, I still stay with the feeling that there is no clear roadmap for Java in Debian, beginning with the Java Policy. Information is available, here and there, but is frequently obsolete and scattered in numerous places. Experiments and prototypes have been done to solve the CLASSPATH problem, for instance, but no clear and "best" solution has been promoted in the Policy. For years, there have been discussions on debian-java, but the best ideas have not always been promoted in the Java Policy or Java FAQ. Compared with other policies, the Java Policy appears as an alpha draft, with many missing information, either for the Java developper or the Java packager. In this email, I've tried to create the structure of a new Java Policy. My goal was to list all the points that should appear in a complete and extensive Java Policy. There are probably missing ones, and the discussions on the list will pinpoint them and add them to this content list. I expect at least 50% changes! I've tried to be exhaustive in the contents list, at least to give to the future reader or to debian-java discussions the impression that the point has not been missed. Writing that something is irrelevant is richer information than lack of reference. Or for reference to external sources of information. Also, one of the first step is to define precisely the scope of the Java Policy. As the group of Java developpers and packagers on Debian is more limited than for languages like PHP or Perl, I thought that the Java Policy had to be more practical than the equivalent policies for these languages, and include information that we would expect in a Developper Guide. So I have created this table of contents in the spirit of listing the best practices for Java Developpers _and_ Packagers. The Java FAQ will remain complementary for how-to information or beginners questions; and the wiki for fast moving ideas or experiments... Then, with a complete Java Policy Table of Contents, we should been able to fill in the text between the headers, consolidating the information already in the Wiki, debian-java and the bugs system, and of course the present Java Policy draft. I think that having a common structured road map for the Java Policy will help to achieve this long standing graal of Java use on Debian. What do you think? -- Pierre Métras Proposed Java Policy table of contents 1 About this manual 1.2 Scope 1.2.3 Java packages interface definition 1.2.4 Best practices for packagers and developpers 1.3 New versions of this document 1.4 Authors and Maintainers 1.4.3 How to submit updates 1.5 Related documents 1.6 Terms and conventions 2 The Debian Archive 2.2 The package name 2.3 Main, contrib or non-free 2.4 Virtual packages 2.5 Packages relationships 2.6 Subsections 2.7 Tags 3 Binary packages 3.2 Versions and Sun versionning 3.3 User interaction 4 The Operating System 4.2 File system hierarchy 4.2.3 Libraries 4.2.4 Applications 4.2.5 Web applications 4.2.6 Pluggins 4.2.7 Applets 4.3 Environment variables 4.4 Architecture independance 4.5 binfmt_misc registration 4.6 Menus 4.7 Documents associations 4.8 MIME types 5 Virtual Machines 5.2 Free JVM 5.3 Alternatives 5.4 How to find the current JVM 5.5 How to build the CLASSPATH 5.6 Extensions 5.7 Fonts 5.8 Security policies 5.9 Compilers 5.10 Other tools 6 Java libraries 6.2 Class files 6.3 Manifest 6.4 Java archives: JAR 6.5 Native libraries 7 Applications 7.2 Wrappers 7.3 Run-time dependencies detection 8 Applets and pluggins 9 Web applications 9.2 Web containers 9.2.3 Tomcat 9.3 Users, groups, file permissions 9.4 Web archives: WAR, EAR... 9.5 WEB-INF 9.6 Contexts, virtual hosts and configuration 9.6.3 Apache front-end 9.6.4 webapps-common 9.7 External libraries 9.8 Logs 10 Build scripts and IDE 10.2 Ant 10.3 Eclipse/Netbeans 11 Configuration and external files 11.2 Configuration files 11.2.3 Permissions and ownership 11.3 Encoding of text files 11.4 Language files 12 Documentation 12.2 Manual pages 12.3 Javadoc 12.3.3 doc-base 13 Tests 13.2 Junit 14 Misc 14.2 Databases 14.2.3 db-config-common 14.2.4 JDBC 14.3 Network services 15 Advices to Java packagers 15.2 Package maintainers scripts 15.3 CLASSPATH 15.4 Libraries dependencies 16 Advices to Java developpers Annexes Best practices Best tools for Java development on Debian Sun java command line options for compatible alternatives Sun javac command line options for compatible alternatives Ant common build targets CLASSPATH creation example Wrapper with run-time dependencies checks (install vs run-time dependencies example) Javadoc creation and doc-base registration Packaging example for web-app registration with tomcat, jonas, jigsaw, jetty...
