Hi devs,
https://github.com/xwiki-contrib/ is starting to be crowded with
archiving purpose repositories so it would be nice to move them
somewhere else to have less noise.
"attic" naming refer to https://attic.apache.org/
Here is my +1
--
Thomas Mortagne
Hi devs,
I’d like to propose that we bundle the Syntax Highlighting Extension in the Standard flavor, starting with XWiki 9.7RC1.
Rationale:
* No impact for simple users (ie the default)
* For advanced users, it makes editing pages using the wiki editor much nicer
* It’s already a recommended extension on e.x.o and I’m willing to continue supporting it (and I’m sure Edy is interested in doing that too - Right Edy?)
See http://extensions.xwiki.org/xwiki/bin/view/Extension/Syntax%20Highlighting%… for more details.
TBH I don’t really understand why we haven’t bundled this a long time ago.
Does anyone see any issue in bundling it?
Thanks
-Vincent
The XWiki development team is proud to announce the availability of XWiki
9.6 Release Candidate 1.
This release brings improvements to Notifications, like live email
notifications, the ability to get notifications through RSS feed or to
override their default display. It is now possible also to generate Table
of content for another page, or to define optional extension dependencies
so they can be uninstalled by the Extension Manager.
You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/9.6RC1/
Thanks for your support
-The XWiki dev team
Good day to all.
First, a quick update on the current status of the redpen extension:
It is now renamed as Content Checker, in consideration of implementing other
document checking technology in the future. Also content checker's results
are currently shown as logs, and the messages are split into warnings and
errors. Also, during automatic validation of a document on save, if an error
exists, the save is canceled.
Next, I am in the middle of adding most of the available validators from
redpen as a configurable setting. However there are validator settings that
require a dictionary i.e. Invalid words, suggested words and expressions. To
this end, I plan to reformat the application homepage, to add a select field
before the user enters into the text input fields, indicating whether the
entry for invalid words or for suggested words and expressions.
Further, I have been looking for a way to extract the live table data within
Java, but have been unable to. Is there a way to do it?
Lastly, as the number of validation settings pile up, I plan to reformat the
UI of the configurable class of my app to one that is tabbed, like the
WYSIWYG configurable class in the administration wiki, to achieve a cleaner
look.
I would greatly appreciate any comments on the above implementation plans,
thanks!
--
View this message in context: http://xwiki.475771.n2.nabble.com/GSOC-Update-4-Design-RedPen-Integration-t…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi,
We’ve been having 3 persons in the community who help test XWiki every day and who report jira issues: Ilie, Gabriela and Manuel. Manuel has been doing this over 4 years now (close to 5 actually)!
They’re important and they help XWiki get better every day and release over release.
I think we should recognize them more in the project.
I have 2 ideas:
* Mention this role of QA engineer on http://dev.xwiki.org/xwiki/bin/view/Community/HallOfFame and make it more “official"
* Make them visible in the RN. Right now in the RN we mention everyone who contributed code. I think we could also mention everyone who created a JIRA issue that got fixed during that release.
WDYT? Any other idea?
Thanks
-Vincent
PS: I forgot if I already sent a mail on this topic or not (couldn’t find one but it vaguely rings a bell). Anyone remembers? :)
Hi everyone,
I just implemented https://jira.xwiki.org/browse/XCOMMONS-1229 which
allows to indicate that a dependency will be installed by default but
does not have a string dependency link with the extension, meaning
that uninstalling it won't impact the backward dependencies (so they
are not really backward dependencies in that case :)).
Now we need to decide what exactly is optional in Standard flavor.
Here are some ideas:
* application-help-center
* xwiki-platform-menu-ui
* xwiki-platform-wiki-ui-mainwiki
* xwiki-platform-office-ui
* xwiki-platform-invitation-ui
* xwiki-platform-appwithinminutes-ui
* xwiki-platform-linkchecker-ui
* xwiki-platform-sandbox
* xwiki-platform-sharepage-ui
* xwiki-platform-distribution-flavor-tour
* application-templates-ui
I did not actually tried to uninstall those so it's possible it's not
a good idea to uninstall some of them right now (hardcoded use
somewhere maybe).
WDYT ?
--
Thomas Mortagne
Hi devs,
We’ve moved the register/login buttons inside the drawer. However one consequence is that users don’t notice it anymore.
I’d like this thread to be a brainstorming about what we could do about it and whether you agree it’s an issue that we need to fix.
Ideas?
One idea could to reuse the Avatar image location to have some icon to register/login when not logged in.
WDYT?
Thanks
-Vincent
Hi devs,
So we now have the concept of optional dependencies at Extension
Manager level. This are dependencies that are installed by default
(but if they fail they don't fail the whole install) and which can be
uninstalled without any impact on what is no longer it's backward
dependency.
On Maven -> EM side what I did is reuse <optional>true</optional>
mostly the following reason: there is no way in pom.xml to put custom
stuff in <dependency> so it would be a huge pain to maintain a list of
optional dependencies from a property at general pom level.
The issue is that the behavior of this <optional> is not exactly the
same in EM and Maven: in Maven those dependencies are NOT triggered by
default. Still, apart from this it's supposed to be the same meaning
and it should not be an issue to install this dependency (if it is
then it means you should have used something else like
<scope>provided</scope>) but as usually since there is no official way
in Maven to say "I just want to use that during the build and it does
not make any sens to get this dependency" some projects may have used
it that way.
So do you think it is OK ? It's not acceptable and we absolutely need
to move this kind of information in some general property in the pom
<properties> ?
--
Thomas Mortagne