Hi Murray! nice to see you on the dev list again :-)
lots of interesting points on your email, my POV on them: - re. GraphReferenceManager: I fail to see how it works, would you mind sharing a concrete example? it is not clear to me if it needs a syntax change or not, or if the current syntax would be used for a different meaning? Would making the reference manager more "pluggable-friendly" (i.e., selecting the implementation through a property file instead of using classmapping-extra.xml) something helpful for you? You also mention some possibility of an unsynchronized set of links on DeafultReferenceManager, would you mind ellaborating a bit on it? If it's fixable, I'd like to address it, rather than dropping the de/serialization, it helps with faster startups on large wikis. - re. JGraphT, I've checked their repo and it's dual-licensed under EPL 2.0, so it could be brought as a dependency; maybe it would need a note on the NOTICE file, but that should be all, I've to check that license on detail to see what it requires to be used. However, that dependency requires Java 11 to run, so as of today, on the convenience binaries, the GraphReferenceManager and associated classes would not be shippable with the main war. Which leds me to the next point - re. Java 11: probably deserves an specific thread on itself, but right now there aren't specific plans for it. Which does not mean we're not tkaing that into account.. Given the pace of the JDK releases may be even going to JDK-17 would seem reasonable, next Java LTS is due september 2023, which is not that far. Maybe post-2.11.3 release seems like a good moment to discuss this topic? - re. Lombok, would be +1 from me - re, plugins and graph reference manager package: if you plan to include them on JSPWiki :-) then the org.apache.wiki package should be the way to go, would be their final package in any case. cheers, juan pablo On Fri, Jul 22, 2022 at 4:16 AM Murray Altheim <murra...@altheim.com> wrote: > Hi, > > I've been busy on my own projects but under the neocortext.net domain I > will possibly soon be releasing some open source code, mostly related to > digital libraries and ontologies. But there is some JSPWiki related code > as well, as I've been incorporating JSPWiki into some of this other work. > > I'm working on a potential replacement DefaultReferenceManager. My first > iteration proved not different enough from the existing code to warrant > the update; yes, it removed some of the strangeness (and eliminated the > serialization/deserialization, which I didn't find useful and created the > possibility of an unsynchronized set of links), but I didn't find it very > elegant, mostly just a cleanup but no real innovation. > > So rather than using Sets or Maps, I thought a better and certainly more > interesting approach would use JGraphT to implement a proper graph > structure > of links between Pages, Attachments, as well as external links. With some > default predicates that could be expanded so that wiki links could take the > form of subject-predicate-object, i.e., actual tuples. The implementation > is > called GraphReferenceManager. > > A link in this system could look like: > > [Object] # where 'Object' is the target page, the > implicit 'Subject' being the page > containing the link (typical existing link) > [Predicate|Object] # where 'Predicate' expresses the meaning of > the link. Such predicates are wiki pages, > with the three existing links hardwired: > inter-page, attachment, and external links > [Subject|Predicate|Object] # frees the link from its parent page, so > links could be expressed anywhere > > I wouldn't introduce any changes to the link parser at first, so this > extended syntax is only a proposal, and the GraphReferenceManager doesn't > conceptionally require the syntax changes, i.e., I'd use hardwired values > for the predicates until such point as predicates were supported in wiki > syntax. > > This work raises some questions: > > 1. would anyone have any issues with introducing JGraphT into the > JSPWiki > set of dependencies? > > 2. would anyone have any issues with introducing Lombok into the JSPWiki > set of dependencies? I'd rather use factories and builders than > constructors, and would also like to avoid explicit getters and > setters. Something like a DSL might be nice. > > 3. at what point is it planned to bump JSPWiki from Java 8 to say, > Java 11? For my day job I've been doing a fair bit of remediation > work > on legacy apps, bumping them *up* to Java 8. But the number of > features I've grown accustomed to in Java 11 makes these features a > bit painful to lose. > > 4. would the team prefer I develop the reference manager under the > org.apache.wiki.* package or under my own (net.neocortext.wiki.*)? > > ---- > > I've also got a couple of JSPWiki plugins, e.g., a QR code plugin, that > are close to ready for usage/testing. > > Also my wiki TagManager and associated tag plugins (Tag, Tags, HasTagOf) > have been in use now for I suppose over a decade now on various wikis, so > perhaps the team might be interested in incorporating a tagging > functionality into the Apache code, or I can release it under my own > package name as I have in the past. > > Good to see JSPWiki still ticking along, with a new release coming up! > > Cheers, > > Murray > > ........................................................................... > Murray Altheim <murray18 at altheim dot com> = = === > http://www.altheim.com/murray/ === > === > = = > === > In the evening > The rice leaves in the garden > Rustle in the autumn wind > That blows through my reed hut. > -- Minamoto no Tsunenobu > >
