Decide on the way forward

Start by reading the two architectural questions and the discussion linked from issue #25, then compare the listed module combinations and Maven repository arrangements. This issue is done only when the repository owner makes a decision on modularization and project organization; it is not a self-contained implementation task.

@hsivonen: as the de facto owner of this repository, I'd like to urge you to decide on the way forward, because I feel things are getting out of hand: @carlosame and I have different views on how to proceed, and we're both investing quite a bit of our spare time in implementing/defending our point of view. I believe that it's in everyone's interest for a final decision to be taken sooner rather than later. (I understand if modularization is not a priority for neither you nor your employer, but I believe it's not unreasonable to ask some of your time to settle this debate.)

1. Java modularization

There are plenty of options, starting from the most fine-grained modularization:

1. one module per XML API, with 2 base modules
   • htmlparser.dom -> htmlparser.common
   • htmlparser.sax -> htmlparser.common, saxtree
   • htmlparser.xom -> htmlparser.common
2. merge all htmlparser modules: htmlparser + saxtree
3. merge all modules into 1: htmlparser
4. merge all modules into 1, except the XOM module: htmlparser + htmlparser.xom
5. some other combination:
   • htmlparser + htmlparser.xom + saxtree
   • htmlparser.jaxp + htmlparser.xom + htmlparser.common + saxtree
   • ...

Q1: which combination makes most sense to you?
(edit: please note that this question is about modules as a generic software architectural concept, not about Java modules specifically. So any Java technicalities can be disregarded when answering this question. I've merely named it "Java modularization" in the title to clarify that it's about the conceptual modularization of the code, not about how the code is organized in Maven modules or Git submodules or anything like that)

2. Project organization

Assuming there's at least 2 modules in the chose combination, there's multiple options on how to organize them:

1. a single multi-module Maven project in a single git repo
2. multiple single-module Maven projects in multiple git repos
3. some other organization

(since @carlosame claimed that the first option would "complicate the workflow [...] and expose the project to a new category of Maven bugs": I claim the exact opposite, so please disregard any Maven-related concerns)

Q2: which option works best for you & @sideshowbarker?

3. upcoming releases

Edit: given that we agree that backward compatibility will be broken as needed to implement the decisions for 1. and 2., I'm fine with a 1.5 release as it is (except for the use of version ranges, but I'll argument that in the PR).

I'd like to propose that, no matter the answer to Q1 and Q2, version 1.5 is released with minimal changes, i.e. only changes that are required to resolve #17. In particular: no automatic module name, no changes to the dependency versions, ... Once 1.5 is published, we can then implement 1. and 2. as decided for a 2.0 release.

Q3: do you agree with this proposal?

Thanks in advance for reading & answering the 3 2 questions above, and thereby bringing back peace and quiet to this repository.

Edit: the comment below demonstrates exactly why I'm saying it's in everyone's interest for a final decision to be taken sooner rather than later: there's a lot of frustration on both sides, and both sides feel the other is counterworking them. That's why I'm asking you to take an authoritative decision on this matter, so we can both accept your decision and move forward on implementing it.