git.net

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

Re: [All] CP definitions


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?

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