Re: 2.12.2 release?
Hi Juan Pablo, JSPWiki is largely a very stable platform, and its installation hasn't changed markedly in years. I don't know how large its installed base is, but I would prioritise security fixes at this point, both for the loyal, installed base as well as first-timers. Cheers, Murray On 10/05/24 09:30, Juan Pablo Santos Rodríguez wrote: Hi, we've been some months with a security issue fixed on master, but unreleased, so I was wondering when to release 2.12.2, the soonish the better. Right now I'd only want to look at JSPWIKI-1186, as it is related to the installer and having an issue there would leave a bad impression for first-timers trying JSPWiki. Other than that I think 2.12.2 should be ready to go, but I was wondering if anyone else wants to push something else more into 2.12.2. Thoughts? br, jp -- ... Murray Altheim= = === 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
Re: [PR] [JSPWIKI-1178] Address potential deadlock with JDK 21 Virtual Threads. [jspwiki]
Hi Juan Pablo,
Sounds like a good idea. I wouldn't mind at all but I'm sorry to say I'm
not in a situation for the next month or so (until mid-January) where I
can do any coding. Apologies.
Cheers,
Murray
On 3/12/23 22:03, Juan Pablo Santos Rodríguez wrote:
Hi Murray,
I agree, listeners should only appear on startup, if they appear later on
then there's something wrong.
It occurs to me that, in this case, perhaps replacing the listener list
with a CopyOnWriteArrayList would be enough to tackle all the synchronized
code (and the need to wrap it around Synchronizer on the PR). There are
only about 30 listeners, give or take, and they get instantiated/added on
startup, so CopyOnWriteArrayList makes sense to me in this case.
WDYT? Would you mind sending a PR with that?
cheers,
juan pablo
El sáb, 2 dic 2023, 23:53, Murray Altheim escribió:
Hi Juan Pablo,
It's been many years since I wrote that event manager and I assume there've
been many edits since, but it occurs to me that the vast majority of
changes
are made to the engine when the wiki engine is first started up. Isn't that
the case? I guess there's also the possibility of instances of listeners
popping up from its use on page-based plugins. Hmm.
In any case, I would think that we consider what the purposes of the locks
are for in the first case. Since the manager is a singleton, used by the
whole wiki engine, we'd not want it to be having its set of listeners
modified
while in the middle of processing an event. So I would tend to agree with
you that at least for 'm_listenerList' a single lock is best. On the other
hand, another approach would be to modify the event manager to be able to
simply ignore the issue, i.e., if an event comes through for a listener
that
is in the process of being added, I'm not sure what the harm is in ignoring
that. The chance of that event being tied to the new listener seems rather
remote. Dunno. We'd just need to avoid ConcurrentModificationExceptions.
[I'm somewhat embarrassed to see that at that time (about 20 years ago) I
had gotten into the habit of using Hungarian Notation in my code. I suppose
when I was doing all my coding in vi it made more sense. Now it just looks
weird to me.]
Cheers,
Murray
On 3/12/23 11:24, juanpablo-santos (via GitHub) wrote:
juanpablo-santos commented on code in PR #307:
URL: https://github.com/apache/jspwiki/pull/307#discussion_r1412879450
##
jspwiki-event/src/main/java/org/apache/wiki/event/WikiEventManager.java:
##
@@ -406,15 +429,15 @@ public Set< WikiEventListener >
getWikiEventListeners() {
* @return true if the listener was added (i.e., it was not
already in the list and was added)
*/
public boolean addWikiEventListener( final WikiEventListener
listener ) {
-synchronized( m_listenerList ) {
+return Synchronizer.synchronize(wikiEventListenerLock, ()
-> {
Review Comment:
shouldn't `m_listener` reuse the same `Lock` through the entire
class? Different locks on different operations would imply they could
execute operations on `m_listenerList` at the same time
##
jspwiki-main/src/main/java/org/apache/wiki/auth/authorize/DefaultGroupManager.java:
##
@@ -367,14 +395,18 @@ protected String[] extractMembers( final String
memberLine ) {
/** {@inheritDoc} */
@Override
-public synchronized void addWikiEventListener( final
WikiEventListener listener ) {
-WikiEventManager.addWikiEventListener( this, listener );
+public void addWikiEventListener( final WikiEventListener listener
) {
Review Comment:
should use the same lock as `removeWikiEventListener`
##
jspwiki-main/src/main/java/org/apache/wiki/WatchDog.java:
##
@@ -136,26 +154,26 @@ private static void scrub() {
* Can be used to enable the WatchDog. Will cause a new Thread
to be created, if none was existing previously.
*/
public void enable() {
-synchronized( WatchDog.class ) {
+Synchronizer.synchronize(enableLock, () -> {
Review Comment:
same as before, same synchronized object should reuse the same Lock
throughout the class.
##
jspwiki-main/src/main/java/org/apache/wiki/auth/authorize/DefaultGroupManager.java:
##
@@ -152,13 +180,13 @@ public void initialize( final Engine engine, final
Properties props ) throws Wik
// Load all groups from the database into the cache
final Group[] groups = m_groupDatabase.groups();
-synchronized( m_groups ) {
Review Comment:
converting `m_groups` to `ConcurrentHashMap` would avoid the use of
`Synchronizer`
##
jspwiki-event/src/main/java/org/apache/wiki/event/WikiEventManager.java:
##
@@ -314,35 +337,35 @@ private Map< Object, WikiEventDelegate >
getDelegates() {
* @param client the client Object, or alternately a Class
reference
* @return the
Re: [PR] [JSPWIKI-1178] Address potential deadlock with JDK 21 Virtual Threads. [jspwiki]
removeDelegates() {
-synchronized( m_delegates ) {
-m_delegates.clear();
-}
-synchronized( m_preloadCache ) {
-m_preloadCache.clear();
-}
+Synchronizer.synchronize(delegatesLockLock, m_delegates::clear);
Review Comment:
`m_delegates` could be converted to a `ConcurrentHashMap`, avoiding the
need of using `Synchronizer.synchronize`. Also `m_preloadCache` is a `Vector`,
hence thread-safe, so there's no need of syncing.. don't know why it was
`synchronized` in first place, though.
--
...
Murray Altheim= = ===
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
Re: Proposal to Implement New GitHub Actions Workflows for CI/CD
any concerns or suggestions you'd like to share? Best regards, Arturo -- ... Murray Altheim= = === 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
Re: Proposal to Implement New GitHub Actions Workflows for CI/CD
Hi, I'm not sure I see the benefit of this exactly, particularly since we do currently have a functioning build system, and the existing members here understand and have experience with Jenkins. If fulfilled we'd have a team of people with varying experience with GH actions; e.g., I myself have none, and I'd be curious if others do. Maybe I'm the outlier (and frankly I've not been very active anyway so my vote is less important). But that does raise the question: who else on the team does have experience with Github actions? So I guess I'm not against the proposal, with one caveat as described by Juan Pablo: namely, that any new build system would not replace Jenkins until *all* the steps are completed, without compromise. Until then it would remain a proposal. I know from decades' experience that with any volunteer group there is always the danger in proposals not quite fulfilling their promises. Sometimes there is an unforeseen technical or licensing barrier or impossibility, sometimes the main driver runs out of steam or has professional or personal priorities that supersede finishing, etc. etc. I tend to be rather cautious with replacing existing things that work. Cheers, Murray On 21/10/23 07:58, Juan Pablo Santos Rodríguez wrote: Hi Arturo! My 2c, I'm ok with the change, with a caveat: If we switch to GH actions, let's ditch the Jenkins build entirely, in order to not have two different build/ci systems. This implies a number of things - SQ analysis should be done from one of the pipelines, perhaps the codeql one? So it would have to be renamed to qa.yaml or something like that - Also, currently, if the ci build is successful and we have a SNAPSHOT version, we automatically deploy to repository.a.o, one of the pipelines should also take care of that, not sure which. - Last, a successful build also triggers the build on charge of deploying the static site and associated assets (javadocs, japicmp reports). IIRC, infra provides support for these actions when working with either Jenkins or GH actions, but don't have any pointer on how to do it on the latter. Of course we can keep the Jenkins build until all of these steps are completed, but always having the final picture in mind (i.e., one build/ci system). Said that a couple questions/wishes on the GH actions builds: 1) what kind of errors display the windows builds? I suspect that most probably there's a problem with the test execution order (at least that's what happened in other similar situations). Could we get a lot of any of those builds? 2) would it be possible to also run the integration tests? They can be run on headless mode, so we'd only need an additional chrome binary on the build path. Don't know if it's possible though. Thx + best regards, juan pablo El jue, 19 oct 2023, 22:08, Arturo Bernal escribió: Dear Team, I'd like to propose the addition of three new GitHub Actions workflows to enhance our CI/CD pipeline for the Apache JSPWiki project. Below are the details: 1. *Java CI Workflow*: Provides continuous integration support across multiple OS (Ubuntu, macOS) and Java versions (11, 17). It also caches Maven dependencies for optimized build times. 2. *Dependency Review Workflow*: Triggered on pull requests to review and ensure that dependencies are safe. 3. *CodeQL Workflow*: Provides continuous integration and code quality checks. These workflows are designed to automate and streamline our development process, making it more efficient. They will run on every push to the master branch and on every pull request, ensuring that our code is continuously tested and dependencies are reviewed. I've already created a pull request with these changes, which you can review here <https://github.com/apache/jspwiki/pull/299/files>. Here are the key files to be added: - CodeQL (codeql.yml) for continuous integration and code quality checks. - Dependency Review (dependency-review.yml) for dependency checks. - Java CI (maven.yml) for continuous integration across multiple OS and Java versions. I'd appreciate your thoughts and feedback on this proposal. Are there any concerns or suggestions you'd like to share? Best regards, Arturo -- ... Murray Altheim= = === 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
Re: [PR] [JSPWIKI-1178] Address potential deadlock with JDK 21 Virtual Threads. [jspwiki]
HI Arturo and Juan Pablo,
I don't disagree with anything either of you have written. I'm all in
favour of the ReentrantLock replacement via a Synchronizer pattern.
I'm only suggesting, as does both Larman/Guthrie and the quoted section
("There is no need to replace synchronized blocks and methods that are
used infrequently (e.g., only performed at startup)..."), that the
double-null-checked synchronized blocks used to protect singletons is
likely still a simpler and better practice, and there'd be little
benefit of a ReentrantLock in those cases. These are only called at
the moment when the singleton is created, i.e., once per session.
Cheers,
Murray
On 13/10/23 06:08, Arturo Bernal wrote:
Hi Murray
I'd like to clarify the main goal of my PR, which is to transition from
traditional synchronized blocks to the more modern ReentrantLocks. The
Synchronizer class is essentially a way to standardize this transition
across the codebase.[...]
.......
Murray Altheim= = ===
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
Re: [PR] [JSPWIKI-1178] Address potential deadlock with JDK 21 Virtual Threads. [jspwiki]
Hi,
My use of the synchronized block in WikiEventManager was based on a
section "Use Double-Checked Locking to Reduce Synchronization" of Craig
Larman and Rhett Guthrie's book "Java 2: Performance and Idiom Guide"*
about the use of a synchronized block on singleton classes protected by
a pair of null checks.
I have been successfully using this approach in my own software designs
since the 90s, quoting from page 100:
"Consider the example of a 'Singleton' method implementing the
Singleton pattern [GHJV 1995]. This is likely to be a high-use method,
but the critical section is in the rarely entered lazy initialization
block. It is not desirable to synchronize the method, when only a very
rarely entered block contains the critical section for which the
synchronization was required. Synchronizing the entire method adds
unnecessary overhead for all method invocations, and reduces
concurrency."
What I take from this is somewhat of a cautionary advisory not to use
this new lock-based approach everywhere in JSPWiki, that a simple double-
null check was a means to avoid a synchronized block's overhead. Use of
locks certainly does have its place -- particularly where the use of the
lock spans methods -- but the creation of a lock object, the necessity for
an additional utility method call, the potential for performance hits, and
the additional possibility of exceptions and their handling when locks
cannot be obtained, all this additional complexity might suggest that at
least for this particular use in lazily creating singletons the
synchronized keyword probably makes the most sense.
A typical existing usage of the double null check for singletons:
/**
* Returns the single instance of this class.
*
* If the singleton has already been generated it is returned.
*
*/
public static IdGenerator getInstance()
{
if ( instance == null ) {
synchronized (IdGenerator.class) { // see larman/guthrie p.100
if ( instance == null ) {
IdGenerator idg = new IdGenerator(IdType.BASE64);
return idg;
}
}
}
return instance;
}
While use of the proposed Synchronizer method might appear to be a
simplification,
public static IdGenerator getInstance()
{
if ( instance == null ) {
final ReentrantLock lock = new ReentrantLock();
Synchronizer.synchronize(lock, () -> {
IdGenerator idg = new IdGenerator(IdType.BASE64);
return idg;
}
lock.unlock();
}
return instance;
}
Under the covers the replacement for this would be akin to:
public static IdGenerator getInstance()
{
if ( instance == null ) {
final ReentrantLock lock = new ReentrantLock();
try {
if ( lock.tryLock(20, TimeUnit.MILLISECONDS) ) {
IdGenerator idg = new IdGenerator(IdType.BASE64);
return idg;
} else {
throw new RuntimeException("unable to obtain lock.");
}
} catch ( InterruptedException e ) {
throw new RuntimeException("the current thread was interrupted:
" + e.getMessage());
} finally {
lock.unlock();
}
}
return instance;
}
Though I'm entirely willing to entertain discussion to the contrary as I'm
possibly not understanding the proposal or its implementation. I'm also
sure that a book published in 1999 for Java 2 may have been superceded by
more current ideas about how to handle high performance concurrent
applications, and indeed, if anyone knows of a good book on the subject
that's up to date with JDK 21 I'd be interested in knowing about it.
Murray
*
https://www.abebooks.com/9780130142603/Java-2-Performance-Idiom-Guide-0130142603/plp
On 11/10/23 22:52, juanpablo-santos (via GitHub) wrote:
juanpablo-santos commented on code in PR #307:
URL: https://github.com/apache/jspwiki/pull/307#discussion_r1354460996
[...]
##
jspwiki-event/src/main/java/org/apache/wiki/event/WikiEventManager.java:
##
@@ -154,11 +168,13 @@ private WikiEventManager() {
* @return A shared instance of the WikiEventManager
*/
public static WikiEventManager getInstance() {
-if( c_instance == null ) {
-synchronized( WikiEventManager.class ) {
-return new WikiEventManager();
-// start up any post-instantiation services here
-}
+if (c_instance == null) {
+Synchronizer.synchronize(lock, () -> {
.......
Murray Altheim
Re: [PR] JSPWIKI-925 - Add Missing i18n Literals for Multiple Languages [jspwiki]
To be clear, in XML, comments are permitted in the XML Prolog (Production 22 in the XML spec) and the doctypedecl (Production 28), but I think the POM parser barfs on them. On 11/10/23 12:24, Murray Altheim wrote: Hi Arturo, Does there happen to be an XML comment between the declaration and the start tag? That's what the error message suggests. Cheers, Murray On 11/10/23 05:44, arturobernalg (via GitHub) wrote: arturobernalg commented on PR #312: URL: https://github.com/apache/jspwiki/pull/312#issuecomment-1755833207 @juanpablo-santos I'm encountering the following error while when the CI is running: ```[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:3.1.1:deploy (default-deploy) on project jspwiki-wikipages-en: Failed to update metadata org.apache.jspwiki.wikipages:jspwiki-wikipages-en/maven-metadata.xml: Could not parse metadata /home/jenkins/.m2/repository/org/apache/jspwiki/wikipages/jspwiki-wikipages-en/maven-metadata-apache.snapshots.https.xml: in epilog non whitespace content is not allowed but got t (position: END_TAG seen ...\nt... @12:2) -> [Help 1] ``` This isn't the first time I've encountered this issue; I faced the same error in another PR as well. Do you have any insights into what might be causing it?" ... Murray Altheim= = === 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
Re: [PR] JSPWIKI-925 - Add Missing i18n Literals for Multiple Languages [jspwiki]
Hi Arturo, Does there happen to be an XML comment between the declaration and the start tag? That's what the error message suggests. Cheers, Murray On 11/10/23 05:44, arturobernalg (via GitHub) wrote: arturobernalg commented on PR #312: URL: https://github.com/apache/jspwiki/pull/312#issuecomment-1755833207 @juanpablo-santos I'm encountering the following error while when the CI is running: ```[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:3.1.1:deploy (default-deploy) on project jspwiki-wikipages-en: Failed to update metadata org.apache.jspwiki.wikipages:jspwiki-wikipages-en/maven-metadata.xml: Could not parse metadata /home/jenkins/.m2/repository/org/apache/jspwiki/wikipages/jspwiki-wikipages-en/maven-metadata-apache.snapshots.https.xml: in epilog non whitespace content is not allowed but got t (position: END_TAG seen ...\nt... @12:2) -> [Help 1] ``` This isn't the first time I've encountered this issue; I faced the same error in another PR as well. Do you have any insights into what might be causing it?" -- ... Murray Altheim= = === 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
Re: [PR] [JSPWIKI-1178] Address potential deadlock with JDK 21 Virtual Threads. [jspwiki]
> It makes sense to start with this abstraction for the sake of code cleanliness and readability. Agreed. Implementing a single Synchronizer class across the code base means that should it need to be refactored in the future, it's straightforward to do so (e.g., in any IDE it's trivial to locate the method calls). I see no real downside in replacing all the existing usage of "synchronized" with such a solution. On 10/10/23 05:46, arturobernalg (via GitHub) wrote: It makes sense to start with this abstraction for the sake of code cleanliness and readability. ....... Murray Altheim= = === 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
Re: [PR] [JSPWIKI-1178] Address potential deadlock with JDK 21 Virtual Threads. (jspwiki)
Hi Juan Pablo,
So under the covers we'd be using a safe and approved JDK locking mechanism
in a way that can be re-implemented en masse should a new methodology arrive
in JDK 39...
Sounds good! In fact, I may rewrite my own use of ReentrantLock to encapsulate
that idea, thank you.
Murray
On 9/10/23 23:45, Juan Pablo Santos Rodríguez wrote:
Hi Murray,
broadly speaking, synchronized blocks aren't go to play so very nice
with the new virtual threads functionality, so in order to take
advantage of them, the suggeston is to switch to something else,
namely locking with a ReentrantLock
Going that way, the PR ends up having a lot of blocks like
lock.lock();
try {
doSomething();
} finally {
lock.unlock();
}
instead of having that everytime, I suggested encapsulating that block
on an utility method, so instead of that you simply end up writting
something like
Synchronizer.synchronize( lock, ()-> doSomething() );
The utility class is just to capture the idiom that is getting
repeated throughout the code, not managing or trying to enhance the
lock in any way. And of course, if later on more advanced cases of
locking/syncing appear, we can move away from the utility method, and
we also don't have to tie to it later on if it's not needed.
cheers,
juan pablo
On Mon, Oct 9, 2023 at 12:22 PM Murray Altheim wrote:
Hi,
My apologies for arriving a bit out of context, so please excuse me if this
has already been asked or addressed, but can I assume that we would be using
the existing java.util.concurrent.locks.ReentrantLock class for this? I'm
trying to understand the question better. I don't see the need for a utility
class if ReentrantLock is used, and would advise against a bespoke solution
considering the JVM is likely optimised to handle the existing class.
I'm not yet familiar with JDK 21's Virtual Threads and am just reading up
on them now.
Cheers,
Murray
On 9/10/23 22:05, juanpablo-santos (via GitHub) wrote:
juanpablo-santos commented on PR #307:
URL: https://github.com/apache/jspwiki/pull/307#issuecomment-1752606848
Hi @arturobernalg !
> However, this approach has limitations when it comes to working with
condition variables and allowing for custom scenarios. Specifically, using a
utility class for locking would make it challenging to implement more complex
control flows that involve waiting for certain conditions to be met or signaling
other threads to proceed.
>
> In essence, while the utility class would make the code cleaner for
basic locking and unlocking, it might not be flexible enough to handle advanced
locking scenarios that require the use of conditions.
I agree that more complex scenarios would fit inside this utility class.
However, the scope of the PR is to switch away from `synchronized` blocks, and
for all them we have the same idiom all over the place:
```
lock.lock();
try {
doSomething();
} finally {
lock.unlock();
}
```
So abstracting it into a common method makes sense to me. If later on a we
want to refactor or we want to capture more complex scenarios, we can move away
from the utility `synchronize` method. The utility/class method focus should be
more about synchronizing than locking (hence the names).
WDYT?
--
...
Murray Altheim= = ===
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
--
...
Murray Altheim= = ===
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
Re: [PR] [JSPWIKI-1178] Address potential deadlock with JDK 21 Virtual Threads. (jspwiki)
Hi,
My apologies for arriving a bit out of context, so please excuse me if this
has already been asked or addressed, but can I assume that we would be using
the existing java.util.concurrent.locks.ReentrantLock class for this? I'm
trying to understand the question better. I don't see the need for a utility
class if ReentrantLock is used, and would advise against a bespoke solution
considering the JVM is likely optimised to handle the existing class.
I'm not yet familiar with JDK 21's Virtual Threads and am just reading up
on them now.
Cheers,
Murray
On 9/10/23 22:05, juanpablo-santos (via GitHub) wrote:
juanpablo-santos commented on PR #307:
URL: https://github.com/apache/jspwiki/pull/307#issuecomment-1752606848
Hi @arturobernalg !
> However, this approach has limitations when it comes to working with condition variables and allowing for custom scenarios. Specifically, using a utility class for locking would make it challenging to implement more complex control flows that involve waiting for certain conditions to be met or signaling other threads to proceed.
>
> In essence, while the utility class would make the code cleaner for basic
locking and unlocking, it might not be flexible enough to handle advanced locking
scenarios that require the use of conditions.
I agree that more complex scenarios would fit inside this utility class. However, the scope of the PR is to switch away from `synchronized` blocks, and for all them we have the same idiom all over the place:
```
lock.lock();
try {
doSomething();
} finally {
lock.unlock();
}
```
So abstracting it into a common method makes sense to me. If later on a we want to refactor or we want to capture more complex scenarios, we can move away from the utility `synchronize` method. The utility/class method focus should be more about synchronizing than locking (hence the names).
WDYT?
--
.......
Murray Altheim= = ===
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
Re: [VOTE] Release JSPWiki version 2.12.1
I will be traveling for the next few days and unable to download or test the code, so with my apologies, my vote is: 0. Cheers, Murray On 8/8/23 06:29, Arturo Bernal wrote: Good Afternoon everyone, This is a release vote for Apache JSPWiki, version 2.12.1. The vote will be open for at least 72 hours from now. It fixes the following issues: https://issues.apache.org/jira/projects/JSPWIKI/versions/12353279 https://github.com/apache/jspwiki/commit/5d78b49c6a15f633813147cd7a4a4aa8a1b2cf55 You can see a curated changelog at https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.12 Note that we are voting upon the source (tag), binaries are provided for convenience. Everybody is encouraged to vote. Source and binary files: https://dist.apache.org/repos/dist/dev/jspwiki/2.12.1-RC1 Nexus staging repo: https://repository.apache.org/content/repositories/orgapachejspwiki-1031 The tag to be voted upon: https://github.com/apache/jspwiki/tree/2.12.1-RC1 JSPWiki's KEYS file containing PGP keys we use to sign the release: https://www.apache.org/dist/jspwiki/KEYS *** Please download, test and vote: [ ] +1 Approve the release [ ] 0 Don't mind [ ] -1 Disapprove the release (please provide specific comments) Cheers, -- Arturo -- ... Murray Altheim= = === 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
Re: Workflow documentation [Re: 2.12.1?]
Juan Pablo, Thanks very much, this is much appreciated. I'll take a look over this in a bit, I'm in the process of moving country in the next week or so. Cheers, Murray On 8/1/23 04:05, Juan Pablo Santos Rodríguez wrote: Hi Murray, I've drafted some doc at https://jspwiki-wiki.apache.org/Wiki.jsp?page=Workflow%20configuration It has been mostly taken from the jspwiki.properties file, but I think it's enough for starters. Please (anyone) feel free to update that page :-) cheers, juan pablo On Thu, Jun 22, 2023 at 3:12 AM Murray Altheim wrote: Hi Juan Pablo, Sorry for being out of the loop, but could you provide a reference to the workflow documentation? That would be very helpful, thank you. I've not investigated it previously. Cheers, Murray On 6/22/23 05:11, Juan Pablo Santos Rodríguez wrote: Hi, given that the workflow area is now working as expected, I'd like to release it, with the usual dependency updates and maybe PR #282, which seems pretty close to completion. Sounds reasonable? I know 2.12.0 has been released pretty close, but the workflow approval functionality seems to me like something that should be working ASAP.. WDYT? cheers, juan pablo ... Murray Altheim= = === 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 -- ... Murray Altheim= = === 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
Re: 2.12.1?
Hi Juan Pablo, Sorry for being out of the loop, but could you provide a reference to the workflow documentation? That would be very helpful, thank you. I've not investigated it previously. Cheers, Murray On 6/22/23 05:11, Juan Pablo Santos Rodríguez wrote: Hi, given that the workflow area is now working as expected, I'd like to release it, with the usual dependency updates and maybe PR #282, which seems pretty close to completion. Sounds reasonable? I know 2.12.0 has been released pretty close, but the workflow approval functionality seems to me like something that should be working ASAP.. WDYT? cheers, juan pablo ... Murray Altheim= = === 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
Re: [VOTE] Release JSPWiki version 2.12.0
Hi Juan Pablo,
I've gone ahead and installed Tomcat 9 and successfully deployed
JSPWiki 2.12.0. Thanks for the information -- all is good.
+1
Cheers,
Murray
On 5/21/23 21:27, Juan Pablo Santos Rodríguez wrote:
Hi Murray!
Tomcat 10 onwards support the jakarta namespace instead of javax (the one
that JSPWiki compiles to), so JSPWiki cannot run on it without
modifications. There's
https://issues.apache.org/jira/projects/JSPWIKI/issues/JSPWIKI-1170 to
track that, but so far we haven't done anything in that direction.
IIRC, Tomcat offers a migration tool, to seamlessly migrate from one
namespace to the other, but I haven't tried it. Also, IIRC, you can place
your javax war application on some special $TOMCAT folder
(webapp-something) and it also translates it to a jakarta-based
application, but I haven't tried it.
We should document that at jspwiki-wiki.a.org, as of today tomcat 9 or
equivalent is a hard requirement to run JSPWiki.
HTH,
juan pablo
El dom, 21 may 2023, 14:14, Murray Altheim escribió:
Here's the relevant log file:
21-May-2023 19:25:34.754 INFO [main]
org.apache.catalina.core.ApplicationContext.log ContextListener:
contextInitialized()
21-May-2023 19:25:34.754 INFO [main]
org.apache.catalina.core.ApplicationContext.log SessionListener:
contextInitialized()
21-May-2023 19:25:34.755 INFO [main]
org.apache.catalina.core.ApplicationContext.log ContextListener:
attributeAdded('StockTicker', 'async.Stockticker@2baa48e3')
21-May-2023 19:26:45.627 SEVERE [Catalina-utility-2]
org.apache.catalina.core.StandardContext.listenerStart Error
configuring application listener of class
[org.apache.wiki.auth.SessionMonitor]
java.lang.NoClassDefFoundError: javax/servlet/http/HttpSessionListener
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at
java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
at
java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
at
org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2487)
On 5/21/23 19:36, Murray Altheim wrote:
Hi,
Sorry for the late reply, but here's my report (no 'yes' vote, sorry,
see below).
I'm running Ubuntu 23.04 on a Dell XPS 9315. I was able to successfully
build
JSPWiki 2.12.0 with no issues, using:
Picked up JAVA_TOOL_OPTIONS: -Xms512m -Xmx8192m
java version "11.0.11" 2021-04-20 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.11+9-LTS-194)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.11+9-LTS-194,
mixed mode)
I deployed the war file to Apache Tomcat/10.1.8 and it failed to run,
FAIL - Application at context path [/JSPWiki] could not be started
with very little helpful in the logs:
21-May-2023 19:26:04.308 INFO [http-nio-7070-exec-9]
org.apache.catalina.startup.HostConfig.undeploy Undeploying context
[/ws]
21-May-2023 19:26:44.802 INFO [Catalina-utility-2]
org.apache.catalina.startup.HostConfig.deployWAR Deploying web
application archive [/opt/apache-tomcat-10.1.8/webapps/JSPW
21-May-2023 19:26:45.625 INFO [Catalina-utility-2]
org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was
scanned for TLDs yet contained no TLDs. Enable debug lo
21-May-2023 19:26:45.628 SEVERE [Catalina-utility-2]
org.apache.catalina.core.StandardContext.startInternal One or more
listeners failed to start. Full details will be found21-May-2023
19:26:45.629 SEVERE [Catalina-utility-2]
org.apache.catalina.core.StandardContext.startInternal Context
[/JSPWiki] startup failed due to previous errors
21-May-2023 19:26:45.633 INFO [Catalina-utility-2]
org.apache.catalina.startup.HostConfig.deployWAR Deployment of web
application archive [/opt/apache-tomcat-10.1.8/webapps/
If I'm running the wrong version of Java or Tomcat or there's something
obvious,
I'm happy to fix that within the next 12 hours, but for now I can't vote
yes.
Cheers,
Murray
On 5/21/23 15:27, Juan Pablo Santos Rodríguez wrote:
Hi,
This is a gently reminder for our PMC members: we still need one binding
vote to be able to proceed with the release.
Thanks in advance!
El jue, 18 may 2023, 22:01, Arturo Bernal
.invalid>
escribió:
[x] +1 Release these artifacts
Build passed with no issues, running `mvn clean test install site`
Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)Maven
home:
/opt/apache-maven-3.8.1Java version: 17.0.2, vendor: Oracle
Corporation,
runtime:
/Library/Java/JavaVirtualMachines/jdk-17.0.2.jdk/Contents/HomeDefault
locale: en_US, platform encoding: UTF-8OS name: "mac os x", version:
"13.3.1", arch: "x86_64", family: "mac"
Checked signatures of dist area files, found no issues.
Additionally, the default goal of Maven is functioning as expected.
On Tuesday, May 16, 2023 at 11:07:29 AM GMT+2, Harry Metske <
harry.met...@gmail.com> wrote:
+1
Looking good!
cheers,
Harry
Re: [VOTE] Release JSPWiki version 2.12.0
Here's the relevant log file:
21-May-2023 19:25:34.754 INFO [main]
org.apache.catalina.core.ApplicationContext.log ContextListener:
contextInitialized()
21-May-2023 19:25:34.754 INFO [main]
org.apache.catalina.core.ApplicationContext.log SessionListener:
contextInitialized()
21-May-2023 19:25:34.755 INFO [main] org.apache.catalina.core.ApplicationContext.log ContextListener:
attributeAdded('StockTicker', 'async.Stockticker@2baa48e3')
21-May-2023 19:26:45.627 SEVERE [Catalina-utility-2] org.apache.catalina.core.StandardContext.listenerStart Error
configuring application listener of class [org.apache.wiki.auth.SessionMonitor]
java.lang.NoClassDefFoundError: javax/servlet/http/HttpSessionListener
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
at
java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
at
org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2487)
On 5/21/23 19:36, Murray Altheim wrote:
Hi,
Sorry for the late reply, but here's my report (no 'yes' vote, sorry, see
below).
I'm running Ubuntu 23.04 on a Dell XPS 9315. I was able to successfully build
JSPWiki 2.12.0 with no issues, using:
Picked up JAVA_TOOL_OPTIONS: -Xms512m -Xmx8192m
java version "11.0.11" 2021-04-20 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.11+9-LTS-194)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.11+9-LTS-194, mixed mode)
I deployed the war file to Apache Tomcat/10.1.8 and it failed to run,
FAIL - Application at context path [/JSPWiki] could not be started
with very little helpful in the logs:
21-May-2023 19:26:04.308 INFO [http-nio-7070-exec-9] org.apache.catalina.startup.HostConfig.undeploy Undeploying context
[/ws]
21-May-2023 19:26:44.802 INFO [Catalina-utility-2] org.apache.catalina.startup.HostConfig.deployWAR Deploying web
application archive [/opt/apache-tomcat-10.1.8/webapps/JSPW
21-May-2023 19:26:45.625 INFO [Catalina-utility-2] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was
scanned for TLDs yet contained no TLDs. Enable debug lo
21-May-2023 19:26:45.628 SEVERE [Catalina-utility-2] org.apache.catalina.core.StandardContext.startInternal One or more
listeners failed to start. Full details will be found21-May-2023 19:26:45.629 SEVERE [Catalina-utility-2]
org.apache.catalina.core.StandardContext.startInternal Context [/JSPWiki] startup failed due to previous errors
21-May-2023 19:26:45.633 INFO [Catalina-utility-2] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web
application archive [/opt/apache-tomcat-10.1.8/webapps/
If I'm running the wrong version of Java or Tomcat or there's something obvious,
I'm happy to fix that within the next 12 hours, but for now I can't vote yes.
Cheers,
Murray
On 5/21/23 15:27, Juan Pablo Santos Rodríguez wrote:
Hi,
This is a gently reminder for our PMC members: we still need one binding
vote to be able to proceed with the release.
Thanks in advance!
El jue, 18 may 2023, 22:01, Arturo Bernal
escribió:
[x] +1 Release these artifacts
Build passed with no issues, running `mvn clean test install site`
Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)Maven home:
/opt/apache-maven-3.8.1Java version: 17.0.2, vendor: Oracle Corporation,
runtime:
/Library/Java/JavaVirtualMachines/jdk-17.0.2.jdk/Contents/HomeDefault
locale: en_US, platform encoding: UTF-8OS name: "mac os x", version:
"13.3.1", arch: "x86_64", family: "mac"
Checked signatures of dist area files, found no issues.
Additionally, the default goal of Maven is functioning as expected.
On Tuesday, May 16, 2023 at 11:07:29 AM GMT+2, Harry Metske <
harry.met...@gmail.com> wrote:
+1
Looking good!
cheers,
Harry
On Mon, 15 May 2023 at 12:13, Juan Pablo Santos Rodríguez <
juanpa...@apache.org> wrote:
This is a release vote for Apache JSPWiki, version 2.12.0. The vote will
be
open for at least 72 hours from now.
You can see a curated changelog at
https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.12
Note that we are voting upon the source (tag), binaries are provided for
convenience.
Everybody is encouraged to vote.
Source and binary files:
https://dist.apache.org/repos/dist/dev/jspwiki/2.12.0-RC2
Nexus staging repo: https://repository.apache.org/
<
https://repository.apache.org/content/repositories/orgapachejspwiki-1030>
content/repositories/
<
https://repository.apache.org/content/repositories/orgapachejspwiki-1030>
orgapachejspwiki-1030
<
https://repository.apache.org/content/repositories/orgapachejspwiki-1030>
The tag to be voted upon:
https://github.com/apache/jspwiki/tree/2.12.0-RC2
JSPWiki's KEYS file containing PGP keys we use to sign the release:
https://www.apache.org/dist/jspwiki/KEYS
*** Please download
Re: [VOTE] Release JSPWiki version 2.12.0
Hi, Sorry for the late reply, but here's my report (no 'yes' vote, sorry, see below). I'm running Ubuntu 23.04 on a Dell XPS 9315. I was able to successfully build JSPWiki 2.12.0 with no issues, using: Picked up JAVA_TOOL_OPTIONS: -Xms512m -Xmx8192m java version "11.0.11" 2021-04-20 LTS Java(TM) SE Runtime Environment 18.9 (build 11.0.11+9-LTS-194) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.11+9-LTS-194, mixed mode) I deployed the war file to Apache Tomcat/10.1.8 and it failed to run, FAIL - Application at context path [/JSPWiki] could not be started with very little helpful in the logs: 21-May-2023 19:26:04.308 INFO [http-nio-7070-exec-9] org.apache.catalina.startup.HostConfig.undeploy Undeploying context [/ws] 21-May-2023 19:26:44.802 INFO [Catalina-utility-2] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/opt/apache-tomcat-10.1.8/webapps/JSPW 21-May-2023 19:26:45.625 INFO [Catalina-utility-2] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug lo 21-May-2023 19:26:45.628 SEVERE [Catalina-utility-2] org.apache.catalina.core.StandardContext.startInternal One or more listeners failed to start. Full details will be found21-May-2023 19:26:45.629 SEVERE [Catalina-utility-2] org.apache.catalina.core.StandardContext.startInternal Context [/JSPWiki] startup failed due to previous errors 21-May-2023 19:26:45.633 INFO [Catalina-utility-2] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/opt/apache-tomcat-10.1.8/webapps/ If I'm running the wrong version of Java or Tomcat or there's something obvious, I'm happy to fix that within the next 12 hours, but for now I can't vote yes. Cheers, Murray On 5/21/23 15:27, Juan Pablo Santos Rodríguez wrote: Hi, This is a gently reminder for our PMC members: we still need one binding vote to be able to proceed with the release. Thanks in advance! El jue, 18 may 2023, 22:01, Arturo Bernal escribió: [x] +1 Release these artifacts Build passed with no issues, running `mvn clean test install site` Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)Maven home: /opt/apache-maven-3.8.1Java version: 17.0.2, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk-17.0.2.jdk/Contents/HomeDefault locale: en_US, platform encoding: UTF-8OS name: "mac os x", version: "13.3.1", arch: "x86_64", family: "mac" Checked signatures of dist area files, found no issues. Additionally, the default goal of Maven is functioning as expected. On Tuesday, May 16, 2023 at 11:07:29 AM GMT+2, Harry Metske < harry.met...@gmail.com> wrote: +1 Looking good! cheers, Harry On Mon, 15 May 2023 at 12:13, Juan Pablo Santos Rodríguez < juanpa...@apache.org> wrote: This is a release vote for Apache JSPWiki, version 2.12.0. The vote will be open for at least 72 hours from now. You can see a curated changelog at https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.12 Note that we are voting upon the source (tag), binaries are provided for convenience. Everybody is encouraged to vote. Source and binary files: https://dist.apache.org/repos/dist/dev/jspwiki/2.12.0-RC2 Nexus staging repo: https://repository.apache.org/ < https://repository.apache.org/content/repositories/orgapachejspwiki-1030> content/repositories/ < https://repository.apache.org/content/repositories/orgapachejspwiki-1030> orgapachejspwiki-1030 < https://repository.apache.org/content/repositories/orgapachejspwiki-1030> The tag to be voted upon: https://github.com/apache/jspwiki/tree/2.12.0-RC2 JSPWiki's KEYS file containing PGP keys we use to sign the release: https://www.apache.org/dist/jspwiki/KEYS *** Please download, test and vote: [ ] +1 Approve the release [ ] 0 Don't mind [ ] -1 Disapprove the release (please provide specific comments) -- ....... Murray Altheim= = === 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
Re: Incoming release for 2.12.0?
+1 On 2023/04/04 17:26, Harry Metske wrote: +1 Op zo 2 apr. 2023 om 23:46 schreef Juan Pablo Santos Rodríguez < juanpablo.san...@gmail.com> Hi! We have some security fixes sitting on master for a while now. We've also had another security report for some weeks that seems to resolve to not be an issue, since we haven't heard back from the reporter from quite a while now. Maybe it's a good time to proceed with the release of 2.12.0. I'd like to merge latest dependabot updates and maybe look at other PRs that are waiting to be looked at, before proceeding with the release, but that shouldn't take more than this week. Anyone wanting anything else for 2.12.0, or feeling that there's rush with the plan, please do tell so we can adjust the release timeframe. Cheers, juan pablo
Re: Policy on matchEnglishPlurals?
On 2022/09/23 6:18, Juan Pablo Santos Rodríguez wrote: Hi, I'd say you've found all the documentation that there is about that :-/ Basically if the jspwiki.translatorReader.matchEnglishPlurals property is set to true, then pages ending with 's' are considered the same as their singular form when linking between them. It does not prevent you from having both kinds of pages - we fall back to the other one if the primary name does not exist. Although doing the work, is a bit naive, so it is recommended only for english wikipages. Don't know if it would be worth implementing for a custom ReferenceManager, or if it could be implemented with a more complex logic or if it makes sense to mimic the same logic on the DefaultReferenceManager.. The matchEnglishPlurals feature is only meant for English wiki pages, but given that the localisation of the wiki itself isn't actually taken into account at all by the current code (i.e., the code for this isn't aware of the localisation), this is clearly a setting that a wiki admin explicitly makes understanding that their wiki is predominantly English. E.g., if the wiki were in German with the flag set true it wouldn't work properly. I hadn't thought about the notion of not conforming to the same rules as the existing DefaultReferenceManager, not supporting the matchEnglishPlurals, or supporting it differently. But the latter is not a bad alternative. I can get almost all of the existing tests to pass, but not all. If I make one slight change in the code the tests that didn't pass will pass, but that breaks a different set of tests. This suggests that it might be either very difficult or impossible to mimic the existing behaviour with a different implementation, and of course any programmatic handling of English plurals is never going to be 100% correct anyway. So I think I might aim for a reasonable compromise and just call that Victory. I've spent probably too much time on this already, as it's quite a difficult implementation and there's still a fair bit of graph-related work to start. Cheers, Murray On Mon, Sep 19, 2022 at 10:22 AM Murray Altheim wrote: Hi, I'm struggling with the modifications necessary to implement a replacement ReferenceManager using a graph backend, and in a somewhat surprising place: namely, passing tests related to parsing plurals. I can kinda figure what is meant from the various tests, but overall I can't discern a policy on how to handle references to wiki page names, how to deal with page creates or updates in either direction of a singular-to-plural update, plural-to- singular, whether or not to consider an initial link to a singular or plural as to the same page, etc. These kinds of questions can be seen in tests like testPluralSingularUpdate1, testPluralSingularUpdate2, and testPluralSingularUpdate3 in ReferenceManagerTest. Is there anywhere documented the actual policy on how to handle singular and plural wikiNames in either page names or links? I've only found the one paragraph in the properties file. ... Murray Altheim= = === 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
Re: Upgrading jdk requirement?
Hi Juan Pablo, I'm perfectly fine with JDK 11 and certainly bumping to it from Java 8 in 2022 is hardly a radical step, with so far as I can see little downside. I've not for my own projects moved to JDK 17 but I appreciate hearing that for you it's been worth the effort. Even the multiline strings for JSPWiki would be quite welcome. I wanted to add that the latest 2022-09 version of Eclipse requires JDK 17 at minimum (though of course one can add older JREs for specific projects), but I'd think moving to JDK 11 for now would be prudent and would have my full support. As some may not know, I'm developing a graph-based ReferenceManager for JSPWiki that does require JDK 11 (due to some of the essential libraries requiring it, not simply my decision), so having the main project bumped to that version would permit my ReferenceManager to use the same JDK as the application itself. Cheers, Murray On 2022/09/23 6:00, Juan Pablo Santos Rodríguez wrote: Hiya! been on holidays and with a lot of $dayjob after that, just wanted to close this, so it doesn't slip through. Let's say next version will be 2.12.0, instead of 2.11.4, and it will require JDK-11? As for when to upgrade the JDK requirement, let's just ask the question every minor release, if it's reasonable to do so? Or the other way round, when upgrading the JDK requirement, it would require increasing at least a minor release? As a side note, and completely agreeing with the reasons to upgrade to JDK-11, my experience with JDK-17 has been very similar to what Murray expressed with JDK-11, cleaner and less verbose code, as compared with JDK-11; multiline strings, pattern matching, helpful NPEs, records, etc. are little things that ease your day to day, and that I've found missing when going back.. kind regards, juan pablo On Tue, Aug 9, 2022 at 5:36 PM Jürgen Weber wrote: Actually I never understood the need for get/setters anyway (course I know the book). C++ got along well without. Cheers Murray Altheim schrieb am Di., 9. Aug. 2022, 16:12: On 2022/08/09 22:55, Jürgen Weber wrote: Java 11 would be OK. Not more. Enterprises are very conservative. Agreed, my current job is largely upgrading dozens and dozens of JDK 8 applications which have had no love for over a decade. I'm not so sure if this is the result of being conservative so much as executive management's typical desire to build New Things rather than maintain Old Things, or possibly The World of Constant Emergencies. Also, I do not see why a mature product like JSPWiki should be refactored to use newer Java features. I'm not a fan of using new features simply because they're new, but I have found some of the Java 11 features result in cleaner and less verbose code, e.g., some of the streaming syntax removes a lot of lines of boilerplate. This can be (like many things) abused and make things harder to either read or understand, but on balance I've gotten used to using many of the Java 11 features. Post JDK 11, I've found little of real value so far. On one of my larger personal projects I experimented recently with trying to back-date the code to JDK 8 and found that I'm very much a Java 11 person now, as almost none of the classes compiled as I'd used a lot of the new syntax. I've also previously suggested Lombok, which has for me become somewhat of a standard for all new code*. It removes all the pointless getters and setters, and with @Builder one effectively gets a DSL. Combining Lombok with an enum class really cleans up a lot of ugly use of integer contants, such as found in WikiPageEvent. I'd be happy to help out with migrating to Java 11, simply to get rid of that kind of thing... Cheers, Murray * I really wish Lombok were adopted into the Java syntax itself. ... Murray Altheim= = === 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 -- ... Murray Altheim= = === 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
Policy on matchEnglishPlurals?
Hi, I'm struggling with the modifications necessary to implement a replacement ReferenceManager using a graph backend, and in a somewhat surprising place: namely, passing tests related to parsing plurals. I can kinda figure what is meant from the various tests, but overall I can't discern a policy on how to handle references to wiki page names, how to deal with page creates or updates in either direction of a singular-to-plural update, plural-to- singular, whether or not to consider an initial link to a singular or plural as to the same page, etc. These kinds of questions can be seen in tests like testPluralSingularUpdate1, testPluralSingularUpdate2, and testPluralSingularUpdate3 in ReferenceManagerTest. Is there anywhere documented the actual policy on how to handle singular and plural wikiNames in either page names or links? I've only found the one paragraph in the properties file. Cheers, Murray ... Murray Altheim= = === 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
progress on GraphRenderingManager
Hi,
My last iteration of the GraphReferenceManager resulted in a manager far
too tightly wound into the existing JSPWiki code, where I had long ago
realised that the LinkManager (the actual manager that handles the
building and maintenance of the graph) really only needs to receive
WikiPageEvents.
The actual GraphReferenceManager would then no longer maintain the maps
of the existing DefaultReferenceManager, and effectively hand off its
functionality largely to the LinkManager in order to still comply with
the methods of the ReferenceManager API, and would effectively become
mostly an empty shell class, not doing much of anything. So my next
version will be quite a bit lighter in terms of hooks.
But I note that apart from modifying the contents of classmappings.xml
or classmappings-extra.xml, one thing I'd like to request is that the
functionality we currently have for several managers to configure the
choice of implementing class in jspwiki.properties be extended to the
ReferenceManager implementation. There'd seemingly be no downside to
this as the default would for most deployments be the existing class,
with this proposed configuration akin to:
jspwiki.referenceProvider = DefaultReferenceManager
This would be the sufficient hook I'd need to consider replacement of
the existing ReferenceManager (noting that my implementation is JDK 11
so I can't integrate it directly into jspwiki-main).
There would be a new enum for the various link types in the graph:
// not recognised as a link
INVALID("Invalid"),
// recognised as a link
INTERWIKI("Interwiki"),
IMAGE("Image"),
INTERNAL("Internal"),
EXTERNAL("External"),
ATTACHMENT("Attachment"),
UNCREATED("Uncreated"),
// parsed but not recognised as a link
ACCESS_RULE("AccessRule"),
PLUGIN("Plugin"),
METADATA("Metadata"),
VARIABLE("Variable");
[you may now understand my interest in the LinkParsingOperations class]
I've played with a variety of different JGraphT visualisations in the
jungrapht-visualization library for the default set of JSPWiki pages:
http://altheim.com/murray/yk/visualised.png
http://altheim.com/murray/yk/visualised-zoom.png
As part of this plan, there would be no "uncreated pages" any longer, as
all links-to-nowhere end up as fully-fledged graph nodes. So when a user
attempts to traverse to an uncreated page, the engine wouldn't simply
provide an edit link, it could also show the existing link sources.
The ability to traverse the graph from any node (at any depth, and
filtering on any link type) would provide a lot of additional
functionality.
Cheers,
Murray
...
Murray Altheim= = ===
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
Re: Upgrading jdk requirement?
On 2022/08/09 22:55, Jürgen Weber wrote: Java 11 would be OK. Not more. Enterprises are very conservative. Agreed, my current job is largely upgrading dozens and dozens of JDK 8 applications which have had no love for over a decade. I'm not so sure if this is the result of being conservative so much as executive management's typical desire to build New Things rather than maintain Old Things, or possibly The World of Constant Emergencies. Also, I do not see why a mature product like JSPWiki should be refactored to use newer Java features. I'm not a fan of using new features simply because they're new, but I have found some of the Java 11 features result in cleaner and less verbose code, e.g., some of the streaming syntax removes a lot of lines of boilerplate. This can be (like many things) abused and make things harder to either read or understand, but on balance I've gotten used to using many of the Java 11 features. Post JDK 11, I've found little of real value so far. On one of my larger personal projects I experimented recently with trying to back-date the code to JDK 8 and found that I'm very much a Java 11 person now, as almost none of the classes compiled as I'd used a lot of the new syntax. I've also previously suggested Lombok, which has for me become somewhat of a standard for all new code*. It removes all the pointless getters and setters, and with @Builder one effectively gets a DSL. Combining Lombok with an enum class really cleans up a lot of ugly use of integer contants, such as found in WikiPageEvent. I'd be happy to help out with migrating to Java 11, simply to get rid of that kind of thing... Cheers, Murray * I really wish Lombok were adopted into the Java syntax itself. ... Murray Altheim= = === 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
ClassCastException on application reboot
Hi, Also, just wondering if this has already been noted, if it's just me (possibly due to Oracle Java 11), or if this is a valid bug. If this is ignorable I'm fine with that, i.e., it's seemingly not affecting anything I'm doing. I'm running Ubuntu 22.04.1 LTS on an HP Envy laptop, Intel® Core™ i7-8550U CPU @ 1.80GHz × 8, ► java -version java version "11.0.14" 2022-01-18 LTS Java(TM) SE Runtime Environment 18.9 (build 11.0.14+8-LTS-263) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.14+8-LTS-263, mixed mode) On restarting Tomcat I always see this stack trace in the logs: -- catalina.out stack trace -- [...] 09-Aug-2022 12:06:46.610 INFO [main] org.apache.catalina.core.StandardServer.await A valid shutdown command was received via the shutdown port. Stopping the Server instance. 09-Aug-2022 12:06:46.611 INFO [main] org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler ["http-nio-9627"] 09-Aug-2022 12:06:46.613 INFO [main] org.apache.catalina.core.StandardService.stopInternal Stopping service [Catalina] 09-Aug-2022 12:06:46.617 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesObjectStreamClassCaches Failed to clear soft references from ObjectStreamClass$Caches for web application [ROOT] java.lang.ClassCastException: class java.io.ObjectStreamClass$Caches$1 cannot be cast to class java.util.Map (java.io.ObjectStreamClass$Caches$1 and java.util.Map are in module java.base of loader 'bootstrap') at org.apache.catalina.loader.WebappClassLoaderBase.clearCache(WebappClassLoaderBase.java:2325) at org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesObjectStreamClassCaches(WebappClassLoaderBase.java:2300) at org.apache.catalina.loader.WebappClassLoaderBase.clearReferences(WebappClassLoaderBase.java:1669) at org.apache.catalina.loader.WebappClassLoaderBase.stop(WebappClassLoaderBase.java:1597) at org.apache.catalina.loader.WebappLoader.stopInternal(WebappLoader.java:463) at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257) at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5515) at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257) at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1412) at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1401) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140) at org.apache.catalina.core.ContainerBase.stopInternal(ContainerBase.java:986) at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257) at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1412) at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1401) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140) at org.apache.catalina.core.ContainerBase.stopInternal(ContainerBase.java:986) at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257) at org.apache.catalina.core.StandardService.stopInternal(StandardService.java:497) at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257) at org.apache.catalina.core.StandardServer.stopInternal(StandardServer.java:979) at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257) at org.apache.catalina.startup.Catalina.stop(Catalina.java:849) at org.apache.catalina.startup.Catalina.start(Catalina.java:811) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:345) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:476) Cheers, Murray ......
Is 2.11.3 a drop-in replacement for 2.11.2?
Hi, Hopefully a quick question: I've got a local wiki based on the "department wiki" distributed with JSPWiki Portable that I use for both personal stuff and testing my developments, and I was wondering if I can just drop the new 2.11.3 jar files in place of the 2.11.2 files in jspwiki/lib/: jspwiki-210-adapters-2.11.2.jar jspwiki-api-2.11.2.jar jspwiki-bootstrap-2.11.2.jar jspwiki-cache-2.11.2.jar jspwiki-event-2.11.2.jar jspwiki-kendra-searchprovider-2.11.2.jar jspwiki-main-2.11.2.jar jspwiki-markdown-2.11.2.jar jspwiki-util-2.11.2.jar or if there's any dependency or JSP changes that would be required for compatibility. I'd prefer not having to rebuild that deployment if it's unnecessary as it took quite a lot of time to set up. Thanks, Murray ....... Murray Altheim= = === 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
Re: LinkParsingOperations improvements?
On 2022/08/05 8:53, Juan Pablo Santos Rodríguez wrote: Hi Murray, (apologies for the brevity, is really late in here, and won't be having too much time next few days..) Hi Juan Pablo, No worries, my time is pretty limited lately as well. Thanks very much for the explanation, I certainly understand refactorings. I myself don't have any issues with static methods, and on a massive refactoring job I did a few years ago (something like 30 modules), I ended up creating a lot of utility classes composed solely of static methods, as the devs over the years had ended up creating multiple copies of various functions, etc. and I was essentially collecting all of them into classes categorised for area of function. Testing wasn't too bad, but of course we already had unit, integration and system tests for a lot of the features already. I've been playing with ideas for the graph-based reference manager, have even been experimenting with some visualisations of wiki links using the JUNG and JunGraphT libraries: http://jung.sourceforge.net/index.html https://tomnelson.github.io/jungrapht-visualization/ As something gets closer to reality I'll post links to some of the generated images. The visualisations are more of a curiosity than something that would be functional for a working wiki, but are helping me understand what is actually happening in the GraphReferenceManager as I go along. Cheers, Murray ... Murray Altheim= = === 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
LinkParsingOperations improvements?
Hi, As I've been digging around in the code related to the ReferenceManager, I found a curiosity. I'm not sure of the history surrounding LinkParsingOperations, but it seems that we create an instance for every WikiContext, despite the fact that both of the two methods that use it actually use it just to obtain the WikiEngine. The other eight methods could be static, and there's a StartingComparator inner static class that's not actually used anywhere else in code so it could be removed (so far as I can see). The linkIfExists(String) and linkExists(String) methods both do almost the same thing, so in theory the latter could simply call the former to obtain its boolean result. Since all the places where these two methods are called (all are within JSPWikiMarkupParser) have access to the WikiEngine it could be passed in as an argument, and therefore all of the methods of the LinkParsingOperations could be made static and turn this into a static utility class. There's clearly no urgency for this but it does seem like we could reduce the number of objects created by adopting the above suggestions. Cheers, Murray ... Murray Altheim= = === 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
Re: [VOTE] Release JSPWiki version 2.11.3
r-news-module:org.apache.tika:2.4.1]. It will be ignored by the remote resources Mojo. [WARNING] Failed to build parent project for org.apache.tika:tika-parsers:pom:2.4.1 [WARNING] Failed to build parent project for org.apache.tika:tika-parsers-standard:pom:2.4.1 [WARNING] Failed to build parent project for org.apache.tika:tika-parsers-standard-modules:pom:2.4.1 [WARNING] Failed to build parent project for org.apache.tika:tika-parser-ocr-module:jar:2.4.1 [WARNING] Invalid project model for artifact [tika-parser-ocr-module:org.apache.tika:2.4.1]. It will be ignored by the remote resources Mojo. [WARNING] Failed to build parent project for org.apache.commons:commons-exec:jar:1.3 [WARNING] Invalid project model for artifact [commons-exec:org.apache.commons:1.3]. It will be ignored by the remote resources Mojo. [WARNING] Failed to build parent project for org.apache.tika:tika-parsers:pom:2.4.1 [WARNING] Failed to build parent project for org.apache.tika:tika-parsers-standard:pom:2.4.1 [WARNING] Failed to build parent project for org.apache.tika:tika-parsers-standard-modules:pom:2.4.1 [WARNING] Failed to build parent project for org.apache.tika:tika-parser-pdf-module:jar:2.4.1 [WARNING] Invalid project model for artifact [tika-parser-pdf-module:org.apache.tika:2.4.1]. It will be ignored by the remote resources Mojo. [WARNING] Failed to build parent project for org.apache.pdfbox:pdfbox:bundle:2.0.26 [WARNING] Invalid project model for artifact [pdfbox:org.apache.pdfbox:2.0.26]. It will be ignored by the remote resources Mojo. [WARNING] Failed to build parent project for org.apache.pdfbox:pdfbox-tools:jar:2.0.26 [WARNING] Invalid project model for artifact [pdfbox-tools:org.apache.pdfbox:2.0.26]. It will be ignored by the remote resources Mojo. [WARNING] Failed to build parent project for org.apache.pdfbox:pdfbox-debugger:jar:2.0.26 [WARNING] Invalid project model for artifact [pdfbox-debugger:org.apache.pdfbox:2.0.26]. It will be ignored by the remote resources Mojo. [WARNING] Failed to build parent project for org.apache.tika:tika-parsers:pom:2.4.1 [WARNING] Failed to build parent project for org.apache.tika:tika-parsers-standard:pom:2.4.1 [WARNING] Failed to build parent project for org.apache.tika:tika-parsers-standard-modules:pom:2.4.1 [WARNING] Failed to build parent project for org.apache.tika:tika-parser-pkg-module:jar:2.4.1 [WARNING] Invalid project model for artifact [tika-parser-pkg-module:org.apache.tika:2.4.1]. It will be ignored by the remote resources Mojo. [WARNING] Failed to build parent project for org.apache.tika:tika-parsers:pom:2.4.1 [WARNING] Failed to build parent project for org.apache.tika:tika-parsers-standard:pom:2.4.1 [WARNING] Failed to build parent project for org.apache.tika:tika-parsers-standard-modules:pom:2.4.1 [WARNING] Failed to build parent project for org.apache.tika:tika-parser-webarchive-module:jar:2.4.1 [WARNING] Invalid project model for artifact [tika-parser-webarchive-module:org.apache.tika:2.4.1]. It will be ignored by the remote resources Mojo. [INFO] ... Murray Altheim= = === 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
Re: [VOTE] Release JSPWiki version 2.11.3
Hi Juan Pablo, To confirm, I just did a successful build with OpenJDK 1.8, so the problem building seems related to building under Oracle's JDK. As a previous Sun employee I'm hardly a fan of Larry Ellison (who has screwed with the Java community many times), so: +1 on my vote. ► java -version openjdk version "1.8.0_312" OpenJDK Runtime Environment (build 1.8.0_312-8u312-b07-0ubuntu1-b07) OpenJDK 64-Bit Server VM (build 25.312-b07, mixed mode) ... [INFO] jspwiki-it-test-cma-jdbc ... SUCCESS [ 1.715 s] [INFO] Apache JSPWiki bill of materials ... SUCCESS [ 0.016 s] [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 02:46 min [INFO] Finished at: 2022-08-01T21:51:28+09:00 [INFO] On 2022/08/01 21:44, Murray Altheim wrote: Hi Juan Pablo, Is it possible this is related to Oracle vs. OpenJDK? I'm not sure. Looks to be a missing library. The stack trace follows. If I build that module without tests and then proceed "mvn -rf", the rest of the build completes successfully. --- Test set: org.apache.wiki.search.tika.TikaSearchProviderTest --- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.97 s <<< FAILURE! - in org.apache.wiki.search.tika.TikaSearchProviderTest org.apache.wiki.search.tika.TikaSearchProviderTest.testGetAttachmentContent Time elapsed: 0.263 s <<< ERROR! java.lang.UnsatisfiedLinkError: /usr/lib/jvm/jdk1.8.0_202/jre/lib/i386/libawt_xawt.so: libXext.so.6: cannot open shared object file: No such file or directory at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1824) at java.lang.Runtime.load0(Runtime.java:809) at java.lang.System.load(System.java:1086) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1845) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1122) at java.awt.image.ColorModel$1.run(ColorModel.java:209) at java.awt.image.ColorModel$1.run(ColorModel.java:207) at java.security.AccessController.doPrivileged(Native Method) at java.awt.image.ColorModel.loadLibraries(ColorModel.java:206) at java.awt.image.ColorModel.(ColorModel.java:219) at java.awt.image.Raster.(Raster.java:172) at org.apache.pdfbox.pdmodel.PDDocument.(PDDocument.java:107) at org.apache.tika.parser.pdf.PDFParser.getPDDocument(PDFParser.java:284) at org.apache.tika.parser.pdf.PDFParser.parse(PDFParser.java:171) at org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:298) at org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:298) at org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:167) at org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:235) at org.apache.wiki.search.tika.TikaSearchProvider.getAttachmentContent(TikaSearchProvider.java:105) at org.apache.wiki.search.LuceneSearchProvider.reindexPage(LuceneSearchProvider.java:437) at org.apache.wiki.search.SearchManager.reindexPage(SearchManager.java:86) at org.apache.wiki.attachment.DefaultAttachmentManager.storeAttachment(DefaultAttachmentManager.java:265) at org.apache.wiki.TestEngine.addAttachment(TestEngine.java:397) at org.apache.wiki.search.tika.TikaSearchProviderTest.testGetAttachmentContent(TikaSearchProviderTest.java:39) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727) at org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60) at org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131) at org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156) at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147) at org.junit.jupiter.engine.extension.TimeoutExtension.interc
Re: [VOTE] Release JSPWiki version 2.11.3
core.DefaultLauncher.execute(DefaultLauncher.java:114) at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:86) at org.junit.platform.launcher.core.DefaultLauncherSession$DelegatingLauncher.execute(DefaultLauncherSession.java:86) at org.apache.maven.surefire.junitplatform.LazyLauncher.execute(LazyLauncher.java:55) at org.apache.maven.surefire.junitplatform.JUnitPlatformProvider.execute(JUnitPlatformProvider.java:223) at org.apache.maven.surefire.junitplatform.JUnitPlatformProvider.invokeAllTests(JUnitPlatformProvider.java:175) at org.apache.maven.surefire.junitplatform.JUnitPlatformProvider.invoke(JUnitPlatformProvider.java:139) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:456) at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:169) at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:595) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581) On 2022/08/01 19:25, Juan Pablo Santos Rodríguez wrote: Hi Murray, Would you mind sharing the stacktrace with the error? JSPWiki is successfully building with jdk-8, jdk-11 and jdk-17 at https://ci-builds.apache.org/job/JSPWiki/job/ci/job/master (mvn clean package for jdks 11 & 17, the same + sonarqube analysis for jdk-8). Thx in advance, juan pablo El lun, 1 ago 2022 12:14, Murray Altheim escribió: -1 or -1 or -1. Explanation follows... I didn't have Java 8 installed on the laptop I have with me (I'm in Japan, not at home in New Zealand), so I tried building it with Java 11 first: ► java -version java version "11.0.14" 2022-01-18 LTS Java(TM) SE Runtime Environment 18.9 (build 11.0.14+8-LTS-263) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.14+8-LTS-263, mixed mode) 1st try: ... [INFO] Apache JSPWiki AWS Kendra Search provider .. SUCCESS [ 11.955 s] [INFO] Apache JSPWiki test extensions not using public api SUCCESS [ 0.517 s] [INFO] Apache JSPWiki adapters for pre-public api . SUCCESS [ 2.446 s] [INFO] Apache JSPWiki Main War FAILURE [ 43.885 s] [INFO] Apache JSPWiki portable SKIPPED [INFO] jspwiki-it-builder . SKIPPED 2nd try: ... [INFO] Apache JSPWiki AWS Kendra Search provider .. SUCCESS [ 4.328 s] [INFO] Apache JSPWiki test extensions not using public api SUCCESS [ 0.813 s] [INFO] Apache JSPWiki adapters for pre-public api . SUCCESS [ 3.025 s] [INFO] Apache JSPWiki Main War FAILURE [ 44.743 s] [INFO] Apache JSPWiki portable SKIPPED [INFO] jspwiki-it-builder . SKIPPED Then I built jspwiki-main on its own successfully and "mvn install test -rf"'d from there, with this failure: ... [INFO] Apache JSPWiki Main War SUCCESS [ 40.523 s] [INFO] Apache JSPWiki portable FAILURE [ 10.504 s] [INFO] jspwiki-it-builder . SKIPPED [INFO] jspwiki-selenide-tests . SKIPPED ...so: I'm not finding this very stable in Java 11. There were a ton of warnings but ultimately I wasn't able to build it in one go. Summary #1: Now, I realise before that JSPWiki is a Java 8 application. If it's meant to be buildable using Java 11, then I must vote -1. But maybe that's not fair. So, I went ahead and installed Java 8: ► java -version java version "1.8.0_202" Java(TM) SE Runtime Environment (build 1.8.0_202-b08) Java HotSpot(TM) Server VM (build 25.202-b08, mixed mode) But failed again on the build (with a new terminal): ... [INFO] Apache JSPWiki markdown support SUCCESS [ 8.529 s] [INFO] Apache JSPWiki Tika Search provider FAILURE [ 6.852 s] [INFO] Apache JSPWiki AWS Kendra Search provider .. SKIPPED [INFO] Apache JSPWiki test extensions not using public api SKIPPED Summary #2: so, even with Java 8 installed I wasn't able to build JSPWiki, with just "mvn install test" from the download. I tried yet a third time with Java 8 but am still failing when trying to build jspwiki-tika-searchprovider. :-( Cheers, Murray On 2022/08/01 17:29, Harry Metske wrote: +1 On Sat, 30 Jul 2022 at 14:58, Juan Pablo Santos Rodríguez < juanpa...@apache.org> wrote: This is a release vote for Apache JSPWiki, version 2.11.3. The vote will be open for at least 72 hours from now. It fixes the following issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12351386 You can see a curated changelog at https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11 Note that we are voting upon the source (tag), binaries are provided for convenience. Everybody is encouraged to vote. Source and binary files: https://
Re: [VOTE] Release JSPWiki version 2.11.3
-1 or -1 or -1. Explanation follows... I didn't have Java 8 installed on the laptop I have with me (I'm in Japan, not at home in New Zealand), so I tried building it with Java 11 first: ► java -version java version "11.0.14" 2022-01-18 LTS Java(TM) SE Runtime Environment 18.9 (build 11.0.14+8-LTS-263) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.14+8-LTS-263, mixed mode) 1st try: ... [INFO] Apache JSPWiki AWS Kendra Search provider .. SUCCESS [ 11.955 s] [INFO] Apache JSPWiki test extensions not using public api SUCCESS [ 0.517 s] [INFO] Apache JSPWiki adapters for pre-public api . SUCCESS [ 2.446 s] [INFO] Apache JSPWiki Main War FAILURE [ 43.885 s] [INFO] Apache JSPWiki portable SKIPPED [INFO] jspwiki-it-builder . SKIPPED 2nd try: ... [INFO] Apache JSPWiki AWS Kendra Search provider .. SUCCESS [ 4.328 s] [INFO] Apache JSPWiki test extensions not using public api SUCCESS [ 0.813 s] [INFO] Apache JSPWiki adapters for pre-public api . SUCCESS [ 3.025 s] [INFO] Apache JSPWiki Main War FAILURE [ 44.743 s] [INFO] Apache JSPWiki portable SKIPPED [INFO] jspwiki-it-builder . SKIPPED Then I built jspwiki-main on its own successfully and "mvn install test -rf"'d from there, with this failure: ... [INFO] Apache JSPWiki Main War SUCCESS [ 40.523 s] [INFO] Apache JSPWiki portable FAILURE [ 10.504 s] [INFO] jspwiki-it-builder . SKIPPED [INFO] jspwiki-selenide-tests . SKIPPED ...so: I'm not finding this very stable in Java 11. There were a ton of warnings but ultimately I wasn't able to build it in one go. Summary #1: Now, I realise before that JSPWiki is a Java 8 application. If it's meant to be buildable using Java 11, then I must vote -1. But maybe that's not fair. So, I went ahead and installed Java 8: ► java -version java version "1.8.0_202" Java(TM) SE Runtime Environment (build 1.8.0_202-b08) Java HotSpot(TM) Server VM (build 25.202-b08, mixed mode) But failed again on the build (with a new terminal): ... [INFO] Apache JSPWiki markdown support SUCCESS [ 8.529 s] [INFO] Apache JSPWiki Tika Search provider FAILURE [ 6.852 s] [INFO] Apache JSPWiki AWS Kendra Search provider .. SKIPPED [INFO] Apache JSPWiki test extensions not using public api SKIPPED Summary #2: so, even with Java 8 installed I wasn't able to build JSPWiki, with just "mvn install test" from the download. I tried yet a third time with Java 8 but am still failing when trying to build jspwiki-tika-searchprovider. :-( Cheers, Murray On 2022/08/01 17:29, Harry Metske wrote: +1 On Sat, 30 Jul 2022 at 14:58, Juan Pablo Santos Rodríguez < juanpa...@apache.org> wrote: This is a release vote for Apache JSPWiki, version 2.11.3. The vote will be open for at least 72 hours from now. It fixes the following issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12351386 You can see a curated changelog at https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11 Note that we are voting upon the source (tag), binaries are provided for convenience. Everybody is encouraged to vote. Source and binary files: https://dist.apache.org/repos/dist/dev/jspwiki/2.11.3-RC1 Nexus staging repo: https://repository.apache.org/content/repositories/orgapachejspwiki-1028 The tag to be voted upon: https://github.com/apache/jspwiki/tree/2.11.3-RC1 JSPWiki's KEYS file containing PGP keys we use to sign the release: https://www.apache.org/dist/jspwiki/KEYS *** Please download, test and vote: [ ] +1 Approve the release [ ] 0 Don't mind [ ] -1 Disapprove the release (please provide specific comments) -- ........... Murray Altheim= = === 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
Re: GraphReferenceManager
On 2022/07/29 15:11, Juan Pablo Santos Rodríguez wrote:
Hi Murray,
Just a quick note, current wiki syntax allows a second | in order to
support link attributes, e.g., [Page|MyPage|title='Page']. Markdown syntax
allows the same thing using [](){}, IIRC, so perhaps
[Subject|Predicate::Object] (or something like that) could be used instead?
Hi Juan Pablo,
Ah, thanks for the tip. If there's already a parser for an attribute, I
might choose to extend that with a 'predicate=' rather than extend the
parser itself. That way existing applications that don't now what to do
with the attribute will simply store it. The existing link attribute
syntax is probably better than my proposed syntax as it wouldn't break
any other wikis that weren't using the GraphReferenceManager (and any
sub-processors that handle the ontology-related stuff), i.e., the pages
would be still compatible regardless of ReferenceManager implementation.
Cheers,
Murray
...
Murray Altheim= = ===
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
Re: GraphReferenceManager
On 2022/07/29 6:01, Juan Pablo Santos Rodríguez wrote: Hi Murray, ahh ok, now I see, so I guess we could start by making the reference manager pluggable through a wiki property, so anyone wishing to use it can do so easily. Hi Juan Pablo, The one pseudo-proposal I'm considering adding to the syntax would be to support normal intra-wiki links, but also optionally permit a second vertical bar character '|' to create a triple/tuple, e.g.: [Subject|Predicate|Object] so that one could type a link to a page using another page. E.g., [ThisPage|IsPreviousToPage|ThatPage] [ThatPage|HasPreviousPage|ThisPage] [ThisPage|HasParentPage|ThatPage] [ThisPage|HasCategory|ThatPage] [ErnestHemingway|IsA|Writer] [TheCat|SitsOn|TheMat] I did something similar back around 2005 with a wiki plugin that did exactly this, but with this proposal it'd be integrated as link syntax rather than as a plugin. This allows you to make a relationship between two pages (or a page and an external URL) that is typed by another page. That predicate page could in theory (in my system it always is) part of a predicate hierarchy. But I won't lead the team down that ontological rabbit hole. But for a teaser, one could create the predicates for first order predicate logic and begin to make statements between wiki pages (as "Terms) that describe what they mean. [This was part of the core of my unfinished Ph.D. work at that time.] So taking Cyc's definition of its 'genls' (inheritance) predicate: (isa genls TransitiveBinaryPredicate) (isa genls ReflexiveBinaryPredicate) (arg1Isa genls Collection) (arg2Isa genls Collection) (arg1Genl genls Thing) (arg2Genl genls Thing) one could express that as wiki pages with only minor syntactical changes: [IsA|Genls|TransitiveBinaryPredicate] [IsA|Genls|ReflexiveBinaryPredicate] [Arg1Isa|Genls|Collection] [Arg2Isa|Genls|Collection] [Arg1Genl|Genls|Thing] [Arg2Genl|Genls|Thing] But like I said, I won't go any further down that rabbit hole. Setting aside when to switch to JDK-11 (or whatever version we see fit), the graphmanager could be compiled with Java 11, having the rest of the project compiling with Java 8. The markdown module has been in a similar situation in the past, where it has been compiling with Java 8, and the rest of the project with Java 6 or 7, so that shouldn't be a stopper.. As for the number of pages, jspwiki-wiki has almost 400 pages, but there are other wikis out there with higher number of pages; f.ex., https://encyclopaedia-wot.org has almost 4000 pages, https://www.ecyrd.com/ButtUgly/wiki has around 3200 and http://ldapwiki.com/ almost 16400 That probably shouldn't be an issue. I've got a test corpus of around 1200 files that I could copy a few times to do a test at the 16K level and find out how long things take to process. I would be interested in knowing if there are any stats for that 16400 page wiki I could compare with... The ingest/accession (import/process metadata) on 1200 files with my digital library software is about 40 seconds, but that's also moving and writing files and creating an archive file for each. I might try to create a benchmark unit test to see how performance rates just for the reference manager. I'd still rather avoid Java serialisation/deserialisation if it turns out the difference between that and simply reading the source files isn't that huge. A lot cleaner design for sure. With high-frequence and multi-core CPUs, VMs and SSDs a lot of things that used to take a lot of time simply don't. I bought a 12 core, 24 thread i9 recently and my compile times (when coupled with command line optimisations) went from 90-120 seconds down to 15. For something like the reference manager where it's all reads and no writes (if we avoid serialisation on shutdown), then I think the performance even on 16K files should be reasonable. Interesting to test in any case. My time comes in spurts so I'm not sure how long this will take. I've currently got the bones of it, the easy bits, the rest is coming along... Cheers, Murray ... Murray Altheim= = === 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
Re: GraphReferenceManager
ly recommend Java 11 for JSPWiki though for the same reasons. Going to Java 17+ starts to introduce a lot of things to the world of Java that I'm not sure the project either benefits from or is compatible with (such as the radical bump in JSP version). So it sounds like my project could be a Java 11 external library for the interim, and brought into the trunk sometime after a transition to Java 11+. This doesn't shut down the project for me, just provides some insights on how to align it best with what the JSPWiki team are doing. Cheers, Murray ....... Murray Altheim= = === 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
GraphReferenceManager
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= = === 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
Re: [jira] [Commented] (JSPWIKI-1131) Lucene Index not updated on edits/new page
Hi Harry,
Yes, I think I've gotten so used to this I forgot it would be considered
a bug. This occurs on my older wikis as well as my latest wiki for
robots.org.nz's wiki at https://service.robots.org.nz/wiki/
I'm trying to think back as to what triggers a Lucene update, probably
the EventListener/EventManager? Sorry I can't be more helpful on this.
Cheers,
Murray
On 28/09/20 1:10 am, Harry Metske (Jira) wrote:
[
https://issues.apache.org/jira/browse/JSPWIKI-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202816#comment-17202816
]
Harry Metske commented on JSPWIKI-1131:
---
This is really an annoying one, I experience the same on my own wiki.
Lucene Index not updated on edits/new page
--
Key: JSPWIKI-1131
URL: https://issues.apache.org/jira/browse/JSPWIKI-1131
Project: JSPWiki
Issue Type: Bug
Components: Search
Affects Versions: 2.11.0-M7
Environment: * Debian 10
* Tomcat 9: 9.0.31-1~deb10u2
* OpenJDK-JRE 11: 11.0.7+10-3~deb10u1
* JSPWiki 2.11.0-M7
Reporter: FP
Priority: Critical
Attachments: exception.txt
It seems that the lucene search index is not updated when a user edits an
existing page or creates a new page. In both cases, the page is not found when
someone searches for it.
Search works as expected when:
* Tomcat is stopped
* The files in the {{lucene}} directory are removed
* Tomcat is started
* Wait until the Lucene Indexer thread finishes reindexing
The following exception occurs when a page is edited (full stack trace
attached):
{{java.io.NotSerializableException: org.apache.wiki.WikiContext}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
--
...
Murray Altheim= = ===
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
Re: [jira] [Created] (JSPWIKI-1133) Can't search for: a
That's not a bug, as 'a' is one of the search engine's "stop words": "a", "an", "and", "are", "as", "at", "be", "but", "by", "for", "if", "in", "into", "is", "it", "no", "not", "of", "on", "or", "such", "that", "the", "their", "then", "there", "these", "they", "this", "to", "was", "will", "with" https://stackoverflow.com/questions/17527741/what-is-the-default-list-of-stopwords-used-in-lucenes-stopfilter Any word in the Lucene stop word list can't be searched on, as it is (by default) not indexed. So you *can* search on a stop word but the engine has not indexed it. Lucene is the engine behind JSPWiki, Solr, ElasticSearch and most web sites. Cheers, Murray On 15/09/20 7:30 pm, FP (Jira) wrote: FP created JSPWIKI-1133: --- Summary: Can't search for: a Key: JSPWIKI-1133 URL: https://issues.apache.org/jira/browse/JSPWIKI-1133 Project: JSPWiki Issue Type: Bug Components: Search Affects Versions: 2.11.0-M7 Environment: * Debian 10 * Tomcat 9: 9.0.31-1~deb10u2 * OpenJDK-JRE 11: 11.0.7+10-3~deb10u1 * JSPWiki 2.11.0-M7 Reporter: FP There are no search results when a user searches for »a« (just the single letter, without »«). Every other single letter, e.g. »b«, … works fine. Page count: > 5000 with lots of pages containing the letter »a«. ... Murray Altheim= = === 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
Re: [VOTE] Release JSPWiki version 2.11.0.M7
+1 Agreed, Juan Pablo deserves an award for all his hard work. Cheers, Murray On 28/05/20 7:23 am, Dirk Frederickx wrote: +1 Tx Juan, for the major work done on the public api ! Grtz dirk On Wed, May 27, 2020 at 6:30 PM Harry Metske wrote: +1 Found no issues tx for the work, cheers, Harry ... Murray Altheim= = === 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
Re: JSPWiki public api proposal + 2.11.0.M7 release
> 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. > After that, re-introduce API compatibility with plugins (easy) and filters > (a bit more of work but hopefully doable too without spending too much > time on it). It would be really, *really* nice if someone volunteered for > the page providers: keeping the existing extensions is gone to take some > time that I was planning to spend on other tasks, so any help with that > would mean more time spent on the public api. I can only apologise that I'm not available to do any coding in the foreseeable future. It seems I'm now perpetually overcommitted, which I guess is a good thing. > (5) JSPWiki installations' islands > > We don't want to have them, and we strive to avoid them as much as > possible. Said that, I think they're bound to happen someday. Keeping the > backward compatibility is an ongoing burden. It is not that we shouldn't > have it as a top priority, but that doesn't mean is the absolute driver. Agreed. And it's admittedly a shame that the nature of JSPWiki is that there's likely a lot of people who are using it, and upgrading regularly, but we don't have any metrics on how many people have done customisations, or on the nature and depth of those customisations. We can only surmise, and I can only advocate on the likelihood of the needs of that community, not on anything beyond my own personal experience. > 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. I think we all have the experience that developers operate at a much faster speed than end users. I'm always struck by how many installations are still using old hardware and software. A few years ago I came upon a critical, enterprise system (which I can't name) that was working *entirely* on two Windows 2000 servers (physical boxes!) in the basement of the building. I managed to talk management to have me lead a project to get that onto Linux blade servers and properly requisitioned, and that effort took a couple of years. 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. Cheers, Murray ... Murray Altheim= = === 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
Re: [DISCUSS] rewording versioning proposal?
Juan Pablo wrote: > I've just sent another mail on how to tackle the backward compatibility > issue under the public api thread, so I'll skip > that here. I understand the rewording is fine with you (whether we end up > breaking backwards compatibility or not)? I'd prefer that we not break backwards compatibility if at all possible, as previously discussed, so no, I was speaking of the appropriateness of the rewording, which I entirely agree with as necessary for such a big change. I'll respond to the details in the other thread. > Do you find it specificies more clearly what to expect with each type of > release? Yes, thank you. > If there are no objections, I'd like to update the versioning proposal > somewhere near next Friday.. Thanks as always for your very hard work. Cheers, Murray ....... Murray Altheim= = === 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
Re: [DISCUSS] rewording versioning proposal?
ing a class or completely rewritting them. * minor: there are backwards incompatible changes, which *may* be translated on *some* plugins / filters / page providers, but generally speaking they should work, or at least they'll be loaded by JSPWiki. * revision: *All* custom plugins / filters / page providers will continue to work at this level. thoughts? makes sense? is it clear as it is, and doesn't need further editing? thanks in advance, juan pablo -- ........... Murray Altheim= = === 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
Re: JSPWiki public api proposal + 2.11.0.M7 release
> Hi Murray, > > for plugins, most probably there'll be a signature change on WikiPlugin, > from: > String execute( WikiContext context, Map< String, String > params ) throws > PluginException; > > to: > String execute( Context context, Map< String, String > params ) throws > PluginException; Hi Juan Pablo, I realise you can't promise anything, but what I'm asking is that there be an adapter-pattern package that maintains **exactly** the same signature as the existing plugins, if at all possible. If we require people to re-code and ecompile plugins then in many cases they simply won't upgrade JSPWiki, as in many cases they won't have time, don't have the developer time or experience or personnel available, etc. as I mentioned previously. If the changes proposed as part of this public API are merely changes of name and package location (effectively facades over the existing code), then an adapter package should be possible. If not, I can't say I'd advocate for making such a change as I believe it would segregate existing users into two camps: those able to re-code and re-install an update, and those who can't due to existing plugins. That seems an overly high price for the existence of a new public API that doesn't add functionality, i.e., if we don't provide a compatible bridging adapter package. Cheers, Murray ........... Murray Altheim= = === 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
Re: JSPWiki public api proposal + 2.11.0.M7 release
Hi Juan Pablo, One of the things I have considered proposing I'll go ahead and propose. I'm as seems typical lately rather overcommitted so I've not been able to review what's going on with the new APIs but I had the thought that it might be a good idea to actually support, at least for some period of time, **two** plugin APIs, the old and the new. This would enable existing wikis to continue to use older plugins that may have not or may never get updated, whilst still moving forward with newer versions of JSPWiki. The only difference between the old and new plugin APIs may simply be its own package signature and the package signatures of the respective dependencies (e.g., replacing WikiEngine with its API, etc.). As the author of a lot of plugins, I'd still like to be able to upgrade to the newer versions of JSPWiki for production sites, and upgrade my plugins as time permits. There are likely a lot of private plugins developed for personal or professional sites (that we never hear about) whose developers are either too busy or otherwise unavailable for updating them, and it'd be a shame to force those sites to either abandon what might be essential plugins or never upgrade. Cheers, Murray ... Murray Altheim= = === 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
Re: JSPWiki public api proposal + 2.11.0.M7 release
[...] > Thoughts? Am I missing something, should the API include more things, or > is it too wide,..? Hi Juan Pablo, As an author of a lot of plugins I'm guessing I'll have some work to do to update my code. Sorry, but I won't be able to look into this and provide any feedback until this coming weekend though as this week is pretty chocka. Cheers, Murray ... Murray Altheim= = === 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
Re: Two CSS Issues
Hi Dirk, Sometimes a second set of eyes is all it takes -- I'd not noticed that and was looking in the wrong place. Of course (in retrospect) it worked great. Thank you, Murray On 30/12/19 12:13 AM, Dirk Frederickx wrote: Hi Murray, I had a quick look. Apparently the header and footer have a fixed width of 2000px. Which makes the page much wider then the screen window. Try removing that. dirk On Sat, Dec 28, 2019 at 11:57 PM Murray Altheim wrote: Hi, I've been a bit busy with a new project, which has recently incorporated a JSPWiki-based wiki at: https://service.robots.org.nz/wiki/ The problem occurs if you push the mouse button and drag on the right edge of the window: the page will scroll to the left, exposing a black background (the element). I'm sure this has something to do with page or element size but I'm stumped. In particular, browse to a typical page with more content: https://service.robots.org.nz/wiki/Wiki.jsp?page=SiteOrganisation This doesn't happen on the JSPWiki main site so it's something I've done (admittedly) in my skin, but I can't figure where. I have based my skin on the haddock template. This seems to occur on both Firefox on Linux and Chrome on OS X -- I've not tested elsewhere. It seems worse on Chrome, depending on the page content. Also, where in the CSS is the control for where the search box popup is positioned? This isn't an error (the behaviour on my wiki is the same as Apache JSPWiki), but I'd like to move it up and to the left so that it pops up right to the left of the cursor, not below it, as I'm finding that is difficult for some users to catch it with their mouse before it disappears. Thanks much for any help, Murray BTW, if this isn't the right list for this kind of message, please let me know... ... Murray Altheim= = === 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 -- ... Murray Altheim= = === 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
Two CSS Issues
Hi, I've been a bit busy with a new project, which has recently incorporated a JSPWiki-based wiki at: https://service.robots.org.nz/wiki/ The problem occurs if you push the mouse button and drag on the right edge of the window: the page will scroll to the left, exposing a black background (the element). I'm sure this has something to do with page or element size but I'm stumped. In particular, browse to a typical page with more content: https://service.robots.org.nz/wiki/Wiki.jsp?page=SiteOrganisation This doesn't happen on the JSPWiki main site so it's something I've done (admittedly) in my skin, but I can't figure where. I have based my skin on the haddock template. This seems to occur on both Firefox on Linux and Chrome on OS X -- I've not tested elsewhere. It seems worse on Chrome, depending on the page content. Also, where in the CSS is the control for where the search box popup is positioned? This isn't an error (the behaviour on my wiki is the same as Apache JSPWiki), but I'd like to move it up and to the left so that it pops up right to the left of the cursor, not below it, as I'm finding that is difficult for some users to catch it with their mouse before it disappears. Thanks much for any help, Murray BTW, if this isn't the right list for this kind of message, please let me know... ... Murray Altheim= = === 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
Re: Plugin not compatible with this version of JSPWiki
Sorry, I found it: the jspwiki-module.xml file. Took awhile... maybe my brain isn't working too well today. Ahh, the holidays! Cheers, Murray > Hi all, > > Hopefully quick question: I just did a quick recompile of my plugin > set for a new wiki (compiled against JSPWiki v2.11.0-M5) and when I > try out a plugin on a page I get: > >Plugin 'MostPopular' not compatible with this version of JSPWiki > > I've added my package path in jspwiki-custom.properties (and it seems > to be finding the plugin) but I seem to remember something else was > necessary, just can't remember what... nor could I find this in the > documentation... > > Any ideas? > > Thanks, > > Murray > > ........... > Murray Altheim= = > === > 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 > > > > ... Murray Altheim= = === 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
Plugin not compatible with this version of JSPWiki
Hi all, Hopefully quick question: I just did a quick recompile of my plugin set for a new wiki (compiled against JSPWiki v2.11.0-M5) and when I try out a plugin on a page I get: Plugin 'MostPopular' not compatible with this version of JSPWiki I've added my package path in jspwiki-custom.properties (and it seems to be finding the plugin) but I seem to remember something else was necessary, just can't remember what... nor could I find this in the documentation... Any ideas? Thanks, Murray ... Murray Altheim= = === 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
MarkDown Support in JSPWiki [Was: (JSPWIKI-120) Separate rendering engine from core]
ds
>
> Context creation
> * WikiContext createContext( final HttpServletRequest request, final
> String requestContext )
>
> WikiEngine attributes
> * Object getAttribute( String key )
> * Object removeAttribute( String key )
> * void setAttribute( String key, Object value )
>
> URL creation [2]
> * CommandResolver getCommandResolver()
> * getURL( final String context, String pageName, final String params,
> final boolean absolute )
> * String getInterWikiURL( String wikiName )
> * String getViewURL( String pageName )
> * String getRedirectURL( final WikiContext context ) (seems unused?)
> * String getFinalPageName( String page )
> * String getSpecialPageReference( String original ) (unused?)
>
> Event Listeners / WatchDog related operations:
> * void addWikiEventListener( WikiEventListener listener )
> * void removeWikiEventListener( WikiEventListener listener )
> * WatchDog getCurrentWatchDog()
>
> [1]: Instead of exposing each getWhateverManager(), I was more thinking of
> having one getManager( Class managerClass ) method at the public API
> level, whereas the concrete class would retain all the getXYZManager, in
> order to not make an even more breaking change
> [2]: perhaps these should be moved into WikiContext ?
> {quote}
>
>> Separate rendering engine from core
>> ---
>>
>> Key: JSPWIKI-120
>> URL: https://issues.apache.org/jira/browse/JSPWIKI-120
>> Project: JSPWiki
>> Issue Type: New Feature
>> Components: Core storage
>>Reporter: Janne Jalkanen
>>Priority: Major
>> Fix For: 3.0
>>
>>
>> Quite a few people have shown up recently on the mailing list and have
>> expressed a wish to separate the rendering engine from the core itself,
>> so that they wouldn't need so much baggage with the engine.
>> Unfortunately, this is quite difficult, as the rendering engine does
>> rely on quite a few bits from the WikiEngine instance, for example URL
>> generation and checking whether a page/attachment exists or not, as well
>> as settings.
>> However, these things could be enumerated and isolated to a
>> RenderingContext interface. Then, anyone who would like to get their
>> own engine would need to implement this interface.
>> It may mean that WikiEngine and WikiContext might need to become
>> interfaces as well. However, that might not be such a bad thing, as it
>> would give a more stable developer API. Then we would have a
>> three-layered architecture, where one layer (WikiEngine) takes care of
>> static stuff, WikiContext contains per-request data, and
>> RenderingContext provides the bits and pieces which are part of HTML
>> generation.
>> At any rate, this requires more thinking. Probably not going to happen
>> before 3.0 anyway.
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.3.4#803005)
>
>
...
Murray Altheim= = ===
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
The Blue Flash
Hi, I'm not sure if this is related to a recent update or not, but I'm just putting together a new wiki site that has a style that's largely red and dark brown, a bit different than the blues I've used previously. This has pointed out either something inherent in the Haddock style or a mistake I'm making, not quite clear yet if this is a bug or just me. I've got a header background picture, and what I'm noticing is that when I do a screen refresh, prior to the header background picture loading, and prior to my skin loading, I see a brief flash of that bright blue of the Haddock template. I've tried just about everything to eliminate the blue flash, but I can't seem to shake it. I've set the background colors of most things in haddock.css to some shade of gray, trying to find out where it's getting set. No luck. Oh, I've implemented my stylesheet as a skin, not modifying haddock.css itself (apart from the aforementioned "bug fixes"). Anyone have any idea how to eliminate the blue flash? Cheers, Murray ....... Murray Altheim= = === 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
Re: [VOTE] Release JSPWiki version 2.11.0.M6
+1, looks good. On 14/12/19 4:38 AM, Harry Metske wrote: +1 thanks, Harry On Thu, 12 Dec 2019 at 22:14, Juan Pablo Santos Rodríguez < juanpa...@apache.org> wrote: This is a release vote for Apache JSPWiki, version 2.11.0.M6. The vote will be open for at least 72 hours from now. It fixes the following issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12346489 You can see a curated changelog at https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11 Note that we are voting upon the source (tag), binaries are provided for convenience. Everybody is encouraged to vote. Source and binary files: https://dist.apache.org/repos/dist/dev/jspwiki/2.11.0.M6-rc1 Nexus staging repo: https://repository.apache.org/content/repositories/orgapachejspwiki-1016 The tag to be voted upon: https://github.com/apache/jspwiki/tree/2.11.0.M6-RC1 JSPWiki's KEYS file containing PGP keys we use to sign the release: https://www.apache.org/dist/jspwiki/KEYS *** Please download, test and vote: [ ] +1 Approve the release [ ] 0 Don't mind [ ] -1 Disapprove the release (please provide specific comments) -- ... Murray Altheim= = === 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
Re: TikaSearchProvider test failing at builds.apache.org
Okay, I've had a go at this, have found the solution, or at least why it's
breaking.
Running testGetAttachmentContent() on TikaSearchProviderTest, it successfully
creates the two attachments:
./target/test-classes/testrepository1557439078377/test-tika-att/aaa-diagram.pdf-dir/attachment.properties
./target/test-classes/testrepository1557439078377/test-tika-att/aaa-diagram.pdf-dir/1.pdf
./target/test-classes/testrepository1557439078377/test-tika-att/favicon.png-dir/attachment.properties
./target/test-classes/testrepository1557439078377/test-tika-att/favicon.png-dir/1.png
and correctly updates the Lucene index for both attachments:
2019-05-10 10:06:26,979 [JSPWiki Lucene Indexer] DEBUG
org.apache.wiki.search.LuceneSearchProvider \
- Done updating Lucene index for page 'test-tika/aaa-diagram.pdf'.
2019-05-10 10:07:23,203 [JSPWiki Lucene Indexer] DEBUG
org.apache.wiki.search.LuceneSearchProvider \
- Done updating Lucene index for page 'test-tika/favicon.png'.
and successfully creates the TikaSearchProvider ('tsp').
but runs into this code
// If the page cannot be determined, we cannot possibly find the
// attachments.
//
if( currentPage == null || currentPage.getName().length() == 0 )
{
return null;
}
and hence returns a null page and then a null attachment on:
Attachment attPdf = engine.getAttachmentManager().getAttachmentInfo(
"test-tika/aaa-diagram.pdf" );
In looking at why, it's because the parent page name is "Test-tika", not
"test-tika", i.e., this is a case difference. Changing the string to "Test-tika"
allows the test to pass.
Cheers,
Murray
On 10/05/19 8:35 AM, Murray Altheim wrote:
HI Juan Pablo,
Part of what fails with Lucene is not only what version is used by the code,
but also what's available in the classpath. So you may also need to eliminate
the conflicting versions, as if Lucene can find a newer version that can also
cause a conflict. Or set both to the most recent one, Version.LATEST.
From my own Lucene version unit test:
Version.LATEST,
Version.LUCENE_7_5_0,
Version.LUCENE_7_4_0,
Version.LUCENE_7_0_0,
Version.LUCENE_6_6_5,
Version.LUCENE_6_5_0,
Version.LUCENE_6_0_0,
Cheers,
Murray
On 10/05/19 12:25 AM, Juan Pablo Santos Rodríguez wrote:
Hi Murray,
Thanks for taking a look! I was able to make an additional test, setting
jspwiki's lucene version to 7.5 (the same brought by default by tika) and
had the same outcome.
I did look at other tests retrieving attachments and PageRenamerTest grabs
them the same way. I still have to take a better look at it, though..
best regards,
juan pablo
.......
Murray Altheim = = ===
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
--
.......
Murray Altheim= = ===
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
Re: TikaSearchProvider test failing at builds.apache.org
HI Juan Pablo, Part of what fails with Lucene is not only what version is used by the code, but also what's available in the classpath. So you may also need to eliminate the conflicting versions, as if Lucene can find a newer version that can also cause a conflict. Or set both to the most recent one, Version.LATEST. From my own Lucene version unit test: Version.LATEST, Version.LUCENE_7_5_0, Version.LUCENE_7_4_0, Version.LUCENE_7_0_0, Version.LUCENE_6_6_5, Version.LUCENE_6_5_0, Version.LUCENE_6_0_0, Cheers, Murray On 10/05/19 12:25 AM, Juan Pablo Santos Rodríguez wrote: Hi Murray, Thanks for taking a look! I was able to make an additional test, setting jspwiki's lucene version to 7.5 (the same brought by default by tika) and had the same outcome. I did look at other tests retrieving attachments and PageRenamerTest grabs them the same way. I still have to take a better look at it, though.. best regards, juan pablo ... Murray Altheim= = === 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
Re: TikaSearchProvider test failing at builds.apache.org
Hi Juan Pablo, I can duplicate the error on Ubuntu 18.10, Java version: java version "1.8.0_211" Java(TM) SE Runtime Environment (build 1.8.0_211-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.211-b12, mixed mode) with: 2019-05-09 23:11:26,236 [main] DEBUG org.apache.wiki.search.LuceneSearchProvider - Scheduling page test-tika/aaa-diagram.pdf for index update 2019-05-09 23:11:26,236 [main] INFO org.apache.wiki.providers.BasicAttachmentProvider - Uploading attachment favicon.png to page test-tika 2019-05-09 23:11:26,236 [main] INFO org.apache.wiki.providers.BasicAttachmentProvider - Saving attachment contents to /home/altheim/workspace/jspwiki/jspwiki-tika-searchprovider/target/test-classes/testrepository1557400283189/test-tika-att/favicon.png-dir/1.png 2019-05-09 23:11:26,280 [main] DEBUG org.apache.wiki.search.LuceneSearchProvider - Scheduling page test-tika/favicon.png for index update [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.367 s <<< FAILURE! - in org.apache.wiki.search.tika.TikaSearchProviderTest [ERROR] testGetAttachmentContent Time elapsed: 3.358 s <<< ERROR! java.lang.NullPointerException at org.apache.wiki.search.tika.TikaSearchProviderTest.testGetAttachmentContent(TikaSearchProviderTest.java:58) [INFO] [INFO] Results: [INFO] [ERROR] Errors: [ERROR] TikaSearchProviderTest.testGetAttachmentContent:58 » NullPointer [INFO] [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 It's late here so I'll hopefully get to this again tomorrow. I still suspect instantiation somewhere inside of Lucene, where I've seen strange behaviours when multiple versions are present, including NPEs. Cheers, Murray On 9/05/19 9:46 PM, Juan Pablo Santos Rodríguez wrote: Hi, Made some updates, as I was able to grab an Ubuntu box. The build seems to fail, consistently, on ubuntu. Regarding the NPE, the SearchManager (tsp on the test) is *not* null, but the attachment is. Oddly this only happens on ubuntu. I'll try to debug some more, but I've limited access to this box, so extra eyes are more than welcome. br, juan pablo El mar., 7 may. 2019 0:24, Juan Pablo Santos Rodríguez < juanpablo.san...@gmail.com> escribió: My daily update on this: definitely, seems something is weird on the ubuntu nodes; I've been trying several combinations of JDK 8, maven installations, increasing the -Xmx through MAVEN_OPTS, and all failed, on ubuntu nodes. I've modified the build to run on windows nodes, and suddenly there aren't any problems. I've also tried on my local pc (windows based) with several JDK 8 and memory settings and haven't been able to reproduce the test failure. I'll try tomorrow on an Ubuntu box at work to see if I can reproduce the test failure. Meanwhile, has anybody been able to reproduce it? What do we do with the build process? Comment out the test, move it to Windows nodes,..? best regards, juan pablo On Sun, May 5, 2019 at 11:44 PM Juan Pablo Santos Rodríguez < juanpablo.san...@gmail.com> wrote: Hi, hmm, didn't realize that Tika and JSPWiki pull different versions (7.5.0 and 8.0.0). However, JSPWiki "forces" it's Lucene version to Tika via dependencyManagement section in pom, so when pulling the dependencies only Lucene 8 appears in classpath for both JSPWiki and Tika. We could have binary incompatibilities down the line, but I think we are not using Tika enough for them to appear. Also, there are occasions of tests failing where Tika isn't even loaded in memory (https://builds.apache.org/job/jspwiki-test/18/console). Tests which have been running for ages, and with NPEs on objects that are obviously not null at that point.. Tika related code runs ok, the error comes on an NPE afterwards. Weirder, the offending test fails with: [ERROR] testGetAttachmentContent Time elapsed: 3.892 s <<< ERROR! java.lang.NullPointerException at org.apache.wiki.search.tika.TikaSearchProviderTest.testGetAttachmentContent(TikaSearchProviderTest.java:58) being the offending line: String pdfIndexed = tsp.getAttachmentContent( attPdf ); and tsp being loaded as: TikaSearchProvider tsp = ( TikaSearchProvider )engine.getSearchManager().getSearchEngine(); (so, only tsp could yield the NPE) I modified the Jenkinsfile to perform a sed on that test so the above line gets replaced by: TikaSearchProvider tsp = new TikaSearchProvider();tsp.initialize( engine, props ); tsp *cannot* be null beyond that point.. But it is: https://builds.apache.org/job/jspwiki-test/19/ shows the same NPE on the same line yielding it as before. Perhaps is that the build is running with a very adjusted memory setting (i.e.: the default maven setting is not enough for the jspwiki build?). Will keep digging tomorrow.. best regards, juan pablo On Sun, May 5, 2019 at 10:50 PM Murray Altheim wrote: Hi Juan Pablo, My suspicion is still relate
Re: TikaSearchProvider test failing at builds.apache.org
Hi Juan Pablo, My suspicion is still related to there being two Lucene engines in the mix. If JSPWiki and Tika use *different* versions of Lucene there will be two Lucenes the classpath, and I've personally had all sorts of issues with Lucene instantiating when two components both use it (I seem to remember the "Version" can't be resolved, or something like that). Put it this way: I've noted that two Lucene engines in the same project might not like each other too much. I think I might have even had problems if they use the same version number there can be contention. So when I heard something in Tika related to Lucene was popping an NPE it set off my Lucene Alarm... But I've got some time this week so I'll be trying out the latest release, hopefully in the next few days. Cheers, Murray On 6/05/19 8:42 AM, Juan Pablo Santos Rodríguez wrote: Hi Murray, thanks for looking into it :-) My findings so far: Lucene index related test are already in the main build, so that part should be covered, and regarding the Tika-related ones, they don't interact with Lucene, they only parse a couple of files, and check the extracted information (which is afterwards sent to Lucene, but that's outside the scope of the test). I was suspecting of something weird on the node in which the build kept running and made a new Jenkins job to do some tests (and avoid spamming dev@j.a.o) at https://builds.apache.org/job/jspwiki-test/ [...] ....... Murray Altheim= = === 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
Re: [jira] [Updated] (JSPWIKI-1040) Add new markup (%%% ... /%) for marking plain-text sections
Hi Juan Pablo, I'm sorry to say but no, (I'm smiling while I write this), your last message didn't clear up (for me) your intention. You seem to indicate that you believe this particular proposal wouldn't break existing installations, but that cannot be known. So while I appreciate your approach to the question, you seem to be agreeing with me in saying that "if the proposed markup breaks existing installations, I'd be a big no-no of bringing it in". So maybe I was the one not being very clear. I'll try again: Because JSPWiki has been around for around 20 years*, we can't know the extent of user customisations/modifications and plugins that people are actually using, as there's no requirement that users publish or publicise their customisations. JSPWiki has from the beginning been promoted as a "programmer's wiki" so it's likely been customised for various purposes. I've certainly made many, many customisations (though always via plugins that didn't modify the main syntax, though that's anyone's option). I'm deliberately taking a very conservative approach here, to represent the interests of these unknown users. And in doing that I'm proposing a policy for the group: that *any* syntax changes on a 20 year old project should be permitted (and perhaps default enabled), but be optional. Since this isn't difficult to implement I don't think it unreasonable. This would be to require that, even if the default for the new syntax is enabled, there'd still be an option to disable it in jspwiki-custom.properties. In this way we can continue to make changes to syntax (and continue to improve JSPWiki without being held back by existing implementations) but still permit existing users to disable those features if they find them incompatible with their existing, customised installations. Is that any clearer? Cheers, Murray * version 1 of the About page on ecyrd.com was from 2001 but I think the project is older, maybe circa 1999, we'd have to ask Janne. There's a review of it in 2001 on http://wiki.c2.com/?JspWiki > Hi Murray, > > having to edit wiki-pages in order to comply with the new markup is indeed > a strong hint to not push newly proposed > markup, or at least make it optional. On this particular case however, old > versions of the markup would render > "incorrect" text, that is, the expected and the actual output diverge > enough that most probably the proposed syntax > isn't currently used; hence, in this particular case, I'm more inclined to > not make it optional. > > Re-reading my first e-mail, it seems that I don't prefer optional markup > at > all, but that was poorly expressed, I was > thinking only on the new proposed markup, not as a general rule. > > Of course, if the proposed markup breaks existing installations, I'd be a > big no-no of bringing it in, or at least, as > you say, make it optional (and defaulted to not activating it). Anything > subject to break existing markup should be > optional and deactivated by default (IMO), or even published as another > MarkupParser, but again, in this particular > case I'm not thinking that existing markup would need to be rewritten. > Hope > I make more sense now.. > > > cheers, > juan pablo > > > On Fri, Apr 12, 2019 at 12:11 AM Murray Altheim > wrote: > >> Hi Juan Pablo, >> >> I think this really comes down to a policy decision, insofar as in the >> history >> of this project we've come upon similar decisions, but to my memory I >> can't >> think of how we've resolved them. >> >> So yes, we can always recommend implementers/installers read the change >> logs >> and documentation, but if someone has a existing installation of wiki >> pages >> that this proposal would be in conflict with, that would put that site >> into >> a situation where they'd likely not be able to ever upgrade to the next >> version of JSPWiki unless they could somehow edit all those pages, which >> in >> practicality means (probably) never. The alternative would be to be able >> to >> disable this new feature. >> >> So I'm happy to amend my original proposal, which is to have this as an >> option, but the default is enabled. That way, anyone in the situation >> where >> a syntax change would create conflicts they could at least upgrade to >> the >> latest version of JSPWiki and simply disable the feature. >> >> Would that be too onerous? (Frankly, obviously, I have no idea if there >> are >> any users out there where this would be a conflict, but I'm suggesting a >> policy decision where any new syntax features/changes would have an >> enable/ >> disable flag rather than simply be included). >> >> Cheers, &g
Re: [jira] [Updated] (JSPWIKI-1040) Add new markup (%%% ... /%) for marking plain-text sections
Hi Juan Pablo, I think this really comes down to a policy decision, insofar as in the history of this project we've come upon similar decisions, but to my memory I can't think of how we've resolved them. So yes, we can always recommend implementers/installers read the change logs and documentation, but if someone has a existing installation of wiki pages that this proposal would be in conflict with, that would put that site into a situation where they'd likely not be able to ever upgrade to the next version of JSPWiki unless they could somehow edit all those pages, which in practicality means (probably) never. The alternative would be to be able to disable this new feature. So I'm happy to amend my original proposal, which is to have this as an option, but the default is enabled. That way, anyone in the situation where a syntax change would create conflicts they could at least upgrade to the latest version of JSPWiki and simply disable the feature. Would that be too onerous? (Frankly, obviously, I have no idea if there are any users out there where this would be a conflict, but I'm suggesting a policy decision where any new syntax features/changes would have an enable/ disable flag rather than simply be included). Cheers, Murray > Hi, > > I'd prefer not to have optional markup, as it would lead to more complex > setups / things to have in mind when > setting up JSPWiki. Also we're in the middle of transitioning to 2.11 so > breaking changes should be expected, > as long as their clearly depicted on the NewIn.. page. > > Also, in this particular case the alternative feels cumbersome, so it > looks > to me as a welcome addition, and > is likely to break not too much wikipages (%%% not being a typical text > for > a wiki page). Again, in this case, > people upgrading should check the NewIn.. page for all kinds of changes. > In > any case, that's my opinion only, > what do you people think? > > best regards, > juan pablo ....... Murray Altheim= = === 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
Re: [jira] [Updated] (JSPWIKI-1040) Add new markup (%%% ... /%) for marking plain-text sections
Hi,
I'm fine with this proposal so long as it's a feature with a default of
false. As JSPWiki has been around for a very long time and has had a
lot of bespoke extensions created by people (many or most we may not even
know about) it's possible that a change of syntax like this could break
existing installations, where a plugin or extension isn't prepared for a
change of syntactical interpretation, such as a triple-"%".
For those who want this new feature it could be enabled by setting a
property in jspwiki-custom.properties. That would be the safe approach.
Principle of least surprise, etc.
Cheers,
Murray
> https://issues.apache.org/jira/browse/JSPWIKI-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> brushed updated JSPWIKI-1040:
> -
> Summary: Add new markup (%%% ... /%) for marking plain-text sections
> (was: Add new markup (%%% ... /%%) for marking plain-text sections )
>
>> Add new markup (%%% ... /%) for marking plain-text sections
>>
>>
>> Key: JSPWIKI-1040
>> URL: https://issues.apache.org/jira/browse/JSPWIKI-1040
>> Project: JSPWiki
>> Issue Type: Improvement
>> Components: Core storage
>>Reporter: brushed
>>Priority: Minor
>>
>> JSPWiki uses the following pattern to mark a block of text, to apply
>> different styles (eg. %%info) or as a trigger for a javascript handler
>> adding certain behaviour (eg. %%viewer)
>> {noformat}
>> %%... /%
>> {noformat}
>> Note that the text inside the %% block continues to be parsed as regular
>> JSPWiki text. (eg. \[links] are properly converted to ; explicit
>> line-breaks, etc...)
>> For some use-cases, it would be convenient to be able to mark certain
>> sections in a page indicating that the text inside the section should
>> NOT be parsed by JSPWiki.
>> This is similar to a pre-formatted text block enclosed in triple curly
>> braces but then with different styling.
>> Today's workaround is to try to escape any possible markup conflict
>> (with tilde character) or to combine both syntaxes like this:
>> {noformat}
>> %%
>> {{{
>> ...
>> }}}
>> /%
>> {noformat}
>> Both solutions are cumbersome and not trivial to the user.
>>
>> The proposed syntax is to use a triple % sign:
>> {noformat}
>> %%%
>> plain vanilla text, remains unparsed by jsp-wiki
>> /%
>> {noformat}
>> Example use-case:
>> - mark a block of Tex/LaTeX syntax, and have some JS to render the math
>> - add an exotic markup language converter written in javascript
>> (markdown, pod, ...)
>> - etc.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)
>
>
...
Murray Altheim= = ===
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
Re: [jira] [Commented] (JSPWIKI-469) Enhance LuceneSearchProvider for other Attachments
Hi Ulf, While I understand the desire to index PDF, I agree that Tika will increase the jar load of the application quite substantially, so this decision should be considered quite carefully. I've myself avoided Tika for this reason (in one case it would have made my deployable application many times larger than my own code). Cheers, Murray > [ > https://issues.apache.org/jira/browse/JSPWIKI-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800635#comment-16800635 > ] > > Ulf Dittmer commented on JSPWIKI-469: > - > > A year later than I had hoped I was finally able to get back to this, and > it turned out to be easier that I had feared. The TikaParser class is > attached, it compiles against 2.11.0.M2 > > jspwiki-main needs this dependency (which will draw in a LOT of other > dependencies): > > Â Â Â org.apache.tika > Â Â Â tika-parsers > Â Â Â 1.20 > > >> Enhance LuceneSearchProvider for other Attachments >> --- >> >> Key: JSPWIKI-469 >> URL: https://issues.apache.org/jira/browse/JSPWIKI-469 >> Project: JSPWiki >> Issue Type: Improvement >>Reporter: NicolaFischer >>Assignee: Florian Holeczek >>Priority: Minor >> Fix For: FutureVersion >> >> Attachments: TikaSearchProvider.java, patch.txt >> >> >> LuceneProvider should index more filestypes then only plain text. This >> is one attempt to index pdf-files. >> Required jars: >> * [Apache POI|http://ftp.tpnet.pl/vol/d1/apache/poi/release/bin] (not >> tested with 3.0.1 final) >> * [PDFBox|http://www.pdfbox.org] >> * [FontBox|http://www.fontbox.org] >> * >> [OpenDocumentTextInputStream|http://books.evc-cit.info/odf_utils/index.html] >> Patch attached for 2.8.1 >> Maybe we should check how to index more documents. > > > > -- > This message was sent by Atlassian JIRA > (v7.6.3#76005) > > ... Murray Altheim= = === 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
Re: [VOTE] Release JSPWiki version 2.11.0.M2
My apologies, I won't have time in the next few days to test the release thoroughly but it built fine on Ubuntu 18.04 LTS on Java 8 and I don't want to hold up the show, so: +1 >> This is a release vote for Apache JSPWiki, version 2.11.0.M2. The >> vote will be open for at least 72 hours from now. ... Murray Altheim= = === 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
Re: [VOTE] Release JSPWiki version 2.11.0.M1
Hi Juan Pablo,
With your notes and the JIRA issue I'm
+1
Thanks very much,
Murray
> Hi Murray
>
> I think it's a valid concern, although I think it's enough (for this
> release) with the prominent section noting
> this at https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11 This link
> will be sent on the announce
> mail so downstream users should see it and avoid potential hassles. Also,
> as per release numbering,
> changes should be expected when migrating to this version.
>
> Lastly, later tonight I'll open a JIRA so this doesn't get lost and gets
> properly fixed with references to
> Dirk's suggestions.
>
> WDYT?
>
> br,
> juan pablo
>
> On Mon, Jan 28, 2019 at 9:39 AM Murray Altheim
> wrote:
>
>> Here's a possible solution. In WikiContext there's a method named
>> setDefaultTemplate(HttpServletRequest) that has a FIXME note, to the
>> effect that we need to check for the existence of the template
>> directory.
>>
>> If we were to replace the beginning of the WikiContext.java file with:
>>
>> public class WikiContext
>> implements Cloneable, Command
>> {
>> /**
>> * The name used for the default template. The value is {@value}.
>> */
>> public static final String DEFAULT_TEMPLATE_NAME = "default";
>>
>> ...
>> privateString m_template = DEFAULT_TEMPLATE_NAME;
>> ...
>>
>> and the beginning of the setDefaultTemplate() method with:
>>
>> protected void setDefaultTemplate( HttpServletRequest request )
>> {
>> String defaultTemplate = m_engine.getTemplateDir();
>>
>> // check to see if the template directory actually exists
>> if ( !templateDirectoryExists( m_engine, request ) ) {
>> defaultTemplate = DEFAULT_TEMPLATE_NAME;
>> }
>> ...
>>
>> and provide this utility method, which returns true if it finds
>> ViewTemplate.jsp
>> in the template directory specified in the property file:
>>
>> /**
>> * A test to see if the template directory specified in the wiki's
>> properties actually
>> * exists.
>> *
>> * This checks the existence of the ViewTemplate.jsp file,
>> which exists in every
>> * template.
>> *
>> * @param engine the WikiEngine
>> * @param request the HttpServletRequest used to obtain the real
>> path
>> * @return true if the template directory exists on the server
>> */
>> private boolean templateDirectoryExists( WikiEngine engine,
>> HttpServletRequest request )
>> {
>> File templatesDir = new
>> File(request.getServletContext().getRealPath("/"), "templates");
>> File templateDir = new File(templatesDir,
>> engine.getTemplateDir());
>> File viewTemplateJsp = new File(templateDir,
>> "ViewTemplate.jsp");
>> return viewTemplateJsp.exists();
>> }
>>
>> Would that do?
>>
>> Yes, I can either provide the changed file or a patch, but the above is
>> the gist of it.
>>
>> I haven't quite understood the responses so far, i.e., whether or not
>> this is considered serious enough to warrant not going forward. As I
>> mentioned my downvote is open to change. The above suggestion could go
>> in the next version...
>>
>> Cheers,
>>
>> Murray
>>
>> .......
>> Murray Altheim= =
>> ===
>> 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
>>
>>
>>
>>
>
...
Murray Altheim= = ===
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
Re: [VOTE] Release JSPWiki version 2.11.0.M1
Here's a possible solution. In WikiContext there's a method named
setDefaultTemplate(HttpServletRequest) that has a FIXME note, to the
effect that we need to check for the existence of the template directory.
If we were to replace the beginning of the WikiContext.java file with:
public class WikiContext
implements Cloneable, Command
{
/**
* The name used for the default template. The value is {@value}.
*/
public static final String DEFAULT_TEMPLATE_NAME = "default";
...
privateString m_template = DEFAULT_TEMPLATE_NAME;
...
and the beginning of the setDefaultTemplate() method with:
protected void setDefaultTemplate( HttpServletRequest request )
{
String defaultTemplate = m_engine.getTemplateDir();
// check to see if the template directory actually exists
if ( !templateDirectoryExists( m_engine, request ) ) {
defaultTemplate = DEFAULT_TEMPLATE_NAME;
}
...
and provide this utility method, which returns true if it finds
ViewTemplate.jsp
in the template directory specified in the property file:
/**
* A test to see if the template directory specified in the wiki's
properties actually
* exists.
*
* This checks the existence of the ViewTemplate.jsp file,
which exists in every
* template.
*
* @param engine the WikiEngine
* @param request the HttpServletRequest used to obtain the real path
* @return true if the template directory exists on the server
*/
private boolean templateDirectoryExists( WikiEngine engine,
HttpServletRequest request )
{
File templatesDir = new
File(request.getServletContext().getRealPath("/"), "templates");
File templateDir = new File(templatesDir, engine.getTemplateDir());
File viewTemplateJsp = new File(templateDir, "ViewTemplate.jsp");
return viewTemplateJsp.exists();
}
Would that do?
Yes, I can either provide the changed file or a patch, but the above is
the gist of it.
I haven't quite understood the responses so far, i.e., whether or not
this is considered serious enough to warrant not going forward. As I
mentioned my downvote is open to change. The above suggestion could go
in the next version...
Cheers,
Murray
.......
Murray Altheim= = ===
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
Re: [VOTE] Release JSPWiki version 2.11.0.M1
Hi all. > This is a release vote for Apache JSPWiki, version 2.11.0.M1. The vote > will be open for at least 72 hours from now. -1. I've successfully built, installed and fired up a wiki based on 2.11.0.M1. Everything works as it should. I was even able to do a one-liner change to common-headers.jsp and get my own supplemental stylesheet to work nicely. I'm downvoting for one reason: any users (such as myself) who (mistakenly) re-use their existing jspwiki-custom.properties file, or as I did, copy my "custom" properties across to the new file, will get a template-less result (a white page with the LeftMenu at the bottom of the screen and the page-content even further down) if they neglect to set the template name from 'haddock' to 'default' or leave the property commented-out. This might flummox some admins and isn't a friendly behaviour. Perhaps when the template name in the property file fails JSPWiki should fall back to the default template rather than fail outright? At very least there should be a note in the change log indicating that 'haddock' no longer works as a template name. This is kinda an edge case; I don't really want to downvote and delay things but this does seem like a minor bug. I'm open to changing my vote, BTW, i.e., I'm easily convinced that a note in the change log would suffice, more wanting to see how you folks feel about this. Cheers, Murray ....... Murray Altheim= = === 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
'Ne' Wiki Plugins
Hi all, This is a announcement of plans to begin releasing a set of wiki plugins and services related to those plugins, including tagging, page 'events' (e.g., for building a timeline), form handing via a JAX-RS WikWebService, which also provides endpoints for building a graph of the wiki with Neo4j and can be easily expanded. Spring Boot compatible but no Spring Boot dependency. These include older plugins I wrote as far back as 20 years ago, some with and/or by John Volkar (such as the QueryPlugin, AggregatePlugin and TranscludePlugin), but many are new and almost all have been updated in some way. Those that may have security or performance implications may now extend a RestrictedWikiPlugin abstract class, which provides the ability to enable, disable, or restrict access based on user-asserted, authenticated or 'open-wiki' (a configuration flag) status, as set in the JSPWiki configuration file. Absent explicit configuration, a RestrictedWikiPlugin is disabled. So these plugins are all disabled by default. There are over 30 plugins and I'll begin releasing the ones that have either no or low impact first, gradually adding the more complicated stuff. There is documentation for all as wiki pages. See: https://jspwiki-wiki.apache.org/Wiki.jsp?page=NeWikiPlugins for more details. I'll begin posting the pages for each as they're pushed into the repository. Once the TagPlugin is in the repository and we use it on the JSPWiki web site I can add tagging to the pages. BTW, there is a definition of 'ne' on the wiki page. More info as time permits... Cheers, Murray ... Murray Altheim= = === 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
Re: [VOTE] Release JSPWiki version 2.11.0.M1
+1 > This is a release vote for Apache JSPWiki, version 2.11.0.M1. The vote > will > be open for at least 72 hours from now. > > It fixes the following issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12343348 > > Note that we are voting upon the source (tag), binaries are provided for > convenience. > > Everybody is encouraged to vote. > > Source and binary files: > https://dist.apache.org/repos/dist/dev/jspwiki/2.11.0.M1-rc1 > > Nexus staging repo: > https://repository.apache.org/content/repositories/orgapachejspwiki-1007 > > The tag to be voted upon: > https://github.com/apache/jspwiki/tree/2.11.0.M1-RC1 > > JSPWiki's KEYS file containing PGP keys we use to sign the release: > https://www.apache.org/dist/jspwiki/KEYS > > *** Please download, test and vote: > > [ ] +1 Approve the release > [ ] 0 Don't mind > [ ] -1 Disapprove the release (please provide specific comments) > ... Murray Altheim= = === 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
Re: Some dev questions getting started again...
[My apologies, I wasn't meaning to burden the group with that message; nothing in it is a secret. Just a mistake due to trying to post during my lunch hour while using a rather sorry excuse for a webmail.] If I can find the time I'll post a better description of the provider project. For now I'm simply trying to get myself up and running to post the wiki plugins described a bit earlier. Cheers, Murray > [offline] > > Hi Juan Pablo, > > Thanks for the info, that's very helpful. I've updated my Eclipse from > the master but still get one error, a generics mismatch on rss.jsp. But > for whatever reason that's there it won't stop me from continuing. > > It does sound like I should work from a branch though, not necessarily > for the plugins, but for the providers, as there might be some contention > there. How does one go about creating a branch, and what might be an > appropriate name? > > To give you an idea of what I'm working on, it's a set of three providers, > based on a text-based format for wiki pages called a "Ned" (as my parent > project is called 'ne' and it's referred to as a "ne node"), A Ned is a > text format, using a model influenced by the original Macintosh file > format, > which divided the file content into a "resource fork" (file metadata) and > a > "data fork" (file content). This uses an untypeable delimiter character to > separate the forks. > > I've currently got four providers, three of which are finished: > > 1. an in-memory provider for testing only > 2. a Berkeley DB JE based provider > 3. a Neo4j Embedded graph database provider > 4. a Neo4j OGM graph database provider (unfinished) > > It wouldn't be too difficult to develop a file-based provider since there > are already Ned serialiser and deserialiser methods in the code. > > The Neo4j providers have a 32K data limitation on any single property, > (due to a current limitation in Neo4j) so wiki pages over 32K get > segmented > and re-built when pulled from the repository. > > Full-text and field-based search is currently via Lucene using a separate, > non-JSPWiki API, not sure what to do about that. > > I haven't advertised this project to the group yet because I'm not sure > I'll > have enough time to actually convert it over to JSPWiki and get it up and > running on my own. I can probably publish some of the plugins but the > providers are a significantly larger venture. While the benefits of a > graph > database backend for a wiki may be apparent to some, the Berkeley DB > version > is probably enough of a win to promote the basic Ned project, even without > the Neo4j providers. It's exceedingly fast and is a very stable DB. > > This all comes out of a project called 'ne', a CLI-based application I've > written to capture and store text-based notes. Basically, the idea is that > one could write notes that are easily turned directly into wiki pages, > without needing to use a wiki. Ne also has a directory watcher that can > auto-ingest anything dropped into it. It's got more features than that, > suffice it to say that the Neo4j providers are coming out of ne's storage > backend, which is an embedded Neo4j. > > Ne's metadata model is configurable via a JSON file. Ne uses a more > complicated model than JSPWiki but they're by design compatible. > > As you may imagine, the enemy in all this is, as always, time available. > > ...enough for now. ... Murray Altheim= = === 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
Re: Some questions on proposed JSPWiki plugins
> Hi Murray! Hi Juan Pablo & Andrew, Nice to see you're still on the team. You guys are very dedicated! > you're still on the PMC, so you are not only able to commit, but your vote > on releases is binding too :-) Yikes! > As the source lives now on Github, you may have to enable 2FA between your > Apache ID and your Github ID (detailed instructions at [#1]). Okay, thanks -- I'll check up on that. > Other than that, you shouldn't have any problems pushing code; if there's > any problem though, please ping me and I'll try to fix whatever needed ASAP. > > As for the plugins, I'd be +1 to host them on the main distribution. I have no reason not to host on GitHub, and I guess you've answered my question about whether to package them as org.apache.wiki.plugin.* or under my own net.neocortext.wiki.plugin.*. I'd thought of them as "contributed plugins" but if the team is happy to have them under the main distribution I'm certainly fine doing that. It's easier for me as well. I'll probably start by creating a wiki page for the new plugins so that they can be identified (at least initially) as new and have their own web pages (for tests, demos, etc.) as such. When we're ready to consider having each one as part of the main distribution we can change that initial page to then point to the main plugin page. I'll probably select a few of the very simple ones as a first set, then add the more complicated ones after that. My band has a recording session this weekend so I probably will be busy for the next few days but I'll get going on the plugins. Good to be back, Murray ........... Murray Altheim= = === 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
Some questions on proposed JSPWiki plugins
Hello. It's been awhile since I've been involved in the project and I'm not sure if I'm even still on the committer's list or not. I've got some space and some of my own requirements that involve work on JSPWiki plugins, both updating old ones I wrote years ago and some new ones. This would/could include navigation plugins, the ability to do tagging and querying on tags via plugins, and likely some plugin- based text compiling functionality (e.g., you could write a book as a set of wiki pages and compose the result as a single document, sorta like XML named entities), etc. I'm writing to inquire about how the group thinks I might best go about contributing and publishing these. I've thought about publishing on GitHub, on some pages on JSPWiki (as we used to do), or my own personal web pages. The work would be open sourced and I'm not particularly fussed about details, i.e., I could do this work privately (as it's really my own agenda driving it) but I'm happy to share. Cheers, Murray ... Murray Altheim= = === 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
