[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [parent] change in commons.scmPubUrl in Parent 47

On 2018-08-22, Rob Tompkins wrote:

>> On Aug 22, 2018, at 9:03 AM, Stefan Bodewig <bodewig@xxxxxxxxxx> wrote:

>> On 2018-08-22, Rob Tompkins wrote:

>>>> On Aug 22, 2018, at 1:47 AM, Benedikt Ritter <britter@xxxxxxxxxx> wrote:

>>>> Hi,

>>>> I don't understand this discussion. Changes in Commons Parent have broken
>>>> the commons-compress build. So we should either roll this changes back or
>>>> those who need the changes in commons parent should fix the commons
>>>> compress build.

>>> I think the problem at hand here is that we, across our projects, are
>>> inconsistent with our usage of componentId, so naturally any changes
>>> to the way we consume it in the parent are breaking changes. For
>>> example:

>>> https://github.com/apache/commons-lang/blob/master/pom.xml#L573 <https://github.com/apache/commons-lang/blob/master/pom.xml#L573>
>>> versus
>>> https://github.com/apache/commons-collections/blob/master/pom.xml#L487 <https://github.com/apache/commons-collections/blob/master/pom.xml#L487>

>> Anyway

>> https://github.com/apache/commons-parent/blob/trunk/pom.xml#L1942

>> is wrong for both of them as all subdirectories of
>> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/
>> start with "commons-" and no ${commons.componentid} does so. That's why
>> I don't understand how site-deploy can work for commons-lang or
>> commons-collections. I've simply overwritten the commons.scmPubUrl in
>> Compress' POM to make it work again.

> I think that’s the standard practice at this point.

> https://github.com/apache/commons-collections/blob/master/pom.xml#L519 <https://github.com/apache/commons-collections/blob/master/pom.xml#L519>

> https://github.com/apache/commons-lang/blob/master/pom.xml#L587

In that case I may come back to my original question of why
commons.scmPubUrl - which worked for many in parent 46 - has been
changed to a value in 47 that (almost?) all components need to overwrite

This has been water under the bridge for me and I wouldn't have brought
it up again, but if I now see others need to adjust as well, I may
better ask once again.


To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx