Hello all,
Platform and Client team of XWiki SAS find interesting the idea of having
XWiki version written as comment in the top of xwiki.cfg (no need for
particular location though).
When an upgrade is performed, it would permit to know if this configuration
file has been merged (new xwiki version) or directly moved (first/previous
xwiki version) from the old webapp.
Do you think it would be feasible?
Thank you in advance.
Guillaume
Just commenced migrating three XWiki instances from XWiki 4.4.1 to 5.1
These three XWiki instances are each run as individual contexts within a
single
Tomcat instance. Under previous versions of XWiki this required some
configuration
tweaking of infinispan cache settings and lucene index locations to avoid
conflicts
between the various XWiki instances.
However, with the introduction of the SOLR search engine, there appear to
have been
similar conflicts introduced which I am unsure how to solve. Should it be
possible
for a single Tomcat instance to host multiple XWiki 5.1 application
contexts?
Catalina logs show the embedded SOLR throwing "OverlappingFileLockException"
when
starting the second XWiki instance. No doubt this is due to the index
directory
conflict shown below despite the fact that "environment.permanentDirectory"
is set
to different locations in "xwiki.properties" for each XWiki application
context.
Jul 28, 2013 5:57:15 PM org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory /var/lib/tomcat/webapps/xwikidtc
2013-07-28 17:57:26,008 [localhost-startStop-1] INFO
o.x.s.s.i.EmbeddedSolrInstance - Starting embedded Solr server...
2013-07-28 17:57:26,012 [localhost-startStop-1] INFO
o.x.s.s.i.EmbeddedSolrInstance - Using Solr home directory:
/net/sydnas1/c/deltasoft/XWiki/DTC/data/solr
2013-07-28 17:57:27,650 [localhost-startStop-1] WARN o.a.s.c.SolrCore
- New index directory detected: old=null
new=/net/sydnas1/c/deltasoft/XWiki/DTC/data/solr/./data/index/
2013-07-28 17:57:30,602 [localhost-startStop-1] INFO
o.x.s.s.i.EmbeddedSolrInstance - Started embedded Solr server.
Jul 28, 2013 5:57:37 PM org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory
/var/lib/tomcat/webapps/xwikisportzman
2013-07-28 17:57:58,944 [localhost-startStop-1] INFO
o.x.s.s.i.EmbeddedSolrInstance - Starting embedded Solr server...
2013-07-28 17:57:58,950 [localhost-startStop-1] INFO
o.x.s.s.i.EmbeddedSolrInstance - Using Solr home directory:
/net/sydnas1/c/deltasoft/XWiki/DTC/data/solr
2013-07-28 17:58:00,584 [localhost-startStop-1] WARN o.a.s.c.SolrCore
- New index directory detected: old=null
new=/net/sydnas1/c/deltasoft/XWiki/DTC/data/solr/./data/index/
2013-07-28 17:58:02,678 [localhost-startStop-1] INFO
o.x.s.s.i.EmbeddedSolrInstance - Started embedded Solr server.
Appears that the first setting of "environment.permanentDirectory" is used
for all
application contexts after that ??? However, other files (e.g., "extension"
and "jobs"
directories) are being placed in the correct permanent direcrory. i.e., it
is only
SOLR that appears to be picking up an incorrect setting for
"environment.permanentDirectory".
--
View this message in context: http://xwiki.475771.n2.nabble.com/SOLR-Fails-with-Multiple-XWiki-Contexts-t…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi XWiki developers!
Relating to http://markmail.org/message/n2yove6lr3rlzh6j , I'm working on
the "Workspace" integration in XWiki Enterprise.
After a brainstorm with Vincent, this is the first things I will do:
1/ the "xwiki-manager" repository will not be used anymore, it could even
be closed.
2/ the "xwiki-manager-ui" will be split in the different projects of
xwiki-enterprise and xwiki-platform (mainly xwiki-workspace-application).
All the content of the manager will not be lost. We might rename some of
the page in order to not override the current ones (ex: Dashboard.WebHome
will be renamed WikiManager.Dashboard).
3/ "xwiki-manager-data", "xwiki-manager-distribution", "xwiki-manager-web"
and "xwiki-manager-tests" will not be imported. The only useful test is a
Selenium test that we can keep, but it is better to rewrite-it because we
will change the UI too.
I will write you an other email with Caty tomorrow, with what we plan to do
for the 5.2 roadmap.
If you have any question or suggestion, please send me them!
Regards,
Louis-Marie
Hi devs,
We're getting close to releasing 5.1 final so we need to start the roadmap for 5.2.
Content
======
Here's some proposal based on discussions with various committers (those from XWiki SAS) and based on our past roadmap leftovers:
* SOLR Search improvements/tuning + search suggest in SOLR - Thomas + Marius
* Have Workspace by default in XE + improved home page - Caty + Guillaume Delhumeau. FTR Guillaume is not a committer yet but he's going to work full time on XWiki development and especially on UI aspects from now on. Welcome aboard Guillaume, we need you! :)
* Scalable import/export based on wiki stream - Thomas
* Improvements on EM (introduce "always" switch in the EM conflict UI, When uninstalling a XAR extension a question should be asked for various conflict use cases, various bugs, etc) - Thomas + Marius
* Script signing - Thomas Delafosse
* Add UI extension point in key places - Who wants to work on this?
Here are also some JIRA issues that were raised as important (in this order of importance):
* XWIKI-8765: When upgrading a wiki, do not display what happened (files edited, etc.) in the Activity Stream
* XWIKI-9046: Improve document save performance by not loading the full history
* XWIKI-6700: Copying a page over an existing one does not warn user
* XWIKI-7377: AWM Add the ability to publish an application as an extension
* XWIKI-5146: Support LiveTable text filtering on DBListclass columns
* XWIKI-6275: Removing the last member of a group removes the group as well
* XWIKI-7718: Improve user profile's UI by using the vertical menu
* XWIKI-9156: The Wiki UIExtensions should check the rights before executing extension points
* XWIKI-8763: Improve AWM for it to deal with error messages directly in the edit mode
* XWIKI-9227: Extend the link creation feature for XEM
* XWIKI-8757: Support 2 roles for users for app within minutes: application creator and data creator
* XWIKI-9233: Cannot save a wiki page containing a link towards a page with a full name >255
Last, here's a list of interesting investigations to do (for future implementation):
* Activity Stream UI + Notifications Investigations - Caty + GuillaumeD
* Easier automatic field validation (including UI for advanced user). Ajax or Not - Marius (if enough time)
For committers for whom I've suggested a name next to items above, is it ok for you to work on this in 5.2?
For committers not listed, anything special you wish to work on for 5.2?
Dates
=====
5.2M1: 12 Aug (5 weeks since holiday period and all XWiki SAS devs at seminar for 10 days)
5.2M2: 9 Sep (4 weeks since holiday period)
5.2RC1: 23 Sep (2 weeks)
5.2Final: 30 Sep
This allows to roughly keep the September period for 5.2 final as planned initially so that we can have 5.3 in November, 5.4 in December and 5.5 in January.
WDYT?
Thanks
-Vincent
Hello,
I currently developing an additional component, this component need 3rd
party jars to run.
I have included my project in Eclipse, where I stored the jars in the
build path.
To create the jar with Maven works without error.
Whenever I install my component in xwiki.basedir {} / WEB-INF/lib, and
then try to execute this in Velocity in a page I get the following error
displayed:
Caused by: org.apache.velocity.exception.MethodInvocationException: Invocation of method 'createProjectPages' in class com.acme.internal.BlueAntComponentScriptService threw exception java.lang.NoClassDefFoundError: org/apache/commons/discovery/tools/DiscoverSingleton at xwiki:BlueAnt Space.WebHome[line 2, column 19]
at org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:261)
at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:187)
at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280)
at org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:369)
at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)
at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:228)
... 106 more
Caused by: java.lang.NoClassDefFoundError: org/apache/commons/discovery/tools/DiscoverSingleton
at org.apache.axis.components.logger.LogFactory$1.run(LogFactory.java:45)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.axis.components.logger.LogFactory.getLogFactory(LogFactory.java:41)
at org.apache.axis.components.logger.LogFactory.<clinit>(LogFactory.java:33)
at org.apache.axis.handlers.BasicHandler.<clinit>(BasicHandler.java:43)
at org.apache.axis.client.Service.getAxisClient(Service.java:104)
at org.apache.axis.client.Service.<init>(Service.java:113)
at net.proventis.axis.blueant.BaseServiceLocator.<init>(BaseServiceLocator.java:12)
at com.acme.internal.ClientTest.<init>(ClientTest.java:41)
at com.acme.internal.BlueAntDefaultComponent.createProjectPages(BlueAntDefaultComponent.java:73)
at com.acme.internal.BlueAntComponentScriptService.createProjectPages(BlueAntComponentScriptService.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:395)
at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:384)
at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:173)
... 110 more
Caused by: java.lang.ClassNotFoundException: org.apache.commons.discovery.tools.DiscoverSingleton
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1516)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1361)
... 128 more
I've tried to make the jars available via the command:
mvn install:install-file -Dfile=src\main\resources\axis.jar
-DgroupId=axis -DartifactId=axis -Dversion=1 -Dpackaging=jar
...
...
...
But this has not helped.
My pom file looks like:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.xwiki.commons</groupId>
<artifactId>xwiki-commons-component-archetype</artifactId>
<version>3.3-milestone-2</version>
<name>XWiki BlueAnt Component</name>
<description>XWiki BlueAnt Component</description>
<properties>
<platform.core.version>3.3-milestone-2</platform.core.version>
</properties>
<build>
<plugins>
<!-- plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerVersion>1.5</compilerVersion>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>org.xwiki.commons</groupId>
<artifactId>xwiki-commons-component-default</artifactId>
<version>${platform.core.version}</version>
</dependency>
<!-- Only needed if some of the component's APIs must be made
visible to scripting in wiki pages -->
<dependency>
<groupId>org.xwiki.commons</groupId>
<artifactId>xwiki-commons-script</artifactId>
<version>${platform.core.version}</version>
</dependency>
<!-- Testing dependencies -->
<dependency>
<groupId>org.xwiki.commons</groupId>
<artifactId>xwiki-commons-test</artifactId>
<version>${platform.core.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>axis</groupId>
<artifactId>axis</artifactId>
<version>1.0</version>
<type>jar</type>
<scope>system</scope>
<systemPath>D:\Entwicklung\JAVA\Maven\TestProject\example\src\main\resources\axis.jar</systemPath>
</dependency>
... and for all other third party jars
</dependencies>
</project>
Can anyone help a desperate trainee? :)
--
MPDigital GmbH
Michael Born
Auszubildender Fachinformatiker Anwendungsentwicklung
Kantstraße 5-13
44867 Bochum
Tel.: (0 23 27) 307-323
E-Mail: born(a)mpdigital.de
http://www.mpdigital.de
Geschaeftsführer: Hans-Joachim Janke
Sitz und Registergericht:
Amtsgericht Bochum - HRB 6454
Hi devs,
Just to let you know that I've installed the Solr app on test.xwiki.org so that test.xwiki.org has its own search.
I've also modified Main.SolrSearch on xwiki.org to add "-wiki:test" so that results from the test wiki don't appear when users search on xwiki.org.
Thanks
-Vincent
Hi guys,
Several of us had an IRL discussion while at the XWiki SAS seminar. We brainstormed a bit about the xwiki.org community and about issues that exist and how to find actions to improve them.
* Denis said: Lacking long term direction in the project
* Denis said: Would be nice to have XWiki SAS long term vision in the open source project since XWiki SAS has the most committers in the project
=> action: create page on xwiki.org with big items discussed/decided on the list but not done yet (e.g. Flavors, etc). Assignee: Vincent
=> action: send mail on list about the vision of the xwiki project. Assignee: Denis
=> action: send a survey with a list of flavors identified (and possibility for the responders to add more) to see how xwiki users are using XWiki. Assignee: Silvia
* Denis said: Difficult to know who's working on what, who's an expert in what domain in the community
=> action: rewrite hall of fame page to be more friendly with a short presentation of committers. Create the skeleton and ask everyone to fill his part. Assignee: Vincent
=> idea: define a set of tags corresponding to xwiki features/modules and tag user pages with them. Create a User Directory app on xwiki.org displaying those tags to see who's an expert in what. Assignee: ?
=> idea: improve profile pages to see what users have contributed too. Assignee: ?
* Denis, Caleb said: sometimes "too hard" for newcomers. Feeling of not being welcomed and having to work too hard to push something in.
=> idea: create an XWiki event. Assignee: ? (Vincent is interested to organize something in France/Paris)
* Denis said: Hard to find what you're looking for in the documentation, some obsolete parts.
* ThomasD said: Missing some guides for newcomers who wish to start contributing on the platform
=> we didn't get the time to discuss this
* Caleb said: Lack of code ownership. If there was code ownership then the owner would feel responsible for his part
=> we didn't get the time to discuss this
* Caleb said: Sometimes difficult to discuss on the mailing list because others will answer about the way it should be done and the proposer has no time to do that
=> we didn't get the time to discuss this
Do you agree about this?
Do you have other points not mentioned about issues in the xwiki community?
Do you have ideas on how to improve the points mentioned above?
Are you willing to help on some actions?
Thanks!
-Vincent
Hi all,
I'd like to welcome Buddhiprabha Erabadda to our community on the GSOC
Mobile Client project, which I will mentor. Buddhiprabha Erabadda is our
only GSOC student this year as we were not enough satisfied with the
quality of the other proposals. No pressure Buddhiprabha.
The objective of Buddhiprabha will be to help me getting the best possible
XWiki Mobile out the door on Android and iOS, with particularly
notifications implemented. We will also work with Caty on her proposals for
the mobile app:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MobileApp
We will also add improvements to the XWiki REST Api during the project
especially to improve performance. There is already a pull request to get
more page data in one request (
https://github.com/xwiki/xwiki-platform/pull/111 )
We have a jira project to track tasks: http://jira.xwiki.org/browse/XMMORPHO
Welcome Buddhiprabha to XWiki
Ludovic
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hello fellow developers,
for my local association (Scouts de Forbach), I've been pushing to get an XWiki which is now deployed and starts slowly to be used.
One of the central objectives is to get a communication channel between the members. A forum could be sufficient but a wiki is useful already per se.
For the communication, I could go in the direction of the message-board or the emerging discussions' module but I am thinking that the threading is not the most important part but the delivery and making sure that people read it.
Thus I am thinking of an "Announce" class whose objects would be added by a menu and would first show a dialog inviting to indicate recipients and send the email.
Once sent, the announce keeps a track of the version number and the users and emails that have been sent.
The email sent is in html, contains the whole page content, and contains a tracker image, individualized by recipient. The image pull, which is activated when people show images (I know not all do), would then update the object and show to the (registered) readers of that page that the given user has read it.
Considering my experience of a somewhat uncertain communication it seems to be a useful addition to stimulate the usage of the wiki and to enroll people that do not necessarily go there often.
Is anything such existing?
Can some of you make other suggestions?
What would be the way for me to embed such a menu action and the display of the announce space?
thanks in advance.
Paul
After user logout from the XWiki, following exception occurs:
2013-07-11 12:38:47,440
[http://localhost:8080/xwiki/bin/logout/XWiki/XWikiLogout?xredirect=/xwiki/b…] ERROR c.x.x.w.XWikiAction - Cannot send action notifications for document [XWiki.XWikiLogout using action [logout]
java.lang.StackOverflowError: null
at
java.net.AbstractPlainSocketImpl.available(AbstractPlainSocketImpl.java:455) ~[na:1.6.0_27]
at java.net.SocketInputStream.available(SocketInputStream.java:234)
~[na:1.6.0_27]
at
com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:72) ~[mysql-connector-java-5.1.25-bin.jar:na]
at
com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161) ~[mysql-connector-java-5.1.25-bin.jar:na]
at
com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:189) ~[mysql-connector-java-5.1.25-bin.jar:na]
at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3116)
~[mysql-connector-java-5.1.25-bin.jar:na]
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3570)
~[mysql-connector-java-5.1.25-bin.jar:na]
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3559)
~[mysql-connector-java-5.1.25-bin.jar:na]
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4110)
~[mysql-connector-java-5.1.25-bin.jar:na]
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2570)
~[mysql-connector-java-5.1.25-bin.jar:na]
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2731)
~[mysql-connector-java-5.1.25-bin.jar:na]
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2809)
~[mysql-connector-java-5.1.25-bin.jar:na]
at
com.mysql.jdbc.ConnectionImpl.rollbackNoChecks(ConnectionImpl.java:5165)
~[mysql-connector-java-5.1.25-bin.jar:na]
at com.mysql.jdbc.ConnectionImpl.rollback(ConnectionImpl.java:5048)
~[mysql-connector-java-5.1.25-bin.jar:na]
at
org.apache.commons.dbcp.DelegatingConnection.rollback(DelegatingConnection.java:368) ~[commons-dbcp-1.3.jar:1.3]
at
org.apache.commons.dbcp.DelegatingConnection.rollback(DelegatingConnection.java:368) ~[commons-dbcp-1.3.jar:1.3]
at
org.apache.commons.dbcp.PoolableConnectionFactory.passivateObject(PoolableConnectionFactory.java:685) ~[commons-dbcp-1.3.jar:1.3]
at
org.apache.commons.pool.impl.GenericObjectPool.addObjectToPool(GenericObjectPool.java:1379) ~[commons-pool-1.5.4.jar:1.5.4]
at
org.apache.commons.pool.impl.GenericObjectPool.returnObject(GenericObjectPool.java:1342) ~[commons-pool-1.5.4.jar:1.5.4]
at
org.apache.commons.dbcp.PoolableConnection.close(PoolableConnection.java:90) ~[commons-dbcp-1.3.jar:1.3]
at org.apache.commons.dbcp.PoolingDataSource
$PoolGuardConnectionWrapper.close(PoolingDataSource.java:191)
~[commons-dbcp-1.3.jar:1.3]
at
com.xpn.xwiki.store.DBCPConnectionProvider.closeConnection(DBCPConnectionProvider.java:236) ~[xwiki-platform-legacy-oldcore-4.5.3.jar:na]
at
org.hibernate.jdbc.ConnectionManager.closeConnection(ConnectionManager.java:474) ~[hibernate-core-3.6.9.Final.jar:3.6.9.Final]
at
org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:408)
~[hibernate-core-3.6.9.Final.jar:3.6.9.Final]
at
org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:347)
~[hibernate-core-3.6.9.Final.jar:3.6.9.Final]
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:343)
~[hibernate-core-3.6.9.Final.jar:3.6.9.Final]
at
com.xpn.xwiki.store.XWikiHibernateBaseStore.closeSession(XWikiHibernateBaseStore.java:993) ~[xwiki-platform-legacy-oldcore-4.5.3.jar:na]
at
com.xpn.xwiki.store.XWikiHibernateBaseStore.endTransaction(XWikiHibernateBaseStore.java:954) ~[xwiki-platform-legacy-oldcore-4.5.3.jar:na]
at
com.xpn.xwiki.store.XWikiHibernateStore.releaseAllLocksForCurrentUser(XWikiHibernateStore.java:1749) ~[xwiki-platform-legacy-oldcore-4.5.3.jar:na]
... few hundred lines here ...
at
com.xpn.xwiki.store.XWikiHibernateStore.releaseAllLocksForCurrentUser(XWikiHibernateStore.java:1768) ~[xwiki-platform-legacy-oldcore-4.5.3.jar:na]
Maybe there is something wrong with used SAML STS authentcation
(suspected code can be found at
https://github.com/ValdisVitolins/munixwiki/blob/master/tools/xwiki-authent…
) though I didn't find any reasonable differences from
https://github.com/xwiki-contrib/sandbox/blob/master/authenticators/xwiki-a…
...
Thanks in advance for any idea!
Valdis
Hi devs,
Today I needed to see all the features that were added since XWiki 2.4 and that got me thinking about how to document new feature or improvements on xwiki.org.
I started imagining the following:
* To have an xclass representing an improvement or feature, with several properties:
- the version in which the feature or improvement was added
- whether it's an improvement or a feature
- the description of the improvement or feature (textarea), in wiki syntax
* On a given page, add as many xobjects that there are features or improvements
* Create a wiki macro to include the xobject's content in the page content so that the user can see it when viewing the page
Pros:
* This would allow to be able to query the full wiki to see all the features/improvements added in a given version
* This would allow to auto generate the release notes :) We wouldn't need to duplicate the content in both the release notes and in the reference document.
* This would allow to automatically add some "new" icons when the version corresponding to the improvement/new feature is newer than the baseline version (for example, if we're developing version N we can say that on xwiki.org we consider a feature/improvement to be "new" when its corresponding version is >= N-2)
Cons:
* A lot of work to convert the existing xwiki.org content to this but we don't need to do that upfront. We can start by agreeing that any new feature/improvement would go through this mechanism for example.
* A bit more complex to add new content for users but this mechanism doesn't preclude using the current way (ie unstructured content) as it'll still work.
WDYT? Do you think this could be useful?
Thanks
-Vincent
The XWiki development team is proud to announce the availability of XWiki 5.1.
This release comes with Solr search enabled by default. The search UI
has been redesigned and the search backend has been greatly improved.
A new Menu application is now avaible to help you create navigation
menus that ca be placed after the header or in a side panel. Beside
this, a lot of bug fixes (124) and small improvements (53) make this
release worth trying.
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/ReleaseNotesXWiki51
Thanks
-The XWiki dev team
Hi,
Would it be possible to reactivate xeclipse build on jenkins.xwiki.org, or
at least force a build with the current code ? This would allow to get some
snapshot of the current 2.0 status.
Thanks
Ludovic
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hi devs,
I know XWiki 5.1 is going to be released today. Sorin and me are currently
testing Solr and I already tested most of the Jira Tickets Marked as Fixed
in the Release Notes<http://www.xwiki.org/xwiki/bin/view/TestReports/ManualTestReportXWiki51#HJi…>.
Is there anything else you want us to test ?
Thanks,
Manuel
Hi devs,
I saw that Marius and Thomas put as assignee the contributor who created the PR today:
* http://jira.xwiki.org/browse/XWIKI-9316
* http://jira.xwiki.org/browse/XWIKI-9232
Thus I've done the same for:
* http://jira.xwiki.org/browse/XWIKI-7403
I was under the impression that till now we were always using a committer as the assignee in JIRA. The main reason we were doing this is that it's the committed code becomes the committer's responsibility in case the code causes some issues.
The cons are:
* Less recognition of the contributor (even though he appears in the SCM thanks to GitHub's PR).
* He won't appear in the BFD reports. For example: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11604
I'm fine either way but it would be good to have an agreement on what strategy we wish to follow.
Thanks
-Vincent
Hi Devs,
Passing CLIRR is far from sufficient to stay backward compatible or
document incompatible changes !
I know that you know that already, but I want you to remind it once more
because while I was on the road showcasing a site, I had to discover that a
major feature of the site got broken, and it was silently true for a while
apparently. I missed some potential leads, which get me really upset, so I
waited a while before writing.
The cause was a very simple incompatible change introduced in 4.3M2 !
But tracking it down was not easy since this API breakage was not reported
in the RN.
Here it is:
com.xpn.xwiki.objects.classes.PropertyClass#getClassType is no more
reporting the full classname of the type, but now drop the "Class" suffix.
So, "com.xpn.xwiki.objects.classes.StringClass" become "String",
"com.xpn.xwiki.objects.classes.NumberClass" become "Number"... and so on.
The unprivileged API com.xpn.xwiki.api.PropertyClass#getClassType() was
also impacted since "StringClass" become "String", "NumberClass" become
"Number" and so on.
The javadoc of the latter function get updated, meaning that we were really
conscious a breakage was done here. Even more conscious, the following was
applied in the toXML() method:
String classType = getClassType();
if (this.getClass().getSimpleName().equals(classType + "Class")) {
// Keep exporting the full Java class name for old/default property
types to avoid breaking the XAR format
// (to allow XClasses created with the current version of XWiki to be
imported in an older version).
classType = this.getClass().getName();
}
The com.xpn.xwiki.objects.meta.MetaClass was also, since it was using those
name as property names. Some compatibility change was applied as well, with
explicit comments.
But apparently, no one notice (including myself !), and this incompatible
change goes through without even a mention in the RN, nor in the the jira
issue (XWIKI-8355).
So guys, I have no intend to blame anyone here, but I couldn't warn you
more about potential consequence of incompatible changes. These need to be
discuss, or at least clearly mentioned in the RN. Do not rely on CLIRR for
doing the job, it don't.
Probably adding a mention about those changes in the RN of 4.3 is better
now than never, Marius, could you take care of it ?
Thanks for your attention,
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
Hi devs,
I've noticed Apache BloodHound (https://issues.apache.org/bloodhound/) and this reminded of this idea I've had several times in the past: Creating a Project Development Flavor of XE. I mentioned it in some other email already but I wanted to see if this excites you as much as it does for me and maybe we could brainstorm in this thread about what it could be like .
Some scattered thoughts:
* First, from the point of view of the XWiki project I believe it could be a game changer if we did it right since it has the potential of being adopted by projects around the world and thus making them discover xwiki as a result. And since they're developers they would be able to take advantage of XWiki's development features and contribute back to the project through extensions for example.
* Ideally it would be awesome that this project be started independently of the XWiki project I think and just use XWiki as the platform since it's a full fledged project with a different goal than the XWiki project itself.
* We need to finish the Flavor idea by allowing the DM to list flavors.
* Some ideas of content for this Development Project flavor:
** A home page dashboard about metrics of your project. These metrics would be retried from external sources. Examples:
*** Statistics about commits using Git/GitHub
*** Latest emails (taken from mailman or other mailing list software, possibly by subscribing the project to a mailing list so that it gets the emails)
*** Latest issues (taken from JIRA for example)
*** Screenshot example: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgProposal2#…
** A Release application to help perform releases
** A forum application, for example the Mail Archive Application done by Jeremie which would need to be improved to add ability to post from it
** A Release notes application
** The Blog application
** Ability to generate a whole PDF for the project's documentation for a given version
** A modern and nice skin (either Lyrebird or the new Skin proposal: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4x)
** A layout configured for the flavor
** Future: a simple issue tracker (or integrate one) for those who want an all-in-one solution. However keep the external issue tracker possibility for those already having an issue tracker
** Some predefined templates for creating well known project pages: source repository, build, hall in fame, project documentation home page, etc
** The IRC Bot application
** Bundle the JIRA macro
** Bundle the FAQ application
** A Roadmap application
* Of course we should use this flavor on xwiki.org itself. And we could move some of the modules we currently have in platform and that would make more sense there (jira macro, IRC Bot application, FAQ application, etc).
WDYT?
Add your ideas to this email thread or, better, on http://dev.xwiki.org/xwiki/bin/view/Design/DevelopmentFlavor
Thanks
-Vincent
Hi devs,
I just extracted the old google plugin from oldcore (mostly to move a
few dependencies from oldcore with it).
Thinking more about it it seems to me we should retire it mostly for
the following reasons:
* it simply does not work (since probably a very long time): looks
like there is a missing dependency, see
http://tuska.myxwiki.org/xwiki/bin/view/Test/Google
* it depends on a very old (probably more than 4 years old) and
totally unknown google API which probably don't (fully) work anymore.
I tried to look at recent google api jars (mostly to replace the one
we have) but there is so much differences that it could be about
something totally different
Even if it was working there is not reason for it to be packaged by
default in XE.
--
Thomas Mortagne
Hi,
We introduced the Activity Stream macro in XE 2.6
http://extensions.xwiki.org/xwiki/bin/view/Extension/Activity+Macro
We are investigating ways to improve our Activity Stream, but in order to
do that we would want to know your feedback about it (both from a
technology and an user experience pov):
- Is Activity Stream a macro you use?
- What features you most miss about it? Maybe filtering? Maybe pagination?
- Would you like to see more event types, like events generated by
applications?
- Are you using the "Send Message" functionality?
- Other opinions about it.
Your feedback will help us improve the macro by adding needed functionality
and not breaking used one.
I'll gather ideas on
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActivityStreamFeed…
Thanks,
Caty
Hi devs,
While working on XWIKI-9200 (which is done expect for that little
question ;)) I found that there is no API to check if a document exist
in specific language. You have to do a custom query.
Since I would like to make my code as readable as possible and
considering that we will have to do it eventually anyway here it is:
two choices:
1) add support for reference locale in XWiki#exist and
XWiki#getDocument as well as XWikiHibernateStore#exists. Both
XWikiHibernateStore#loadXWikiDoc and XWikiCacheStore are already
taking into account the locale since they are based on the id (so this
would also be about consistency)
2) introduce new methods like XWiki#existsWithLocale,
XWiki#getDocumentWithLocale and XWikiStoreInterface#existsWithLocale
(and the corresponding implementations)
WDYT ?
2) is obviously the safest but I can't find method names I like. I
would be OK with 1) if everyone is strongly for it but it's probably a
bit dangerous so my vote goes to 2) for now.
--
Thomas Mortagne
Hi devs,
I'd like to propose that have our own instance on xwiki.org. Namely on sonar.xwiki.org with an alias of qa.xwiki.org pointing to it.
The Sonar guys were kind enough to add XWiki to nemo (http://nemo.sonarsource.org/dashboard/index/XWIKI) but it has some shortcomings for us:
* We don't control the configuration (and plugins)
* It fails to build XWiki regularly
* It's not synced with our CI builds
I could ask XWiki SAS (http://xwiki.com) if they would be ok to kindly contribute some new VM/server for the xwiki.org project for that.
WDYT?
Thanks
-Vincent