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
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
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 :
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.