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

Options set on transtitive projects are not picked up. #283

Open
borissmidt opened this issue Dec 13, 2021 · 6 comments
Open

Options set on transtitive projects are not picked up. #283

borissmidt opened this issue Dec 13, 2021 · 6 comments

Comments

@borissmidt
Copy link

Projects that dependOn other sbt projects does not include defined protofiles from other sbt projects.

so if i define this in the 'commons ' project and have a concrete project depend on it:

lazy val common = project(file("common"))
lazy val api = project(file("my-api")).dependsOn(common)

where the commons has these transformers defined it will not be picked up by the other project:

package com.mycompany;

import "scalapb/scalapb.proto";

//Company wide conversions! can be overrided in sub packages if needed
option (scalapb.options) = {
  scope: PACKAGE
  import: "com.mycompany.protobuf.ProtoToJoda._"
  field_transformations : [
    {
      when : {
        type: TYPE_MESSAGE
        type_name: ".google.protobuf.Timestamp"
      }
      set : {[scalapb.field] {type : 'org.joda.time.base.AbstractInstant' }}
    },
    {
      when : {
        type: TYPE_MESSAGE
        type_name: ".google.protobuf.Duration"
      }
      //this should become scala.concurrent.FinitDuration
      set : {[scalapb.field] {type : 'org.joda.time.Duration' }}
    }
  ]
};
@thesamet
Copy link
Owner

Thanks for reporting. As a workaround you should be able to add to the api project a proto file with a single import for the options proto.

I'll need to think for a better overall solution. For external jar (not dependencies in the same build) we allowed exporting a manifest (https://scalapb.github.io/docs/customizations/#publishing-package-scoped-options) that will automatically load the options. We don't have anything similar to subprojects, and it would be nice to come up with a way to unify.

@borissmidt
Copy link
Author

I will make a workaround in this project by adding the:
internalDependencyAsJars to the task that extracts the jars or if i fail at that i might be able to just extract it myself to
target/protobuf_external

@bjaglin
Copy link
Contributor

bjaglin commented Dec 13, 2021

We are using the following hack to source a specific file (scalapb/package.proto) in all modules inhering from a common one

// We scope to PB.generate here to break a circular dependency preventing sbt to evaluate the task graph,
// as PB.includePaths depends on PB.protoSources
PB.generate / PB.protoSources ++=
  PB.includePaths.value.flatMap { depIncludePath =>
    // The "scalapb" subdirectory does not match the package but is used as a drop-in directory convention
    Seq(depIncludePath / "scalapb").filter(dir => (dir / "package.proto").exists())
  },

@borissmidt
Copy link
Author

Ah cool idea! i'll try it out

@borissmidt
Copy link
Author

borissmidt commented Dec 13, 2021

I couldn't get it to work as you posted but i ended up using and moved the options to a special include folder and i was lucky that only 1 project has custom types for now:

    p.settings(Compile / PB.generate / PB.protoSources ++={
      (grpcCommonProtofiles / Compile / PB.includePaths).value.map(dir => dir / "scalapbOptions").filter(_.exists())
    })

But my build hangs so i suppose there is some circular dependency issue.

@borissmidt
Copy link
Author

borissmidt commented Dec 17, 2021

Maybe a simpeler solution would be to automatically add proto files if they have the name scalapb-options.proto or some other convention.
A bit like reference.conf.

Its probably the easiest without opening any file.

Or give it a special extension so other generator's ignore it. I.e. '.scalapb'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants