How to simply get custom content into Maven-generated index.html? - maven

In a Maven project with subprojects, each subproject gets an index.html with some content that comes from its POM's description element.
In one of these subprojects, I need that content to contain additional information, including links. There is a section of the doc that suggests I should not do it by trying to put HTML markup in CDATA in the description element (in fact, that doesn't work anyway; the HTML markup just comes out literal). Instead, it suggests there is some better way to get my own content included in the file.
While this element can be specified as CDATA to enable the use of HTML tags
within the description, it is discouraged to allow plain text representation.
If you need to modify the index page of the generated web site, you are able
to specify your own instead of adjusting this text.
Can anyone describe how to do that? I have tried several methods unsuccessfully (I can supply Markdown files with other names and they generate HTML, but a subproject's index.md has no effect on the generated index.html). I have also read about the custom element in site.xml but it seems to require writing a custom Velocity template for the site; I hope the passage "you are able to specify your own" must mean there is some method more straightforward than that.
Of course I would also appreciate a pointer into the docs if there is already an answer I have simply failed to find. (Just pointing me to docs I've already read isn't in itself helpful, though pointing out the answer I missed would be helpful, if it's there.)
In response to inquiries
Directory structure under src/site:
src/site
src/site/resources
src/site/resources/images
src/site/markdown
src/site/markdown/use
src/site/markdown/install
src/site/markdown/examples
src/site/markdown/build
maven-site-plugin version: 3.4
What I mean by 'adding a link':
The part of the index.html that comes from the POM description element
is the central content of the page (not the navigation bar, not the sidebar menus, but the actual content).
I would like that actual-content portion of the page to be able to have a paragraph or two explaining that this is a generated page for developers, and providing links (HTML <a href=...>) for people who arrived at the page from a web search but are really looking for the user-oriented pages.
I can't put that in the description element (even using CDATA), because HTML elements just come out literal. A comment below gives a link to a page on writing a whole custom Velocity template for the site, but is there honestly no simpler way to accomplish this?

I have the same issue. The only thing the generated index.html gives you of value is the list of modules. You can add your own index.md page to src/site/markdown, putting in whatever content you want. To reproduce the list of modules, include something like this:
###Project Modules
This project has declared the following modules:
| Name | Description |
|-|-|
|[Module1 name](module1/index.html)| Module 1 description|
|-|-|
|[Module2 name](module2/index.html)| Module 2 description|
Of course the text is not lifted from the POM. You also have to manually change this file if you have a new module. Not a perfect solution, but the best I could come up with.

Where I wrote:
I can supply Markdown files with other names and they generate HTML,
but a subproject's index.md has no effect on the generated index.html
it turns out the truth is more complex. In a project with subprojects,
there are two places such an index.md might go: in src/site/markdown/subproject-name of the parent project (where all of the other human-written docs for the whole project happen to be), or in a new src/site/markdown directory created within the subproject. A file with any other non-special name can be added in either place, and end up where you expect it in the target. But not for index.md, in that case only the second location can work, and even then, only after a clean.
I had tried both places without success, but trying the second again with a full clean install site site:stage makes it work. Out of the four combinations (parent/clean, parent/noclean, sub/clean, sub/noclean), that was the one I missed trying before posting the question, so of course that's the one that works. :)
If there had been an answer or comment like "hmm, are you sure an index.md in the subproject doesn't work, it works for me?" it probably would have put me quickly back on track. Sometimes after trying several avenues all without success, all that's needed is to know which of them is the one that's supposed to work (if indeed one of them is) and therefore worth spending more time on.

Related

How do I merge or even disable footnote links in asciidoc fop

I've got a rather large asciidoc document that I translate dynamically to PDF for our developer guide. Since the doc often refers to Java classes that are documented in our developer guide we converted them into links directly in the docs e.g.:
In this block we create a new
https://www.codenameone.com/javadoc/com/codename1/ui/Form.html[Form]
named `hi`.
This works rather well for the most part and looks great in HTML as every reference to a class leads directly to its JavaDoc making the reference/guide process much simpler.
However when we generate a PDF we end up with something like this on some pages:
Normally I wouldn't mind a lot of footnotes or even repeats from a previous page. However, in this case the link to Container appears 3 times.
I could remove some of the links but I'd rather not since they make a lot of sense on the web version. Since I also have no idea where the page break will land I'd rather not do it myself.
This looks to me like a bug somewhere, if the link is the same the footnote for the link should only be generated once.
I'm fine with removing all link footnotes in the document if that is the price to pay although I'd rather be able to do this on a case by case basis so some links would remain printable
Adding these two parameters in fo-pdf.xsl remove footnotes:
<xsl:param name="ulink.footnotes" select="0"></xsl:param>
<xsl:param name="ulink.show" select="0"></xsl:param>
The first parameter disable footnotes, which triggers urls to re-appear inline.
The second parameter removes urls from the text. Links remain active and clickable.
Non-zero values toggle these parameters.
Source:
http://docbook.sourceforge.net/release/xsl/1.78.1/doc/fo/ulink.show.html
We were looking for something similar in a slightly different situation and didn't find a solution. We ended up writing a processor that just stripped away some of the links e.g. every link to the same URL within a section that started with '==='.
Not an ideal situation but as far as I know its the only way.

Is there an efficient way in docpad to keep static and to-be-rendered files in the same directory?

I am rebuilding a site with docpad and it's very liberating to form a folders structure that makes sense with my workflow of content-creation, but I'm running into a problem with docpad's hard-division of content-to-be-rendered vs 'static'-content.
Docpad recommends that you put things like images in /files instead of /documents, and the documentation makes it sound as if otherwise there will be some processing overhead incurred.
First, I'd like an explanation if anyone has it of why a file with a
single extension (therefore no rendering) and no YAML front-matter,
such as a .jpg, would impact site-regeneration time when placed
within /documents.
Second, the real issue: is there a way, if it does indeed create a
performance hit, to mitigate it? For example, to specify an 'ignore'
list with regex, etc...
My use case
I would like to do this for posts and their associated images to make authoring a post more natural. I can easily see the images I have to work with and all the related files are in one place.
I also am doing this for an artwork I am displaying. In this case it's an even stronger use case, as the only data in my html.eco file is yaml front matter of various meta data, my layout automatically generates the gallery from all the attached images located in a folder of the same-name as the post. I can match the relative output path folder in my /files directory but it's error prone, because you're in one folder (src/files/artworks/) when creating the folder of images and another (src/documents/artworks/) when creating the html file -- typos are far more likely (as you can't ever see the folder and the html file side by side)...
Even without justifying a use case I can't see why docpad should be putting forth such a hard division. A performance consideration should not be passed on to the end user like that if it can be avoided in any way; since with docpad I am likely to be managing my blog through the file system I ought to have full control over that structure and certainly don't want my content divided up based on some framework limitation or performance concern instead of based on logical content divisions.
I think the key is the line about "metadata".Even though a file does NOT have a double extension, it can still have metadata at the top of the file which needs to be scanned and read. The double extension really just tells docpad to convert the file from one format and output it as another. If I create a straight html file in the document folder I can still include the metadata header in the form:
---
tags: ['tag1','tag2','tag3']
title: 'Some title'
---
When the file is copied to the out directory, this metadata will be removed. If I do the same thing to a html file in the files directory, the file will be copied to the out directory with the metadata header intact. So, the answer to your question is that even though your file has a single extension and is not "rendered" as such, it still needs to be opened and processed.
The point you make, however, is a good one. Keeping images and documents together. I can see a good argument for excluding certain file extensions (like image files) from being processed. Or perhaps, only including certain file extensions.

Can I change the root of the treeview generated by Doxygen?

Can I change the root of the treeview with a custom link instead of index.html?
Or at least add html before the treeview on the side-nav?
I think the answer is not with the vanilla Doxygen.
However, you may be able to get someway by using the '#page' documentation, which Doxygen will include before the API tree.
Doxygen also recognises '.dox' files as just containing Doxygen comment blocks - while not required for #page, these are useful where the supporting documentation is not linked to any particular source file. I've used these in the past to build the full SDK document, with background, examples, etc.
A variant is the '#mainpage', which comes first - otherwise #page entries are unordered. In the past I have modified Doxygen to order #pages by their internal name (as opposed to their title).

How do I have my plugin fire before another in docpad so I can preprocess the content?

I would like to create a plugin which preprocesses content like markdown before it is passed to marked.
I don't want to create yet another extension to tack on the filename but would rather just search for a pattern in the content and if found do a substitution before marked has a chance to render.
I tried using the render event but my plugin seems to fire after marked even though its name sorts below it. What order do the plugins get used in?
I also tried using a renderBefore event but I can't figure out how to manipulate the content from there.
Any help would be appreciated.
Thanks in advance!
Jeff
Adding a plugin.priority will affect the order in which plugins are called with greater priorities being executed first.
The default plugin priority is 500.

Diagnosing Mac Help keyword indexing?

I am having difficulty coaxing the "Help → Search" function of my application to show topics related to the useful (and unique) keywords in my application. Only one keyword shows up.
Background: I created several html help pages (examples: index, accuracy, convert) in a subdirectory of my program. If I invoke the master help, the index.html file shows up fine. From there, I can click through to any of the other topic pages.
Problem: If I try using the keyword search function, only "Accuracy" and a blank indicator (that pulls up the index.html) show up. I have other keywords like "coordinates" that should point to a specific page, but aren't showing up.
What I've done so far: In addition to re-skimming the documentation (which at this time, I am a little bleary-eyed), I have run each page through BBEdit's syntax checker. I also searched StackOverflow for information related to the problem. Because the keywords are rather ubiquitous, this was the primary topical match, but I'm well-past that.
The Help Indexer log notes that it's indexed all of the html files, finding KEYWORDS and DESCRIPTION meta tags in each (as recommended by the Help Book):
droot.html -- File has KEYWORDS meta tag content being indexed.
gc.html -- File has KEYWORDS meta tag content being indexed.
index.html -- File has KEYWORDS meta tag content being indexed.
droot.html -- File has DESCRIPTION meta tag used for abstract.
gc.html -- File has DESCRIPTION meta tag used for abstract.
index.html -- Finished parsing
droot.html -- Finished parsing
gc.html -- Finished parsing
(etc)
The *.helpindex file in the Release package (?/Contents/Resources/MacFizzyCalcHelp/ directory) is ~25k. I do not know how to inspect its contents, though.
Any thoughts on what I'm missing?
I found the following post on the Apple Support site useful when I ran into a similar problem with the Help topics of my Helpbook not appearing using the Search functions:
https://discussions.apple.com/thread/3442044
There are many reasons of problems. Once I found that apple developer documentation has a mistake (in describing anchors). Did you register help book in application Info.plist? Does help book contains own info plist file? You can check helpindex file using hiutil. I hope this help you.
I just had the issue of the blank Apple help entry and after several days of trying everything I could think of, finally found the solution. Add META NAME="ROBOTS" CONTENT="NOINDEX" to the blank entry's page (in my case it was index.html, aka the landing page or access page). I then re-indexed the HTML pages and lo, no more blank entry. No need to even delete the help viewer cache.
[Edited as tags hid content :-]

Resources