Hi Murray, <snip/>
> > Why introduce then the first option? Because that would be the way to go > > with > > I'm guessing you had to take a typing break here. :-) > that would've been "next section" > > ............................................................................... > > (2) Filters > > > > Not surpringsily, filter execution is handled by the different methods on > <snip/> > > extract the event package to its own jspwiki-event maven module, and > > create a jspwiki-api > maven module. This module would contain the full > > public API, although right now only part of it would be used (Engine, > > Session and maybe a few more classes), so it can be discussed and > reasoned > > around with a more clear focus. > > Having been I seem to remember the one who wrote the original event handler > it's remarkable how many times I've reused that code for other projects, so > having it pushed over into a public API is a good thing. > In fact, it'll be in its own maven module, and completely independent from JSPWiki code, i.e., you'll be able to import the dependency and use the event subsystem on any other project without bringing in any more JSPWiki related code. Its only dependencies are commons-lang3 and log4j, IIRC. The public api maven module will bring the event subsystem as a dependency. <snip/> > > JSPWiki API hasn't changed in ~7 years. A minor release after introducing > > the public API (that is on 2.12.0 or 3.1.0, whatever we see fit) I plan / > > like to remove the backward compatibility introduced above, as it also > > means more complexity on the code base. That would be a breaking change > > in the API in about 8-9 years, which I don't find completely > unreasonable. > > > > thoughts? > > I think this is entirely reasonable, if that change were to occur in a year > or two. I would suggest that after things settle we all look at the > additional complexity required by the adapter/facade classes that permit > the plugins to continue to work and consider that rather than kill that off > after some period of time, that rather than that consider moving that code > off to its own sub-project so that people could install that jar file to > continue to use the older plugins. Iff that's a reasonable proposition. > haven't thought of that, but moving this code to its own maven module sounds like a great idea. I wouldn't mind if the code inside that module ends up being messy, because the rest of the code would not. Also, problems like having two parallel classes on different packages (like SearchResult or QueryItem mentioned earlier) would also be solved, as adapter-related code would not interfere with the rest of the codebase, and the use of duplicated classes would be reduced to calls to the 2.11 pre API and transforming between those classes and their doppelgangers. I wouldn't mind then having this module around as long as it useful, as opposed to remove it from the main module a minor release after the public api is released. <snip/> > But *typically* management don't see infrastructure as so high a priority > as new features. And support systems like wikis are pretty much at the > bottom of that priority list. They just want them to keep ticking over. > <snip/> I agree, but it is also highly unusual to have free effort/cost upgrades, for any software. If an end user / administrator gets a free effort/cost upgrade for a given software, then that cost of upgrading is translated to that said software. Also, for a company or an administrator, wanting to update some software, but not its related, custom code seems weird to me (not that I don't have seen it). In the case of JSPWiki customizations, I understand its different, because that cost of upgrade is translated to the plugin/filter/page provider mantainers, and suddenly having to keep track of what version of a plugin is compatible with which version(s) of JSPWiki is a PITA. Closing up, Jürgen, Murray, thanks for chiming in on this thread, I think that JSPWiki will become better because of it. best regards, juan pablo
