IRC Archive for channel #xwiki
Last modified by Vincent Massol on 2012/10/18 19:18
02:51 <DrLou> has quit
03:21 <abusenius> has quit
05:23 <venkatesh> has joined #xwiki
05:24 <venkatesh> has quit
05:25 <venkatesh> has joined #xwiki
06:11 <jvdrean> has quit
07:05 <venkatesh> has quit
07:21 <venkatesh> has joined #xwiki
07:44 <npm_> has joined #xwiki
07:47 <venkatesh> has quit
07:48 <npm> has quit
07:58 <sdumitriu> has quit
08:03 <venkatesh> has joined #xwiki
08:16 <mflorea> has joined #xwiki
08:25 <tmortagne> has joined #xwiki
08:36 <vmassol> has joined #xwiki
08:54 <sburjan> has joined #xwiki
08:58 <npm__> has joined #xwiki
09:03 <npm_> has quit
09:10 <vmassol> moving jira issues related to rendering to new jira project…. not sending notif mails
09:11 <vmassol> (fyi)
09:16 <vmassol> and good morning!
09:21 <DrLou> has joined #xwiki
09:22 <+tmortagne> are you sure you are not sending notif mails ? ;)
09:22 <vmassol> well I checked the "don't send emails" button ;)
09:22 <+tmortagne> does not seems to work
09:23 <vmassol> well we only received 20 so far
09:23 <vmassol> I moved over 100
09:23 <+tmortagne> or it's because i'm warching most of theses issues
09:23 <+tmortagne> i received more than 20
09:23 <+tmortagne> a lot more actually
09:24 <vmassol> tmortagne: for http://jira.xwiki.org/jira/browse/XWIKI-1689 should it stay where it is or be moved to the new rendering jira
09:24 <vmassol> tmortagne: btw we'll need to do cleanup on issues, I did a builk move without looking at each issue in detail
09:24 <vmassol> I guess some will need to stay in the platform
09:24 <+tmortagne> vmassol: yes was planning to look all that after you finish
09:25 <vmassol> lightbox might be too related to platform to be moved maybe
09:25 <vmassol> wdyt?
09:25 <+tmortagne> for XWIKI-1689 i'm not sure
09:25 <+tmortagne> i would say move
09:25 <+tmortagne> it does not seems related to xwiki
09:25 <vmassol> ok
09:25 <vmassol> moving
09:25 <vmassol> it's going to be a pain for users to know where to log a jira issue :)
09:25 <+tmortagne> yep
09:25 <vmassol> s/a pain/even more of a pain/
09:25 <+tmortagne> but not worst than with plugins
09:26 <jvelociter> has quit
09:26 <+tmortagne> we will move issue as we do right now
09:26 <vmassol> tmortagne: could you look at the components I created for the new jira project?
09:26 <vmassol> I was wondering if we wanted more details or not
09:26 <+tmortagne> ok
09:26 <vmassol> I put only Syntax for ex
09:26 <vmassol> without listing all syntaxes
09:26 <vmassol> same for macros, transformations
09:28 <+tmortagne> yes i think I would prefer having a component by syntax/macro or group of macros (grouping info/error/etc. macro and things like that)
09:29 <@cjdelisle> Good morning, I think I'm going to remove RegisterTest since all of it's tests except for liveValidation are tested by RegisterWithoutLiveValidationTest and it has proven too fragile and prone to race conditions.
09:30 <@cjdelisle> *and every time I turn around, it is failing.
09:32 <vmassol> tmortagne: I'm neutral on this so go ahead if you want to create more components (I don't mind)
09:32 <+tmortagne> vmassol: btw there is thing depending on platform in projects you moved like xwiki1.0 syntax parser
09:32 <+tmortagne> vmassol: i will
09:32 <vmassol> sure there are errors
09:32 <vmassol> xwiki10 syntax parser is in the new rendering though
09:33 <+tmortagne> i'm not saying it depens on xwiki stuff exactly
09:33 <+tmortagne> but we should define how we do with dependency from the platform
09:33 <+tmortagne> like velocity
09:33 <+tmortagne> do we move them in some other project too
09:33 <+tmortagne> etc...
09:34 <vmassol> what we do usually
09:34 <vmassol> is either keep one issue in the jira project that seems the most appropriate
09:34 <vmassol> and then when you impleùent
09:34 <vmassol> you create another issue in other projects if they are impcted
09:34 <+tmortagne> i'm not talking about jira
09:34 <vmassol> ah
09:34 <+tmortagne> i'm talking about real dependencies here
09:35 <+tmortagne> we have platform depending of rendering and rendering depending on platform currently
09:35 <+tmortagne> which could make it very hard to release
09:35 <arkub> has joined #xwiki
09:35 <vmassol> ok yes we need to define precisely what deps we allow
09:35 <vmassol> right now
09:36 <vmassol> the definition is:
09:36 <vmassol> rendering can depend on anything in platform except the model
09:36 <vmassol> but we need to refine this
09:36 <vmassol> and add it to our enforcer
09:36 <@cjdelisle> +1
09:36 <+tmortagne> yes since that rule is already creating dependencies issue
09:37 <vmassol> yes we have a problem for releasing…. don't know how to solve this right now....
09:37 <vmassol> problem = not impossible but tedious to do (cannot release all core at once)
09:38 <+tmortagne> ideally we should have at least three projects (rendering, something depending on rendering and something rendering depends on) but not easy
09:38 <vmassol> looks like we'll need to break core into 2 parts or something
09:38 <vmassol> the core modules that are not tied to xwiki , i.e. "independent" and the modules tied to the xwiki business
09:38 <vmassol> or something like this
09:38 <vmassol> need to think about it
09:39 <+tmortagne> we should define a lists of project that are in some kind of XWiki Commons (all project that are not really Xwiki specifics, xwiki-properties, xwiki-configuration...)
09:39 <vmassol> looks like an xwiki common thingie…. caleb will like this….
09:39 <+tmortagne> and then rendering can depends on anything which is part of XWiki Commons
09:39 <vmassol> yep
09:40 <+tmortagne> would also be more clear for rendering contributors (not only a release issue)
09:40 <@cjdelisle> XWiki Commons :)
09:42 <+tmortagne> in that configuration rendering would be a big XWiki Commons that deserve it's own life basically (like we could do latter of others) ;)
09:43 <vmassol> actually that was the reason I mentioned at some point that extracting rendering would need to extract some other modules too but I was told that it wasn't an issue by jerome…. it was an issue actually!
09:44 <@cjdelisle> I don't know if you were on holiday at the time but I suggested starting an XWiki Commons project for libraries which have little or no dependencies and are useful in other projects.
09:44 <vmassol> (I should have thought more about it)
09:44 <vmassol> cjdelisle: I was here
09:44 <vmassol> but you talked about it in the context of your transaction module
09:44 <vmassol> (AFAIR)
09:45 <@cjdelisle> Yes, we talked about it, I was surprised to hear Thomas suggest the same thing today.
09:45 <vmassol> we talked about it a long ago too
09:45 <vmassol> it's the kind of thing that comes regularly
09:45 <vmassol> it's tempting but it's hard to define
09:45 <vmassol> you can easily swallow the whole of xwiki with it
09:45 <vmassol> which then makes it unneeded
09:45 <vmassol> :)
09:46 <@cjdelisle> My definition is it is for things which have no dependencies.
09:46 <vmassol> no dep on what?
09:46 <vmassol> no module has no dep
09:46 <vmassol> (in xwiki)
09:46 <vmassol> or maybe one
09:46 <vmassol> ;)
09:47 <@cjdelisle> So the logic would be split into a provider and a consumer as I split the logic in storage so that only a attachment storage depends on core.
09:48 <+tmortagne> cjdelisle: i was probably not here (1 month seek all that...)
09:49 <+tmortagne> s/seek/sick/
09:49 <@cjdelisle> IMO dependency is the biggest contributer to code disintegration. Unless dependcies are controlled strictly, everything will soon depend on everything and the code will unmanagable.
09:49 <@cjdelisle> ouch, glad you are feeling better now.
09:49 <+tmortagne> me too :)
09:50 <@cjdelisle> s/will/will become/
09:50 <+tmortagne> cjdelisle: I agree that's why I always look at it very closely
09:50 <vmassol> cjdelisle: I agree about controlling deps but I don't agree about not depending on external things and especially rewriting stuff and NIH syndrome
09:51 <+tmortagne> (I agree about being very careful with dependencies)
09:52 <@cjdelisle> I really wish other code conformed to my specifications more but when I go looking for a library I find I am so often disappointed that I do tend to suffer from NIH.
09:52 <+sburjan> what is NIH ?
09:53 <@cjdelisle> "Not Invented Here"
09:53 <@cjdelisle> in assembly
09:53 <vmassol> :)
09:54 <vmassol> actually my direction is the opposite: always try to remove our code in favor or someone's else code
09:54 <vmassol> (provided it's good quality, maintained, blah blah)
09:54 <@cjdelisle> Re dependencies, a pattern which I have found to work is to divide up the code into providers and glue. The providers should have dependency graphs shaped like tree branches and the glue should be as little as possible.
09:54 <vmassol> for ex, as soon as there's component mgmt in the JDK, I'd love to remove our component manager
09:55 <@cjdelisle> +1 there
09:55 <@cjdelisle> Ofc I will probably look over the JDK dep manager and go D: -30
09:55 <jvdrean> has joined #xwiki
09:55 <vmassol> hehe
09:56 <vmassol> guys if some of you want to help on what remains listed here: http://jira.xwiki.org/jira/browse/XWIKI-6053?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#issue-tabs
09:56 <vmassol> feel free.. that would help me… still a lot to do
09:56 <vmassol> btw tmortagne just seen core build is fialing
09:56 <@cjdelisle> Also I have found dep injection to be a peril since it makes it so easy to create horrible unmanagable dependency graphs since everything is effectively global.
09:57 <vmassol> seems the ordering thing is not fixed for metadata
09:57 <+tmortagne> that would be weird if you used a linkedhashmap
09:57 <vmassol> cjdelisle: you're going to have a hard time convincing me that IOC/dep ijection isn't good....
09:58 <vmassol> tmortagne: you just introduced a checkstyle error in the build ;)
09:58 <@cjdelisle> Not that it's not good, as with oop, it is a great power which must be handled very carefully.
09:59 <+tmortagne> vmassol: checking
10:01 <+tmortagne> "with great prower comes great responsibilities" as they say ;)
10:01 <Denis> has joined #xwiki
10:02 <vmassol> cjdelisle: I don't even see that. For me it's way of passing what you need instead of doing a new yourself. I don't see how that makes things unmanageable. Maybe your concern is the *automatic* part but not IOC
10:03 <@cjdelisle> I have been doing a project in C and I have found that when I start writing in a bad direction, it becomes obvious it much sooner because I do not have the tools to lean on.
10:03 <@cjdelisle> "ut oh, that context is becoming global" kind of thing.
10:06 <vmassol> tmortagne: sergiu introduced a dep on xwiki-core-script in xwiki-core-xml, IMO we need to separate this into another module
10:07 <vmassol> otherwise it draws it for rendering-api for ex
10:07 <+tmortagne> yep xml depending on script does not seems great
10:08 <+tmortagne> there should be xwiki-script module which provide the script service
10:08 <+tmortagne> (i guess it's for script service he did that)
10:08 <vmassol> xwiki-core-xml-script you mean?
10:08 <+tmortagne> s/xwiki-script/xml-script/
10:09 <+tmortagne> when i start a work with a "x" is usually ends up as xwiki since a while now :)
10:10 <vmassol> I need to check if there's an enforcer for the number of drawn deps
10:10 <vmassol> I'd love to add it to the rendering modules
10:10 <vmassol> so that when someone introduces a new dep we know it
10:11 <vmassol> we can write a custom one if one doesn't exist
10:12 <vmassol> maybe http://maven.apache.org/enforcer/enforcer-rules/evaluateBeanshell.html is enough somehow
10:12 <+tmortagne> there is nothing about dependecies in clirr ?
10:12 <vmassol> nope
10:12 <+tmortagne> that could be something they handle
10:12 <vmassol> it's only about java code
10:12 <+tmortagne> ok
10:12 <vmassol> and it's a dead project
10:12 <vmassol> so it won't be added unless we do it
10:12 <vmassol> which is some work
10:13 <+tmortagne> yep
10:14 <@cjdelisle> hmm todo is write a script to mine the source and make an image of a dependency graph which is hopefully snowflake shaped.
10:14 <vmassol> cjdelisle: why code it?
10:14 <vmassol> :)
10:15 <vmassol> there are already tons of such tools for maven
10:15 <+tmortagne> you can get one using m2eclipse
10:15 <vmassol> even for java code btw
10:15 <vmassol> intellij has very nice dep matrixes
10:16 <@cjdelisle> meh, could be done with sed and postgres.
10:16 <vmassol> http://www.jetbrains.com/idea/features/dependency_analysis.html
10:17 <@cjdelisle> hey, minesweeper
10:17 <vmassol> :)
10:20 <vmassol> wikimodel draws 4 deps now that's a lot (used to draw 2)
10:20 <vmassol> cssparser and sac been added
10:21 <vmassol> 14 deps drawn by xwiki-rendering-syntax-wikimodel
10:21 <vmassol> jdom, xerces, dom4j could be reduced
10:23 <vmassol> I don't see how we could reduce to less than 10 though
10:24 <vmassol> maybe 9 if we removed commons-lang
10:25 <+tmortagne> most of the dependencies comes from xhtml parser
10:25 <+tmortagne> which we are supposed to move
10:25 <vmassol> http://tinycoke.com/_6rAfu3qTdTaeI/screen_shot_2011-02-28_at_10.25.09_am.png
10:28 <+tmortagne> without xhtml parser we can remove xwiki-core-xml, cssparser
10:28 <+tmortagne> plus there is a lot of thing to move from rendering-api
10:28 <vmassol> yes would be nice
10:29 <vmassol> tmortagne: so are we going to renamed -syntax modules into parser modules?
10:29 <vmassol> s/renamed/rename/
10:29 <vmassol> parser specific to a syntax that is
10:29 <+tmortagne> why ?
10:30 <vmassol> xwiki-rendering-syntax-xhtml, -xwiki20, etc
10:30 <vmassol> instead of wikimodel, doxia
10:30 <+tmortagne> that already exist and what is planned
10:30 <+tmortagne> and its not parsers modulees
10:30 <+tmortagne> it's syntax modules
10:30 <vmassol> yes ok we can keep syntax notion
10:30 <+tmortagne> we will have a syntax-xwiki20 that will contains parser and renderer
10:31 <+tmortagne> etc...
10:31 <vmassol> right
10:31 <+tmortagne> like the xmlxdom one (which is not yet in platfor ok ;))
10:31 <+tmortagne> s/platform/rendring/
10:31 <vmassol> in rendering you mean :)
10:31 <vmassol> yep
10:31 <+tmortagne> need to change reflex :)
10:33 <vmassol> wow xwiki-core-velocity draws a *lot* of deps
10:33 <+tmortagne> yes and it's pretty xwiki specific too
10:34 <+tmortagne> skins etc...
10:34 <+tmortagne> we need to separate things a bit more in this project
10:34 <vmassol> http://tinycoke.com/_6r6Z53EvIX7RA/screen_shot_2011-02-28_at_10.33.51_am.png
10:34 <vmassol> I don't tink we need all of those in syntax-xwiki10
10:34 <+tmortagne> no we don't
10:34 <+tmortagne> we just need the velocity parser
10:35 <+tmortagne> which is located in this project
10:36 <+tmortagne> same thing for velocity macro which should only use "velocity" implementation of JSR223 it can find and not depends on all that
10:38 <+tmortagne> (but it also directly depends on velocity parser for "html" filter)
10:44 <vmassol> jstoldt: good morning, feel like documenting transformations on the syntax page?
10:44 <vmassol> we need to find a way to document the icon and wikiword transformations
10:45 <vmassol> and have that linked (or documented inline) from the syntax page
10:45 <vmassol> icon tx == emoticons
10:45 <vmassol> emoticons is a nice feature that we need to document
10:48 <vmassol> tmortagne: so maybe it's time to define a real core and separate platform from core…. ie have platform/core and platform/modules for ex
10:49 <+tmortagne> vmassol: what are you calling platform/core and platform/modules ?
10:49 <vmassol> hmm maybe core is too coarse grained
10:49 <vmassol> I was thinking about foundations
10:49 <vmassol> foundation modules
10:49 <vmassol> basically all modules required by rendering
10:50 <vmassol> (after we've removed the unnecessary deps)
10:50 <vmassol> we could keep them in platform/ for now
10:50 <+tmortagne> ok, i like better the "commons" idea (apache style) ;)
10:50 <@cjdelisle> +1
10:50 <vmassol> but grouped together
10:50 <+tmortagne> sure
10:50 <+tmortagne> of course
10:50 <+tmortagne> not exactly apache style
10:50 <+tmortagne> but same vocalbulary I mean
10:51 <vmassol> we'd need an enforcer definition in them
10:51 <vmassol> so that they can only depend on each another
10:51 <vmassol> + external deps
10:51 <+tmortagne> yep
10:51 <+tmortagne> and when a commons project is too big like rendering is it get it's own top project
10:52 <vmassol> yes
10:52 <mflorea> has quit
10:52 <vmassol> let's keep the notion of core jsut for now
10:52 <vmassol> (since it's in artifactid)
10:52 <vmassol> and introduce a commons notion under it
10:52 <vmassol> that would give:
10:52 <+tmortagne> and yes it's time i think since it's the "easiest" way to handle issue we have right now with rendering project
10:53 <vmassol> platform/core/commons/*, platform/core/* ?
10:53 <vmassol> or plarform/core/modules/*
10:53 <+tmortagne> hmm it's the same issue here
10:53 <+tmortagne> we sill have rendering depending on core
10:53 <+tmortagne> if you make commons a subporject of core
10:53 <vmassol> sure
10:54 <+tmortagne> it has to be independent
10:54 <vmassol> but that's 2 maven commands
10:54 <vmassol> you want to do a top level commons project now?
10:55 <@cjdelisle> I have a fix that should stabilize the registration test but it kind of abuses js.
10:55 <@cjdelisle> executeJavascript("try{ document.getElementById('register').onsubmit(null); }catch(err){}");
10:55 <@cjdelisle> // input, it encounters an error which keeps the next page from loading.
10:55 <@cjdelisle> Is that too evil?
10:55 <+tmortagne> vmassol: yep
10:55 <+tmortagne> that or do nothing for now
10:56 <+tmortagne> since that does not change anything
10:56 <+tmortagne> but i would prefer doing it now
10:56 <+tmortagne> so that rendering is clean
10:56 <vmassol> all these top level moves will make life a bit harder
10:56 <Enygma`> has joined #xwiki
10:56 <vmassol> for jira reporters, for release managers
10:56 <vmassol> (for developers who need to create separate jiras)
10:57 <vmassol> we need to find some easy way
10:57 <vmassol> we often have to change common modules
10:57 <vmassol> when working on something else
10:57 <vmassol> it's already true for rendering but even more true for commons modules
10:57 <Denis> has quit
10:57 <Denis2> has joined #xwiki
10:57 <+tmortagne> for jira reporters it does not change that much, most of the time we have to move them because they created on XE or it's actually a plugin issue
10:58 <Denis2> is now known as <Denis>
10:58 <vmassol> yes but
10:58 <vmassol> if developers have to create 2 issues instead of one
10:58 <vmassol> it's a bit of a pain
10:58 <vmassol> developers are jira reporters
10:59 <@cjdelisle> woo registration test is quick. I'm going to hold my nose and commit. I don't see any other way to trigger liveValidation.
10:59 <vmassol> cjdelisle: sorry no time to look right now, sounds too hacky and complex to look at right now for me;)
11:00 <+tmortagne> for release manager it's harder when dependencies are a mess than when project are properly separated IMO
11:00 <@cjdelisle> IMO it's nicer than what was there before (certainly more stable) it just causes an intentional error to block a page load.
11:01 <+tmortagne> i'm not sure yo ualways need to create several issue btw
11:01 <+tmortagne> s/ualways/always/
11:01 <+tmortagne> if you fix somethingon commons there is no reason to create a duplicate on platform
11:02 <+tmortagne> we don't create a duplicate on XE each time we fix something on core
11:03 <+tmortagne> commons -> platform is exactly the same thing than current platform -> XE
11:03 <@cjdelisle> What will the dependency rule be for commons? Clearly they aren't commons if commons depend on other xwiki projects but how much is too much dependency on other commons projects or outside projects?
11:05 <+tmortagne> cjdelisle: commons is one project and it would not have the right to depends on any other xwiki project
11:05 <+tmortagne> s/project/top project/
11:06 <+tmortagne> i don't see why they could not depends on each others
11:06 <evalica> has joined #xwiki
11:06 <+tmortagne> or why we should have some outside project limitation
11:07 <@cjdelisle> Well there must be some idea of "too much" dependency between the commons subprojects otherwise they will become the same as core.
11:08 <+tmortagne> cjdelisle: what i mean is that it's not a rule IMO it's just commons sense, when a project contains too much concept you separate it is several like we do all the time in core currently
11:08 <@cjdelisle> As far as outside projects I suppose it is alright not to impose any limit since outside projects are often what the commons projects are wrapping.
11:08 <mflorea> has joined #xwiki
11:09 <@cjdelisle> I suppose that is good enough. Maybe we should put something in writing that dependencies are supposed to be minimal?
11:10 <+tmortagne> we can
11:11 <jstoldt> vmassol: good morning to you, too
11:11 <jstoldt> what do you mean in detail?
11:12 <jstoldt> i already started to document the image syntax last week and i was going to include the icons
11:12 <jstoldt> but what about document something transformation?
11:13 <jstoldt> i might have a couple of minutes in the afternoon, no promise, though
11:20 <jstoldt|Notebook> has joined #xwiki
11:21 <sburjan_> has joined #xwiki
11:21 <sburjan> has quit
11:22 <sburjan_> has quit
11:22 <sburjan_> has joined #xwiki
11:23 <sburjan_> has quit
11:24 <sburjan> has joined #xwiki
11:34 <tcamberlin> has joined #xwiki
11:35 <vmassol> back (reading)
11:36 <vmassol> tmortagne: the issue is when you fix something in platform and you have to also fix something in commons (this happens very frequently IMO)
11:36 <vmassol> you need 2 jira issues for this
11:36 <vmassol> (instead of one now)
11:37 <vmassol> I'm not against it, I'm just saying it's going to be a little bit more difficult to commit
11:37 <@cjdelisle> perhaps the need to make changes to the both at the same time suggests that the api provided by the commons module is not generic enough.
11:38 <vmassol> it means the commons api is not stable yet
11:38 <vmassol> I don't see it about genericity
11:38 <vmassol> for me it's more about refactoring stuff
11:39 <vmassol> would need to check svn history to see how frequently we touch at common modules
11:39 <vmassol> there are some modules we don't touch often for sure
11:39 <@cjdelisle> I would think a good measure of an api is that is is altered less and less as it gets older.
11:40 <vmassol> so who wants to lead the xwiki commons proposal and move?
11:40 <vmassol> :)
11:40 <vmassol> I guess I could do it
11:40 <vmassol> but would need help
11:40 <@cjdelisle> What can I do.
11:40 <@cjdelisle> ?
11:40 <+tmortagne> vmassol: sure sometimes there is several but IMO it's not that much a pain
11:41 <vmassol> tmortagne: if you want to lead it, I can help too, your choice
11:41 <tcamberlin1> has joined #xwiki
11:41 <+tmortagne> at least it's not enough to not do it IMO
11:43 <vmassol> yes I agree about that
11:43 <+tmortagne> i would be glad to help but I still not finished the UI refactoring of extension manager (actually i did not even started with all other things i had to take care) :(
11:43 <+tmortagne> depends when we can report release
11:43 <vmassol> report?
11:43 <vmassol> postpone?
11:43 <+tmortagne> postpone yes
11:43 <vmassol> right now it's still planned for today
11:43 <vmassol> who's the RM?
11:43 <vmassol> sergiu?
11:43 <+tmortagne> no idea
11:44 <vmassol> who did M2?
11:44 <+tmortagne> mflorea IIRW
11:44 <vmassol> mflorea: ping
11:44 <vmassol> mflorea: are you the RM for 3.0?
11:44 <vmassol> (epecially 3.0M3)
11:44 <+tmortagne> unless it was something else, i'm a bit lost with RM theses days :)
11:45 <tcamberlin> has quit
11:45 <+tmortagne> we need to keep the old one branch one RM rule I think
11:45 <vmassol> at least one release one RM
11:45 <vmassol> I don't agree about branch
11:45 <vmassol> it's too much
11:46 <vmassol> release being a main release
11:46 <vmassol> like denis did a 2.5.1 at some point which was fine
11:46 <vmassol> it didn't have to be the RM that did the 2.5
11:46 <vmassol> same if some committer wants to do a bug fix release
11:54 <+mflorea> vmassol: I can do 3.0M3 but I need time to fix the WYSIWYG tests
11:54 <vmassol> mflorea: ok thanks. I'll let you handle the preparation for it then and make sure everyoen is ready
11:55 <vmassol> we need to evaulate when we can start the release
11:55 <+mflorea> not today anyway
11:55 <vmassol> with what we discussed this morning with cjdelisle and tmortagne, we might need 1-2 more days
11:55 <vmassol> if we're to implement the xwiki commons idea
11:56 <vmassol> so we might want to postpone the release to wednesday morning
11:56 <vmassol> could you handle that?
11:56 <+mflorea> yes
11:56 <vmassol> (verify if the idea floats, send vote mail, etc)
11:56 <+mflorea> that is fine with me too because the issue that makes selenium tests fails is tricky
11:57 <vmassol> (recompute release dates without changing the final date)
12:02 <venkatesh> has quit
12:03 <venkatesh> has joined #xwiki
12:04 <venkatesh> has quit
12:09 <tcamberlin1> has quit
12:14 <abusenius> has joined #xwiki
12:14 <vmassol> tmortagne, cjdelisle: can you look at http://tinypaste.com/a5b89 and tell me what you think/if I've forgotten something?
12:19 <vmassol> cjdelisle: what's the ETA of the attachment FS storgae for 3.0 final?
12:24 <jstoldt> vmassol: i'll be afk here for a while. if i have some time i'll message you later on, okay?
12:25 <vmassol> jstoldt: fine
12:25 <vmassol> I'm going for lunch now
12:26 <vmassol> tmortagne, cjdelisle: I'd like to send the mail now, is it ok for you?
12:26 <vmassol> I'd like a confirmation of the modules
12:26 <vmassol> the modules I listed
12:26 <vmassol> ok sending, you can reply to the mail
12:31 <vmassol> lunch, bb in 1 hour
12:33 <jstoldt|Notebook> has quit
12:37 <@cjdelisle> vmassol: I can get the recycle bin written in a day or two, I just have to stop doing other things.
12:47 <@cjdelisle> WDYT about dependency of one module in commons on another module in commons? I am leaning thward saying it should be unallowable since it is a slippery sloap.
12:50 <@cjdelisle> hmm apache commons does have inter commons module dependencies.
12:55 <@cjdelisle> vmassol: I don't like the list of things to move to commons. They all depend on our dependency injection system so IMO they are too tight knit to be considered commons.
12:56 <@cjdelisle> If there is no limit on dependencies then we could as well rename core to commons.
12:56 <abusenius> has quit
12:57 <oanat> has joined #xwiki
13:13 <@cjdelisle> why does rendering depend on xwiki-core-bridge?
13:29 <vmassol> cjdelisle: where do you see that in rendering/? (It's not supposed to be possible, there's a check)
13:29 <vmassol> cjdelisle: commons is about stuff not related to wikis
13:29 <vmassol> (ie modules that can be reused in other projects)
13:31 <vmassol> platofrm is about common stuff related to the wiki/xwiki domain
13:32 <vmassol> not depending on anything doesn't exist btw
13:32 <vmassol> (and would be very bad IMO)
13:32 <vmassol> (since it would mean reinventing everything)
13:32 <vmassol> (logging, configuration, IOC, etc)
13:33 <vmassol> we're not recreatinf apache comons
13:33 <vmassol> it already exists
13:33 <vmassol> if you don't watn a relationship on xwiki compnent module
13:33 <vmassol> then I would suggest that your code doesn't belong to the xwiki project
13:33 <vmassol> and should be proposed to another forge
13:34 <vmassol> if you're in xwiki you have to use component, xwiki logging, xwiki configuration, etc
13:57 <@cjdelisle> hehe you're going to have to throw out crypto and most of store.
13:58 <vmassol> crypto will need to use xwiki logging too
13:58 <vmassol> and probably other services
13:59 <vmassol> store will need a lot of services (cache, lgging, component, etc)
13:59 <@cjdelisle> Yes, I have been meaning to fix that logging service so that it doesn't require everyone to extend it.
13:59 <@cjdelisle> <description>XWiki Platform - Core - Rendering - XWiki-specific implementation</description>
13:59 <@cjdelisle> <dependencies>
13:59 <@cjdelisle> <dependency>
13:59 <@cjdelisle> <groupId>org.xwiki.platform</groupId>
13:59 <@cjdelisle> ^that's what I saw
13:59 <@cjdelisle> <artifactId>xwiki-core-bridge</artifactId>
13:59 <vmassol> yes
14:00 <@cjdelisle> Is that different?
14:00 <vmassol> that's not in rendering/
14:00 <vmassol> it's in platform
14:00 <vmassol> and it's "XWiki-specific implementation"
14:00 <@cjdelisle> ok, looking again.
14:00 <vmassol> it implements WikiModel using the DAB
14:01 <@cjdelisle> I didn't realize I had git svn rebase'd
14:02 <@cjdelisle> These are a lot of dependencies. Do you expect anyone to use our code if it demands that they install a separate componant manager from what they are using?
14:02 <+sburjan> @devs. I found some issues like this. http://jira.xwiki.org/jira/browse/XWIKI-5764 .This issue was not fixed but wasn't moved to 2.5.2 because I guess we're dropping 2.5 and 2.6. But what if this issue is present in 2.6, 2.7 or even 3.0 ?
14:02 <vmassol> why a separate one?
14:02 <vmassol> and yes
14:03 <vmassol> and they do
14:03 <vmassol> :)
14:03 <@cjdelisle> If someone is using guice or jsr299 then you want them to install ecm next to that?
14:03 <vmassol> and they don't need to care
14:03 <abusenius> has joined #xwiki
14:03 <vmassol> it's the same thing as saying:
14:03 <vmassol> becuase I use guice I disallow anyone use the new java keyword
14:03 <vmassol> you can have both next to each other
14:04 <@cjdelisle> "it's the same thing" ay?
14:04 <vmassol> to use the rendering module you use lookup(Parser.class, "xwiki/2.0) instead of new XWiki20Parser()
14:04 <vmassol> it's just an api thing
14:04 <vmassol> as a user you don't need to care
14:04 <vmassol> how it's implemented
14:05 <vmassol> now the good part
14:05 <vmassol> is that if you do care
14:05 <@cjdelisle> If you are a developer of a project and you don't care then you deserve whatever happens to you.
14:05 <vmassol> you can bridge it to your component system
14:05 <vmassol> you're not stuck
14:05 <vmassol> which you'd be if we were using new instead
14:06 <vmassol> cjdelisle: nobody is forced to use xwiki's rendering. If you use it it's because you see pros
14:07 <vmassol> we thought agrout this at length already
14:07 <vmassol> about
14:07 <@cjdelisle> Well then I guess my input is not needed.
14:07 <vmassol> unless you make a proposal
14:07 <vmassol> no
14:07 <vmassol> if you make a proposal that works
14:07 <@cjdelisle> Cool. I'll get deleted attachments done then.
14:08 <vmassol> then yes
14:08 <vmassol> :)
14:08 <vmassol> ah yes
14:08 <vmassol> that would be cool
14:08 <vmassol> would be great to have a fully working attachment store but 3.0
14:08 <vmassol> will 2 days be enough?
14:08 <vmassol> (we're released on wednesday)
14:08 <vmassol> s/released/releasing/
14:09 <vmassol> well you'd still have several days more to fix issues
14:09 <vmassol> but it would be good to have the base feature for 3.0M3
14:09 <vmassol> since thereafter it's RC
14:09 <@cjdelisle> Should be. I don't expect any surprises now. The hardest part is dealing with an api which allows deleting or restoring them by a db id #.
14:10 <@cjdelisle> So I have to add a file which maps numbers to paths :(
14:10 <vmassol> cjdelisle: btw not putting component module in commons won't help at all for teh dep issue
14:10 <vmassol> between rendering and platform
14:11 <@cjdelisle> I gather you have this all sorted out but I sense the deaggregation monster is beginning to eat the new core like it did the old.
14:13 <vmassol> I don't feel it like this for lots of reasons (unit tests, clear separation of concerns, components)
14:13 <vmassol> problems of old core were: hard to understand/maintain, hard to extend, no tests to prove it works
14:14 <@cjdelisle> everything depended on everything
14:15 <vmassol> we now have clean APIs (through interfaces), separated by domain
14:15 <@cjdelisle> *depends
14:15 <vmassol> eveyrtihng depended on everyghin wasn't the issue
14:15 <vmassol> the issue is that it caused
14:15 <vmassol> - hard to extend
14:15 <vmassol> -hard to maintain
14:16 <vmassol> we have separated them
14:16 <@cjdelisle> I know it well. I make a tiney change here and 50 miles away in some other code something breaks.
14:16 <vmassol> they're no longer hard dependencies
14:16 <vmassol> they're interface dependencies
14:16 <vmassol> implementation have been separated
14:17 <vmassol> dependencies are normal and cannot be avoided
14:17 <vmassol> how would you prevent for ex wiki pages to not depend on storage
14:17 <@cjdelisle> I have to commit a couple test changes and get into store. Anyway, something to keep in mind re that long list of dependencies.
14:17 <vmassol> ?
14:18 <@cjdelisle> I'll write up a essay/thesis type thing at some point with dependency graphs. I promise ;)
14:30 <vmassol> guys can you please reply to evalica's mail about the new download page please
14:30 <vmassol> we need a few more votes/feedback
14:30 <vmassol> evalica is ready to implement it
14:30 <vmassol> so far we have denis, caty and me I think
14:31 <vmassol> actually just caty and me
14:31 <vmassol> I mean people agreed on the textual proposal
14:32 <vmassol> evalica: IMO you can go ahead
14:32 <vmassol> since everyone agreed on the proposal
14:32 <vmassol> (the textual one)
14:32 <vmassol> and your proposal was an implementation of it
14:33 <+evalica> k
14:35 <sdumitriu> has joined #xwiki
14:42 <jvdrean> has quit
14:43 <vmassol> quick poll: should I create a xwiki-xml-script module to put the XMLScriptService component impl or should we instead put all script services in a common place. I prefer the former (ie grouping code by domain rather than by technical feature). wdyt?
14:45 <jvdrean> has joined #xwiki
14:46 <+tmortagne> +1 for xwiki-xml-script, a big project will all script services (and it could never be all) is very bad
14:46 <vmassol> ok good
14:46 <vmassol> I'll do that one now
14:47 <vmassol> a pity is that it'll have to be moved later on if we do the xwiki commons thing ....
14:47 <vmassol> tmortagne: so moving current xwiki-xml to xwiki-xml-api is ok to you?
14:47 <vmassol> hmm api or default?
14:47 <vmassol> or something else
14:48 <vmassol> default is better probably
14:48 <vmassol> (I'm not sure we want both -api and -default right now)
14:51 <@sdumitriu> vmassol: +1
14:52 <vmassol> ok thanks, doing it
14:52 <+tmortagne> -default kind of imply there is a -api somewhere, maybe tool or util but i'm +0 for default anyway
14:52 <vmassol> IMO default is ok even without api it means default impl
14:52 <vmassol> (having an api is not mandatory)
14:53 <vmassol> api = separated interfaces
14:53 <+tmortagne> ok as you want
14:53 <vmassol> I can't think of a better name
14:53 <vmassol> right now
14:53 <vmassol> :)
14:53 <+tmortagne> me neither
14:53 <vmassol> ok using default for now
14:53 <+tmortagne> reading your mail
14:54 <@sdumitriu> There's a problem with myxwiki, and a lot of the stacktraces are like this:
14:54 <@sdumitriu> - almost all threads locked on org.jboss.cache.RegionImpl.registerEvictionEvent
14:54 <@sdumitriu> - one thread is inside it
14:55 <@sdumitriu> So it's a JBossCache congestion
14:55 <@sdumitriu> tmortagne: Any ideas how to fix it?
14:55 <+tmortagne> sdumitriu: not really no
14:56 <@sdumitriu> The memory seems full as well
14:57 <@sdumitriu> Might be just a slowdown caused by swap thrashing
14:57 <@sdumitriu> In which case we should reduce the size of the cache
14:57 <@sdumitriu> I'll try that
14:58 <@sdumitriu> Done, let's see the results
15:37 <+sburjan> it seems that these issues have not been moved for 2.7.1, and now they will remain isolated there: http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+XWIKI+AND+affectedVersion+%3D+%222.7%22+AND+status+%3Dopen
15:38 <+tmortagne> indeed that's not very clean
15:39 <+sburjan> it creates noise in my reports :)
15:39 <+tmortagne> hmm wait
15:39 <+tmortagne> i was reading it the overway around
15:39 <+tmortagne> tough is was fix for 2.7
15:39 <+tmortagne> was is wrong here
15:39 <+tmortagne> ?
15:40 <+tmortagne> s/was/what/
15:40 <+sburjan> well they weren't fixed for 2.7, but they weren't moved to "affects" to 2.7.1
15:40 <+tmortagne> they are not supposed to
15:41 <+sburjan> why ?
15:41 <+tmortagne> affects has nothing to do with fix for
15:41 <+tmortagne> affect is where you foud this issue
15:41 <+tmortagne> found
15:41 <+tmortagne> we never change
15:43 <+tmortagne> it
15:43 <+tmortagne> theses issue has been found in 2.7 so the affects is 2.7
15:43 <+tmortagne> since it's not fixed in 2.7.1 it's obviously affecting 2.7.1 too
15:43 <+sburjan> I see.
15:43 <+tmortagne> I hope you did not changed affects in issues
15:43 <+sburjan> so you only migrate the "Fixed for" version ? (increment)
15:43 <+sburjan> nope
15:43 <+tmortagne> keeping a fix for a released version when the issue is not fixed does not really make sense so yes we move it
15:43 <+tmortagne> either we move it or we change for future when it's not critical and nobody is planning to work on it soon
15:44 <+sburjan> so in theory a issue could have 2.7 in Affects and 3.5 Fix for ?
15:44 <@sdumitriu> Yep
15:44 <+sburjan> understood
15:44 <+tmortagne> yep if 2.7 branch is abandonned when the issue is fixed
15:45 <+sburjan> understood
15:47 <+sburjan> thanks
15:47 <+sburjan> laters
15:47 <sburjan> has quit
16:23 <cjdelisle> has quit
16:25 <cjdelisle> has joined #xwiki
16:26 <vmassol> has quit
16:52 <npm> has joined #xwiki
16:54 <abusenius> has quit
16:56 <npm__> has quit
17:04 <abusenius> has joined #xwiki
17:21 <oanat> has left #xwiki
18:10 <abusenius> has quit
18:17 <+tmortagne> sdumitriu: any idea why some xwiki-core-xml-script test are failing ? as far as I can see DOMImplementationRegistry.newInstance().getDOMImplementation("LS 3.0"); is returning null
18:17 <+tmortagne> I guess there is a missing dependency or something
18:17 <@sdumitriu> Xalan
18:17 <@sdumitriu> Or Xerces
18:17 <@sdumitriu> I keep confusing these two
18:17 <@sdumitriu> Xerces
18:18 <+tmortagne> what's weird is that it does have a transitive dependency on xerces
18:18 <+tmortagne> through xwiki-core-xml-default
18:19 <@sdumitriu> Maybe there's an older version pulled in by a higher dependency
18:19 <@sdumitriu> JDOM?
18:19 <@sdumitriu> Try a dependency:tree to see what version ends up in the build
18:20 <+tmortagne> actually vmassol forgot something I think
18:20 <+tmortagne> checking something
18:20 <+tmortagne> looks like xml-script does not depends on xml-default
18:21 <+tmortagne> but it still build
18:21 <+tmortagne> sdumitriu: is that normal that script service doe snot use anything in xml-default ?
18:22 <@sdumitriu> Currently yes
18:22 <@sdumitriu> The script service is the API as well
18:23 <+tmortagne> should i put a dependency for later ?
18:23 <+tmortagne> otherwise i put a direct dependency on xerces
18:24 <@sdumitriu> Yes, add one for later
18:24 <+tmortagne> ok thanks
18:27 <@sdumitriu> tmortagne: hudson fails, missing dependency: org.xwiki.platform:xwiki-core-extension-handler-xar:jar:3.0-SNAPSHOT
18:27 <@sdumitriu> Did you add it to the parent pom as a submodule?
18:27 <+tmortagne> sdumitriu: yes i know
18:27 <+tmortagne> should be ok now
18:27 <+tmortagne> need core to rebuild
18:28 <+tmortagne> xar was not built because there was some half refactoring in jar
18:56 <tmortagne> has left #xwiki
18:59 <arkub> has quit
19:28 <jvdrean> has quit
20:50 <sburjan`> has quit
21:54 <abusenius> has joined #xwiki
23:08 <jvdrean> has joined #xwiki
23:12 <jvdrean> has quit
23:34 <mflorea> has quit
03:21 <abusenius> has quit
05:23 <venkatesh> has joined #xwiki
05:24 <venkatesh> has quit
05:25 <venkatesh> has joined #xwiki
06:11 <jvdrean> has quit
07:05 <venkatesh> has quit
07:21 <venkatesh> has joined #xwiki
07:44 <npm_> has joined #xwiki
07:47 <venkatesh> has quit
07:48 <npm> has quit
07:58 <sdumitriu> has quit
08:03 <venkatesh> has joined #xwiki
08:16 <mflorea> has joined #xwiki
08:25 <tmortagne> has joined #xwiki
08:36 <vmassol> has joined #xwiki
08:54 <sburjan> has joined #xwiki
08:58 <npm__> has joined #xwiki
09:03 <npm_> has quit
09:10 <vmassol> moving jira issues related to rendering to new jira project…. not sending notif mails
09:11 <vmassol> (fyi)
09:16 <vmassol> and good morning!
09:21 <DrLou> has joined #xwiki
09:22 <+tmortagne> are you sure you are not sending notif mails ? ;)
09:22 <vmassol> well I checked the "don't send emails" button ;)
09:22 <+tmortagne> does not seems to work
09:23 <vmassol> well we only received 20 so far
09:23 <vmassol> I moved over 100
09:23 <+tmortagne> or it's because i'm warching most of theses issues
09:23 <+tmortagne> i received more than 20
09:23 <+tmortagne> a lot more actually
09:24 <vmassol> tmortagne: for http://jira.xwiki.org/jira/browse/XWIKI-1689 should it stay where it is or be moved to the new rendering jira
09:24 <vmassol> tmortagne: btw we'll need to do cleanup on issues, I did a builk move without looking at each issue in detail
09:24 <vmassol> I guess some will need to stay in the platform
09:24 <+tmortagne> vmassol: yes was planning to look all that after you finish
09:25 <vmassol> lightbox might be too related to platform to be moved maybe
09:25 <vmassol> wdyt?
09:25 <+tmortagne> for XWIKI-1689 i'm not sure
09:25 <+tmortagne> i would say move
09:25 <+tmortagne> it does not seems related to xwiki
09:25 <vmassol> ok
09:25 <vmassol> moving
09:25 <vmassol> it's going to be a pain for users to know where to log a jira issue :)
09:25 <+tmortagne> yep
09:25 <vmassol> s/a pain/even more of a pain/
09:25 <+tmortagne> but not worst than with plugins
09:26 <jvelociter> has quit
09:26 <+tmortagne> we will move issue as we do right now
09:26 <vmassol> tmortagne: could you look at the components I created for the new jira project?
09:26 <vmassol> I was wondering if we wanted more details or not
09:26 <+tmortagne> ok
09:26 <vmassol> I put only Syntax for ex
09:26 <vmassol> without listing all syntaxes
09:26 <vmassol> same for macros, transformations
09:28 <+tmortagne> yes i think I would prefer having a component by syntax/macro or group of macros (grouping info/error/etc. macro and things like that)
09:29 <@cjdelisle> Good morning, I think I'm going to remove RegisterTest since all of it's tests except for liveValidation are tested by RegisterWithoutLiveValidationTest and it has proven too fragile and prone to race conditions.
09:30 <@cjdelisle> *and every time I turn around, it is failing.
09:32 <vmassol> tmortagne: I'm neutral on this so go ahead if you want to create more components (I don't mind)
09:32 <+tmortagne> vmassol: btw there is thing depending on platform in projects you moved like xwiki1.0 syntax parser
09:32 <+tmortagne> vmassol: i will
09:32 <vmassol> sure there are errors
09:32 <vmassol> xwiki10 syntax parser is in the new rendering though
09:33 <+tmortagne> i'm not saying it depens on xwiki stuff exactly
09:33 <+tmortagne> but we should define how we do with dependency from the platform
09:33 <+tmortagne> like velocity
09:33 <+tmortagne> do we move them in some other project too
09:33 <+tmortagne> etc...
09:34 <vmassol> what we do usually
09:34 <vmassol> is either keep one issue in the jira project that seems the most appropriate
09:34 <vmassol> and then when you impleùent
09:34 <vmassol> you create another issue in other projects if they are impcted
09:34 <+tmortagne> i'm not talking about jira
09:34 <vmassol> ah
09:34 <+tmortagne> i'm talking about real dependencies here
09:35 <+tmortagne> we have platform depending of rendering and rendering depending on platform currently
09:35 <+tmortagne> which could make it very hard to release
09:35 <arkub> has joined #xwiki
09:35 <vmassol> ok yes we need to define precisely what deps we allow
09:35 <vmassol> right now
09:36 <vmassol> the definition is:
09:36 <vmassol> rendering can depend on anything in platform except the model
09:36 <vmassol> but we need to refine this
09:36 <vmassol> and add it to our enforcer
09:36 <@cjdelisle> +1
09:36 <+tmortagne> yes since that rule is already creating dependencies issue
09:37 <vmassol> yes we have a problem for releasing…. don't know how to solve this right now....
09:37 <vmassol> problem = not impossible but tedious to do (cannot release all core at once)
09:38 <+tmortagne> ideally we should have at least three projects (rendering, something depending on rendering and something rendering depends on) but not easy
09:38 <vmassol> looks like we'll need to break core into 2 parts or something
09:38 <vmassol> the core modules that are not tied to xwiki , i.e. "independent" and the modules tied to the xwiki business
09:38 <vmassol> or something like this
09:38 <vmassol> need to think about it
09:39 <+tmortagne> we should define a lists of project that are in some kind of XWiki Commons (all project that are not really Xwiki specifics, xwiki-properties, xwiki-configuration...)
09:39 <vmassol> looks like an xwiki common thingie…. caleb will like this….
09:39 <+tmortagne> and then rendering can depends on anything which is part of XWiki Commons
09:39 <vmassol> yep
09:40 <+tmortagne> would also be more clear for rendering contributors (not only a release issue)
09:40 <@cjdelisle> XWiki Commons :)
09:42 <+tmortagne> in that configuration rendering would be a big XWiki Commons that deserve it's own life basically (like we could do latter of others) ;)
09:43 <vmassol> actually that was the reason I mentioned at some point that extracting rendering would need to extract some other modules too but I was told that it wasn't an issue by jerome…. it was an issue actually!
09:44 <@cjdelisle> I don't know if you were on holiday at the time but I suggested starting an XWiki Commons project for libraries which have little or no dependencies and are useful in other projects.
09:44 <vmassol> (I should have thought more about it)
09:44 <vmassol> cjdelisle: I was here
09:44 <vmassol> but you talked about it in the context of your transaction module
09:44 <vmassol> (AFAIR)
09:45 <@cjdelisle> Yes, we talked about it, I was surprised to hear Thomas suggest the same thing today.
09:45 <vmassol> we talked about it a long ago too
09:45 <vmassol> it's the kind of thing that comes regularly
09:45 <vmassol> it's tempting but it's hard to define
09:45 <vmassol> you can easily swallow the whole of xwiki with it
09:45 <vmassol> which then makes it unneeded
09:45 <vmassol> :)
09:46 <@cjdelisle> My definition is it is for things which have no dependencies.
09:46 <vmassol> no dep on what?
09:46 <vmassol> no module has no dep
09:46 <vmassol> (in xwiki)
09:46 <vmassol> or maybe one
09:46 <vmassol> ;)
09:47 <@cjdelisle> So the logic would be split into a provider and a consumer as I split the logic in storage so that only a attachment storage depends on core.
09:48 <+tmortagne> cjdelisle: i was probably not here (1 month seek all that...)
09:49 <+tmortagne> s/seek/sick/
09:49 <@cjdelisle> IMO dependency is the biggest contributer to code disintegration. Unless dependcies are controlled strictly, everything will soon depend on everything and the code will unmanagable.
09:49 <@cjdelisle> ouch, glad you are feeling better now.
09:49 <+tmortagne> me too :)
09:50 <@cjdelisle> s/will/will become/
09:50 <+tmortagne> cjdelisle: I agree that's why I always look at it very closely
09:50 <vmassol> cjdelisle: I agree about controlling deps but I don't agree about not depending on external things and especially rewriting stuff and NIH syndrome
09:51 <+tmortagne> (I agree about being very careful with dependencies)
09:52 <@cjdelisle> I really wish other code conformed to my specifications more but when I go looking for a library I find I am so often disappointed that I do tend to suffer from NIH.
09:52 <+sburjan> what is NIH ?
09:53 <@cjdelisle> "Not Invented Here"
09:53 <@cjdelisle> in assembly
09:53 <vmassol> :)
09:54 <vmassol> actually my direction is the opposite: always try to remove our code in favor or someone's else code
09:54 <vmassol> (provided it's good quality, maintained, blah blah)
09:54 <@cjdelisle> Re dependencies, a pattern which I have found to work is to divide up the code into providers and glue. The providers should have dependency graphs shaped like tree branches and the glue should be as little as possible.
09:54 <vmassol> for ex, as soon as there's component mgmt in the JDK, I'd love to remove our component manager
09:55 <@cjdelisle> +1 there
09:55 <@cjdelisle> Ofc I will probably look over the JDK dep manager and go D: -30
09:55 <jvdrean> has joined #xwiki
09:55 <vmassol> hehe
09:56 <vmassol> guys if some of you want to help on what remains listed here: http://jira.xwiki.org/jira/browse/XWIKI-6053?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#issue-tabs
09:56 <vmassol> feel free.. that would help me… still a lot to do
09:56 <vmassol> btw tmortagne just seen core build is fialing
09:56 <@cjdelisle> Also I have found dep injection to be a peril since it makes it so easy to create horrible unmanagable dependency graphs since everything is effectively global.
09:57 <vmassol> seems the ordering thing is not fixed for metadata
09:57 <+tmortagne> that would be weird if you used a linkedhashmap
09:57 <vmassol> cjdelisle: you're going to have a hard time convincing me that IOC/dep ijection isn't good....
09:58 <vmassol> tmortagne: you just introduced a checkstyle error in the build ;)
09:58 <@cjdelisle> Not that it's not good, as with oop, it is a great power which must be handled very carefully.
09:59 <+tmortagne> vmassol: checking
10:01 <+tmortagne> "with great prower comes great responsibilities" as they say ;)
10:01 <Denis> has joined #xwiki
10:02 <vmassol> cjdelisle: I don't even see that. For me it's way of passing what you need instead of doing a new yourself. I don't see how that makes things unmanageable. Maybe your concern is the *automatic* part but not IOC
10:03 <@cjdelisle> I have been doing a project in C and I have found that when I start writing in a bad direction, it becomes obvious it much sooner because I do not have the tools to lean on.
10:03 <@cjdelisle> "ut oh, that context is becoming global" kind of thing.
10:06 <vmassol> tmortagne: sergiu introduced a dep on xwiki-core-script in xwiki-core-xml, IMO we need to separate this into another module
10:07 <vmassol> otherwise it draws it for rendering-api for ex
10:07 <+tmortagne> yep xml depending on script does not seems great
10:08 <+tmortagne> there should be xwiki-script module which provide the script service
10:08 <+tmortagne> (i guess it's for script service he did that)
10:08 <vmassol> xwiki-core-xml-script you mean?
10:08 <+tmortagne> s/xwiki-script/xml-script/
10:09 <+tmortagne> when i start a work with a "x" is usually ends up as xwiki since a while now :)
10:10 <vmassol> I need to check if there's an enforcer for the number of drawn deps
10:10 <vmassol> I'd love to add it to the rendering modules
10:10 <vmassol> so that when someone introduces a new dep we know it
10:11 <vmassol> we can write a custom one if one doesn't exist
10:12 <vmassol> maybe http://maven.apache.org/enforcer/enforcer-rules/evaluateBeanshell.html is enough somehow
10:12 <+tmortagne> there is nothing about dependecies in clirr ?
10:12 <vmassol> nope
10:12 <+tmortagne> that could be something they handle
10:12 <vmassol> it's only about java code
10:12 <+tmortagne> ok
10:12 <vmassol> and it's a dead project
10:12 <vmassol> so it won't be added unless we do it
10:12 <vmassol> which is some work
10:13 <+tmortagne> yep
10:14 <@cjdelisle> hmm todo is write a script to mine the source and make an image of a dependency graph which is hopefully snowflake shaped.
10:14 <vmassol> cjdelisle: why code it?
10:14 <vmassol> :)
10:15 <vmassol> there are already tons of such tools for maven
10:15 <+tmortagne> you can get one using m2eclipse
10:15 <vmassol> even for java code btw
10:15 <vmassol> intellij has very nice dep matrixes
10:16 <@cjdelisle> meh, could be done with sed and postgres.
10:16 <vmassol> http://www.jetbrains.com/idea/features/dependency_analysis.html
10:17 <@cjdelisle> hey, minesweeper
10:17 <vmassol> :)
10:20 <vmassol> wikimodel draws 4 deps now that's a lot (used to draw 2)
10:20 <vmassol> cssparser and sac been added
10:21 <vmassol> 14 deps drawn by xwiki-rendering-syntax-wikimodel
10:21 <vmassol> jdom, xerces, dom4j could be reduced
10:23 <vmassol> I don't see how we could reduce to less than 10 though
10:24 <vmassol> maybe 9 if we removed commons-lang
10:25 <+tmortagne> most of the dependencies comes from xhtml parser
10:25 <+tmortagne> which we are supposed to move
10:25 <vmassol> http://tinycoke.com/_6rAfu3qTdTaeI/screen_shot_2011-02-28_at_10.25.09_am.png
10:28 <+tmortagne> without xhtml parser we can remove xwiki-core-xml, cssparser
10:28 <+tmortagne> plus there is a lot of thing to move from rendering-api
10:28 <vmassol> yes would be nice
10:29 <vmassol> tmortagne: so are we going to renamed -syntax modules into parser modules?
10:29 <vmassol> s/renamed/rename/
10:29 <vmassol> parser specific to a syntax that is
10:29 <+tmortagne> why ?
10:30 <vmassol> xwiki-rendering-syntax-xhtml, -xwiki20, etc
10:30 <vmassol> instead of wikimodel, doxia
10:30 <+tmortagne> that already exist and what is planned
10:30 <+tmortagne> and its not parsers modulees
10:30 <+tmortagne> it's syntax modules
10:30 <vmassol> yes ok we can keep syntax notion
10:30 <+tmortagne> we will have a syntax-xwiki20 that will contains parser and renderer
10:31 <+tmortagne> etc...
10:31 <vmassol> right
10:31 <+tmortagne> like the xmlxdom one (which is not yet in platfor ok ;))
10:31 <+tmortagne> s/platform/rendring/
10:31 <vmassol> in rendering you mean :)
10:31 <vmassol> yep
10:31 <+tmortagne> need to change reflex :)
10:33 <vmassol> wow xwiki-core-velocity draws a *lot* of deps
10:33 <+tmortagne> yes and it's pretty xwiki specific too
10:34 <+tmortagne> skins etc...
10:34 <+tmortagne> we need to separate things a bit more in this project
10:34 <vmassol> http://tinycoke.com/_6r6Z53EvIX7RA/screen_shot_2011-02-28_at_10.33.51_am.png
10:34 <vmassol> I don't tink we need all of those in syntax-xwiki10
10:34 <+tmortagne> no we don't
10:34 <+tmortagne> we just need the velocity parser
10:35 <+tmortagne> which is located in this project
10:36 <+tmortagne> same thing for velocity macro which should only use "velocity" implementation of JSR223 it can find and not depends on all that
10:38 <+tmortagne> (but it also directly depends on velocity parser for "html" filter)
10:44 <vmassol> jstoldt: good morning, feel like documenting transformations on the syntax page?
10:44 <vmassol> we need to find a way to document the icon and wikiword transformations
10:45 <vmassol> and have that linked (or documented inline) from the syntax page
10:45 <vmassol> icon tx == emoticons
10:45 <vmassol> emoticons is a nice feature that we need to document
10:48 <vmassol> tmortagne: so maybe it's time to define a real core and separate platform from core…. ie have platform/core and platform/modules for ex
10:49 <+tmortagne> vmassol: what are you calling platform/core and platform/modules ?
10:49 <vmassol> hmm maybe core is too coarse grained
10:49 <vmassol> I was thinking about foundations
10:49 <vmassol> foundation modules
10:49 <vmassol> basically all modules required by rendering
10:50 <vmassol> (after we've removed the unnecessary deps)
10:50 <vmassol> we could keep them in platform/ for now
10:50 <+tmortagne> ok, i like better the "commons" idea (apache style) ;)
10:50 <@cjdelisle> +1
10:50 <vmassol> but grouped together
10:50 <+tmortagne> sure
10:50 <+tmortagne> of course
10:50 <+tmortagne> not exactly apache style
10:50 <+tmortagne> but same vocalbulary I mean
10:51 <vmassol> we'd need an enforcer definition in them
10:51 <vmassol> so that they can only depend on each another
10:51 <vmassol> + external deps
10:51 <+tmortagne> yep
10:51 <+tmortagne> and when a commons project is too big like rendering is it get it's own top project
10:52 <vmassol> yes
10:52 <mflorea> has quit
10:52 <vmassol> let's keep the notion of core jsut for now
10:52 <vmassol> (since it's in artifactid)
10:52 <vmassol> and introduce a commons notion under it
10:52 <vmassol> that would give:
10:52 <+tmortagne> and yes it's time i think since it's the "easiest" way to handle issue we have right now with rendering project
10:53 <vmassol> platform/core/commons/*, platform/core/* ?
10:53 <vmassol> or plarform/core/modules/*
10:53 <+tmortagne> hmm it's the same issue here
10:53 <+tmortagne> we sill have rendering depending on core
10:53 <+tmortagne> if you make commons a subporject of core
10:53 <vmassol> sure
10:54 <+tmortagne> it has to be independent
10:54 <vmassol> but that's 2 maven commands
10:54 <vmassol> you want to do a top level commons project now?
10:55 <@cjdelisle> I have a fix that should stabilize the registration test but it kind of abuses js.
10:55 <@cjdelisle> executeJavascript("try{ document.getElementById('register').onsubmit(null); }catch(err){}");
10:55 <@cjdelisle> // input, it encounters an error which keeps the next page from loading.
10:55 <@cjdelisle> Is that too evil?
10:55 <+tmortagne> vmassol: yep
10:55 <+tmortagne> that or do nothing for now
10:56 <+tmortagne> since that does not change anything
10:56 <+tmortagne> but i would prefer doing it now
10:56 <+tmortagne> so that rendering is clean
10:56 <vmassol> all these top level moves will make life a bit harder
10:56 <Enygma`> has joined #xwiki
10:56 <vmassol> for jira reporters, for release managers
10:56 <vmassol> (for developers who need to create separate jiras)
10:57 <vmassol> we need to find some easy way
10:57 <vmassol> we often have to change common modules
10:57 <vmassol> when working on something else
10:57 <vmassol> it's already true for rendering but even more true for commons modules
10:57 <Denis> has quit
10:57 <Denis2> has joined #xwiki
10:57 <+tmortagne> for jira reporters it does not change that much, most of the time we have to move them because they created on XE or it's actually a plugin issue
10:58 <Denis2> is now known as <Denis>
10:58 <vmassol> yes but
10:58 <vmassol> if developers have to create 2 issues instead of one
10:58 <vmassol> it's a bit of a pain
10:58 <vmassol> developers are jira reporters
10:59 <@cjdelisle> woo registration test is quick. I'm going to hold my nose and commit. I don't see any other way to trigger liveValidation.
10:59 <vmassol> cjdelisle: sorry no time to look right now, sounds too hacky and complex to look at right now for me;)
11:00 <+tmortagne> for release manager it's harder when dependencies are a mess than when project are properly separated IMO
11:00 <@cjdelisle> IMO it's nicer than what was there before (certainly more stable) it just causes an intentional error to block a page load.
11:01 <+tmortagne> i'm not sure yo ualways need to create several issue btw
11:01 <+tmortagne> s/ualways/always/
11:01 <+tmortagne> if you fix somethingon commons there is no reason to create a duplicate on platform
11:02 <+tmortagne> we don't create a duplicate on XE each time we fix something on core
11:03 <+tmortagne> commons -> platform is exactly the same thing than current platform -> XE
11:03 <@cjdelisle> What will the dependency rule be for commons? Clearly they aren't commons if commons depend on other xwiki projects but how much is too much dependency on other commons projects or outside projects?
11:05 <+tmortagne> cjdelisle: commons is one project and it would not have the right to depends on any other xwiki project
11:05 <+tmortagne> s/project/top project/
11:06 <+tmortagne> i don't see why they could not depends on each others
11:06 <evalica> has joined #xwiki
11:06 <+tmortagne> or why we should have some outside project limitation
11:07 <@cjdelisle> Well there must be some idea of "too much" dependency between the commons subprojects otherwise they will become the same as core.
11:08 <+tmortagne> cjdelisle: what i mean is that it's not a rule IMO it's just commons sense, when a project contains too much concept you separate it is several like we do all the time in core currently
11:08 <@cjdelisle> As far as outside projects I suppose it is alright not to impose any limit since outside projects are often what the commons projects are wrapping.
11:08 <mflorea> has joined #xwiki
11:09 <@cjdelisle> I suppose that is good enough. Maybe we should put something in writing that dependencies are supposed to be minimal?
11:10 <+tmortagne> we can
11:11 <jstoldt> vmassol: good morning to you, too
11:11 <jstoldt> what do you mean in detail?
11:12 <jstoldt> i already started to document the image syntax last week and i was going to include the icons
11:12 <jstoldt> but what about document something transformation?
11:13 <jstoldt> i might have a couple of minutes in the afternoon, no promise, though
11:20 <jstoldt|Notebook> has joined #xwiki
11:21 <sburjan_> has joined #xwiki
11:21 <sburjan> has quit
11:22 <sburjan_> has quit
11:22 <sburjan_> has joined #xwiki
11:23 <sburjan_> has quit
11:24 <sburjan> has joined #xwiki
11:34 <tcamberlin> has joined #xwiki
11:35 <vmassol> back (reading)
11:36 <vmassol> tmortagne: the issue is when you fix something in platform and you have to also fix something in commons (this happens very frequently IMO)
11:36 <vmassol> you need 2 jira issues for this
11:36 <vmassol> (instead of one now)
11:37 <vmassol> I'm not against it, I'm just saying it's going to be a little bit more difficult to commit
11:37 <@cjdelisle> perhaps the need to make changes to the both at the same time suggests that the api provided by the commons module is not generic enough.
11:38 <vmassol> it means the commons api is not stable yet
11:38 <vmassol> I don't see it about genericity
11:38 <vmassol> for me it's more about refactoring stuff
11:39 <vmassol> would need to check svn history to see how frequently we touch at common modules
11:39 <vmassol> there are some modules we don't touch often for sure
11:39 <@cjdelisle> I would think a good measure of an api is that is is altered less and less as it gets older.
11:40 <vmassol> so who wants to lead the xwiki commons proposal and move?
11:40 <vmassol> :)
11:40 <vmassol> I guess I could do it
11:40 <vmassol> but would need help
11:40 <@cjdelisle> What can I do.
11:40 <@cjdelisle> ?
11:40 <+tmortagne> vmassol: sure sometimes there is several but IMO it's not that much a pain
11:41 <vmassol> tmortagne: if you want to lead it, I can help too, your choice
11:41 <tcamberlin1> has joined #xwiki
11:41 <+tmortagne> at least it's not enough to not do it IMO
11:43 <vmassol> yes I agree about that
11:43 <+tmortagne> i would be glad to help but I still not finished the UI refactoring of extension manager (actually i did not even started with all other things i had to take care) :(
11:43 <+tmortagne> depends when we can report release
11:43 <vmassol> report?
11:43 <vmassol> postpone?
11:43 <+tmortagne> postpone yes
11:43 <vmassol> right now it's still planned for today
11:43 <vmassol> who's the RM?
11:43 <vmassol> sergiu?
11:43 <+tmortagne> no idea
11:44 <vmassol> who did M2?
11:44 <+tmortagne> mflorea IIRW
11:44 <vmassol> mflorea: ping
11:44 <vmassol> mflorea: are you the RM for 3.0?
11:44 <vmassol> (epecially 3.0M3)
11:44 <+tmortagne> unless it was something else, i'm a bit lost with RM theses days :)
11:45 <tcamberlin> has quit
11:45 <+tmortagne> we need to keep the old one branch one RM rule I think
11:45 <vmassol> at least one release one RM
11:45 <vmassol> I don't agree about branch
11:45 <vmassol> it's too much
11:46 <vmassol> release being a main release
11:46 <vmassol> like denis did a 2.5.1 at some point which was fine
11:46 <vmassol> it didn't have to be the RM that did the 2.5
11:46 <vmassol> same if some committer wants to do a bug fix release
11:54 <+mflorea> vmassol: I can do 3.0M3 but I need time to fix the WYSIWYG tests
11:54 <vmassol> mflorea: ok thanks. I'll let you handle the preparation for it then and make sure everyoen is ready
11:55 <vmassol> we need to evaulate when we can start the release
11:55 <+mflorea> not today anyway
11:55 <vmassol> with what we discussed this morning with cjdelisle and tmortagne, we might need 1-2 more days
11:55 <vmassol> if we're to implement the xwiki commons idea
11:56 <vmassol> so we might want to postpone the release to wednesday morning
11:56 <vmassol> could you handle that?
11:56 <+mflorea> yes
11:56 <vmassol> (verify if the idea floats, send vote mail, etc)
11:56 <+mflorea> that is fine with me too because the issue that makes selenium tests fails is tricky
11:57 <vmassol> (recompute release dates without changing the final date)
12:02 <venkatesh> has quit
12:03 <venkatesh> has joined #xwiki
12:04 <venkatesh> has quit
12:09 <tcamberlin1> has quit
12:14 <abusenius> has joined #xwiki
12:14 <vmassol> tmortagne, cjdelisle: can you look at http://tinypaste.com/a5b89 and tell me what you think/if I've forgotten something?
12:19 <vmassol> cjdelisle: what's the ETA of the attachment FS storgae for 3.0 final?
12:24 <jstoldt> vmassol: i'll be afk here for a while. if i have some time i'll message you later on, okay?
12:25 <vmassol> jstoldt: fine
12:25 <vmassol> I'm going for lunch now
12:26 <vmassol> tmortagne, cjdelisle: I'd like to send the mail now, is it ok for you?
12:26 <vmassol> I'd like a confirmation of the modules
12:26 <vmassol> the modules I listed
12:26 <vmassol> ok sending, you can reply to the mail
12:31 <vmassol> lunch, bb in 1 hour
12:33 <jstoldt|Notebook> has quit
12:37 <@cjdelisle> vmassol: I can get the recycle bin written in a day or two, I just have to stop doing other things.
12:47 <@cjdelisle> WDYT about dependency of one module in commons on another module in commons? I am leaning thward saying it should be unallowable since it is a slippery sloap.
12:50 <@cjdelisle> hmm apache commons does have inter commons module dependencies.
12:55 <@cjdelisle> vmassol: I don't like the list of things to move to commons. They all depend on our dependency injection system so IMO they are too tight knit to be considered commons.
12:56 <@cjdelisle> If there is no limit on dependencies then we could as well rename core to commons.
12:56 <abusenius> has quit
12:57 <oanat> has joined #xwiki
13:13 <@cjdelisle> why does rendering depend on xwiki-core-bridge?
13:29 <vmassol> cjdelisle: where do you see that in rendering/? (It's not supposed to be possible, there's a check)
13:29 <vmassol> cjdelisle: commons is about stuff not related to wikis
13:29 <vmassol> (ie modules that can be reused in other projects)
13:31 <vmassol> platofrm is about common stuff related to the wiki/xwiki domain
13:32 <vmassol> not depending on anything doesn't exist btw
13:32 <vmassol> (and would be very bad IMO)
13:32 <vmassol> (since it would mean reinventing everything)
13:32 <vmassol> (logging, configuration, IOC, etc)
13:33 <vmassol> we're not recreatinf apache comons
13:33 <vmassol> it already exists
13:33 <vmassol> if you don't watn a relationship on xwiki compnent module
13:33 <vmassol> then I would suggest that your code doesn't belong to the xwiki project
13:33 <vmassol> and should be proposed to another forge
13:34 <vmassol> if you're in xwiki you have to use component, xwiki logging, xwiki configuration, etc
13:57 <@cjdelisle> hehe you're going to have to throw out crypto and most of store.
13:58 <vmassol> crypto will need to use xwiki logging too
13:58 <vmassol> and probably other services
13:59 <vmassol> store will need a lot of services (cache, lgging, component, etc)
13:59 <@cjdelisle> Yes, I have been meaning to fix that logging service so that it doesn't require everyone to extend it.
13:59 <@cjdelisle> <description>XWiki Platform - Core - Rendering - XWiki-specific implementation</description>
13:59 <@cjdelisle> <dependencies>
13:59 <@cjdelisle> <dependency>
13:59 <@cjdelisle> <groupId>org.xwiki.platform</groupId>
13:59 <@cjdelisle> ^that's what I saw
13:59 <@cjdelisle> <artifactId>xwiki-core-bridge</artifactId>
13:59 <vmassol> yes
14:00 <@cjdelisle> Is that different?
14:00 <vmassol> that's not in rendering/
14:00 <vmassol> it's in platform
14:00 <vmassol> and it's "XWiki-specific implementation"
14:00 <@cjdelisle> ok, looking again.
14:00 <vmassol> it implements WikiModel using the DAB
14:01 <@cjdelisle> I didn't realize I had git svn rebase'd
14:02 <@cjdelisle> These are a lot of dependencies. Do you expect anyone to use our code if it demands that they install a separate componant manager from what they are using?
14:02 <+sburjan> @devs. I found some issues like this. http://jira.xwiki.org/jira/browse/XWIKI-5764 .This issue was not fixed but wasn't moved to 2.5.2 because I guess we're dropping 2.5 and 2.6. But what if this issue is present in 2.6, 2.7 or even 3.0 ?
14:02 <vmassol> why a separate one?
14:02 <vmassol> and yes
14:03 <vmassol> and they do
14:03 <vmassol> :)
14:03 <@cjdelisle> If someone is using guice or jsr299 then you want them to install ecm next to that?
14:03 <vmassol> and they don't need to care
14:03 <abusenius> has joined #xwiki
14:03 <vmassol> it's the same thing as saying:
14:03 <vmassol> becuase I use guice I disallow anyone use the new java keyword
14:03 <vmassol> you can have both next to each other
14:04 <@cjdelisle> "it's the same thing" ay?
14:04 <vmassol> to use the rendering module you use lookup(Parser.class, "xwiki/2.0) instead of new XWiki20Parser()
14:04 <vmassol> it's just an api thing
14:04 <vmassol> as a user you don't need to care
14:04 <vmassol> how it's implemented
14:05 <vmassol> now the good part
14:05 <vmassol> is that if you do care
14:05 <@cjdelisle> If you are a developer of a project and you don't care then you deserve whatever happens to you.
14:05 <vmassol> you can bridge it to your component system
14:05 <vmassol> you're not stuck
14:05 <vmassol> which you'd be if we were using new instead
14:06 <vmassol> cjdelisle: nobody is forced to use xwiki's rendering. If you use it it's because you see pros
14:07 <vmassol> we thought agrout this at length already
14:07 <vmassol> about
14:07 <@cjdelisle> Well then I guess my input is not needed.
14:07 <vmassol> unless you make a proposal
14:07 <vmassol> no
14:07 <vmassol> if you make a proposal that works
14:07 <@cjdelisle> Cool. I'll get deleted attachments done then.
14:08 <vmassol> then yes
14:08 <vmassol> :)
14:08 <vmassol> ah yes
14:08 <vmassol> that would be cool
14:08 <vmassol> would be great to have a fully working attachment store but 3.0
14:08 <vmassol> will 2 days be enough?
14:08 <vmassol> (we're released on wednesday)
14:08 <vmassol> s/released/releasing/
14:09 <vmassol> well you'd still have several days more to fix issues
14:09 <vmassol> but it would be good to have the base feature for 3.0M3
14:09 <vmassol> since thereafter it's RC
14:09 <@cjdelisle> Should be. I don't expect any surprises now. The hardest part is dealing with an api which allows deleting or restoring them by a db id #.
14:10 <@cjdelisle> So I have to add a file which maps numbers to paths :(
14:10 <vmassol> cjdelisle: btw not putting component module in commons won't help at all for teh dep issue
14:10 <vmassol> between rendering and platform
14:11 <@cjdelisle> I gather you have this all sorted out but I sense the deaggregation monster is beginning to eat the new core like it did the old.
14:13 <vmassol> I don't feel it like this for lots of reasons (unit tests, clear separation of concerns, components)
14:13 <vmassol> problems of old core were: hard to understand/maintain, hard to extend, no tests to prove it works
14:14 <@cjdelisle> everything depended on everything
14:15 <vmassol> we now have clean APIs (through interfaces), separated by domain
14:15 <@cjdelisle> *depends
14:15 <vmassol> eveyrtihng depended on everyghin wasn't the issue
14:15 <vmassol> the issue is that it caused
14:15 <vmassol> - hard to extend
14:15 <vmassol> -hard to maintain
14:16 <vmassol> we have separated them
14:16 <@cjdelisle> I know it well. I make a tiney change here and 50 miles away in some other code something breaks.
14:16 <vmassol> they're no longer hard dependencies
14:16 <vmassol> they're interface dependencies
14:16 <vmassol> implementation have been separated
14:17 <vmassol> dependencies are normal and cannot be avoided
14:17 <vmassol> how would you prevent for ex wiki pages to not depend on storage
14:17 <@cjdelisle> I have to commit a couple test changes and get into store. Anyway, something to keep in mind re that long list of dependencies.
14:17 <vmassol> ?
14:18 <@cjdelisle> I'll write up a essay/thesis type thing at some point with dependency graphs. I promise ;)
14:30 <vmassol> guys can you please reply to evalica's mail about the new download page please
14:30 <vmassol> we need a few more votes/feedback
14:30 <vmassol> evalica is ready to implement it
14:30 <vmassol> so far we have denis, caty and me I think
14:31 <vmassol> actually just caty and me
14:31 <vmassol> I mean people agreed on the textual proposal
14:32 <vmassol> evalica: IMO you can go ahead
14:32 <vmassol> since everyone agreed on the proposal
14:32 <vmassol> (the textual one)
14:32 <vmassol> and your proposal was an implementation of it
14:33 <+evalica> k
14:35 <sdumitriu> has joined #xwiki
14:42 <jvdrean> has quit
14:43 <vmassol> quick poll: should I create a xwiki-xml-script module to put the XMLScriptService component impl or should we instead put all script services in a common place. I prefer the former (ie grouping code by domain rather than by technical feature). wdyt?
14:45 <jvdrean> has joined #xwiki
14:46 <+tmortagne> +1 for xwiki-xml-script, a big project will all script services (and it could never be all) is very bad
14:46 <vmassol> ok good
14:46 <vmassol> I'll do that one now
14:47 <vmassol> a pity is that it'll have to be moved later on if we do the xwiki commons thing ....
14:47 <vmassol> tmortagne: so moving current xwiki-xml to xwiki-xml-api is ok to you?
14:47 <vmassol> hmm api or default?
14:47 <vmassol> or something else
14:48 <vmassol> default is better probably
14:48 <vmassol> (I'm not sure we want both -api and -default right now)
14:51 <@sdumitriu> vmassol: +1
14:52 <vmassol> ok thanks, doing it
14:52 <+tmortagne> -default kind of imply there is a -api somewhere, maybe tool or util but i'm +0 for default anyway
14:52 <vmassol> IMO default is ok even without api it means default impl
14:52 <vmassol> (having an api is not mandatory)
14:53 <vmassol> api = separated interfaces
14:53 <+tmortagne> ok as you want
14:53 <vmassol> I can't think of a better name
14:53 <vmassol> right now
14:53 <vmassol> :)
14:53 <+tmortagne> me neither
14:53 <vmassol> ok using default for now
14:53 <+tmortagne> reading your mail
14:54 <@sdumitriu> There's a problem with myxwiki, and a lot of the stacktraces are like this:
14:54 <@sdumitriu> - almost all threads locked on org.jboss.cache.RegionImpl.registerEvictionEvent
14:54 <@sdumitriu> - one thread is inside it
14:55 <@sdumitriu> So it's a JBossCache congestion
14:55 <@sdumitriu> tmortagne: Any ideas how to fix it?
14:55 <+tmortagne> sdumitriu: not really no
14:56 <@sdumitriu> The memory seems full as well
14:57 <@sdumitriu> Might be just a slowdown caused by swap thrashing
14:57 <@sdumitriu> In which case we should reduce the size of the cache
14:57 <@sdumitriu> I'll try that
14:58 <@sdumitriu> Done, let's see the results
15:37 <+sburjan> it seems that these issues have not been moved for 2.7.1, and now they will remain isolated there: http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+XWIKI+AND+affectedVersion+%3D+%222.7%22+AND+status+%3Dopen
15:38 <+tmortagne> indeed that's not very clean
15:39 <+sburjan> it creates noise in my reports :)
15:39 <+tmortagne> hmm wait
15:39 <+tmortagne> i was reading it the overway around
15:39 <+tmortagne> tough is was fix for 2.7
15:39 <+tmortagne> was is wrong here
15:39 <+tmortagne> ?
15:40 <+tmortagne> s/was/what/
15:40 <+sburjan> well they weren't fixed for 2.7, but they weren't moved to "affects" to 2.7.1
15:40 <+tmortagne> they are not supposed to
15:41 <+sburjan> why ?
15:41 <+tmortagne> affects has nothing to do with fix for
15:41 <+tmortagne> affect is where you foud this issue
15:41 <+tmortagne> found
15:41 <+tmortagne> we never change
15:43 <+tmortagne> it
15:43 <+tmortagne> theses issue has been found in 2.7 so the affects is 2.7
15:43 <+tmortagne> since it's not fixed in 2.7.1 it's obviously affecting 2.7.1 too
15:43 <+sburjan> I see.
15:43 <+tmortagne> I hope you did not changed affects in issues
15:43 <+sburjan> so you only migrate the "Fixed for" version ? (increment)
15:43 <+sburjan> nope
15:43 <+tmortagne> keeping a fix for a released version when the issue is not fixed does not really make sense so yes we move it
15:43 <+tmortagne> either we move it or we change for future when it's not critical and nobody is planning to work on it soon
15:44 <+sburjan> so in theory a issue could have 2.7 in Affects and 3.5 Fix for ?
15:44 <@sdumitriu> Yep
15:44 <+sburjan> understood
15:44 <+tmortagne> yep if 2.7 branch is abandonned when the issue is fixed
15:45 <+sburjan> understood
15:47 <+sburjan> thanks
15:47 <+sburjan> laters
15:47 <sburjan> has quit
16:23 <cjdelisle> has quit
16:25 <cjdelisle> has joined #xwiki
16:26 <vmassol> has quit
16:52 <npm> has joined #xwiki
16:54 <abusenius> has quit
16:56 <npm__> has quit
17:04 <abusenius> has joined #xwiki
17:21 <oanat> has left #xwiki
18:10 <abusenius> has quit
18:17 <+tmortagne> sdumitriu: any idea why some xwiki-core-xml-script test are failing ? as far as I can see DOMImplementationRegistry.newInstance().getDOMImplementation("LS 3.0"); is returning null
18:17 <+tmortagne> I guess there is a missing dependency or something
18:17 <@sdumitriu> Xalan
18:17 <@sdumitriu> Or Xerces
18:17 <@sdumitriu> I keep confusing these two
18:17 <@sdumitriu> Xerces
18:18 <+tmortagne> what's weird is that it does have a transitive dependency on xerces
18:18 <+tmortagne> through xwiki-core-xml-default
18:19 <@sdumitriu> Maybe there's an older version pulled in by a higher dependency
18:19 <@sdumitriu> JDOM?
18:19 <@sdumitriu> Try a dependency:tree to see what version ends up in the build
18:20 <+tmortagne> actually vmassol forgot something I think
18:20 <+tmortagne> checking something
18:20 <+tmortagne> looks like xml-script does not depends on xml-default
18:21 <+tmortagne> but it still build
18:21 <+tmortagne> sdumitriu: is that normal that script service doe snot use anything in xml-default ?
18:22 <@sdumitriu> Currently yes
18:22 <@sdumitriu> The script service is the API as well
18:23 <+tmortagne> should i put a dependency for later ?
18:23 <+tmortagne> otherwise i put a direct dependency on xerces
18:24 <@sdumitriu> Yes, add one for later
18:24 <+tmortagne> ok thanks
18:27 <@sdumitriu> tmortagne: hudson fails, missing dependency: org.xwiki.platform:xwiki-core-extension-handler-xar:jar:3.0-SNAPSHOT
18:27 <@sdumitriu> Did you add it to the parent pom as a submodule?
18:27 <+tmortagne> sdumitriu: yes i know
18:27 <+tmortagne> should be ok now
18:27 <+tmortagne> need core to rebuild
18:28 <+tmortagne> xar was not built because there was some half refactoring in jar
18:56 <tmortagne> has left #xwiki
18:59 <arkub> has quit
19:28 <jvdrean> has quit
20:50 <sburjan`> has quit
21:54 <abusenius> has joined #xwiki
23:08 <jvdrean> has joined #xwiki
23:12 <jvdrean> has quit
23:34 <mflorea> has quit
