Hi devs,
Here's a proposal for the 4.3 roadmap. I'm putting names of committers I've discussed it with, please correct me if I'm wrong and please add any other items you'd like to do for 4.3 for committers not listed or even for committers listed if you want to work on other stuff! :)
"Large Features"
=============
- Improvements on Search Components SOLR Implementation - Assignee: Edy
- Implementing Usability Action Plan: from Wysiwyg macros improvements, improvement dashboard look, Help center, XEM Usability - Assignee: JV
- Improvements on AppWithinMinutes (according to the initial specs: user fields, suggests, validation, automated naming of pages, doc title + doc content, app generation quality) - Assignee: Marius with Sergiu for "automated page names"
- Extension Manager Maintenance (testing, bug fixing, etc.) - Assignee: Thomas
- Extension Manager Authentication - Assignee: Thomas
- l10n module and especially automatic Registration of translation objects in wiki pages (similar to wiki macros) - Assignee: Thomas
- Ludovic's Mobile Skin Patch - Assignee: Sergiu (if he gets the time)
- Validating LibreOffice as standard Office Importer (brings pptx support) - Assignee: Sorin
JIRAs:
======
There are 3 important JIRAs that we should commit on:
- Be able to rename a space from the UI (also Rename Application) - XWIKI-6722 - Assignee: ? (Sergiu maybe if he gets the time)
- Improvements on Dashboard editing - XWIKI-7681- Assignee: JV
- User picker (User field does not scale to 1000 users - User picker implementation) - Assignee: Sergiu
Other important JIRAs (but no commitment):
- tag suggest feature does not work if Main.WebHome is not saved with programming rights - XE-539
- Tracking Active Installs - no JIRA yet - Vincent (I hope I can find the time)
- Profile Improvements - XWIKI-6307
- Lucene Search should not return HTML tags - XWIKI-8111
- Search suggest does not use translation keys (Show all results... and No results!) Patch aleardy exists, it has to be applied - XWIKI-7138
- PDF Export when CDATA section (generated by Livetable) - XWIKI-7871
- App Within Minutes pages cannot be annotated (and any page using the HTML macro)- JIRA?
Investigations:
============
- 4.x Skin. Assignee: Caty
- Scalability Auditing. Assignee: Sorin
- Mobile Skin + Mobile App investigation. Assignee: Ludovic
Dates
=====
- 4.3M1: 22 oct (3w)
- 4.3M2: 5 nov (2w)
- 4.3RC1: 12 nov (1w)
- 4.3final: 19 nov (1w)
Then 4.4 around beginning of January and 4.5 around beginning of February ==> 4.x cycle finished for early February.
WDYT?
Thanks
-Vincent
Hi devs,
In many APIs we sometime want to manipulate several Block but we don't
want to put them in a meaningful Block like XDOM which is supposed to
mean a full document. Right now the only way to do it is to have both
an API with Block and another with Collection<Block> but it's a bit
more annoying for return type where you are forced to return a
List<Block> even if you are in a case where you actually have only one
Block to return like in macros for example.
We talked a long time ago with Vincent about a BlockCollection which
would not have any meaning (i.e. no corresponding event in the stream
rendering API) and would just be here to be able to pass several
blocks as a Block.
Since UI extension is going to use it a lot I propose to introduce it now.
WDYT ?
Any better idea for the name ?
Here is my +1.
--
Thomas Mortagne
Hi devs,
I find myself starting to copy past a lot of stuff from one
ScriptService to another and I wanted to discuss with you think I find
common enough to be put in a AbstractScriptService in
xwiki-commons-script to be reused everywhere.
As a discussion based I committed a first thing in
https://github.com/xwiki/xwiki-commons/commit/a19c6df56fa984dacc9a8eeb50bb9…
in a branch.
So here are some ideas:
* helper to set/get exception that every method is supposed to catch
to make error handling in languages like velocity easier (in the
commit)
* helper to find a proper "safe" wrapper based on the type of an
object (there is a example of such helper in
https://github.com/xwiki/xwiki-commons/tree/master/xwiki-commons-core/xwiki…)
Any other ?
WDYT ?
--
Thomas Mortagne
Hi guys,
For those of you who might be interested, I created a platform branch
that contains a demo of how XWiki's WYSIWYG Editor can be used outside
XWiki. The editor uses the rendering module and the component manager,
but they can be removed also if you want to use only the client side
(JavaScript code). See
https://github.com/xwiki/xwiki-platform/tree/feature-wysiwyg-standalone/xwi…
. If you want to try it, you need to build the WYSIWYG Editor modules
(use -Pdev for a quick build) and deploy the standalone war in a
servlet container of your choice.
Hope this helps,
Marius
I would like to pass in a variable from a JSP page, named mySession, to the
login page of Xwiki, such as:
So when the user has valid credentials they will be redirected here:
/xwiki/bin/login/XWiki/XWikiLogin/?mySession=" + session.getId();
There is some a custom authentication class written in Java that extends
XwikiAuthServiceImpl and inside of the checkAuth(XWikiContext context)
method I am trying to retrieve the value I passed in from the JSP page.
String mySession =
(String)context.getRequest().getSession().getAttribute("mySession");
The value of mySession is always null. Does anyone know where I went wrong
in trying to accomplish this?
--
View this message in context: http://xwiki.475771.n2.nabble.com/passing-a-session-variable-to-the-XwikiLo…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi devs,
Just a reminder that we have a Template for creating release notes on xwiki.org. The way to create a new release note is:
* Go to http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/
* Click in Add>Page in the top menu and select "Release Note"
* Starting with 4.3M1 name the page: ReleaseNotesXWiki<version> (without the "Enteprrise" part).
Thanks
-Vincent
Hello devs,
I've volunteered (designated volunteer ;) for performing the 4.2 final
release.
It was supposed to be today, so we need to agree on a new date.
Personnally I can do it either Wednesday or Thursday (I'm taking a train
on Friday, so I will be less available). I have a preference for Wednesday.
So, my +1 for Wednesday
WDYT ?
Jérôme
Hi devs,
I was trying to make XEM work with HSQLDB and... I have succeeded :)
The only problem I have is that DBCP doesn't seem to work with Hibernate. For some weird reasons when we do a SET SCHEMA it makes calls to fail afterwards. In any case if I configure Hibernate to not use DBCP all work just fine.
I've googled around and found that there are lots of people complaining about DBCP.
I've googled for what connection pooling library to use and I've found that most people are recommending BoneCP (http://jolbox.com/).
See:
* http://stackoverflow.com/questions/5640146/java-jdbc-connection-pool-librar…
* http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/
* http://stackoverflow.com/questions/8057110/java-database-connection-pool-bo…
The other thing is that we currently have some 300 line of code that we shouldn't have at all and that we need in XWiki just for handling DBCP (see com.xpn.xwiki.store.DBCPConnectionProvider).
The pro of BoneCP is that it seems to be the fastest, see http://jolbox.com/benchmarks.html
So here's what I'd like to propose:
* We move DBCPConnectionProvider to a legacy module
* We bundle the bonecp jar by default
* We configure our hibernate.cfg.xml by default to use boneCP:
<property name="bonecp.idleMaxAge">240</property>
<property name="bonecp.idleConnectionTestPeriod">60</property>
<property name="bonecp.partitionCount">3</property>
<property name="bonecp.acquireIncrement">10</property>
<property name="bonecp.maxConnectionsPerPartition">60</property>
<property name="bonecp.minConnectionsPerPartition">20</property>
<property name="bonecp.statementsCacheSize">50</property>
<property name="bonecp.releaseHelperThreads">3</property>
<property name="connection.provider_class">com.jolbox.bonecp.provider.BoneCPConnectionProvider</property>
What this means:
* Existing users of XWiki will not have to change anything, it'll still work
* New users will use bonecp without knowing
* Existing users can migrate to bonecp just by changing one line in their hibernate.cfg.xml file
I'd love to do this for 4.3 but we're already quite advanced in the 4.x cycle. That said it's just a one line change in hibernate.cfg.xml in case of problem to go back to DBCP so we could do this for 4.3 which leaves us 4.3, 4.4 and 4.5 to test this out. And if later on we find an issue we'll always be able to release a 4.5.1 that has this one line change to go back to DBCP.
WDYT?
Here's my +1 for this action plan.
Thanks
-Vincent
Hi devs,
Current situation:
* on http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ we have separated the RN into 2 parts: XE and XEM.
* in the RN for XE we put all platform release notes, even release notes for modules in platform that are not bundled with XE (IRC Bot for ex).
* It's normal to have release notes for everything we release, not just XE or XEM
Proposal:
* Have only a single release note page for each release (ie no more specific XEM release notes + always make sure to document all releases modules in the RN, not just what is bundled with XE). I propose to name this "XWiki" instead of "XWiki Enterprise". So we would have "XWiki 4.3" for ex.
* The URL for 4.3M1 would be (for ex): http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki43M1
I propose to do this ASAP for 4.2 final (I can do the refactoring).
Here's my +1
Thanks
-Vincent
Hi devs,
It's a best practice that unit tests must not output anything to the console. Rationale:
* It pollutes the maven logs unnecessarily. For example imagine that you're expecting an error in your test and that the stacktrace is logged to the console. When looking at the maven console logs the reader will wonder if there was an error or if it was expected.
* The test must assert whatever it needs to validate the code under test. So if it expects a log to be printed it should assert it.
In order to make this easy I've just added JUnit LogRule to our commons test framework.
Here's a usage example:
public class RestrictParseLocationEventHandlerTest
{
private RestrictParseLocationEventHandler handler = new RestrictParseLocationEventHandler();
/**
* Capture logs with WARN or higher severity to assert them.
*/
@Rule public LogRule logRule = new LogRule() {{
record(LogLevel.WARN);
recordLoggingForType(RestrictParseLocationEventHandler.class);
}};
@Test
public void includeEventWhenIllegalPath()
{
Assert.assertNull("Template shouldn't have been returned",
this.handler.includeEvent("../WEB-INF/xwiki.cfg", "xwiki:Main.WebHome", "parse"));
Assert.assertEquals(1, this.logRule.size());
Assert.assertTrue(this.logRule.contains(
"Direct access to template file [/WEB-INF/xwiki.cfg] refused. Possible break-in attempt!"));
}
}
So this is a vote to agree on this best practice and to document it on dev.xwiki.org.
Here's my +1
If you agree then please make sure your tests don't output anything from now on and please try fixing the tests you wrote that do...
Thanks
-Vincent