Re: Upgrading from 0.5.9

2 views
Skip to first unread message

Nadav Samet

unread,
May 28, 2020, 6:29:23 PM5/28/20
to Louis B, ScalaPB
Python is not needed on or after 0.99.15, but the option is still there and ignored, in order not to break the build.

The import line can be removed, also the reference for PB.protobufSettings. 

On Thu, May 28, 2020 at 3:15 PM Louis B <chillip...@gmail.com> wrote:
Hi,

Anyway meanwhile I went ahead and just tried it and it did resolve some dependencies in our dependency proxy, so that’s better than expected, however, the build syntax I shared does have a problem.

Do I need to change import package names? Does it still use python and the python path setting?

Here is result of just changing the plugin;

[info] Loading global plugins from C:\Users\botteril\.sbt\0.13\plugins

[info] Updating {file:/C:/Users/botteril/.sbt/0.13/plugins/}global-plugins...

[info] Resolving org.fusesource.jansi#jansi;1.4 ...

[info] Done updating.

[info] Loading project definition from C:\dev\projects\spark-aggregator\project

[info] Updating {file:/C:/dev/projects/spark-aggregator/project/}spark-aggregator-build...

[info] Resolving org.fusesource.jansi#jansi;1.4 ...

[info] downloading https://nexus.foobar.com/nexus/content/groups/ivy-releases/com.thesamet/sbt-protoc/scala_2.10/sbt_0.13/0.99.18/jars/sbt-protoc.jar ...

[info]  [SUCCESSFUL ] com.thesamet#sbt-protoc;0.99.18!sbt-protoc.jar (1357ms)

[info] downloading https://nexus.foobar.com/nexus/content/groups/ivy-releases/com.thesamet/sbt-protoc/scala_2.10/sbt_0.13/0.99.18/docs/sbt-protoc-javadoc.jar ...

[info]  [SUCCESSFUL ] com.thesamet#sbt-protoc;0.99.18!sbt-protoc.jar(doc) (3810ms)

[info] downloading https://nexus.foobar.com/nexus/content/groups/ivy-releases/com.thesamet/sbt-protoc/scala_2.10/sbt_0.13/0.99.18/srcs/sbt-protoc-sources.jar ...

[info]  [SUCCESSFUL ] com.thesamet#sbt-protoc;0.99.18!sbt-protoc.jar(src) (989ms)

[info] downloading https://nexus.foobar.com/nexus/content/groups/foobar/com/github/os72/protoc-jar/3.5.1/protoc-jar-3.5.1.jar ...

[info]  [SUCCESSFUL ] com.github.os72#protoc-jar;3.5.1!protoc-jar.jar (5303ms)

[info] downloading https://nexus.foobar.com/nexus/content/groups/foobar/com/thesamet/scalapb/protoc-bridge_2.10/0.7.3/protoc-bridge_2.10-0.7.3.jar ...

[info]  [SUCCESSFUL ] com.thesamet.scalapb#protoc-bridge_2.10;0.7.3!protoc-bridge_2.10.jar (478ms)

[info] Done updating.

[info] Compiling 2 Scala sources to C:\dev\projects\spark-aggregator\project\target\scala-2.10\sbt-0.13\classes...

[error] C:\dev\projects\spark-aggregator\project\ProjectSettings.scala:4: object trueaccord is not a member of package com

[error] import com.trueaccord.scalapb.{ScalaPbPlugin => PB}

[error]            ^

[error] C:\dev\projects\spark-aggregator\project\ProjectSettings.scala:55: not found: value PB

[error]   lazy val scalaPbSettings = PB.protobufSettings ++ Seq(

[error]                              ^

[error] two errors found

[error] (compile:compileIncremental) Compilation failed

 

________________________________________________________________________


Sent from my iPad Pro

On May 28, 2020, at 5:49 PM, Louis B <chillip...@gmail.com> wrote:

Hi,

Ok I can give that a go,

What version of scalapb-runtime and compilerplugin will it depends on, 0.6.7?

Basically I need to get all the correct dependencies added to our repos in advance, I added the ones I shared below for 0.6.7, did I do the right thing or something else will be needed instead due to this sbt-protoc change and do I also need to request protocbridge too? What is the gav for that?

All the best, Louis


Sent from my iPad Pro

On May 28, 2020, at 5:40 PM, Nadav Samet <thes...@gmail.com> wrote:


Hi Louis,

ScalaPB compilerplugin and sbt-protoc share a dependency on a library called protocbridge. If sbt-protoc is too new (0.99.28 instead of 0.99.18), I believe the build will fail due to binary incompatibility issue between the different versions of protocbridge.

In your project/plugins.sbt, remove the dependency:
addSbtPlugin("com.trueaccord.scalapb" % "sbt-scalapb" % "0.4.14")
and instead add:
addSbtPlugin("com.thesamet" % "sbt-protoc" % "0.99.18")

I think the rest of the build should remain unchanged.

On Thu, May 28, 2020 at 2:11 PM Louis Botterill <chillip...@gmail.com> wrote:
Hi,

Ok so when I look at this page I see some steps that don't seem to tally with what we currently have working in our build. (using sbt 0.13.18)
Following this guide https://scalapb.github.io/migrating.html - for example it starts out with

In project/scalapb.proto or project/plugins.proto, remove the library dependency on sbt-scalapb.


I don't have those files, I've pulled out what I have and have shared it below, this is all I can find in our old but currently working fine build.

During our previous we'd concluded upgrade to 0.6.7, but if I change plugin to 

addSbtPlugin("com.thesamet" % "sbt-protoc" % "0.99.28")

what bearing does this have to 0.6.7, what is at version 0.6.7 you previously said to use and where do I set it?

This is what we currently have, using 0.4.14 it turns out

project\plugins.sbt

 

addSbtPlugin("com.trueaccord.scalapb" % "sbt-scalapb" % "0.4.14")

 

 

project\Build.scala

 

lazy val scalaPbSettings = PB.protobufSettings ++ Seq(

  PB.pythonExecutable in PB.protobufConfig := DEFAULT_PYTHON_EXE

)

 

lazy val protoPrj = Project(

    id = "proto",

    base = file("proto")

  ) dependsOn (utilsPrj % defaultProjectScopeInheritance) settings(

    globalSettings,

    libraryDependencies ++= coreDeps ++ formatConverterDeps,

    scalaPbSettings

  )

and that is literally all I can find. I can change plugin in plugins.sbt but 0.99.28 seems no relation to 'use 0.6.7 instead of 0.4.14' and where would I set 0.6.7, there doesn't seem anywhere to set it.
I'd so far requested scala runtime and compiler plugin for 0.6.7 for both scala 2.10 and 2.11 and thought that was it.

if I change the plugin line to refer

"com.thesamet" % "sbt-protoc" % "0.99.28"

as well as adding this new artifact which we don't seem to have, what else do we need?

So far I'd gone ahead and requested this libs added since I thought 0.6.7 was the aim;


scala pb version upgrade requested - to 0.6.7 for scala 2.10 and 2.11 (13th May 2020)

 

<!-- https://mvnrepository.com/artifact/com.trueaccord.scalapb/scalapb-runtime -->

<dependency>

    <groupId>com.trueaccord.scalapb</groupId>

    <artifactId>scalapb-runtime_2.10</artifactId>

    <version>0.6.7</version>

</dependency>

 

<!-- https://mvnrepository.com/artifact/com.trueaccord.scalapb/scalapb-runtime -->

<dependency>

    <groupId>com.trueaccord.scalapb</groupId>

    <artifactId>scalapb-runtime_2.11</artifactId>

    <version>0.6.7</version>

</dependency>

 

<!-- https://mvnrepository.com/artifact/com.trueaccord.scalapb/compilerplugin -->

<dependency>

    <groupId>com.trueaccord.scalapb</groupId>

    <artifactId>compilerplugin_2.10</artifactId>

    <version>0.6.7</version>

</dependency>

 

<!-- https://mvnrepository.com/artifact/com.trueaccord.scalapb/compilerplugin -->

<dependency>

    <groupId>com.trueaccord.scalapb</groupId>

    <artifactId>compilerplugin_2.11</artifactId>

    <version>0.6.7</version>

</dependency>



many thanks,
Louis


On Wed, 27 May 2020 at 21:09, Nadav Samet <thes...@gmail.com> wrote:
Yes, the switch to sbt-protoc is needed: based on the change log, the transition to sbt-protoc happened at ScalaPB 0.5.43,.


On Wed, May 27, 2020 at 5:41 PM Louis <chillip...@gmail.com> wrote:
Hi, ok thanks but based on previous I thought we’d concluded if I only upgrade to 0.6.7 for now (prior to 0.7, which that guide is for) it would essentially stay the same?

I guess I missed something. Even At 0.6.7 I still have to change to sbt-protoc anyway? 

Louis


On May 27, 2020, at 7:24 PM, Nadav Samet <thes...@gmail.com> wrote:


Hi Louis, see earlier message in this thread about moving from sbt-scalapb to sbt-protoc, also mentioned in the migration guide: https://scalapb.github.io/migrating.html#migrating-from-sbt-scalapb-to-sbt-protoc

I believe the version that should work for you is 0.99.18.

Hope this helps!

-Nadav

On Wed, May 27, 2020 at 3:23 PM Louis Botterill <chillip...@gmail.com> wrote:
Hi again,

I got the Scala 2.10 and 2.11 runtime and compile plugins added to our internal repo for scala pb 0.6.7, based on this intermediate upgrade (before the renaming).

However when I tried to change the plugin version and boot SBT i was hit with further missing artifacts, looks like sbt-scalapb
i.e. resolving 


However I can't seem to find 0.6.7 version for both scala 2.10 and scala 2.11 in maven. I wanted to use 0.6.7 and bridge seamlessly from scala 2.10 to 2.11 using that same version as part of project upgrade.

What are the artifact GAVs I need to be requesting and making available here for this, so that both scala 2.10 and 2.11 work for sbt 0.13.x using scala pb 0.6.7

Many thanks, Louis


On Wed, 13 May 2020 at 10:26, Louis <chillip...@gmail.com> wrote:
Hi,

Ok thanks for confirming that. Let me work on that as a first step and then after I will look at the 0.7 hurdle and migrating to new artefacts. Once that is achieved then hopefully final steps you suggest will then be straightforward, getting as up to date as possible, which limited in our case (for the time being) by scala 2.11, which is itself dictated by our use of Spark also.

Many thanks!

Louis


On May 13, 2020, at 9:55 AM, Nadav Samet <thes...@gmail.com> wrote:


(Re-adding the mailing list). Upgrading to 0.6.7 as a first step makes sense, as it isolates you from the package name changing.

On Wed, May 13, 2020 at 5:52 AM Louis Botterill <chillip...@gmail.com> wrote:
Hi again,

Looking in maven, perhaps then I should try for 0.6.7 for now, until I can get the name changed artifacts available.
Does this sound like the best bet?
I can do several incremental steps to get up to date, this being step 0. The others may take time due to the artifacts, so that's what I'm aiming for initially, a quick win to do now and then what to do next, which I think you answered once I can get past the 0.7.0 hurdles.

0.6.7 would be a good first step?

All the best, Louis


On Wed, 13 May 2020 at 08:37, Louis Botterill <chillip...@gmail.com> wrote:
Hi again,

Ah I see after reading your migration guide. I think I will need initially to update to the latest version that is before this change that occurs at 0.7.0, in the interim. This is because the renaming will mean I'll need to get the libs checked and approved for loading into internal nexus, that is tricky! Something I wanted to avoid right now, but will do also later. For now I just want to bump a like for like version update, if possible.

If I want a version in the mean-tim that is effectively same as 0.4 or 0.5 what is the latest working version I can use that is just prior to the 0.7.0 changes. 

this may be a useful question for others, I'll post in the group too but meanwhile to save time I'm emailing you a direct reply here for now.

Many thanks,
Louis


On Wed, 13 May 2020 at 08:32, Louis Botterill <chillip...@gmail.com> wrote:
Hi Nadav,

Great, thanks very much.
It's been a very long time since I first set this up, so maybe I forgot some details, specifically then;

Since the only version I reference is in the plugin line (as far as I can see), which is

addSbtPlugin("com.trueaccord.scalapb" % "sbt-scalapb" % "0.5.9")

I should just change this to 0.8.4. and that should bring in the correct transitives, the runtime component and also the sbt-protoc version would update accordingly?

Or is there some other component of this I've set somewhere and since forgotten about, the sbt-protoc where I can try to set the version to 0.99.27

Will this update produce case classes in the same way as the old version I am using? Or the same with minor changes?

Also I presume this will be fine with same protoc compiler binary.

Many thanks, Louis


On Tue, 12 May 2020 at 22:50, Nadav Samet <thes...@gmail.com> wrote:
Hi Louis,

The most recent version of ScalaPB that supports 2.10/2.11 is 0.8.4.

The most recent version of sbt-protoc that supports SBT 0.13.x is 0.99.27. I believe these two versions of sbt-protoc and ScalaPB should work together, however if you are seeing errors during compilation that indicate binary incompatibility (like MethodNotFoundException or ClassNotFoundException), look for the latest sbt-protoc that would work (based on changelog 0.99.18 should be fine)

The transition from your current version require some renaming of package so please follow the migration notes here. When you are ready to update Scala and SBT to recent version, the transition from 0.8.4 to 0.10.x is pretty straightforward.

Hope this helps!

-Nadav




On Tue, May 12, 2020 at 7:29 PM Louis B <chillip...@gmail.com> wrote:
Hi

I'm using scala pb, but an old version (which actually works just fine) 

addSbtPlugin("com.trueaccord.scalapb" % "sbt-scalapb" % "0.5.9")


however I'm conscious this version is getting very old and I should upgrade soon. But, I doubt I can move to the very latest for many reasons, old sbt 0.13 for one, scala 2.10 for another, for now.


So, I'm looking to find an intermediate version that hopefully drops-in and meets these goals:

 

Same basic case class construction (not using lenses etc so that doesn’t matter)


Works with SBT 0.13.x still (launched by scala 2.10 or 2.11)

Works with Scala 2.10 and 2.11 (compile, libs, target) alike (runs on JRE 8)

Uses same python 2.7 (or no longer needs it)


What can you recommend as a latest intermediate plugin version that I can just try in the above setting.


Later I will trying newer versions but for now, just want to make a stepping stone forward.


What do you recommend? If you can recommend a suitable version,I will give it a try out!


Many thanks in advance, Louis


--
You received this message because you are subscribed to the Google Groups "ScalaPB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scalapb+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scalapb/71b9115e-4b21-483d-9944-73cf697154d2%40googlegroups.com.


--
-Nadav


--
Web: www.chillipower.com
Blog: http://louisbotterill.blogspot.com/
Twitter: http://twitter.com/BinaryJunkie
LinkedIn: http://uk.linkedin.com/pub/louis-botterill/10/3b2/265

“The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt.” –Bertrand Russell

Please consider your environmental responsibility before printing this e-mail


--
Web: www.chillipower.com
Blog: http://louisbotterill.blogspot.com/
Twitter: http://twitter.com/BinaryJunkie
LinkedIn: http://uk.linkedin.com/pub/louis-botterill/10/3b2/265

“The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt.” –Bertrand Russell

Please consider your environmental responsibility before printing this e-mail


--
Web: www.chillipower.com
Blog: http://louisbotterill.blogspot.com/
Twitter: http://twitter.com/BinaryJunkie
LinkedIn: http://uk.linkedin.com/pub/louis-botterill/10/3b2/265

“The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt.” –Bertrand Russell

Please consider your environmental responsibility before printing this e-mail


--
-Nadav


--
Web: www.chillipower.com
Blog: http://louisbotterill.blogspot.com/
Twitter: http://twitter.com/BinaryJunkie
LinkedIn: http://uk.linkedin.com/pub/louis-botterill/10/3b2/265

“The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt.” –Bertrand Russell

Please consider your environmental responsibility before printing this e-mail


--
-Nadav


--
-Nadav


--
Web: www.chillipower.com
Blog: http://louisbotterill.blogspot.com/
Twitter: http://twitter.com/BinaryJunkie
LinkedIn: http://uk.linkedin.com/pub/louis-botterill/10/3b2/265

“The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt.” –Bertrand Russell

Please consider your environmental responsibility before printing this e-mail


--
-Nadav


--
-Nadav

Nadav Samet

unread,
May 29, 2020, 11:54:12 AM5/29/20
to Louis Botterill, ScalaPB
Normally there is a single top-level build.sbt, where the different subprojects are defined. Each project would have their own settings there, and those
that have modules under src/main/protobuf need to have `PB.targets in Compile` defined for them.

Regarding the dependency question:
sbt-protoc depends on protoc-brige
compilerplugin depends on protoc-bridge

There is no dependency between sbt-protoc and compilerplugin, but the versions you pick need to be binary compatible. The numbers suggested above should work.

It is hard to follow what is your exact set up. I suggest that you create a small project on github that represents a minimal version of your project structure, and experiment there in a way that would be observable, otherwise it's hard to tell why things are not working.

-Nadav



On Fri, May 29, 2020 at 6:46 AM Louis Botterill <chillip...@gmail.com> wrote:
Hi,

Also on further trying I see it is not producing compiled classes from the protos

can see this message during compile:

[info] Protobufs files found, but PB.targets is empty.

so then I tried to add as per;

Add a value to gen.targets:

PB.targets in Compile := Seq(
  scalapb.gen() -> (sourceManaged in Compile).value
)
So I don't have this file gen.targets already and the proto files are all in their own sbt project module. In that module I added the file gen.targets with above content but I still get

[info] Protobufs files found, but PB.targets is empty.

Where should these targets settings lines go, file name and in relation to the module, in the module or at the root project level?

and can I access PB still from code, is there a new import for it? So I can just do this in our build.scala initially if that is easier.

Many thanks,
Louis





On Fri, 29 May 2020 at 08:54, Louis Botterill <chillip...@gmail.com> wrote:
Hi,

Ok so I can try out 0.99.18  of "com.thesamet" % "sbt-protoc" plugin.

How is  "but the option is still there and ignored, in order not to break the build." possible if the PB object is removed?

So I still don't understand how if the only definition I add is the sbt-protoc 0.99.18 how does this tie to a ScalaPB version, in particular based on the original discussion, moving to 0.6.7 first to avoid artifact and package renaming and other breaking changes.

Does sbt-protoc 0.99.18 internally depend on ScalaPB 0.6.7?

I'm referring here to the start of our discussion where I said I was looking for sbt 0.13.x scala 2.10 / 2.11 compatible upgrade without too many breaking changes and we can to agree 0.6.7 and so I went and got these added to our internal repo;

<groupId>com.trueaccord.scalapb</groupId>

<artifactId>scalapb-runtime_2.10</artifactId>

<version>0.6.7</version>

 

<groupId>com.trueaccord.scalapb</groupId>

<artifactId>scalapb-runtime_2.11</artifactId>

<version>0.6.7</version>

 

<groupId>com.trueaccord.scalapb</groupId>

<artifactId>compilerplugin_2.10</artifactId>

<version>0.6.7</version>

<groupId>com.trueaccord.scalapb</groupId>

<artifactId>compilerplugin_2.11</artifactId>

<version>0.6.7</version>


Are these going to be used as internal dependencies of the 0.99.18 sbt-protoc or if not, what is and how does it work, how do I control the versions of scalapb-runtime and compilerplugin

Or these no longer used at all?

All the best, Louis



--
-Nadav

Nadav Samet

unread,
May 29, 2020, 12:53:16 PM5/29/20
to Louis Botterill, ScalaPB
(please use reply-all to include the group)

sbt-protoc is an auto plugin, which means by default it is applied to all projects, and that "PB" is imported automatically into your build.sbt - no need to import that, and this is why the migration guide is instructing you to remove the import alias.

AFAIK, sbt plugins are global - they apply to all sub-projects automatically. In general the plugin does nothing if PB.targets is not defined, but may show warnings if there are protos. You can disable the plugin for a specific subproject by adding this to the sub-project you want to disable the plugin for:

disablePlugins(ProtocPlugin) 


I understand your project is complex, but I think it would be simpler to help you if you create a similar project structure in a new project so the same problems will surface. Please capture the relevant parts that cause problems in your migration so it will be easier to help you.
 



On Fri, May 29, 2020 at 9:12 AM Louis Botterill <chillip...@gmail.com> wrote:
Hi,

Ok so the way our project is setup is a top level ./project/ has plugins.sbt etc defined globally
However, definitely don't want to pull in or incur protoc in all modules, we have more than 10 and only one contains all the proto stuff.

The way that was achieved was programmatically in a build.scala the lines I shared setup settings for proto only added to the proto module.

I think all we want to do is achieve that.

Issue is, programmatically I can't seem to import PB (as an alias) anymore, that would be easiest to apply like for like.

If I want to put in the module i.e. ./proto/build.sbt or similar it seems not to know what scalapb is in the line

PB.targets in Compile := Seq( scalapb.gen() -> (sourceManaged in Compile).value )

So while I'm sure in a new simple project it will work, I guess it's not going to help me apply to our real project which is a bit more complex and is where the problem occurs.

Either for now I need to programmatically set the settings for protoc on just the module it applies to only (which is how we have it working now) or need to know why in a module's build.sbt the lines listed in the migration don't work, sbt spits them out as the objects like scapapb are not defined.
I can see however the plugin and dependencies are loaded, or it's probably just a syntax thing your guide doesn't cover.

What are the options for doing it programmatically or fixing the build.sbt for gen targets in a multi-module project such that it finds the required definitions? I also want to avoid making proto leak into all the modules of the project, that was the point of keeping it in one self-contained build module (project) that worked very well with earlier scalapb versions.

In earlier email I think I shared all relevant parts of our build wrt. protoc, there really isn't much too it.

have you ever tried it in a project with more than one module, can your guide be tweaked to add some notes around it?

All the best, Louis



--
-Nadav

Nadav Samet

unread,
May 29, 2020, 2:32:23 PM5/29/20
to Louis B, ScalaPB
Looks like you are missing the dependency on the version of compilerplugin that you want to use. It needed to be added as a libraryDependency to project/plugins.sbt. The migration guide doesn't mention it, since it was supposed to be there prior to the migration.

On Fri, May 29, 2020 at 11:14 AM Louis B <chillip...@gmail.com> wrote:
Hi Nadav,

Thanks for the reply. If we can’t solve as is I’ll make a project but I think the setup and error is so straightforward it must be possible to think of the cause as-is.

I share an outline of the project and relevant files/content and then what happens when you start sbt (0.13.xj;

ls

 

...

project/

  plugins.sbt

proto/

other-modules/

build.sbt

 

./project/plugins.sbt

 

addSbtPlugin("com.thesamet" % "sbt-protoc" % "0.99.18")

 

./build.sbt

 

PB.targets in Compile := Seq(

  scalapb.gen() -> (sourceManaged in Compile).value

)

 

$ sbt

[info] Loading global plugins from ~\.sbt\0.13\plugins

[info] Loading project definition from ~\dev\projects\spark-aggregator\project

[info] Compiling 2 Scala sources to ~\dev\projects\spark-aggregator\project\target\scala-2.10\sbt-0.13\classes...

Building for Java version: 1.8

JAVA_OPTS: -Xms256m -Xmx16g -Djavax.net.ssl.trustStore=java.cacerts

SBT_OPTS: -Xmx16g -Dsbt.repository.config=repositories -Dsbt.override.build.repos=true -Djavax.net.ssl.trustStore=java.cacerts

Python executable: 'C:\cygwin64\bin\python2.7.exe'

Aggregating the following projects : config, utils, solace, svcInterface, proto, datapacket, transformers, berkeleydb, clusterCommon, webservice, ingestion, aggregation, aggservice, integrationTest

 

~\dev\projects\spark-aggregator\build.sbt:12: error: not found: value scalapb

  scalapb.gen() -> (sourceManaged in Compile).value

  ^

[error] Type error in expression

Project loading failed: (r)etry, (q)uit, (l)ast, or (i)gnore?




Sent from my iPad Pro

On May 29, 2020, at 12:53 PM, Nadav Samet <thes...@gmail.com> wrote:




--
-Nadav

Louis Botterill

unread,
Jun 1, 2020, 10:18:27 PM6/1/20
to Nadav Samet, ScalaPB
Hi Nadav,

Ok so I've added that and with the gen targets in build.sbt it still says not defined as before

i.e. with 


./project/plugins.sbt

 

//addSbtPlugin("com.trueaccord.scalapb" % "sbt-scalapb" % "0.4.14")

addSbtPlugin("com.thesamet" % "sbt-protoc" % "0.99.18")

 

//libraryDependencies += "com.thesamet.scalapb" %% "compilerplugin" % "0.10.2"

libraryDependencies += "com.trueaccord.scalapb" %% "compilerplugin" % "0.6.7"


and in ./build.sbt

PB.targets in Compile := Seq(

  scalapb.gen() -> (sourceManaged in Compile).value

)


SBT boots up but I still get no classes created and I can still see 

"Protobuffs files found, but PB.targets is empty" even though set in build.sbt as recommended

if then instead (or as well as) I try add to the module as a setting as per bellow sbt won't boot again, seems still not happy with objects in scope, definitely don't require imports with these versions?

project/Build.scala

 

import scalapb.compiler.Version.scalapbVersion

 

lazy val scalaPbSettings = {

    PB.protobufSettings ++ PB.targets in Compile := Seq(

      scalapb.gen() -> (sourceManaged in Compile).value

    )

  }

 

/// protobuf module - ScalaPb protocol-buffers builder

  lazy val protoPrj = Project(

    id = "proto",

    base = file("proto")

  ) dependsOn (utilsPrj % defaultProjectScopeInheritance) settings(

    globalSettings,

    libraryDependencies ++= coreDeps ++ formatConverterDeps,

    scalaPbSettings

  )

 

[error] C:\dev\projects\spark-aggregator\project\ProjectSettings.scala:57: not found: value PB

[error]     PB.protobufSettings ++ PB.targets in Compile := Seq(

[error]     ^

[error] C:\dev\projects\spark-aggregator\project\ProjectSettings.scala:55: object compiler is not a member of package scalapb

[error]   import scalapb.compiler.Version.scalapbVersion

[error]                  ^

[error] two errors found


Is there some difference with how this works in SBT 0.13.x ver 1.x and / or with the earlier compiler 0.6.7 chosen?

Many thanks, Louis

Louis

unread,
Jun 1, 2020, 10:18:27 PM6/1/20
to Nadav Samet, ScalaPB
Please ignore the bit about missing classes, looks like an sbt incremental compile issue. It’s creating classes :) I will test more next week. Thanks for all the help...


On May 29, 2020, at 5:34 PM, Louis Botterill <chillip...@gmail.com> wrote:


Hi,

Ok with the correct import to resolve PB in the Build.scala it seems the scalapb is producing compiled classes, which is a good step forward now.
However, some existing code in the src/main/scala of the same module can no longer see these protoc generated classes, just get object xxx is not a member of package yyy.
I checked and the generated classes seem to have the same correct package name structure, so it's not like they moved.
Is there a change to the compile order, is code in same module not compiled after the protoc classes, with the protoc classes target on the classpath of the compile and test phases?

All the best, Louis

Louis B

unread,
Jun 1, 2020, 10:18:27 PM6/1/20
to Nadav Samet, ScalaPB
Hi Nadav,

Thanks for the reply. If we can’t solve as is I’ll make a project but I think the setup and error is so straightforward it must be possible to think of the cause as-is.

I share an outline of the project and relevant files/content and then what happens when you start sbt (0.13.xj;

ls

 

...

project/

  plugins.sbt

proto/

other-modules/

build.sbt

 

./project/plugins.sbt

 

addSbtPlugin("com.thesamet" % "sbt-protoc" % "0.99.18")

 

./build.sbt

 

PB.targets in Compile := Seq(

  scalapb.gen() -> (sourceManaged in Compile).value

)

 

$ sbt

[info] Loading global plugins from ~\.sbt\0.13\plugins

[info] Loading project definition from ~\dev\projects\spark-aggregator\project

[info] Compiling 2 Scala sources to ~\dev\projects\spark-aggregator\project\target\scala-2.10\sbt-0.13\classes...

Building for Java version: 1.8

JAVA_OPTS: -Xms256m -Xmx16g -Djavax.net.ssl.trustStore=java.cacerts

SBT_OPTS: -Xmx16g -Dsbt.repository.config=repositories -Dsbt.override.build.repos=true -Djavax.net.ssl.trustStore=java.cacerts

Python executable: 'C:\cygwin64\bin\python2.7.exe'

Aggregating the following projects : config, utils, solace, svcInterface, proto, datapacket, transformers, berkeleydb, clusterCommon, webservice, ingestion, aggregation, aggservice, integrationTest

 

~\dev\projects\spark-aggregator\build.sbt:12: error: not found: value scalapb

  scalapb.gen() -> (sourceManaged in Compile).value

  ^

[error] Type error in expression

Project loading failed: (r)etry, (q)uit, (l)ast, or (i)gnore?




Sent from my iPad Pro

On May 29, 2020, at 12:53 PM, Nadav Samet <thes...@gmail.com> wrote:



Louis Botterill

unread,
Jun 1, 2020, 10:18:27 PM6/1/20
to Nadav Samet, ScalaPB
Hi,

Ok with the correct import to resolve PB in the Build.scala it seems the scalapb is producing compiled classes, which is a good step forward now.
However, some existing code in the src/main/scala of the same module can no longer see these protoc generated classes, just get object xxx is not a member of package yyy.
I checked and the generated classes seem to have the same correct package name structure, so it's not like they moved.
Is there a change to the compile order, is code in same module not compiled after the protoc classes, with the protoc classes target on the classpath of the compile and test phases?

All the best, Louis

Reply all
Reply to author
Forward
0 new messages