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…).