Hi devs,
I’d like to start/revisit a brainstorming on the idea of merging the 3 xwiki repos: commons, rendering & platform.
Pros:
* Nicer to have XWiki Standard be contained in a single repo
* More logical since we release the 3 at the same time with the same versions
* Simpler to commit. Right now if you make changes that affect more than 1 repo we get failures in the CI + we need several jira issues ideally + developers need to rebuild locally the changes from the other repo or wait for the CI to finish building the changes (takes long).
* Simpler for users to report issues. One jira project is simpler to know where to report.
* Less CI jobs
* Simpler for running tools like jacoco, clover, etc since they can run in a singe maven reactor.
* Simpler for releases (e.g. to find the list of committers for the RN, you need to run the command only once instead of 3 times, etc)
* Simpler to understand the xwiki code base and for onboarding
Cons:
* We need to find a solution for Maven plugins that need to be build before they’re used (XAR plugin, Package plugin, etc). One solution for those is to have them in a separate repo and using the last released version for their XWiki dependencies. Unless it now works with Maven to build plugins in the same reactor as where they’re used (need to try it).
* Maybe could cause memory issues when running the whole build in a single maven reactor?
* Note that I don’t think this would impact the release of commons and rendering modules to Maven Central since we can still configure that in the poms for those modules.
* We might need to refactor some of our build checking tools such as the one verifying that commons doesn’t use rendering or platform modules but that’s not a big deal.
* Possibly slightly longer paths for building on windows (see below)
If we were to agree on the merge, we could keep the separation between the 3 repos with directories and have an addition level such as:
xwiki (repo)
|_ xwiki-commons
|_ xwiki-rendering
|_ xwiki-platform
Now we could also forge this organization and flatten it with:
xwiki (repo)
|_ xwiki-(feature)
|_ xwiki-(feature)-(subname1)
For example:
xwiki
|_ xwiki-core
|_ xwiki-component
|_ xwiki-component-api (from commons)
|_ xwiki-component-multi (from platform)
|_ xwiki-rendering
|_ …
|_ xwiki-tools
We could even try to go with an even flatter structure:
xwiki
|_ xwiki-component
|_ xwiki-component-api (from commons)
|_ xwiki-component-multi (from platform)
|_ xwiki-rendering
|_ …
|_ xwiki-tools
|_ ...
(it would mean that in xwiki-tools, we apply similar rules that for runtime code or override the maven configs)
WDYT?
Thanks
-Vincent
Hi devs,
Here’s a proposal for 10.10 (discussed already with the persons mentioned below).
Date: November 2018
Scope:
BAU:
* Thomas/Vincent: Improve STAMP KPIs (20%)
* All: BFD (20%)
Outstanding work:
* Thomas: continue work on performance (started in 10.4). Goal: go back to XWiki 8.x performance!
* Specifically commit the work already done on the asynchronous framework/macro + apply it for UIX + panels + other places - Status: work already done mostly, will require a few more days
* Other performance-related topics
* Simon/Marius (moved from 10.8 roadmap): Macro inline editing in WYSIWYG
* Work mostly done but there are still some leftovers, especially in https://jira.xwiki.org/browse/XRENDERING-518 which is proving harder than expected. Since it’s already late in the release, it’ll be committed in 10.10RC1.
* Adel (moved from 10.8 roadmap): finish applying Autocomplete on reference everywhere,
* We have one issue that is in 10.9. The rest is ready but will be committed in 10.10 only (too late for 10.9).
* Simon: Page Move/Renaming: don't allow and/or warn when moving pages containing xclass definitions. Use case: prevent users from breaking AWM apps they created
* Work finished but too late to be in 10.9. Will now be in 10.10
* Adel/Marius (moved from 10.8 roadmap): Auto complete of references in WYSIWYG Macro Dialog (+ grouping feature so that users don't get both "page" and "reference" at the same time + "deprecated"/"priority" to show "page" more proemintenly than "reference")
* Guillaume: fix outstanding issues for notifications
New work:
* Simon: Button to remove all deleted pages/attachments in a single click
Best effort (if time permits, the items below are previous leftovers from previous roadmaps or items originally planned for 10.10):
* Marius/Adel/Simon: ConfigurableClass doesn't support page level configuration ccse
* Marius/Adel/Simon: Import: make it work with new versions of Libre Office (idea: use a more recent fork of jodconverter, we identified one and check if we need to merge changes we did in our fork)
* Marius/Adel/Simon: Display Reference of documents to copy paste
* Marius/Adel/Simon: Improve the XClass picker when in object edit mode (make it like the Add Macro dialog for WYSIWYG editor)
* Thomas: work on some items to make the upgrade experience simpler + unattended upgrades (ability to upgrade XWiki from the command line without interaction). Use the result of Caty's investigation from XWiki 10.8 period.
Dates:
* 10.10RC1: 19th of November 2018
* 10.10Final: 26th of November 2018
I’ve also updated https://www.xwiki.org/xwiki/bin/view/Roadmaps/
If you’re ok with the proposal please edit https://www.xwiki.org/xwiki/bin/view/Roadmaps/ and add the individual jira issues that you’re taking for 10.10 for the mentioned topics.
Thanks!
-Vincent
Hi everyone,
I'll work this month on adding the "delete all" functionality in the
recycle bin.
However I'd like to have your opinion on how it should looks like for
the users.
I have at least 4 proposals that I detailed there:
https://design.xwiki.org/xwiki/bin/view/Proposal/Deleteallfromrecyclebin
The 4 proposal are numbered as following:
A. A simple button
B. A simple button with a checkbox to activate it
C. A button and a modal to confirm the action
D. A generic bulk action on the livetable
Thanks in advance for your feedbacks.
Simon
--
Simon Urli
Software Engineer at XWiki SAS
simon.urli(a)xwiki.com
More about us at http://www.xwiki.com