-
Notifications
You must be signed in to change notification settings - Fork 186
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
gh-pages update #182
gh-pages update #182
Conversation
jmockit is likely to replace the current testing mocking we use. in order to explore that we need to ensure that junit appears last in classpath. This just prepares for that future reality.
update antrun plugin to 1.8 update surefire plugin to 2.18.1 update jgit to 3.6.0 release. In order to replace gh-pages site from original waffle version, merge the readme markdown into the maven generated twitter bootstrap page layout. This is actually a large improvement over the original as readme has changed quite a bit and had lots more useful information to provide. At the moment this does mean some duplication with the readme that will be addressed later. This results in doxia-module-markdown and wagon-git being added. There is not presently a good solid way to do this so write-up will be coming. As always multi-module issues persist thus multiple ways around this. After much work on this, this seems best solution for now but requires a little setup to work. mvn site to build the site mvn site:deploy to deply the site. requires setup in .m2 for this to work which is dependent on user settings.
Merging this, thanks. I think what we need is a proper top level RELEASING document (not just maven), that describes everything we need to do to make a release, maybe ala https://github.com/intridea/grape/blob/master/RELEASING.md? |
So you pushed this to gh-pages? What did you do for that? |
JavaDoc in https://dblock.github.io/waffle/apidocs/index.html looks good btw. |
Also note that aside of JavaDoc there's also the C# stuff :) |
Only way to fully test it all the way through. I plan to switch to this branch tonight and kill all junk commits plus fix links. Do you see anything missing from original? I believe Readme covered it. Also maybe look and feel changes to be like original or does this work? I'll look at fixing landing page too as it should be on Readme rather than maven reports. --- Original Message --- From: "Daniel Doubrovkine (dB.) @dblockdotorg" [email protected] So you pushed this to gh-pages? What did you do for that? Reply to this email directly or view it on GitHub: |
^^^ is all good, thx, I just want to make sure we end up with a repeatable process and don't forget what to do next time :) |
Must have been too tired this morning. Didn’t read this correctly. To push the gh-pages, did it via maven/java. I ran ‘mvn site’ to build the site and then did ‘mvn site-deploy’ to push it out. The way I got this working using ssh which is probably why it was so slow. Took around 40 minutes to push it out. Using other way took about 5 minutes but ended up requiring deeper nesting. I think this is far from perfect at the moment but going in the right direction. I probably should have targeted my fork when testing so I wasn’t trashing the master gh-pages. I will at least squash all the junk there as we really don’t need failed history there. For now, I’ll just switch to my branch for testing until I can get all the details worked out. Basically I want to clear all the issues I see with this as it stands currently. I also look at adding a bit more documentation such as the entire release process you sent a link for. I do like having waffle well documented for all things. I’ve been leaning towards it for other things I do as it sort of shows everything in one form or another which definitely has been more than helpful! Thanks, Jeremy From: Daniel Doubrovkine (dB.) @dblockdotorg [mailto:[email protected]] So you pushed this to gh-pages? What did you do for that? — |
I didn’t realize javadocs sort of all pulled together. Nice little win! I should have noticed that as I get a lot of warnings in builds due to class path conflicts (ie multiple spring / tomcat conflicts). Probably a little more reason to separate out the implementations. That makes a lot of things happy (code checkers, coveralls, javadocs, etc.). However, it would be a breaking change. At some point though that will have to be addressed. For now just making this much more solid is more appropriate. From: Daniel Doubrovkine (dB.) @dblockdotorg [mailto:[email protected]] JavaDoc in https://dblock.github.io/waffle/apidocs/index.html looks good btw. — |
This pull request does no harm to include but isn't a final solution yet and is extremely slow solution. I took this approach as it was the cleanest as there are issues in plugins that don't address multi module projects that well yet with site distributions.
In order to pull up site go here...
https://dblock.github.io/waffle/
For readme - essentially replacing the old gh-pages site.
https://dblock.github.io/waffle/README.html
For any module, do not use links as they are broken, instead just type in the module as following example shows.
https://dblock.github.io/waffle/waffle-jna
Example javadoc location...
https://dblock.github.io/waffle/waffle-jna/apidocs/index.html
Outstanding issues