Michael, Thanks for the note.
I am willing to spend some time working on a solution if we can design and acceptable one. Claude On Sun, Jul 7, 2024 at 4:22 PM Michael Osipov <micha...@apache.org> wrote: > Am 2024-07-07 um 15:20 schrieb Claude Warren: > > In looking at some of the codebase it seems like the markdown processor > > could use lazy instantiation by using the init() method. However, I > don't > > see any way to pass information to the processor. > > > > Perhaps the org.apache.maven.doxia.module.markdown could have 2 > > constructors. > > > > > > 1. Takes a file as an argument and processes the file line by line > with > > each line being the name of an extension to load. > > 2. A no-argument constructor that sets up the system as though the > > configuration file contained the current list of extensions. > > > > The Maven Site plugin could then be modified to look for a hidden file in > > the markdown directory (.configure perhaps) and if present use that to > > construct the MarkdownProcessor. > > > > Alternatively, an environment variable that specifies the list of > > extensions could be used to provide the list during the static > > construction. I like the file based approach since the directory of > > markdown files would contain the configuration. > > While I need to think about this here might be a stop-gap solution: > I believe that we can use priorities for the same bean id during DI, > thus you could drop in your own impl of the parser and it would override > ours containing all the config you need. We do this in Resolver. > > @cstamas, can you shed some light on this for Warren until we can > provide something out of the box? > > Michael > > > On Mon, Jun 24, 2024 at 2:33 PM Michael Osipov <micha...@apache.org> > wrote: > > > >> I see, you are referring to > >> > https://github.com/apache/maven-doxia/blob/master/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java#L126-L165 > >> > >> One of the issue is that I personally do not know what the implications > >> might be in terms of performance, etc. Are parsers heavy weight or can > they > >> be created easily? If you have thousands of files and I had reports of > >> people that they process tens of thousands of files... > >> kwin@ has recently added a generic approach to configure a parser. I > >> think if we are going to make this non-static you should pick it up. > From > >> my PoV we need his expertise to give you a defitive answer. > >> > >> Downside: That configuration approach is available only for Doxia 2.0.0. > >> > >> Konrad, can you look into Claude's request and tell us your opinion? > >> > >> On 2024/06/24 12:46:16 Claude Warren wrote: > >>> Michael, > >>> > >>> Flexmark has a number of extensions available, but both 1.12.0 and > >>> 2.0.0-M12 use a static to create the Flexmark parser. It would be nice > >> to > >>> be able to pass a list of Flexmark extensions to be added to the > >> defaults. > >>> The only way I can see to do this is to use configuration options and > >> make > >>> the parser non-static. Would this be acceptable to you? > >>> > >>> I will start on the work but before I spend a lot of time figuring out > >> how > >>> to make it work, I want to know if the solution has a chance of being > >>> accepted. > >>> > >>> Claude > >>> > >>> > >>> On Sun, Jun 16, 2024 at 8:43 PM Michael Osipov <micha...@apache.org> > >> wrote: > >>> > >>>> Am 2024-06-16 um 15:58 schrieb Claude Warren: > >>>>> There is a standard footnote extension available from flexmark, and I > >>>> have > >>>>> a private branch of 1.12.0 that adds it. It seems to work. Is > >> there any > >>>>> reason not to add this? > >>>>> > >>>>> I want to use it for some commons collections documentation where I > >> want > >>>> to > >>>>> refer to various published papers. > >>>> > >>>> Please create a JIRA issue, the PR with a test for the feature, but I > >>>> won't merge anything into Doxia 1.x anymore because all is focused on > >>>> upcoming Doxia 2.0.0 stack. > >>>> > >>>> Michael > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>> > >>>> > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > >> > > > > -- LinkedIn: http://www.linkedin.com/in/claudewarren
