- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] [Investigation] SOLR integration
by Fabio Mancinelli 14 Sep '11

14 Sep '11

Hi everybody, for the 3.2 release cycle I said that I was going to investigate a bit the SOLR search engine and how to use/integrate it in the current platform. I wrote a document that you can find here: http://dev.xwiki.org/xwiki/bin/view/Design/SOLRIntegration about some of the things I looked at. There is a lot of room for discussion/improvement but I think the document is already a good starting point. Feedback is welcome. Thanks, Fabio

2 3

[xwiki-devs] [PROPOSAL] Introduce a work directory concept in the Container API
by Thomas Mortagne 13 Sep '11

13 Sep '11

Hi devs, Right now there is no way for a component to know where is the standard work directory (the one used for Lucene or filesystem attachments for example) so I would like to add an API to access it. That said I propose to add a File getWorkDirectory() in org.xwiki.container.ApplicationContext which will use XWiki#getWorkDirectory() behind the scene probably for now. WDYT ? -- Thomas Mortagne

5 20

[xwiki-devs] [Proposal] Global versioning brainstorming
by Vincent Massol 13 Sep '11

13 Sep '11

Hi devs, I'd like to brainstorm about the idea of having global versioning in XE. First here is a use case: * I have a given state in my wiki with pages in different versions * I add some pages or make modifications to existing pages * I want to go back to the previous state A good use case could be for example to return to a state before one or several applications have been installed. Proposed solution ============== * Store a global version number in the DB. Let's call it VERSION * Whenever a doc is modified, use VERSION + 1 as the new doc version * When we rollback (to say version OLDVERSION) do a query on all docs in the wiki having a version > OLDVERSION and for each of them rollback to their last version <= OLDVERSION * Write a migrator that runs the whole wiki history by looking at all versions of all docs (map in memory) and recompute the new version starting a VERSION = 1 and incrementing. * We would also need to modify the XAR importer so that importing a XAR with an older versioning scheme will work. BTW knowing that it's an old scheme is relatively easy since all old versions have a dot in their name. More notes: * This would also allow us to rollback before a given date * If we wanted we could easily add the notion of Tags later on, i.e. to associate a name with a VERSION * I've been thinking about this in the context of the new model but it's probably easier to implement it first with the old model * JRCS uses the format X.Y for versions but we could decide to only use the major, i.e always have versions of the form X.0 * In order to continue to support minor edits we would need a way to save that information. One solution is to use the minor to signify a minor edit, for ex: X.1 would mean that X is a minor. Another, probably better solution would be to store that information in the DB in the xwikircs table WDYT? Do you see any drawback of using a global versioning scheme? Do you think this is doable or too much work? Is there anything Git can tell us re managing versions that would be useful to this discussion? Thanks -Vincent

3 3

[xwiki-devs] Usability feedback on first time usage for setting a logo
by Vincent Massol 12 Sep '11

12 Sep '11

Hi devs, I've just installed a new wiki with someone (an xwiki newbie) and realized that we have some usability issues. I'm listing just one below to start with. Usability issue #1: Color theme usage Story: * A user wants to change the logo * First he has to know it's done in the Color theme but let's imagine that this is fine… (although it's not since Color theme means changing colors, not the logo…) * He click on "customize" for the Color Theme then realizes that he wants his own color theme (for ex because he doesn't want that a future upgrade overwrites his theme) * He clicks on manager color themes * He sees the "create new color theme" and use it. However he finds that the new color theme isn't the same as the color theme he wants to use as the basis for the new color theme (btw the new color theme should be the default color theme IMO and not a different one as it is now). * Then he's stuck because the doesn't offer the possibility to copy an existing theme * Imagine that he understands that he can go a color theme page and click the copy action… * He goes there clicks copy, he finds that he wants to copy in a new space but he cannot (this is fixed in 3.2 I think so cool). He copies in the new space. * Then he edits the new color theme, finds the way to set the logo * He sees a field where he has to enter information and doesn't see how to upload his logo. Reading more carefully the text he understand that he has to cancel the edit, go to the attachment tab, upload the logo, edit again, edit the header again and there he's stuck again because he doesn't remember the name of his logo. So he has to do it all again this time copy pasting his logo name * Then he saves his modifications * .. and realizes that nothing is happening: the displayed theme is still the same as before. He hits refresh (because he's a clever guy!) and finds it doesn't help * Then someone points to him that he has to go back to the admin, click on presentation and sets the color theme to use to be his new color theme. * So he does this and finds that his new color theme doesn't appear in the list but OTOH there are 2 color themes with the same name * Then someone mentions to him that it's because he hasn't changed the title of this copied page... Ideas for improving this experience: * In the Admin>L&F>Presentation screen, next to "customize", add a new button "Create new colortheme". * In the new color theme page screen, add the possibility to copy from an existing theme *AND* that sets the new title! * In color theme edit mode, add the capability to select the logo using the widget used in the user profile to select/upload images * When saving the new color theme, go back automatically to the admin page from where the user clicked on "create new colortheme" and set the newly created theme as the selected them * The user press save and he's done WDYT? In addition to all this we should probably rename Color Theme into something else to make it more clear that it's not just about colors (or move the logo out). Also it's probably not very clear what's the difference between color themes and skins. Note: I really did all those steps mentioned above in the story and it was a real pain from a newbie user POV. Thanks -Vincent

4 4

Re: [xwiki-devs] 5
by dennis.coonich＠comcast.net 12 Sep '11

12 Sep '11

Visit this site. I hope it will help you to rid of shyness.. http://www.endrik.com/com.page.php?jfuGIS=50up9

1 0

[xwiki-devs] (no subject)
by dennis.coonich＠comcast.net 12 Sep '11

12 Sep '11

Life is not boring!!!. http://www.kempsu-huolto.fi/com.page.php?iaolid=25o0

1 0

[xwiki-devs] Blockers for XE 3.2M3 and XE 3.2 release?
by Vincent Massol 12 Sep '11

12 Sep '11

Hi devs, Can we list blocker issues in this thread? I can think of the following: - http://jira.xwiki.org/jira/browse/XWIKI-6925: ActivityStream nolonger works if upgrading a legacy system. - http://jira.xwiki.org/jira/browse/XRENDERING-46: Upgrade to HTML Cleaner 2.2 This one is a blocker because we want to put XE 3.2M3 and XE 3.2 final on Maven Central for Commons and Rendering and we're using HTML Cleaner 2.1 which isn't located on Central but version 2.2 is. An alternative is to push version 2.1 of HTML Cleaner on Central. - http://jira.xwiki.org/jira/browse/XWIKI-6939: Can't find any core extension when executed in a folder with white space - upgrade myxwiki to XE 3.3M3 There are also 47 issues marked "Critical" in JIRA… We need to review them and verify if they're really critical. Please add more if you know blocker issues. Also, we need volunteers to work on them! Thanks -Vincent

4 4

Re: [xwiki-devs] 8
by dennis.coonich＠comcast.net 12 Sep '11

12 Sep '11

Cool! I want you to visit this site too!. http://mpbarnehage.no/com.page.php?jcaolid=60w4

1 0

[xwiki-devs] Unable to build xwiki code
by Karamjit Singh 09 Sep '11

09 Sep '11

Hi Team, I am unable to build xwiki from source its source code. I am getting below error message while executing Maven goal:- *[ERROR] Failed to execute goal on project xwiki-platform-rest-server: Could not resolve dependencies for project org.xwiki.platform:xwiki-platform-rest-server:jar:3.2-SNAPSHOT: Could not find artifact org.jboss.cache:jbosscache-core:jar:3.2.5.GA in xwiki-externals (http://maven.xwiki.org/externals) -> [Help 1]* Looks like jboss cache core lib does not exist on maven external repository * * *Please help me. Its very urgent as I am stuck and unable to deploy new changes to our server.* * * *I shall be very thankful.* * * *Thanks* *Karamjit.*

2 2

[xwiki-devs] [Proposal] Naming rules for translation resource properties + deprecated properties
by Vincent Massol 08 Sep '11

08 Sep '11

Hi devs, I see that in ApplicationResources.properties we now have some wrongly named properties. For example for the scheduler I find properties of the type xe.scheduler.* but the scheduler is now in the platform. There are also resources named core.* Thus I'd like to propose a simple rule: <short top level projet name>.<short module name>.<propertyName> where: <short top level projet name> = top level projet name without the "xwiki-" prefix, for example: commons, rendering, platform, enterprise, manager, etc <short module name> = the name of the maven module without the <short top level project name> prefix, for example: oldcore, scheduler, activitystream, etc <propertyName> = the name of the property using camel case, ex: updateJobClassCommitComment For example the property core.importer.package.version would be renamed in platform.web.packageVersion The only issue is when we rename modules we need to rename the properties for that module but I don't see any way out of this if we want to have expressive property names. But at least it's an easy and mechanic change I also propose to introduce a different resource property file that will hold deprecated properties and that we can put in the xwiki-platform-legacy module. We could call it DeprecatedApplicationResources*.properties Of course in the future each module should be able to contribute both resource properties (but they would use the same naming scheme!). Even though this is not the topic of this mail this is how I'd implement this in the future: * Implement a TranslationPropertiesConfigurationSource that is initialized by reading all property files found in the classloader under META-INF/translations.properties and META-INF/translations-deprecated.properties. This component would listen to observation events so that when a new jar is installed by the extension manager it can check if it provides some translations and add them. * Have a Translation Manager component which is the main API to be used by other modules wishing to get translations. This manager would use the TranslationPropertiesConfigurationSource component. WDYT? Thanks -Vincent

2 1