On Wed, 13 Nov 2019 at 15:12, Gilles Sadowski <gillese...@gmail.com> wrote:
> 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. Obviously it is not ideal that the new CP did not work for every component. But it did not make the situation worse. And the next version of the CP can hopefully fix the breakage. > Which entails duplication, and is contrary to having a *shared* > configuration (where improvements benefit everyone). > > Of course. > - 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. > In which case we should formally vote on CP releases. Ideally of course CP updates should always be improvements. There are lots of different combinations of component setups, so it's very difficult to ensure that changes will always be positive. However, given that there is no need to use a particular CP version, this is not an issue. That's why we were able to adopt a lazy vote for the CP. Think of a new CP version as similar to a release candidate. If it does not work, then it is not adopted. Perhaps a Jenkins job could help assessing the impact of a using > an alternative CP (?). > > Feel free to set one up. I think it would be really difficult (followups if any to a separate thread please) 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 > >
