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>

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


[...]


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to