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