You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by Tobi Knaup <to...@knaup.me> on 2014/04/16 06:15:42 UTC

Review Request 20402: Use maven to compile and package Mesos' Java files

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20402/
-----------------------------------------------------------

Review request for mesos.


Bugs: MESOS-1212
    https://issues.apache.org/jira/browse/MESOS-1212


Repository: mesos-git


Description
-------

Use Maven to build the Mesos jars, and include shaded protbuf jar.
No longer builds a custom protobuf jar but relies on Maven.

NOTE: #20329 (shading) is a breaking change for JVM frameworks which use the com.google.protobuf namespace. These need to change to org.apache.mesos.com.google.protobuf.

Includes the dependent patch from https://reviews.apache.org/r/20329/ which I'll delete once that's merged.


Diffs
-----

  configure.ac c1de6d7 
  src/Makefile.am 560b4c7 
  src/examples/java/TestExceptionFramework.java 464b3b0 
  src/examples/java/TestFramework.java 65ee2dc 
  src/examples/java/TestMultipleExecutorsFramework.java 6846959 
  src/examples/java/test-exception-framework.in 26617e2 
  src/examples/java/test-executor.in 8b27a37 
  src/examples/java/test-framework.in bbdc1ed 
  src/examples/java/test-log.in b7e69e4 
  src/examples/java/test-multiple-executors-framework.in eb8edf6 
  src/java/mesos.pom.in 8f9b747 

Diff: https://reviews.apache.org/r/20402/diff/


Testing
-------

make check
make maven-install


Thanks,

Tobi Knaup


Re: Review Request 20402: Use maven to compile and package Mesos' Java files

Posted by Tobi Knaup <to...@knaup.me>.

> On April 16, 2014, 3:22 p.m., Benjamin Hindman wrote:
> > This is awesome Tobi!
> > 
> > One question: Can we actually still use protobuf.jar with the example frameworks? My expectation is that existing frameworks should be able to continue to use their protobuf dependencies and we've just shaded all use of protobuf from them. That way we don't require frameworks/users to use org.apache.mesos.com.google.protobuf... but perhaps I'm missing something here? Assuming that works, we can drop all the changes to Java example code (which should make this diff even simpler) since that will stand as a reference for how we expect people to still use Mesos.
> > 
> > Also, it's great to see the configure check and apparently our build machines don't have maven!? I'll look into that for you ASAP.
> 
> Tobi Knaup wrote:
>     Thanks Ben. In the current form you have to get rid of the protobuf jar because the code generated from the Mesos protos expects the shaded namespace. For example ExecutorInfo.Builder#setData() expects a org.apache.mesos.com.google.protobuf.ByteString now.
>     
>     This is awkward and I thought about a better solution. We should build two jars: The regular mesos-VERSION.jar will be unchaged, and we build an additional shaded mesos-with-protobuf-VERSION.jar for projects with conflicting protobuf versions. That way the "normal" way remains the same, but we give affected projects an upgrade path at the small cost of changing the namespace. Over time these projects will hopefully move to 2.5 and can use the regular jar again.
>     
>     Thoughts?
> 
> Benjamin Hindman wrote:
>     Ah, I see now. The two jar solution sounds good to me. The only other thing I can think of is providing some wrappers (e.g., ByteString_To_Mesos_Protobuf_2_5_0_ByteString) but since this issue seems like it will boil down to an individual project and whether or not they know they have this problem (or one of their users has this problem) they should be able to start with the un-shaded jar and move to the shaded jar on demand (and make the protobuf changes then). I've added Patrick Wendell to this review to see if there was anything they did in particular for Spark to deal with this case.
> 
> Benjamin Hindman wrote:
>     FYI, I updated Jenkins so hopefully the review bot will pick this up and test it for us.

Thanks! A wrapper would work too, I'd argue though that a namespace change is less invasive and easier to revert later.


- Tobi


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20402/#review40553
-----------------------------------------------------------


On April 16, 2014, 4:24 p.m., Tobi Knaup wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20402/
> -----------------------------------------------------------
> 
> (Updated April 16, 2014, 4:24 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Patrick Wendell.
> 
> 
> Bugs: MESOS-1212
>     https://issues.apache.org/jira/browse/MESOS-1212
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Use Maven to build the Mesos jars, and include shaded protbuf jar.
> No longer builds a custom protobuf jar but relies on Maven.
> 
> NOTE: #20329 (shading) is a breaking change for JVM frameworks which use the com.google.protobuf namespace. These need to change to org.apache.mesos.com.google.protobuf.
> 
> Includes the dependent patch from https://reviews.apache.org/r/20329/ which I'll delete once that's merged.
> 
> 
> Diffs
> -----
> 
>   configure.ac c1de6d7 
>   src/Makefile.am 560b4c7 
>   src/examples/java/TestExceptionFramework.java 464b3b0 
>   src/examples/java/TestFramework.java 65ee2dc 
>   src/examples/java/TestMultipleExecutorsFramework.java 6846959 
>   src/examples/java/test-exception-framework.in 26617e2 
>   src/examples/java/test-executor.in 8b27a37 
>   src/examples/java/test-framework.in bbdc1ed 
>   src/examples/java/test-log.in b7e69e4 
>   src/examples/java/test-multiple-executors-framework.in eb8edf6 
>   src/java/mesos.pom.in 8f9b747 
> 
> Diff: https://reviews.apache.org/r/20402/diff/
> 
> 
> Testing
> -------
> 
> make check
> make maven-install
> 
> 
> Thanks,
> 
> Tobi Knaup
> 
>


Re: Review Request 20402: Use maven to compile and package Mesos' Java files

Posted by Vinod Kone <vi...@gmail.com>.

> On April 16, 2014, 3:22 p.m., Benjamin Hindman wrote:
> > This is awesome Tobi!
> > 
> > One question: Can we actually still use protobuf.jar with the example frameworks? My expectation is that existing frameworks should be able to continue to use their protobuf dependencies and we've just shaded all use of protobuf from them. That way we don't require frameworks/users to use org.apache.mesos.com.google.protobuf... but perhaps I'm missing something here? Assuming that works, we can drop all the changes to Java example code (which should make this diff even simpler) since that will stand as a reference for how we expect people to still use Mesos.
> > 
> > Also, it's great to see the configure check and apparently our build machines don't have maven!? I'll look into that for you ASAP.
> 
> Tobi Knaup wrote:
>     Thanks Ben. In the current form you have to get rid of the protobuf jar because the code generated from the Mesos protos expects the shaded namespace. For example ExecutorInfo.Builder#setData() expects a org.apache.mesos.com.google.protobuf.ByteString now.
>     
>     This is awkward and I thought about a better solution. We should build two jars: The regular mesos-VERSION.jar will be unchaged, and we build an additional shaded mesos-with-protobuf-VERSION.jar for projects with conflicting protobuf versions. That way the "normal" way remains the same, but we give affected projects an upgrade path at the small cost of changing the namespace. Over time these projects will hopefully move to 2.5 and can use the regular jar again.
>     
>     Thoughts?
> 
> Benjamin Hindman wrote:
>     Ah, I see now. The two jar solution sounds good to me. The only other thing I can think of is providing some wrappers (e.g., ByteString_To_Mesos_Protobuf_2_5_0_ByteString) but since this issue seems like it will boil down to an individual project and whether or not they know they have this problem (or one of their users has this problem) they should be able to start with the un-shaded jar and move to the shaded jar on demand (and make the protobuf changes then). I've added Patrick Wendell to this review to see if there was anything they did in particular for Spark to deal with this case.
> 
> Benjamin Hindman wrote:
>     FYI, I updated Jenkins so hopefully the review bot will pick this up and test it for us.
> 
> Tobi Knaup wrote:
>     Thanks! A wrapper would work too, I'd argue though that a namespace change is less invasive and easier to revert later.
> 
> Benjamin Hindman wrote:
>     I agree, let's go with the two jars. Also, I think I'd prefer to keep the examples using the non-shaded protobuf for now since that's what we "prefer" people use/do. We could add a TestFrameworkShaded.java to test the shaded version but feel free to punt for a subsequent review (and/or add a TODO in the makefile where we build the examples suggesting as much).

2 jars sounds great to me. We should also publish the shaded version of jars for 0.16.0 (protobuf-2.4.1), 0.17.0 (protobuf-2.5.0) and 0.18.0 (protobuf-2.5.0) in maven central?


- Vinod


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20402/#review40553
-----------------------------------------------------------


On April 16, 2014, 4:24 p.m., Tobi Knaup wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20402/
> -----------------------------------------------------------
> 
> (Updated April 16, 2014, 4:24 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Patrick Wendell.
> 
> 
> Bugs: MESOS-1212
>     https://issues.apache.org/jira/browse/MESOS-1212
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Use Maven to build the Mesos jars, and include shaded protbuf jar.
> No longer builds a custom protobuf jar but relies on Maven.
> 
> NOTE: #20329 (shading) is a breaking change for JVM frameworks which use the com.google.protobuf namespace. These need to change to org.apache.mesos.com.google.protobuf.
> 
> Includes the dependent patch from https://reviews.apache.org/r/20329/ which I'll delete once that's merged.
> 
> 
> Diffs
> -----
> 
>   configure.ac c1de6d7 
>   src/Makefile.am 560b4c7 
>   src/examples/java/TestExceptionFramework.java 464b3b0 
>   src/examples/java/TestFramework.java 65ee2dc 
>   src/examples/java/TestMultipleExecutorsFramework.java 6846959 
>   src/examples/java/test-exception-framework.in 26617e2 
>   src/examples/java/test-executor.in 8b27a37 
>   src/examples/java/test-framework.in bbdc1ed 
>   src/examples/java/test-log.in b7e69e4 
>   src/examples/java/test-multiple-executors-framework.in eb8edf6 
>   src/java/mesos.pom.in 8f9b747 
> 
> Diff: https://reviews.apache.org/r/20402/diff/
> 
> 
> Testing
> -------
> 
> make check
> make maven-install
> 
> 
> Thanks,
> 
> Tobi Knaup
> 
>


Re: Review Request 20402: Use maven to compile and package Mesos' Java files

Posted by Benjamin Hindman <be...@berkeley.edu>.

> On April 16, 2014, 3:22 p.m., Benjamin Hindman wrote:
> > This is awesome Tobi!
> > 
> > One question: Can we actually still use protobuf.jar with the example frameworks? My expectation is that existing frameworks should be able to continue to use their protobuf dependencies and we've just shaded all use of protobuf from them. That way we don't require frameworks/users to use org.apache.mesos.com.google.protobuf... but perhaps I'm missing something here? Assuming that works, we can drop all the changes to Java example code (which should make this diff even simpler) since that will stand as a reference for how we expect people to still use Mesos.
> > 
> > Also, it's great to see the configure check and apparently our build machines don't have maven!? I'll look into that for you ASAP.
> 
> Tobi Knaup wrote:
>     Thanks Ben. In the current form you have to get rid of the protobuf jar because the code generated from the Mesos protos expects the shaded namespace. For example ExecutorInfo.Builder#setData() expects a org.apache.mesos.com.google.protobuf.ByteString now.
>     
>     This is awkward and I thought about a better solution. We should build two jars: The regular mesos-VERSION.jar will be unchaged, and we build an additional shaded mesos-with-protobuf-VERSION.jar for projects with conflicting protobuf versions. That way the "normal" way remains the same, but we give affected projects an upgrade path at the small cost of changing the namespace. Over time these projects will hopefully move to 2.5 and can use the regular jar again.
>     
>     Thoughts?

Ah, I see now. The two jar solution sounds good to me. The only other thing I can think of is providing some wrappers (e.g., ByteString_To_Mesos_Protobuf_2_5_0_ByteString) but since this issue seems like it will boil down to an individual project and whether or not they know they have this problem (or one of their users has this problem) they should be able to start with the un-shaded jar and move to the shaded jar on demand (and make the protobuf changes then). I've added Patrick Wendell to this review to see if there was anything they did in particular for Spark to deal with this case.


- Benjamin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20402/#review40553
-----------------------------------------------------------


On April 16, 2014, 4:23 p.m., Tobi Knaup wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20402/
> -----------------------------------------------------------
> 
> (Updated April 16, 2014, 4:23 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Patrick Wendell.
> 
> 
> Bugs: MESOS-1212
>     https://issues.apache.org/jira/browse/MESOS-1212
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Use Maven to build the Mesos jars, and include shaded protbuf jar.
> No longer builds a custom protobuf jar but relies on Maven.
> 
> NOTE: #20329 (shading) is a breaking change for JVM frameworks which use the com.google.protobuf namespace. These need to change to org.apache.mesos.com.google.protobuf.
> 
> Includes the dependent patch from https://reviews.apache.org/r/20329/ which I'll delete once that's merged.
> 
> 
> Diffs
> -----
> 
>   configure.ac c1de6d7 
>   src/Makefile.am 560b4c7 
>   src/examples/java/TestExceptionFramework.java 464b3b0 
>   src/examples/java/TestFramework.java 65ee2dc 
>   src/examples/java/TestMultipleExecutorsFramework.java 6846959 
>   src/examples/java/test-exception-framework.in 26617e2 
>   src/examples/java/test-executor.in 8b27a37 
>   src/examples/java/test-framework.in bbdc1ed 
>   src/examples/java/test-log.in b7e69e4 
>   src/examples/java/test-multiple-executors-framework.in eb8edf6 
>   src/java/mesos.pom.in 8f9b747 
> 
> Diff: https://reviews.apache.org/r/20402/diff/
> 
> 
> Testing
> -------
> 
> make check
> make maven-install
> 
> 
> Thanks,
> 
> Tobi Knaup
> 
>


Re: Review Request 20402: Use maven to compile and package Mesos' Java files

Posted by Tobi Knaup <to...@knaup.me>.

> On April 16, 2014, 3:22 p.m., Benjamin Hindman wrote:
> > This is awesome Tobi!
> > 
> > One question: Can we actually still use protobuf.jar with the example frameworks? My expectation is that existing frameworks should be able to continue to use their protobuf dependencies and we've just shaded all use of protobuf from them. That way we don't require frameworks/users to use org.apache.mesos.com.google.protobuf... but perhaps I'm missing something here? Assuming that works, we can drop all the changes to Java example code (which should make this diff even simpler) since that will stand as a reference for how we expect people to still use Mesos.
> > 
> > Also, it's great to see the configure check and apparently our build machines don't have maven!? I'll look into that for you ASAP.

Thanks Ben. In the current form you have to get rid of the protobuf jar because the code generated from the Mesos protos expects the shaded namespace. For example ExecutorInfo.Builder#setData() expects a org.apache.mesos.com.google.protobuf.ByteString now.

This is awkward and I thought about a better solution. We should build two jars: The regular mesos-VERSION.jar will be unchaged, and we build an additional shaded mesos-with-protobuf-VERSION.jar for projects with conflicting protobuf versions. That way the "normal" way remains the same, but we give affected projects an upgrade path at the small cost of changing the namespace. Over time these projects will hopefully move to 2.5 and can use the regular jar again.

Thoughts?


- Tobi


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20402/#review40553
-----------------------------------------------------------


On April 16, 2014, 4:15 a.m., Tobi Knaup wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20402/
> -----------------------------------------------------------
> 
> (Updated April 16, 2014, 4:15 a.m.)
> 
> 
> Review request for mesos.
> 
> 
> Bugs: MESOS-1212
>     https://issues.apache.org/jira/browse/MESOS-1212
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Use Maven to build the Mesos jars, and include shaded protbuf jar.
> No longer builds a custom protobuf jar but relies on Maven.
> 
> NOTE: #20329 (shading) is a breaking change for JVM frameworks which use the com.google.protobuf namespace. These need to change to org.apache.mesos.com.google.protobuf.
> 
> Includes the dependent patch from https://reviews.apache.org/r/20329/ which I'll delete once that's merged.
> 
> 
> Diffs
> -----
> 
>   configure.ac c1de6d7 
>   src/Makefile.am 560b4c7 
>   src/examples/java/TestExceptionFramework.java 464b3b0 
>   src/examples/java/TestFramework.java 65ee2dc 
>   src/examples/java/TestMultipleExecutorsFramework.java 6846959 
>   src/examples/java/test-exception-framework.in 26617e2 
>   src/examples/java/test-executor.in 8b27a37 
>   src/examples/java/test-framework.in bbdc1ed 
>   src/examples/java/test-log.in b7e69e4 
>   src/examples/java/test-multiple-executors-framework.in eb8edf6 
>   src/java/mesos.pom.in 8f9b747 
> 
> Diff: https://reviews.apache.org/r/20402/diff/
> 
> 
> Testing
> -------
> 
> make check
> make maven-install
> 
> 
> Thanks,
> 
> Tobi Knaup
> 
>


Re: Review Request 20402: Use maven to compile and package Mesos' Java files

Posted by Benjamin Hindman <be...@berkeley.edu>.

> On April 16, 2014, 3:22 p.m., Benjamin Hindman wrote:
> > This is awesome Tobi!
> > 
> > One question: Can we actually still use protobuf.jar with the example frameworks? My expectation is that existing frameworks should be able to continue to use their protobuf dependencies and we've just shaded all use of protobuf from them. That way we don't require frameworks/users to use org.apache.mesos.com.google.protobuf... but perhaps I'm missing something here? Assuming that works, we can drop all the changes to Java example code (which should make this diff even simpler) since that will stand as a reference for how we expect people to still use Mesos.
> > 
> > Also, it's great to see the configure check and apparently our build machines don't have maven!? I'll look into that for you ASAP.
> 
> Tobi Knaup wrote:
>     Thanks Ben. In the current form you have to get rid of the protobuf jar because the code generated from the Mesos protos expects the shaded namespace. For example ExecutorInfo.Builder#setData() expects a org.apache.mesos.com.google.protobuf.ByteString now.
>     
>     This is awkward and I thought about a better solution. We should build two jars: The regular mesos-VERSION.jar will be unchaged, and we build an additional shaded mesos-with-protobuf-VERSION.jar for projects with conflicting protobuf versions. That way the "normal" way remains the same, but we give affected projects an upgrade path at the small cost of changing the namespace. Over time these projects will hopefully move to 2.5 and can use the regular jar again.
>     
>     Thoughts?
> 
> Benjamin Hindman wrote:
>     Ah, I see now. The two jar solution sounds good to me. The only other thing I can think of is providing some wrappers (e.g., ByteString_To_Mesos_Protobuf_2_5_0_ByteString) but since this issue seems like it will boil down to an individual project and whether or not they know they have this problem (or one of their users has this problem) they should be able to start with the un-shaded jar and move to the shaded jar on demand (and make the protobuf changes then). I've added Patrick Wendell to this review to see if there was anything they did in particular for Spark to deal with this case.

FYI, I updated Jenkins so hopefully the review bot will pick this up and test it for us.


- Benjamin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20402/#review40553
-----------------------------------------------------------


On April 16, 2014, 4:24 p.m., Tobi Knaup wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20402/
> -----------------------------------------------------------
> 
> (Updated April 16, 2014, 4:24 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Patrick Wendell.
> 
> 
> Bugs: MESOS-1212
>     https://issues.apache.org/jira/browse/MESOS-1212
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Use Maven to build the Mesos jars, and include shaded protbuf jar.
> No longer builds a custom protobuf jar but relies on Maven.
> 
> NOTE: #20329 (shading) is a breaking change for JVM frameworks which use the com.google.protobuf namespace. These need to change to org.apache.mesos.com.google.protobuf.
> 
> Includes the dependent patch from https://reviews.apache.org/r/20329/ which I'll delete once that's merged.
> 
> 
> Diffs
> -----
> 
>   configure.ac c1de6d7 
>   src/Makefile.am 560b4c7 
>   src/examples/java/TestExceptionFramework.java 464b3b0 
>   src/examples/java/TestFramework.java 65ee2dc 
>   src/examples/java/TestMultipleExecutorsFramework.java 6846959 
>   src/examples/java/test-exception-framework.in 26617e2 
>   src/examples/java/test-executor.in 8b27a37 
>   src/examples/java/test-framework.in bbdc1ed 
>   src/examples/java/test-log.in b7e69e4 
>   src/examples/java/test-multiple-executors-framework.in eb8edf6 
>   src/java/mesos.pom.in 8f9b747 
> 
> Diff: https://reviews.apache.org/r/20402/diff/
> 
> 
> Testing
> -------
> 
> make check
> make maven-install
> 
> 
> Thanks,
> 
> Tobi Knaup
> 
>


Re: Review Request 20402: Use maven to compile and package Mesos' Java files

Posted by Benjamin Hindman <be...@berkeley.edu>.

> On April 16, 2014, 3:22 p.m., Benjamin Hindman wrote:
> > This is awesome Tobi!
> > 
> > One question: Can we actually still use protobuf.jar with the example frameworks? My expectation is that existing frameworks should be able to continue to use their protobuf dependencies and we've just shaded all use of protobuf from them. That way we don't require frameworks/users to use org.apache.mesos.com.google.protobuf... but perhaps I'm missing something here? Assuming that works, we can drop all the changes to Java example code (which should make this diff even simpler) since that will stand as a reference for how we expect people to still use Mesos.
> > 
> > Also, it's great to see the configure check and apparently our build machines don't have maven!? I'll look into that for you ASAP.
> 
> Tobi Knaup wrote:
>     Thanks Ben. In the current form you have to get rid of the protobuf jar because the code generated from the Mesos protos expects the shaded namespace. For example ExecutorInfo.Builder#setData() expects a org.apache.mesos.com.google.protobuf.ByteString now.
>     
>     This is awkward and I thought about a better solution. We should build two jars: The regular mesos-VERSION.jar will be unchaged, and we build an additional shaded mesos-with-protobuf-VERSION.jar for projects with conflicting protobuf versions. That way the "normal" way remains the same, but we give affected projects an upgrade path at the small cost of changing the namespace. Over time these projects will hopefully move to 2.5 and can use the regular jar again.
>     
>     Thoughts?
> 
> Benjamin Hindman wrote:
>     Ah, I see now. The two jar solution sounds good to me. The only other thing I can think of is providing some wrappers (e.g., ByteString_To_Mesos_Protobuf_2_5_0_ByteString) but since this issue seems like it will boil down to an individual project and whether or not they know they have this problem (or one of their users has this problem) they should be able to start with the un-shaded jar and move to the shaded jar on demand (and make the protobuf changes then). I've added Patrick Wendell to this review to see if there was anything they did in particular for Spark to deal with this case.
> 
> Benjamin Hindman wrote:
>     FYI, I updated Jenkins so hopefully the review bot will pick this up and test it for us.
> 
> Tobi Knaup wrote:
>     Thanks! A wrapper would work too, I'd argue though that a namespace change is less invasive and easier to revert later.

I agree, let's go with the two jars. Also, I think I'd prefer to keep the examples using the non-shaded protobuf for now since that's what we "prefer" people use/do. We could add a TestFrameworkShaded.java to test the shaded version but feel free to punt for a subsequent review (and/or add a TODO in the makefile where we build the examples suggesting as much).


- Benjamin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20402/#review40553
-----------------------------------------------------------


On April 16, 2014, 4:24 p.m., Tobi Knaup wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20402/
> -----------------------------------------------------------
> 
> (Updated April 16, 2014, 4:24 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Patrick Wendell.
> 
> 
> Bugs: MESOS-1212
>     https://issues.apache.org/jira/browse/MESOS-1212
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Use Maven to build the Mesos jars, and include shaded protbuf jar.
> No longer builds a custom protobuf jar but relies on Maven.
> 
> NOTE: #20329 (shading) is a breaking change for JVM frameworks which use the com.google.protobuf namespace. These need to change to org.apache.mesos.com.google.protobuf.
> 
> Includes the dependent patch from https://reviews.apache.org/r/20329/ which I'll delete once that's merged.
> 
> 
> Diffs
> -----
> 
>   configure.ac c1de6d7 
>   src/Makefile.am 560b4c7 
>   src/examples/java/TestExceptionFramework.java 464b3b0 
>   src/examples/java/TestFramework.java 65ee2dc 
>   src/examples/java/TestMultipleExecutorsFramework.java 6846959 
>   src/examples/java/test-exception-framework.in 26617e2 
>   src/examples/java/test-executor.in 8b27a37 
>   src/examples/java/test-framework.in bbdc1ed 
>   src/examples/java/test-log.in b7e69e4 
>   src/examples/java/test-multiple-executors-framework.in eb8edf6 
>   src/java/mesos.pom.in 8f9b747 
> 
> Diff: https://reviews.apache.org/r/20402/diff/
> 
> 
> Testing
> -------
> 
> make check
> make maven-install
> 
> 
> Thanks,
> 
> Tobi Knaup
> 
>


Re: Review Request 20402: Use maven to compile and package Mesos' Java files

Posted by Benjamin Hindman <be...@berkeley.edu>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20402/#review40553
-----------------------------------------------------------


This is awesome Tobi!

One question: Can we actually still use protobuf.jar with the example frameworks? My expectation is that existing frameworks should be able to continue to use their protobuf dependencies and we've just shaded all use of protobuf from them. That way we don't require frameworks/users to use org.apache.mesos.com.google.protobuf... but perhaps I'm missing something here? Assuming that works, we can drop all the changes to Java example code (which should make this diff even simpler) since that will stand as a reference for how we expect people to still use Mesos.

Also, it's great to see the configure check and apparently our build machines don't have maven!? I'll look into that for you ASAP.

- Benjamin Hindman


On April 16, 2014, 4:15 a.m., Tobi Knaup wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20402/
> -----------------------------------------------------------
> 
> (Updated April 16, 2014, 4:15 a.m.)
> 
> 
> Review request for mesos.
> 
> 
> Bugs: MESOS-1212
>     https://issues.apache.org/jira/browse/MESOS-1212
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Use Maven to build the Mesos jars, and include shaded protbuf jar.
> No longer builds a custom protobuf jar but relies on Maven.
> 
> NOTE: #20329 (shading) is a breaking change for JVM frameworks which use the com.google.protobuf namespace. These need to change to org.apache.mesos.com.google.protobuf.
> 
> Includes the dependent patch from https://reviews.apache.org/r/20329/ which I'll delete once that's merged.
> 
> 
> Diffs
> -----
> 
>   configure.ac c1de6d7 
>   src/Makefile.am 560b4c7 
>   src/examples/java/TestExceptionFramework.java 464b3b0 
>   src/examples/java/TestFramework.java 65ee2dc 
>   src/examples/java/TestMultipleExecutorsFramework.java 6846959 
>   src/examples/java/test-exception-framework.in 26617e2 
>   src/examples/java/test-executor.in 8b27a37 
>   src/examples/java/test-framework.in bbdc1ed 
>   src/examples/java/test-log.in b7e69e4 
>   src/examples/java/test-multiple-executors-framework.in eb8edf6 
>   src/java/mesos.pom.in 8f9b747 
> 
> Diff: https://reviews.apache.org/r/20402/diff/
> 
> 
> Testing
> -------
> 
> make check
> make maven-install
> 
> 
> Thanks,
> 
> Tobi Knaup
> 
>


Re: Review Request 20402: Use maven to compile and package Mesos' Java files

Posted by Tobi Knaup <to...@knaup.me>.

> On April 16, 2014, 5:22 a.m., John Sirois wrote:
> > src/Makefile.am, line 603
> > <https://reviews.apache.org/r/20402/diff/1/?file=560751#file560751line603>
> >
> >     should this `... clean package` to kill dead classfiles when protobuf messages go away?  LHS did this afaict with its `rm -rf ...`

Good catch, thanks!


- Tobi


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20402/#review40501
-----------------------------------------------------------


On April 16, 2014, 4:24 p.m., Tobi Knaup wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20402/
> -----------------------------------------------------------
> 
> (Updated April 16, 2014, 4:24 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Patrick Wendell.
> 
> 
> Bugs: MESOS-1212
>     https://issues.apache.org/jira/browse/MESOS-1212
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Use Maven to build the Mesos jars, and include shaded protbuf jar.
> No longer builds a custom protobuf jar but relies on Maven.
> 
> NOTE: #20329 (shading) is a breaking change for JVM frameworks which use the com.google.protobuf namespace. These need to change to org.apache.mesos.com.google.protobuf.
> 
> Includes the dependent patch from https://reviews.apache.org/r/20329/ which I'll delete once that's merged.
> 
> 
> Diffs
> -----
> 
>   configure.ac c1de6d7 
>   src/Makefile.am 560b4c7 
>   src/examples/java/TestExceptionFramework.java 464b3b0 
>   src/examples/java/TestFramework.java 65ee2dc 
>   src/examples/java/TestMultipleExecutorsFramework.java 6846959 
>   src/examples/java/test-exception-framework.in 26617e2 
>   src/examples/java/test-executor.in 8b27a37 
>   src/examples/java/test-framework.in bbdc1ed 
>   src/examples/java/test-log.in b7e69e4 
>   src/examples/java/test-multiple-executors-framework.in eb8edf6 
>   src/java/mesos.pom.in 8f9b747 
> 
> Diff: https://reviews.apache.org/r/20402/diff/
> 
> 
> Testing
> -------
> 
> make check
> make maven-install
> 
> 
> Thanks,
> 
> Tobi Knaup
> 
>


Re: Review Request 20402: Use maven to compile and package Mesos' Java files

Posted by John Sirois <jo...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20402/#review40501
-----------------------------------------------------------

Ship it!



src/Makefile.am
<https://reviews.apache.org/r/20402/#comment73536>

    should this `... clean package` to kill dead classfiles when protobuf messages go away?  LHS did this afaict with its `rm -rf ...`


- John Sirois


On April 15, 2014, 10:15 p.m., Tobi Knaup wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20402/
> -----------------------------------------------------------
> 
> (Updated April 15, 2014, 10:15 p.m.)
> 
> 
> Review request for mesos.
> 
> 
> Bugs: MESOS-1212
>     https://issues.apache.org/jira/browse/MESOS-1212
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Use Maven to build the Mesos jars, and include shaded protbuf jar.
> No longer builds a custom protobuf jar but relies on Maven.
> 
> NOTE: #20329 (shading) is a breaking change for JVM frameworks which use the com.google.protobuf namespace. These need to change to org.apache.mesos.com.google.protobuf.
> 
> Includes the dependent patch from https://reviews.apache.org/r/20329/ which I'll delete once that's merged.
> 
> 
> Diffs
> -----
> 
>   configure.ac c1de6d7 
>   src/Makefile.am 560b4c7 
>   src/examples/java/TestExceptionFramework.java 464b3b0 
>   src/examples/java/TestFramework.java 65ee2dc 
>   src/examples/java/TestMultipleExecutorsFramework.java 6846959 
>   src/examples/java/test-exception-framework.in 26617e2 
>   src/examples/java/test-executor.in 8b27a37 
>   src/examples/java/test-framework.in bbdc1ed 
>   src/examples/java/test-log.in b7e69e4 
>   src/examples/java/test-multiple-executors-framework.in eb8edf6 
>   src/java/mesos.pom.in 8f9b747 
> 
> Diff: https://reviews.apache.org/r/20402/diff/
> 
> 
> Testing
> -------
> 
> make check
> make maven-install
> 
> 
> Thanks,
> 
> Tobi Knaup
> 
>


Re: Review Request 20402: Use maven to compile and package Mesos' Java files

Posted by Benjamin Hindman <be...@berkeley.edu>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20402/#review40628
-----------------------------------------------------------

Ship it!


This looks great Tobi. Very minor nits from Vinod and I and then I'll get this committed ASAP.


configure.ac
<https://reviews.apache.org/r/20402/#comment73701>

    As Vinod mentioned below, we try and use proper punctuation in our comments, not a big deal, just a style aspect of our codebase.



src/Makefile.am
<https://reviews.apache.org/r/20402/#comment73700>

    Will running something like 'mvn clean' handle the first and last case of this target? Clearly we'll still need/want to delete the examples and generated headers ourselves. Not being a Maven guy it seems a bit weird not to have a call to 'mvn' to clean when we have a call to compile/package ... but maybe this is standard practice with Maven?


- Benjamin Hindman


On April 16, 2014, 11:56 p.m., Tobi Knaup wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20402/
> -----------------------------------------------------------
> 
> (Updated April 16, 2014, 11:56 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Patrick Wendell.
> 
> 
> Bugs: MESOS-1212
>     https://issues.apache.org/jira/browse/MESOS-1212
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Use Maven to build the Mesos jars, and include shaded protbuf jar.
> No longer builds a custom protobuf jar but relies on Maven.
> 
> NOTE: #20329 (shading) is a breaking change for JVM frameworks which use the com.google.protobuf namespace. These need to change to org.apache.mesos.com.google.protobuf.
> 
> Includes the dependent patch from https://reviews.apache.org/r/20329/ which I'll delete once that's merged.
> 
> 
> Diffs
> -----
> 
>   configure.ac c1de6d7 
>   src/Makefile.am 560b4c7 
>   src/examples/java/test-exception-framework.in 26617e2 
>   src/examples/java/test-executor.in 8b27a37 
>   src/examples/java/test-framework.in bbdc1ed 
>   src/examples/java/test-log.in b7e69e4 
>   src/examples/java/test-multiple-executors-framework.in eb8edf6 
>   src/java/mesos.pom.in 8f9b747 
> 
> Diff: https://reviews.apache.org/r/20402/diff/
> 
> 
> Testing
> -------
> 
> make check
> make maven-install
> 
> 
> Thanks,
> 
> Tobi Knaup
> 
>


Re: Review Request 20402: Use maven to compile and package Mesos' Java files

Posted by Benjamin Hindman <be...@berkeley.edu>.

> On April 17, 2014, 11:49 a.m., Mesos ReviewBot wrote:
> > Bad patch!
> > 
> > Reviews applied: [20402]
> > 
> > Failed command: make -j3 distcheck GTEST_FILTER='' >/dev/null
> > 
> > Error:
> >  configure: WARNING: can not find python-boto
> > -------------------------------------------------------------------
> > mesos-ec2 services will not function.
> > -------------------------------------------------------------------
> > ev.c:1531:31: warning: 'ev_default_loop_ptr' initialized and declared 'extern' [enabled by default]
> > ev.c: In function 'evpipe_write':
> > ev.c:2160:17: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result]
> > ev.c:2172:17: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result]
> > ev.c: In function 'pipecb':
> > ev.c:2193:16: warning: ignoring return value of 'read', declared with attribute warn_unused_result [-Wunused-result]
> > ev.c:2207:16: warning: ignoring return value of 'read', declared with attribute warn_unused_result [-Wunused-result]
> > In file included from /usr/include/c++/4.6/ext/hash_set:61:0,
> >                  from src/glog/stl_logging.h:54,
> >                  from src/stl_logging_unittest.cc:34:
> > /usr/include/c++/4.6/backward/backward_warning.h:33:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp]
> > In file included from src/utilities.h:73:0,
> >                  from src/googletest.h:38,
> >                  from src/stl_logging_unittest.cc:48:
> > src/base/mutex.h:137:0: warning: "_XOPEN_SOURCE" redefined [enabled by default]
> > /usr/include/features.h:166:0: note: this is the location of the previous definition
> > warning: no files found matching 'Makefile' under directory 'docs'
> > warning: no files found matching 'indexsidebar.html' under directory 'docs'
> > ar: creating libleveldb.a
> > make[2]: *** [java/target/mesos-0.19.0.jar] Error 1
> > make[1]: *** [all-recursive] Error 1
> > make: *** [distcheck] Error 1
> >

Good news, it got past the configure check. Bad news, the review bot is still broken. :(


- Benjamin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20402/#review40640
-----------------------------------------------------------


On April 16, 2014, 11:56 p.m., Tobi Knaup wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20402/
> -----------------------------------------------------------
> 
> (Updated April 16, 2014, 11:56 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Patrick Wendell.
> 
> 
> Bugs: MESOS-1212
>     https://issues.apache.org/jira/browse/MESOS-1212
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Use Maven to build the Mesos jars, and include shaded protbuf jar.
> No longer builds a custom protobuf jar but relies on Maven.
> 
> NOTE: #20329 (shading) is a breaking change for JVM frameworks which use the com.google.protobuf namespace. These need to change to org.apache.mesos.com.google.protobuf.
> 
> Includes the dependent patch from https://reviews.apache.org/r/20329/ which I'll delete once that's merged.
> 
> 
> Diffs
> -----
> 
>   configure.ac c1de6d7 
>   src/Makefile.am 560b4c7 
>   src/examples/java/test-exception-framework.in 26617e2 
>   src/examples/java/test-executor.in 8b27a37 
>   src/examples/java/test-framework.in bbdc1ed 
>   src/examples/java/test-log.in b7e69e4 
>   src/examples/java/test-multiple-executors-framework.in eb8edf6 
>   src/java/mesos.pom.in 8f9b747 
> 
> Diff: https://reviews.apache.org/r/20402/diff/
> 
> 
> Testing
> -------
> 
> make check
> make maven-install
> 
> 
> Thanks,
> 
> Tobi Knaup
> 
>


Re: Review Request 20402: Use maven to compile and package Mesos' Java files

Posted by Mesos ReviewBot <de...@mesos.apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20402/#review40640
-----------------------------------------------------------


Bad patch!

Reviews applied: [20402]

Failed command: make -j3 distcheck GTEST_FILTER='' >/dev/null

Error:
 configure: WARNING: can not find python-boto
-------------------------------------------------------------------
mesos-ec2 services will not function.
-------------------------------------------------------------------
ev.c:1531:31: warning: 'ev_default_loop_ptr' initialized and declared 'extern' [enabled by default]
ev.c: In function 'evpipe_write':
ev.c:2160:17: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result]
ev.c:2172:17: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result]
ev.c: In function 'pipecb':
ev.c:2193:16: warning: ignoring return value of 'read', declared with attribute warn_unused_result [-Wunused-result]
ev.c:2207:16: warning: ignoring return value of 'read', declared with attribute warn_unused_result [-Wunused-result]
In file included from /usr/include/c++/4.6/ext/hash_set:61:0,
                 from src/glog/stl_logging.h:54,
                 from src/stl_logging_unittest.cc:34:
/usr/include/c++/4.6/backward/backward_warning.h:33:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp]
In file included from src/utilities.h:73:0,
                 from src/googletest.h:38,
                 from src/stl_logging_unittest.cc:48:
src/base/mutex.h:137:0: warning: "_XOPEN_SOURCE" redefined [enabled by default]
/usr/include/features.h:166:0: note: this is the location of the previous definition
warning: no files found matching 'Makefile' under directory 'docs'
warning: no files found matching 'indexsidebar.html' under directory 'docs'
ar: creating libleveldb.a
make[2]: *** [java/target/mesos-0.19.0.jar] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [distcheck] Error 1


- Mesos ReviewBot


On April 16, 2014, 11:56 p.m., Tobi Knaup wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20402/
> -----------------------------------------------------------
> 
> (Updated April 16, 2014, 11:56 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Patrick Wendell.
> 
> 
> Bugs: MESOS-1212
>     https://issues.apache.org/jira/browse/MESOS-1212
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Use Maven to build the Mesos jars, and include shaded protbuf jar.
> No longer builds a custom protobuf jar but relies on Maven.
> 
> NOTE: #20329 (shading) is a breaking change for JVM frameworks which use the com.google.protobuf namespace. These need to change to org.apache.mesos.com.google.protobuf.
> 
> Includes the dependent patch from https://reviews.apache.org/r/20329/ which I'll delete once that's merged.
> 
> 
> Diffs
> -----
> 
>   configure.ac c1de6d7 
>   src/Makefile.am 560b4c7 
>   src/examples/java/test-exception-framework.in 26617e2 
>   src/examples/java/test-executor.in 8b27a37 
>   src/examples/java/test-framework.in bbdc1ed 
>   src/examples/java/test-log.in b7e69e4 
>   src/examples/java/test-multiple-executors-framework.in eb8edf6 
>   src/java/mesos.pom.in 8f9b747 
> 
> Diff: https://reviews.apache.org/r/20402/diff/
> 
> 
> Testing
> -------
> 
> make check
> make maven-install
> 
> 
> Thanks,
> 
> Tobi Knaup
> 
>


Re: Review Request 20402: Use maven to compile and package Mesos' Java files

Posted by Benjamin Hindman <be...@berkeley.edu>.

> On April 17, 2014, 1:02 a.m., Vinod Kone wrote:
> > src/Makefile.am, line 570
> > <https://reviews.apache.org/r/20402/diff/2/?file=561414#file561414line570>
> >
> >     End with period.
> >     
> >     Also, can you pull this down close to where it is used?

I think just putting it directly where it was defined before should be sufficient. Was there some reason that didn't work Tobi?


> On April 17, 2014, 1:02 a.m., Vinod Kone wrote:
> > src/Makefile.am, line 733
> > <https://reviews.apache.org/r/20402/diff/2/?file=561414#file561414line733>
> >
> >     So this installs both the shaded and non-shaded versions with different names?
> >     
> >     What gets published when we do "mvn deploy -f src/java/mesos.pom" (e.g: support/tag.sh and support/vote.sh).
> >     
> >     Also, would you mind updating src/java/MESOS-MAVEN-README?

What explicitly needs to get updated Vinod? I wouldn't know what you'd want me to update so I figured we should be a bit more explicit for poor Tobi. ;)


- Benjamin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20402/#review40620
-----------------------------------------------------------


On April 16, 2014, 11:56 p.m., Tobi Knaup wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20402/
> -----------------------------------------------------------
> 
> (Updated April 16, 2014, 11:56 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Patrick Wendell.
> 
> 
> Bugs: MESOS-1212
>     https://issues.apache.org/jira/browse/MESOS-1212
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Use Maven to build the Mesos jars, and include shaded protbuf jar.
> No longer builds a custom protobuf jar but relies on Maven.
> 
> NOTE: #20329 (shading) is a breaking change for JVM frameworks which use the com.google.protobuf namespace. These need to change to org.apache.mesos.com.google.protobuf.
> 
> Includes the dependent patch from https://reviews.apache.org/r/20329/ which I'll delete once that's merged.
> 
> 
> Diffs
> -----
> 
>   configure.ac c1de6d7 
>   src/Makefile.am 560b4c7 
>   src/examples/java/test-exception-framework.in 26617e2 
>   src/examples/java/test-executor.in 8b27a37 
>   src/examples/java/test-framework.in bbdc1ed 
>   src/examples/java/test-log.in b7e69e4 
>   src/examples/java/test-multiple-executors-framework.in eb8edf6 
>   src/java/mesos.pom.in 8f9b747 
> 
> Diff: https://reviews.apache.org/r/20402/diff/
> 
> 
> Testing
> -------
> 
> make check
> make maven-install
> 
> 
> Thanks,
> 
> Tobi Knaup
> 
>


Re: Review Request 20402: Use maven to compile and package Mesos' Java files

Posted by Tobi Knaup <to...@knaup.me>.

> On April 17, 2014, 1:02 a.m., Vinod Kone wrote:
> > src/Makefile.am, line 570
> > <https://reviews.apache.org/r/20402/diff/2/?file=561414#file561414line570>
> >
> >     End with period.
> >     
> >     Also, can you pull this down close to where it is used?
> 
> Benjamin Hindman wrote:
>     I think just putting it directly where it was defined before should be sufficient. Was there some reason that didn't work Tobi?

No reason, put it where it was before.


> On April 17, 2014, 1:02 a.m., Vinod Kone wrote:
> > src/Makefile.am, line 733
> > <https://reviews.apache.org/r/20402/diff/2/?file=561414#file561414line733>
> >
> >     So this installs both the shaded and non-shaded versions with different names?
> >     
> >     What gets published when we do "mvn deploy -f src/java/mesos.pom" (e.g: support/tag.sh and support/vote.sh).
> >     
> >     Also, would you mind updating src/java/MESOS-MAVEN-README?
> 
> Benjamin Hindman wrote:
>     What explicitly needs to get updated Vinod? I wouldn't know what you'd want me to update so I figured we should be a bit more explicit for poor Tobi. ;)
> 
> Vinod Kone wrote:
>     Fair enough :)
>     
>     Mainly the "NOTE:" section seems out of date. We need to mention about producing 2 jars now. Also 'make src/mesos-0.9.0.jar' doesn't seem correct (though that is nothing to do with this review).
>     
>     Also, instructions 4) and 5) need to be updated with the 2 jar world.

Fixed that. 4 and 5 are still the same since maven treats the shaded jar as an additional artifact and automatically includes it when you run install or deploy.


- Tobi


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20402/#review40620
-----------------------------------------------------------


On April 25, 2014, 8:24 p.m., Tobi Knaup wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20402/
> -----------------------------------------------------------
> 
> (Updated April 25, 2014, 8:24 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Patrick Wendell.
> 
> 
> Bugs: MESOS-1212
>     https://issues.apache.org/jira/browse/MESOS-1212
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Use Maven to build the Mesos jars, and include shaded protbuf jar.
> No longer builds a custom protobuf jar but relies on Maven.
> 
> NOTE: #20329 (shading) is a breaking change for JVM frameworks which use the com.google.protobuf namespace. These need to change to org.apache.mesos.com.google.protobuf.
> 
> Includes the dependent patch from https://reviews.apache.org/r/20329/ which I'll delete once that's merged.
> 
> 
> Diffs
> -----
> 
>   configure.ac c1de6d7 
>   src/Makefile.am 560b4c7 
>   src/examples/java/test-exception-framework.in 26617e2 
>   src/examples/java/test-executor.in 8b27a37 
>   src/examples/java/test-framework.in bbdc1ed 
>   src/examples/java/test-log.in b7e69e4 
>   src/examples/java/test-multiple-executors-framework.in eb8edf6 
>   src/java/MESOS-MAVEN-README 2da6646 
>   src/java/mesos.pom.in 8f9b747 
> 
> Diff: https://reviews.apache.org/r/20402/diff/
> 
> 
> Testing
> -------
> 
> make check
> make maven-install
> 
> 
> Thanks,
> 
> Tobi Knaup
> 
>


Re: Review Request 20402: Use maven to compile and package Mesos' Java files

Posted by Vinod Kone <vi...@gmail.com>.

> On April 17, 2014, 1:02 a.m., Vinod Kone wrote:
> > src/Makefile.am, line 733
> > <https://reviews.apache.org/r/20402/diff/2/?file=561414#file561414line733>
> >
> >     So this installs both the shaded and non-shaded versions with different names?
> >     
> >     What gets published when we do "mvn deploy -f src/java/mesos.pom" (e.g: support/tag.sh and support/vote.sh).
> >     
> >     Also, would you mind updating src/java/MESOS-MAVEN-README?
> 
> Benjamin Hindman wrote:
>     What explicitly needs to get updated Vinod? I wouldn't know what you'd want me to update so I figured we should be a bit more explicit for poor Tobi. ;)

Fair enough :)

Mainly the "NOTE:" section seems out of date. We need to mention about producing 2 jars now. Also 'make src/mesos-0.9.0.jar' doesn't seem correct (though that is nothing to do with this review).

Also, instructions 4) and 5) need to be updated with the 2 jar world.


- Vinod


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20402/#review40620
-----------------------------------------------------------


On April 16, 2014, 11:56 p.m., Tobi Knaup wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20402/
> -----------------------------------------------------------
> 
> (Updated April 16, 2014, 11:56 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Patrick Wendell.
> 
> 
> Bugs: MESOS-1212
>     https://issues.apache.org/jira/browse/MESOS-1212
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Use Maven to build the Mesos jars, and include shaded protbuf jar.
> No longer builds a custom protobuf jar but relies on Maven.
> 
> NOTE: #20329 (shading) is a breaking change for JVM frameworks which use the com.google.protobuf namespace. These need to change to org.apache.mesos.com.google.protobuf.
> 
> Includes the dependent patch from https://reviews.apache.org/r/20329/ which I'll delete once that's merged.
> 
> 
> Diffs
> -----
> 
>   configure.ac c1de6d7 
>   src/Makefile.am 560b4c7 
>   src/examples/java/test-exception-framework.in 26617e2 
>   src/examples/java/test-executor.in 8b27a37 
>   src/examples/java/test-framework.in bbdc1ed 
>   src/examples/java/test-log.in b7e69e4 
>   src/examples/java/test-multiple-executors-framework.in eb8edf6 
>   src/java/mesos.pom.in 8f9b747 
> 
> Diff: https://reviews.apache.org/r/20402/diff/
> 
> 
> Testing
> -------
> 
> make check
> make maven-install
> 
> 
> Thanks,
> 
> Tobi Knaup
> 
>


Re: Review Request 20402: Use maven to compile and package Mesos' Java files

Posted by Vinod Kone <vi...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20402/#review40620
-----------------------------------------------------------



src/Makefile.am
<https://reviews.apache.org/r/20402/#comment73684>

    End with period.
    
    Also, can you pull this down close to where it is used?



src/Makefile.am
<https://reviews.apache.org/r/20402/#comment73686>

    So this installs both the shaded and non-shaded versions with different names?
    
    What gets published when we do "mvn deploy -f src/java/mesos.pom" (e.g: support/tag.sh and support/vote.sh).
    
    Also, would you mind updating src/java/MESOS-MAVEN-README?


- Vinod Kone


On April 16, 2014, 11:56 p.m., Tobi Knaup wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20402/
> -----------------------------------------------------------
> 
> (Updated April 16, 2014, 11:56 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Patrick Wendell.
> 
> 
> Bugs: MESOS-1212
>     https://issues.apache.org/jira/browse/MESOS-1212
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Use Maven to build the Mesos jars, and include shaded protbuf jar.
> No longer builds a custom protobuf jar but relies on Maven.
> 
> NOTE: #20329 (shading) is a breaking change for JVM frameworks which use the com.google.protobuf namespace. These need to change to org.apache.mesos.com.google.protobuf.
> 
> Includes the dependent patch from https://reviews.apache.org/r/20329/ which I'll delete once that's merged.
> 
> 
> Diffs
> -----
> 
>   configure.ac c1de6d7 
>   src/Makefile.am 560b4c7 
>   src/examples/java/test-exception-framework.in 26617e2 
>   src/examples/java/test-executor.in 8b27a37 
>   src/examples/java/test-framework.in bbdc1ed 
>   src/examples/java/test-log.in b7e69e4 
>   src/examples/java/test-multiple-executors-framework.in eb8edf6 
>   src/java/mesos.pom.in 8f9b747 
> 
> Diff: https://reviews.apache.org/r/20402/diff/
> 
> 
> Testing
> -------
> 
> make check
> make maven-install
> 
> 
> Thanks,
> 
> Tobi Knaup
> 
>


Re: Review Request 20402: Use maven to compile and package Mesos' Java files

Posted by Tobi Knaup <to...@knaup.me>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20402/
-----------------------------------------------------------

(Updated April 25, 2014, 8:24 p.m.)


Review request for mesos, Benjamin Hindman and Patrick Wendell.


Changes
-------

Implemented everybody's feedback.


Bugs: MESOS-1212
    https://issues.apache.org/jira/browse/MESOS-1212


Repository: mesos-git


Description
-------

Use Maven to build the Mesos jars, and include shaded protbuf jar.
No longer builds a custom protobuf jar but relies on Maven.

NOTE: #20329 (shading) is a breaking change for JVM frameworks which use the com.google.protobuf namespace. These need to change to org.apache.mesos.com.google.protobuf.

Includes the dependent patch from https://reviews.apache.org/r/20329/ which I'll delete once that's merged.


Diffs (updated)
-----

  configure.ac c1de6d7 
  src/Makefile.am 560b4c7 
  src/examples/java/test-exception-framework.in 26617e2 
  src/examples/java/test-executor.in 8b27a37 
  src/examples/java/test-framework.in bbdc1ed 
  src/examples/java/test-log.in b7e69e4 
  src/examples/java/test-multiple-executors-framework.in eb8edf6 
  src/java/MESOS-MAVEN-README 2da6646 
  src/java/mesos.pom.in 8f9b747 

Diff: https://reviews.apache.org/r/20402/diff/


Testing
-------

make check
make maven-install


Thanks,

Tobi Knaup


Re: Review Request 20402: Use maven to compile and package Mesos' Java files

Posted by Tobi Knaup <to...@knaup.me>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20402/
-----------------------------------------------------------

(Updated April 16, 2014, 11:56 p.m.)


Review request for mesos, Benjamin Hindman and Patrick Wendell.


Changes
-------

* creates additional shaded mesos-with-protobuf-VERSION.jar, leaving the original jar intact
* mvn -f mesos.pom clean package, thanks John
* Let Maven fetch the protobuf jar and use it in the Java tests instead of the shaded jar


Bugs: MESOS-1212
    https://issues.apache.org/jira/browse/MESOS-1212


Repository: mesos-git


Description
-------

Use Maven to build the Mesos jars, and include shaded protbuf jar.
No longer builds a custom protobuf jar but relies on Maven.

NOTE: #20329 (shading) is a breaking change for JVM frameworks which use the com.google.protobuf namespace. These need to change to org.apache.mesos.com.google.protobuf.

Includes the dependent patch from https://reviews.apache.org/r/20329/ which I'll delete once that's merged.


Diffs (updated)
-----

  configure.ac c1de6d7 
  src/Makefile.am 560b4c7 
  src/examples/java/test-exception-framework.in 26617e2 
  src/examples/java/test-executor.in 8b27a37 
  src/examples/java/test-framework.in bbdc1ed 
  src/examples/java/test-log.in b7e69e4 
  src/examples/java/test-multiple-executors-framework.in eb8edf6 
  src/java/mesos.pom.in 8f9b747 

Diff: https://reviews.apache.org/r/20402/diff/


Testing
-------

make check
make maven-install


Thanks,

Tobi Knaup


Re: Review Request 20402: Use maven to compile and package Mesos' Java files

Posted by Mesos ReviewBot <de...@mesos.apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20402/#review40570
-----------------------------------------------------------


Bad patch!

Reviews applied: [20329, 20402]

Failed command: ./configure

Error:
 checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking how to print strings... printf
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
configure: creating ./config.lt
config.lt: creating libtool
configure: Setting up build environment for x86_64 linux-gnu
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking dependency style of g++... (cached) gcc3
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking dependency style of gcc... (cached) gcc3
checking if compiling with clang... no
configure: GCC version: 4.6
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking whether to check for GCC pthread/shared inconsistencies... yes
checking whether -pthread is sufficient with -shared... yes
checking for backtrace in -lunwind... no
checking whether or not we can build with JNI... yes
checking whether we have Maven... checking for mvn... no
configure: error: Unable to find mvn on your path.


- Mesos ReviewBot


On April 16, 2014, 4:24 p.m., Tobi Knaup wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20402/
> -----------------------------------------------------------
> 
> (Updated April 16, 2014, 4:24 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Patrick Wendell.
> 
> 
> Bugs: MESOS-1212
>     https://issues.apache.org/jira/browse/MESOS-1212
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Use Maven to build the Mesos jars, and include shaded protbuf jar.
> No longer builds a custom protobuf jar but relies on Maven.
> 
> NOTE: #20329 (shading) is a breaking change for JVM frameworks which use the com.google.protobuf namespace. These need to change to org.apache.mesos.com.google.protobuf.
> 
> Includes the dependent patch from https://reviews.apache.org/r/20329/ which I'll delete once that's merged.
> 
> 
> Diffs
> -----
> 
>   configure.ac c1de6d7 
>   src/Makefile.am 560b4c7 
>   src/examples/java/TestExceptionFramework.java 464b3b0 
>   src/examples/java/TestFramework.java 65ee2dc 
>   src/examples/java/TestMultipleExecutorsFramework.java 6846959 
>   src/examples/java/test-exception-framework.in 26617e2 
>   src/examples/java/test-executor.in 8b27a37 
>   src/examples/java/test-framework.in bbdc1ed 
>   src/examples/java/test-log.in b7e69e4 
>   src/examples/java/test-multiple-executors-framework.in eb8edf6 
>   src/java/mesos.pom.in 8f9b747 
> 
> Diff: https://reviews.apache.org/r/20402/diff/
> 
> 
> Testing
> -------
> 
> make check
> make maven-install
> 
> 
> Thanks,
> 
> Tobi Knaup
> 
>


Re: Review Request 20402: Use maven to compile and package Mesos' Java files

Posted by Tobi Knaup <to...@knaup.me>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20402/
-----------------------------------------------------------

(Updated April 16, 2014, 4:24 p.m.)


Review request for mesos, Benjamin Hindman and Patrick Wendell.


Changes
-------

Re-added the dependency review. :/


Bugs: MESOS-1212
    https://issues.apache.org/jira/browse/MESOS-1212


Repository: mesos-git


Description
-------

Use Maven to build the Mesos jars, and include shaded protbuf jar.
No longer builds a custom protobuf jar but relies on Maven.

NOTE: #20329 (shading) is a breaking change for JVM frameworks which use the com.google.protobuf namespace. These need to change to org.apache.mesos.com.google.protobuf.

Includes the dependent patch from https://reviews.apache.org/r/20329/ which I'll delete once that's merged.


Diffs
-----

  configure.ac c1de6d7 
  src/Makefile.am 560b4c7 
  src/examples/java/TestExceptionFramework.java 464b3b0 
  src/examples/java/TestFramework.java 65ee2dc 
  src/examples/java/TestMultipleExecutorsFramework.java 6846959 
  src/examples/java/test-exception-framework.in 26617e2 
  src/examples/java/test-executor.in 8b27a37 
  src/examples/java/test-framework.in bbdc1ed 
  src/examples/java/test-log.in b7e69e4 
  src/examples/java/test-multiple-executors-framework.in eb8edf6 
  src/java/mesos.pom.in 8f9b747 

Diff: https://reviews.apache.org/r/20402/diff/


Testing
-------

make check
make maven-install


Thanks,

Tobi Knaup


Re: Review Request 20402: Use maven to compile and package Mesos' Java files

Posted by Tobi Knaup <to...@knaup.me>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20402/
-----------------------------------------------------------

(Updated April 16, 2014, 4:23 p.m.)


Review request for mesos, Benjamin Hindman and Patrick Wendell.


Changes
-------

Added Patrick Wendell and myself to the review. - @benh


Bugs: MESOS-1212
    https://issues.apache.org/jira/browse/MESOS-1212


Repository: mesos-git


Description
-------

Use Maven to build the Mesos jars, and include shaded protbuf jar.
No longer builds a custom protobuf jar but relies on Maven.

NOTE: #20329 (shading) is a breaking change for JVM frameworks which use the com.google.protobuf namespace. These need to change to org.apache.mesos.com.google.protobuf.

Includes the dependent patch from https://reviews.apache.org/r/20329/ which I'll delete once that's merged.


Diffs
-----

  configure.ac c1de6d7 
  src/Makefile.am 560b4c7 
  src/examples/java/TestExceptionFramework.java 464b3b0 
  src/examples/java/TestFramework.java 65ee2dc 
  src/examples/java/TestMultipleExecutorsFramework.java 6846959 
  src/examples/java/test-exception-framework.in 26617e2 
  src/examples/java/test-executor.in 8b27a37 
  src/examples/java/test-framework.in bbdc1ed 
  src/examples/java/test-log.in b7e69e4 
  src/examples/java/test-multiple-executors-framework.in eb8edf6 
  src/java/mesos.pom.in 8f9b747 

Diff: https://reviews.apache.org/r/20402/diff/


Testing
-------

make check
make maven-install


Thanks,

Tobi Knaup


Re: Review Request 20402: Use maven to compile and package Mesos' Java files

Posted by Mesos ReviewBot <de...@mesos.apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20402/#review40524
-----------------------------------------------------------


Bad patch!

Reviews applied: [20329, 20402]

Failed command: ./configure

Error:
 checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking how to print strings... printf
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
configure: creating ./config.lt
config.lt: creating libtool
configure: Setting up build environment for x86_64 linux-gnu
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking dependency style of g++... (cached) gcc3
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking dependency style of gcc... (cached) gcc3
checking if compiling with clang... no
configure: GCC version: 4.6
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking whether to check for GCC pthread/shared inconsistencies... yes
checking whether -pthread is sufficient with -shared... yes
checking for backtrace in -lunwind... no
checking whether or not we can build with JNI... yes
checking whether we have Maven... checking for mvn... no
configure: error: Unable to find mvn on your path.


- Mesos ReviewBot


On April 16, 2014, 4:15 a.m., Tobi Knaup wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20402/
> -----------------------------------------------------------
> 
> (Updated April 16, 2014, 4:15 a.m.)
> 
> 
> Review request for mesos.
> 
> 
> Bugs: MESOS-1212
>     https://issues.apache.org/jira/browse/MESOS-1212
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Use Maven to build the Mesos jars, and include shaded protbuf jar.
> No longer builds a custom protobuf jar but relies on Maven.
> 
> NOTE: #20329 (shading) is a breaking change for JVM frameworks which use the com.google.protobuf namespace. These need to change to org.apache.mesos.com.google.protobuf.
> 
> Includes the dependent patch from https://reviews.apache.org/r/20329/ which I'll delete once that's merged.
> 
> 
> Diffs
> -----
> 
>   configure.ac c1de6d7 
>   src/Makefile.am 560b4c7 
>   src/examples/java/TestExceptionFramework.java 464b3b0 
>   src/examples/java/TestFramework.java 65ee2dc 
>   src/examples/java/TestMultipleExecutorsFramework.java 6846959 
>   src/examples/java/test-exception-framework.in 26617e2 
>   src/examples/java/test-executor.in 8b27a37 
>   src/examples/java/test-framework.in bbdc1ed 
>   src/examples/java/test-log.in b7e69e4 
>   src/examples/java/test-multiple-executors-framework.in eb8edf6 
>   src/java/mesos.pom.in 8f9b747 
> 
> Diff: https://reviews.apache.org/r/20402/diff/
> 
> 
> Testing
> -------
> 
> make check
> make maven-install
> 
> 
> Thanks,
> 
> Tobi Knaup
> 
>