March 2012 - xwiki-devs@xwiki.org

[xwiki-devs] Convention for class property hints ?
by Jerome Velociter 18 Jul '16

18 Jul '16

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

5 7

[xwiki-devs] [UX][Consistency][Vote] "Page" vs. "Document" consistent naming
by Ecaterina Moraru (Valica) 09 Sep '15

09 Sep '15

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

10 14

[xwiki-devs] [Proposal] Split XE pages into platform modules
by Vincent Massol 06 Mar '15

06 Mar '15

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

8 20

[xwiki-devs] Questions about fixing getRenderedContent() bug
by Vincent Massol 18 Feb '15

18 Feb '15

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

4 7

[xwiki-devs] [Proposal] Cleaning our POM deps by explicitly listing used dependencies?
by Vincent Massol 06 Jun '14

06 Jun '14

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

6 16

[xwiki-devs] [Vote] Creation of a design wiki and it's purpose
by Ecaterina Moraru (Valica) 18 Nov '13

18 Nov '13

Hi, *Short version* for voting: *A*. Creation of a new wiki on xwiki.org farm that will hold development process details about a specific feature. This wiki will deprecate dev.xwiki.org:Design and incubator.myxwiki.org *B*. Vote on naming alternatives for this new wiki: design.xwiki.org incubator.xwiki.org *C*. UI on how a Proposal will be displayed in this new wiki (example AppWithinMinutes): http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgDesignWiki ------------------------------------------------ *Long version: * Right now development process activities are located in multiple places: - Analysis + Architecture: http://dev.xwiki.org/xwiki/bin/view/Design/ - Analysis + User Interface: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ - Other: http://xwiki.markmail.org/, http://jira.xwiki.org, chats, git comments, etc. This process can be hard to optimize and information is hard to track if you are looking for specific information. And the worst part of it is that is hard to automatize and lots of the items need manual gathering or search. *Part A. * This mail is about combining http://dev.xwiki.org/xwiki/bin/view/Design/and http://incubator.myxwiki.org/ work in a single place. This has already been discussed several times before ( http://xwiki.markmail.org/thread/kc32dufsf7nyyt6s and http://xwiki.markmail.org/thread/izj6aiyodwqia4vl) and the vote was favorable in this direction. The proposal was to create a new wiki called design.xwiki.org that will contain the combined information and that will target developers. The new wiki will be used to gather only proposal's development process information: requirements, architecture, solutions alternatives, user interface variants, planning, etc. for a specific feature/idea/improvement. After the proposal is implemented it will be properly documented in the right location for users (ex platform.xwiki.org) It is acceptable to have CSS + JS code on this wiki in order to demonstrate the functionality of the proposals, but we should not add experimental/dangerous code (groovy scripts, jars, etc.). For this case it is advisable to use a test machine, share your own instance or use the contrib.xwiki.org repository for hosting. The version upgrades will be handle by a community admin and the wiki gardening by me. The data from incubator.myxwiki.org and dev.xwiki.org:Design will be moved gradually after the new wiki is created. *Part B. * You should state your opinion regarding which name is better for the new wiki: - design.xwiki.org - incubator.xwiki.org - we accept other proposals. *Part C.* I've made a proposal on how a proposal page would look like: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgDesignWiki The proposal page will gather all the information related to it, making it easier to track it's progress. The entries will be separated depending on 4 categories: Analysis, Architecture, User Interface and Implementation, each category having it's own status, participants, jiras and timeframe. Categories are not mandatory for all proposals, smaller proposals will have just the related pages for certain areas. Each proposal will store it's data in a dedicated space. The implementation of the proposal will be handled by me. Let me know what you think. Thanks, Caty

9 23

[xwiki-devs] [Proposal] Finding how many active instances of XWiki there are out there
by Vincent Massol 03 Sep '13

03 Sep '13

Hi devs, I think it would be great to have some indication of how many active instances of XWiki are out there in the wild. The idea is not so much to know the figure but to see how this figures evolves and thus to see if we're doing things right. It will also give us information about how quickly or slowly our user base upgrades from version to version. Here's my proposal: * When installing XWiki on a clean DB (ie first time install) generate a unique id and store it in the DB (similar to the version we're storing in the DB but using some UUID). Thus when an install is upgraded the same id is preserved. * When the Extension Manager is used and thus connects to extensions.xwiki.org (default extension repository), this unique ID is sent too. * In addition the version of XE is sent too * On extensions.xwiki.org side, we only log the unique ID/XE version **without** logging the IP or any other information thus ensuring that the ID remains completely anonymous * We display a counter on xwiki.org about the # of active instances of XE with a graph about XE versions used WDYT? Thanks -Vincent

5 8

[xwiki-devs] Redirect to a space
by Bruno Amaro Almeida 04 Jun '13

04 Jun '13

Hi How can i redirect the users after login to a space ? I`m looking at login.vm but i have no clue to do this Thanks

4 6

[xwiki-devs] [Brainstorming] Colocated Functional Test (CFT)
by Vincent Massol 22 Nov '12

22 Nov '12

Hi devs, I've started an experiment to have colocated functional tests (CFT), which means having the functional tests located where the functional domain sources are located instead of in XE. For example for the linkchecker module we have the following directories: xwiki-platform-linkchecker/ |_ xwiki-platform-linkchecker-refresher (JAR) |_ xwiki-platform-linkchecker-ui (XAR) |_ xwiki-platform-linkchecker-tests (functional tests) The rationale for this was: * Have everything about a functional domain self-contained (source and all tests) * Making it easy to run only tests for a given functional domain * Move page objects to the functional domain too Here are some findings about this experiment: A - It takes about 30 seconds to generate the adhoc packaging and start XWiki. This would be done for each module having functional tests compared to only once if all tests were executed in XE B- The package mojo created to generate a full packaging is quite nice and I plan to reuse it in lots of other places in our build (distributions, database, places where we need XWiki configuration files) C- We will not be able to run platform builds in Maven multithreaded mode since it would mean that several XWiki instance could be started at the same time on the same port D- The colocated functional test module Solutions/ideas: * One idea to overcome A and C would to have the following setup: ** Keep functional test modules colocated but have them generate a test JAR ** Still allow running functional tests from the colocated module (this makes it easy to verify no regression was introduced when making changes to a given domain) ** Have functional tests in XE depend on the colocated functional test module JARs and configure Jenkins to run all functional tests from XE only * Another solution to overcome C is to auto-discover the port to use in our XWiki startup script (and save it in a file so that the stop script can use it). I think the first proposal is the best one and brings the best of the 2 worlds. WDYT? Thanks -Vincent

4 10

Re: [xwiki-devs] [VOTE] Move history when moving stuff from repositories of "xwiki" organization
by Denis Gervalle 14 Nov '12

14 Nov '12

Le 9 mars 2012 16:59, "Vincent Massol" <vincent(a)massol.net> a écrit : > > > On Mar 2, 2012, at 10:06 AM, Denis Gervalle wrote: > > > On Wed, Feb 29, 2012 at 08:19, Vincent Massol <vincent(a)massol.net> wrote: > > > >> Hi, > >> > >> On Feb 28, 2012, at 12:17 PM, Thomas Mortagne wrote: > >> > >>> Hi devs, > >>> > >>> Since I plan to move some stuff from platform to commons I would like > >>> to know what you think of the history in this case. > >>> > >>> Pros including history: > >>> * can access easily the whole history of a moved file. > >> > > > > This is really an important matter, especially for those joining the > > project. When you follow XWiki from "outside", and not in a continuous > > manner, the history is of great value to understand why stuffs are like > > they are, and what you may do, or not when moving forward. > > The history is not lost. If you do a join (all active repos) you still have it. I do not know what you means by joining all repos, but I would be surprise to see the IDE find its way between them. I even wonder how it could be possible. > > >> But sometimes > >>> changing packages etc make too much difference for git to see it's > >>> actually the same file so you loose it anyway. > >> > > > > If you simply change the package name, and nothing else, it is really > > unlikely to happen. > > > > > >>> > >>> Cons including history: > >>> * double the history which make tools like ohloh indicate wrong > >> informations > >> > > > > Sure, the stats will be broken, but what is the matter. This is not > > cheating, just a misfeature in Ohloh, since the commit are just identical, > > something they may notice. IMO, this is the matter of the statistical tools > > to improve that. > > Can you tell me how to implement this because right now my GitHub tool doesn't do that and I don't know how to do it? If I had to implement it, I will probably use some hashing method to be able to recognize similar commits, since there effectively no link between them. But my main remarks that the statistics are broken, not the way we use git. > > >>> * it's a lot easier to move without history > >> > > > > There should be some tools to improve that point or we may write one, once > > for all. So this is not a real cons either. > > It's really hard to copy history in Git. It's almost impossible to do it right. You have to remember the full history and it's just too hard. I would be really disappointed to have to conclude that. There is probably some edge cases, but most of the time there is clever work around. You have to talk to Sergiu :-) > > >>> WDYT ? > >>> > >>> Even if it was looking a bit weird to me at first I'm actually +1 to > >>> not move the history in this case. > >> > >> +1, FTR I'd be -0, close to -1 to move it. If/when the source repository > >> is removed for one reason or another, then we might want to import its > >> history somewhere. > >> > > > > Seems we are really opposite on this one, since I am close to -1 to not > > move it. > > Sorry but that's the current practice :) It's also the easiest one. Until we have Git, there were no better way. This does not means that we should not improve our practice. By the way, it was not my thread, if Thomas has asked, it means that the current practice was not so current. > > > Statistics is really less valuable IMO, it is a small interest compare to > > code history, that I have use a lot, especially when I have join the > > project and follow sparingly. > > I can say exactly the same thing as you said above. It's just a question of tools since the history is not lost. It's still there in our active repos. There is absolutely no link between these histories. It is not only a question of tools. Moreover, requiring querying all active repositories to have a proper history completely defeat the purpose of having separate repositories. I do not see the comparison with my remark above. Git has been made for versionning, not for statistics, it is not my fault. > > > So the general rule for me is: Copy history when the source repository is > >> removed/deleted/not used anymore. > > How many times have you done this? I believe 0 times since I don't think you'd be so much in favor if you had tried it. I suggest you try it a few times on your own projects first :) It's really hard to do it right and very time consuming. When I have copied the security component from contrib, I have done so. I hope that I am not alone. And, frankly, it was not so hard, compare to the advantage you have. > > > You never know what will happen to a repository in the future, so this > > rules is somewhat a hope on the future, no more. And remembering that we > > may loose history if we do some change in the old repository, is for me > > like hoping you will remember my birthday ;) > > I don't agree with this at all. Again we're not loosing history. If a repo is removed then its history is copied I agree about that. I would like to know how you do that after the facts? > > >>> Eduard was proposing to include in the first commit of the new > >>> repository the id of the last commit containing the files (basically > >>> the id of the parent of the commit deleting the files) in the old > >>> repository so that it's easier to find it. I'm +1 for this. > >> > > > > But you loose all the benefits of the IDE tools that brings history of a > > selection automatically and that are really useful. > > A huge majority of xwiki's history is already lost to IDEs (when we moved from SVN) even though the SVN history was moved. Even Git itself doesn't follow the history when you move stuff around. Said differently it's alwasy possible to find the history but the IDE and "standard" tool don't follow it. It does so far better since we move to Git and it is really a valuable tool. Do you means that because in a few case, the history may be broken, that we should not try to have it as complete as possible? > > > Moreover, if the history is rewritten due to a change in structure later, > > the hash may be broken. > > Not sure I understand this one. In Git, nothing is fully permanent, that is all I say. > > You should really measure the cost of what you propose Denis. It's really hard to do. Prove me that is more cost than the one newcommers has to enter the project. Maybe you do not value history so much because you have by your own experience of the project a good knowledge of what happen in the past. When I dig in some code, I always found history valuable to understand why that piece of code is not written the way I may have expected and why I should not got that way. If Thomas conclude it is too hard to be done, and not just some developer's lazyness, I would understand; but I do not agree that it should not be done just because it breaks statistics or we think it is too hard. This is why I suggest a tools that do it once for all. I would be really disappointed of Git if we had to conclude this. Thanks, Denis > > Thanks > -Vincent > > > So having a broken history is hardening the task of those who want to > > participate. A great value compare to the statistics IMO. > > > > -- > > Denis Gervalle > > SOFTEC sa - CEO > > eGuilde sarl - CTO > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

5 8