On Fri, 21 Sep 2018 09:26:07 -0600, Gary Gregory wrote:
On Fri, Sep 21, 2018 at 7:05 AM Gilles <gil...@harfang.homelinux.org>
wrote:
On Fri, 21 Sep 2018 08:52:37 -0400, Rob Tompkins wrote:
>> On Sep 20, 2018, at 9:31 AM, Gilles
<gil...@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
<brit...@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.
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.
Unfair.
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 don't agree: Components that used to delegate to CP should not start
doing everything by themselves because some CP update is not adequate
for all components. Case in point: at some point, CP evolution broke
multi-module builds, while update was *required* to support newer JDK.
I sincerely believe that we are all
trying to make Commons better.
Didn't say otherwise. Just that we cannot stay in the middle of
the river (meaning: some components cannot build).
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.
Thank you.
Current headache is: How do I make "mvn site:stage" work for [RNG]?
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.
IMO conciseness would help. Not arguing further; those who do the work
will choose whatever suits them.
Gilles
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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
