Discussion:
[All] CP definitions (Was: svn commit: r1841296 [...])
Gilles
2018-09-19 10:07:44 UTC
Permalink
Hi.

Are we sure that the fix/revert below to work as intended for
*all* components?

Common usage should be enforced (e.g. to allow anyone to help
releasing any component), and ancient inconsistencies fixed.

With a concrete example of a component that has had major
version changes (and top-level package change accordingly),
what is
commons.componentid
and what is
project.artefactId
?

Thanks,
Gilles
Author: britter
Date: Wed Sep 19 08:06:17 2018
New Revision: 1841296
URL: http://svn.apache.org/viewvc?rev=1841296&view=rev
COMMONSSITE-124: Revert change in commons.scmPubUrl in Parent 47
commons/proper/commons-parent/trunk/pom.xml
commons/proper/commons-parent/trunk/src/changes/changes.xml
Modified: commons/proper/commons-parent/trunk/pom.xml
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?rev=1841296&r1=1841295&r2=1841296&view=diff
==============================================================================
--- commons/proper/commons-parent/trunk/pom.xml (original)
+++ commons/proper/commons-parent/trunk/pom.xml Wed Sep 19 08:06:17
2018
@@ -1940,7 +1940,7 @@
<!-- value modules can override it -->
<commons.site.path>${commons.componentid}</commons.site.path>
-
<commons.scmPubUrl>https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${commons.componentid}</commons.scmPubUrl>
+
<commons.scmPubUrl>https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${project.artifactId}</commons.scmPubUrl>
<commons.scmPubCheckoutDirectory>${commons.site.cache}/${commons.site.path}</commons.scmPubCheckoutDirectory>
<commons.scmPubServer>commons.site</commons.scmPubServer>
Modified: commons/proper/commons-parent/trunk/src/changes/changes.xml
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/src/changes/changes.xml?rev=1841296&r1=1841295&r2=1841296&view=diff
==============================================================================
--- commons/proper/commons-parent/trunk/src/changes/changes.xml
(original)
+++ commons/proper/commons-parent/trunk/src/changes/changes.xml Wed
Sep 19 08:06:17 2018
@@ -61,6 +61,7 @@ The <action> type attribute can be add,u
<body>
<release version="48" date="YYYY-MM-DD" description="TBD">
+ <action issue="COMMONSSITE-124" type="fix"
dev="britter">Revert change in commons.scmPubUrl in Parent
47</action>
<action type="update">Update parent from
org.apache:apache 19 to 20.</action>
<action type="update">maven-compiler-plugin 3.7.0 ->
3.8.0</action>
<action type="fix">re-enabled japicmp and introduced
japicmp.skip property that
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@commons.apache.org
For additional commands, e-mail: dev-***@commons.apache.org
Gary Gregory
2018-09-19 12:45:13 UTC
Permalink
The difference is to account for artifact ids that contain a version like
commons-lang3. The component id is then just commons-lang. You must not
have versions in names for certain names like in the download page. This
change will probably break builds like pool, dbcp, lang, and so on.

Gary
Post by Gilles
Hi.
Are we sure that the fix/revert below to work as intended for
*all* components?
Common usage should be enforced (e.g. to allow anyone to help
releasing any component), and ancient inconsistencies fixed.
With a concrete example of a component that has had major
version changes (and top-level package change accordingly),
what is
commons.componentid
and what is
project.artefactId
?
Thanks,
Gilles
Author: britter
Date: Wed Sep 19 08:06:17 2018
New Revision: 1841296
URL: http://svn.apache.org/viewvc?rev=1841296&view=rev
COMMONSSITE-124: Revert change in commons.scmPubUrl in Parent 47
commons/proper/commons-parent/trunk/pom.xml
commons/proper/commons-parent/trunk/src/changes/changes.xml
Modified: commons/proper/commons-parent/trunk/pom.xml
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?rev=1841296&r1=1841295&r2=1841296&view=diff
==============================================================================
--- commons/proper/commons-parent/trunk/pom.xml (original)
+++ commons/proper/commons-parent/trunk/pom.xml Wed Sep 19 08:06:17
2018
@@ -1940,7 +1940,7 @@
<!-- value modules can override it -->
<commons.site.path>${commons.componentid}</commons.site.path>
-
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${commons.componentid}
</commons.scmPubUrl>
+
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${project.artifactId}
</commons.scmPubUrl>
<commons.scmPubCheckoutDirectory>${commons.site.cache}/${commons.site.path}</commons.scmPubCheckoutDirectory>
<commons.scmPubServer>commons.site</commons.scmPubServer>
Modified: commons/proper/commons-parent/trunk/src/changes/changes.xml
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/src/changes/changes.xml?rev=1841296&r1=1841295&r2=1841296&view=diff
==============================================================================
--- commons/proper/commons-parent/trunk/src/changes/changes.xml
(original)
+++ commons/proper/commons-parent/trunk/src/changes/changes.xml Wed
Sep 19 08:06:17 2018
@@ -61,6 +61,7 @@ The <action> type attribute can be add,u
<body>
<release version="48" date="YYYY-MM-DD" description="TBD">
+ <action issue="COMMONSSITE-124" type="fix"
dev="britter">Revert change in commons.scmPubUrl in Parent
47</action>
<action type="update">Update parent from
org.apache:apache 19 to 20.</action>
<action type="update">maven-compiler-plugin 3.7.0 ->
3.8.0</action>
<action type="fix">re-enabled japicmp and introduced
japicmp.skip property that
---------------------------------------------------------------------
Rob Tompkins
2018-09-19 13:08:51 UTC
Permalink
My impression was that we had this conversation, and we decided that we wanted this the other way around and to fix the components respectively due to the semantics of the issue at hand based on what Gary said below.

-Rob
Post by Gary Gregory
The difference is to account for artifact ids that contain a version like
commons-lang3. The component id is then just commons-lang. You must not
have versions in names for certain names like in the download page. This
change will probably break builds like pool, dbcp, lang, and so on.
Gary
Post by Gilles
Hi.
Are we sure that the fix/revert below to work as intended for
*all* components?
Common usage should be enforced (e.g. to allow anyone to help
releasing any component), and ancient inconsistencies fixed.
With a concrete example of a component that has had major
version changes (and top-level package change accordingly),
what is
commons.componentid
and what is
project.artefactId
?
Thanks,
Gilles
Author: britter
Date: Wed Sep 19 08:06:17 2018
New Revision: 1841296
URL: http://svn.apache.org/viewvc?rev=1841296&view=rev
COMMONSSITE-124: Revert change in commons.scmPubUrl in Parent 47
commons/proper/commons-parent/trunk/pom.xml
commons/proper/commons-parent/trunk/src/changes/changes.xml
Modified: commons/proper/commons-parent/trunk/pom.xml
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?rev=1841296&r1=1841295&r2=1841296&view=diff
==============================================================================
--- commons/proper/commons-parent/trunk/pom.xml (original)
+++ commons/proper/commons-parent/trunk/pom.xml Wed Sep 19 08:06:17
2018
@@ -1940,7 +1940,7 @@
<!-- value modules can override it -->
<commons.site.path>${commons.componentid}</commons.site.path>
-
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${commons.componentid}
</commons.scmPubUrl>
+
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${project.artifactId}
</commons.scmPubUrl>
<commons.scmPubCheckoutDirectory>${commons.site.cache}/${commons.site.path}</commons.scmPubCheckoutDirectory>
<commons.scmPubServer>commons.site</commons.scmPubServer>
Modified: commons/proper/commons-parent/trunk/src/changes/changes.xml
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/src/changes/changes.xml?rev=1841296&r1=1841295&r2=1841296&view=diff
==============================================================================
--- commons/proper/commons-parent/trunk/src/changes/changes.xml
(original)
+++ commons/proper/commons-parent/trunk/src/changes/changes.xml Wed
Sep 19 08:06:17 2018
@@ -61,6 +61,7 @@ The <action> type attribute can be add,u
<body>
<release version="48" date="YYYY-MM-DD" description="TBD">
+ <action issue="COMMONSSITE-124" type="fix"
dev="britter">Revert change in commons.scmPubUrl in Parent
47</action>
<action type="update">Update parent from
org.apache:apache 19 to 20.</action>
<action type="update">maven-compiler-plugin 3.7.0 ->
3.8.0</action>
<action type="fix">re-enabled japicmp and introduced
japicmp.skip property that
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@commons.apache.org
For additional commands, e-mail: dev-***@commons.apache.org
Gilles
2018-09-19 13:42:02 UTC
Permalink
Hi Rob.
Post by Rob Tompkins
My impression was that we had this conversation, and we decided that
we wanted this the other way around and to fix the components
respectively due to the semantics of the issue at hand based on what
Gary said below.
It is not clear (see my reply to Gary's message).

+1 to fix of course.
As proposed previously, [RNG] could serve as the testing ground
and future "reference" POM of a new modular component that works
with the more recent CP (with your release-plugin).[1]

Regards,
Gilles

[1] It is *not* the case currently on master ("mvn site" fails)!
Post by Rob Tompkins
-Rob
Post by Gary Gregory
The difference is to account for artifact ids that contain a version like
commons-lang3. The component id is then just commons-lang. You must not
have versions in names for certain names like in the download page. This
change will probably break builds like pool, dbcp, lang, and so on.
Gary
Post by Gilles
Hi.
Are we sure that the fix/revert below to work as intended for
*all* components?
Common usage should be enforced (e.g. to allow anyone to help
releasing any component), and ancient inconsistencies fixed.
With a concrete example of a component that has had major
version changes (and top-level package change accordingly),
what is
commons.componentid
and what is
project.artefactId
?
Thanks,
Gilles
Author: britter
Date: Wed Sep 19 08:06:17 2018
New Revision: 1841296
URL: http://svn.apache.org/viewvc?rev=1841296&view=rev
COMMONSSITE-124: Revert change in commons.scmPubUrl in Parent 47
commons/proper/commons-parent/trunk/pom.xml
commons/proper/commons-parent/trunk/src/changes/changes.xml
Modified: commons/proper/commons-parent/trunk/pom.xml
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?rev=1841296&r1=1841295&r2=1841296&view=diff
==============================================================================
--- commons/proper/commons-parent/trunk/pom.xml (original)
+++ commons/proper/commons-parent/trunk/pom.xml Wed Sep 19
08:06:17
2018
@@ -1940,7 +1940,7 @@
<!-- value modules can override it -->
<commons.site.path>${commons.componentid}</commons.site.path>
-
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${commons.componentid}
</commons.scmPubUrl>
+
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${project.artifactId}
</commons.scmPubUrl>
<commons.scmPubCheckoutDirectory>${commons.site.cache}/${commons.site.path}</commons.scmPubCheckoutDirectory>
<commons.scmPubServer>commons.site</commons.scmPubServer>
commons/proper/commons-parent/trunk/src/changes/changes.xml
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/src/changes/changes.xml?rev=1841296&r1=1841295&r2=1841296&view=diff
==============================================================================
--- commons/proper/commons-parent/trunk/src/changes/changes.xml
(original)
+++ commons/proper/commons-parent/trunk/src/changes/changes.xml Wed
Sep 19 08:06:17 2018
@@ -61,6 +61,7 @@ The <action> type attribute can be add,u
<body>
<release version="48" date="YYYY-MM-DD" description="TBD">
+ <action issue="COMMONSSITE-124" type="fix"
dev="britter">Revert change in commons.scmPubUrl in Parent
47</action>
<action type="update">Update parent from
org.apache:apache 19 to 20.</action>
<action type="update">maven-compiler-plugin 3.7.0 ->
3.8.0</action>
<action type="fix">re-enabled japicmp and introduced
japicmp.skip property that
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@commons.apache.org
For additional commands, e-mail: dev-***@commons.apache.org
Gilles
2018-09-19 13:28:46 UTC
Permalink
Post by Gary Gregory
The difference is to account for artifact ids that contain a version like
commons-lang3. The component id is then just commons-lang. You must not
have versions in names for certain names like in the download page. This
change will probably break builds like pool, dbcp, lang, and so on.
Hmm, this completes the confusion!

If "artifactId" is e.g. commons-lang3 then I don't understand how
the reverted line works because (AFAICT) the SVN URL is

https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-lang/

The [Math] POM contains these lines:
---CUT---
<!-- Do not change: "math" is the name of the component even if the
name of the base package evolves with major release numbers
(see "commons.osgi.symbolicName", below). -->
<commons.componentid>math4</commons.componentid>
---CUT---
Correct or not?

It also uses a fix string:
---CUT---
<commons.scmPubUrl>https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-math</commons.scmPubUrl>
---CUT---
whereas a variable (as in the commit below) would seem more portable.

Why isn't "<commons.scmPubUrl>" defined in CP only (using the
appropriate
variable overridden in each component)?

Why having
---CUT---
<commons.site.path>math</commons.site.path>
---CUT---
that doesn't look at all like a "path"?
We could define a quite more explicit "<commons.component.name>"
that could serve for composing a path, as well as for any
other purpose where the component is meant, independently
of artefact identifier syntax or major version.


Regards,
Gilles
Post by Gary Gregory
Gary
Post by Gilles
Hi.
Are we sure that the fix/revert below to work as intended for
*all* components?
Common usage should be enforced (e.g. to allow anyone to help
releasing any component), and ancient inconsistencies fixed.
With a concrete example of a component that has had major
version changes (and top-level package change accordingly),
what is
commons.componentid
and what is
project.artefactId
?
Thanks,
Gilles
Author: britter
Date: Wed Sep 19 08:06:17 2018
New Revision: 1841296
URL: http://svn.apache.org/viewvc?rev=1841296&view=rev
COMMONSSITE-124: Revert change in commons.scmPubUrl in Parent 47
commons/proper/commons-parent/trunk/pom.xml
commons/proper/commons-parent/trunk/src/changes/changes.xml
Modified: commons/proper/commons-parent/trunk/pom.xml
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?rev=1841296&r1=1841295&r2=1841296&view=diff
==============================================================================
--- commons/proper/commons-parent/trunk/pom.xml (original)
+++ commons/proper/commons-parent/trunk/pom.xml Wed Sep 19
08:06:17
2018
@@ -1940,7 +1940,7 @@
<!-- value modules can override it -->
<commons.site.path>${commons.componentid}</commons.site.path>
-
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${commons.componentid}
</commons.scmPubUrl>
+
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${project.artifactId}
</commons.scmPubUrl>
<commons.scmPubCheckoutDirectory>${commons.site.cache}/${commons.site.path}</commons.scmPubCheckoutDirectory>
<commons.scmPubServer>commons.site</commons.scmPubServer>
commons/proper/commons-parent/trunk/src/changes/changes.xml
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/src/changes/changes.xml?rev=1841296&r1=1841295&r2=1841296&view=diff
==============================================================================
--- commons/proper/commons-parent/trunk/src/changes/changes.xml
(original)
+++ commons/proper/commons-parent/trunk/src/changes/changes.xml
Wed
Sep 19 08:06:17 2018
@@ -61,6 +61,7 @@ The <action> type attribute can be add,u
<body>
<release version="48" date="YYYY-MM-DD"
description="TBD">
+ <action issue="COMMONSSITE-124" type="fix"
dev="britter">Revert change in commons.scmPubUrl in Parent
47</action>
<action type="update">Update parent from
org.apache:apache 19 to 20.</action>
<action type="update">maven-compiler-plugin 3.7.0 ->
3.8.0</action>
<action type="fix">re-enabled japicmp and introduced
japicmp.skip property that
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@commons.apache.org
For additional commands, e-mail: dev-***@commons.apache.org
Rob Tompkins
2018-09-19 13:36:25 UTC
Permalink
Post by Gilles
Post by Gary Gregory
The difference is to account for artifact ids that contain a version like
commons-lang3. The component id is then just commons-lang. You must not
have versions in names for certain names like in the download page. This
change will probably break builds like pool, dbcp, lang, and so on.
Hmm, this completes the confusion!
If "artifactId" is e.g. commons-lang3 then I don't understand how
the reverted line works because (AFAICT) the SVN URL is
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-lang/
---CUT---
<!-- Do not change: "math" is the name of the component even if the
name of the base package evolves with major release numbers
(see "commons.osgi.symbolicName", below). -->
<commons.componentid>math4</commons.componentid>
---CUT---
Correct or not?
Half of the components are correct, half aren’t.

What’s the consensus here? My thought was that componentId=math is actually correct based on the documentation, and we need and “artifactIdSuffix” or something analogous.

-Rob
Post by Gilles
---CUT---
<commons.scmPubUrl>https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-math</commons.scmPubUrl>
---CUT---
whereas a variable (as in the commit below) would seem more portable.
Why isn't "<commons.scmPubUrl>" defined in CP only (using the appropriate
variable overridden in each component)?
Why having
---CUT---
<commons.site.path>math</commons.site.path>
---CUT---
that doesn't look at all like a "path"?
We could define a quite more explicit "<commons.component.name>"
that could serve for composing a path, as well as for any
other purpose where the component is meant, independently
of artefact identifier syntax or major version.
Regards,
Gilles
Post by Gary Gregory
Gary
Post by Gilles
Hi.
Are we sure that the fix/revert below to work as intended for
*all* components?
Common usage should be enforced (e.g. to allow anyone to help
releasing any component), and ancient inconsistencies fixed.
With a concrete example of a component that has had major
version changes (and top-level package change accordingly),
what is
commons.componentid
and what is
project.artefactId
?
Thanks,
Gilles
Author: britter
Date: Wed Sep 19 08:06:17 2018
New Revision: 1841296
URL: http://svn.apache.org/viewvc?rev=1841296&view=rev
COMMONSSITE-124: Revert change in commons.scmPubUrl in Parent 47
commons/proper/commons-parent/trunk/pom.xml
commons/proper/commons-parent/trunk/src/changes/changes.xml
Modified: commons/proper/commons-parent/trunk/pom.xml
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?rev=1841296&r1=1841295&r2=1841296&view=diff
==============================================================================
--- commons/proper/commons-parent/trunk/pom.xml (original)
+++ commons/proper/commons-parent/trunk/pom.xml Wed Sep 19 08:06:17
2018
@@ -1940,7 +1940,7 @@
<!-- value modules can override it -->
<commons.site.path>${commons.componentid}</commons.site.path>
-
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${commons.componentid}
</commons.scmPubUrl>
+
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${project.artifactId}
</commons.scmPubUrl>
<commons.scmPubCheckoutDirectory>${commons.site.cache}/${commons.site.path}</commons.scmPubCheckoutDirectory>
<commons.scmPubServer>commons.site</commons.scmPubServer>
Modified: commons/proper/commons-parent/trunk/src/changes/changes.xml
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/src/changes/changes.xml?rev=1841296&r1=1841295&r2=1841296&view=diff
==============================================================================
--- commons/proper/commons-parent/trunk/src/changes/changes.xml
(original)
+++ commons/proper/commons-parent/trunk/src/changes/changes.xml Wed
Sep 19 08:06:17 2018
@@ -61,6 +61,7 @@ The <action> type attribute can be add,u
<body>
<release version="48" date="YYYY-MM-DD" description="TBD">
+ <action issue="COMMONSSITE-124" type="fix"
dev="britter">Revert change in commons.scmPubUrl in Parent
47</action>
<action type="update">Update parent from
org.apache:apache 19 to 20.</action>
<action type="update">maven-compiler-plugin 3.7.0 ->
3.8.0</action>
<action type="fix">re-enabled japicmp and introduced
japicmp.skip property that
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@commons.apache.org
For additional commands, e-mail: dev-***@commons.apache.org
Gilles
2018-09-19 14:02:47 UTC
Permalink
Post by Rob Tompkins
Post by Gilles
Post by Gary Gregory
The difference is to account for artifact ids that contain a
version like
commons-lang3. The component id is then just commons-lang. You must not
have versions in names for certain names like in the download page. This
change will probably break builds like pool, dbcp, lang, and so on.
Hmm, this completes the confusion!
If "artifactId" is e.g. commons-lang3 then I don't understand how
the reverted line works because (AFAICT) the SVN URL is
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-lang/
---CUT---
<!-- Do not change: "math" is the name of the component even if the
name of the base package evolves with major release numbers
(see "commons.osgi.symbolicName", below). -->
<commons.componentid>math4</commons.componentid>
---CUT---
Correct or not?
Half of the components are correct, half aren’t.
What’s the consensus here? My thought was that componentId=math is
actually correct based on the documentation, and we need and
“artifactIdSuffix” or something analogous.
We need to reduce the number of variations on a name.

I propose something like:

<commons.componentName>lang</commons.componentName>
<commons.component.majorVersion>3</commons.component.majorVersion>

Then, all the various names can be constructed, and
hopefully most of the currently duplicated functionality
can be removed, and the "right things" be done in CP.

Gilles
Post by Rob Tompkins
-Rob
Post by Gilles
---CUT---
<commons.scmPubUrl>https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-math</commons.scmPubUrl>
---CUT---
whereas a variable (as in the commit below) would seem more
portable.
Why isn't "<commons.scmPubUrl>" defined in CP only (using the
appropriate
variable overridden in each component)?
Why having
---CUT---
<commons.site.path>math</commons.site.path>
---CUT---
that doesn't look at all like a "path"?
We could define a quite more explicit "<commons.component.name>"
that could serve for composing a path, as well as for any
other purpose where the component is meant, independently
of artefact identifier syntax or major version.
Regards,
Gilles
Post by Gary Gregory
Gary
Post by Gilles
Hi.
Are we sure that the fix/revert below to work as intended for
*all* components?
Common usage should be enforced (e.g. to allow anyone to help
releasing any component), and ancient inconsistencies fixed.
With a concrete example of a component that has had major
version changes (and top-level package change accordingly),
what is
commons.componentid
and what is
project.artefactId
?
Thanks,
Gilles
Author: britter
Date: Wed Sep 19 08:06:17 2018
New Revision: 1841296
URL: http://svn.apache.org/viewvc?rev=1841296&view=rev
COMMONSSITE-124: Revert change in commons.scmPubUrl in Parent 47
commons/proper/commons-parent/trunk/pom.xml
commons/proper/commons-parent/trunk/src/changes/changes.xml
Modified: commons/proper/commons-parent/trunk/pom.xml
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?rev=1841296&r1=1841295&r2=1841296&view=diff
==============================================================================
--- commons/proper/commons-parent/trunk/pom.xml (original)
+++ commons/proper/commons-parent/trunk/pom.xml Wed Sep 19
08:06:17
2018
@@ -1940,7 +1940,7 @@
<!-- value modules can override it -->
<commons.site.path>${commons.componentid}</commons.site.path>
-
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${commons.componentid}
</commons.scmPubUrl>
+
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${project.artifactId}
</commons.scmPubUrl>
<commons.scmPubCheckoutDirectory>${commons.site.cache}/${commons.site.path}</commons.scmPubCheckoutDirectory>
<commons.scmPubServer>commons.site</commons.scmPubServer>
commons/proper/commons-parent/trunk/src/changes/changes.xml
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/src/changes/changes.xml?rev=1841296&r1=1841295&r2=1841296&view=diff
==============================================================================
--- commons/proper/commons-parent/trunk/src/changes/changes.xml
(original)
+++ commons/proper/commons-parent/trunk/src/changes/changes.xml
Wed
Sep 19 08:06:17 2018
@@ -61,6 +61,7 @@ The <action> type attribute can be add,u
<body>
<release version="48" date="YYYY-MM-DD"
description="TBD">
+ <action issue="COMMONSSITE-124" type="fix"
dev="britter">Revert change in commons.scmPubUrl in Parent
47</action>
<action type="update">Update parent from
org.apache:apache 19 to 20.</action>
<action type="update">maven-compiler-plugin 3.7.0
->
3.8.0</action>
<action type="fix">re-enabled japicmp and
introduced
japicmp.skip property that
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@commons.apache.org
For additional commands, e-mail: dev-***@commons.apache.org
Rob Tompkins
2018-09-19 14:28:50 UTC
Permalink
I think the plan moving forward here is that we should do the following:

<commons.componentid>math</commons.componentid>
<commons.packageId>math4</commons.pachageId>

And change [parent] back to

<commons.scmPubUrl>https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${commons.componentid}</commons.scmPubUrl>

Yeah?

-Rob
Post by Rob Tompkins
Post by Gilles
Post by Gary Gregory
The difference is to account for artifact ids that contain a version like
commons-lang3. The component id is then just commons-lang. You must not
have versions in names for certain names like in the download page. This
change will probably break builds like pool, dbcp, lang, and so on.
Hmm, this completes the confusion!
If "artifactId" is e.g. commons-lang3 then I don't understand how
the reverted line works because (AFAICT) the SVN URL is
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-lang/
---CUT---
<!-- Do not change: "math" is the name of the component even if the
name of the base package evolves with major release numbers
(see "commons.osgi.symbolicName", below). -->
<commons.componentid>math4</commons.componentid>
---CUT---
Correct or not?
Half of the components are correct, half aren’t.
What’s the consensus here? My thought was that componentId=math is actually correct based on the documentation, and we need and “artifactIdSuffix” or something analogous.
-Rob
Post by Gilles
---CUT---
<commons.scmPubUrl>https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-math</commons.scmPubUrl>
---CUT---
whereas a variable (as in the commit below) would seem more portable.
Why isn't "<commons.scmPubUrl>" defined in CP only (using the appropriate
variable overridden in each component)?
Why having
---CUT---
<commons.site.path>math</commons.site.path>
---CUT---
that doesn't look at all like a "path"?
We could define a quite more explicit "<commons.component.name>"
that could serve for composing a path, as well as for any
other purpose where the component is meant, independently
of artefact identifier syntax or major version.
Regards,
Gilles
Post by Gary Gregory
Gary
Post by Gilles
Hi.
Are we sure that the fix/revert below to work as intended for
*all* components?
Common usage should be enforced (e.g. to allow anyone to help
releasing any component), and ancient inconsistencies fixed.
With a concrete example of a component that has had major
version changes (and top-level package change accordingly),
what is
commons.componentid
and what is
project.artefactId
?
Thanks,
Gilles
Author: britter
Date: Wed Sep 19 08:06:17 2018
New Revision: 1841296
URL: http://svn.apache.org/viewvc?rev=1841296&view=rev
COMMONSSITE-124: Revert change in commons.scmPubUrl in Parent 47
commons/proper/commons-parent/trunk/pom.xml
commons/proper/commons-parent/trunk/src/changes/changes.xml
Modified: commons/proper/commons-parent/trunk/pom.xml
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?rev=1841296&r1=1841295&r2=1841296&view=diff
==============================================================================
--- commons/proper/commons-parent/trunk/pom.xml (original)
+++ commons/proper/commons-parent/trunk/pom.xml Wed Sep 19 08:06:17
2018
@@ -1940,7 +1940,7 @@
<!-- value modules can override it -->
<commons.site.path>${commons.componentid}</commons.site.path>
-
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${commons.componentid}
</commons.scmPubUrl>
+
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${project.artifactId}
</commons.scmPubUrl>
<commons.scmPubCheckoutDirectory>${commons.site.cache}/${commons.site.path}</commons.scmPubCheckoutDirectory>
<commons.scmPubServer>commons.site</commons.scmPubServer>
Modified: commons/proper/commons-parent/trunk/src/changes/changes.xml
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/src/changes/changes.xml?rev=1841296&r1=1841295&r2=1841296&view=diff
==============================================================================
--- commons/proper/commons-parent/trunk/src/changes/changes.xml
(original)
+++ commons/proper/commons-parent/trunk/src/changes/changes.xml Wed
Sep 19 08:06:17 2018
@@ -61,6 +61,7 @@ The <action> type attribute can be add,u
<body>
<release version="48" date="YYYY-MM-DD" description="TBD">
+ <action issue="COMMONSSITE-124" type="fix"
dev="britter">Revert change in commons.scmPubUrl in Parent
47</action>
<action type="update">Update parent from
org.apache:apache 19 to 20.</action>
<action type="update">maven-compiler-plugin 3.7.0 ->
3.8.0</action>
<action type="fix">re-enabled japicmp and introduced
japicmp.skip property that
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@commons.apache.org
For additional commands, e-mail: dev-***@commons.apache.org
Gilles
2018-09-19 14:48:25 UTC
Permalink
Post by Rob Tompkins
I think the plan moving forward here is that we should do the
<commons.componentid>math</commons.componentid>
<commons.packageId>math4</commons.pachageId>
See my other post for an alternative.
Post by Rob Tompkins
And change [parent] back to
<commons.scmPubUrl>https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${commons.componentid}</commons.scmPubUrl>
If possible, we should either create the Jenkins jobs I
referred to in a previous message, or reimplement some
functionality in CP so as to not break existing POMs
(managed by people who do not yet want to change how
they perform a release).

For example, the component's POM should not need to define
the above path; everything should be transparently performed
as part of a new "rob-release" profile. :-)

Gilles
Post by Rob Tompkins
Yeah?
-Rob
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@commons.apache.org
For additional commands, e-mail: dev-***@commons.apache.org
Gary Gregory
2018-09-19 15:25:20 UTC
Permalink
Post by Rob Tompkins
<commons.componentid>math</commons.componentid>
<commons.packageId>math4</commons.pachageId>
And change [parent] back to
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${commons.componentid}
</commons.scmPubUrl>
Yeah?
LGTM.

Gary
Post by Rob Tompkins
-Rob
Post by Gilles
Post by Gary Gregory
The difference is to account for artifact ids that contain a version
like
Post by Gilles
Post by Gary Gregory
commons-lang3. The component id is then just commons-lang. You must not
have versions in names for certain names like in the download page.
This
Post by Gilles
Post by Gary Gregory
change will probably break builds like pool, dbcp, lang, and so on.
Hmm, this completes the confusion!
If "artifactId" is e.g. commons-lang3 then I don't understand how
the reverted line works because (AFAICT) the SVN URL is
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-lang/
Post by Gilles
---CUT---
<!-- Do not change: "math" is the name of the component even if the
name of the base package evolves with major release numbers
(see "commons.osgi.symbolicName", below). -->
<commons.componentid>math4</commons.componentid>
---CUT---
Correct or not?
Half of the components are correct, half aren’t.
What’s the consensus here? My thought was that componentId=math is
actually correct based on the documentation, and we need and
“artifactIdSuffix” or something analogous.
-Rob
Post by Gilles
---CUT---
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-math
</commons.scmPubUrl>
Post by Gilles
---CUT---
whereas a variable (as in the commit below) would seem more portable.
Why isn't "<commons.scmPubUrl>" defined in CP only (using the
appropriate
Post by Gilles
variable overridden in each component)?
Why having
---CUT---
<commons.site.path>math</commons.site.path>
---CUT---
that doesn't look at all like a "path"?
We could define a quite more explicit "<commons.component.name>"
that could serve for composing a path, as well as for any
other purpose where the component is meant, independently
of artefact identifier syntax or major version.
Regards,
Gilles
Post by Gary Gregory
Gary
Post by Gilles
Hi.
Are we sure that the fix/revert below to work as intended for
*all* components?
Common usage should be enforced (e.g. to allow anyone to help
releasing any component), and ancient inconsistencies fixed.
With a concrete example of a component that has had major
version changes (and top-level package change accordingly),
what is
commons.componentid
and what is
project.artefactId
?
Thanks,
Gilles
Author: britter
Date: Wed Sep 19 08:06:17 2018
New Revision: 1841296
URL: http://svn.apache.org/viewvc?rev=1841296&view=rev
COMMONSSITE-124: Revert change in commons.scmPubUrl in Parent 47
commons/proper/commons-parent/trunk/pom.xml
commons/proper/commons-parent/trunk/src/changes/changes.xml
Modified: commons/proper/commons-parent/trunk/pom.xml
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?rev=1841296&r1=1841295&r2=1841296&view=diff
==============================================================================
Post by Gilles
Post by Gary Gregory
Post by Gilles
--- commons/proper/commons-parent/trunk/pom.xml (original)
+++ commons/proper/commons-parent/trunk/pom.xml Wed Sep 19 08:06:17
2018
@@ -1940,7 +1940,7 @@
<!-- value modules can override it -->
<commons.site.path>${commons.componentid}</commons.site.path>
-
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${commons.componentid}
Post by Gilles
Post by Gary Gregory
Post by Gilles
</commons.scmPubUrl>
+
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${project.artifactId}
Post by Gilles
Post by Gary Gregory
Post by Gilles
</commons.scmPubUrl>
<commons.scmPubCheckoutDirectory>${commons.site.cache}/${commons.site.path}</commons.scmPubCheckoutDirectory>
Post by Gilles
Post by Gary Gregory
Post by Gilles
<commons.scmPubServer>commons.site</commons.scmPubServer>
Modified: commons/proper/commons-parent/trunk/src/changes/changes.xml
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/src/changes/changes.xml?rev=1841296&r1=1841295&r2=1841296&view=diff
==============================================================================
Post by Gilles
Post by Gary Gregory
Post by Gilles
--- commons/proper/commons-parent/trunk/src/changes/changes.xml
(original)
+++ commons/proper/commons-parent/trunk/src/changes/changes.xml Wed
Sep 19 08:06:17 2018
@@ -61,6 +61,7 @@ The <action> type attribute can be add,u
<body>
<release version="48" date="YYYY-MM-DD" description="TBD">
+ <action issue="COMMONSSITE-124" type="fix"
dev="britter">Revert change in commons.scmPubUrl in Parent
47</action>
<action type="update">Update parent from
org.apache:apache 19 to 20.</action>
<action type="update">maven-compiler-plugin 3.7.0 ->
3.8.0</action>
<action type="fix">re-enabled japicmp and introduced
japicmp.skip property that
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
Benedikt Ritter
2018-09-20 07:10:50 UTC
Permalink
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.

Regards,
Benedikt

[1]
https://lists.apache.org/thread.html/304129bf7d25a2118ee3f324214c04e1e8f0846e7ee43a57b100a26e@%3Cdev.commons.apache.org%3E
[2]
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=1831599&r2=1832339

Am Mi., 19. Sep. 2018 um 17:25 Uhr schrieb Gary Gregory <
Post by Rob Tompkins
<commons.componentid>math</commons.componentid>
<commons.packageId>math4</commons.pachageId>
And change [parent] back to
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${commons.componentid}
Post by Rob Tompkins
</commons.scmPubUrl>
Yeah?
LGTM.
Gary
Post by Rob Tompkins
-Rob
Post by Gilles
Post by Gary Gregory
The difference is to account for artifact ids that contain a version
like
Post by Gilles
Post by Gary Gregory
commons-lang3. The component id is then just commons-lang. You must
not
Post by Rob Tompkins
Post by Gilles
Post by Gary Gregory
have versions in names for certain names like in the download page.
This
Post by Gilles
Post by Gary Gregory
change will probably break builds like pool, dbcp, lang, and so on.
Hmm, this completes the confusion!
If "artifactId" is e.g. commons-lang3 then I don't understand how
the reverted line works because (AFAICT) the SVN URL is
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-lang/
Post by Rob Tompkins
Post by Gilles
---CUT---
<!-- Do not change: "math" is the name of the component even if the
name of the base package evolves with major release numbers
(see "commons.osgi.symbolicName", below). -->
<commons.componentid>math4</commons.componentid>
---CUT---
Correct or not?
Half of the components are correct, half aren’t.
What’s the consensus here? My thought was that componentId=math is
actually correct based on the documentation, and we need and
“artifactIdSuffix” or something analogous.
-Rob
Post by Gilles
---CUT---
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-math
Post by Rob Tompkins
</commons.scmPubUrl>
Post by Gilles
---CUT---
whereas a variable (as in the commit below) would seem more portable.
Why isn't "<commons.scmPubUrl>" defined in CP only (using the
appropriate
Post by Gilles
variable overridden in each component)?
Why having
---CUT---
<commons.site.path>math</commons.site.path>
---CUT---
that doesn't look at all like a "path"?
We could define a quite more explicit "<commons.component.name>"
that could serve for composing a path, as well as for any
other purpose where the component is meant, independently
of artefact identifier syntax or major version.
Regards,
Gilles
Post by Gary Gregory
Gary
Post by Gilles
Hi.
Are we sure that the fix/revert below to work as intended for
*all* components?
Common usage should be enforced (e.g. to allow anyone to help
releasing any component), and ancient inconsistencies fixed.
With a concrete example of a component that has had major
version changes (and top-level package change accordingly),
what is
commons.componentid
and what is
project.artefactId
?
Thanks,
Gilles
Author: britter
Date: Wed Sep 19 08:06:17 2018
New Revision: 1841296
URL: http://svn.apache.org/viewvc?rev=1841296&view=rev
COMMONSSITE-124: Revert change in commons.scmPubUrl in Parent 47
commons/proper/commons-parent/trunk/pom.xml
commons/proper/commons-parent/trunk/src/changes/changes.xml
Modified: commons/proper/commons-parent/trunk/pom.xml
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?rev=1841296&r1=1841295&r2=1841296&view=diff
==============================================================================
Post by Rob Tompkins
Post by Gilles
Post by Gary Gregory
Post by Gilles
--- commons/proper/commons-parent/trunk/pom.xml (original)
+++ commons/proper/commons-parent/trunk/pom.xml Wed Sep 19 08:06:17
2018
@@ -1940,7 +1940,7 @@
<!-- value modules can override it -->
<commons.site.path>${commons.componentid}</commons.site.path>
-
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${commons.componentid}
Post by Rob Tompkins
Post by Gilles
Post by Gary Gregory
Post by Gilles
</commons.scmPubUrl>
+
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${project.artifactId}
Post by Rob Tompkins
Post by Gilles
Post by Gary Gregory
Post by Gilles
</commons.scmPubUrl>
<commons.scmPubCheckoutDirectory>${commons.site.cache}/${commons.site.path}</commons.scmPubCheckoutDirectory>
Post by Rob Tompkins
Post by Gilles
Post by Gary Gregory
Post by Gilles
<commons.scmPubServer>commons.site</commons.scmPubServer>
commons/proper/commons-parent/trunk/src/changes/changes.xml
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/src/changes/changes.xml?rev=1841296&r1=1841295&r2=1841296&view=diff
==============================================================================
Post by Rob Tompkins
Post by Gilles
Post by Gary Gregory
Post by Gilles
--- commons/proper/commons-parent/trunk/src/changes/changes.xml
(original)
+++ commons/proper/commons-parent/trunk/src/changes/changes.xml Wed
Sep 19 08:06:17 2018
@@ -61,6 +61,7 @@ The <action> type attribute can be add,u
<body>
<release version="48" date="YYYY-MM-DD" description="TBD">
+ <action issue="COMMONSSITE-124" type="fix"
dev="britter">Revert change in commons.scmPubUrl in Parent
47</action>
<action type="update">Update parent from
org.apache:apache 19 to 20.</action>
<action type="update">maven-compiler-plugin 3.7.0 ->
3.8.0</action>
<action type="fix">re-enabled japicmp and introduced
japicmp.skip property that
---------------------------------------------------------------------
Post by Rob Tompkins
Post by Gilles
---------------------------------------------------------------------
---------------------------------------------------------------------
Gilles
2018-09-20 10:24:09 UTC
Permalink
Post by Benedikt Ritter
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.
I'm for it too. But not everyone is (or thinks that things
get easier)...
Post by Benedikt Ritter
But let's make sure that all the other
components still work.
I certainly agree, and am also frustrated that what used to work
suddenly doesn't anymore without anything related having changed
within the component's source repository.
Case in point is [RNG]: "mvn site:stage" doesn't work in "master"
for any version of CP. :-(

Gilles
Post by Benedikt Ritter
Regards,
Benedikt
[1]
[2]
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=1831599&r2=1832339
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@commons.apache.org
For additional commands, e-mail: dev-***@commons.apache.org
Rob Tompkins
2018-09-20 12:53:38 UTC
Permalink
Post by Benedikt Ritter
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>
????

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
Post by Benedikt Ritter
Regards,
Benedikt
[1]
[2]
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=1831599&r2=1832339
Am Mi., 19. Sep. 2018 um 17:25 Uhr schrieb Gary Gregory <
Post by Rob Tompkins
<commons.componentid>math</commons.componentid>
<commons.packageId>math4</commons.pachageId>
And change [parent] back to
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${commons.componentid}
Post by Rob Tompkins
</commons.scmPubUrl>
Yeah?
LGTM.
Gary
Post by Rob Tompkins
-Rob
Post by Rob Tompkins
Post by Gilles
Post by Gary Gregory
The difference is to account for artifact ids that contain a version
like
Post by Rob Tompkins
Post by Gilles
Post by Gary Gregory
commons-lang3. The component id is then just commons-lang. You must
not
Post by Rob Tompkins
Post by Rob Tompkins
Post by Gilles
Post by Gary Gregory
have versions in names for certain names like in the download page.
This
Post by Rob Tompkins
Post by Gilles
Post by Gary Gregory
change will probably break builds like pool, dbcp, lang, and so on.
Hmm, this completes the confusion!
If "artifactId" is e.g. commons-lang3 then I don't understand how
the reverted line works because (AFAICT) the SVN URL is
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-lang/
Post by Rob Tompkins
Post by Rob Tompkins
Post by Gilles
---CUT---
<!-- Do not change: "math" is the name of the component even if the
name of the base package evolves with major release numbers
(see "commons.osgi.symbolicName", below). -->
<commons.componentid>math4</commons.componentid>
---CUT---
Correct or not?
Half of the components are correct, half aren’t.
What’s the consensus here? My thought was that componentId=math is
actually correct based on the documentation, and we need and
“artifactIdSuffix” or something analogous.
Post by Rob Tompkins
-Rob
Post by Gilles
---CUT---
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-math
Post by Rob Tompkins
</commons.scmPubUrl>
Post by Rob Tompkins
Post by Gilles
---CUT---
whereas a variable (as in the commit below) would seem more portable.
Why isn't "<commons.scmPubUrl>" defined in CP only (using the
appropriate
Post by Rob Tompkins
Post by Gilles
variable overridden in each component)?
Why having
---CUT---
<commons.site.path>math</commons.site.path>
---CUT---
that doesn't look at all like a "path"?
We could define a quite more explicit "<commons.component.name>"
that could serve for composing a path, as well as for any
other purpose where the component is meant, independently
of artefact identifier syntax or major version.
Regards,
Gilles
Post by Gary Gregory
Gary
Post by Gilles
Hi.
Are we sure that the fix/revert below to work as intended for
*all* components?
Common usage should be enforced (e.g. to allow anyone to help
releasing any component), and ancient inconsistencies fixed.
With a concrete example of a component that has had major
version changes (and top-level package change accordingly),
what is
commons.componentid
and what is
project.artefactId
?
Thanks,
Gilles
Author: britter
Date: Wed Sep 19 08:06:17 2018
New Revision: 1841296
URL: http://svn.apache.org/viewvc?rev=1841296&view=rev
COMMONSSITE-124: Revert change in commons.scmPubUrl in Parent 47
commons/proper/commons-parent/trunk/pom.xml
commons/proper/commons-parent/trunk/src/changes/changes.xml
Modified: commons/proper/commons-parent/trunk/pom.xml
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?rev=1841296&r1=1841295&r2=1841296&view=diff
==============================================================================
Post by Rob Tompkins
Post by Rob Tompkins
Post by Gilles
Post by Gary Gregory
Post by Gilles
--- commons/proper/commons-parent/trunk/pom.xml (original)
+++ commons/proper/commons-parent/trunk/pom.xml Wed Sep 19 08:06:17
2018
@@ -1940,7 +1940,7 @@
<!-- value modules can override it -->
<commons.site.path>${commons.componentid}</commons.site.path>
-
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${commons.componentid}
Post by Rob Tompkins
Post by Rob Tompkins
Post by Gilles
Post by Gary Gregory
Post by Gilles
</commons.scmPubUrl>
+
<commons.scmPubUrl>
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${project.artifactId}
Post by Rob Tompkins
Post by Rob Tompkins
Post by Gilles
Post by Gary Gregory
Post by Gilles
</commons.scmPubUrl>
<commons.scmPubCheckoutDirectory>${commons.site.cache}/${commons.site.path}</commons.scmPubCheckoutDirectory>
Post by Rob Tompkins
Post by Rob Tompkins
Post by Gilles
Post by Gary Gregory
Post by Gilles
<commons.scmPubServer>commons.site</commons.scmPubServer>
commons/proper/commons-parent/trunk/src/changes/changes.xml
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/src/changes/changes.xml?rev=1841296&r1=1841295&r2=1841296&view=diff
==============================================================================
Post by Rob Tompkins
Post by Rob Tompkins
Post by Gilles
Post by Gary Gregory
Post by Gilles
--- commons/proper/commons-parent/trunk/src/changes/changes.xml
(original)
+++ commons/proper/commons-parent/trunk/src/changes/changes.xml Wed
Sep 19 08:06:17 2018
@@ -61,6 +61,7 @@ The <action> type attribute can be add,u
<body>
<release version="48" date="YYYY-MM-DD" description="TBD">
+ <action issue="COMMONSSITE-124" type="fix"
dev="britter">Revert change in commons.scmPubUrl in Parent
47</action>
<action type="update">Update parent from
org.apache:apache 19 to 20.</action>
<action type="update">maven-compiler-plugin 3.7.0 ->
3.8.0</action>
<action type="fix">re-enabled japicmp and introduced
japicmp.skip property that
---------------------------------------------------------------------
Post by Rob Tompkins
Post by Rob Tompkins
Post by Gilles
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@commons.apache.org
For additional commands, e-mail: dev-***@commons.apache.org
Gilles
2018-09-20 13:31:42 UTC
Permalink
Post by Rob Tompkins
Post by Benedikt Ritter
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.
<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
Post by Rob Tompkins
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
Post by Benedikt Ritter
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@commons.apache.org
For additional commands, e-mail: dev-***@commons.apache.org
Rob Tompkins
2018-09-21 12:52:37 UTC
Permalink
Post by Gilles
Post by Benedikt Ritter
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.
<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
Post by Gilles
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>
Post by Benedikt Ritter
[...]
---------------------------------------------------------------------
Gilles
2018-09-21 13:05:43 UTC
Permalink
Post by Gilles
Post by Rob Tompkins
Post by Benedikt Ritter
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.
<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
Post by Gilles
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
Post by Rob Tompkins
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>
Post by Benedikt Ritter
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@commons.apache.org
For additional commands, e-mail: dev-***@commons.apache.org
Gary Gregory
2018-09-21 15:26:07 UTC
Permalink
Post by Rob Tompkins
Post by Gilles
Post by Benedikt Ritter
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.
<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}
Post by Rob Tompkins
Post by Gilles
</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.
Post by Rob Tompkins
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. 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 sincerely believe that we are all
trying to make Commons better. 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. 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.

Gary
Gilles
Post by Rob Tompkins
@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
Post by Gilles
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>
Post by Benedikt Ritter
[...]
---------------------------------------------------------------------
Rob Tompkins
2018-09-21 15:32:38 UTC
Permalink
Post by Gary Gregory
Post by Rob Tompkins
Post by Gilles
Post by Benedikt Ritter
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.
<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}
Post by Rob Tompkins
Post by Gilles
</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.
Post by Rob Tompkins
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. 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 sincerely believe that we are all
trying to make Commons better. 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. 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.
I’ll try to over the next few days sort this out across all the projects consuming cp 47 so that we don’t see this problem again.

-Rob
Post by Gary Gregory
Gary
Gilles
Post by Rob Tompkins
@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
Post by Gilles
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>
Post by Benedikt Ritter
[...]
---------------------------------------------------------------------
Gilles
2018-09-21 23:14:50 UTC
Permalink
Post by Gary Gregory
Post by Benedikt Ritter
On Sep 20, 2018, at 9:31 AM, Gilles
Post by Rob Tompkins
On Sep 20, 2018, at 3:10 AM, Benedikt Ritter
Hello,
Reverting this change was discussed here [1]. It was a result
of
Post by Rob Tompkins
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
Post by Rob Tompkins
the
websites have the commons prefix (e.g. commons-math).
I just restored the old (working) behavior. I'm fine with
making
Post by Rob Tompkins
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
Post by Rob Tompkins
of
discussion let our project.artifactId=commons-something where N
represents the major version of the release with N being the
empty
Post by Rob Tompkins
string for a major version equal to 1. We still are stuck with
half
Post by Rob Tompkins
of
our projects in one state for building with
componentid=something
Post by Rob Tompkins
and
the other half with componentid=somethingN. Furthermore we need
a
Post by Rob Tompkins
properties representing both “something” as well as “somethingN”
given
that we have our dist urls and site urls not containing the
major
Post by Rob Tompkins
release version.
<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}
Post by Rob Tompkins
</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.
Post by Gary Gregory
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.
Post by Gary Gregory
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).
Post by Gary Gregory
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]?
Post by Gary Gregory
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
Post by Gary Gregory
Gary
Post by Benedikt Ritter
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
Post by Rob Tompkins
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-***@commons.apache.org
For additional commands, e-mail: dev-***@commons.apache.org

Loading...