Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a new htmlparser-xom repository for the htmlparser.xom package? #25

Closed
carlosame opened this issue Jul 6, 2020 · 1 comment · May be fixed by #43
Closed

Create a new htmlparser-xom repository for the htmlparser.xom package? #25

carlosame opened this issue Jul 6, 2020 · 1 comment · May be fixed by #43

Comments

@carlosame
Copy link

carlosame commented Jul 6, 2020

PR #23 includes a modularization patch that has a dependency on XOM. Initially, the patch had a strict dependency on nu.xom, but as the result of a comment from @anthonyvdotbe I changed the requirement to static (i.e. optional). This is the most conservative thing to do right now but otherwise is formally wrong (because XOM objects are part of this library's public API) and defeats the purpose of a full modularization (the current setup is mostly equivalent to an automatic module name).

As a better solution, I suggest splitting the htmlparser.xom package to a different repository, and ship it as a different artifact (with different release cycles). As I believe that patches are better than words, I created that repository here:

https://github.com/carlosame/htmlparser-xom

and a xom-removed branch that removes the XOM support from htmlparser (it starts from my validator-nu branch that has the modularization patch):

https://github.com/carlosame/htmlparser/tree/xom-removed

A possible alternative would be to convert htmlparser to a modular Maven project (with a single Git repository but two artifacts being also created), however that would complicate the workflow for little to no benefit, and expose the project to a new category of Maven bugs (I mean bugs affecting modular builds only).

Thoughts?

@carlosame
Copy link
Author

It was decided against this in #26 (comment), so closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant