January 2014 - xwiki-devs@xwiki.org

[xwiki-devs] [proposal] Process to handle Pull Requests

by Ludovic Dubost

Hi devs, I don't think there is currently a process that is in place to handle pull requests and I have the feeling that the way there are handled today is a bit random. There are usually comments sent out on each pull request but sometimes it seems that some pull requests are going in sleep mode and it's not clear who is in charge. I would like to suggest that a process is put in place where it's clear who is responsible for a pull request and a status is given to the contributors that propose that pull request. Something like: Assigned developer: XXXX Status: New -> new pull request, not yet assigned Assigned -> assigned to a developer, he is in charge of reviewing the pull request and ask for modifications or accept it. The developer can auto assign it to himself. If nobody does, we need to decide how they will be taken into account. ModificationsRequired -> for now rejected with comments. Contributor needs to apply comments and then change back to Assigned for further evaluation VoteRequired -> there are no more comments, but a vote is required as the changes to XWiki core are important WaitingFinalAuthorization -> optional step for complex patches where a additional authorization would be required (need to define who would be the persons that give the authorization) WaitingApplication -> there are no more comments and no changes or vote required. The pull request can be applied and is waiting for a developer to apply it Abandoned -> contributors is abandoning the pull request (cannot do the changes, no more time, etc..) Rejected -> pull request is rejected (quality not enough, etc..) Applied -> pull request is applied What do you think ? Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

6 years, 1 month

7
12
0 0

[xwiki-devs] Convention for class property hints ?

by Jerome Velociter

Hello, Right now class property hints are not supported right in the core of XWiki (though it's been mentioned as a possible future item of the roadmap for AWM, see http://markmail.org/message/ltuphlj7bnnso2yb ). Once this will be implemented, it will rely on i18n message keys so that hints are localizables (same strategy as for class property pretty names) I'd like to start the discussion and see if we can agree on a convention that would be used in the future when this module is implemented. The reason for this is I'm starting to work on a LDAP admin UI, and I find that their field pretty names are not self-explanatory. It's not a matter of expression, it's just the fact that what they describe needs more explanation than what the pretty name can offer). In this light, I'm planning on displaying such longer hints in this admin section. Right now the format for a pretty name is : Space.Class_property=Pretty name The format for a hint could be something like : Space.Class_property.xHint=Hint This would need escaping rules I think, since I believe "property.xHint" is a valid property name Note that I use "xHint" and not "hint" to be consistent with the form standards class names. This can be discussed though. WDYT ? Do you have other ideas ? Jerome. -- Jérôme Velociter Winesquare http://www.winesquare.net/

8 years, 11 months

5
7
0 0

[xwiki-devs] [Idea] Sponsoring issues

by Vincent Massol

Hi devs, WDYT of doing like Jenkins is doing and adding a "Sponsor this issue" button on JIRA? For example: https://issues.jenkins-ci.org/browse/JENKINS-9030 When you click it redirects to http://www.freedomsponsors.org/core/login/?next=/core/issue/sponsor%3Ftrack… You can check http://www.freedomsponsors.org/ It could be interesting to try it and see how it goes. WDYT? Thanks -Vincent

9 years, 4 months

8
16
0 0

[xwiki-devs] [VOTE] Stop bundling the Statistics Application by default in XE

by Vincent Massol

Hi devs, Since statistics are disabled by default, I'm proposing to not bundle the Statistics application by default. Admins who want to enable stats on their would need to install it through the EM. In addition, the Stats app's quality is not exactly perfect either and performances are not that great so I think it makes sense to not promote it too much either. Last, since 5.3M2 the stats app is now visible in the Applications Panel (for Admins), thus not bundling it by default seems even more needed now IMO. WDYT? Thanks -Vincent

9 years, 5 months

9
14
0 0

[xwiki-devs] [Idea] Page Administration

by Ecaterina Moraru (Valica)

Hi devs, So this proposal appeared in some of my proposals but right now I created a proper Proposal/Idea mail for it. It's about having an 'Administer Page' section in the menus, similar to the 'Administer Wiki' and 'Administer Space' functionality. The 'Administer Page' will be accessible to global admins, page creators and users with (edit?/admin?) rights for the page. >From what we currently have implemented it should contain the 'Rights Editor' (?editor=rights) at page level. In the future we could make 'Presentation', 'Page Elements' or 'Panel Wizard' to be more granular and be set at Page level (have different panels and style for just one page). Some screenshots at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/PageAdministration Thanks, Caty

9 years, 7 months

5
9
0 0

[xwiki-devs] [UX][Consistency][Vote] "Page" vs. "Document" consistent naming

by Ecaterina Moraru (Valica)

Hi, We are using mixed naming when referring to a document/page, not only on different pages, but also in the same context (Rename step for example). There is also an issue referring to this problem XWIKI-5401<http://jira.xwiki.org/jira/browse/XWIKI-5401>and we need to find an answer in order to move forward consistency. So the question is which version we prefer: "Page" or "Document" ? I'm voting +1 for "Page". "Page" is more used IMO, especially in the "Space"/"Page" context. "Page" is more general than "Document" and better fitted for a platform that encapsulates all kind of content (not just documents). Please cast your vote. Thanks, Caty

9 years, 9 months

10
14
0 0

[xwiki-devs] [Proposal] Object addition/removal/update shouldn't change content author

by Vincent Massol

Hi, According to the javadoc in XWikiDocument: /** * The last user that has changed the document's content (ie not object, attachments). The Content author is only * changed when the document content changes. Note that Content Author is used to check programming rights on a * document and this is the reason we need to know the last author who's modified the content since programming * rights depend on this. */ private DocumentReference contentAuthorReference; This means that objectadd or objectremove actions shouldn't change the content author as they do now. I'm proposing that we fix this. Do you see any issue? Thanks -Vincent

9 years, 12 months

7
11
0 0

[xwiki-devs] [Proposal] Split XE pages into platform modules

by Vincent Massol

Hi devs, Here's a proposal to move pages currently located in XE into platform modules: * ColorThemes/*.xml --> xwiki-platform-colorthemes * Main/Activity.xml --> xwiki-platform-activitystream-ui (move current xwiki-platform-activitytream into xwiki-platform-activitystream-api) * Main/AllDocs.xml (and XWiki.Tableview, XWiki.Treeview, XWiki.OrphanedPages, XWiki.AllAttachments*, XWiki.DeletedDocuments, XWiki.DeletedAttachments and all pages used by those) --> new xwiki-platform-navigation module * Main/RssFeeds.xml --> new xwiki-platform-help module or xwiki-platform-rss-ui module (see below) * Main/SpaceIndex.xml --> xwiki-platform-navigation * Main/Spaces.xml --> xwiki-platform-navigation * Main/UserDirectory.xml --> xwiki-platform-user-ui * Main/WebHome.xml --> xwiki-platform-dashboard-ui * Main/WebRss.xml --> new xwiki-platform-rss-ui module, we would create a xwiki-platform-rss-api module too where we will move the feed plugin * Main/Welcome.xml --> move to xwiki-platform-dashboard-ui since it's a dashboard gadget which we could consider as a default widget * Sandbox/*.xml --> xwiki-platform-sandbox module (or xwiki-platform-help module) * XWiki/XWikSyntax.xml --> xwiki-platform-help module * XWiki/AttachmentSelector.xml --> xwiki-platform-user-ui or new xwiki-platform-attachmentselector module * XWiki/ClassSheet, ClassTemplate, ObjectSheet, XWikiClasses, * XWiki/GadgetClass.xml --> xwiki-platform-dashboard-ui * XWiki/LiveTableResult*.xml --> new xwiki-platform-livetable module * XWiki/MessageStreamConfig.xml --> new xwiki-platform-messagestream-ui module (and move xwiki-platform-message in xwiki-platform-message-api module) * XWiki/RequestsStatus.xml --> xwiki-platform-administration module or remove from platform till we integrate it in the Admin as an admin tool somewhere since right now I think it's available in the Admin tools application * XWiki/RequiredRightClass.xml --> since it's used in lots of other ui modules I'd propose to move it in java code as a class created on startup. Alternatively start creating a xwiki-platform-rights-ui module (or xwiki-platform-permission-ui module) and move it there * XWiki/SharePage.xml --> not sure…. maybe in a xwiki-platform-share or xwiki-platform-sharepage module * XWiki/TemplateProvider*.xml --> xwiki-platform-administration for the moment * XWiki/WebHome.xml --> xwiki-platform-administration module * XWiki/WebPreferences.xml --> xwiki-platform-administration module WDYT? Please try to tell me if you're ok for each line if you have time ;) Thanks -Vincent

10 years, 3 months

8
20
0 0

[xwiki-devs] Inject Warning in Page when Macro in Space not exists

by Matthias Wegner

Hi All, i want to put a {{warning}} in the header of a page when a specific macro is not contained. How can i do that. I tried in a Listener when the needed Macro-Block is not contained with doc.getXDOM().getRoot().addChild(new WordBlock("{{warning}}Warning Text.{{/warning}}")); context.getWiki().saveDocument(doc, context); This not works. What is the correct way to manipulate the Document DOM on Load? Regards, Matthias -- View this message in context: http://xwiki.475771.n2.nabble.com/Inject-Warning-in-Page-when-Macro-in-Spac… Sent from the XWiki- Dev mailing list archive at Nabble.com.

10 years, 4 months

2
1
0 0

[xwiki-devs] Overwrite Method of Component in Velocity

by Matthias Wegner

Hi All, I want to create a component where i can overwrite a method of the component from velocity or groovy script inside a wiki page. Its also fine if i can "read" a groovy script to the component so i can use the defined logic. Maybe i have to use a own programmed macro for that. Is that possible? Do you use something similar somewhere? Regards, Matthias -- View this message in context: http://xwiki.475771.n2.nabble.com/Overwrite-Method-of-Component-in-Velocity… Sent from the XWiki- Dev mailing list archive at Nabble.com.

10 years, 4 months

2
1
0 0

[xwiki-devs] Questions about fixing getRenderedContent() bug

by Vincent Massol

Hi, Im trying to fix http://jira.xwiki.org/jira/browse/XWIKI-4274 Basically if you do $xwiki.getDocument("someDoc").getRenderedContent() it'll get executed in the context of the current doc which I believe is wrong especially since other signatures of getRenderedContent() execute in the target document's context. I have fixed this locally but found that admin.vm for example is assuming that getRenderedContent() will get executed in the context of the calling doc (i.e. XWiki.Import when doing an import for example). FYI the chain flow is admin.vm -- getRenderedContent() --> XWiki.AdminSheet --> XWiki.AdminImportSheet --> importinline.vm, which requires the current doc to be XWiki.Import (to get/put attachments from/to it). I can fix this easily using a new getRenderedContent signature I've introduced. However I'm wondering if we have other places that incorrectly use getRenderedContent() and assume it won't be rendered in the context of the target document. Is this change too dangerous to make? If not know, we'll need to it quickly (2.1M1?) since it's an important bug IMO. WDYT? Thanks -Vincent

10 years, 4 months

4
7
0 0

[xwiki-devs] [Contrib] Request repository for Recruitment Application

by Alexandru Chelariu

Hello, I would like to request a repository on xwiki-contrib for the Recruitment Application i am working on. I'd like the repo to be named application-recruitment and also jira component. My github username is chalx. Thank you, Alexandru Chelariu

10 years, 8 months

4
3
0 0

[xwiki-devs] [ANN] 10 years of the XWiki open source project!

by Vincent Massol

Hi everyone, On the 15th of December (i.e. in a month's time), it will be **10 years** since the first commit on the XWiki open source project. Ludovic did the first commit in CVS on Sourceforge: " 15.12.2003 10:13:33, by ludovic Initial revision " (Can be seen at http://svnsearch.org/svnsearch/repos/XWIKI/search?from=20030101&to=20040101 ) 10 years is starting to be some respectable milestone! I invite everyone to join us in celebrating by adding your own story about your interaction with the XWiki community or the XWiki software at http://dev.xwiki.org/xwiki/bin/view/Drafts/TenYearsOfXWiki <XWiki SAS hat> Since I'm also the CTO of the XWiki SAS company, I'd like to officially invite all the members of this great community to join us in celebrating the 10 days of the XWiki project at the XWiki SAS office in Paris, France on the 12th of December 2013. Here's the invitation: http://www.xwiki.com/lang/en/News/XWiki+10th+Anniversary See you there! </XWiki SAS hat> Well done everyone! -Vincent Massol

11 years

2
2
0 0

[xwiki-devs] [Proposal] Cleaning our POM deps by explicitly listing used dependencies?

by Vincent Massol

Hi devs, Running mvn dependency:dependency-analyze produces interesting results. For example: [INFO] --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [INFO] Building XWiki Commons - Properties 3.2-SNAPSHOT [INFO] --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- … [INFO] --- maven-dependency-plugin:2.3:analyze (default-cli) @ xwiki-commons-properties --- [WARNING] Used undeclared dependencies found: [WARNING] org.slf4j:slf4j-api:jar:1.6.1:compile [WARNING] javax.inject:javax.inject:jar:1:compile [WARNING] Unused declared dependencies found: [WARNING] org.xwiki.commons:xwiki-commons-component-api:jar:3.2-SNAPSHOT:compile [WARNING] org.xwiki.commons:xwiki-commons-test:jar:3.2-SNAPSHOT:test [WARNING] org.hibernate:hibernate-validator:jar:4.2.0.Final:test [WARNING] org.hamcrest:hamcrest-core:jar:1.1:test [WARNING] org.jmock:jmock:jar:2.5.1:test The question is (for this module but more generally for all others): * Should we add slf4j and javax.inject reps in the pom.xml for this module? (for ex today slf4j and javax.inject are found in the component-api dep) I think we should, wdyt? Note that the "Unused declared dependencies found:" doesn't always generate correct results as is the case here. This is mostly because it's a static byte code check so any dep used at runtime will be considered unused. See http://www.sonatype.com/books/mvnex-book/reference/optimizing-sect-dependen… Thanks -Vincent

11 years

6
16
0 0

[xwiki-devs] [Proposal] Hidden wikis & template wikis

by Guillaume "Louis-Marie" Delhumeau

Hi devs. In the coming 5.3 milestone 2, all wikis are displayed in the Wiki Index, including the templates, which was not the case before. >From the user point of view, maybe these templates should not be listed in the Wiki Index. But on the other hand, if you want to see a template, you will not be able to access through the wiki index. We also have introduced the "hidden" flag for wikis (in the WikiDescriptor, not in the UI yet). If we consider template wikis are "technical" wikis, we may use this flag to hide them. Then, in the Wiki Index, we don't care if a wiki is a template or not, we only care about the "hidden" flag. If the user does not want to see the templates in the list, she can mark them as hidden, exactly as we do for documents. But what about the template list in the wiki creation wizard? Should we list all templates, or only the visible ones? My proposition: - all wikis are visible though the wiki index (template or not). - if we want to hide templates to the users, we use the hidden flag in the wiki descriptor. - in the wiki creation wizard, we display all the templates, even these which are tagged as hidden. WDYT? Thanks, Louis-Marie

11 years, 2 months

5
6
0 0

[xwiki-devs] [VOTE] Remove all duplicated information from folders names on git repositories

by Thomas Mortagne

Reviving http://markmail.org/message/hlnqke3igkbec332 for as an official vote. We have waited way too long and I think we really need to find a solution even if none of the committers use Windows since a long time. Every time a Windows dev even think of contributing he is very quickly discouraged... As a reminder the issue is that working on XWiki source code is a pain for MS Windows developers because of the (impossible to understand I agree) limitation on path size. So the idea is to find a new logical rule to drastically shorten our paths and Sergiu proposed the following: remove duplicated information from our paths to maven modules. Here is an example: xwiki-platform-core/xwiki-platform-rendering/xwiki-platform-rendering-transformations/xwiki-platform-rendering-transformation-macro (131 chars) would become core/rendering/transformations/macro (36 chars) So WDYT ? Here is my +1 I also find it nicer when navigating using cd and tab in a unix shell anyway. Planning to do it in 5.1 if everyone agree. -- Thomas Mortagne

11 years, 3 months

9
34
0 0

[xwiki-devs] [Discussion][Skin] Bootstrap integration inside platform

by Ecaterina Moraru (Valica)

Hi, As part of the 6.0 Roadmap we have as entry the creation/integration of a new Skin inside XWiki. Currently there are 2 proposals for the new skin: Flamingo http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4x Junco http://design.xwiki.org/xwiki/bin/view/Proposal/JuncoSkin Both proposals are done using Twitter's Bootstrap framework ( http://getbootstrap.com). This thread's purpose is to discuss possible problems we might face by integrating Bootstrap inside platform. You can find the investigation page at http://design.xwiki.org/xwiki/bin/view/Proposal/BootstrapIntegration Besides the already mentioned problems I would want to know the community's opinion about this framework. Have you worked with it? Do you think we should consider some alternatives? See some other frameworks at http://usablica.github.io/front-end-frameworks/compare.html Thanks, Caty

11 years, 3 months

7
9
0 0

[xwiki-devs] [VOTE] Create reference to macros

by Denis Gervalle

Hi devs, While building the new signed script solution with Thomas, we have the need to create a new kind of entity references for macros. This will allow us to keep reference to signed macros. Those references will have entityReference as parent, since macros may be contained in document, but also in object properties. Currently we do not need a syntax for those references, since these will only exists as objects. So, no string serializer is planned. So, we need to agree on creating macroReference that will have at this point a unique identifier (to be discussed later) and a parent that could be either a documentReference or an objectPropertyReference. Here is my +1, -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

11 years, 3 months

4
8
0 0

[xwiki-devs] [Contrib] Request repository for integration between XWiki and Activiti

by Sorin Burjan

Hello, Last year I worked for my master thesis on a integration between XWiki and Activiti. Activiti is a popular open-source workflow execution engine. ( http://activiti.org/) I'd like to commit my work so others can use and improve it. For this, I'd like a repository called application-activiti for the source code, and also a JIRA project called Activiti Application with the key ACTIVITI. Thanks in advance, Sorin B.

11 years, 3 months

6
11
0 0

[xwiki-devs] [Vote][Skin] Keep Colibri look or have another look for 6.x

by Ecaterina Moraru (Valica)

Hi, As part of the 6.0 Roadmap we have as entry the creation/integration of a new Skin inside XWiki. Currently there are 2 proposals for the new skin: Flamingo http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4x Junco http://design.xwiki.org/xwiki/bin/view/Proposal/JuncoSkin = Similarities = * Both skins have been done using the Twitter's Bootstrap framework ( http://getbootstrap.com) * Both skin are thus responsive = Differences = * Flamingo is just a proposal, while Junco is an extension. The difference is that while for Flamingo I have just a prototype, Junco is functional and installable (with some integration problems/dependencies discussed in another thread). The difference matter just from a development time perspective (if we choose Flamingo it will take longer to implement). * Flamingo provides a new look while Junco offers 'Themes', one of themes being very similar to Colibri, see http://extensions.xwiki.org/xwiki/bin/view/Extension/Junco+Skin#HTheme:Coli… This vote mail is about this difference. What to consider: A. Freshness Advantages of Flamingo is that its interface is centered around Applications (it has a new left panel used for navigation). It will provide a visual difference from Colibri and looks more similar to current applications found in the wild. Advantages of Junco is that it provides Themes. Junco's Themes are very similar to our current ColorThemes, the difference is that they can change also the font used, the colors and can also add some esthetic effects (gradients, borders, shadows, etc. - CSS effects) to Bootstrap's components (buttons, navbars, alerts, tables, etc.). But except minor changes, the layout is similar to Colibri. Improvement consist in using refreshed style for font, forms, buttons, messages, etc. B. Extensions Integration One of the reasons I choose to make Junco similar to Colibri was extensions integration. The advantage of XWiki is that you can extend it how you like. The problem is that because the extensions are developed by our community (and not by a single entity) each application is providing it's own style. On extensions.xwiki.org we have applications that provide an unique style, while others are build around and for Colibri. Adding a new skin with a different style (like Flamingo) will make current extensions not look unitary. This problem is more general than just this Colibri/Junco/Flamingo discussion and it the problem of having extensions that adapt to the skin used (without creating special versions for each skin). Junco was created to look similar to Colibri (preserving layout, style, colors) while updating the 'back-end' (created on Bootstrap, it will put at developer's disposal the Bootstrap's guide style and components). One of the reasons we are having this extensions 'incompatibility' is because we are lacking visual standards and guides (maybe using the ones provided by Bootstrap can improve this area - I will send a separate mail about the CSS Framework selection). So from the style standards perspective having Junco integrated first could represent a transition step between our current Colibri and a new skin with a different look, because the developers might use Bootstrap style/structure guides in their extension development (not guaranteed). C. Parallel skin support Another advantage of Junco is that (by having the same layout) is using the same templates as Colibri. Having just a set of templates to maintain is very important from a development perspective especially if your development resources are limited. This is one of the reasons XWiki is not supporting multiple default skins. Flamingo will need some templates changed, so important from a development time and maintenance perspective. So this vote is about: 1. Keep Colibri's current look which is supported by the Junco skin, or 2. Have another look for 6.x which is proposed in the Flamingo skin Thanks, Caty

11 years, 3 months

4
8
0 0

[xwiki-devs] [Discussion][Skin] Less vs. Sass vs. Velocity

by Ecaterina Moraru (Valica)

Hi, As part of the 6.0 Roadmap we have as entry the creation/integration of a new Skin inside XWiki. Currently there are 2 proposals for the new skin: Flamingo http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4x Junco http://design.xwiki.org/xwiki/bin/view/Proposal/JuncoSkin Both proposals are done using Twitter's Bootstrap framework ( http://getbootstrap.com). Bootstrap officially is written using Less ( http://www.lesscss.org/ ) and is the default pre-processor they support. There is also a Sass ( http://sass-lang.com/ ) version for Bootstrap ( https://github.com/twbs/bootstrap-sass ) so the idea is that the preprocessor variant is not limiting us in integrating Bootstrap. The question we discuss in this thread is what preprocessor we should integrate in platform when we integrate Bootstrap (that in the case we integrate either of these tools). Currently Junco's extension is done with Bootstrap + Less. My decision to use this combination was done after a light research and mostly based on a personal preference of the Less language. We are having this preprocessors discussion so late (they appeared in 2007-2009) because we didn't really need a preprocessor until now. The base functionality they add we solved by using Velocity (we have CSS3 prefix macros defined in macro.vm that are similar to the compatibility mixins provided by Bootstrap, we have also a ColorThemes variables solution for reusing color values and because we can have Velocity code inside our stylesheets we cover most of the functions&operations need). The only downside for us using Velocity to do these kind of things is that the functionality we cover is very basic and was done only if we had a certain need. This is not necessarily a bad thing but it's kind of a limitation for external developers that might want to make more complex things. Less and Sass community members are very active and they make sure their functionality is tested and covers most of the cases. Also there are some features (like extends, etc.) that would be hard for us to duplicate in Velocity. Just as a note, adding Less doesn't mean we are replacing Velocity. We are just replacing the CSS things done in Velocity with Less functionality. Replacing Velocity with another templating engine should be the topic for another thread (in case we are considering this). If we integrate Less, what is currently done with CSS+Velocity will be done using Less(CSS)+Velocity(less code). If we integrate Sass (because Sass also has control directives) we transform CSS+Velocity in Sass(CSS)+Velocity(even less code) but the API calls will still need to be added with Velocity (so still we will not have just Sass). One of the problems with the preprocessors is that they depend on Javascript or Ruby (there are some versions also on Java in case of Sass, but not officially maintained). So first we need to find a solution to compile Less/Scss files into CSS, inside our platform. If you make a Google search you'll see that there are much more 'recommendations' to pick Sass over Less. One remark regarding this is that we need to understand that right now Sass is used on a different technologies stack (mostly for Ruby applications). Sass is very attractive because of its power. But what we need to ask ourselves is if we need the full power of Sass (because some of it is already covered by Velocity). Personally I prefer Less, but that's because of the separation of concerns (structure, presentation, behavior). I prefer the limitations Less has (regarding control structure) in order to not be tempted to write logic with a language that is not supposed to do that (even though it can). Preprocessors should be used exclusively to write CSS and especially to write it more rapid (nesting, mixins). Also Less syntax is more close to default CSS syntax, which IMO is a big plus. But because of its power, Sass could be in the future the new 'JQuery', since right now it has a bigger community. One of the advantages of picking a technology later is that at least you see some clear candidates (and we don't need to consider other preprocessors like Stylus, etc.). Let me know what you think. Thanks, Caty

11 years, 3 months

3
5
0 0

[xwiki-devs] [Proposal] XWiki 6.0 + 5.4.1 roadmaps

by vincent＠massol.net

Hi devs, XWiki 6.0 ======== As usual here’s a proposal resulting from discussions I’ve had with XWiki committers who work at XWiki SAS for 6.0. * Collaborative Applications (Meeting, Calendar, (new) Forum, Tasks, Doodle, Photo) - Caty to work on usability and design (she’s started already at http://design.xwiki.org if you wish to follow the work). Andrea who’s a contributor is helping on the test + implementation part. There might be another contributor joining too. This work is currently done inside xwiki-contrib. * New skin! Caty for the design and Guillaume Delhumeau for the implementation part. We’ve been dreaming about this skin for a while. Caty has whet our appetite with screenshots from Junco (http://design.xwiki.org/xwiki/bin/view/Proposal/JuncoSkin and http://extensions.xwiki.org/xwiki/bin/view/Extension/Junco+Skin) and from Flamingo (http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4x). The idea is to establish new strong foundations for new skins (like standardizing on bootstrap classes for example) + have a new L&F. Caty and Guillaume will make proposals on the list about this. * At last we agreed to work on identifying performances issues (especially page load times) and work to fix them! Thomas is in charge of leading this extra important domain. One idea is to establish some automated tests to measure current performances and get a baseline so that we can then monitor our progress and start fixing things (and ensure we keep getting better all the time in the future). Thomas will send some proposals on the list too on this to let us know how he plans to tackle performance improvements. * Of course we need to keep some time to fix any remaining issues we get on the major feature we developed in 5.x + some improvements. I’m thinking about our SOLR search, Multiwiki integration, EM/DW, scalable import/export, etc. Thomas needs to finish the scalable import feature which is already well under way (see below). * Marius agreed to lead an investigation on CKEditor to see if it would make sense for us to use it as a replacement of our homemade editor. The general issue is that maintaining a WYSIWYG editor takes time and this is not really our core business at xwiki. We have 2 choices basically: have someone constantly working on improving our WYSIWYG editor or integrate an existing one so that we can benefit from the work of others. In the past few years we haven’t added that many features to our editor so it’s time to evaluate the feasibility and cost of using an external editor such as CKEditor. * The way users develop applications in XWiki hasn’t changed much over the past 10 years. Since then there’s been an explosion in the area of JS frameworks. We want to make it super easy to develop modern applications using XWiki (read ajaxy applications with new dev models). Marius agreed to lead this investigation along with the help of Guillaume Delhumeau. Since it’s an important aspect of XWiki and a complex one, they’ll need to drive various discussions and brainstorming with everyone and make some proposals so that we all agree to the directions we wish to go towards and so that we can start implementing it in 6.1. * Denis is going to continue working on Script signing as way to replace the existing Programming Rights which has shown its limitations. Denis has committed a new Crypto API in 5.x which is a strong base for the script signing implementation. In addition, during those discussions some raised a list of JIRA they consider important and that would be interesting to tackle if we get the time: - Support 2 roles for users for app within minutes: application creator and data creator - XWIKI-8757 - xwiki.cfg & xwiki.properties merging - Add default column and sort choices in AppWithinMinutes livetable setting - XWIKI-9659 - Save & view a section should go to the section anchor instead of the top of the document - XE-1335 - Add a message for the Livetable's empty state - XWIKI-7821 - "Space Templates" should also create the space preferences page - XWIKI-9712 - The Wiki UIExtensions should check the rights before executing extension points - XWIKI-9156 - Add an explanation next to the fields in user profile - XWIKI-6307 - When creating a new sub-wiki, pages are listed with guest - XWIKI-9888 - Cannot remove all panels using the Panel Wizard for space preferences - XWIKI-9891 Please comment if anyone sees a concern or if I have forgotten something! XWiki 5.4.1 ========= In addition we identified the need for a 5.4.1 release to: - finish important issues for the 5.x cycle and any leftover from 5.4. Our idea is to have usable and stable implementation for the bug items we worked on in 5.x: SOLR search, multiwiki integration, EM/DW and scalable export (scalable import has been pushed to 6.0 since we considered it too dangerous to plug by default in the default import UI in 5.x). - implement support for IE11 (there are only a few issues open). Marius agreed to work on the IE11 fixes. The reason we wish to implement this support is because we’re seeing more and more users reporting issues and asking for this support. ATM we support IE till IE9 only. IE10&11 are currently not officially supported at http://dev.xwiki.org/xwiki/bin/view/Community/BrowserSupportStrategy It would be nice that after 5.4.1 we could edit this doc and mark them supported! Dates ===== I’m proposing the date of 17 of Feb for the final release of 5.4.1, assuming 5.4 is released on the 3rd of Feb as currently planned (i.e. 2 weeks after the release of 5.4). For 6.0: - 5.0M1: 10th of March 2014 (ie 3 weeks) - 5.0M2: 31st of March 2014 (ie 3 weeks) - 5.0RC1: 14th of April 2014 (ie 2 weeks) - 5.0Final: 28th of April 2014 (ie 2 weeks) TOTAL: 10 weeks, ie 2.5 months. WDYT? Thanks -Vincent

11 years, 4 months

6
12
0 0

[xwiki-devs] [Contrib] Reporting extensions issues

by Ecaterina Moraru (Valica)

Hi, This mail should be seen as feedback for improving our e.x.o ( extensions.xwiki.org) and our contributions process, while answering some of my questions :) Right now I am playing and testing some XWiki extensions from e.x.o. The problem that I have is that I don't know where is the best place to report bugs and issues. 1. First of all I think we should add a 'Issue Tracker' field in the repository application, where the developer should state where the issues should be reported (what is the preferred way of reporting and even if the developer is available for further iterations of the extension). 2. What issue tracker we should use and how? Right now there are several ways the users can give feedback for a certain extension: A. Direct e-mails to the developers: I've received couple of times e-mails with questions about the extensions I've developed. This approach is not recommended since we are doing open development and other users might have the same question. Usually I suggest to use the mailinglist ( http://dev.xwiki.org/xwiki/bin/view/Community/MailingLists ) if there are additional questions, but an issue tracker could also solve the problem. B. Community mailinglist: We receive many questions about the extensions on the mailinglists. The problem is that the answers are very hard to track and share among other users (you need to know that the question has been asked before and than that an answer has been provided). An issue tracker would improve the process. C. Comments on the extension page: There are several extensions that have comments on their extension page. While this approach is the most accessible, it is hard to know what is the status of a comment and the responsible person for it (was it fixed already? in what version? is the comment still valid?). D. GitHub issue tracker: While some extensions contain just snippet code or local XARs, other have a repository attached to it. I know some extensions that track their issues on github. The advantages of this approach is that you keep total control of your extension and also you don't need approvals from xwiki community to have your repository created or help with the management of it (rights, etc.). You handle your own development while using e.x.o as a publishing platform. The above statements are in case you have a personal repository. The alternative is to have a repository on xwiki-contrib ( https://github.com/xwiki-contrib ), but these repository could also have the github issue tracker activated. E. jira.xwiki.org project: On jira.xwiki.org there is a whole section of Contributed Projects ( http://jira.xwiki.org/secure/BrowseProjects.jspa#all ). There is also a generic XWiki Contrib project ( http://jira.xwiki.org/browse/XCONTRIB ) " to be used by all projects till they achieve a first release or till they grow to a size significant enough to warrant a dedicated JIRA project" (quote taken from http://contrib.xwiki.org/ ) F. IRC: Even harder than mailinglist to reference. G. other? I've written all the ways in order to agree on the recommended way (which I guess is E.) while I don't think there is a way to force the others from happening. 3. Related extensions vs. Branched extensions vs. Forked extensions My problem is like this: Lets say I want to test the Forum Application. Currently there are 3 versions of the Forum application (read more at http://design.xwiki.org/xwiki/bin/view/Proposal/ForumApplication ). - First of all it was hard to know that we have 3 versions for the 'same' functionality. A feature like "Related extensions" would have been great to have on e.x.o. - Then it was difficult to find out where is the place to report issues for each of these applications (see the whole point of this mail). Currently there are 2 JIRA projects created for Forum (XAFORUM and XBB) but there is no place to report for SimpleForumApp. - It was hard to know what version still work and if there is still active development on it (especially if you have just an attached XAR and not a repository). - It is hard to know if the apps are completely different or if they are just forks of the same base code. Do they share the same functionality, do they want to be improved versions or are just completely different things? These questions are important because they give you an answer if the entries should have separate JIRA projects or we could solve the problem by creating just a COMPONENT in the same JIRA project. - Whose responsibility is it to create the issue tracker, to link to the related applications, etc? (the developer? the contrib managers? other members of the community?) The same questions apply for Calendar Application ( http://design.xwiki.org/xwiki/bin/view/Proposal/CalendarApplication ). I have 3 variants with other related extensions. The only extension that has a JIRA project associated with it is the older extension. So, as an user of the extension, where do I report issues? - Do I need to ask for the creation of a separate project? - Do I ask for the creation of a separate component in the existing project? - Do I report in the generic xcontrib project? - Do I need the permission of the developer to have the project created? - Should we enforce the creation of projects for the new extensions? - How we decide if an extension is big enough or important enough to have its own project? - Who should monitor these growth? (since we actually don't know if the extensions are used or downloaded?) Let me know what you think. Thanks, Caty

11 years, 4 months

2
4
0 0

[xwiki-devs] [Reminder] Review and removal of @Unstable annotation for 6.x

by vincent＠massol.net

Hi guys, According to your rules since we’re starting a new cycle we need to review all existing @Unstable annotations and remove ones that have been there for at least one cycle (i.e. prior to the 5.x cycle). See http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#H40Unsta… It’s also the occasion to check @Unstable APIs that we can consider stable now. Thanks -Vincent

11 years, 4 months

4
9
0 0

[xwiki-devs] [VOTE] Move to Java 7 as minimum supported version

by Thomas Mortagne

Hi devs, I would like to propose that we move to Java 7 as minimum version in XWiki 6.0. You can look at http://jira.xwiki.org/browse/XCOMMONS-432 for details on why and why not. The only cons basically is that Java 6 may still be used in production but we are talking about a version that won't be used in production before at least 3 months. WDYT ? Here is my +1 -- Thomas Mortagne

11 years, 4 months

11
12
0 0

[xwiki-devs] [Proposal] WebJar integration in XWiki

by Vincent Massol

Hi devs, I'd like to make it easy in XWiki to use javascript frameworks required by extensions. I've found the webjars project (http://webjars.org) which packages javascript frameworks in JAR files available in Maven Central. They work out of the box if you drop them in WEB-INF/lib in a Servlet 3.0 container (like Jetty 7). It works because the 3.0 spec says that any files located in META-INF/resources/<path> will be made available by the servlet container as static resources (accessible as <path>). However the servlet 3.0 specs doesn't support adding those JAR dynamically outside of WEB-INF/lib so it doesn't work with our extension mechanism. Thus I'm proposing the following (which I have tested to work): * Add a new WebJarFilter filter to web.xml * The URL to access, for ex, angular.js packaged in the http://repo2.maven.org/maven2/org/webjars/angularjs/1.1.5-1/angularjs-1.1.5… jar would be: /xwiki/webjar/angularjs/1.1.5/angular.js This allows for example to have a dep on: <dependency> <groupId>org.webjars</groupId> <artifactId>angularjs</artifactId> <version>1.1.5-1</version> <scope>runtime</scope> </dependency> Then in a JSX object: require(["/xwiki/webjar/angularjs/1.1.5/angular.js"], function() { … }); WDYT? Thanks -Vincent

11 years, 4 months

5
11
0 0

[xwiki-devs] [Brainstorming] Default rights in subwikis

by Guillaume "Louis-Marie" Delhumeau

Hi devs. Since 5.3, we have this issue opened: http://jira.xwiki.org/browse/XWIKI-9726 - The default rights of subwikis has changed. I am not shocked by the new settings - same as in the main wiki - but it is different from what Workspaces used to be. What do you think about it? Thanks, Louis-Marie

11 years, 4 months

5
8
0 0

[xwiki-devs] [Reminder] BFD#53

by vincent＠massol.net

Hi devs, Today is Bug Fixing Day 53. We're currently at -47 bugs for the 1600 days period: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#53 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11997 Happy BFD! -Vincent PS: I’m sending an email later on to propose some changes for BFDs for the 6.x cycle.

11 years, 4 months

1
1
0 0

[xwiki-devs] [VOTE] Remove feature of extracting the title from the content

by vincent＠massol.net

Hi devs, I’d like to propose removing the feature of extracting the title from the content in 6.x. The rationale is: * This is costing more than it should. It needs parsing the document content to get its XDOM and then to traverse it to find Heading blocks. When we display doc titles in lists (in livetables for example or in the activity stream) it costs a lot to do so. * Our implementation is broken since if you use an include macro that generates a heading for ex, it won’t be taken into account since we don’t apply transformations ATM when computing the title since it would be even more expensive. Since 6.x is about performance I believe this would be a good step forward. Now in order to handle backward compatibility. I propose that we: * Add a legacy configuration parameter to keep the behavior (but off by default). This would be in order to let users using this feature convert their wiki * Move the code to a legacy module (I hope it’s possible) Here’s my +1 Thanks -Vincent

11 years, 4 months

9
10
0 0

[xwiki-devs] [VOTE] Stop supporting export to RTF without an open office server

by vincent＠massol.net

Hi, Our RTF export has never been very good and is even crashing depending on the reader you use (see for example http://jira.xwiki.org/browse/XWIKI-5251 ). I propose to drop the RTF support without OO Rationale: * If a user really needs it he can make it work with an OO server connected to xwiki * RTF is not really a mainstream format * I don’t think we want to invest in fixing our RTF export Here’s my +1 Thanks -Vincent

11 years, 4 months

9
9
0 0

[xwiki-devs] [Proposal] Improving extensions.xwiki.org classification

by Ecaterina Moraru (Valica)

Hi, This mails wants to cover two topics: 1. Improving/cleaning/standardizing a bit the current tags added for e.x.o entries; 2. Proposal to use the tag system to mark the extension's compatibility field. ------ 1. Currently we have 545 tags for 660 extensions (with 705 pages in Extension space). Also we have 367 pages with no tag found in the Extension space. The idea is that I will want to clean a bit the useless tags and keep just the relevant ones. Having useful tags will improve the findability of extensions. Also all extensions should have a tag (right now we have extensions without tags). Tags should be written using small-caps. The current tags are a bit more complex because right now e.x.o also contains 'Snippets' and their scope can be much broader. The current extensions 'Types' (JAR, XAR, Plugin) are very technical and not intended for end-user. I've investigated a bit the tags used on e.x.o and you can see some results here: By Count: http://design.xwiki.org/xwiki/bin/download/Proposal/RepositoryApplicationIm… By Type: http://design.xwiki.org/xwiki/bin/download/Proposal/RepositoryApplicationIm… By Keep: http://design.xwiki.org/xwiki/bin/download/Proposal/RepositoryApplicationIm… The tags investigation images contain a 'Keep' (Y/N) column. If a tag is marked as 'No keep' we should remove that tag (in some cases I provide an alternative found in 'Type/Category' column). This is the first organization, we could further improve on the categories/tags. Having some 'standard' categories but also having multiple extensions share the same tag/category will let us have something like 'Related extensions' in the future. Also very important is to 'standardise' the 'deprecated'/'obsolete'/'archive' tag to mark old/unmaintained extensions. In the future we could display the deprecated extensions in a separate place, maybe called 'Archive'. ------ 2. Right now the 'Compatibility' field of extensions is a free form textarea. This is bad when you want to filter working extensions for a specific version. Example: http://extensions.xwiki.org/xwiki/bin/view/Extension/ForumApplication Adding something in the 'Compatibility' field means that the extension has been tested with that version and not that it works only with that version. Using tags for the 'Compatibility' functionality will improve filtering (and maybe reporting). Also we could parse tags and display in top Compatibility section just the numeric tag entries (that will correspond to the tested versions). The format would be the same as in JIRA: '5.2.4', '6.0-milestone-1', '5.4-rc-1', '4.5.x', etc. Let me know what you think, Caty

11 years, 4 months

1
0
0 0

[xwiki-devs] [Proposal] XWiki Days for the 6.x cycle

by vincent＠massol.net

Hi devs, We’ve done one year of BFD on the 5.x cycle and this has allowed us to reach a greater goal: one of having caught up with the number of open bugs. We’ve first succeeded in closing more bugs than there has been created bugs over a year, then over 2 years, then over 3 years, then over 4 years and we’re very close to succeed for the last 1600 days (ie 4.4 years)! :) I’d like to congratulate everyone on this achievement which is really awesome. I don’t know a lot of other projects who’ve had this kind of success so we can be proud of ourselves! Current result can be seen at: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Note that there are still 357 opened bugs which were created since the beginning of the project. My feeling is that it’s hard to keep the sustained pace we’ve set on the BFD days and I think we need a bit of fresh air. Also now that we’ve caught up with bugs I believe the most important part is to just try to contain the bug ratio so that we’re about even in term of number of new bugs vs umber of bugs we close. If we can achieve this it would already be a very nice success. So what I’m proposing for the 6.x cycle is this: - one week out of 2 we continue doing a BFD - the other week we do a rolling XWiki Day on another activity Here’s a list of other activities we could do (first mentioned in this thread: http://markmail.org/message/a5ew5ilbgxvf67lu ): A) Doc Fixing Day: improve xwiki.org B) Deprecation Fixing Day: reduce # of deprecated calls and move code to legacy C) Violation Fixing Dy: reduce # of violations. 12K right now on platform for ex (see http://sonar.xwiki.org/drilldown/issues/org.xwiki.platform:xwiki-platform) D) Javadoc Improvement Day: Add missing javadocs in our code and remove checkstyle excludes E) Code Coverage Day: Add as many tests as possible (unit and functional) to increase the TPC F) Broken Links Day: fix as many broken links as possible on xwiki.org. To find them is easy: we just need to enable the IRC Link Checker botlet and wait on IRC to get them listed! G) Others you would consider interesting? The only constraint for defining a day is that it contains small elements that can be fixed quickly which is the case for the proposals listed above. So what I propose to be precise: - one week out of 2 we do a BFD - the other week we do one of each (A through F). Then once we’ve done a full round we decide which ones are the best for the project, which ones we want to drop and which ones we want to repeat more often than others. I also propose that the 6th and 13th we still do a BFD and on the 20th of Feb we start doing A, then BFD, then B, etc. WDYT? Any other proposal or better idea? Thanks -Vincent

11 years, 4 months

6
13
0 0

[xwiki-devs] [ANN] XWiki 5.4 Release Candidate 1 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 5.4 Release Candidate 1. This is an improvement and stability release for things started during the 5.x cycle. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download (please allow a few hours for the binaries to propagate to the download servers if the download doesn't work yet) Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki4RC1 Thanks -The XWiki dev team

11 years, 4 months

1
1
0 0

[xwiki-devs] Bootstrap 3.1.0 is out

by vincent＠massol.net

Good to know for our new skin: http://blog.getbootstrap.com/2014/01/30/bootstrap-3-1-0-released/ Thanks -Vincent

11 years, 4 months

1
0
0 0

[xwiki-devs] Pb in 5.4RC1

by vincent＠massol.net

Hi devs, I’ve just rebuilt enterprise and started XE (hsqldb+jetty) and found a problem: a migrator is executed even though I’m running the latest version! 2014-01-29 22:49:57,799 [http://localhost:8080/xwiki/bin/view/Main/] INFO .HibernateDataMigrationManager - The following data migration(s) will be applied for database [xwiki] currently in version [53010]: 2014-01-29 22:49:57,800 [http://localhost:8080/xwiki/bin/view/Main/] INFO .HibernateDataMigrationManager - R54000WikiTemplateMigration - http://jira.xwiki.org/browse/XWIKI-9934 This is not normal obviously and would need to be fixed ASAP before 5.4 final. Thanks -Vincent

11 years, 4 months

3
3
0 0

[xwiki-devs] detect the syntax in the context?

by Paul Libbrecht

Hello fellow developers, at curriki we are slowly evolving to xwiki 2.1 (finally!) and it is not too easy. Some of our objects are rendering user-interfaces messages that are expressed in xwiki syntax. To do so, they have the context. But these objects are rendered sometimes in syntax 2.1 or syntax 1.0… Is there a way to tell the "current" syntax in the context object? thanks paul

11 years, 4 months

3
3
0 0

Re: [xwiki-devs] [Proposal] XWiki 6.0 + 5.4.1 roadmaps

by vincent＠massol.net

Hi , On 28 Jan 2014 at 16:27:44, Arvind Gupta (arvind.bernaulli@gmail.com(mailto:arvind.bernaulli@gmail.com)) wrote: > Vincent > I agree on Flamingo. I will fetch up JIRA issues start documenting it. I will also like to add few tutorial on customising Xwiki. I think it's good to move on with SASS or Less as Caty mentioned in another thread. I have an observation about Velocity. We used velocity as that time it was best available approach. Now front-end matters a lot, If a front guy think that he also have to get acquainted with Velocity also it may discourage him. > > Is there any other approach we should consider? I know it will be a lot of work shouldn't we think replacing Velocity with CSS/Javascript based layout? Note that Velocity is not front end but back end (it’s executed on the server) and thus doesn’t compete with Javascript per see. Also, note that in the mail below there a full domain about: “ * The way users develop applications in XWiki hasn’t changed much over the past 10 years. Since then there’s been an explosion in the area of JS frameworks. We want to make it super easy to develop modern applications using XWiki (read ajaxy applications with new dev models). Marius agreed to lead this investigation along with the help of Guillaume Delhumeau. Since it’s an important aspect of XWiki and a complex one, they’ll need to drive various discussions and brainstorming with everyone and make some proposals so that we all agree to the directions we wish to go towards and so that we can start implementing it in 6.1. “ This could be discussed during this investigation. Now if you wish to elaborate or if you have some specific proposal to make, you could start a new email thread with your proposal and we would discuss it there. Thanks -Vincent > -arvind > > > On Tue, Jan 28, 2014 at 5:42 PM, vincent@massol.net(mailto:vincent@massol.net) wrote: > > Hi Arvind, > > > > On 28 Jan 2014 at 12:25:15, Arvind Gupta (arvind.bernaulli@gmail.com(mailto:arvind.bernaulli@gmail.com)(mailto:arvind.bernaulli@gmail.com)) wrote: > > > > > +1 > > > > > > Are there any other options to CKeditor? > > > > AFAIK this is the strongest one to evaluate. Is there a better one you have in mind? Note that in the past xwiki was using TinyMCE but we weren’t very successful (could have been caused by our wrong usage of it though). > > > > > I would like contribute with documentation of new features. > > > > Great! Here are some JIRA about missing documentation items: http://bit.ly/M96bin > > > > If you’re interested in documenting something else please send us a mail on the users list for example detailing what you wish to do so that others know about it and we could give you some directions/help. > > > > > Should be consider to have new xwiki.org(http://xwiki.org) design along with new UI? > > > > As Caty mentioned, the xwiki.org(http://xwiki.org) design has already been modified not that long ago. My take is that if we agree to develop Flamingo then it would be a good idea to update xwiki.org(http://xwiki.org) with it. > > > > Thanks > > -Vincent > > > > > > > -arvind > > > > > > > > > > > On Tue, Jan 28, 2014 at 4:23 PM, vincent@massol.net(mailto:vincent@massol.net) wrote: > > > > > > > Of course this is only the work planned by the committers I mentioned. > > > > > > > > For the other committers, feel free to add stuff you’d like to work on in > > > > 6.0 so that we can add it to our global roadmap. > > > > > > > > Note: I’ll put all this on > > > > http://www.xwiki.org/xwiki/bin/view/Roadmaps/WebHome in a few days if > > > > people agree about it. > > > > > > > > Thanks > > > > -Vincent > > > > > > > > On 28 Jan 2014 at 11:17:29, vincent@massol.net(mailto:vincent@massol.net) (vincent@massol.net(mailto:vincent@massol.net)) wrote: > > > > > > > > Hi devs, > > > > > > > > XWiki 6.0 > > > > ======== > > > > > > > > As usual here’s a proposal resulting from discussions I’ve had with XWiki > > > > committers who work at XWiki SAS for 6.0. > > > > > > > > * Collaborative Applications (Meeting, Calendar, (new) Forum, Tasks, > > > > Doodle, Photo) - Caty to work on usability and design (she’s started > > > > already at http://design.xwiki.org if you wish to follow the work). > > > > Andrea who’s a contributor is helping on the test + implementation part. > > > > There might be another contributor joining too. This work is currently done > > > > inside xwiki-contrib. > > > > > > > > * New skin! Caty for the design and Guillaume Delhumeau for the > > > > implementation part. We’ve been dreaming about this skin for a while. Caty > > > > has whet our appetite with screenshots from Junco ( > > > > http://design.xwiki.org/xwiki/bin/view/Proposal/JuncoSkin and > > > > http://extensions.xwiki.org/xwiki/bin/view/Extension/Junco+Skin) and from > > > > Flamingo (http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4x). > > > > The idea is to establish new strong foundations for new skins (like > > > > standardizing on bootstrap classes for example) + have a new L&F. Caty and > > > > Guillaume will make proposals on the list about this. > > > > > > > > * At last we agreed to work on identifying performances issues (especially > > > > page load times) and work to fix them! Thomas is in charge of leading this > > > > extra important domain. One idea is to establish some automated tests to > > > > measure current performances and get a baseline so that we can then monitor > > > > our progress and start fixing things (and ensure we keep getting better all > > > > the time in the future). Thomas will send some proposals on the list too on > > > > this to let us know how he plans to tackle performance improvements. > > > > > > > > * Of course we need to keep some time to fix any remaining issues we get > > > > on the major feature we developed in 5.x + some improvements. I’m thinking > > > > about our SOLR search, Multiwiki integration, EM/DW, scalable > > > > import/export, etc. Thomas needs to finish the scalable import feature > > > > which is already well under way (see below). > > > > > > > > * Marius agreed to lead an investigation on CKEditor to see if it would > > > > make sense for us to use it as a replacement of our homemade editor. The > > > > general issue is that maintaining a WYSIWYG editor takes time and this is > > > > not really our core business at xwiki. We have 2 choices basically: have > > > > someone constantly working on improving our WYSIWYG editor or integrate an > > > > existing one so that we can benefit from the work of others. In the past > > > > few years we haven’t added that many features to our editor so it’s time > > > > to evaluate the feasibility and cost of using an external editor such as > > > > CKEditor. > > > > > > > > * The way users develop applications in XWiki hasn’t changed much over the > > > > past 10 years. Since then there’s been an explosion in the area of JS > > > > frameworks. We want to make it super easy to develop modern applications > > > > using XWiki (read ajaxy applications with new dev models). Marius agreed to > > > > lead this investigation along with the help of Guillaume Delhumeau. Since > > > > it’s an important aspect of XWiki and a complex one, they’ll need to drive > > > > various discussions and brainstorming with everyone and make some proposals > > > > so that we all agree to the directions we wish to go towards and so that we > > > > can start implementing it in 6.1. > > > > > > > > * Denis is going to continue working on Script signing as way to replace > > > > the existing Programming Rights which has shown its limitations. Denis has > > > > committed a new Crypto API in 5.x which is a strong base for the script > > > > signing implementation. > > > > > > > > In addition, during those discussions some raised a list of JIRA they > > > > consider important and that would be interesting to tackle if we get the > > > > time: > > > > > > > > - Support 2 roles for users for app within minutes: application creator > > > > and data creator - XWIKI-8757 > > > > - xwiki.cfg & xwiki.properties merging > > > > - Add default column and sort choices in AppWithinMinutes livetable > > > > setting - XWIKI-9659 > > > > - Save & view a section should go to the section anchor instead of the top > > > > of the document - XE-1335 > > > > - Add a message for the Livetable's empty state - XWIKI-7821 > > > > - "Space Templates" should also create the space preferences page - > > > > XWIKI-9712 > > > > - The Wiki UIExtensions should check the rights before executing extension > > > > points - XWIKI-9156 > > > > - Add an explanation next to the fields in user profile - XWIKI-6307 > > > > - When creating a new sub-wiki, pages are listed with guest - XWIKI-9888 > > > > - Cannot remove all panels using the Panel Wizard for space preferences - > > > > XWIKI-9891 > > > > > > > > Please comment if anyone sees a concern or if I have forgotten something! > > > > > > > > XWiki 5.4.1 > > > > ========= > > > > > > > > In addition we identified the need for a 5.4.1 release to: > > > > - finish important issues for the 5.x cycle and any leftover from 5.4. Our > > > > idea is to have usable and stable implementation for the bug items we > > > > worked on in 5.x: SOLR search, multiwiki integration, EM/DW and scalable > > > > export (scalable import has been pushed to 6.0 since we considered it too > > > > dangerous to plug by default in the default import UI in 5.x). > > > > - implement support for IE11 (there are only a few issues open). Marius > > > > agreed to work on the IE11 fixes. The reason we wish to implement this > > > > support is because we’re seeing more and more users reporting issues and > > > > asking for this support. ATM we support IE till IE9 only. IE10&11 are > > > > currently not officially supported at > > > > http://dev.xwiki.org/xwiki/bin/view/Community/BrowserSupportStrategy It > > > > would be nice that after 5.4.1 we could edit this doc and mark them > > > > supported! > > > > > > > > Dates > > > > ===== > > > > > > > > I’m proposing the date of 17 of Feb for the final release of 5.4.1, > > > > assuming 5.4 is released on the 3rd of Feb as currently planned (i.e. 2 > > > > weeks after the release of 5.4). > > > > > > > > For 6.0: > > > > - 5.0M1: 10th of March 2014 (ie 3 weeks) > > > > - 5.0M2: 31st of March 2014 (ie 3 weeks) > > > > - 5.0RC1: 14th of April 2014 (ie 2 weeks) > > > > - 5.0Final: 28th of April 2014 (ie 2 weeks) > > > > > > > > TOTAL: 10 weeks, ie 2.5 months. > > > > > > > > WDYT? > > > > > > > > Thanks > > > > -Vincent > > > > >

11 years, 4 months

1
0
0 0

[xwiki-devs] [Proposal] Members of subwiki migration

by Guillaume "Louis-Marie" Delhumeau

Hi developers! In Workspaces, we used to add global users in the XWikiAllGroup page of a subwiki to indicate that they are members of that wiki. Now, we have an option called "user scope", and we can have both global & local users in a subwiki. That means we have global & local users in XWikiAllGroup. Then, it is a problem because it can not work when XWikiAllGroup is a virtual group [1]. Then, I have proposed to create a new group, called XWikiMemberGroup, that hold the members of the subwiki. (Note: XWikiAllGroup will be a member of XWikiMemberGroup, in order to say "a local user is a member"). So, I have written a migration (again!) [2], to create the new group with the current content of XWikiAllGroup. In this migration, I also changes all existing rights that occur on XWikiAllGroup to make them effective for XWikiMemberGroup. I did not want to duplicate these rights by just adding the sames for XWikiMemberGroup. I think it is easier for the user to only take care of the XWikiMemberGroup. But it looks a bit "magical", and some people don't like it. I would like to have your opinion. +1 for adding XWikiMemberGroup and to "migrate" rights (replace all rights given to XWikiAllGroup by rights given to XWikiMemberGroup). Thanks, Louis-Marie [1] http://jira.xwiki.org/browse/XWIKI-9886 - Enabling virtual XWikiAllGroup breaks wiki membership [2] https://github.com/xwiki/xwiki-platform/compare/feature-wiki-members - Git branch for this proposal

11 years, 4 months

7
18
0 0

[xwiki-devs] WYSIWYG editor menus are behind the editor… how to solve?

by Paul Libbrecht

Hello fellow XWikiers, we are having a bug at Curriki where one positioning of the wysiwyg editor has the following bug: the menus pop-up behind the tool-bar and editor-pane. Other instances of the editor do not have this issue. What should I investigate? Is this z-index (apparently always 12) not dynamically updated depending on the current z-index? paul

11 years, 4 months

2
3
0 0

[xwiki-devs] [Reminder] BFD#51

by vincent＠massol.net

Hi devs, Today is Bug Fixing Day 51. We're currently at -63 bugs for the 1600 days period: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Note that we’re a bit lucky since there was a cluster of bugs that slipped of, thus reducing our bug count from around -120 three weeks ago to -63 now without us closing more bugs than there were creations :) Let’s grab this opportunity to win against the evil bugs! Here's the BFD#51 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11995 Happy BFD! -Vincent PS: Next week I’ll send some proposal for this special day for the 6.x cycle and we can brainstorm about it.

11 years, 4 months

1
2
0 0

[xwiki-devs] [Contrib] New repository for the "Mocca Calendar" Application

by Clemens Klein-Robbenhaar

Hi dev's, I would like to create a repository on xwiki-contrib for the "Mocca Calendar" extension: http://extensions.xwiki.org/xwiki/bin/view/Extension/MoccaCalendar The current Git-Repo is at https://github.com/espresto/xwiki-application-moccacalendar (Of course when moving the groupId in the pom.xml will need to be updated, too) I have the following questions: - Looking at the naming conventions I guess instead of "xwiki-application-moccacalendar" the repo should be named "application-moccacalendar", right? - GitHub user "nedgot" (aka Denis Gotthans, who has actually glued the application together) would like to have write access for that repository, too, if possible. I guess have to make him member of xwiki-contrib at large for that to work, right? - As I have heard rumours that is application might have bugs worth reporting ;) could someone please set up a project on jira.xwiki.org for that? I am not sure what the naming conventions are here, maybe "MOCCACAL" might be a good project name, but I will be happy with anything else that I could point bug spotters too. - Denis Gotthans also has an account on the jira, this time "gotthans" for a change. If the project is set up, could someone give him access to edit issues? Best Regards, Clemens

11 years, 4 months

3
3
0 0

[xwiki-devs] [Brainstorming] Document's Hidden flag behaviour with translations?

by vincent＠massol.net

Hi devs, I’m working to fix http://jira.xwiki.org/browse/XWIKI-9910 but before I can fix it we need to decide something since we have 2 possibilities. - Option 1: The hidden flag is set at document translation level which means when the user check the hidden flag it’s only for the current translation - Option 2: The hidden flag is set at the default document level (not set at translated doc level) which means there’s a single hidden flag ATM the problem with XWIKI-9910 is that when the user checks the hidden flag, it’s set at the translation level but when a translation is displayed the value shown is the one from the default document. Option 1 offers more use cases but: - users may be surprised - users need to be careful to edit the default doc if they wish to set the doc as hidden for all translations I’m not sure what option I prefer. Initially I was more for option 2 but I’m now hesitating and leaning more towards option 1. Note that option 2 means one more DB upate when saving a translated doc. WDYT? Thanks -Vincent

11 years, 4 months

7
12
0 0

[xwiki-devs] help for communication ajax with script velocity

by le bihan matthieu

Hello, For a wiki, I 'd use the ajax but I do not see how it works with velocity . Background: In one of my forms I use two metadata "Database List " type. The first is a list of specialties. The second is a list of people. To make a link between the two lists , I defined a person as follows : specialty_name . Example for a person : his specialty : "test" Name: "toto" The value specified in the second list is " test_toto " My need : Whenever the user changes the state of the form of the first list ( specialty ) I would like to use a velocity script that returns me the list of people associated with this specialty. The parameter passed to the velocity script is the name of the specialty. How do I create the velocity script? You just create a new page , is not it ? If not for the script, there must be specific information to indicate that he must retrieve a value and return a list of users. Regards -- View this message in context: http://xwiki.475771.n2.nabble.com/help-for-communication-ajax-with-script-v… Sent from the XWiki- Dev mailing list archive at Nabble.com.

11 years, 4 months

1
1
0 0

[xwiki-devs] [ANN] XWiki 5.2.3 released

by vincent＠massol.net

The XWiki development team is proud to announce the availability of XWiki 5.2.3. This is a bugfix release fixing a security issue allowing unregistered users some access under some circumstances. We recommend anyone using XWiki 5.0+ to upgrade to it, especially if your wiki is a public wiki. 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/ReleaseNotesXWiki523 Thanks -The XWiki dev team

11 years, 5 months

1
0
0 0

[xwiki-devs] Delay 5.4RC1

by Thomas Mortagne

Hi devs, 5.4RC1 is due today but as far as I can see in http://jira.xwiki.org/issues/?jql=fixVersion%20in%20%28%225.4-rc-1%22%29%20… we are quite a bit short on that. I know at least that for XWIKI-9720 and XWIKI-9579 I will need at least several days then there is BFD and ci is not all blue (as always when being close to a release...). We could say it's ok we actually have one more week before final release but I would prefer that Release Candidate to actually be a release candidate for once so I propose to delay all that to 1 week later which would give us: * 5.4RC1: 27th of January 2014 * 5.4: 3rd of Feb 2014 WDYT ? Here is my +1. -- Thomas Mortagne

11 years, 5 months

5
4
0 0

[xwiki-devs] debugging sheets applications

by Paul Libbrecht

Hello fellow developers, we have met a fairly hard bug on www.curriki.org which has almost delayed our release and required a last minute removal of our new discussions feature: the trigger of the sheet application has not been consistent. It has been inconsistent between servers (development, staging, production) and has been inconsistent between syntaxes. For a while I thought that the lack of the class XWiki.ClassSheetBinding was guilty, but adding it did not change anything. I then went through the XWiki core pages and added as much as possible that could have something related… then it started to work on pages in old syntax but failed with newly created pages (which are copies of a template page). Where could I look to debug this? There seems to be *something* applied, since the rendered page is empty and the content is ignored. Thanks for hints. Paul PS: we're now running xwiki 3.5.1

11 years, 5 months

3
5
0 0

[xwiki-devs] [VOTE] Allow adding new link/images resource types in XWiki Syntax 2.1 or not

by vincent＠massol.net

Hi devs, I’ve just committed support for http://jira.xwiki.org/browse/XRENDERING-278 (which allows copy pasting images in the WYSIWYG editor btw). However I’ve just realized (had forgotten) that my code will break image attachments to a subwiki named “data”: image:data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAO9JREFUOE+lUrsNwjAUdCyWIBXjIEokVoCejgkyQ2gYAIkSsQUrUIUxwrund5bjX4OlyPG9u3v22Z2rjM1uWEtpkq//PC/fCs35UoHi/WGL8mTrErVsAJGJHU2KagGzHUi3I8iP+0s1nInXjBSPSfI/n2/vGTNFJZOVCRkYltdGl1FMRqmHYL0FFM6MjnFXaxCwNJMOZAbW6JyVkI1cbwcD3T5MGBjZLQxi8Lw9kp5iFFikUYwZr2dNQzQT7EavsDFOwl2ErNuIh5kgaX1E0bEyMTiZAcA0WAa26GSL7CUaHjJJz1wyqWLpe6gS/yn8AD9tcjFN7/ajAAAAAElFTkSuQmCC Of course the solution for a user is to prefix with “attach:”, to show that it’s an image coming from an attachment: image:attach:data:…. We discussed this previously: * Original thread: http://markmail.org/thread/vw3derowozijqalr * This lead to this first VOTE which was not conclusive: http://markmail.org/thread/vw3derowozijqalr * Which lead to another VOTE which was also not conclusive: http://markmail.org/thread/t2wb2xq7534qsshg (note that this thread contains 2 proposals, the last one beeing a choice between A) and B)). However we kind of agreed at the end that it would be acceptable to break backward compatibility (solution A in the last thread). So the question here: * Should I revert my change that I did for 5.4? * Is it ok to break backward compatibility and thus add this in XWiki Syntax 2.1 as I did and document it on the release notes? Note that I could also relatively easily implement a new rendering configuration option (e.g. rendering.ignoreResourceTypes=user,data) which would be optional and that would allow to ignore some resource types (IMO this is slightly overkill). WDYT? Thanks -Vincent

11 years, 5 months

3
5
0 0

[xwiki-devs] Moving xwiki-platform-wiki-manager to contrib

by Guillaume "Louis-Marie" Delhumeau

Hi. Since I have implemented a REST api for the creation of subwiki using the new wiki API [1], we can remove wiki-manager from platform [2]. But there is a problem: the new implementation has the exact same interface and the same path than the old one, so we can not have both the new api and xwiki-platform-wiki-manager in the classpath anymore. A solution is to release a new version of xwiki-platform-wiki-manager without its own REST api. I see 2 ways to acheive this: 1/ remove the REST api of wiki-manager and remove wiki-manager in 6.0 or 2/ remove wiki-manager in 5.4 and release a new wiki-manager without the REST api in contrib. What do you prefer? Thanks Louis-Marie [1] : http://jira.xwiki.org/browse/XWIKI-9670 [2] : http://jira.xwiki.org/browse/XWIKI-9671

11 years, 5 months

2
2
0 0

[xwiki-devs] Rights issue with new Struts action

by Mircea Staicu

Hello, I am having some issues with a new custom action that I did to solve a platform issue. My work was done a new branch created from the master branch of xwiki on github. I added the new Action class and the form bean to the 'web' module in the xwiki-platform-oldcore @com.xpn.xwiki.web and I mapped the new action in struts-config.xml. I've build the oldcore, followed by the build on the legacy-oldcore, deployed the legacy-oldcore artifact to my local 5.4-SNAPSHOT instance and deployed the struts-config.xml with the new modifications to the WEB-INF/lib. On accessing my action from the wiki, I get the following: You are not allowed to view this document or perform this action. Is there a mapping of the non-default actions and the rights that one must have in order to run them?

11 years, 5 months

3
4
0 0

[xwiki-devs] [Reminder] BFD#51

by vincent＠massol.net

Hi devs, Today is Bug Fixing Day 51! We're currently at -82 bugs for the 1600 days period: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#51 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11993 Let’s crush those nasties! Happy BFD! -Vincent

11 years, 5 months

1
0
0 0

[xwiki-devs] xwiki-contrib-websocket -- I'd like to move it to contrib and release into maven.xwiki.org

by Caleb James DeLisle

Hi, I just finished working on XWiki/WebSocket integration which allows components which implement XWikiWebSocketHandler and they will be called when a user creates a WebSocket connection to the wiki. Now I'd like some permission and guidance on getting this published as an extension, unfortunately I was a little bit too modular so I can't just upload a .jar and I will have to publish this in maven.xwiki.org What do people think about transferring this to xwiki-contrib and can anyone give me some advice about publishing an extension through maven? For reference, this is the code: https://github.com/cjdelisle/xwiki-contrib-websocket Thanks, Caleb

11 years, 5 months

3
6
0 0

[xwiki-devs] Creation of contrib project for XWiki Rendering + AngularJS demo

by vincent＠massol.net

Hi devs, FYI I’m creating a new repository on xwiki-contrib’s github to host a demo project I’ll present in my FOSDEM talk about XWiki Rendering. It show the following: - exposing XWiki Rendering through a REST resource - realtime rendering of what you type in your browser using AngularJS Thanks -Vincent

11 years, 5 months

1
1
0 0

[xwiki-devs] Rule for configuration property naming in documentation

by vincent＠massol.net

Hi guys, A long time ago I sent a vote for naming configuration property http://markmail.org/thread/xzz2gqmexkgargbz And this is what has been mostly used in xwiki.properties… However some developers have not followed the existing rules. For example: # solr.embedded.home=/var/local/xwiki/solr # solr.remote.url=http://localhost:8983/solr # solr.indexer.batch.size=50 # solr.indexer.batch.maxLength=10000 # solr.indexer.queue.capacity=100000 This is a pity since it’s hard to change a property. I have now taken the time to document it in our dev practices at http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HConfigu… If some dev has an issue with this please raise it here. If not, please make sure to follow it from now on. Thanks -Vincent

11 years, 5 months

2
2
0 0

[xwiki-devs] Issues with 5.2.3 Snapshot

by Sorin Burjan

Hello developers, I have made some tests today the 5.2.3-SNAPSHOT version, and I found out some issues which I don't have on a 5.2.2 install. On a 5.2.2 there is thew following behavior - create test subwiki as "Open" and Admin as creator. * No DW kick in, everything looks ok on the subwiki 5.2.3-SNAPSHOT - create test subwiki as "Open" and Admin as creator. * DW kicks in and asks me if this is an upgrade or not. It does not ask for version. * "Are you performing an upgrade? There are currently 291 documents in the database which indicates this is not a new install. " * Select: "No, this is a new install" * Merge conflicts on pages: XWiki.XWikiAdminGroup, XWiki.XWikiAllGroup, XWiki.XWikiPreferences, XWiki.DefaultSkin, XWiki.SearchSuggestConfig, ColorThemes.WebPreferences, XWiki.WebPreferences * Even that I created the subwiki as Admin, after finishing with the DW, I have the Join button in the Wiki Information panel. * I have an Admin user which is the member of the subwiki, but it seems to be a local Admin. I created the wiki as the global Admin. * Logging off and Logging back in on the subwiki with Admin, I am still logged as the Global Admin, and still not listed as a member of the subwiki. * On the homepage of the subwiki, I have the following text: "You are a member of this wiki. $services.localization.render('platform.workspace.currentUserCanLeave', $leaveUrl)" Just wanted to point these issues out before we release 5.2.3. Regards, Sorin B.

11 years, 5 months

2
4
0 0

[xwiki-devs] [Reminder] BFD#50

by vincent＠massol.net

Hi devs, Today is Bug Fixing Day 50 (announcing a bit late sorry, I had forgotten ;)). We're currently at -90 bugs for the 1600 days period: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#50 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11991 Happy BFD! -Vincent

11 years, 5 months

1
1
0 0

[xwiki-devs] Where is the documentation for the Confluence importer?

by vincent＠massol.net

Hi Thomas, I wanted to point someone to our documentation for the new Confluence importer but I couldn’t find documentation for it. All I’ve found was http://extensions.xwiki.org/xwiki/bin/view/Extension/XWiki+Platform+-+Wiki+… which is too technical and doesn’t contain much information. I think we need a user-friendly documentation for the Confluence importer that appears in the XE feature list on http://enterprise.xwiki.org/xwiki/bin/view/Main/Features Also we should comment on http://extensions.xwiki.org/xwiki/bin/view/Extension/Convert+Confluence+to+… to add an {{info}} message to explain there’s now a better way, no? WDYT? Thanks -Vincent

11 years, 5 months

2
2
0 0

[xwiki-devs] [Proposal] XWiki 6.x Cycle Theme

by vincent＠massol.net

Hi devs, We’re getting close to the end of the 5.x cycle with 5.4 and we need to find a new theme for 6.x. At XWiki SAS we’ve had an internal meeting to brainstorm about what that theme could be and we’ve come up with the following idea: Theme motto: “Slick and Slim” Explanations: * Performance improvements across the board: page load time, scalability, activity stream rewrite, memory usage rationalization * Introduce the flavor mechanism (as already discussed here) with the idea of removing the maximum of extensions from the base and be able to build a minimal, lightweight wiki + create a few flavors (as already discussed here too). * Slickiness achieved with things like new skin (see the proposal from Caty) + syntax highlighting + autocompletion + easier rights UI + etc… In short we’ve realized that XWiki has grown along the years and it’s becoming a bit heavyweight in various aspects. So the idea would be to focus on performances + ease of use to slim it down and ensure it’s kicking fast! Of course, as usual, I’m sure there’ll be other things being worked on, but the idea would be to try our maximum to work within this theme. WDYT? Thanks -Vincent

11 years, 5 months

6
6
0 0

[xwiki-devs] [ANN] XWiki 5.4 Milestone 1 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 5.4 Milestone 1. This is an improvement and stability release for things started during the 5.x cycle. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download (please allow a few hours for the binaries to propagate to the download servers if the download doesn't work yet) Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki54M1 Thanks -The XWiki dev team

11 years, 5 months

2
1
0 0

[xwiki-devs] [ANN] Guillaume Delhumeau is now a committer

by vincent＠massol.net

Hi devs, Guillaume Delhumeau has been voted as a committer by the other committers and he’s accepted the role! :) http://dev.xwiki.org/xwiki/bin/view/Community/Committership Guillaume had been contributing daily to the XWiki project since last July (AFAIR), contributing recently to the Workspaces integration in XE. Welcome aboard! Thanks -Vincent

11 years, 5 months

7
6
0 0

[xwiki-devs] [ANN] Welcome our new committer Clemens Robbenhaar

by Thomas Mortagne

Hi xwikiers, The committers discussed and voted to include Clemens Robbenhaar in the team which he agreed so a warm welcome to him ! He has been very active since he started working on XWiki, he already spend a lot of time answering questions on the mailing list and on IRC (more than me I think). On the technical aspect everything I saw from him was good and very clean and he is clearly no afraid to look at advanced stuff (he spent a long time last month trying to help Kaisen and Denis on migration stuff which I'm sure was not that critically related to his own work). Note that he is working on XWiki for EsPresto AG (don't forget to add it to http://main.xwiki.org/xwiki/bin/view/Main/Support). I'm sure he will be great addition to the team and it's always a nice bonus to see non XWiki SAS members so active ;) Welcome ! -- Thomas Mortagne

11 years, 5 months

5
4
0 0

[xwiki-devs] [Brainstorming] Do we still want to be accessible without javascript

by Guillaume "Louis-Marie" Delhumeau

Hi devs, In a recent pull request (https://github.com/xwiki/xwiki-platform/pull/254), I have "fixed" a bug reported by the accessibility validator by hiding a link if javascript is not enabled on the browser. It didn't fix the fact that the feature is unavailable without javascript, but at least the link was not there. I did it because I have the feeling that some committers think we don't need support the navigation without javascript in 2014. Now, it seems that we do not all agree about this. That is why I think we should talk about this to decide what rule we should put in place for the next years. Thanks, in advance, for your opinions. Louis-Marie

11 years, 5 months

8
15
0 0

[xwiki-devs] How to end/finish respose programmatically?

by Valdis Vītoliņš

Due to performance reasons I had to improve Groovy script to print results directly to the response object: {{groovy}} response.setContentType('application/xml'); response.setCharacterEncoding("UTF-8"); def out=response.getWriter(); try { ... out.println('<?xml version="1.0" encoding="UTF-8"?>'); out.println('<certificates>'); ... But now problem is that after that I got additional XWiki HTML even using ?outputSyntax=plain parameter. I suspect, I need to end/close response somehow programmatically. Any hints? Thanks in advance

11 years, 5 months

3
3
0 0

[xwiki-devs] [Brainstorm] Application development best practices

by vincent＠massol.net

Hi devs, I’ve started to list at http://platform.xwiki.org/xwiki/bin/view/DevGuide/ApplicationDevelopmentBes… the list of best practices that we use for developing XWiki Applications. Please let me know if there’s something that is wrong there (i.e. that we’re not doing) Also, please add if you find missing things (I’m sure there are plenty ;)). Please make sure that you **only** add practices that we are **currently** following. Thanks! -Vincent PS: Actually I think this page should be moved to dev.xwiki.org and linked from http://platform.xwiki.org/xwiki/bin/view/DevGuide/BestPractices WDYT?

11 years, 5 months

2
2
0 0

[xwiki-devs] [Reminder] BFD#49

by vincent＠massol.net

Hi devs, Today is Bug Fixing Day 49 (announcing a bit late sorry, I had forgotten ;)). We're currently at -119 bugs for the 1600 days period: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 As you can see on the graph we’ve been stagnating for a while now, we’ll need to draw some conclusions about this soon. Here's the BFD#49 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11893 Thanks -Vincent

11 years, 5 months

1
1
0 0

[xwiki-devs] 5.4M1 release day today + RM + lateness

by vincent＠massol.net

Hi devs, Today is release day for 5.4M1. I see that there are quite a few broken functional tests (GuillaumeD, it seems you’ve broken the build 2 weeks ago… could you please fix it ASAP?). Could everyone check the CI to see if there’s anything they can fix? We also need a RM to start the release. Any volunteer? (If not, I’ll propose someone based on http://dev.xwiki.org/xwiki/bin/view/Community/ReleaseManagerRoster Good candidates: GuillaumeD, Denis, Sergiu and then Thomas, Vincent and last Marius who’s been doing quite a lot during the 5.x cycle). Please don’t commit anything that may fail the build ATM since we need to release M1. Note that I’m worried since the next release is RC1 and not much has been done compared to the defined roadmap… Please make sure that you can still implement what you had planned to do. Let me know how you wish to proceed. Thanks -Vincent

11 years, 5 months

2
1
0 0

[xwiki-devs] Happy New XWiki Year!

by Ricardo.Julio.Rodriguez.Fernandez＠sergas.es

http://ow.ly/sanLQ Thanks for your hard work, for this nice product and even better community! Warm regards, Ricardo -- Ricardo Rodríguez Research Management and Promotion Technician Technical Secretariat Health Research Institute of Santiago de Compostela (IDIS) http://www.idisantiago.es Nota: A información contida nesta mensaxe e os seus posibles documentos adxuntos é privada e confidencial e está dirixida únicamente ó seu destinatario/a. Se vostede non é o/a destinatario/a orixinal desta mensaxe, por favor elimínea. A distribución ou copia desta mensaxe non está autorizada. Nota: La información contenida en este mensaje y sus posibles documentos adjuntos es privada y confidencial y está dirigida únicamente a su destinatario/a. Si usted no es el/la destinatario/a original de este mensaje, por favor elimínelo. La distribución o copia de este mensaje no está autorizada. See more languages: http://www.sergas.es/aviso_confidencialidad.htm

11 years, 5 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs January 2014