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

[xwiki-devs] Questions concerning the development of XWiki, Final Round

by Martin Schönberger

Hello again, and let me start once more by thanking everyone who bore with me until now. The answers you gave me so far helped a great deal for me to understand the details of this project's development as an example of open source processes and their underlying structures. In the final round of this extended interview I would like to conclude with a few questions which move a bit outside the box and beyond the horizon. ;) As I explained in one of my earlier posts, I am researching open source development processes in comparison to other approaches of developing software, and trying to find out how they relate to each other in different aspects. Besides examining those aspects, however, I am also interested in your opinion about the process. Do you see similarities to agile methods of development, or to the well-defined processes of software engineering, in your approach? Where can these similarities be found, and where do they end? Finally, may I ask you for a quick outlook into the future of XWiki? Which chances and challenges do you see coming up? In what direction would you like the development of XWiki to go in the following years? Also, do you have any points you would like to additionally mention, some vital aspect of the process I failed to address, or a special emphasis on anything you feel we did not talk about enough? I am glad for further hints and comments. :) Best regards, Martin

13 years, 3 months

2
3
0 0

[xwiki-devs] Jetty tool maven reorganization

by Vincent Massol

Hi devs, Just some heads up to let you know I'm planning to reorganize the Jetty tool modules today as follows: xwiki-patform-tool-jetty/ |_ xwiki-patform-tool-jetty-listener/ --> JAR |_ xwiki-patform-tool-jetty-configuration/ --> JAR using Remote Resource Bundle plugin |_ xwiki-patform-tool-jetty-resources/ --> ZIP that includes the other 2 modules The goal of introducing xwiki-patform-tool-jetty-configuration is to be able to use the Maven Remote resource plugin to substitute the xwiki data dir value. Thanks -Vincent

13 years, 3 months

1
3
0 0

[xwiki-devs] [Proposal] XWiki's Permanent Directory Strategy for Installations

by Vincent Massol

Hi devs, Since I'm working on making XE work in Windows7 I've thought more about XWiki's install and configuration. Actually this is not a new topic, I remember starting a discussion about it a few years ago on the devs list but we didn't act on it so here it comes again ;) Rationale ======== The idea is to separate XWiki's binaries from its data. There are several reasons for wanting this: * Some OSes require this and don't allow writing in the binary directory. Windows 7 for example won't allow writing data in \Program Files. * It makes upgrading simpler since you don't need to fish for configuration data and copy them somewhere before unpacking a new distribution over. Or if you unpack in a new directory you don't need to copy the data from the old directory to the new one. * As a consequence of the previous point It allows easier auto upgrades of XE * It makes it simpler to know what to backup: all you need to back is the data directory. Proposal ======= This is the simplest I've found (I've imagine a lot of more complex options which offer other small possibilities but in the end I went for the simpler one for now). So here goes the process when starting up XE: * XE looks for a XWIKI_DATA environment variable and if found it uses it as its environment.permanentDirectory value * If not found, XE looks in the user home directory for an XWiki directory. Now the name of this directory is environment-dependent. On non windows systems it looks for ".xwiki" directory and on Windows systems it looks for a "XWiki" directory. * If not found, then XE stops and prints a message in the console explaining that it couldn't find the location of the XWiki Data dir with explanations on how to set it. The recommendation is thus that users set the XWIKI_DATA environment property. Notes: * At startup XE prints as an INFO log the location of the permanent dir it is using. * For the standalone distribution we would set the XWIKI_DATA env variable in the xwiki start file (start_xwiki.sh and start_xwiki.bat) to point to the data/ dir in the distribution. * One aspect that is not covered here yet (the topic for another email): the installer. I'll prepare another mail for that since it's independent for me. Use cases ========= This allows the following use cases: * Make it easy to upgrade XE * Make it easy to backup XE * MAke it easy to use an existing XE install but point it to a different configuration, for testing purposes for ex * Allow installing XE for all users on a system * Allow installing XE for my user only WDYT? Thanks -Vincent

13 years, 3 months

6
13
0 0

[xwiki-devs] append html node to wysiwyg

by liujinlong5788

Hello , I have sent a similar email yesterday which said I can't append html button to wysiwyg in js. Just now I have tried in plugin with gwt. It doesn't work eithor. For example I define a string varirable String button= "<input type='button' value='xx' />" and use execute(button) ,and it will add a button to wysiwyg editor ,but it does nothing to the source ,so ,the things I have done can't be saved.Of course ,execute(rta.getDocument().createButtonInputElement()) doesn't work eithor. I see the RichTextArea which is implemented by xwiki and extended from the RichTextArea of the gwt has a method setHtml() .And it doesn't work just like execute(). At first ,I think this should be a very easy thing .but I have been defeat by it - -! Pleanse ,help me . Thank you .

13 years, 3 months

2
1
0 0

[xwiki-devs] Two problems about wysiwyg

by liujinlong5788

Hello , I an sorry it's also simple problems about wysiwyg. The first one .can I use component in wysiwyg plugin. (The component is to get and save data in database which is not the table created by XWIKI, and not mapped by hibernate )I hava used it ,but it can't run .So , I wander it is the problem in my code or XWIKI doesn't support it (I thinke there is something wront with the grammer .I don't know how to say it correctly ,but I think you can understand it). The second one is when I use js to operate the wysiwyg, I use editor.getRichTextArea().contentWindow.document.body to get the document ,but all the operate to the html do nothing to the source , and {{html}} tag which I think will work also take no effect. So ,If I append html child to the document ,The change can't be saved .Is there method to make it or the method to operate the source .I don't think getSourceText can achieve it .. Thank you!

13 years, 3 months

2
1
0 0

[xwiki-devs] [Proposal] Add and Copy CLIRR explanations to release notes when releasing

by Vincent Massol

Hi devs, I'd like to propose that we: 1) always add explanations in our pom.xml files when we add CLIRR excludes (since we should have any based on our deprecation/legacy rule) 2) copy them in our release notes. As an example I've just done that for http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris… The advantage: * Users get an explanation as to why we have broken some APIs * We need the explanation in our pom.xml for ourselves to understand why we're excluding some files and since we have that explanation we might as well copy it to the release notes… WDYT? Thanks -Vincent

13 years, 3 months

4
3
0 0

[xwiki-devs] [Proposal] XWiki Configuration and Data directories

by Vincent Massol

Hi devs, This proposal is a restart of the thread I've sent, entitled "[Proposal] XWiki's Permanent Directory Strategy for Installations" in which I wasn't clear. Executive Summary ================ Define 2 XWiki directories; one for holding configuration data and one for holding (permanent) data and allow various configurations for our distributions. * Config dir is where xwiki configuration files is located. Examples: xwiki.cfg, xwiki.properties, hibernate.cfg.xml * Data dir is where xwiki writes permanent data. Examples: database/, extension/ lucene/, jetty log files Rationale ======== This proposal below tries to answer the following general use cases: * Ability to easily backup an XWiki install * Ability to easily upgrade an XWiki install * Ability to install XWiki on various OSes, including OSes like Windows 7 which require a total separation of readonly binaries and generated data * Ability to have several instances of XWiki on the same machine Note that I'm sending this email since I'm currently working on making our installer work on Windows 7 and I need an agreement on this before I can continue since I'm currently blocked. Use Cases ========= The proposal below should allow the following use cases easily: UC1: use the standalone zip distribution UC2: upgrade a standalone zip distribution install UC3: Use the WAR production distribution UC4: Upgrade an existing WAR distribution Short Term Proposal ================= * Add 2 system property variables: xwiki.config.dir and xwiki.data.dir * Use the following algorithm for resolving the Config dir (in Environment Module): ** Check if system property xwiki.config.dir is set, if so, use it ** Otherwise default to the WEB-INF directory (same as now) * Use the following algorithm for resolving the Data dir (in Environment Module): ** Check if system property xwiki.data.dir is set, if so, use it ** Otherwise use value of environment.permanentDirectory in xwiki.properties (same as now) ** If no environment.permanentDirectory exists, then use the temporary directory (same as now) * Don't provide a default value for environment.permanentDirectory in xwiki.properties * Note that we probably need to modify a bit Environment module to add support for a Configuration directory (not sure yet about this need). Use Cases Walkthrough =================== UC1: * user unzips, that's all * in start/stop xwiki scripts we use xwiki.config.dir = [homedir]/config and xwiki.data.dir=[homedir]/data * environment.permanentDirectory is not defined in xwiki.properties UC2: * user unzips new version in another directory and copy the old data and config directories over * Note that this use case is not really a valid one since the standalone zip is not meant to be a production zip at the moment UC3: * user deploys war in container's webapps dir and edits WEB-INF/xwiki.properties to set environment.permanentDirectory (same as now) * however the recommendation is for the user to put it's XWiki config dir and data dir somewhere on his system and use the xwiki.config.dir and xwiki.data.dir system properties in his startup/stop scripts, thus making it easy for UC4 UC4: * users replaces the older WAR with the new WAR and if he has applied the recommendation from UC3 that's all he has to do. Otherwise he needs to edit the xwiki.properties file to set environment.permanentDirectory WDYT? Thanks -Vincent

13 years, 3 months

5
9
0 0

[xwiki-devs] context.language having wild values?

by Paul Libbrecht

Hello developers, We had some (rare) users that had a very bad issue because we told their browser to load the lang_xx.js of their language. And their language was... wild! See: http://jira.xwiki.org/browse/CURRIKI-5694 for a sample of the things that got submitted to us. Sure, we'll now protect against these bizarre languages, still, there might be other things broken. Is there some guarantee on the set of possible languages provided by $context.language? I was expect the possible values of ISO-623-1 but that was clearly not sufficient! paul

13 years, 3 months

3
4
0 0

[xwiki-devs] [VOTE] Remove the notion of sending messages from the activity macro

by Eduard Moraru

Hi devs, We have recently extracted the functionality of sending messages from the activity macro into a new messageSender macro [1][2]. However, for backwards compatibility reasons, the activity macro still uses by default (unless the parameter messageSender='false' is specified) the messageSender macro so the users still see the ability to send messages as a feature of the activity macro. The proposal is that, for 4.1, we follow the original jira [2] issue idea (as seen in the issue's images) and: - Completely remove the messageSender macro call from activity macro (including the recently introduced messageSender=true/false parameter) - Providing instead a "Send Message" gadget for the main Dashboard that will use the new messageSender macro This way we have 2 clear macros, no more mixing: - messageSender for sending messages - activity for displaying messages (and other events) Additionally, it makes it easier for users to remove the ability to send messages from the homepage by editing the Dahsboard and removing the "Send Message" gadget. Here's my +1. Thanks, Eduard ---------- [1] http://xwiki.markmail.org/thread/mxpkpqfplbznfgbd [2] http://jira.xwiki.org/browse/XWIKI-7679

13 years, 3 months

7
7
0 0

[xwiki-devs] deadly bug on MoveItM: temporary fix

by Paul Libbrecht

Hello Smalalers, Thanks to Marc, we just realized that MoveItM broke since quite a while, since shortly after 1.1. I rolled back to the version 1.1 on prod so that http://sail-m.de/smala/act/de.ph-ludwigsburg.MZimmermann-Modul1.2.MoveItM_S… kind of works whereas: http://dev.sail-m.de/smala/act/de.ph-ludwigsburg.MZimmermann-Modul1.2.MoveI… shows the bug. I've opened: http://youtrack.i2geo.net/youtrack/issue/LABB-16 do you know of anyone else intending to use MoveItM? It is not very clear if the logging will work on the URL that works... paul

13 years, 3 months

1
1
0 0

[xwiki-devs] Expand our support strategy to include a longer support period for the end of each cycle

by Sergiu Dumitriu

Hi devs, Given that each development cycle usually starts with bigger changes and ends with a couple of stabilization releases, IMHO it makes sense to keep the last branch of a cycle maintained for a while longer. Our current strategy is to only support two branches at a time, the one being developed, and the one before it. This means that as soon as [N].0 is released, [N-1].5.x is dropped. However, the [N-1].5.x branch is much more stable and polished than the fresh new start of the cycle, so more people would be interested in using that stable version, especially in enterprise situations. Thus, I propose to amend our support rule to keep the end-of-cycle branch active for, let's say, 6 months. Still, this means only that we backport major or critical issues, which would improve the stability of that branch, without any new features. -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years, 3 months

8
12
0 0

[xwiki-devs] [ANN] XWiki Enterprise 4.1 Milestone 2 Released

by Caleb James DeLisle

The XWiki Development Team is pleased to announce the release of XWiki Enterprise 4.1 Milestone 2. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This is the second and final milestone of the XWiki Enterprise 4.1 development cycle. Changes from Milestone 1: * Extension Manager now handles updates to configuration documents. * New localization through timezone settings. * Customization of chart colors. For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris… Thanks, The XWiki Development Team

13 years, 3 months

1
0
0 0

[xwiki-devs] [VOTE] Merge the new diff API/service

by Thomas Mortagne

Hi devs, As I said in another mail I'm working on a diff/merge module to use in XWiki, the first target being Extension Manager and document history (since both are going to use the same code, see Marius mails). You can see the detail on https://github.com/xwiki/xwiki-commons/pull/2. TODO/QUESTIONS: * improve the generic 3 ways merge to be at least as good as the List<String> 3 ways merge and get rid of JDiff * not sure where/if I should put String related helpers (things that do a diff on two String instead of having to cut List<String> or List<Character> and call the diff API etc.) I'm ready to merge it into master so I'm waiting your vote. Caleb is it OK to put new stuff in master already or should I wait the complete release to be done ? Here is my +1. Thanks, -- Thomas Mortagne

13 years, 3 months

5
19
0 0

[xwiki-devs] [Proposal] Add notion of "Restricted" Configuration Source to XWiki Commons

by Vincent Massol

Hi devs, We have the need of a Configuration Source component hint for implementation that only looks in non-modifiable sources (e.g. xwiki.properties). More specifically there's a security issue in some cases in allowing to use the current "default" configuration source which looks in space preferences, wiki preferences and the only in xwiki.properties. For example the Environment's permanent directory should not be modifiable from wiki pages (see http://jira.xwiki.org/browse/XCOMMONS-182). So here's the proposal: * Introduce a new RestrictedConfigurationSourceProvider implementation (in configuration-api) that does the same as the current ConfigurationSourceProvider but when looking up the CS, it looks for a CS with hint "restricted" * Deprecate the current XWikiPropertiesConfigurationSource (hint = "default") * Add a new XWikiPropertiesConfigurationSource with hint = "restricted" * Modify DefaultEnvironmentConfiguration to use: @Inject @Named("restricted") private Provider<ConfigurationSource> configurationSourceProvider; WDYT? Thanks -Vincent

13 years, 3 months

4
7
0 0

[xwiki-devs] [ANN] Releasing tomorrow, please reply if the release must be delayed.

by Caleb James DeLisle

Hi, I would like to release M2 early tomorrow, if any developer needs to hold the release to make a change, or has any questions, please reply to this mail before the end of today. Thanks, Caleb

13 years, 3 months

1
0
0 0

[xwiki-devs] Newer versions of attachments are not indexed by Lucene

by marczi＠dev-labs.com

Hi, I know this is not a support list, but we found a bug that we consider serious related to searching: http://jira.xwiki.org/browse/XWIKI-7753 Since search is an often used function, we believe others have faced this so I'd like to ask the most experienced ones if this bug is a real bug, or we just misconfigured XWiki. Thanks in advance, Daniel Marczisovszky

13 years, 3 months

1
0
0 0

[xwiki-devs] Best way to add buttons on wysiwyg toolbar

by Geo Du

Hi, all, I am trying to add buttons on the wysiwyg or inline form editor toolbar, I checked the wysiwyg gwt source code, and the wysiwyg.js file, I am more toward add javascript code in wysiwyg.js file to add javascript code for buttons on the toolbar, instead of adding java code for the plugin, any suggestions? Thanks in advance Dave

13 years, 3 months

2
4
0 0

[xwiki-devs] the wysiwyg js api to use in client

by liujinlong5788

Hello ,I wander if there is the js api document about the wysiwyg which I can use in client .I need to add a very very simple function to the wysiwyg in client. but I only find some api I can use here!(I use xwiki 3.5) http://extensions.xwiki.org/xwiki/bin/view/Extension/WYSIWYG+Editor+Module#… Is there api in detail ?.In fact ,The most important thing is to add some HTML elements (just as div or button)to the xwiki document .It is very easy no matter in javascript or gwt(It is unable to use here because of some problems, so I have to implement it in client with js). But I don't know how to operate the xwiki document w't ith js,I even can't get it ,so .. A poor student with poor English and programming knowledge who have to develop the system by himself need your help .Thanks ! Why can't we offer the download of apis ? of it's just I havn't fount theml

13 years, 3 months

1
0
0 0

Re: [xwiki-devs] [GSoC] Responsive Skin

by Jonathan Solichin

Hello friends, Thank you, glad to hear that I am getting somewhere Here is a better version of the sidebar: http://jssolichin.com/public/4/4.%20Home-alt.png The boxes with the x will be icons. having those I think will help inform the reader what is available, instead of the previous metro like overflow. It will also allow a space for numbers showing how much content is available in that section. When you hover over that section, it will still reveal the hover nav in the last mock up to allow for easier clicking and clarity (as to what the icons are): http://jssolichin.com/public/4/3.%20Home-navhover.png I know that the icons will not fit with longer section names like comments, so the icon might be placed above the section name, or be smaller. On that point, I would just like to mention that i'm hoping to also allow the reader to resize the sidebar size fluidly. So if they are reading the comments section, they can devote more space to it. This will, however, be disabled in the mobile version. * The way the navigation links are organized/grouped together is a bit > weird (the upper part with wiki/space/page links) > Visually, I'm not sure if it came through in the wireframe, but i'm imagining it like the iphone folder [1], where we have the breadcrumb/nav (wiki/space/pages) always visible, then when the user clicks it, it reveals the "watch page, access rights, etc." By iphone folder like i mean, it pushes everything down and visually seems to reveal something underneath. But that last point is trivial. More technically, since the navigation is vertical, the breadcrumb style is a bit unclear, and do need to be more refined. Right now i'm thinking maybe a folder esque structure: x wiki \_ x space \_x pages but I feel like that might get to cluttered. Maybe we should just remove the breadcrumb navigation and just have it like in the lyrebird where it appears as part of the content and not as a "global nav?" What does the community think? * On the desktop you probably don't want that inner scroller, but > rather have the right panel fixed and keep the page's natural scroll. You're right, that would make sense. I think the right solution would be to make the right sidebar scroll like the chatlist window on facebook where if you hover over the area, it will reveal a scroll bar indicator to show your vertical location and allow you to scroll that section using the mouse wheel. Do you guys think it will be ok that we do not have the up and down arrow? or would that be bad usability. I personally think it will be fine since even sites like gmail uses a non native scroll indicator without the up and down arrow--it's just prettier. The menu part still needs to be refined Did I address it earlier in this email, or am I still missing something? Can you clarify specifically which point for me to work at? > Putting the menu on the left would be more familiar to mobile users (the > > nav menu is usually on the right in all the mobile apps I regularly > use). > Maybe we don't want to be like every other app ;p > I don't know, I think we can try it out on the right and see how it > feels. Same for the desktop in fact ; though I think it's going to > feel more natural on the right in that case. I think both points are valid. I personally chose the right side because I feel like when you land on a page, you want to read content first. But I do know what you mean, left is the traditional side and is used in giant sites like gmail, facebook, hotmail and so forth. I think we should get more input on this. > Jonathan: I don't remember whether Jérôme pointed you to his lyrebird > work: > > > http://www.velociter.fr/journal/lyrebird-a-xwiki-skin-based-on-bootstrap-cs… > > it could be an additional source of inspiration for you. > I don't remember I did. > Let me fix the link : > > http://www.velociter.fr/journal/lyrebird-a-xwiki-skin-based-on-bootstrap-css > Also, sources are on github : https://github.com/jvelo/Lyrebird<https://github.com/jvelo/Lyrebird;cid=1338111304826-974> Thank you, this will be a wonderful resource! Let me know what you guys think. Best, Jonathan Solichin [1] http://media.tecca.com/2011/02/17/mh-630-iphone-folder-header-630w.jpg

13 years, 3 months

2
1
0 0

[xwiki-devs] [GSOC] Solr Search component

by savitha sundaramurthy

Hi, I want to create a repository in XWiki contrib for Solr search implementation. So, I kindly request you to grant access. -- Thanks, Savitha.s

13 years, 3 months

2
2
0 0

[xwiki-devs] [Proposal] Naming convention for new wiki macros

by Eduard Moraru

Hi devs, For the new messageSender macro [1][2], I chose the name using the "attachmentSelector" macro as a template: "<object><personified-action>" Vincent did not really like the "messageSender" name and proposed "message", "sendMessage" or "userMessage". Since AFAIK we don`t currently have a naming convention for wiki macro names, I`d like to propose that we stick to the patterns: 1) "<object><personified-action>" (attachmentSelector, messageSender) for action-oriented macros and 2) "<object(s)>" (documents, spaces, activity) for display-oriented macros For 2), it's pretty clear, but for 1), I personally prefer "<object><personified-action>" since overall it is a noun and, in english, the phrase "messageSender macro" sounds better to me than "sendMessage macro". Also, I think that the main action of the action-oriented macro should be reflected in its name. I`d like your opinion on the matter and also new proposals if you have any. Here's my +1 for 1) and 2). Thanks, Eduard ---------- [1] http://xwiki.markmail.org/thread/mxpkpqfplbznfgbd [2] http://jira.xwiki.org/browse/XWIKI-7679

13 years, 3 months

5
4
0 0

[xwiki-devs] [Contrib] Xinit

by Alexandru Stancu

Hello guys, As some of you already know, we are using Xinit to manage tomcat and implicitly xwiki. Today is the day when we want to publish it. Xinit is a tool written in bash, at this moment is only compatible with Debian systems and some of its functionalities are: 1. stop / start / restart tomcat 2. send reports by email 3. check xwiki availability 4. check tomcat process 5. send mail and jabber notifications 6. check Open Office daemon availability 7. offer informations that can be used in Nagios. So for this project I would like an repository on github and a page on extensions.xwiki.org Name of the project: Xinit github username: astancu Thx, Alex

13 years, 3 months

2
1
0 0

[xwiki-devs] [UX][Proposal] Help Center

by Ecaterina Moraru (Valica)

Hi, This proposal comes as part of the investigation on improving the content of the Homepage. Instead of keeping all the roles (presentational, navigational, informational and learning experience) in the same page, I've opted to separate the 'Learning Experience / Documentation / Help' in a separate space/application. http://incubator.myxwiki.org/xwiki/bin/view/Improvements/HelpCenter This proposal is done on a new skin proposal (which is partially represented and not finished, missing: contextual menu, comments zone, header, etc.) that could be our new skin structure for the 4.x. The layout is done using Bootstrap. What this proposal fixes: - better separation of the application and their purposes - creates a single entry point for 'Getting Started', 'Documentation', 'FAQ', 'Quick Tour' sections - separates the applications and the information an User or an Admin sees - better explains what are steps he can do as a new comer - better explains what are the applications a user can utilize in his wiki - highlights AppWithinMinutes and ExtensionManager functionality Thanks, Caty

13 years, 3 months

3
4
0 0

[xwiki-devs] WYSIWYG Editor - WAR Distribution blocking release of milestone 2.

by Caleb James DeLisle

Hi, I'm going to have to delay the release because the WYSIWYG war distribution is breaking it. It builds ok but fails to release. I tried specifying <type>jar</type> in the dependency plugin configuration to no avail. I'm going to have to get some help on this issue because I'm neither a maven expert not an expert on the WYSIWYG war distribution and I'm not sure what it's trying to achieve and how. Caleb Below is the release failure: I noticed a few builds had failed with this exception but thought it was a case of local repository in a bad state. [INFO] XWiki Platform - Workspace - Parent POM ........... SUCCESS [0.022s] [INFO] XWiki Platform - Workspace - API .................. SUCCESS [0.537s] [INFO] XWiki Platform - Workspace - Template Features .... SUCCESS [0.081s] [INFO] XWiki Platform - Workspace - UI ................... SUCCESS [4.767s] [INFO] XWiki Platform - WYSIWYG Editor - WAR Distribution FAILURE [0.025s] [INFO] XWiki Platform - XML - Parent POM ................. SKIPPED [INFO] XWiki Platform - XML - Script Service ............. SKIPPED [INFO] XWiki Platform - XMLRPC - Client .................. SKIPPED [INFO] XWiki Platform - ZIP Explorer ..................... SKIPPED [INFO] XWiki Platform - Legacy ........................... SKIPPED [INFO] XWiki Platform - Legacy - Old Core ................ SKIPPED [INFO] XWiki Platform - Legacy - Observation ............. SKIPPED [INFO] XWiki Platform - Legacy - Annotation .............. SKIPPED [INFO] XWiki Platform - Legacy - Model ................... SKIPPED [INFO] XWiki Platform - Legacy - Office Importer ......... SKIPPED [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 3:17.080s [INFO] Finished at: Mon May 28 20:50:28 CEST 2012 [INFO] Final Memory: 214M/655M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.4:copy (default) on project xwiki-platform-wysiwyg-war: Error copying artifact from /home/hudsonagent/releases/xwiki-trunks/xwiki-platform/xwiki-platform-core/xwiki-platform-wysiwyg/xwiki-platform-wysiwyg-client/target/classes to /home/hudsonagent/releases/xwiki-trunks/xwiki-platform/xwiki-platform-core/xwiki-platform-wysiwyg/xwiki-platform-wysiwyg-war/target/xwiki-platform-wysiwyg-war-4.1-milestone-2/WEB-INF/lib/xwiki-platform-wysiwyg-client-4.1-milestone-2-shared.jar: /home/hudsonagent/releases/xwiki-trunks/xwiki-platform/xwiki-platform-core/xwiki-platform-wysiwyg/xwiki-platform-wysiwyg-client/target/classes (Is a directory) -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn <goals> -rf :xwiki-platform-wysiwyg-war hudsonagent@ks365275:~/releases/xwiki-trunks$

13 years, 3 months

1
1
0 0

[xwiki-devs] [VOTE] Extract a reusable messageSender macro from the current activity macro

by Eduard Moraru

Hi devs, I`ve recently worked on extracting the textarea input from the activity stream macro into a separate and reusable {{messageSender}} macro that is able to do just that, send messages. By default, the activity macro will still display the messages text area (by including itself the messageSender macro), but it can also be disabled by passing the messageSender='false' parameter to the activity macro. The new messageSender can be used wherever you want to be able to send a message and do not want to carry the whole activity stream with you (with all it's performance and layout impact). Please check out the Jira issue [1] and the available pull requests [2][3] for additional details. I`d like your vote on whether or not we want to include this into platform. Here's my +1. If your vote is positive, should we add it for 4.1M2 (which is scheduled on Monday)? Note that I am also working on adding filtering support to the activity macro and am planning to build on top of this :) Thanks, Eduard ---------- [1] http://jira.xwiki.org/browse/XWIKI-7679 [2] https://github.com/xwiki/xwiki-enterprise/pull/22 [3] https://github.com/xwiki/xwiki-platform/pull/48

13 years, 3 months

4
4
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