search

orchidhq / Orchid

Build and deploy beautiful documentation sites that grow with you
https://orchid.run
GNU General Public License v3.0
517 stars 53 forks source link

Adds a Maven plugin that allows running Orchid from Maven projects #191

Closed bjansen closed 6 years ago

bjansen commented 6 years ago

This fixes issue #100.

The plugin is currently built using Gradle, so it can be built at the same time as the Gradle plugin. I must admit I had quite a hard time setting up the build file, and couldn't find a way to do everything I'd like to.

For example, Javadoc comments defined on @Mojo classes and their fields should in theory be copied to the output plugin.xml file, to let IDEs show documentation tooltips when users configure the plugin in their projects.

I think those problems would be solved by building the plugin using Maven instead of Gradle, but then we'd need to separate build tools to build Orchid.

Another option could be to put this plugin in its own Github repo, and build it using Maven.

bjansen commented 6 years ago

I need to fix that error that only happens in Travis and Appveyor:

[main] ERROR org.apache.maven.cli.MavenCli - Plugin org.apache.maven.plugins:maven-plugin-plugin:3.5.2 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-plugin-plugin:jar:3.5.2: Could not transfer artifact org.apache.maven.plugins:maven-plugin-plugin:pom:3.5.2 from/to central (https://repo.maven.apache.org/maven2): No connector factories available -> [Help 1]
bjansen commented 6 years ago

I fixed the build error!

cjbrooks12 commented 6 years ago

This looks great, thank you so much!

I wouldn't be opposed to having the plugin built in Maven, but I would like it to stay in this repo and have the same version as the Gradle plugin.

And how does the plugin get deployed? Can I just release it as an artifact on Bintray?

bjansen commented 6 years ago

Yes, I suppose uploading the artifact on Bintray would be enough. People who want to use the plugin would simply have to configure pluginRepositories like I did here.

I'll try publishing a snapshot version in a temporary repo, and see if I can fetch everything from a clean environment.

If you're okay with mixing Gradle and Maven, I might also try to build the plugin using Maven. It looks like you are doing releases from Travis, so I suppose it wouldn't be a problem to run a Gradle build, then a Maven build.

cjbrooks12 commented 6 years ago

Yeah, go for it building the plugin with Maven! As it is, publishing the Gradle plugin is a separate build step than publishing the Orchid artifacts, so adding another step for a Maven release is no problem at all.

bjansen commented 6 years ago

Do you know if it would be possible to make publish.gradle also publish an artifact that was not built by Gradle? I could configure the deployment in pom.xml, but that would duplicate a lot of info that is already in publish.gradle.

bjansen commented 6 years ago

OK, publishing from Maven does not require that much config. However, I'm wondering where the bintray_username and bintray_apiKey project properties come from. Do you define them in environment variables named ORG_GRADLE_PROJECT_bintray_username?

cjbrooks12 commented 6 years ago

Yeah I've got those properties set up in the following Travis CI environment variables: ORG_GRADLE_PROJECT_bintray_apiKey, ORG_GRADLE_PROJECT_bintray_username.

bjansen commented 6 years ago

All right, I think my PR is ready :)

cjbrooks12 commented 6 years ago

Thank you so much for your work on this! I just merged it in, I'm starting to run a build, and hopefully everything deploys correctly! The Pebble docs are good to go as well, so this should be the last piece needed to finish up the Pebble documentation site.