Hi. Le mer. 22 janv. 2025 à 14:29, Gary Gregory <garydgreg...@gmail.com> a écrit : > > On Wed, Jan 22, 2025 at 8:00 AM Gilles Sadowski <gillese...@gmail.com> wrote: > > > > Hi. > > > > Le mer. 22 janv. 2025 à 13:12, Gary Gregory <garydgreg...@gmail.com> a > > écrit : > > > > > > It's unclear to me if we need the PMC's approval for this. We > > > certainly did not vote on it. > > Well, I certainly would like to know exactly what is proposed here.
I gave quite a few directions. If I knew _exactly_ I would have precise proposals... > Does this affect one component, all components, if not all components, > which components? All. The purpose is to have a _one_ stop (one command/one maven target) to generate the whole TLP site, at any time (whether it's for a release candidate or a simple update after correcting a typo in a "template", or in a layout engine, or within static contents). > > > > Well, this thread is meant to gather opinions about this. > > No need to vote if there is a clear argument, one way or > > the other. > > > > > It just looks like busy work to me for > > > little to no gain. > > > > For one, the caveat[1] when a release candidate is being > > put to the vote that says something equivalent to "some > > parts of the site don't work, but all will be fine (at some point > > in the future)" is something that's worth fixing IMHO. > > I think the only site link that doesn't work is the download*.cgi > link. Do you know of other links? There were others for sure. I've not prepared a release for quite some time, and in my latest attempts, I did not care too much about the web site (because it is a task that should be made orthogonal to a release). > > > > Also, you mentioned one path of progress, that is (IIUC) for > > the web site contents to be the aggregation of the > > components' Javadoc-generated files. > > I did not mention this in this conversation. Still, years ago I did > mention somewhere that it would be nice to have a Javadoc site for all > of Commons in addition to the Javadocs for individual components, > especially considering Javadoc's search box feature. My first impression is that <whatever> feature should be modular (meaning targeting each component separately). So that for example someone could easily make a local copy (e.g. through "wget") and have a fully functional (local) web site of a single component. Then some aggregation code/tool/whatever would allow global search. > What I did mention last week is the desire to migrate a component's > documentation from its site into its Javadoc, like Apache Juneau and > Commons BeanUtils. Sure, that's what I was referring to. I also already mentioned that it would be one of the tasks of the GSoC project (e.g. through a migration script). As Piotr said, it's a lot of work, and obviously not worth redoing by every maintainer of a component, each in his own way > > > So somewhere (in which "...-plugin"?), code would generate > > a "staged" website (from the release candidate functional > > and easily comparable to the "live" one. > > > > > Refactoring is not just about moving things or updating the > > CSS (or equivalent) style sheet. > > It could potentially lead to new functionality to be potentially > > more easily added, e.g. a "search box" whose results would > > point to the relevant parts of the Javadoc (just an idea; I've > > no clue how to do that). > > Javadoc sites include a search box, which is nice but only matches > type and method names IIRC. OK, so it would yet another "little" thing that "would" be "easy" to "tack" onto the existing site. It would still not be much better. To be clear(er), I've no personal stake in this because I do not actually use the website; I only care for the (not really good) image which the site gives of the projects. If we could get some interested web developer doing the upgrade, it looks like a huge gain. I really don't get how our respective perceptions could be so different. Maybe what you and I could agree (?) is to go the opposite direction, that stop trying to support a subpar website, and keep only the bare minimum requirements such as * a download page, * the javadoc-generated set of HTML files posted to some public repository. We thus simplify the common POM file to generate the reports in the most suitable format for the RM and reviewers. Gilles > > > > The web site is for _users_. The current one offers barely > > any added value (over reading the source in a pager). > > [By far, the most time I spent looking at it was while preparing > > a release candidate. And even then it was mostly to look at > > reports, whose contents could as well have been collected > > in a bunch of ASCII files. Users are mostly not really > > interested in reports (like RAT, source code management, > > Junit, Jacoco, CheckStyle, SpotBugs, PMD, CPD), only > > people who check the release candidate are.] > > > > Regards, > > Gilles > > > > [1] That existed for as long as I've been here. > > > > >> [...] --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
