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

Re: [xwiki-devs] Some quesiton regarding development of xwiki macro / extensions / plugins

by David Delbecq

Hi, thanks everyone for all those usefull informations, i think with those + source codes from xwiki platform, i have everything i need to get started :) David Delbecq ----- Mail original ----- De: "Marius Dumitru Florea" <mariusdumitru.florea(a)xwiki.com> À: "XWiki Developers" <devs(a)xwiki.org> Envoyé: Mercredi 13 Juin 2012 09:30:34 Objet: Re: [xwiki-devs] Some quesiton regarding development of xwiki macro / extensions / plugins On Wed, Jun 13, 2012 at 1:48 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote: > On 06/12/2012 09:46 AM, David Delbecq wrote: >> >> Hello, >> >> To customize our entreprise wiki, we have identified a few plugins / >> macros that we need to develop. I have checked the online xwiki >> documentation / tutorial, but i find them quite uncomplete, so here i am >> with my questions :) >> >> >> 1) It is my understanding that, if my macro need some specific javascript >> (eg jquery.js) and css, i must use xwiki skin extension. While i can find >> easily how to create xwiki velocity code that use those extension, i found >> no explanation on how to do this in java from within "public List<Block> >> execute(T parameters, String content, MacroTransformationContext context)"? >> Where can i find example of embedding javascript/css inside a java macro jar >> or xar? > > > You declare a dependency on the org.xwiki.platform:xwiki-platform-skin-api > module in your project, and you declare a dependency on one or more > org.xwiki.skinx.SkinExtension fields with the right hint. For example: > > @Inject > @Named("jsrx") > private SkinExtension jsrx; > > Then you can call jsrx.use("jquery.js") if that file is packaged as a > resource whenever your macro is used. > > If you'r > > >> 2) Extensions are provided as xar, maven archetype for xwiki java macro >> generates a .jar. How do i generate a xar with maven so that in one archive >> i have both my macro, the css and the js? > > > Not true, extensions can be both jars or xars, depending on what kind of > extensions they are. If you're deploying a java macro, then it's right to > have a jar extension. A xar is used when you're providing wiki documents > that should be installed in the wiki. > > >> 3) Most extension referenced on xwiki main site are open source, but where >> are the source? I can only find the compiled xar files on download > > > A xar is just a zip file holding wiki documents, and you can always edit > those wiki documents to see their "source". A xar is both the source and the > binary. > > Some extensions do have a separate link to a repository if they have one, > especially those hosted on the official xwiki or xwiki-contrib repositories. > > >> 4) Is there some recommanded way to pass complex parameters to macros? I >> need to create some dynamic menu that will get as parameter a list of node + >> links + icon to show + subnodes + for each subnodes icons / links + >> subsubnode etc. Is it good practice to just put some kind of json in the >> body of macro, something like >> >> {{mymenu width="200px"}} >> [ >> { name: "node1", link: "MySpace.MyPage1", icon: "somelinktoanattachement"} >> , >> { name: "node2", link: "MySpace.MyPage2", icon: >> "somelinktoanattachement"}, >> { name: "node3", link: "MySpace.MyPage3", submenu: [ >> { name: "node3.1", link: "MySpace.MyPage31", icon: >> "somelinktoanattachement"}, >> { name: "node3.2", link: "MySpace.MyPage32", icon: >> "somelinktoanattachement"} >> ] >> } >> ] >> >> {{/mymenu}} > > > Unfortunately, macro calls are in text mode, so you don't have much of a > choice. > > You could define a variable somewhere in Velocity and then read it in Java > from the VelocityContext, but that's not very safe and might break in the > future. > > >> And in this case, are there already some stock xwiki methode to transform >> json into objet array? > > > I'm not sure of the status, but there was a proposal recently to include a > JSoN tool in the platform. I think it wasn't committed yet, It was committed, http://extensions.xwiki.org/xwiki/bin/view/Extension/Velocity+Module#HJSONT… , but it is useful in Velocity code. For Java code you should use directly the available JSON library (e.g. json-lib as suggested by Thomas). Hope this helps, Marius > > Reading from http://markmail.org/message/k4izx6re4lvdynx3 I think that you > should use the Jackson library, available as a maven dependency from > http://search.maven.org/#search|ga|1|a%3A%22jackson-core-lgpl%22 > >> Thank you, >> >> David Delbecq > > > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > > > > _______________________________________________ > 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

13 years, 3 months

1
0
0 0

[xwiki-devs] [VOTE] Change the way we do releases to include staging.

by Caleb James DeLisle

Hi, I'd like to add staging to our official release process. For milestone releases, I propose the staging cycle be for "0 time" (this may be revisited later). For RC or finals, we place the release in staging and immediately call a VOTE to publish the release, this gives our testing team (everybody!) 72 hours to raise a potential issue. Why: #1. After some chat on IRC I decided that it is advantageous to move toward a faster release cycle and begin moving away from milestone releases in favor of staging. This will set the stage for the release method we will need. #2. Staging is easy, I've modified the release script to include staging and with the script, it is a simple matter of about 5 clicks on nexus to "login", "close repository", "release repository". #3. Staging is safe, the RM need not worry about fat fingers breaking the release, all it costs is time. #4. The release process should be as close to the same as possible for milestone and RC/final releases. This simplifies scripting of the process, decreases the amount the RM must remember and makes every milestone release a rehearsal. #5. Everybody else is doing it (is that even a reason?!) Mandatory? I would rather impress the RM with how easy and helpful staging can be than bind him with rules. If I had followed the existing process to the letter, I would not have had any experience with staging to begin with. In the interest of continuous improvement I would like to make this a strong recommendation, not a strict rule. Here's my +1 Caleb

13 years, 3 months

6
18
0 0

[xwiki-devs] 3.5.1 release is partly busted...

by Vincent Massol

Hi devs, The RM for 3.5.1 (Sergiu?) made a mistake while releasing and "forgot" some profiles. One consequence is that rendering-standalone hasn't been released in version 3.5.1: - See http://maven.xwiki.org/releases/org/xwiki/rendering/xwiki-rendering-standal… you'll see that 3.5.1 is missing - Checkout tag 3.5.1 on rendering and view rendering-standalone/pom.xml, you'll see it has <version>3.5-SNAPSHOT</version> has parent version… As a consequence I cannot push Rendering 3.5.1 on Maven Central. Can the RM fix this please? Thanks -Vincent

13 years, 3 months

2
5
0 0

[xwiki-devs] [ANN] XWiki Enterprise 4.1 Release Candidate 1 is now available.

by Caleb James DeLisle

XWiki core development team is proud to announce the availability of XWiki Enterprise 4.1 Release Candidate 1 This is the first and hopefully final release candidate of the 4.1 release cycle. Being a release candidate, this release is sparse on new features concentrating instead on stabilization of the features brought in Milestone 1 and Milestone 2. The 4.1 cycle brings new 3D graphs made with pure XWiki syntax, safer Groovy scripting, and new localization through timezone settings. Go grab it at http://enterprise.xwiki.org/xwiki/bin/view/Main/Download and let us know what you think. For more information about the 4.1-rc-1 release, See the Release Notes http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris… Thanks to everyone who helped out to make this release great. Caleb

13 years, 3 months

1
0
0 0

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

by Jonathan Solichin

Hello friends, Thank you for being so patient with me. Here is a set of mockup with content etc. and further development: http://sdrv.ms/LLmQ5i which extends: (http://sdrv.ms/LO70JI) The goal is to consolidate everything to a section. (breadcrumbs/where you are & navigation/supplementary info & content) eg. the page breadcrumb has been added into the global bread crumb (is this possible?); all page navigation/meta are in the sidebar (such that, again, the main area is just content, and the sidebar are all additional infos) The way i'm envisioning the responsive design for the content is like this: When the screen is big enough, it will become 2 column. as we hit smaller screen (eg. tablet) it will become one column. Then finally, the page would collapse such that only the header is visible for mobile (thus also becoming a table of contents) until being tapped, which will open the div. As mentioned before, the same "sidebar" will appear when you click the navigation hint on mobile (so it will be in a way consistent). Though with this development i should probably add more than navigation (eg. NAVIGATION / INFO / ETC. or something). What are your guys' thoughts, comments, concerns? Thanks again! Best, Jonathan Solichin

13 years, 3 months

2
1
0 0

[xwiki-devs] [Proposal] Change to the 4.1-rc-1 and 4.1 release process.

by Caleb James DeLisle

After some discussion on IRC, the current plan for releasing 4.1-rc-1 and 4.1 has been determined to be unworkable. The specific part at issue is the calling of a VOTE to release what is currently in the staging repository and waiting 72 hours for it to be verified. While this provides the best quality assurance, each blocker means another failed vote and another 72 hours + the time to fix the issue and stage another release. Proposal: Stage the release 2 days before the official release date allowing blockers to be found and fixed. Fix the issues and release the resulting build without any guaranteed testing window, hoping that the patches to the earlier issues didn't introduce any regressions. I don't like it much but it seems that it sucks less than all of the alternatives so +0 for me. Caleb

13 years, 3 months

2
1
0 0

[xwiki-devs] New HTML Macro "restricted" mode question

by Vincent Massol

Hi Andreas, What happens if "clean" is false when executing in "restricted" mode? Thanks -Vincent

13 years, 3 months

3
4
0 0

[xwiki-devs] Bug count status on 8th of June 2012 - Diverging

by Vincent Massol

Hi devs, It seems we're loosing the race against bug reports: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… For the past 365 days there are have been 780 bugs reported and 692 resolved (gap of 88 bugs). The graph seems to indicate that the gap is increasing. Should we organize a bug fixing day? Any other idea? Thanks -Vincent

13 years, 3 months

5
5
0 0

[xwiki-devs] Current document vs. current wiki

by Marius Dumitru Florea

Hi devs, Following Anca's comments on http://jira.xwiki.org/browse/XWIKI-6058 I realized that the current document and the current wiki (database) are completely independent: you can have "someWiki" as the current wiki (context.setDatabase("someWiki")) and otherWiki:Space.Page as the current document (document.setAsContextDoc(context)). This means that it's not enough to set the current document if you want relative references to be resolved relative to that document. You also need to set the current wiki, Is this the desired behaviour? Should setAsContextDoc also set the current wiki? WDYT? Thanks, Marius

13 years, 3 months

2
1
0 0

[xwiki-devs] [UX][Idea] Render Switches

by Ecaterina Moraru (Valica)

Hi, One of the big problems for simple users when trying to use XWiki is the mix we have between text content and syntax/code content. If the user wants to edit the title of the WebHome he will see "$msg.get('xe.home.title')". Same happens for other use cases, like editing the title of the 'Welcome' gadget, etc. This is an idea for having a switch for rendered/syntax content for inputs: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/RenderSwitches… Read the full proposal at: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/RenderSwitches Thanks, Caty

13 years, 3 months

4
5
0 0

[xwiki-devs] New Maven Copy plugin usage

by Vincent Massol

Hi devs, Just a quick mail to let you know I've started using the Maven Copy plugin (http://evgeny-goldin.com/wiki/Copy-maven-plugin). ATM it's used only in the generic installer module: https://github.com/xwiki/xwiki-enterprise/blob/master/xwiki-enterprise-inst… It's very nice. At some point we'll need to decide if we wish to use it more throughout our build. It completely replaces the Assembly plugin, the Dependency plugin and the Remote Resources one. Thanks -Vincent

13 years, 3 months

2
4
0 0

[xwiki-devs] [Release] 4.1-rc-1 is now in staging, testers wanted.

by Caleb James DeLisle

13 years, 3 months

3
4
0 0

[xwiki-devs] [PROPOSAL] Release process/dates for 4.1-rc-1

by Caleb James DeLisle

In order to try meet a release date, I would like to use the process as documented here: http://dev.xwiki.org/xwiki/bin/view/Community/ReleasePlans#H4.1RC1 Synopsis: June 4th: * send 2 day warning mail, ask if anyone needs to block the release. * branch stable-4.1.x to allow 4.2 development to continue. June 6th: * build staged release. * send out call for testing. * do release on jira with release post-dated to the 11th. June 11th: * release from staging. * publish release. I know this is a tight schedule but realistically we need 2 days for warning/stabilization and 2 (working) days for testing. WDYT? Caleb

13 years, 3 months

4
5
0 0

[xwiki-devs] [VOTE] Remove the ancient wikiwiki rendering engine from the platform

by Sergiu Dumitriu

Hi devs, Most of the devs know about the new xwiki-rendering engine which provides the support for the new xwiki/2.x syntaxes, and the old Radeox-based rendering engine which provides support for the xwiki/1.0 syntax, but I wonder who knows about the Oro-based wikiwiki engine that provides support for an even older undocumented wiki syntax? That one has been in the oldcore sources before I came in contact with XWiki, and it has been disabled for a very long time. One thing that we still use from that basic rendering engine is the support for {pre}{/pre} code escaping, and that one will have to be preserved even if we remove all the rest. The advantages of removing it include: - less ancient, unused, buggy code -- thus slightly less PermGen memory required and faster startup - one less Oro dependency (a long term goal is to remove Oro and ECS from our dependencies) - fewer WTFs from people stumbling over that code Does anybody know of any users of that syntax? Is anybody still running 0.1.x versions? -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years, 3 months

8
11
0 0

[xwiki-devs] tab character displays null in xwiki syntax 1.0

by Paul Libbrecht

Hello fellow developers, it occurred to us that using a number followed by a dot then a tab character actually renders with a nested list and the word "null" is displayed. Is this something known? I could not find this on the bug base, we have opened: http://jira.xwiki.org/browse/CURRIKI-5815 I'm fearing, as anything syntax 1.0 that fixing that is going to be quite delicate. thanks for hints. Paul

13 years, 3 months

3
2
0 0

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

by Jonathan Solichin

Hi Jerome & Community, Here is the design page for the Responsive Skin [1]. * I'd like we start with a phase of "paper" design (I mean with gimp > or photoshop or whatever tool to produce images). This is available in the design page, or, alternatively phone [2], tablet [3], desktop [4] * I think we should limit the feature set of the skin ; not trying to > do everything right away (there are potentially a lot of features to > work on, from livetables to data editors, to applications, etc.) * For a start, focus should be given on content and navigation. With a > mobile-first approach, expanding up to large-screens desktop. * I think it's OK to have semantic break points (like "phone", > "tablet", etc.) as long as the skin is actually responsive and adapt > to whatever real estate is available. We should be able to "drag the > corner" of a browser window and have the skin display well at all > sizes. Agreed. Also, current questions (c&p) from other e-mail regarding gsoc: 1. Specific support for non-javascript capable browser? I feel like it is not necessarily since browser which can not support javascript will fall back by itself. More over, it would not be capable of carrying out media-queries required for responsive design and some XWIKI features (such as live tables?) anyway. 2. Is the community ok with trying to use "true (html)" drop downs / forms in order to fully utilize functions built in to phone/tablets [5]? 3. Pressable Links: should they be bigger on mobile to help facilitate touching on words, or would it be better to use a "background" to create a "touch area"? Both are in the phone mock up [6]. Former demonstrated in quicklinks, latter in the "Spaces" section. [1] http://dev.xwiki.org/xwiki/bin/view/Design/ResponsiveSkin [2] http://jssolichin.com/public/mobile.jpg [3] http://jssolichin.com/public/tablet.jpg [4] http://jssolichin.com/public/desktop.jpg [5] http://css-tricks.com/convert-menu-to-dropdown/ [6] http://jssolichin.com/public/mobile.jpg

13 years, 3 months

3
3
0 0

[xwiki-devs] [GSoc] XDroid Platform

by sasinda rukshan

Hi all, I am starting this thread for my XWiki Android Platform Project. Please check whether following are OK. [1] INFO I tried to start my new modules with the de.akquinet.android.archetypes: android-quickstart:1.0.8. (added eclipse plugins m2e, m2e-android[a.k.a *Android Configurator* ]). But this seems buggy in eclipse. Any way the earlier project has not followed the above archtype either. So I am going to write pom.xml manually for my each module. [2] ADVICE NEEDED xwiki-rest-model module contains 2 submodules |-- xwiki-rest-model-gson ( gson should be corrected to json) |-- xwiki-rest-model-simplexml I think the xwiki-rest-model-gson is redundant. The classes in xwiki-rest-model-simplexml is added with simple xml annotations, otherwise both modules have same classes. There is no problem with the added annotations for using the same model objects for Json REST web services. And I intend to add my JPA (ORMLite library for persistence) annotations on top of it. Shall I re-factor them to a single module xwiki-rest-model. [3] INFO I had to change some pom.xml s. As the current project at: https://github.com/xwiki-contrib/android-client.git does not build. Error with parent pom.xml coordinates. Thank you Best Regards. Sasinda Rukshan

13 years, 3 months

4
10
0 0

[xwiki-devs] Choosing the default component implementation [take 2]

by Sergiu Dumitriu

Hi devs, Hmm, time flies, I realized that it's been a month and a half since I started this thread, but didn't get to counter-argument so far. Because I wanted to give more compelling reasons after I wrote the initial draft of the original proposal, I got slammed with counter arguments centering mostly on why our current implementation already allows to work around the technical difficulties that I presented, although those technical difficulties were just extra arguments that weren't actually that important. Let's start from scratch. I believe that using "default" as a component hint is in most cases wrong, since it doesn't actually say anything about the particular implementation. Let's take some examples: EntityReferenceSerializer, with its many implementations: - "compact", which creates compact representations that don't repeat the parts that are the same as the current document - "compactwiki" that only skips the wiki part when not needed - "path" which creates references usable as a path on the filesystem or in URLs - "uid" which creates non-ambiguous representations - and "default", which does a... default representation... whatever that means... So, while the meaning of the other hints can be guessed from their name, that's not true for "default". WikiModel, with its only implementation, XWikiWikiModel, labeled as "default". First, this "default" is defined in xwiki-platform instead of xwiki-rendering, like the components that actually use that component, which means that we're defining a component interface without any implementation in our "standalone rendering engine", and thus we're using "exceptions as normal decision code" which is wrong. Second, this "default" actually means "xwiki default". Why can't the hint be "xwiki" instead of "default", since that what that implementation is actually doing: "this is the model used in XWiki", and not "this is the default model that most wiki engines use". When looking up an instance of the WikiModel component, we don't request "the default wiki model", but "the wiki model currently in use, whichever that is". ConfigurationSource and its implementations: - "space" which looks into space preferences - "wiki" which looks into wiki preferences - "user" which looks at user preferences - "xwikiproperties" which looks in xwiki.properties - "all" which looks into all the above - "void" which is always empty - "memory" which stores settings explicitly set by code - and "default" which does... stuff... let me get back at you after I look into its code to check what it actually does. XHTMLLinkTypeRenderer is an example where "default" does make sense, since we have special treatment for "doc"ument, "attach"ment, "mailto", "unc", "interwiki", and then there's a "default" that handles all the others, like "url" and "path". I was writing a component called UploadedFileManager, which is supposed to parse uploaded files from a request, and the implementation for it was called CommonsFileUploadManager, since it used the Apache commons-fileupload library for the actual request parsing. I don't think that calling it "default" is appropriate, since in the 3.0 servlet specification the upload behavior is embedded in the specification, in the ServletRequest interface, and that seems more "default" than using a particular library to do the job. A more appropriate hint is "commons", since that's what it actually does: "this implementation handles file uploads by using the apache commons library that does that", and not "this implementation handles file upload in the default way, which everyone should know what it actually is". So, I strongly feel that what the component manager returns when looking up a component without a hint shouldn't be the implementation labeled "default", but one of the existing implementations, as configured somehow. I'm not yet sure how that configuration takes place, that would be the subject of another discussion, but I'd like to get a consensus on whether we need this change or not. -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years, 3 months

4
6
0 0

[xwiki-devs] [VOTE] Add right related method to the wikimacro/oldcore bridge

by Thomas Mortagne

Hi devs, Despite what the documentation is saying anyone can register a wiki macro for the whole wiki so I'm about to fix it. See http://jira.xwiki.org/browse/XWIKI-7880. But to fix it properly IMO I need to add a right checking method to the wikimacro/oldcore own bridge. Right now the right check is a pile of hacks using various APIs (WikiModel for edit, DocumentAccessBridge for programming) and there is no way to test admin right in existing bridges and APIs anyway. Instead of adding more hacks to the current wiki macro right checking I find it better to move the check itself to its existing own model bridge and test it there using the rightservice directly. It also make more sense to have this check at the wiki macro model bridge level than the wiki macro component itself. This is a pretty hidden API that noone is supposed to use except the wiki macro and oldcore but since it's a public interface it makes CLIRR complains so according to our rule here is the vote for adding this new method. WDYT ? Here is my +1. Since the master is now on 4.2 branch I'm committing it right now. Will revert it if anyone gives a veto. -- Thomas Mortagne

13 years, 3 months

4
5
0 0

[xwiki-devs] [GSoC] [SOLR]: search and XWiki rights

by Paul Libbrecht

Dear Savitha, Dear XWiki community, that I know of, there's two major flaws in the current lucene plugin: - It stores and indexes everything which makes it a big memory eater. This will be fixed by Savitha using Solr's schema.xml and hopefully other admin-configurred classes. - Each of the search results' list has to be skimmed through so that the count only covers documents one has access to (this is done in SearchResults.java in getRelevantResults). This has the direct consequence that a search for all documents basically goes through all documents which is quite annoying. In general, the practice of going through many documents, one could say the practice of pre-processing the search-results' list, is a catastrophe. There are very many times when a user inputs a query that matches way too many documents. That means also that Savitha should avoid this skimming in her SOLR module and this needs some skills and probably some help: - the skills to understand completely the rights model. As far as I know it is based on XWikiRights objects in each document and can talk about users (a list of users) and groups. but this needs to be deeply observed and asked many times about. - the skills to map this model into something that is executable by Solr/Lucene queries. In Curriki or i2geo and in many other specific applications, this is much easier because the rights model is simpler (owner is defined, only three rights possible). But this has to be done in a generic way and might include the requirement to reindex a large part of documents if a user joins or leaves a group. I am thinking this can be implemented: include fields such as "prohibitedFor" "prohibitedForGroup", "allowedFor", "allowedForGroup" and use the current users' identity and groups when querying. I note that it is important to care for the user that requests the documents when indexing as well (which probably needs to be admin). Savitha, I think this is the hardest part of your project. Are you up to it? paul

13 years, 3 months

2
3
0 0

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

by Jonathan Solichin

Hello friends, So here is a clearer illustration of what I am aiming for: http://sdrv.ms/LO70JI The font being used in these design is Arial (with changes to make it more unique). I was wondering whether the community would like a more regular looking font, or a bolder and unique one? I would be glad to hear the community's feedback. I tried to bring into account all the comments, but let me know if I missed something. Thanks again, Jonathan Solichin p,s almost done with school (one week), will be able to push faster and better soon. Sorry about that!

13 years, 3 months

3
2
0 0

[xwiki-devs] [UX] [Iteration] Improve History Diff

by Ecaterina Moraru (Valica)

Hi, As you know Thomas and Marius are working on a Diff API and there are also some conflict resolution improvements for the Extension Manager [1]. Marius asked me to think about our current history diff and make some improvements suggestions based on their work. I've made a mockup with some ideas that could improve the History Diff UI http://incubator.myxwiki.org/xwiki/bin/view/Improvements/DiffHistory The UI is mostly based and inspired from GitHub. Let me know what you think. Thanks, Caty [1] http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris…

13 years, 3 months

4
4
0 0

[xwiki-devs] [VOTE] Merge feature-diff-display branch into commons master

by Marius Dumitru Florea

Hi devs, The feature-diff-display branch provides a new diff module, xwiki-commons-diff-display, with APIs to help displaying diffs. Currently it supports two diff formats: unified (GitHub style, suited for code) and inline (suited for free text). I'm using this module for the merge conflict resolution UI and for an improved document compare UI (when comparing two versions from a document history). I'd like to merge the branch ASAP, before 4.1RC1 is released. Here's my +1. Thanks, Marius

13 years, 3 months

6
8
0 0

[xwiki-devs] [WARNING] Release 2 days away, branching now, reply here if you need to commit to the release branch.

by Caleb James DeLisle

Hi, I'm going to be starting the stable-4.1.x please tell me if you need to commit against this branch I would like to know what's going to be committed into this branch so we can hopefully avoid the: "late commits - destabilize the build - delaying the release - allowing more late commits" cycle. Of course I also need to know if anyone needs to hold up the release. Thanks, Caleb

13 years, 3 months

3
3
0 0

[xwiki-devs] [Prooposal] Roadmap for XE 4.1

by Vincent Massol

Hi devs, Roadmap time again for 4.1. Here's a proposal below. If you're a committer/contributor and wish to propose doing something for 4.1 please reply to this thread to have a complete roadmap. For committers who have their names next to tasks below, please confirm you're ok to do that for 4.1. Dates ====== * Started since 16th of April * 4.1M1: 7th of May * 4.1M2: 28th of May * 4.1RC1: 11th of June * 4.1Final: 18th of June Release manager: Caleb, with help from Sergiu/Vincent Content ======= XWiki SAS has had an internal meeting to discuss what it would like to work on and here's the result as a proposal: Top level tasks: * Extension Manager (XEM compatibility, XAR merge UI, full XAR upgrade) - Thomas and Marius ** The goal is to be able to "upgrade a wiki farm in 5 minutes" for 4.1 final * Hidding Technical Content - Jean-Vincent * Important JIRA issues - Sergiu and anyone having some time, see below for the priority list Investigations: * Home Page Changes Proposals - Caty Misc: * GSOC mentoring - All mentors First priority JIRAs (no order): * Add the ability to auto-generate application entry names XWIKI-7374 * Properly display live table columns based on User-type class fields XWIKI-7372 * Be able to rename a space from the UI XWIKI-6722 Second priority JIRAs (no order): * Add Required and Hint meta properties for class fields XWiki-7373 * Generate and register a document bundle for the application XWIKI-7371 * Add document title and document content to the field palette (class editor) XWIKI--7369 * Use suggest input (custom display) for User and Group field types (class editor) XWIKI-7368 * Rename Application (through rename space) XWIKI-6722 * OpenOffice Issues on Windows (bug) XWIKI-7510 * Cannot filter using "/" on a Date column in the livetable XWIKI-5889 * Auto-create Space.WebHome when creating a page in an underfined space XWIKI-5399 * New XWiki Syntax Guide XE-880 * Occasionally the livetable fails to load on index pages XE-844 * tag suggest feature does not work if Main.WebHome is not saved with programming rights XE-539 * Fix XWiki Installer on Windows 7 XE-1051 * XWIKI-6073 Change stylesheet and javascript extension filename when a modification is done on those Unassigned Third priority (no order): * Add more/all configuration parameters in the wiki administration XWIKI-7066 * XWIKI-7510 XWiki is not able to automatically start OpenOffice daemon on Windows Server Unassigned * XWIKI-7509 XWiki automatically connect to an external openoffice daemon Unassigned * XWIKI-7058 Page creation date should be the date of the installation Unassigned * XWIKI-6951 When using filesystem attachments with attachment versioning disabled, deleted attachments are duplicated on the hard disk. CalebJamesDeLisle * XWIKI-6917 Deleted attachments duplication in recycle bin while File Storage is on CalebJamesDeLisle * XWIKI-6892 Log-in automatically on registration Unassigned * XWIKI-6569 Problems displaying the correct attachment version when using a proxy Unassigned * XWIKI-6363 Performance of blog category panel is still not enough Unassigned * XWIKI-6207 Auto-suggest doesn't work for global users Unassigned * XWIKI-5949 Better handling of different timezones for date properties Jean-Vincent Drean * XWIKI-5930 Activity Stream doesn't show Image Profile change Unassigned * XE-1031 Better placement of the documentation link Unassigned * XE-748 Add option to 'show more entries' on displaying the Activity Stream Unassigned WDYT? Thanks -Vincent

13 years, 3 months

11
16
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs