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

Added composite build settings.gradle file for running hoist inline #750

Open
wants to merge 6 commits into
base: develop
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
114 changes: 55 additions & 59 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,14 +7,13 @@ usage, and links to related Hoist and Toolbox source code. Toolbox also provides
examples which may be especially useful as a starting point for application developers new to the
framework.

Please refer to the [Hoist Core](https://github.com/xh/hoist-core) and
[Hoist React](https://github.com/xh/hoist-react) repos for detailed information and documentation on
Hoist, including more information on configuring a local development environment.
Please refer to the [Hoist Core](https://github.com/xh/hoist-core) and [Hoist React](https://github.com/xh/hoist-react) repos for detailed information and
documentation on Hoist, including more information on configuring a local development environment.

Toolbox is itself a Hoist Application, and we keep it updated with the latest versions of the Hoist
Framework. A [toolbox-dev instance](https://toolbox-dev.xh.io) is auto-deployed via Teamcity on each
commit to either the Toolbox or Hoist `develop` branches. We update a distinct
["production" instance](https://toolbox.xh.io) manually with each new versioned Hoist release.
Framework. A [toolbox-dev instance](https://toolbox-dev.xh.io) is auto-deployed via Teamcity on each commit to either the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not your change, but link Teamcity to a remote source? Maybe most people know what this is, but I was only previously aware of Jenkins, Bamboo, Travis, CircleCI and AWS CodePipeLine. When I first read this I was unsure what Teamcity meant here.

Toolbox or Hoist `develop` branches. We update a distinct ["production" instance](https://toolbox.xh.io) manually with
each new versioned Hoist release.

## Database

Expand Down Expand Up @@ -64,59 +63,56 @@ When adding a new top-level entry-point for Toolbox (such as a new example appli
URL must be registered with Auth0 as a valid OAuth callback URL. Either Lee or Anselm can update our
Auth0 config accordingly.

## Wrapper project for Toolbox + Hoist development

A special project / directory structure can be useful for developing Toolbox alongside the Hoist
Core and React libraries, so that changes to the libraries themselves can be developed and tested
locally using Toolbox as a reference app. This is the recommended configuration for XH developers to
use when setting up Toolbox.

* Create a new directory within your homedir or another suitable location - name it something like
`toolbox-wrapper`.
* Within this new parent directory, check out the `toolbox`, `hoist-react`, and `hoist-core`
repositories as siblings.
* Create a new `settings.gradle` file within the top-level directory. The contents of this file will
be a single line: `include "toolbox", "hoist-core"`. This tells Gradle to reference and combine
the `build.gradle` targets of those two sub-projects into a single umbrella project.
* Create a new `build.gradle` file within the top-level directory. This is required to support the
`co.uzzu.dotenv` plugin used by Toolbox to read environment variables - the plugin must be applied
to the root project, which is the top-level wrapper directory in this mode. The Toolbox
`build.gradle` file is where the plugin is actually applied, but for that to work in wrapper mode
the plugin must be defined within the root (wrapper) project also, requiring a build file. Its
contents should be:
```groovy
buildscript {
repositories {
gradlePluginPortal()
}
dependencies {
classpath "co.uzzu.dotenv:gradle:4.0.0" // keep in sync with version in Toolbox build.gradle
}
}
```
* From the checked-out `toolbox` sub-directory, copy the `gradle` directory and the `gradlew` (or
`gradlew.bat` if on Windows) wrapper script and paste the copies into the top-level wrapper
directory.
* Your top-level directory should now contain four sub-directories, `settings.gradle`,
`build.gradle`, and the `gradlew` script.
* From the top-level directory, run `./gradlew` to ensure that Gradle can properly configure the
unified build.
* If using IntelliJ, create a new project by running through the "New project from existing
sources..." workflow and pointing the IDE at the top-level `settings.gradle` file.
* IntelliJ should detect that this is a Gradle/Grails project, download and index the
server-side dependencies, and set up an appropriate "Run Configuration" to start the Toolbox
server.

Having all three repos checked out in a single IntelliJ project can be useful to have the code
on-hand, but to actually run Toolbox using the local Hoist libraries some additional steps are
required.

* To run the server using the local `hoist-core`, edit the `toolbox/gradle.properties` file and set
`runHoistInline=true`. Note this is _not_ required if you're not changing any hoist-core code -
you can still have the project structure setup as described, and only flip this switch if/when
testing a local change to the plugin.
* To run the client using the local `hoist-react`, start your local webpack-dev-server from the
`toolbox/client-app` directory by running `yarn startWithHoist`.
## Running Toolbox

To run toolbox locally on your machine, use the following commands:
* Start the server with the command `./gradlew bootRun -Duser.timezone=Etc/UTC` in the `toolbox` package.
* Start the client with the command `yarn start` in the `toolbox/client-app` package.

## Toolbox + Hoist development

Toolbox is often developed alongside the Hoist Core and React libraries, so that changes to the
libraries themselves can be developed and tested locally using Toolbox as a reference app. This is
the recommended configuration for XH developers to use when setting up Toolbox.

* Create or find a suitable directory for multiple project repositories, like homedir or (if using
IntelliJ) `~/IdeaProjects/`.
* Within this directory, check out the `toolbox`, `hoist-react`, and `hoist-core` repositories as
siblings.

### Editing multiple projects together

For editing Hoist Core and React alongside Toolbox, it is recommended to open the `hoist-react` and
`hoist-core` projects as modules in your editor. Having all three repos in a single IntelliJ project
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Assume IJ for the IDE. Do we want to present this README with this assumption?

can be useful to have the code on-hand.

* Open up the `toolbox` project in IntelliJ.
* Import `hoist-react` and `hoist-core` as modules:
File -> Project Structure -> Modules -> Add (+) -> Import Module
* Using the Gradle tool window, "Link Gradle Project" (+) both `toolbox` and `hoist-core`.

### Running Toolbox using local Hoist

* To run the server using the local `hoist-core`, you need `hoist-core` to exist as sibling of the
`toolbox` package, and do one of the following:
* Edit the `toolbox/gradle.properties` file and set `runHoistInline=true`.
* Run the command `./gradlew bootRun -Duser.timezone=Etc/UTC -PrunHoistInline=true` from the `toolbox` directory.

Note this is _only_ required if you're changing hoist-core code.

* To run the client using the local `hoist-react`, you need `hoist-react` to exist as sibling of the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An extension to what I have already said, but there is a lot of details here (and previously) about second tier setups (including hoist in local dev), but it maybe misses the quick, happy path setup.

I think this is ok for now, but it may be worth a think about how we present setup to a new user, and tier the information they receive - from quick start happy path to more in depth configurations as they need it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added some (at least bare bones) info about the happy path above.

`toolbox` package, and to start your local webpack-dev-server from the `toolbox/client-app`
directory by running `yarn startWithHoist`.

Note this is _only_ required if you're changing hoist-react code.

### Running multiple instances of Toolbox
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At this point, I wonder if its worth standing up a Wiki or docs page for toolbox / hoist? If I just want to checkout toolbox to poke around, this doesn't come into play. Having this as an option in my startup commands is merited, but including it in the README may just confuse process of setting a basic setup running.


* Make sure that the `APP_TOOLBOX_MULTI_INSTANCE_ENABLED` property in `.env` is set to `true`.
* Run the first instance of the server and client as normal.
* To run a second instance of the server, you run the command `./gradlew bootRun -Duser.timezone=Etc/UTC -Dserver.port=8082` from the `toolbox` directory.
* To run a second instance of the client connected to the second server, start another local
webpack-dev-server from the `toolbox/client-app` directory using `yarn start --env devGrailsPort=8082 devWebpackPort=3002`.

## Developing with HTTPS on `xh.io` domain

Expand Down
15 changes: 3 additions & 12 deletions build.gradle
Original file line number Diff line number Diff line change
Expand Up @@ -43,19 +43,10 @@ springBoot {
mainClass = xhAppPackage + ".Application"
}

if (parseBoolean(runHoistInline)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personal ignorance only - what does settings.gradle do which we did not get here?

println "${xhAppName}: running with Hoist Core INLINE...."
grails.plugins {
implementation project(":hoist-core")
}
} else {
println "${xhAppName}: running with Hoist Core PACKAGED at v${hoistCoreVersion}...."
dependencies {
implementation "io.xh:hoist-core:$hoistCoreVersion"
}
}

dependencies {
// If `runHoistInline` is true, `hoistCoreVersion` will be ignored and local hoist-core will be used instead.
implementation "io.xh:hoist-core:$hoistCoreVersion"

// For server-side JWT validation.
implementation "org.bitbucket.b_c:jose4j:0.9.6"

Expand Down
11 changes: 11 additions & 0 deletions settings.gradle
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
import static java.lang.Boolean.parseBoolean

rootProject.name = 'toolbox'

// Composite build setup for compiling hoist-core locally
if (parseBoolean(runHoistInline)) {
println "${xhAppName}: running with Hoist Core INLINE...."
includeBuild '../hoist-core'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we are including static pathing, we should 100% ensure the documentation denotes where things should live. It may, I just want to confirm we are thinking about this.

} else {
println "${xhAppName}: running with Hoist Core PACKAGED at v${hoistCoreVersion}...."
}
Loading