On 05/06/2017 10:15 AM, André Malo wrote:
The libs are coupled with the build files (ant files and stuff). Thatswhy they are together. The Separating them creates the same issue again, I'd say.
A one-way dependency to an abstraction (like the Xalan-J API) is fine in my book. Coupling back the other way -- not so much. Libraries shouldn't be tightly coupled to clients, and that's what we have now with deps.xml, allmodules.pl, et al.
I'm still not getting what exactly do you want to move
I'm not proposing moving anything right this instant. But ideally, anything that hardcodes references to the httpd repo belongs in the httpd repo. Scripts that are truly designed to be general-purpose can be refactored to take arguments from the client (httpd) and stay in lib/. Anything that isn't actually general-purpose (e.g. deps.xml) gets moved.
and what problem we're actually trying to solve.
As long as you keep tightly-coupled components in lockstep, there won't be a visible problem. The "problem" is the tight coupling itself, which causes maintenance headaches and bugs if the two sides get out of sync for whatever reason.
For this particular change, if someone forgets to update their build directory and changes an <override> tag, there won't be any error message. But the new override index will silently fail to be updated, and an incorrect index will be checked in. Not great for a piece of security-related documentation.
Branch compatibility is what I got so far. Is that a real problem?
As it stands, we have to ensure that the same dependency list and the same build machinery applies correctly to all branches. That requirement isn't giving us any benefit, as far as I can tell. As for whether it's a "real" problem... well, it doesn't seem to have bitten us yet. But I prefer being proactive when it comes to architecture.
Again, though: it's not like I'm jumping into massive code upheaval starting tomorrow. I just want to get a feel for why things are this way, and if it's due to deliberate design or if it's just how things fell out, and then I'll put it on my ever-growing list of TODOs.
--Jacob --------------------------------------------------------------------- To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org For additional commands, e-mail: docs-h...@httpd.apache.org
