-
Notifications
You must be signed in to change notification settings - Fork 41
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
[DOXIA-722] Optionally create anchors for index entries (used in TOC macro) #180
Conversation
b2eab0c
to
66ae55b
Compare
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/NamesForIndexEntriesSinkWrapper.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Putting the wrong JIRA issue aside...I am not convinced (convoluted at first glance) by this for several reasons:
- I consider it a conceptual flaw that a macro can manipulate a parser, I had the same idea and dumped it
- This seems like a reimplementation of
RandomAccessSink
: The RandomAccessSink provides the ability to create a {@link Sink} with hooks. Why not evaluate it if it there. - This should not be related to the TOC macro although the TOC macro will benefit. A user can request auto anchors regardless of the TOC macro. Don't conflate them.
- I think that a solution should be logically identical to
org.apache.maven.doxia.parser.Parser.setEmitComments(boolean)
. A parser feature will intercept section title text and buffer untilsectionTitle_()
is hit, anchor and title (heading) are emitted.
doxia-core/src/main/java/org/apache/maven/doxia/macro/MacroRequest.java
Outdated
Show resolved
Hide resolved
I was not aware of this class, but
For me the TOC is the primary use case, but I am ok with always generating anchors and TOC macro will just use those.
As long as the default is "emit anchors for every section title" I am fine with adding an option to disable that. I don't think we should make that an opt-in behaviour as that would be breaking change from a user's perspective. |
I don't see need to modify/intercept the sink at all, a parser can do this perfectly with some buffering.
Correct, TOC will use what has been generated, therefore a parser switch...
Well, making it default would be breaking because Apt, for example does not have implicit anchors. What I see is tht the opt-in will be enabled from the Maven Site Plugin invocation and not Doxia directly. That will cover your use case and won't break anything for others. |
The point is that a sink wrapper can be used with all parsers, while buffering on parser level has to be implemented per parser. |
Are you certain about this? Can't this be done in the |
66ae55b
to
0bebc8c
Compare
doxia-core/src/main/java/org/apache/maven/doxia/parser/Parser.java
Outdated
Show resolved
Hide resolved
doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractParser.java
Outdated
Show resolved
Hide resolved
doxia-core/src/main/java/org/apache/maven/doxia/parser/SinkWrapperFactory.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One last nit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is fine for me now. I cannot come up with a better solution in reasonable time. Before this get merged I'd prefer that @hboutemy will also take a look as well. This is a lot of code and needs eyes. Give him some time.
doxia-core/src/main/java/org/apache/maven/doxia/index/IndexEntry.java
Outdated
Show resolved
Hide resolved
@kwin Please rename with a proper DOXIA JIRA issue. Maybe it would even make sense to split up in (a) Wrapper Factory approach and (b) Auto Indexer Feature |
doxia-core/src/main/java/org/apache/maven/doxia/index/IndexEntry.java
Outdated
Show resolved
Hide resolved
doxia-core/src/main/java/org/apache/maven/doxia/index/IndexEntry.java
Outdated
Show resolved
Hide resolved
ca72f70
to
921d2f4
Compare
@Override | ||
public int getPriority() { | ||
// should come last (after potential preprocessing/modification of anchor names) | ||
return -1000; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does using Integer.MIN_VALUE
make sense?
@hboutemy Are you able to review within a week or so? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we somehow check it based on our maven-site and the doxia converter?
Doesn't affect Doxia Converter, for checking with m-site-p you need a patch for m-site-p and m-doxia-sitetools (see some WIP PRs in https://issues.apache.org/jira/browse/MSITE-1000 and https://issues.apache.org/jira/browse/DOXIASITETOOLS-322). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The the actual change is perfectly fine, this needs a new JIRA issue because it does not really solve DOXIA-710 because we cannot solve the problem within the skin.
Please create a new issue and change the commit message. It can only solve external linking and interplay between TOC macro and the content itself.
1c2cf8a
to
4518d58
Compare
|
See my request to rephrase the the issue summary/title. |
I renamed the JIRA title, the commit message should be fine already. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good work. Let's merge!
Introduce SinkWrapper concept
Enforce anchor name uniqueness across documents
Some preliminary documentation in apache/maven-doxia-site#30.