Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publish documentation and Javadoc #14

Closed
dexX7 opened this issue Sep 24, 2015 · 4 comments · Fixed by #16
Closed

Publish documentation and Javadoc #14

dexX7 opened this issue Sep 24, 2015 · 4 comments · Fixed by #16

Comments

@dexX7
Copy link
Owner

dexX7 commented Sep 24, 2015

The documentation should be published, at least everytime a release is tagged.

This might be done via Travis:

http://docs.travis-ci.com/user/deployment/#Conditional-Releases-with-on%3A

@dexX7
Copy link
Owner Author

dexX7 commented Sep 26, 2015

I'd prefer GroovyDoc over JavaDoc, although I noticed the GroovyDoc doens't pick up the enum constants of the script VerifyFlags (when run via IntelliJ).

@dexX7 dexX7 removed the release label Sep 26, 2015
@msgilligan
Copy link
Collaborator

I used GroovyDoc instead of JavaDoc for OmniJ because it can be used for both Groovy and Java source code and produce a single set of docs. Unfortunately, GroovyDoc has an out-of-date Java parser and doesn't work with several Java 7 features. It also doesn't support the AsciiDoclet plugin which I'm using in bitcoinj-addons. It really needs an update.

Why do you prefer GroovyDoc over JavaDoc for Java source code?

@dexX7
Copy link
Owner Author

dexX7 commented Sep 26, 2015

Why do you prefer GroovyDoc over JavaDoc for Java source code?

For Java source code JD is probably the better choice, but since we have Java and Groovy code, it would be nice to combine both.

I would recommend publishing to Github pages over AWS S3 because it's free. [from the other thread]

Thanks for the tip about GitHub pages! :)

I resolved the initial issue more or less:

  1. a new GitHub API access token was created
  2. the access token is set as secure environment variable via Travis
  3. a deploy script generates the docs, then initializes a new repo locally, and force pushes to gh-pages
  4. the script is executed by Travis (if not a pull request, and only for one build target, to avoid pushing four times)

For now, the docs for the latest commit are generated, but it would also be possible to publish the docs only for releases.

The "clear, re-create, and force push" approach is a bit awful in my opinion, so ideas for improvements are very welcome. :)

I'm not sure how you create the gh-pages for bitcoinj-addons, but if it's possible to wrap the generation into a script, then I could help you to setup Travis in a similar fashion. (it's really simple actually)

@msgilligan
Copy link
Collaborator

since we have Java and Groovy code

Well, typically, sites don't publish Java/Groovy Docs for their test code and the public API for this project is all written in Java.

I resolved the initial issue more or less

Really, cool, @dexX7 ! I need to check this out and learn more about Travis.

For now, the docs for the latest commit are generated, but it would also be possible to publish the docs only for releases.

It would be nice to have docs available for latest commit as well as the latest (or all) release(s).

I'm not sure how you create the gh-pages for bitcoinj-addons, but if it's possible to wrap the generation into a script

It's in a script. Let's create an issue over there for making it work with Travis.

Update: Issue ConsensusJ/consensusj#11 created.

@dexX7 dexX7 closed this as completed in #16 Sep 27, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants