>So, what's the point of adding maven coordinates for external binaries? Is
this some requirement of the code donation? Or is this an effort to try to
achieve some kind of "repeteable build" mechanism? (I've arrived late to
the party, so I surely missed the thread where this was discussed).

It's part of the Apache IP clearance. We need to know our dependencies. A
binary JAR won't do, specifically because we patch stuff too. We can't just
go through classes and add small license headers when we imports lots and
lots of binaries as external dependencies. Knowing the exact (legal) status
of our dependencies is even more important than going through the codebase
imho.

>I'd prefer upgrading to modern versions than seeking old ones.

This involve potential breaking changes, code refactoring and potential
bugs. Why risk all that?

Let's just make an inventory of everything (ie. IP clearance) and build
with the JARs we have tested before!


--emi

On Sun, Oct 15, 2017 at 4:01 PM, Antonio <[email protected]> wrote:

>
>
> On 15/10/17 13:30, Emilian Bold wrote:
>
>>   Should I downgrade binaries to previous versions and leave this for a
>>
>>> future enhancement?
>>>
>>
>>
>> No, don't downgrade binaries. We are not beholden to Maven Central.
>>
>>
> I've already have downgraded to previous versions, as Yarda suggested.
>
> So, what's the point of adding maven coordinates for external binaries? Is
> this some requirement of the code donation? Or is this an effort to try to
> achieve some kind of "repeteable build" mechanism? (I've arrived late to
> the party, so I surely missed the thread where this was discussed).
>
> If it's not related to the code donation then I think I'd prefer finishing
> the code donation first and reviewing the modules and upgrading them to the
> most modern versions later on. We're currently seeking versions of
> 2009/2010 in some cases, and things have changed since. I'd prefer
> upgrading to modern versions than seeking old ones.
>
> Cheers,
> Antonio
>

Reply via email to