git.net

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

Re: [All] CP definitions



> On Sep 21, 2018, at 11:26 AM, Gary Gregory <garydgregory@xxxxxxxxx> wrote:
> 
> On Fri, Sep 21, 2018 at 7:05 AM Gilles <gilles@xxxxxxxxxxxxxxxxxxxxx <mailto:gilles@xxxxxxxxxxxxxxxxxxxxx>> wrote:
> 
>> On Fri, 21 Sep 2018 08:52:37 -0400, Rob Tompkins wrote:
>>>> On Sep 20, 2018, at 9:31 AM, Gilles <gilles@xxxxxxxxxxxxxxxxxxxxx>
>>>> wrote:
>>>> 
>>>> On Thu, 20 Sep 2018 08:53:38 -0400, Rob Tompkins wrote:
>>>>>> On Sep 20, 2018, at 3:10 AM, Benedikt Ritter <britter@xxxxxxxxxx>
>>>>>> wrote:
>>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> Reverting this change was discussed here [1]. It was a result of
>>>>>> this
>>>>>> commit [2] breaking multiple component builds. As Stefan points
>>>>>> out the
>>>>>> initial change does not make sense, since the componentId is
>>>>>> always just
>>>>>> the name without "commons-" (e.g. math4). But the folders for all
>>>>>> the
>>>>>> websites have the commons prefix (e.g. commons-math).
>>>>>> 
>>>>>> I just restored the old (working) behavior. I'm fine with making
>>>>>> things
>>>>>> easier/more straight forward. But let's make sure that all the
>>>>>> other
>>>>>> components still work.
>>>>> 
>>>>> I’m relatively indifferent to how we accomplish this. For the sake
>>>>> of
>>>>> discussion let our project.artifactId=commons-something where N
>>>>> represents the major version of the release with N being the empty
>>>>> string for a major version equal to 1. We still are stuck with half
>>>>> of
>>>>> our projects in one state for building with componentid=something
>>>>> and
>>>>> the other half with componentid=somethingN. Furthermore we need a
>>>>> properties representing both “something” as well as “somethingN”
>>>>> given
>>>>> that we have our dist urls and site urls not containing the major
>>>>> release version.
>>>>> 
>>>>> Do you propose something other than:
>>>>> 
>>>>> <commons.componentid>something</commons.componentid>
>>>>> <commons.packageId>somethingN</commons.pachageId>
>>>>> 
>>>>> and change [parent] back to
>>>>> 
>>>>> <commons.scmPubUrl>
>>>>> 
>>>>> 
>>>>> 
>> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${commons.componentid}
>>>>> </commons.scmPubUrl>
>>>>> ????
>>>> 
>>>> What about starting from maven requirements and try and avoid
>>>> redundancies (that ultimately lead to inconsistencies)?
>>>> 
>>>> Given are
>>>> <artefactId>
>>>> <version>
>>> 
>>> I’m actually indifferent to how we approach this.
>> 
>> Discussion should be on what is
>> 1. desirable
>> 2. achievable
>> 
>> And, if you are willing to continue your work on this, it is
>> IMO desirable to take this opportunity to actually reduce the
>> level of redundancy found in the projects' POMs, with all their
>> slight variations that keep things more complicated than they
>> could be.
>> 
>>> I’m more just
>>> motivated to pick a direction and get it behind us.
>> 
>> Do you know whether it is possible to go in the direction
>> which I propose?
>> 
> 
> The original problem this solved is that components that did use a version
> number in their artifact ID has to do to much redefining in their POMs.
> 
> We are now entering bike-shedding territory IMO. As Sebb (IIRC) pointed out
> elsewhere, a component does not have to update to a new CP version. If it
> does, obviously, it has to adapt. I sincerely believe that we are all
> trying to make Commons better. There is no compatibility guarantees for our
> internal components but of course we do not want to create headaches if we
> do not have to. We MUST make the distinction between an artifactId and
> OtherID (pick names, today, packageId and componentId) which does not
> include the major version number. That's what the current CP does and works
> for some components that have been released. CP also reduces the amount of
> properties you have to redefine in components, like the various URLs. My
> POV here is that we can make adjustments to CP but there is no need for
> some higher level discussion about "desirable" and "achievable". The goal
> has been achieved IMO, using packageId and componentId, you can write POMs
> that work for components that either have a version number or not in their
> artifact IDs.

I’ll try to over the next few days sort this out across all the projects consuming cp 47 so that we don’t see this problem again.

-Rob

> 
> Gary
> 
> 
>> Gilles
>> 
>>> @Benedikt - you
>>> have any thoughts on how we keep records of both “lang” as well as
>>> “lang3” in the parent for the sake of our surrounding ecosystem??
>>> 
>>> -Rob
>>> 
>>>> 
>>>> Can the parent POM generate the properties values required by
>>>> the "Commons" infrastructure from those (using maven plugin
>>>> code, I guess)?
>>>> 
>>>> E.g. generate "commons-lang" (a.o. to generate the path to the
>>>> web site's SVN repository) from
>>>> <artifactId>commons-lang3</artifactId>
>>>> <version>3.9-SNAPSHOT</version>
>>>> 
>>>> [Side-effect would be to enforce the rule for changing top-level
>>>> package name in step with a new major version.]
>>>> 
>>>> Best regards,
>>>> Gilles
>>>> 
>>>>> 
>>>>> If so, what is it? Let’s pick it and move forward.
>>>>> 
>>>>> Cheers,
>>>>> -Rob
>>>>> 
>>>>> [Ref]
>>>>> June conversation on the matter as well.
>>>>> https://markmail.org/message/7xbk3zm6pornsrto
>>>>> <https://markmail.org/message/7xbk3zm6pornsrto>
>>>>> 
>>>>>> 
>>>>>> [...]
>>>> 
>>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx