Hi devs,
Another idea for this roadmap is if we want to bundle the Menu App inside
XWiki.
I've tried to list the current issues at:
http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaDefaultMenu
with a proposal for a default menu instance.
WDYT?
Thanks,
Caty
Hi devs,
In the 9.2 roadmap we developed a Help Center in
http://jira.xwiki.org/browse/HELPCENTER-1 that showcases the major XWiki
concepts (templates, macros, apps, etc.) to newcomers.
Currently the idea is to bundle the Help in XWiki, in order to be
accessible from the start, without the need of a manual install.
I've describe the major issues with the bundling here:
http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaDefaultHelp
WDYT?
- Should we bundle it even if we have "Issue 1: Uninstallable"? Should we
fix it first?
- What about the other issues? Do you see any other problems?
Thanks,
Caty
The XWiki development team is proud to announce the availability of XWiki
9.3.
This release brings a couple of small, but very useful improvements like:
* the ability to filter the sections in Administration,
* reset changes done to extension pages and
* alternative configuration locations.
Developers also get:
* some helpful API in writing clean queries when escaping and filtering,
* a new API to find documents belonging to extensions and
* more control through a new extension point for the content menu
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.3
Thanks for your support
-The XWiki dev team
Hi,
I want to connect local maven repository Extension Manager (and so
Extension Repository) according to http://platform.xwiki.org/
xwiki/bin/view/DevGuide/CreatingExtensions/#HUsingtheExtensionManager
In 'xwiki.properties' I put following line:
*extension.repositories=maven-local:maven:file:///C:/Users/Krzysztof/.m2/repository/*
It was discovered by XWiki since in Repository Application it's visible:
http://i.imgur.com/ep9yazr.png
When I try to import extension from local repository (that is present
there) I get exception: http://i.imgur.com/PucSgOL.png
Full stack trace: https://pastebin.com/iUnJ29wm
What may be the problem? Url to local repository (
*file:///C:/Users/Krzysztof/.m2/repository/)* is ok since when I paste it
in browser I can access this directory flawlessly.
I'm working on Windows. (url with backslashes, escaped or not, is not
recognized by xwiki)
Thanks in advance!
Krzysztof
Hi devs,
The idea today is to do a Test Day with priority to fixing long
standing flickering (integration mostly) tests.
You can find known flickering tests on
http://jira.xwiki.org/issues/?filter=14240. The goal is to really fix
them, not just add some random wait here and there ;)
If you are not confident with the area around those specific
flickering tests here are some other ideas for this kind of Day:
* obviously add more tests and increase the code coverage
* move tests from enterprise to platform. Needed for the platform
flavor and removal of XE
* update jacoco covering setup (we often forget to increase it when
adding more tests)
* move more tests from JMock to Mockito
* work on new test setups and tools:
** improve docker containers for packaging XWiki (possibly several for
multiple DBs and Servlet containers).
** work on spreading Jenkins platform job into one job per maven
module so that build can be spread on various agents (groovy
scripting)
** Research/Use Jenkins 2 Pipeline plugin with the new DSL and commit
the jenkinsfile in SCM
** Test platform to run contrib extension tests on various versions of
XWiki automatically
* Speedup existing tests (research xwiki startup time, remove
unnecessary modules, etc)
When what you fix can be linked to an issue, tag it with "testday"
(same idea as "bugfixingday" when doing BFD). If not then answer to
this mail to explain what you did.
Good Test Day !
The XWiki development team is proud to announce the availability of XWiki
9.3 Release Candidate 1.
This release brings a couple of small, but very useful improvements like
the ability to filter the sections in Administration, reset changes done to
extension pages and alternative configuration locations. Developers get
some helpful API in writing clean queries when escaping and filtering, a
new API to find documents belonging to extensions and more control through
a new extension point for the content menu.
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.3RC1
Thanks for your support
-The XWiki dev team
Hi,
Two days before I downloaded the application-blog repository from github on
my pc. In order to check whether the changes I make in the repository(on my
pc) are visible while running the localhost on browser, I made some changes
in the ui of the application blog.
(I tried to change the color of the 'date' text on top of blog page, I
tried to increased the font size of title, I tried to shift the position of
blog-button-toolbox ).
But I think these changes are not visible to me on localhost after
building the whole repository again.
The process that I follow is:
- Going to the application-blog directory.
- going to application-blog-ui
- making changes in BlogStyle.xml and saving them.
- going back to application-blog directory.
- mvn clean install.(100% success)
- refreshing the localhost on my web browser.
No changes seen! :/
Could there be any reason for this?
Or am I doing it in a wrong way?
Thank You
Sarthak Gupta
Hi devs,
Over the weekend I had some friends at my house and I asked one of them to try a few simple tasks in XWiki.
1) I asked him to modify the home page to put his own content.
He couldn’t find how to edit the home page...
* I ran the Tour wizard and he read everything and finished it and still could’t find how to edit
* He even read the content of the home page and noticed the line that says to use the pencil icon above to edit the page. He tried to click the pencil icon but couldn’t find or realize that there was a button to click above.
* In the end I had to explain to him that page action bar.
Idea/suggestion: At the end of the tour or outside the tour, when the first user views the home page, have a flashing arrow with a text “click here to edit this page” to direct the user to edit the page.
Note that he mentioned having some text before the icons to say that this was a Menu… I found it a bit strange. When he saw the XWiki admin UI, he said that the vertical menu was much simpler to understand and that it would be nicer to use that for the page actions. I explained that it would take too much space and he understood that.
2) I asked him to create a new page. It took him some time to understand he had to enter a title but he did it. He clicked the “empty page” template, thinking that it would create the page. He even double-clicked it. After some hints from my side, he was able to locate the “create” button.
Idea/suggestion: the create button is not easy to locate, it’s quite more down from the rest. Note that we’re also missing a cancel button if want to go back and not create a page.
3) I asked him to delete the page after he edited it and even created a new page but he didn’t realize the action would in the same action bar. The reason is that the icon for the actions is a “settings”/“cog” icon and he thought that there would be admin stuff under it.
Idea/Suggestion: Change the icon to something else.
4) I asked him to create pages under other pages and he was able to do that fine.
5) He wanted the wiki in French and we noticed quite a few places that were missing translations:
- the new step in the AWM wizard
- the create page validation message
- color theme admin UI
(there were a few others but I forgot them)
Note: When adding an image in CKEditor and when in French, the tab for uploading is translated as “Téléverser” which is quite awkward in French IMO… ;)
6) He was able to use the navigation panel to navigate
Food for thoughts and actions…
Thanks
-Vincent
Here is a new proposal on this subject.
This supersets the following threads:
* http://markmail.org/message/mhhurc7lbyfanph7
* http://markmail.org/message/nav5a77hzmhq4gq6
* http://markmail.org/message/fd5ijxdquzdhtykw
We discussed with other committers (Vincent and Ludovic) and came to
the conclusion that it was not core dev team job to provide a specific
flavor like Knowledge Base and that we should focus only on a very
generic one (pretty much XE without the Blog).
Here are the details:
= One flavor
We develop only 1 flavor located in xwiki-platform repository. It's a
generic flavor not targeting any specific use case (the first version
with be XE without the Blog). We will discuss the name in another
thread later, let's call it "Wiki Flavor" for now.
Of course everyone is free and welcomed to build lots of contrib
flavors which will be proposed when you install XWiki ("Development
Flavor", "Demo Flavor", "Blog Flavor", etc.).
= No "Base flavor"
But platform will provide an extension that can be used as dependency
by various flavors to get "core" UI extensions that we think make
sense in any kind of flavor.
= Demo package
We currently have a jetty/hsqldb based package in platform which let
you choose which flavor you want. We will show it in the download
page.
We will add another one with the Wiki Flavor already installed in it
(pretty much like the XE jetty/hsqldb package). Listed on the download
page too.
We don't maintain exe/jar installers anymore in platform, they die
with XWiki Enterprise. They are a real pain to maintain and we are
actually failing since they don't really work properly everywhere they
are supposed to work. It does not worth the trouble for what is not a
production ready package and it's better anyway to make more clear
XWiki is a server thing.
WDYT ?
Thanks,
--
Thomas Mortagne
Hello developers!
The new roadmap has been voted and I continue my work on the notifications
module. You might have played with it since the 9.2 release and I hope you
like it.
Now I need to implement the email part of the notifications module. It
means that users could decide either the notifications are displayed on the
top menu or sent by emails periodically. Having this in mind, it is clear
that it conflicts with the Watchlist.
The plan is to move to contrib the Watchlist application (when possible)
and to implement the same features inside the notifications module.
Any objection before I start the work?
Thanks,
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
After sorting out the previous error with some effort, I am getting another
error. Could someone please tell me how to resolve this?
After giving "mvn clean install" command.
.
.
.
.
T/application-ckeditor-test-1.14-SNAPSHOT.pom
[INFO]
[INFO]
------------------------------------------------------------------------
[INFO] Building CKEditor Integration Test Page Objects 1.14-SNAPSHOT
[INFO]
------------------------------------------------------------------------
Downloading:
https://repo.maven.apache.org/maven2/org/xwiki/platform/xwiki-platform-test…
[WARNING] The POM for org.xwiki.platform:xwiki-platform-test-ui:jar:9.1.2
is missing, no dependency information available
Downloading:
https://repo.maven.apache.org/maven2/org/xwiki/platform/xwiki-platform-test…
[INFO]
------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] CKEditor Integration Parent POM .................... SUCCESS [
10.360 s]
[INFO] CKEditor Integration Base .......................... SUCCESS [05:06
min]
[INFO] CKEditor Integration Plugins ....................... SUCCESS [01:02
min]
[INFO] CKEditor Integration Test Modules .................. SUCCESS [
0.249 s]
[INFO] CKEditor Integration Test Page Objects ............. FAILURE [
9.993 s]
[INFO] CKEditor Integration WebJar ........................ SKIPPED
[INFO] CKEditor Integration UI ............................ SKIPPED
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 06:56 min
[INFO] Finished at: 2017-04-14T22:40:32+05:30
[INFO] Final Memory: 37M/126M
[INFO]
------------------------------------------------------------------------
[ERROR] Failed to execute goal on project
application-ckeditor-test-pageobjects: Could not resolve dependencies for
project
org.xwiki.contrib:application-ckeditor-test-pageobjects:jar:1.14-SNAPSHOT:
Could not find artifact org.xwiki.platform:xwiki-platform-test-ui:jar:9.1.2
in central (https://repo.maven.apache.org/maven2) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionExcept…
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR] mvn <goals> -rf :application-ckeditor-test-pageobjects
I'm running into what appears to be a bug in how XObjects are removed and
added, and wanted to ask if I am perhaps using them incorrectly.
Basically I am performing the following sequence of steps:
1. Insert some XObjects to an XWikiDocument using document.newXObject().
Save the document and reload.
2. Delete one of the XObjects in the middle of the list of XObjects, using
document.removeXObject(). Save the document and reload.
3. Add another XObject using document.newXObject(). Save.
Here is that the document's xObjects data looks like after each step
(simplified for demonstration purposes):
AFTER STEP 1:
index=0 object="<?xml...>...<number>0</number>...</xml>"
index=1 object="<?xml...>...<number>1</number>...</xml>"
index=2 object="<?xml...>...<number>2</number>...</xml>"
AFTER STEP 2 (assume I delete the xObject with index=1):
index=0 object="<?xml...>...<number>0</number>...</xml>"
index=1 object=null
index=2 object="<?xml...>...<number>2</number>...</xml>"
AFTER STEP 3:
index=0 object="<?xml...>...<number>0</number>...</xml>"
index=1 object=null
index=2 object="<?xml...>...<number>2</number>...</xml>"
index=3 object="<?xml...>...<number>2</number>...</xml>"
As you can see there are two related problems here:
1. A null object is being preserved in the list of XObjects, even after
being rehydrated from Hibernate following a server restart.
2. The index=3 object has been given a 'number' of '2' -- but that number is
already in use by index=2 object.
Because of this, saving the document actually fails: I am receiving a
NonUniqueObjectException as follows:
org.hibernate.NonUniqueObjectException: a different object with the same
identifier value was already associated with the session:
[com.xpn.xwiki.objects.BaseObject#-1957000305211198111]
Looking in the XWiki code it looks like this is essentially happening
because the value of 'number' is computed as 'list size - 1'. So that 'null'
that gets preserved in the list seems to be throwing off the logic.
Am I using newXObject()/removeXObject() improperly?
Please advise.
Thanks!
--
View this message in context: http://xwiki.475771.n2.nabble.com/Bug-in-XObjects-or-am-I-using-them-incorr…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
BTW I think we’ll need to think about exploring gradle in not too long.
Maven continues to stagnate while gradle is moving fast ahead.
One important feature of gradle is performance (see also https://blog.gradle.org/introducing-gradle-build-cache and https://blog.gradle.org/incremental-compiler-avoidance). Apparently it beats maven easily and that coud make things much nicer for us. The worrying point for me is the ability to find existing gradle plugins to replace the maven ones that we use.
What we could do is to commit the start of a gradle build in our SCM (starting with xwiki-commons) as a way to explore Gradle and see what’s missing compared to our current maven build. In other words, it would be a way to slowly start to learn Gradle.
WDYT?
Thanks
-Vincent
PS1: FTR I did my first gradle build at https://github.com/xwiki-contrib/docker-xwiki/blob/master/build.gradle
PS2: I’m worried about the smaller reliance on conventions in gradle than in Maven (as you can see from https://github.com/xwiki-contrib/docker-xwiki/blob/master/build.gradle, it doesn’t use any fixed structure and we’ll need plenty of best practices, it really reminds me of Ant…).
Release notes:
http://maven.apache.org/docs/3.5.0/release-notes.html
Interesting aspects for us:
* The new project.directory special property adds support in every calculated URLs (project, SCM, site) for module directory name that does not match artifactId MNG-5878
* In previous Maven versions, there had been a larger problem related to memory usage in case of very large reactors (200-300 modules or more) which caused failures with out of memory exceptions or the need to increase the memory settings. This problem has been fixed with MNG-6030.
Fixed bugs that could be interesting for us:
* In previous Maven versions, there had been a larger problem related to memory usage in case of very large reactors (200-300 modules or more) which caused failures with out of memory exceptions or the need to increase the memory settings. This problem has been fixed with MNG-6030.
Potential issues:
* Replaced Eclipse Aether with Maven Resolver MNG-6110, MNG-6140.
Thanks
-Vincent
Hi devs,
Since 8.0 we have in xwiki-platform a flavor simply called "XWiki
Flavor" which contains more or less the strict minimum to have
something you can call an XWiki instance (Administration, Extension
Manager, a home page, etc.).
Since we want to promote the new Knowledge Base flavor have a
concurrent called "XWiki" is not really making it a favor so we should
probably find another name for it.
Here are some ideas:
1) "XWiki" Flavor, it's Ok after all
2) "Default" Flavor
3) "Base" Flavor
4) "Lite" Flavor
5) "Mini" Flavor
6) "Minimum" Flavor
7) "Pico" Flavor
8) <another word that means small> Flavor
I don't think keeping "XWiki" is such a great idea. Default is even worst.
I like "Lite" but might sound too much like "the very limited free
version, you are going to have advertisement in a month" theses days.
If I had to vote for only one it would be "Mini" but I'm fine with any
of the following proposals.
Thanks,
--
Thomas Mortagne
Hi dev,
The title say it all.
The whole point of Knowledge Base flavor move is to stop maintaining a
set of install packages and only provide the flavor.
Now it could be a pain for testers to have to install the flavor every
time so we might still release a jetty/hsqldb package but not list it
on http://www.xwiki.org/xwiki/bin/view/Main/Download for example.
WDYT ?
I would prefer to avoid that but I can understand if others think it's required.
Thanks,
--
Thomas Mortagne
Hi devs,
We want since a while to get rid of XE and transform this custom
distribution into an easier to maintain flavor you install on the
default XWiki distribution. We finally allocated time in the roadmap
to concentrate on it during 9.3-9.5 timeframe.
The goal is to create a new flavor which would contain exactly the
same things than XE for now.
= The place
My main question is: where do we put it ?
There is two main possibilities IMO:
1) In platform under some xwiki-platform-flavors top level module
which would contain the current base XWiki flavor (which is the strict
minimum to have something that just work currently) and the new
Knownledge Base flavor
2) In it's own repository
2.a) Synchronized with the platform repository like XE
2.b) With its own versioning
I much prefer 1) which is a lot easier to maintain and release since
this is going to be the main recommended flavor when you install
XWiki. I really don't see the point of 2.a and 2.b does not worth the
pain IMO.
= The name
The current "code name" in the core team is "Knowledge Base" but maybe
some of you have better ideas.
Here are some ideas:
1) Knowledge Base
2) Enterprise
3) Default
My +1 goes to "Knowledge Base" which is more descriptive. Also I never
really liked "XWiki Enterprise" naming since "Enterprise" suffix very
often means that's the closed/paid version of an Open Source project
which is not the case at all here.
Thanks,
--
Thomas Mortagne
Hi devs,
FTR founds this issue fixed in the just released Maven 3.5.0:
https://issues.apache.org/jira/browse/MNG-5878
This shows that not using artifactId as project names was leading to some issues till Maven 3.5.0.
Mentioning this since there’s been several discussions over the years to remove prefixes and I remember that some devs have done that in some xwiki-contrib repos so maybe there’s an issue there.
Thanks
-Vincent