Also, if someone is thinking about doing this, they better be ready to take on updating and testing our Maven Commons Release Plugin which checks in the site and deliverables to Subversion.
Gary On Sun, Jan 19, 2025 at 6:35 PM sebb <seb...@gmail.com> wrote: > > On Sun, 19 Jan 2025 at 17:28, Piotr P. Karwasz > <pi...@mailing.copernik.eu> wrote: > > > > Hi Gilles, > > > > On 19.01.2025 14:30, Gilles Sadowski wrote: > > > Hi. > > > > > > Le sam. 18 janv. 2025 à 19:14, Piotr P. Karwasz > > > <pi...@mailing.copernik.eu> a écrit : > > >> The changes in `logging.apache.org` took close to 1000 work hours (2 > > >> developers for 3 months) and were financed by the Sovereign Tech Fund > > >> (now Agency). Commons has also several critical projects, so we could > > >> apply for one of its programs. > > > It's clear what "Log4J" does; I'm pretty sure that there won't be > > > a consensus here about what the scope of "Commons" is. My > > > impression is that it would be difficult to explain what the funding > > > will be used for. > > > E.g. they may not be interested in rarely used components; > > > but does that make them less "critical"? > > > A slick website is "nice" but not really "critical" (as long as it is > > > not tampered with). > > > Of course, I'm certainly not opposed to someone trying to get > > > resources to do <something>. > > > > In general most Commons projects fulfill the criteria for funding, while > > `commons-lang`, `commons-io` and `commons-codec` are on multiple lists > > of critical Open Source projects. It would be mostly up to us to define, > > which changes in Commons are most needed and to translate those changes > > in well defined milestones and funding needs. > > > > [1] https://www.sovereign.tech/programs/fund#criteria > > > > > I was going to ask "why Asciidoc", but most of the answers is there > > > https://asciidoc.org/#about > > > > > > A primary question is then: Do we want to normalize the "Commons" > > > documentation so that all components use "Asciidoc"? > > Personally I don't have a preference between markup languages, as long > > as we use the same markup language for all the documentation. Using > > Javadoc as Gary suggests is fine with me too. > > >> 3. Replacing `maven-site-plugin` with Antora can reuse the work done in > > >> Log4j. > > > I don't know what "Antora" is. But if "Log4J" did the work already and > > > people are happy with the result, it's a strong incentive to indeed follow > > > that path. > > > > Antora[2] is a static website generator that can build a website from > > multiple Git repositories/branches and helps creating cross-references > > between the different websites. > > > > In Log4j we were mostly interested in replacing `maven-site-plugin` and > > speeding up the site generation. Most reports generated by > > `maven-site-plugin` (e.g. PMD, Dependency Convergence, etc.) are not > > really useful for the general public and they slow down site generation > > considerably. > > Commons components are low level, and the audience is not the general > public, rather developers. > I think many of the reports *are* needed, for example changes, > japicmp, dependencies. > > > The same remarks apply as for the markup languages, we could have chosen > > any other website generator (including `maven-site-plugin`, if we remove > > all the reports), but we chose Antora. > > > > Piotr > > > > [2] https://antora.org/ > > > > [3] > > https://github.com/apache/infrastructure-asfyaml?tab=readme-ov-file#subdir > > > > > > > > --------------------------------------------------------------------- > > 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