Bad IDEs automatically generate the wrong import. I think we need to
automatically prevent this, otherwise the bad imports will inevitably slip
back in.

Reuven

On Tue, Jan 15, 2019 at 2:54 AM Łukasz Gajowy <[email protected]>
wrote:

> Great news. Thanks all for this work!
>
> +1 to enforcing this on dependency level as Kenn suggested.
>
> Łukasz
>
> wt., 15 sty 2019 o 01:18 Kenneth Knowles <[email protected]> napisał(a):
>
>> We can enforce at the dependency level, since it is a compile error. I
>> think some IDEs and build tools may allow the compile-time classpath to get
>> polluted by transitive runtime deps, so protecting against bad imports is
>> also a good idea.
>>
>> Kenn
>>
>> On Mon, Jan 14, 2019 at 8:42 AM Ismaël Mejía <[email protected]> wrote:
>>
>>> Not yet, we need to add that too, there are still some tasks to be
>>> done like improve the contribution guide with this info, and document
>>> how to  generate a src build artifact locally since I doubt we can
>>> publish that into Apache for copyright reasons.
>>> I will message in the future for awareness for awareness when most of
>>> the pending tasks are finished.
>>>
>>>
>>> On Mon, Jan 14, 2019 at 3:51 PM Maximilian Michels <[email protected]>
>>> wrote:
>>> >
>>> > Thanks for the heads up, Ismaël! Great to see the vendored Guava
>>> version is used
>>> > everywhere now.
>>> >
>>> > Do we already have a Checkstyle rule that prevents people from using
>>> the
>>> > unvendored Guava? If not, such a rule could be useful because it's
>>> almost
>>> > inevitable that the unvedored Guava will slip back in.
>>> >
>>> > Cheers,
>>> > Max
>>> >
>>> > On 14.01.19 05:55, Ismaël Mejía wrote:
>>> > > We merged today the PR [1] that changes most of the code to use our
>>> > > new guava vendored dependency. In practice it means that most of the
>>> > > imports of the classes were changed from `com.google.common.` to
>>> > > `org.apache.beam.vendor.guava.v20_0.com.google.common.`
>>> > >
>>> > > This is a great improvement to fix a long existing problem of guava
>>> > > leaking through some Beam modules. This also reduces the size of most
>>> > > jars in the project because they don't need to relocate and include
>>> > > guava anymore, they just use the vendored dependency.
>>> > >
>>> > > Kudos to Kenn Knowles, Lukasz Cwik, Scott Wegner and the others that
>>> > > worked (are working) to make this possible.
>>> > >
>>> > > Sadly as a side effect of the merge of this PR multiple PRs were
>>> > > broken so please review if yours was and do a rebase and fix the
>>> > > imports to use the new vendored dependency. Sorry for the
>>> > > inconvenience. From now one all uses of guava should use the vendored
>>> > > version. Expect some updates in the docs.
>>> > >
>>> > > [1]  https://github.com/apache/beam/pull/6809
>>> > >
>>>
>>

Reply via email to