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

WIP + Suggestion - Split `library` modules' functionality into `resolving` and `rendering` #303

Closed
wants to merge 1 commit into from

Conversation

@mboogerd
Copy link

mboogerd commented Jun 4, 2017

This is some code to discuss, with the context being: sbt-giter8-resolver#issue-8. In short, sbt giter8 plugin loads its own version of giter8, rather than the plugin provided in the git repository itself. Unless we want to take the burden of forward+backward compatibility, this introduces the risk of using a plugin version that does not match the template.

Proposed solution:

  1. Split library in two. One part for resolving templates, one part for rendering
  2. Refactor sbt plugin to use the rendering module to render the current project
    3a. Refactor sbt new to use the resolving module to clone the desired git repo
    3b. then invoke the sbt plugin included with that project

This PR contains an unimaginative implementation for (1) and (2). Part 3 would require us to choose an interface for Giter8Engine that is unlikely to change, to prevent complications in the future. I think that is more a job for a core developer of SBT/giter8. I hope this PR gets that ball rolling.

Technical debt: Duplicated FileDSL and TestFileHelpers because introducing a new common module seemed somewhat overkill.

Technical debt: Duplicated FileDSL and TestFileHelpers because introducing a new `common` module seems somewhat overkill
@eed3si9n

This comment has been minimized.

Copy link
Member

eed3si9n commented Sep 24, 2017

I think this is an awesome idea.

@mboogerd

This comment has been minimized.

Copy link
Author

mboogerd commented Sep 27, 2017

@eed3si9n Could you clarify for me how you want to proceed with this (#11)?

What I meant to suggest above is to have the "resolving sbt" (the one that is invoking "new") invoke giter8 on the "resolved sbt" so that it automatically works with the right version for rendering. What you seem to suggest is that the "resolving sbt" retrieves the giter8.version property from the "resolved sbt" and then somehow obtain that particular giter8 version to execute its rendering functionality.

Do I get your take on this correctly? Either way would work I think, but I want to make sure that I understand the approach you prefer. If my interpretation of your ticket is right, do you mean to use resolution through ivy to obtain the configured giter8 version?

@eed3si9n

This comment has been minimized.

Copy link
Member

eed3si9n commented Sep 27, 2017

I haven't thought through the details, but I am wondering if we can use something like sbt launcher, which internally uses Ivy, the same way Conscripted g8 script already does it.

  1. sbt new calls up sbt-giter8-resolver dynamically.
  2. It calls giter8.Giter8.run(args) as normal Scala function.
  3. giter8.Giter8.run(args) runs git clone.
  4. Looking at build.properties, Giter8.run launches a second JVM process for renderer using sbt launcher.
  5. sbt launcher resolves Renderer either out of Ivy cache or internet if it's new.
@wolfendale

This comment has been minimized.

Copy link
Contributor

wolfendale commented Sep 28, 2017

I've come up with a simple implementation of something similar to this here.

I've added a Launcher object in the lib project. In this case it's used by the app but it could also be used by the giter8-resolver in the same way.

Flow

  • Decide which version to launch when the app runs:
    • If a --g8Version property exists, use that
    • Otherwise clone the repo of the template arg and look for the project/build.properties and get the giter8.version property.
  • Clone the foundweekends/giter8 repo and check out the tag for the version resolved above.
  • Copy the src/main/conscript/g8/launchconfig to a temporary directory.
  • Launch a new JVM process with the $CONSCRIPT_HOME/sbt-launch.jar using the resolved launchconfig.
  • Pass all arguments to the sub process (minus some filtered ones to prevent it trying to launch another version of itself)
  • ???
  • Profit?

There are a bunch of problems with the implementation, e.g. relying on the user to have conscript installed. But I think it's a good start. It'd be good to get some feedback on it and see where we need to change the solution.

@eed3si9n

This comment has been minimized.

Copy link
Member

eed3si9n commented Oct 6, 2017

Closing this in favor of #344 that got merged.

@eed3si9n eed3si9n closed this Oct 6, 2017
@rbrondgeest

This comment has been minimized.

Copy link

rbrondgeest commented May 7, 2018

Reopen? As due to #365 reverting #344 this is still something that i'd like to see implemented.

eed3si9n added a commit to eed3si9n/giter8 that referenced this pull request Dec 7, 2019
Fixes foundweekends#433
This is a reimplementation of foundweekends#303 / foundweekends#344

This creates a new command-line application called giter8-launcher whose job is analogous to sbt's sbt-launcher. giter8-launcher clones the template and reads `project/build.properties` file to determine the Giter8 version to render the template.

The artifacts for Giter8 is then resolved using Coursier, and `Giter8.run` is called via reflection.
eed3si9n added a commit to eed3si9n/giter8 that referenced this pull request Dec 7, 2019
Fixes foundweekends#433
This is a reimplementation of foundweekends#303 / foundweekends#344

This creates a new command-line application called giter8-launcher whose job is analogous to sbt's sbt-launcher. giter8-launcher clones the template and reads `project/build.properties` file to determine the Giter8 version to render the template.

The artifacts for Giter8 is then resolved using Coursier, and `Giter8.run` is called via reflection.
@eed3si9n eed3si9n mentioned this pull request Dec 7, 2019
eed3si9n added a commit to eed3si9n/giter8 that referenced this pull request Dec 7, 2019
Fixes foundweekends#433
This is a reimplementation of foundweekends#303 / foundweekends#344

This creates a new command-line application called giter8-launcher whose job is analogous to sbt's sbt-launcher. giter8-launcher clones the template and reads `project/build.properties` file to determine the Giter8 version to render the template.

The artifacts for Giter8 is then resolved using Coursier, and `Giter8.run` is called via reflection.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
4 participants
You can’t perform that action at this time.