Having trouble getting generated thrift java files compiled and packaged

386 views
Skip to first unread message

andrew

unread,
Aug 11, 2011, 3:10:37 PM8/11/11
to simple-build-tool
Hello,

Currently I have a task configured to generate thrift java sources
which is generating the sources correctly; so far so good. The problem
that the java sources never get compiled or included in binary and
source jars when I run package.

The target directory for the sources is obtained by:

(sourceManaged in Compile) map { ... }

This results in my java files in:

target/scala-2.9.0.final/src_managed/main/gen-java/

I see that the java files are included under a 'scala-2.9.0.final'
directory which I am sure is one of my problems. I don't see a way to
create a java specific managed source directory or a way to add these
sources to 'javaSource' since javaSource is a Setting[FIle] and not a
Setting[Seq[File]]. I have searched the web and the message group and
I haven't been able to find another example of generated java sources
in sbt .10+. Any tips on how to move forward would be much appreciated
as I am at a bit of a loss right now.

Thanks,
Andy

andrew

unread,
Aug 11, 2011, 8:10:04 PM8/11/11
to simple-build-tool
Ok. The thrift java sources are compiling but are not appearing on the
classpath for the scala files contained in the project or for the
projects that depend on the thrift project.

I looked at the examples in:
https://github.com/harrah/xsbt/wiki/Common-Tasks

tried them and any variations I could think of but no luck.

project ->
api ->

andrew

unread,
Aug 11, 2011, 8:21:18 PM8/11/11
to simple-build-tool
( i accidentally submitted the last post before I was finished.
Continuing.. )

Here is my layout:

project base ->
---- api ->
--------- src/main/thrift/ { all my thrift files }
--------- src/main/scala/ { scala files using generated thrift code }
--------- target/scala-2.9.0.final/src_managed/gen-java/ { thrift java
code is generated here }
--------- target/scala-2.9.0.final/classes/ { java thrift
compiled .class files are here }
----- core ->
--------- src/main/scala/ { packages with code that depends on the api
project ( scala and thrift types ) }

It seems that if the thrift .class files are being generated in the
classes target dir then they should be included on the project's
classpath, get packaged and be available to other projects.

Thanks,
Andy

Arjan Blokzijl

unread,
Aug 12, 2011, 2:35:07 AM8/12/11
to simple-b...@googlegroups.com
Hi Andrew,

We do a similar thing in our project, although java files are generated from a wsdl file. We now use the following settings for this:


The thing that made it work is to ensure that source generation runs before the compile step, so the line:

compile in Compile <<= compile in Compile dependsOn (genwsdl in GenWsdlConfig)

only using the sourceGenerators in Compile <+= (genwsdl in GenWsdlConfig).identity 
setting does not seem to be sufficient for that. I'm not sure whether this can be done more elegantly, but at least it's working for us.

Cheers, Arjan

--
You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
To post to this group, send email to simple-b...@googlegroups.com.
To unsubscribe from this group, send email to simple-build-t...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/simple-build-tool?hl=en.


andrew

unread,
Aug 12, 2011, 1:29:51 PM8/12/11
to simple-build-tool
Great. Thanks. I now have everything compiling correctly. I now just
need to solve the packaging issue.

All the best,
Andy

On Aug 11, 11:35 pm, Arjan Blokzijl <arjanblokz...@gmail.com> wrote:
> Hi Andrew,
>
> We do a similar thing in our project, although java files are generated from
> a wsdl file. We now use the following settings for this:
>
> https://gist.github.com/1141567
>
> The thing that made it work is to ensure that source generation runs before
> the compile step, so the line:
>
> compile in Compile <<= compile in Compile dependsOn (genwsdl in
> GenWsdlConfig)
>
> <https://gist.github.com/1141567>only using the sourceGenerators in Compile
> <+= (genwsdl in GenWsdlConfig).identity
> setting does not seem to be sufficient for that. I'm not sure whether this
> can be done more elegantly, but at least it's working for us.
>
> Cheers, Arjan
>

Arjan Blokzijl

unread,
Aug 12, 2011, 1:44:07 PM8/12/11
to simple-b...@googlegroups.com
Good. What exactly is your packaging issue?

andrew

unread,
Aug 12, 2011, 2:32:40 PM8/12/11
to simple-build-tool
When I generate my jar, none of the generated sources are in the .jar,
javadoc.jar or sources.jar.

-A

On Aug 12, 10:44 am, Arjan Blokzijl <arjanblokz...@gmail.com> wrote:
> Good. What exactly is your packaging issue?
>

andrew

unread,
Aug 12, 2011, 2:39:11 PM8/12/11
to simple-build-tool
Don't ask me why but the exact same code that wasn't working for me
yesterday is now working. I'm all good.

Sbt is a great tool but sometimes it really makes me feel like an
idiot. ;-)

Thanks for the help!!

All the best,
Andy

On Aug 12, 10:44 am, Arjan Blokzijl <arjanblokz...@gmail.com> wrote:
> Good. What exactly is your packaging issue?
>

Arjan Blokzijl

unread,
Aug 12, 2011, 11:34:10 PM8/12/11
to simple-b...@googlegroups.com

Good to hear that it works, perhaps Mark can tell whether this is actually the right way to do this.
We have seen that the build configuration mentioned in https://gist.github.com/1141567 does not work unless the explicit dependency on the compile task is added (I think this also makes the line 'Seq(sourceGenerators in Compile <+= (genwsdl in GenWsdlConfig).identity' that is in this configuration obsolete, but haven't tried this yet).
If the compile dependency is not there, the first time I tried to compile failed because the files in the project that have a dependency on the generated sources are compiled apparently without the generated ones being available on the classpath. When I compiled a second time (without doing a clean) compilation succeeded, as the generated sources were already present, and this time they were available on the classpath. 
I found this behaviour a bit surprising, so my question is whether this is intentional? If so, it might make sense to add this to the Wiki.

Cheers, Arjan

Mark Harrah

unread,
Aug 14, 2011, 7:27:02 PM8/14/11
to simple-b...@googlegroups.com
On Sat, 13 Aug 2011 05:34:10 +0200
Arjan Blokzijl <arjanb...@gmail.com> wrote:

> Good to hear that it works, perhaps Mark can tell whether this is actually
> the right way to do this.
> We have seen that the build configuration mentioned in
> https://gist.github.com/1141567 does not work unless the explicit dependency
> on the compile task is added (I think this also makes the line 'Seq(
> sourceGenerators in Compile <+= (genwsdl in GenWsdlConfig).identity' that is
> in this configuration obsolete, but haven't tried this yet).
> If the compile dependency is not there, the first time I tried to compile
> failed because the files in the project that have a dependency on the
> generated sources are compiled apparently without the generated ones being
> available on the classpath. When I compiled a second time (without doing a
> clean) compilation succeeded, as the generated sources were already present,
> and this time they were available on the classpath.
> I found this behaviour a bit surprising, so my question is whether this is
> intentional? If so, it might make sense to add this to the Wiki.

No, it is not intentional. It would help if you could provide a reproducible example.

-Mark

Arjan Blokzijl

unread,
Aug 15, 2011, 2:20:12 AM8/15/11
to simple-b...@googlegroups.com
It turned out to be a mistake by me: the generated Java sources were generated by a script that calls wsimport to generate the sources from a WSDL file. This is an external process so we don't directly control what files are generated. Being lazy, I therefore just returned an empty Seq from the task that generates the sources instead of the actual list of generated files, causing the described behavior. 
Returning (targetDir ** "*.java").get from the task works perfect however, sorry for the confusion. 

Arjan
Reply all
Reply to author
Forward
0 new messages