Hello The only question left is whether we also put the apidocs into the pear package. I've looked around a bit but judging on the ones I have installed this seems not be usual. It would also be a problem as PEAR is done in the "default:package" and the apidocs in "site:site" goal...
bye, -christian- Am Fri, 30 Oct 2009 06:54:37 +0100 schrieb Christian Grobmeier <[email protected]>: > > 1. The source .tar.gz and .zip contain the site/coverage-report/ > > directory. While including the generated phpdoc could be > > considered useful for people who just want to use log4php and not > > rebuild it, the coverage report seems pretty useless to me. > > Yes, I think so. > > > 2. Should we distribute the apidocs alongside the .tar.gz even if > > they could be generated by the user using maven? > > I would include API docs because the risk that a user needs em is > quite high. > > > 3. The package-config.php and package.php are not included in > > the .tar.gz and .zip. IIRC because they are not needed by the > > endusers but it just came to my mind that this means that the > > user cannot generate the phpdoc using "mvn site" as this would > > fail due to the missing files. Ok, maybe phpdoc is generated before > > the pear package, I don't remember, but it looks a bit > > unprofessional if we distribute the pom.xml but know that it will > > fail with errors, or? > > I agree again :-) IMHO a user should be able to run tests, coverage > reports etc. all himself. > This also goes for pear packages. > > > > 4. The creation of the superfluous empty .jar will not annoy any of > > the reviewers, or? I have no idea how to turn it off and it would > > probably require an ant task to simply remove it. > > Voting is upon the assemblies itself, not on the creation process. We > will not distribute this jar > nor would we make it available for voting. Means, nobody will be > annoyed of that. > We can change the packaging mode to "dir" maybe and then only a > directory will appear. > If we want something else, we would have to create a custom lifecycle > binding, but I don't think > we need this at the moment. > > Cheers, > Christian > > > > > bye, > > > > -christian- > >
