Wiki source code of IRC Archive for channel #xwiki on 10 January 2012
Last modified by Vincent Massol on 2012/10/18 19:22
Show last authors
author | version | line-number | content |
---|---|---|---|
1 | 00:07 <jvdrean> has quit | ||
2 | 00:44 <DrLou_> has quit | ||
3 | 00:45 <rrodriguez> has quit | ||
4 | 00:45 <CIA-121> Sergiu Dumitriu master * r2bbf7a8 / xwiki-platform-core/xwiki-platform-extension/xwiki-platform-extension-ui/src/main/resources/XWiki/ExtensionManagerMacros.xml : XWIKI-7290: Extension manager UI use {{warn}} instead of {{warning}} ... | ||
5 | 02:16 <tekzilla> has quit | ||
6 | 02:18 <tekzilla> has joined #xwiki | ||
7 | 03:06 <CIA-121> Sergiu Dumitriu master * r7046ead / xwiki-platform-core/xwiki-platform-extension/xwiki-platform-extension-ui/src/main/resources/XWiki/ExtensionManagerMacros.xml : XWIKI-7258: Authors ending with ")" are displayed wrongly in the Extension Manager UI ... | ||
8 | 03:47 <CIA-121> Sergiu Dumitriu master * rb496ec1 / (5 files in 2 dirs): XWIKI-7289: Make Extension Manager UI localizable ... | ||
9 | 06:00 <Denis1> has joined #xwiki | ||
10 | 06:00 <Denis> has quit | ||
11 | 07:28 <mflorea> has joined #xwiki | ||
12 | 08:36 <tmortagne> has joined #xwiki | ||
13 | 08:52 <Denis1> is now known as <Denis> | ||
14 | 09:09 <lucaa> has joined #xwiki | ||
15 | 09:12 <jvdrean> has joined #xwiki | ||
16 | 09:15 <CIA-121> Sergiu Dumitriu master * r2780273 / xwiki-platform-core/xwiki-platform-extension/xwiki-platform-extension-ui/src/main/resources/XWiki/ExtensionManagerMacros.xml : XWIKI-7259: Long text overlaps action button in Extension Manager UI ... | ||
17 | 09:23 <evalica> has joined #xwiki | ||
18 | 09:28 <vmassol> tmortagne: hmm I don't see the jboss cache data | ||
19 | 09:28 <vmassol> in the jmx console | ||
20 | 09:29 <vmassol> maybe infinispan doesn't register the jmx mbeans by default | ||
21 | 09:32 <sburjan> has joined #xwiki | ||
22 | 09:32 <+tmortagne> vmassol: don't know, never checked it | ||
23 | 09:34 <Enygma`> has joined #xwiki | ||
24 | 09:35 <vmassol> found doc, reading: https://docs.jboss.org/author/display/ISPN/Management+Tooling | ||
25 | 09:36 <vmassol> tmortagne: do we have an xml file for the infinispan config? | ||
26 | 09:36 <vmassol> (how do we configure the CacheManager) | ||
27 | 09:36 <Enygma`> has quit | ||
28 | 09:37 <Enygma`> has joined #xwiki | ||
29 | 09:39 <vmassol> ok I think you're doing it programmatically in InfinispanCacheFactory | ||
30 | 09:40 <+tmortagne> vmassol: yes we have a conf file | ||
31 | 09:41 <vmassol> /WEB-INF/cache/infinispan/config.xml | ||
32 | 09:41 <vmassol> ? | ||
33 | 09:41 <vmassol> ah yes we fallback to programmatic only if it doesn't exist, cool | ||
34 | 09:41 <jvdrean> has quit | ||
35 | 09:41 <+tmortagne> yes | ||
36 | 09:42 <+tmortagne> not exactly | ||
37 | 09:42 <@sdumitriu> tmortagne: Any ETA on the ability to get all extensions from the searchable repositories, for XWIKI-7246 ? | ||
38 | 09:43 <vmassol> cool the file already exists | ||
39 | 09:43 <vmassol> and it has the jmx config | ||
40 | 09:43 <vmassol> we just need to uncomment it | ||
41 | 09:43 <vmassol> trying it | ||
42 | 09:45 <+tmortagne> sdumitriu: you already can get all extensions, just put a empty pattern | ||
43 | 09:46 <vmassol> hmm doesnet work | ||
44 | 09:46 <@sdumitriu> tmortagne: OK, will try | ||
45 | 10:03 <vmassol> tmortagne: ok found the problem | ||
46 | 10:03 <vmassol> container is null when InfinispanCacheFactory is initialized | ||
47 | 10:04 <vmassol> ahah funny | ||
48 | 10:04 <vmassol> you set it after you get the config file | ||
49 | 10:04 <vmassol> but in the code to get the config file you check if container is null | ||
50 | 10:04 <vmassol> :) | ||
51 | 10:04 <vmassol> so right now the infinispan config file is not taken into account | ||
52 | 10:06 <gdelhumeau> has joined #xwiki | ||
53 | 10:08 <vmassol> fixing | ||
54 | 10:15 <+tmortagne> back | ||
55 | 10:16 <+tmortagne> ok | ||
56 | 10:18 <vmassol> tmortagne: does it mean that the named cahces defined in config.xml were not actually defined? | ||
57 | 10:18 <vmassol> does it mean that there was no cache for image and equation? | ||
58 | 10:20 <+tmortagne> vmassol: probably yes | ||
59 | 10:20 <+tmortagne> well | ||
60 | 10:20 <+tmortagne> actually no | ||
61 | 10:20 <+tmortagne> because there is caches before theses | ||
62 | 10:21 <+tmortagne> hmm | ||
63 | 10:21 <+tmortagne> yes I think it was not taken into account | ||
64 | 10:22 <+tmortagne> vmassol: did you started modifying stuff or can I take care of it ? | ||
65 | 10:22 <vmassol> I started | ||
66 | 10:22 <vmassol> I'm wrting the unit test | ||
67 | 10:22 <vmassol> almost ther | ||
68 | 10:22 <vmassol> e | ||
69 | 10:23 <+tmortagne> ok, basically it's just about moving this.container lookup at the top of init ? | ||
70 | 10:23 <vmassol> yes | ||
71 | 10:24 <vmassol> I'd like to add a comment as to why we want to make this code work even when there's no container? | ||
72 | 10:24 <vmassol> can you explain? | ||
73 | 10:29 <+tmortagne> vmassol: well because it's not really critical to have a confuration to have a working cache | ||
74 | 10:29 <+tmortagne> configuration | ||
75 | 10:30 <+tmortagne> and sometime you don't want to setup a container but still need a cache | ||
76 | 10:30 <+tmortagne> was thinking of when we will move the cache to commons | ||
77 | 10:30 <vmassol> ok unit test working | ||
78 | 10:32 <vmassol> btw you could use a Provider for the container now ;) | ||
79 | 10:32 <jvdrean> has joined #xwiki | ||
80 | 10:48 <vmassol> tmortagne: pushed, can you verify it's ok before I merge it in 3.3.x and 3.2.x? | ||
81 | 10:48 <vmassol> err infinispan is only in 3.3.x? or was it in 3.2.x too? | ||
82 | 10:49 <CIA-121> Vincent Massol master * r2e30d4a / (2 files in 2 dirs): XWIKI-7365: Infinispan configuration is not taken into account - http://git.io/tQST1A | ||
83 | 10:49 <+tmortagne> not sure, checking | ||
84 | 10:49 <+tmortagne> I think it's 3.3 | ||
85 | 10:50 <+tmortagne> vmassol: 3.3 | ||
86 | 10:50 <vmassol> k | ||
87 | 10:50 <vmassol> give me your greenlight and I'll merge | ||
88 | 10:51 <+tmortagne> vmassol: seems ok to me | ||
89 | 10:52 <CIA-121> Vincent Massol stable-3.3.x * r24f46b7 / (2 files in 2 dirs): XWIKI-7365: Infinispan configuration is not taken into account - http://git.io/m1rgGA | ||
90 | 11:11 <vmassol> hmm I don't see how to get the cache content in the JMX console | ||
91 | 11:19 <evalica> has quit | ||
92 | 11:25 <+mflorea> guys, did we change something on the xwql implementation recently, after the 3.3 release? I have queries that worked on 3.3 and don't work anymore on 3.4-SNAPSHOT, this is really bad.. again, someone is making changes without checking the CI for failing tests.. | ||
93 | 11:25 <vmassol> I think jerome chaged something | ||
94 | 11:25 <@sdumitriu> Yes, there's a "distinct" now in the query | ||
95 | 11:26 <+mflorea> I haven't written the app within minutes tests for nothing.. http://ci.xwiki.org/job/xwiki-enterprise-test-ui/org.xwiki.enterprise$xwiki-enterprise-test-ui/852/testReport/ | ||
96 | 11:26 <+mflorea> are failing for 43 builds.. | ||
97 | 11:27 <vmassol> yep I've been amazed at how little we cared about failing builds | ||
98 | 11:27 <vmassol> I pinged aobut this but nobody cared | ||
99 | 11:28 <vmassol> (didn't have time to debug it myself) | ||
100 | 11:28 <+mflorea> I'm going to revert jerome's change | ||
101 | 11:32 <@sdumitriu> vmassol: I cared a little... | ||
102 | 11:43 <sdumitriu> has quit | ||
103 | 11:48 <CIA-121> cjdelisle feature-store-attachments-newstore * r0903ac7 / (7 files in 6 dirs): Got newstore filesysten attachments working. - http://git.io/hwx-5w | ||
104 | 11:55 <CIA-121> Marius Dumitru Florea master * r0e59b3c / (2 files in 2 dirs): Revert "XWIKI-7273 XWQL short form queries should distinct on document fullname." because it breaks existing queries. ... | ||
105 | 11:57 <evalica> has joined #xwiki | ||
106 | 11:58 <CIA-121> cjdelisle master * re479bf9 / xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/XWikiException.java : XWIKI-6757: XWikiException stack traces do not show wrapped exception. ... | ||
107 | 12:04 <sburjan> has quit | ||
108 | 13:03 <mflorea> has quit | ||
109 | 13:20 <sburjan> has joined #xwiki | ||
110 | 13:27 <sburjan> has quit | ||
111 | 13:40 <sburjan> has joined #xwiki | ||
112 | 13:47 <sburjan> has quit | ||
113 | 13:51 <sburjan> has joined #xwiki | ||
114 | 13:59 <CIA-121> Marius Dumitru Florea master * r5a1d39e / xwiki-enterprise-test/xwiki-enterprise-test-selenium/src/test/it/org/xwiki/test/selenium/VelocityMacrosTest.java : XWIKI-7355: Use PNG silk icons instead of GIF ... | ||
115 | 14:00 <mflorea> has joined #xwiki | ||
116 | 14:01 <+mflorea> tmortagne: do you have any idea why wysiwyg selenium tests are not triggered anymore? I committed yesterday both in platform and in xwiki-enterprise-test-wysiwyg and the job hasn't been triggered. I've looked at the job configuration but I can't see anything special compared to other enterprise test modules. | ||
117 | 14:01 <+mflorea> in the "Build Triggers" configuration section I see that it is set to run after xwiki-enterprise-test-selenium, and the "Build when a change is pushed to GitHub" is not checked (probably because this is checked for enterprise which then triggers the test modules) | ||
118 | 14:06 <sburjan> has quit | ||
119 | 14:28 <+tmortagne> mflorea: looking | ||
120 | 14:30 <+tmortagne> mflorea: configuration seems ok, here is the triggering chain: xwiki-enterprise -> xwiki-enterprise-test-pom -> xwiki-enterprise-test-selenium -> xwiki-enterprise-test-wysiwyg | ||
121 | 14:30 <+tmortagne> so building xwiki-enterprise should eventually build wysiwyg tests | ||
122 | 14:31 <+tmortagne> I can see the conf work for xwiki-enterprise-test-pom | ||
123 | 14:31 <+tmortagne> it's ok for xwiki-enterprise-test-selenium too | ||
124 | 14:31 <+mflorea> could be that test-selenium was failing? it wasn't the case before, i.e. wysiwyg tests were run even if there were selenium test failyres | ||
125 | 14:31 <+tmortagne> mflorea: see http://ci.xwiki.org/job/xwiki-enterprise-test-wysiwyg/718/ | ||
126 | 14:31 <+tmortagne> "Started by upstream project xwiki-enterprise-test-selenium build number 902" | ||
127 | 14:31 <+tmortagne> so it seems to work | ||
128 | 14:32 <+mflorea> now, because I just fixed selenium tests | ||
129 | 14:32 <+mflorea> i.e. xwiki-enterprise-test-selenium | ||
130 | 14:32 <+tmortagne> ha yes trigering is always broken if something fail | ||
131 | 14:32 <+mflorea> but this isn't right | ||
132 | 14:32 <+mflorea> ah | ||
133 | 14:32 <+tmortagne> I just looked at latest builds | ||
134 | 14:32 <+mflorea> I wasn't aware of this | ||
135 | 14:33 <+tmortagne> maybe it's configurable | ||
136 | 14:33 <+tmortagne> ye it is | ||
137 | 14:33 <+tmortagne> "Trigger only if build succeeds" | ||
138 | 14:34 <+tmortagne> changing it for xwiki-enterprise-test-selenium | ||
139 | 14:34 <+tmortagne> since we don't need the test to pass for the WYSIWYG | ||
140 | 14:34 <+tmortagne> but it manily mainly mean that the thing the WYSIWYG need shouldn't be in this project | ||
141 | 14:34 <+tmortagne> like UI test framework is actually in another project | ||
142 | 14:35 <+tmortagne> changed for "Trigger even if the build is unstable" | ||
143 | 14:35 <+tmortagne> I should maybe do the same for platform, not sure | ||
144 | 14:36 <+mflorea> yep | ||
145 | 14:36 <+mflorea> the common API should be in a separate module | ||
146 | 14:36 <+mflorea> but since we have to move the tests to selenium 2 it not worth to make this change now | ||
147 | 14:37 <vmassol> tmortagne: just noticed that my linkchecker is not multiwiki-aware…. I'm not sure how to fix this though since the linkchecker manager is in rendering which doesn't know about the notion of wiki... | ||
148 | 14:37 <+mflorea> i.e. to refactor selenium tests | ||
149 | 14:37 <+tmortagne> mflorea: I agree | ||
150 | 14:37 <vmassol> right now it opens a privacy issue since anyone can see the link status for any subwiki | ||
151 | 14:38 <+tmortagne> vmassol: what is not multiwiki in linkchecker exactly ? | ||
152 | 14:38 <+mflorea> tmortagne: I remember a recent commit about case insensitive search but I can't find it. do you know it? otherwise I'll keep searching | ||
153 | 14:38 <vmassol> tmortagne: http://commons.xwiki.org/xwiki/bin/view/Main/AllDocs?view=externalLinks | ||
154 | 14:38 <vmassol> even though this is in the commons wiki you can see all links for all wikis | ||
155 | 14:40 <+tmortagne> that page could be aware of multiwiki concept, where is the API which require multiwiki information exactly ? | ||
156 | 14:40 <+tmortagne> mflorea: no idea, was it a commit I did ? | ||
157 | 14:40 <+tmortagne> does not remember anything like this | ||
158 | 14:40 <+mflorea> I don't remember, nevermind, I'll keep searching | ||
159 | 14:41 <vmassol> tmortagne: that has 2 issues. 1) we still have the script service in rendering which can be accessed and 2) it's costly to parse all references to filter them | ||
160 | 14:41 <+tmortagne> mflorea: search is supposed to be case sensitive from what I know unless you did not properly configured MySQL database | ||
161 | 14:41 <vmassol> one solution I can think of would be to have a system to inject the structure | ||
162 | 14:41 <vmassol> ideally we'd need the resources module | ||
163 | 14:42 <vmassol> (i think) | ||
164 | 14:42 <+tmortagne> vmassol: I don't say the solution is to filter in that page I'm asking where the multiwiki concept is really required | ||
165 | 14:42 <vmassol> tmortagne: IMO each wiki should only list the links for itself and the main wiki should list all links | ||
166 | 14:43 <+tmortagne> you mean duplicate them ? | ||
167 | 14:43 <vmassol> I don't understand | ||
168 | 14:43 <+tmortagne> I tough you were talking about link storage | ||
169 | 14:43 <vmassol> if the same link is broken in several places yes | ||
170 | 14:44 <+tmortagne> vmassol: you could do what I do in extension manager | ||
171 | 14:44 <+tmortagne> there is nowhere the notion of wiki in extension manager, I use a generic "namespace" | ||
172 | 14:44 <vmassol> indeed | ||
173 | 14:45 <vmassol> the only problem that remains is the parsing of the links found but we could use a generic resolver and have platform bring another one | ||
174 | 14:45 <vmassol> (to extract the namespace) | ||
175 | 14:46 <+tmortagne> hmm | ||
176 | 14:47 <vmassol> another soltuion is to introduce a Reference with a type | ||
177 | 14:47 <vmassol> and then have a PageReference in platform | ||
178 | 14:47 <vmassol> and the livetable page would check the type and cast to PageReference | ||
179 | 14:47 <vmassol> and in PageReference you'd have a getWiki() | ||
180 | 14:47 <vmassol> i think this is our ResourceReference idea | ||
181 | 14:48 <+tmortagne> not exactly | ||
182 | 14:48 <+tmortagne> in ResourceReference you have information about the target | ||
183 | 14:48 <+tmortagne> you want information about the source where the link is | ||
184 | 14:49 <+tmortagne> i.e. you want to know where the broken link is | ||
185 | 14:49 <vmassol> source where the link is is itself a ResourceRefrence | ||
186 | 14:49 <+tmortagne> not yet | ||
187 | 14:50 <+tmortagne> it's just a string identifier in the XDOM currently I think | ||
188 | 14:54 <vmassol> yes in Rendering ResourceReference has a reference field and it's a string | ||
189 | 14:55 <vmassol> we would need to have EntityReference a subclass of a more primitive type | ||
190 | 14:55 <+tmortagne> or implementing thing in platform | ||
191 | 14:55 <+tmortagne> s/thing/this/ | ||
192 | 14:55 <vmassol> this = ? | ||
193 | 14:55 <vmassol> linkchecker, | ||
194 | 14:55 <vmassol> ? | ||
195 | 14:56 <+tmortagne> the catch of the links to check | ||
196 | 14:56 <+tmortagne> instead of rendering | ||
197 | 14:56 <+tmortagne> linckchecker store itself can stay in commons if it provide a concept of namespace | ||
198 | 14:56 <vmassol> well if we do this we might as well move the whole thing to platform | ||
199 | 14:56 <vmassol> if we add the concept of namespace then we're good | ||
200 | 14:57 <+tmortagne> for the storage but rendering alone cannot extract the namespace | ||
201 | 14:57 <vmassol> we just need to add an interface to extract the namespace from the string | ||
202 | 14:57 <vmassol> the impl would be in platform indeed | ||
203 | 14:57 <vmassol> with a default impl in rendering that does nothing | ||
204 | 14:57 <vmassol> (empty namespace) | ||
205 | 14:58 <vmassol> I was just thinking that this namespace need is more generic than just hte link checker | ||
206 | 14:58 <vmassol> and this could fit in the resource module we talked about | ||
207 | 14:58 <vmassol> provided we agree to add the concept of namespace in the resource module | ||
208 | 14:58 <vmassol> anyway it's a bit too early for such a module but the interest is growing | ||
209 | 14:59 <+tmortagne> it's more generic that lin kchcker for sure since it already exist in EM and multi CM as I told you | ||
210 | 14:59 <vmassol> yep | ||
211 | 14:59 <vmassol> do you have already interfaces for extracting namespaces somewhere? | ||
212 | 14:59 <vmassol> NamespaceResolver or something like that | ||
213 | 15:00 <+tmortagne> I never had the need to extract the namespace from a string | ||
214 | 15:00 <vmassol> ok | ||
215 | 15:00 <vmassol> well | ||
216 | 15:00 <vmassol> it could be implemented at the level of the rendering api | ||
217 | 15:00 <vmassol> in LinkBlock | ||
218 | 15:00 <vmassol> I mean LinkBlock could return an object having the namespace already extracted | ||
219 | 15:01 <vmassol> ie in ResourceReference | ||
220 | 15:01 <vmassol> not sure if it's useful or not | ||
221 | 15:01 <vmassol> since it would mean 2 parsing…. | ||
222 | 15:02 <vmassol> one for the namespace and another one when we fully resolve the link reference | ||
223 | 15:02 <vmassol> (when we render) | ||
224 | 15:02 <+tmortagne> not sure, I would prefer doing something for linkchecker for now I think | ||
225 | 15:02 <vmassol> yep | ||
226 | 15:02 <+tmortagne> too many stuff in the pipe to think carefuly about introducing something like that | ||
227 | 15:02 <vmassol> we need to think more about it in general | ||
228 | 15:03 <vmassol> yep | ||
229 | 15:08 <vmassol> hmm the script service will not be able to return only links for the currnet namespace anyway since there's no notion of current namespace there.... | ||
230 | 15:08 <vmassol> so the script service would need to move to platform for that | ||
231 | 15:09 <CIA-121> Marius Dumitru Florea master * ref69f8d / xwiki-platform-core/xwiki-platform-extension/xwiki-platform-extension-ui/src/main/resources/XWiki/AddExtensions.xml : Fix HTML markup. - http://git.io/JrcCTQ | ||
232 | 15:11 <vmassol> unless I invent a NamespaceValidator interface... | ||
233 | 15:12 <vmassol> (implemented in platform) | ||
234 | 15:12 <vmassol> NamespaceFilter rather than validator | ||
235 | 15:12 <vmassol> (the default impl would consider everything ok) | ||
236 | 15:12 <vmassol> all this is pretty complex.... | ||
237 | 15:13 <vmassol> the only alternative is to move it all to platform | ||
238 | 15:13 <vmassol> but then people using our rendering only cannot benefit from it… it's a choice.... | ||
239 | 15:14 <+tmortagne> moving all this to platform sounds the easiest for now, we can always move back later when all is ready, we have this more generic than that in platform | ||
240 | 15:14 <+tmortagne> s/this/things/ | ||
241 | 15:15 <vmassol> yeah I'm still hesitating | ||
242 | 15:15 <vmassol> (it also means removing something that we made available in 3.3) | ||
243 | 15:17 <vmassol> the good point is that the linkchecker is optional | ||
244 | 15:18 <vmassol> and not active by default | ||
245 | 15:18 <vmassol> so only the sysadmin can decide to activate it | ||
246 | 15:18 <vmassol> (almost) | ||
247 | 15:18 <vmassol> at least someone with PR | ||
248 | 15:18 <vmassol> I'll add a warning in the RN | ||
249 | 15:21 <vmassol> we could require farm admin rights to display the "external links" tab for now | ||
250 | 15:27 <vmassol> ok I'm not going to work on this now but I've created an issue http://jira.xwiki.org/jira/browse/XRENDERING-170 | ||
251 | 15:38 <vmassol1> has joined #xwiki | ||
252 | 15:39 <vmassol> has quit | ||
253 | 15:55 <CIA-121> Marius Dumitru Florea master * r2207718 / (2 files): Fix access mode. - http://git.io/UWpYRA | ||
254 | 16:03 <CIA-121> Marius Dumitru Florea master * rc550165 / xwiki-enterprise-test/xwiki-enterprise-test-rest/src/test/it/org/xwiki/test/rest/WikisResourceTest.java : XE-1069: Skin and ColorTheme improvements: new colors, gradients, shadows, etc. ... | ||
255 | 16:19 <CIA-121> tmortagne master * ra3cfaa4 / (4 files in 2 dirs): XWIKI-7348: Provide UI to import and syncronise an external extension in the repository - http://git.io/4ZFluw | ||
256 | 16:33 <DrLou> has joined #xwiki | ||
257 | 16:33 <vmassol1> I think we should be able to close http://jira.xwiki.org/jira/browse/XWIKI-605 wdyt? | ||
258 | 16:34 <vmassol1> actually I asked the question in http://jira.xwiki.org/browse/XWIKI-6685# | ||
259 | 16:35 <vmassol1> I'm closing it | ||
260 | 17:18 <evalica> has quit | ||
261 | 17:24 <Enygma`> has quit | ||
262 | 17:38 <lucaa> has quit | ||
263 | 17:46 <sdumitriu> has joined #xwiki | ||
264 | 17:49 <jnsl_> has joined #xwiki | ||
265 | 17:50 <jnsl_> how much memory dose xwiki generally use? I'm currently using confluence, but it takes 70% of all my memory so im looking for a less power hungry application | ||
266 | 18:01 <sburjan> has joined #xwiki | ||
267 | 18:08 <sburjan> has quit | ||
268 | 18:25 <tmortagne> has quit | ||
269 | 18:58 <+mflorea> sdumitriu: ping to read my last mail on devs. Please take some time to fix the remaining tests related to EM UI and Space Template so that I can release 3.4M1 tomorrow morning. Thanks | ||
270 | 18:59 <@sdumitriu> OK mflorea | ||
271 | 19:00 <mflorea> has quit | ||
272 | 19:12 <gdelhumeau> has quit | ||
273 | 19:19 <jvdrean> has quit | ||
274 | 20:04 <CIA-121> Sergiu Dumitriu master * r6a86e93 / (5 files in 2 dirs): XWIKI-7246: Add ability to browse all available extensions ... | ||
275 | 20:13 <CIA-121> Thomas Mortagne master * r45ccbeb / xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/web/XWikiServletResponse.java : Revert again - http://git.io/GcFJDw | ||
276 | 20:30 <mflorea> has joined #xwiki | ||
277 | 20:56 <SvenDowideit> has quit | ||
278 | 20:57 <SvenDowideit> has joined #xwiki | ||
279 | 21:14 <abusenius> has joined #xwiki | ||
280 | 21:56 <rrodriguez> has joined #xwiki | ||
281 | 22:30 <rrodriguez> has quit | ||
282 | 22:31 <rrodriguez> has joined #xwiki | ||
283 | 22:33 <rrodriguez> has quit | ||
284 | 22:35 <rrodriguez> has joined #xwiki | ||
285 | 22:42 <abusenius> has quit | ||
286 | 22:50 <lucaa> has joined #xwiki | ||
287 | 22:58 <lucaa> has quit | ||
288 | 23:12 <DrLou> has quit | ||
289 | 23:20 <DrLou_> has joined #xwiki | ||
290 | 23:23 <DrLou_> has left #xwiki | ||
291 | 23:25 <DrLou_> has joined #xwiki | ||
292 | 23:26 <DrLou_> has left #xwiki | ||
293 | 23:43 <mflorea> has quit | ||
294 | 23:55 <SvenDowideit> has quit | ||
295 | 23:55 <SvenDowideit> has joined #xwiki |