[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: animal-sniffer-parent

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 [1] 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 [2]).
-> 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.

[1] http://ftp-master.debian.org/REJECT-FAQ.html
[2] http://www.debian.org/doc/packaging-manuals/java-policy/x104.html


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: