Community chat around Orchid. Please use Github Discussions for Orchid support https://github.com/orchidhq/Orchid/discussions
plugins {
// Add the official Orchid Gradle plugin so you can use Orchid with the custom DSL
id "com.eden.orchidPlugin" version "0.21.2"
}
repositories {
// Orchid uses dependencies from both Jcenter and Jitpack, so both must be included. jcenter also includes
// everything available from MavenCentral, while Jitpack makes accessible any Github project.
jcenter()
maven { url "https://kotlin.bintray.com/kotlinx" }
}
jcenter() repo, the local bintray repos are no longer working now that bintray has been sunset. And it looks like the version number displayed in the docs got bumped accidentally, the latest version is 0.21.1
Thank you so much for offering to help! Overall, Orchid is a pretty standard multimodule Gradle project, and you shouldn't really need to know much about its internal structure to help get the dependencies updated. There should be plenty of tests, and the Orchid repo uses itself for its own documentation, so between those two, if you make a change and all the tests pass and there don't seem to be any unusual logs during its own orchidBuild, it should be good. You'll want to branch from/PR into the dev branch, and the Gradle dependency versions are all declared in this file: https://github.com/orchidhq/Orchid/blob/dev/buildSrc/src/main/kotlin/Versions.kt
In particular, jsass, pygments, asciidoctorj, and classgraph dependencies should be pretty isolated things. Asciidoctorj and Classgraph both use APIs that are deprecated, and there should be compile warnings with the specific lines that need to be addressed. Jsass and pygments print strange errors at runtime when running Orchid that I'm less sure of what the exact issue or the proper fix it, but looking documentation/release notes for those respective projects might help uncover the issues there.
And finally, if you are comfortable with Gradle, I want to replace those Libs.kt/Versions.kt files in buildSrc with the new Gradle Version Catalogs feature available in Gradle 7. The repo is already updated to Gradle 7, just need to migrate those dependency definitions/usages in the build files
./gradlew clean build from the project root will run everything, but it takes ~10-20 minutes for it to finish, usually. But you can also run any of the tests from within Intellij as you would any other Java project. And running its own documentation is just the same as for any other project that uses Orchid for docs: ./gradlew :docs:orchidServe
java.lang.IllegalStateException: Unexpected SMAP line: *S KotlinDebug-Xlint:deprecation to the compileOptions.freeCompilerArgs tells me the flag is unsupported.
org.gradle.warning.mode=all in gradle.properties would be enough, but it still doesn't give me anything more detailed than:
> Task :OrchidCore:compileJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details../gradlew clean build
> Task :OrchidCore:compileJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
{{ page.title }}
{% endfor %}
Hey everyone, I just wanted to give another quick update on the progress of Orchid's 1.0.0 release. In keeping with the timeline outlined here, and I'm happy to report that things are still on track. I've got the dev branch updated to using Kotlin 1.4.32, updated the majority of its dependencies to their latest versions, and it's no longer referencing any artifacts from JCenter or Bintray. The updated dependencies should also fix crashing running on the latest JDK versions, though the SourceDoc plugins are still quite old and might not work with the latest versions of each respective language. Unfortunately, both the Javadoc and Kotlindoc plugins will need to be completely rewritten because both their underlying documentation tools have been rewritten, and this is out-of-scope for the 1.0.0 release.
I will also note that even though Kotlin is at 1.5.20 now, I am still planning on releasing 1.0.0 at kotlin version 1.4.32, but this should not prevent Orchid from being used in Gradle projects targeting higher Kotlin versions, since the Orchid Gradle plugin does not depend on the Kotlin plugin.
The last bit of work remaining is to finish getting the open PRs merged, get the modules renamed to fit with the normal artifact-naming conventions, and update the documentation. The hard work is definitely behind me now, but some help getting the modules renamed and the documentation updated would be appreciated at this point.
Finally, part of the re-release will involve updates to the Maven and SBT plugins, getting them published to MavenCentral. I do not know how to work with these tools, so I will really need some help getting those updated.
mavenLocal() repo, and test it on your own sites from there. I'm sure there are some kinks to work out that didn't get caught by the unit tests yet. I've mostly been focusing on getting it to compile and pass the tests so far, but haven't really validated the actual functionality too much yet, and the more eyes on it before this big release, the better
- Continue to use the 0.21.1 Gradle/Maven plugin versions
- add https://s01.oss.sonatype.org/content/repositories/snapshots/ as a Maven repository in your build (the new standard Sonatype snapshots repo)
- Use updated coordinates for all Orchid dependencies
- groupId is now
io.github.copper-leaf-orchid - artifactId format has changed from CamelCase (
OrchidCore) to kebob-case (orchid-core). Additionally,-bundle,-featureor-themehas been appended to the artifactId for all modules, as appropriate (orchid-wiki-feature,orchid-bsdoc-theme,orchid-docs-bundle, etc.) - the Taxonomies plugin is being renamed to "Archives" (
OrchidTaxonomiesartifact is noworchid-archives-feature) - A full dependency of
io.github.javaeden.orchid:OrchidWiki:0.21.1should now look likeio.github.copper-leaf.orchid:orchid-wiki-feature:1.0.0-SNAPSHOT
- groupId is now
@cjbrooks12 With the javadoc plugin, how/where does it call to the JDK? We've updated to Java 17 which caused some illegal access issues with Orchid. I've mitigated that for now by using Gradle's toolchains in Orchids build.gradle file so the Orchid tasks use Java 11.
How I've implmeneted it.
java {
toolchain {
languageVersion = JavaLanguageVersion.of(11)
}
}
tasks.withType(JavaExec) {
javaLauncher.set(javaToolchains.launcherFor(java.toolchain))
}
tasks.withType(JavaCompile) {
javaCompiler.set(javaToolchains.compilerFor(java.toolchain))
}
tasks.withType(Javadoc) {
javadocTool.set(javaToolchains.javadocToolFor(java.toolchain))
}
This works great for the exec/compile but not for the javadocs. The Orchid Javadoc plugin seems to not be respecting the the java toolchain I'm telling it to use. I have to change my JAVA_HOME to point to Java 11 instead of Java 17, else it will build the javadocs using JDK 17 and none of the Javadocs will be parsed if that happens. I'm not sure if this is an issue with the Orchid Javadoc plugin or Gradle itself since I cant get into the javadoc plugins code to looks where the jdk is being called. Any help is appreciated.
Actually I see that the JavadocPlugin does not use Gradle tasks but makes a call to the command line
val processArgs = arrayOf(
"javadoc",
"-J-Xms$startMemory", "-J-Xmx$maxMemory",
"-d", destinationDir.toFile().absolutePath, // where Orchid will find them later
"-doclet", "com.copperleaf.javadoc.json.JavadocJsonDoclet",
"-docletpath", formatterJar.toFile().absolutePath, // classpath of embedded formatter jar
*args.toTypedArray(), // allow additional arbitrary args
*allFiles.toTypedArray() // the sources to process
)which is the issue.