lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [lucenenet] Shazwazza commented on issue #282: Docs - Build/Deploy Automation
Date Thu, 28 May 2020 14:25:06 GMT

Shazwazza commented on issue #282:
URL: https://github.com/apache/lucenenet/issues/282#issuecomment-635382437


   > I noticed that the documentation on the beta-00008 file is now linking to the wrong
document (looks like it was the right document in the beta-00007 document).
   
   Will be some annoying issue with namespace project changes from before to now and not tracking,
i'll have to track it down and fix. The fix will be part of the conversion tool to put files
into the right places.
   
   > and breadcrumbs (that are pointing to the test framework).
   
   Due to so many overlapping namespaces breadcrumbs can be annoying it's a known issue with
docfx and I haven't heard a reply from them. If/when we think it's important enough we'll
probably have to write javascript to fix, see https://github.com/dotnet/docfx/issues/2041#issuecomment-328394103
   
   The rest of your info is stuff that we need to do and figure out. Before we consider doing
that we need to ensure the files are in the right places (i.e. not all of them are as you
have seen from the Codec thing, but i worked on this for a long time so it there's probably
very few that are incorrect. The problem is that so much of this was entirely changed again
2 versions ago so i had to re-map everything). 
   
   But yes at the end of the day it's going to be much easier for us to just change the converted
files and commit then, just means we'll need to figure out a way to re-execute the conversion
docs and merging new changes. Keep in mind that we may end up needing to re-run the conversion
tool because even after we've started manually editing files even before another major because
we may discover that a ton of markdown has been converted incorrectly due to the source java
files being very odd. This has happened frequently in this process because the java docs are
so inconsistent. But maybe we deal with that on a case by case basis, i don't think there's
going to be a magic way of automating the re-merge. Only feasible thing i can think of is
to save the automated docs to a 'baseline' (possibly a git branch). Then we edit all the files
we want to and if we need to re-execute the conversion tool, we do so on the baseline git
branch and merge that forward to ours. Might work.
   
   Docfx also has something called 'overwrite' files which I was going to use for namespace
docs that weren't converted from javadocs, this also means we wouldn't need to worry about
them re-overwriting our files. I just haven't go to this stage of the process yet.
   
   > So, in the near term, where is the best place to put the new namespace documentation
for Codecs?
   
   First i need to fix the codec mappings. Then the javadoc file that you can edit will exist
here `/src/Lucene.Net/Codecs/package.md`
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



Mime
View raw message