A little more playing around with Maven, ...
$ mvn javadoc:aggregate
This builds a single javadoc collection of the org.jbpm.* packages. All I need to do now is to pull in the org.drools content in.
It would be great if you could share the javadocs. I am new to JBPM and maven and hence it would be helpful if you could share the java docs in the forum or through the email.
I'm working on it - still dealing with the linking to drools content - but when I get something useful I'll let you know.
Just a heads up - org.jbpm.** has no package documentation at all. Documentation inside packages is limited.
A zipped archive of the org.jbpm packages is attached. It is an aggregated javadoc of all of the jbpm packages in the source download built with a link to the published drools packages (however, there appear to be some missing drools packages - as such, some of the links will be broken, e.g. org.jbpm.compiler.ProcessBuilderImpl references classes in the org.drools.compiler package which is not included in the drools javadoc).
jbpm-5.2.0-final-apidocs.zip 3.9 MB
Have just completed the following:
- a github account creation
- a fork of the https://github.com/droolsjbpm/jbpm repository into a new github repo
- a clone of the forkede repo to my local machine
- an update (on my local clone) of the top-level pom to include some structure to the javadoc generation
- resolution of a handful of javadoc errors in the source code
- fixing tag recognition to removed 500+ javadoc compilation errors
- committed my changes to my local clone
- pushed local clone chances back to my forked repository
- issued a pull request for the integration of my fork changes into the jbpm master repository
If this gets accepted it means that we have:
- a buildable javadoc for the org.jbpm packages linked to the core java and drools javadoc
- a structured index page with a breakdown covering:
- Other Packages
- one example package documentation using a package-info.java source file (under org.jbpm.process.audit)
I've attached the javadoc generated from the proposed changes. If you take a look you will see that we still have a way to go on package, class and method documentation -- but this is a start. If you want to contribute - you don't need permission - just fork, clone, make your changes, commit, push, and issue a pull request.
apidocs.zip 3.8 MB
Hi Stephen! That sounds amazing.. I will take a look on the pull request now.
I liike the github process - register, fork, clone, update, commit, push and post a pull request.
What's the usual turnaround time on that last step?
That's the way to go, now you should wait to someone merge the pull request.. It usually takes some time if the team is busy fighting against a release
That's why I post a comment in the pull request.. to just make them easy the work of merging your stuff.. The idea behind pull requests is that the rest of the community members can validate the source code that other members posts..
ETA (based on the mean of past newbie endeavours)?
It really depends on the avalability of the team.. I will do my best to push them to merge your pull request. And it also depends if you fix a bug that can cause big issues.
The quality of our documentation is a big issue.
I.e. a *really* *big* issue.