Le mer. 13 nov. 2019 à 15:52, sebb <seb...@gmail.com> a écrit : > > On Wed, 13 Nov 2019 at 14:38, Gilles Sadowski <gillese...@gmail.com> wrote: > > > Hello. > > > > Le mer. 13 nov. 2019 à 14:49, sebb <seb...@gmail.com> a écrit : > > > > > > +1 for CP > > > > > > CP versions are entirely optional; > > > > Not "entirely". [We already had this discussion.] > > It happened that a fix for <something> was available in a newer CP but > > that <something else> in CP broke some components (e.g. when CP > > functionality is "enhanced" based on assumptions not valid for all > > components). > > Then, that *suddenly* unsupported component has to cherry-pick and > > duplicate (in its local POM) what exists in that newer CP which it cannot > > use anymore. > > > > > The newer version was still optional. > > By which I mean that it does not affect components that do not choose to > use it. > Also if a particular version is problematic, it can be ignored by all > components. > > In the case above, the newer CP version was faulty: it fixed some things > and broke others. > > Components that were affected by the breakages still had the choice to > continue with the previous version.
Yes, at the cost of having to fix/duplicate functionality that was delegated to CP which now breaks that "promise". > They were no worse off than before It has happened, that an upgrade to a newer CP was *necessary*; for example, to get the new version of a plugin (and this plugin had been handled in CP). Now, if the CP that provides the new version broke something, then the plugin must now be handled at the component level. Which entails duplication, and is contrary to having a *shared* configuration (where improvements benefit everyone). > - but of course the new version did not > help them either. The point is that a CP upgrade should *not* be allowed to break existing components that rely on the last released version. Perhaps a Jenkins job could help assessing the impact of a using an alternative CP (?). Gilles > > > > > a new version is only used if a > > > component chooses to use it. > > > > > > Is this also true of commons-skin? > > > If so, then +1 > > > > > > If not, then extra care needs to be taken to ensure backwards > > compatibilty. > > > There should probably be a formal vote on the actual changes in that > > case. > > > > > > > > > On Wed, 13 Nov 2019 at 13:32, Alex Herbert <alex.d.herb...@gmail.com> > > wrote: > > > > > > > The recent release of RNG has highlighted some issues with the commons > > > > parent configuration for multi-module builds and a desirable change to > > > > commons skin. > > > > > > > > 1. [parent] JaCoCo aggregate reports are included. > > > > > > > > Aggregate reports show coverage of dependencies. Since most commons > > > > components are stand-alone this should be disabled and the report set > > > > updated to have non-aggregate reports. > > > > > > > > An example of the output is shown for the recently release BCEL: > > > > > > > > https://commons.apache.org/proper/commons-bcel/project-reports.html > > > > > > > > The aggregate report is empty. > > > > > > > > > > > > 2. [parent] japicmp does not allow clean opt-in > > > > > > > > The japicmp maven plugin is immature. If set to skip the report it > > still > > > > creates a menu entry in the site reports page. See this release of > > > > Collections: > > > > > > > > > > https://commons.apache.org/proper/commons-collections/project-reports.html > > > > > > > > The link for the japicmp report is a blank page. > > > > > > > > > > > > For collections this could be fixed by running the report. > > > > > > > > For a multi-module build using japicmp any module with no code (i.e. a > > > > pom) has this empty entry if japicmp is enabled as the skip > > > > functionality does not work. > > > > > > > > > > > > The solution is to move the reporting section from the main > > > > configuration into the japicmp profile. This allows opt-in on a > > > > per-module basis to japicmp. > > > > > > > > > > > > 3. [skin] Customisation of the site <head> section > > > > > > > > RNG uses formulas in the site documentation. Ideally this would be > > > > rendered latex using MathJax [1]. > > > > > > > > This cannot be included in the site descriptor for the project as the > > > > <head> entry for each page is generated by commons-skin. This adds > > > > javascript to allow pretty print of code inside <pre "prettyprint"> > > > > tags. I would like to add a javascript tag to allow inclusion of > > MathJax. > > > > > > > > > > > > I have rendered the RNG site using these changes and staged it here: > > > > > > > > mvn package site site:stage -Dcommons.release.version=1.2 > > > > -DcomparisonVersion=1.2 > > > > > > > > https://home.apache.org/~aherbert/commons-rng-1.4-site/index.html > > > > > > > > > > > > Top level reports page does not have japicmp: > > > > > > > > > > https://home.apache.org/~aherbert/commons-rng-1.4-site/project-reports.html > > > > > > > > Components do: > > > > > > > > > > > > > > https://home.apache.org/~aherbert/commons-rng-1.4-site/commons-rng-simple/project-reports.html > > > > > > > > (There are also no jacoco aggregate reports.) > > > > > > > > > > > > You can view how MathJax is rendered on this page: > > > > > > > > https://home.apache.org/~aherbert/commons-rng-1.4-site/developers.html > > > > > > > > (search for 'will render an in-line formula') > > > > > > > > > > > > AFAIK an update to commons-skin to include MathJax will not effect > > sites > > > > that do not contain the \( or \[ characters in plain text on site > > pages. > > > > > > > > > > > > I propose to: > > > > > > > > - Update commons-skin to add a MathJax script to the <head> section > > > > > > > > - Release commons-skin (last release was May 2015) > > > > > > > > - Update commons-parent: > > > > > > > > - Use the new commons-skin > > > > - Remove JaCoCo aggregate reports > > > > - Reconfigure japicmp for clean opt-in > > > > > > > > > > > > Alex > > > > > > > > > > > > [1] https://www.mathjax.org/ > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
