Closed swaldman closed 4 years ago
My initial review of this is looking great! While I don't know Scala, the plugin looks like it's set up and configuring Orchid correctly, and the test script is working perfectly.
For documentation, let's add it as a section to the end of this file instead of having a README in the SBT project root. Within that file, you can use {{site.version}}
to inject the current project version. Also, would you be able to structure the docs like the other sections in that file as well? It should be something like:
The only other thing I see is that it needs an orchidRun
task, with the task name given as a parameter to SBT. For example, with Gradle you can run ./gradlew orchidRun -PorchidRunTask=serve
, and with Maven you can do ./mvnw orchid:run -Dorchid.runTask=serve
, so it would be nice to do the same kind of thing with SBT, however that would normally be done here.
I've implemented an orchidRun
task.
sbt has its own command line, on which you can now do...
> orchidRun <tab>
build deploy serve watch
> orchidRun build
Using the following modules:
--------------------
* com.eden.orchid.StandardModule
Auto-loaded modules:
--------------------
* com.eden.orchid.bsdoc.BsDocModule
* com.eden.orchid.impl.compilers.markdown.FlexmarkModule
...
But you can also use it from the command line:
$ ./sbtw -Dorchid.runTask=build orchidRun
or just
$ ./sbtw "orchidRun build"
OK. I think I've put the documentation where it goes, and gotten rid of the awkward self-updating README.md
. Hopefully it's readable and reasonable.
To be more consistent with everything else, I also modified the conventional source directory from src/main/orchid
to src/main/orchid/resources
. It feels like a bit of a mouthful under main
(and I don't want to use just src/orchid
because that would clash a bit with sbt
conventions), but I thought it'd be easier for people following the docs to have the same orchid/resources
set up as in other environments.
Alright, I've finally gotten time to go through this PR thoroughly, and it's working perfectly! It took a little bit of work to get it published to Bintray properly, but I was able to get it published successfully, and then also successfully used the quickstart docs to run the plugin in another project!
I've gone ahead and squashed the commits and manually applied them to the features/0.17.7
branch, so I will just close this PR without merging. But I am releasing 0.17.7 with this feature right now and will post back here when it's fully released.
Thanks again for your incredible work here, I'm really excited to get this released! Might have to start looking into adding support for Scala code docs soon, too 😉
(Sorry about the zillion tiny commits. It's lazy, but easy to use github as a markdown renderer when messing with documentation!)
No worries, I tend to do the same thing. This has been released now as version 0.17.7, and docs are updated.
Hopefully the scripts are as expected.
test.sh
doesn't say very much, but it will succeed with exit value 0, or fail with exit value 1 iff its (very basic) tests fail.I haven't tested
deploy.sh
against an actual bintray repository, I just watch it fail for lack of authentication. I hope it's set up okay when credentials are available, though I'll not be surprised if I've screwed something up.The
README.md
file remains the documentation, but in order to keep the version there in sync I have it regenerate itself on each build. This seems... awkward. It will be easy to excise all that when the documentation finds a better home.