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 :
./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.
[1] http://ftp-master.debian.org/REJECT-FAQ.html
[2] http://www.debian.org/doc/packaging-manuals/java-policy/x104.html
Cheers,
--
Damien
signature.asc
Description: This is a digitally signed message part.
