Re: [All] CP definitions
> 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:
>>> Reverting this change was discussed here . It was a result of this
>>> commit  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:
>> and change [parent] back to
> What about starting from maven requirements and try and avoid
> redundancies (that ultimately lead to inconsistencies)?
> Given are
I’m actually indifferent to how we approach this. I’m more just motivated to pick a direction and get it behind us. @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??
> 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
> [Side-effect would be to enforce the rule for changing top-level
> package name in step with a new major version.]
> Best regards,
>> If so, what is it? Let’s pick it and move forward.
>> June conversation on the matter as well.
>> https://markmail.org/message/7xbk3zm6pornsrto <https://markmail.org/message/7xbk3zm6pornsrto>
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx <mailto:dev-unsubscribe@xxxxxxxxxxxxxxxxxx>
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx <mailto:dev-help@xxxxxxxxxxxxxxxxxx>