With the scribe-source currently in review, I tried generating the
sources myself using the compileThrift profile. Turns out this no longer
runs in either it or the legacy thrift source(did it ever?) because the
maven-thrift-plugin is no longer locatable on the maven repo.

Both sources work fine with the pre-generated sources,  and these have
apache licenses added to them. Is it ok to add the license to generated
code? I presume so, just want to verify.

In the case of the new scribe source, the actual thrift protocol it uses
is that of scribe, and the *.thrift file is not included, I presume we
cannot include this and should advise users wanting to send data using
the scribe protocol to pick up the thrift file from the scribe github
project?

Also should we just cut out the broken code generation from the .pom files?

On Sun, Aug 5, 2012 at 10:29 PM, Juhani Connolly <
[EMAIL PROTECTED]> wrote:

> With the scribe-source currently in review, I tried generating the sources
> myself using the compileThrift profile. Turns out this no longer runs in
> either it or the legacy thrift source(did it ever?) because the
> maven-thrift-plugin is no longer locatable on the maven repo.
>

I have not tried myself... but I believe it only works with a certain
version of the Thrift code generation binaries installed (this is a common
complaint about Thrift-based RPC).

Both sources work fine with the pre-generated sources,  and these have
> apache licenses added to them. Is it ok to add the license to generated
> code? I presume so, just want to verify.
>

I believe if the code generator permits any license then you have the right
to contribute that code under any license you prefer.
> In the case of the new scribe source, the actual thrift protocol it uses
> is that of scribe, and the *.thrift file is not included, I presume we
> cannot include this and should advise users wanting to send data using the
> scribe protocol to pick up the thrift file from the scribe github project?
>

I believe Scribe is ASL 2.0 licensed. If the thrift file is ASL 2.0
licensed, then we can include it. However, this adds a build-time
dependency to (a specific version of) Thrift, so I'd be inclined to check
in the generated code and make it possible to regenerate it via Maven, like
the legacy stuff is supposed to work.

Also should we just cut out the broken code generation from the .pom files?
>

I'd lean toward leaving it there... it documents at least how it was
supposed to be built. For all we know, it still works with Thrift 0.3. If
anyone has time to test it, that would be great...

Hi Mike,

thanks for your input

On 08/07/2012 05:32 AM, Mike Percy wrote:
> On Sun, Aug 5, 2012 at 10:29 PM, Juhani Connolly <
> [EMAIL PROTECTED]> wrote:
>
>> With the scribe-source currently in review, I tried generating the sources
>> myself using the compileThrift profile. Turns out this no longer runs in
>> either it or the legacy thrift source(did it ever?) because the
>> maven-thrift-plugin is no longer locatable on the maven repo.
>>
> I have not tried myself... but I believe it only works with a certain
> version of the Thrift code generation binaries installed (this is a common
> complaint about Thrift-based RPC).

It's actually the pluging pom file not getting found that seems to be
the problem. Looks like it was removed from the maven repo?
>
> Both sources work fine with the pre-generated sources,  and these have
>> apache licenses added to them. Is it ok to add the license to generated
>> code? I presume so, just want to verify.
>>
> I believe if the code generator permits any license then you have the right
> to contribute that code under any license you prefer.
>
>
>> In the case of the new scribe source, the actual thrift protocol it uses
>> is that of scribe, and the *.thrift file is not included, I presume we
>> cannot include this and should advise users wanting to send data using the
>> scribe protocol to pick up the thrift file from the scribe github project?
>>
> I believe Scribe is ASL 2.0 licensed. If the thrift file is ASL 2.0
> licensed, then we can include it. However, this adds a build-time
> dependency to (a specific version of) Thrift, so I'd be inclined to check
> in the generated code and make it possible to regenerate it via Maven, like
> the legacy stuff is supposed to work.

Ok, will do. Looks like the patch is good as is then.
>
> Also should we just cut out the broken code generation from the .pom files?
> I'd lean toward leaving it there... it documents at least how it was
> supposed to be built. For all we know, it still works with Thrift 0.3. If
> anyone has time to test it, that would be great...
>

Ok, I'll leave it in, and maybe down the line if the maven side things
get fixed we can make whatever fixes are necessary.