Hi Matthias, Here is a more extended review of your package. Le samedi 30 avril 2011 21:12:07, Matthias Schmitz a écrit : > > - on source package name: I don't think we should name it with a > > "-parent" suffix ("-parent" imply for me that only parent POM is > > included) > > first i named it only "animal-sniffer" but upstreams svn tag name is > animal-sniffer-parent-1.6 so the created orig tarball was named > animal-sniffer-parent_1.6.... and i renamed the source package :-). The tag is named like that because in pom.xml file, artifactId is set to "animal-sniffer-parent". So when upstream make a new release (with maven- release-plugin) this artifactId is used a tag name "format". But for me that's orthogonal to upstream source package name. Is it ok for your to rename it ? > > - binary packages count: I don't know if its really necessary to split > > packages that much. Is there really a big number of dependencies ? > > First i tried to package only the animal-sniffer.jar with a single > source / binary package but this needs the java-boot-classpath-detector > and i start another single source / binary package. But this seems > wrong because it comes both from the same source and so this bigger > package was created. Should i melt all together in one binary package? > It seems a neat idea to create a single binary package for every sub > module (The jar, the Maven plugin, the Ant task and so on). YMMV, but for my point of view 1) animal-sniffer is a small package 2) there is no big dependency chain, I see no need to split it that much: 65000 for orig.tar.gz 5492 libanimal-sniffer-annotations-java 9078 libanimal-sniffer-annotations-java-doc 254552 libanimal-sniffer-ant-tasks-java 15690 libanimal-sniffer-ant-tasks-java-doc 10372 libanimal-sniffer-enforcer-rule-java 13642 libanimal-sniffer-enforcer-rule-java-doc 23936 libanimal-sniffer-java 24050 libanimal-sniffer-java-doc 22302 libanimal-sniffer-maven-plugin-java 17420 libanimal-sniffer-maven-plugin-java-doc 6904 libjava-boot-classpath-detector-java 9540 libjava-boot-classpath-detector-java-doc You can check FTP Master Reject FAQ  for explanation of my point : You split a package too much or in a broken way. Well, broken or too much is a wide definition, so this is a case-by-case thing, but you should really think about a split before you do it. For example it doesn't make any sense to split a 50k arch:all package from a 250k arch:any one. Or splitting a package for only one file, depending on the main package. Yes, big dependency chains can be a reason. Or big documentation splitted into one -doc package. The point there is big. Another - linked - comment I have is about providing -doc packages with Javadoc API. For example, libjava-boot-classpath-detector-java-doc, contains only one class Javadoc HTML file : ShowClassPath.html This HTML page doesn't contains any comment/documentation from upstream, only auto-generated info. I see no added value to provide this package (and many others -doc package seems to be on the same pattern) -> Maybe you can 1) move all Javadoc to a common package like libanimal- sniffer-java-doc 2) disable Javadoc modules with no added value 3) install Javadoc to /api-<component>/ (see Java Policy ). -> In animal-sniffer cas, valuable documentation is contained in src/site of each module. Maybe you can generate/provide it ? Regarding source tarball content, there is two binary files without source : ./animal-sniffer-enforcer-rule/src/it/setup-001/src/main/signatures/api-1- SNAPSHOT.signature ./animal-sniffer-enforcer-rule/src/it/setup-002/src/main/signatures/api-2- SNAPSHOT.signature You should removed it and/or find source of them. I haven't any other remark about your work, so we might be able to upload it soon. Thanks for you work.  http://ftp-master.debian.org/REJECT-FAQ.html  http://www.debian.org/doc/packaging-manuals/java-policy/x104.html Cheers, -- Damien
Description: This is a digitally signed message part.