Hi all, I have been starting to experiment whether and how we could deploy Sling JavaDoc and/or sites. This turned out into an experiment of fooling around with the maven site plugin ....
I did not really succeed in generating a basic site, which provides links from the root pom to the modules, since the site plugin does not do this correctly. If we could at least deploy each module separately and still keep some links to a "root page", it would still be ok, I thnk. I am still working on that. What I have had some kind of success is in the generation of an aggregate JavaDoc. But this contains a lot of classes, which are not exported by the bundles and thus may no tbe used. For this reasona I created SLING-916 with the goal to have (almost) all non-exported classes in packages whose name contains impl or internal. I have done this for the main bundles with the exception of the scripting/jsp (repackaing might break compiled JSPs) and the jcr/jackrabbit-usermanager (needs some more investigation). I also set up the root pom to by default not include impl and internal packages in the JavaDoc. In addition a project may set the site.javadoc.exclude property to a list of packages to add to the excludePackageNames configuration property of the javadoc plugin (in addition to impl and internal). More to be documented on the site ... If you encounter any issues with my repackaging, please shout. Thanks. Regards Felix Felix Meschberger (JIRA) schrieb: > Consistently place non-exported classes into packages containing impl or > internal > --------------------------------------------------------------------------------- > > Key: SLING-916 > URL: https://issues.apache.org/jira/browse/SLING-916 > Project: Sling > Issue Type: Improvement > Components: General > Reporter: Felix Meschberger > Assignee: Felix Meschberger > > > To simplify generation of JavaDocs as well as for consistency, internal > classes should always be located in packages whose name contains > either impl or internal. All Sling bundles, which contain a mix of exported > and private packages are currently already implemented like this. > > Sling bundles, which do not export anything, for example the commons/log or > the extensions/fsresource bundle, are not implemented in this way. > > This issue is about aligning these bundles with the consistent setup. >
