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

Add extraProjects and derivedProjects (formerly known as buildExtras and projectExtras) #2717

Merged
merged 1 commit into from Aug 27, 2016

Conversation

Projects
None yet
5 participants
@eed3si9n
Member

eed3si9n commented Aug 27, 2016

Fixes #2532

This adds support to generate synthetic subprojects from an auto plugin.

In addition, a method called projectOrigin is added to distinguish Organic, BuildExtra, ProjectExtra, and GenericRoot.

To generate subprojects, override buildExtras
method as follows:

import sbt._
import Keys._

object BuildExtrasPlugin extends AutoPlugin {
  override def buildExtras: Seq[Project] =
    List("foo", "bar", "baz") map generateProject

  def generateProject(id: String): Project =
    Project(id, file(id)).
      settings(
        name := id
      )
}

Subprojects may also be derived from an existing subproject
by overriding projectExtras.

import sbt._
import Keys._

object ProjectExtrasPlugin extends AutoPlugin {
  // Enable this plugin by default
  override def requires: Plugins = sbt.plugins.CorePlugin
  override def trigger = allRequirements

  override def projectExtras(proj: ProjectDefinition[_]): Seq[Project] =
    // Make sure to exclude project extras to avoid recursive generation
    if (proj.projectOrigin != ProjectOrigin.ProjectExtra) {
      val id = proj.id + "1"
      Seq(
        Project(id, file(id)).
          enablePlugins(DatabasePlugin)
      )
    }
    else Nil
}

/review @dwijnand, @Duhemm

@eed3si9n eed3si9n changed the title from Add buildExtras and projectExtras. Fixes #2532 to Add buildExtras and projectExtras Aug 27, 2016

@eed3si9n eed3si9n added this to the 0.13.13 milestone Aug 27, 2016

@dwijnand

This comment has been minimized.

Show comment
Hide comment
@dwijnand

dwijnand Aug 27, 2016

Member

Wow knocking them out the park this week, awesome.

I'm only concerned with the name buildExtras: for builds where all the projecrs are programmatically generated it sounds a bit weird. So I was thinking perhaps just "projects" (like we have projectSettings, not extraProjectSettings).

projectExtras I'm not sure of either, but I don't have any better suggestions.

Member

dwijnand commented Aug 27, 2016

Wow knocking them out the park this week, awesome.

I'm only concerned with the name buildExtras: for builds where all the projecrs are programmatically generated it sounds a bit weird. So I was thinking perhaps just "projects" (like we have projectSettings, not extraProjectSettings).

projectExtras I'm not sure of either, but I don't have any better suggestions.

@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n Aug 27, 2016

Member

So I was thinking perhaps just "projects" (like we have projectSettings, not extraProjectSettings).

  • If I call it projects that would imply both the organic one and synthetic ones.
  • If I call it syntethicProjects or extras that would imply both the build-level and project-level.

buildExtras I think has a nice symmetry with buildSettings and easy to grasp what it would do.

Member

eed3si9n commented Aug 27, 2016

So I was thinking perhaps just "projects" (like we have projectSettings, not extraProjectSettings).

  • If I call it projects that would imply both the organic one and synthetic ones.
  • If I call it syntethicProjects or extras that would imply both the build-level and project-level.

buildExtras I think has a nice symmetry with buildSettings and easy to grasp what it would do.

@dwijnand

This comment has been minimized.

Show comment
Hide comment
@dwijnand

dwijnand Aug 27, 2016

Member

I see the organic/synthetic project argument. But what's a project-level project?

Member

dwijnand commented Aug 27, 2016

I see the organic/synthetic project argument. But what's a project-level project?

@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n Aug 27, 2016

Member

def projectExtras(proj: ProjectDefinition[_]): Seq[Project].
project-level extras allow you to generate a synthetic subproject from an existing stuff.

Member

eed3si9n commented Aug 27, 2016

def projectExtras(proj: ProjectDefinition[_]): Seq[Project].
project-level extras allow you to generate a synthetic subproject from an existing stuff.

@dwijnand

This comment has been minimized.

Show comment
Hide comment
@dwijnand

dwijnand Aug 27, 2016

Member

I see. Cool.

On Sat, 27 Aug 2016, 12:36 eugene yokota, notifications@github.com wrote:

def projectExtras(proj: ProjectDefinition[_]): Seq[Project].
project-level extras allow you to generate a synthetic subproject from an
existing stuff.


You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#2717 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAVCIvR7_JMVyMReQvQjAm1MrowZ1r6uks5qkBMrgaJpZM4JuqPL
.

Member

dwijnand commented Aug 27, 2016

I see. Cool.

On Sat, 27 Aug 2016, 12:36 eugene yokota, notifications@github.com wrote:

def projectExtras(proj: ProjectDefinition[_]): Seq[Project].
project-level extras allow you to generate a synthetic subproject from an
existing stuff.


You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#2717 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAVCIvR7_JMVyMReQvQjAm1MrowZ1r6uks5qkBMrgaJpZM4JuqPL
.

Show outdated Hide outdated main/src/main/scala/sbt/Project.scala
/** Definitively set the [[ProjectOrigin]] for this project. */
private[sbt] def setProjectOrigin(origin: ProjectOrigin): Project = {
// TODO: for 0.14.0, use copy when it has the additional `autoPlugins` parameter

This comment has been minimized.

@dwijnand

dwijnand Aug 27, 2016

Member

Is this TODO right?

@dwijnand

dwijnand Aug 27, 2016

Member

Is this TODO right?

This comment has been minimized.

@eed3si9n

eed3si9n Aug 27, 2016

Member

It should be additional projectOrigin parameter, I guess.

@eed3si9n

eed3si9n Aug 27, 2016

Member

It should be additional projectOrigin parameter, I guess.

Show outdated Hide outdated main/src/main/scala/sbt/Project.scala
@@ -192,6 +201,15 @@ sealed trait ClasspathDep[PR <: ProjectReference] { def project: PR; def configu
final case class ResolvedClasspathDependency(project: ProjectRef, configuration: Option[String]) extends ClasspathDep[ProjectRef]
final case class ClasspathDependency(project: ProjectReference, configuration: Option[String]) extends ClasspathDep[ProjectReference]
/** Indicate whether the project was created organically, or synthesized by a plugin. */

This comment has been minimized.

@dwijnand

dwijnand Aug 27, 2016

Member

Could you explain what GenericRoot is (somehow)? Either here or on the case objects.

@dwijnand

dwijnand Aug 27, 2016

Member

Could you explain what GenericRoot is (somehow)? Either here or on the case objects.

override def trigger = allRequirements
override def projectExtras(proj: ProjectDefinition[_]): Seq[Project] =
// Make sure to exclude project extras to avoid recursive generation

This comment has been minimized.

@dwijnand

dwijnand Aug 27, 2016

Member

Are we not managing this sbt side because there are edge-cases where it's convenient to have (some level of) recursion? Eg. one autoplugin's projectExtras consuming a previous autoplugin's projectExtras?

If not, then can we avoid making this something the user needs to deal with?

@dwijnand

dwijnand Aug 27, 2016

Member

Are we not managing this sbt side because there are edge-cases where it's convenient to have (some level of) recursion? Eg. one autoplugin's projectExtras consuming a previous autoplugin's projectExtras?

If not, then can we avoid making this something the user needs to deal with?

This comment has been minimized.

@eed3si9n

eed3si9n Aug 27, 2016

Member

Yes. It's possible that plugin A adds Foo1, Bar1, and plugin B derives more subprojects off of that.

@eed3si9n

eed3si9n Aug 27, 2016

Member

Yes. It's possible that plugin A adds Foo1, Bar1, and plugin B derives more subprojects off of that.

@dwijnand

This comment has been minimized.

Show comment
Hide comment
@dwijnand

dwijnand Aug 27, 2016

Member

I'm really happy to see progress, thank you.

Reviewed, some minor tweaks, but generally LGTM.

Member

dwijnand commented Aug 27, 2016

I'm really happy to see progress, thank you.

Reviewed, some minor tweaks, but generally LGTM.

Add buildExtras and projectExtras. Fixes #2532
This adds support to generate synthetic subprojects from an auto plugin.

In addition, a method called `projectOrigin` is added to distinguish
Organic, BuildExtra, ProjectExtra, and GenericRoot.
@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n Aug 27, 2016

Member

Pushed a commit per reviews.

Member

eed3si9n commented Aug 27, 2016

Pushed a commit per reviews.

@eed3si9n eed3si9n merged commit d0ce0ce into sbt:0.13 Aug 27, 2016

2 checks passed

codacy/pr Good work! A perfect pull request.
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@eed3si9n eed3si9n deleted the eed3si9n:wip/plugin branch Aug 27, 2016

@eed3si9n eed3si9n removed the in progress label Aug 27, 2016

@mslinn

This comment has been minimized.

Show comment
Hide comment
@mslinn

mslinn Aug 27, 2016

Docs addressing motivation (why does this feature exist, what problems does it solve) would be helpful.

mslinn commented Aug 27, 2016

Docs addressing motivation (why does this feature exist, what problems does it solve) would be helpful.

@clhodapp

This comment has been minimized.

Show comment
Hide comment
@clhodapp

clhodapp Aug 28, 2016

I agree 100% with @dwijnand's first comment. The feature itself here is absolutely terrific. That said, calling these "extras" feels really under-descriptive to me. There are innumerable "extra" things that could be generated by a plugin, so, as a user, why would I assume that the "extras" would be projects? Also, @dwijnand indicates, this naming would feel kind of weird if you were in a setting where most projects were generated (maybe someone defines a plugin in the future for opinionated builds described by a JSON dependencies file, for instance). Why not just call them generatedProjects and generatedSubprojects?

clhodapp commented Aug 28, 2016

I agree 100% with @dwijnand's first comment. The feature itself here is absolutely terrific. That said, calling these "extras" feels really under-descriptive to me. There are innumerable "extra" things that could be generated by a plugin, so, as a user, why would I assume that the "extras" would be projects? Also, @dwijnand indicates, this naming would feel kind of weird if you were in a setting where most projects were generated (maybe someone defines a plugin in the future for opinionated builds described by a JSON dependencies file, for instance). Why not just call them generatedProjects and generatedSubprojects?

@clhodapp

This comment has been minimized.

Show comment
Hide comment
@clhodapp

clhodapp Aug 28, 2016

Or derivedProjects for the second one might be more accurate

clhodapp commented Aug 28, 2016

Or derivedProjects for the second one might be more accurate

@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n Aug 28, 2016

Member

There are innumerable "extra" things that could be generated by a plugin, so, as a user, why would I assume that the "extras" would be projects?

A typical build user would not see the method name when they consume a plugin. This is mostly for advanced plugin authors.

I want the names that can be used as noun phrase like projectSettings and buildSettings that would distinguish the build- and project-level clearly. generatedProjects + derivedProjects are not bad, but they are more subtle because you can claim that both are "generated" and/or "derived" off of something like JSON. Can we come up with something that's unambiguous?

Member

eed3si9n commented Aug 28, 2016

There are innumerable "extra" things that could be generated by a plugin, so, as a user, why would I assume that the "extras" would be projects?

A typical build user would not see the method name when they consume a plugin. This is mostly for advanced plugin authors.

I want the names that can be used as noun phrase like projectSettings and buildSettings that would distinguish the build- and project-level clearly. generatedProjects + derivedProjects are not bad, but they are more subtle because you can claim that both are "generated" and/or "derived" off of something like JSON. Can we come up with something that's unambiguous?

@ahjohannessen

This comment has been minimized.

Show comment
Hide comment
@ahjohannessen

ahjohannessen Aug 28, 2016

Why not just subProjects ?

ahjohannessen commented Aug 28, 2016

Why not just subProjects ?

@clhodapp

This comment has been minimized.

Show comment
Hide comment
@clhodapp

clhodapp Sep 7, 2016

How about independentProjects and derivedProjects?

One thing I'll note now that I've thought about it is that sbt's model doesn't even really include the notion of "subprojects" unless you count aggregation (which I don't think is in play here). There are just "projects". So isn't it a bit confusing to say that these generated projects are "subprojects"?

clhodapp commented Sep 7, 2016

How about independentProjects and derivedProjects?

One thing I'll note now that I've thought about it is that sbt's model doesn't even really include the notion of "subprojects" unless you count aggregation (which I don't think is in play here). There are just "projects". So isn't it a bit confusing to say that these generated projects are "subprojects"?

@mslinn

This comment has been minimized.

Show comment
Hide comment
@mslinn

mslinn Sep 7, 2016

I do not believe it is accurate to say SBT does not support the concept of subprojects. See dependsOn in the multi-project build page.

mslinn commented Sep 7, 2016

I do not believe it is accurate to say SBT does not support the concept of subprojects. See dependsOn in the multi-project build page.

@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n Sep 7, 2016

Member

ok. How about:

def extraProjects: Seq[Project]
def derivedProjects(proj: ProjectDefinition[_]): Seq[Project]

?

Member

eed3si9n commented Sep 7, 2016

ok. How about:

def extraProjects: Seq[Project]
def derivedProjects(proj: ProjectDefinition[_]): Seq[Project]

?

@clhodapp

This comment has been minimized.

Show comment
Hide comment
@clhodapp

clhodapp Sep 7, 2016

That combo is better than any one so far. From my point of view, the bikeshedding can stop with them ;). Thanks again for this great feature.

clhodapp commented Sep 7, 2016

That combo is better than any one so far. From my point of view, the bikeshedding can stop with them ;). Thanks again for this great feature.

@clhodapp

This comment has been minimized.

Show comment
Hide comment
@clhodapp

clhodapp Sep 7, 2016

@mslinn That usage of "subproject" means "subproject of the build" not "subproject of another project" and is roughly synonymous with just "project".

clhodapp commented Sep 7, 2016

@mslinn That usage of "subproject" means "subproject of the build" not "subproject of another project" and is roughly synonymous with just "project".

@mslinn

This comment has been minimized.

Show comment
Hide comment
@mslinn

mslinn Sep 7, 2016

@clhodapp if this is going to be an ongoing source of confusion, the docs should introduce a term like "build subproject" or "subbuild" - I don't care if the b's are elided or not.

mslinn commented Sep 7, 2016

@clhodapp if this is going to be an ongoing source of confusion, the docs should introduce a term like "build subproject" or "subbuild" - I don't care if the b's are elided or not.

eed3si9n added a commit to eed3si9n/sbt that referenced this pull request Sep 15, 2016

@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n Sep 15, 2016

Member

Sent PR for the rename (#2738)

Member

eed3si9n commented Sep 15, 2016

Sent PR for the rename (#2738)

@eed3si9n eed3si9n changed the title from Add buildExtras and projectExtras to Add extraProjects and derivedProjects (formerly known as buildExtras and projectExtras) Sep 16, 2016

dwijnand added a commit to dwijnand/sbt that referenced this pull request Sep 28, 2016

Add extraProjects adn derivedProjects. Fixes #2532
This adds support to generate synthetic subprojects from an auto plugin.

In addition, a method called `projectOrigin` is added to distinguish
Organic, BuildExtra, ProjectExtra, and GenericRoot.

Forward-port of #2717 and #2738

dwijnand added a commit to dwijnand/sbt that referenced this pull request Sep 29, 2016

Add extraProjects adn derivedProjects. Fixes #2532
This adds support to generate synthetic subprojects from an auto plugin.

In addition, a method called `projectOrigin` is added to distinguish
Organic, BuildExtra, ProjectExtra, and GenericRoot.

Forward-port of #2717 and #2738

@eed3si9n eed3si9n referenced this pull request Nov 15, 2016

Closed

[sbt 1.0] Forward port 0.13 changes #2352

7 of 7 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment