commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Tompkins <chtom...@gmail.com>
Subject Re: [All] CP definitions
Date Fri, 21 Sep 2018 12:52:37 GMT


> On Sep 20, 2018, at 9:31 AM, Gilles <gilles@harfang.homelinux.org> wrote:
> 
> On Thu, 20 Sep 2018 08:53:38 -0400, Rob Tompkins wrote:
>>> On Sep 20, 2018, at 3:10 AM, Benedikt Ritter <britter@apache.org> 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. 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??

-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@commons.apache.org <mailto:dev-unsubscribe@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org <mailto:dev-help@commons.apache.org>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message