On Wed, 22 Jan 2025 at 14:40, Gilles Sadowski <gillese...@gmail.com> wrote: > > 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).
It must be possible to release updated component sites as well, without needing to rebuild everything. > > > > > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
