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

[xwiki-devs] Welcoming our GSoC students
by Sergiu Dumitriu 27 Apr '11

27 Apr '11

Hello community, Hello Google Summer of Code students, First of all, congratulations on your applications and your activity during the selection period, and welcome in the XWiki development team. Before guiding the accepted students to their next steps, we'd like to thank again all those who showed interest in XWiki for this Summer of Code. We had a lot of good applications this year, with professional approaches and interesting ideas, and it was very difficult to choose only 3. Unfortunately, some very good students, with great potential, were not accepted. So, to those interested in getting involved anyway, without Google's implication, I renew the invitation to put your ideas in practice under the guidance of the community. Even though the money will be missing, you can still take advantage of the other GSoC benefits: learning new things, gaining experience, earning recognition, etc [1]. If you would like to do that, please let us know by replying to this mail. For the accepted students, here are some getting started hints: = Community bonding period = According to the program timeline [2], the next month (until - May 23rd) is to be used for community bonding. The first thing to do, sometime this week, is to present yourself and your project on the dev list, so that everyone knows who you are and what to expect from you (a precondition is to be subscribed to the list, which you should do ASAP if you haven't already). Also, you should continue getting acquainted with the code, the practices and the developers. Please make sure you all read and understand the following - very useful - documents: - [3] http://purl.org/xwiki/community/ - [4] http://purl.org/xwiki/dev/ - [5] http://platform.xwiki.org/xwiki/bin/view/Features/ = Mentorship = We prefer open mentorship. While your assigned mentor is the one officially in charge with your guidance, almost all interaction should be done 'in the open' as much as possible, on the IRC channel or on the mailing list. You should choose the communication medium according to the importance of the matters to be discussed: naturally, the less important issues are to be discussed on IRC, while the design decisions, important progress announcements and testing/feedback requests go on the list. This way, the community is informed on the evolution of your project, and other developers can come up anytime with useful ideas and suggestions. Moreover, if your mentor is hit by a bus (the bus factor [6]), another developer can take his place with little effort. = Communication = Sitting alone in your room, working secretly on your project is definitely a bad approach. However, please keep in mind that too much communication can also be harmful, as it distracts the others from their own work. You need to be able to communicate just right: - provide meaningful information about your progress, - ask the community's opinion on non-trivial design or implementation decisions - avoid waisting a lot of time on a problem, when a more experienced developer (or a student that fought the same problem) could quickly provide you an answer; however, do try to find the answer yourself at first. Wrong: "Where do I start? What do I do now? And how do I do that? Is this good? It doesn't work, help me!" Right: "Since a couple of hours ago I get a strange exception when building my project, and googling for a solution doesn't seem to help. Looking at the error, I think that there's a wrong setting for the assembly plugin, but nothing I tried works. Can someone please take a look?" Subscribe to the devs list (if you didn't do this already), and start monitoring the discussions. It is also recommended to subscribe to the users list, but not mandatory. The notifications list is a little too high volume and technical for the moment, but it is a great knowledge source. = Development process = The project's lifecycle is NOT design -> implementation -> testing -> documentation. [7] We invite you to adopt a test driven development [8][9][10] approach and to experience agile development [11]. After the first coding week, you must have some code that works. It won't do much, of course, but it will be the seed of your project. Every functionality will be validated by tests. The code must be properly tested and commented at the time of the writing (don't think you'll do that afterwards, because in most cases you won't). Since we've recently moved our codebase to GitHub [12], you should register an account there and fork some xwiki repositories, so that you can try to build XWiki from sources, and be able to contribute bugfixes. We'll add you to the xwiki-contrib organization [13], and we'll create dedicated repositories for each project. We encourage you to do __at least__ weekly commits (ideally, if you are well organized, you should be able to commit code that works daily, so try to aim at daily commits). This way, the code can be properly reviewed, and any problems can be detected before they grow into something too difficult to fix. One big code blob committed at the end, no matter how good it may seem, is a failure at several levels. A simple way of having something functional in the first week is to prepare the maven build for your modules, which will give you the first unit test for the first class. = Next steps, in a nutshell = - Get more familiar with the code and development process and try to master Maven, JUnit, Selenium, component driven development, ... - Continue fixing a few small issues, chosen so that they are __related to your project__. You can ask on IRC for help selecting good issues, or you can pick from the (non-comprehensive) list of easy issues [14] -- This will help you get more familiar with the code your project needs to interact with. - Refine and organize the ideas concerning your project (you can use the Drafts space [15]), and write several use case scenarios. - Start writing the first piece of code for your project. At the end of the community bonding period, you should have a clear vision of the project, well documented on the xwiki.org wiki, you should have the build infrastructure ready, and you should be pretty familiar with the existing code you will need to interact with. And, of course, you should be familiar with the community and the way we communicate. Good luck, and may we all have a great Summer of Code! [1] http://www.catb.org/~esr/writings/cathedral-bazaar/homesteading/ [2] http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/ti… [3] http://purl.org/xwiki/community/ [4] http://purl.org/xwiki/dev/ [5] http://platform.xwiki.org/xwiki/bin/view/Features/ [6] http://en.wikipedia.org/wiki/Bus_factor [7] http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ [8] http://en.wikipedia.org/wiki/Test-driven_development [9] http://www.amazon.com/dp/0321146530/ [10] http://www.amazon.com/dp/0201485672/ [11] http://www.amazon.com/dp/0596527675/ [12] https://github.com/xwiki/ [13] https://github.com/xwiki-contrib/ [14] http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=1… [15] http://dev.xwiki.org/xwiki/bin/view/Drafts/ -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 1

[xwiki-devs] [myxwiki] new wiki request
by Shoubhik Bose 27 Apr '11

27 Apr '11

Hello, Username: sbose78 Server name: nsec I wish to host a student portal for my institution and therefore wish to host it as nsec.myxwiki.org I am hosting something similar at nseccse3.appspot.com but now wish to take advantage of XWiki's architecture . The application would be used for academic collaboration among students. -- Thanks and Regards, Shoubhik Bose IF I REST, I SHALL RUST.. SO, LETS SHARE THE KNOWLEDGE !

2 1

[xwiki-devs] How to find and fix patches
by 许凌志(Jamesxu) 26 Apr '11

26 Apr '11

Hi, I am so glad that I have got accepted in xwiki for gsoc2011. Thanks Marius, Sergiu, and all the other developers in dev mail list, you really helped me a lot during this time. Now, I want to go deeper in xwiki development, first to find some issues in JIRA and send a patch. Is there any documents for how to do this? -- Best wishes, 许凌志(Jame Xu) MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University Department of Computer Science and Technology, Xi’an Jiaotong University

3 5

[xwiki-devs] authenticators?
by Paul Libbrecht 23 Apr '11

23 Apr '11

Hello XWikiers, Has anyone worked on the possibility of signing-up into an XWiki with external authenatications such as Facebook, Google, OpenID, or any such? I don't seem to see this. thanks in advance paul

4 5

[xwiki-devs] BUG FIX [#XWIKI-6491]
by Supreet Pal Singh 22 Apr '11

22 Apr '11

Hey, I think I was successfully able to find a solution for the bug " http://jira.xwiki.org/jira/browse/XWIKI-6491" I have commented the place where the message can be entered that needs to be displayed when no document for the specified tag is found. Also I have limited the number of entries that would be displayed by the "Activity Macro" to 1 when no document is found. You can find the code at the folowing link, the modified code is given in 'red' . I have tried n tested the code on my localhost. https://docs.google.com/document/pub?id=1wV5eM4QE8fF971EtrL2yC2WRzJWpOEhcMO… -- Thanks, Supreet

1 0

[xwiki-devs] XEclipse Navigator node filtering (pages with dots in names are missing)
by Karel Gardas 22 Apr '11

22 Apr '11

Hello, with using latest Eduard's fix (r36321) I'm able to get XEclipse plugins working in Eclipse 3.6.2. Now I see just more minor issue where pages with dots in their names are missing. I.e. my example is using bookstore idea and one of the author put there is "J.R.R.Tolkien". Its page is not shown in XEclipse navigator but is shown on web interface or more exactly in book store space document index in browser I see it but I don't see it inside book store space node in XEclipse Navigator. Is this expected behavior or known issue? Or shall I report it somewhere? Thanks, Karel

2 1

[xwiki-devs] How to develop XEclipse? (compilation issue in latest source code)
by Karel Gardas 22 Apr '11

22 Apr '11

Hello, I've svn co https://svn.xwiki.org/svnroot/xwiki/xeclipse/trunk xeclipse and following information provided on http://dev.xwiki.org/xwiki/bin/view/Community/BuildingInEclipse -- just on the bottom of the page, there is a paragraph describing building of XEclipse plugins inside Eclipse. Now, when I do first two steps: # Within the Eclipse IDE, select [File->Import->Existing Projects into Workspace]. # In the import projects dialog, point [root] directory to [xeclipse/plugins/org.xwiki.eclipse]. I end with the org.xwiki.eclipse project in my workspace, but this project fails with 12 errors like this: Description Resource Path Location Type The method execute(ExecutionEvent) of type ConnectHandler must override a superclass method ConnectHandler.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/handlers line 42 Java Problem The method execute(ExecutionEvent) of type DebugInfoHandler must override a superclass method DebugInfoHandler.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/handlers line 35 Java Problem The method execute(ExecutionEvent) of type DisconnectHandler must override a superclass method DisconnectHandler.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/handlers line 35 Java Problem The method execute(ExecutionEvent) of type GrabSpaceHandler must override a superclass method GrabSpaceHandler.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/handlers line 50 Java Problem The method execute(ExecutionEvent) of type NewConnectionHandler must override a superclass method NewConnectionHandler.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/handlers line 34 Java Problem The method execute(ExecutionEvent) of type NewPageHandler must override a superclass method NewPageHandler.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/handlers line 36 Java Problem The method execute(ExecutionEvent) of type NewSpaceHandler must override a superclass method NewSpaceHandler.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/handlers line 36 Java Problem The method execute(ExecutionEvent) of type OpenPageHandler must override a superclass method OpenPageHandler.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/handlers line 37 Java Problem The method execute(ExecutionEvent) of type RemoveConnectionHandler must override a superclass method RemoveConnectionHandler.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/handlers line 39 Java Problem The method execute(ExecutionEvent) of type RemovePageHandler must override a superclass method RemovePageHandler.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/handlers line 39 Java Problem The method execute(ExecutionEvent) of type RemoveSpaceHandler must override a superclass method RemoveSpaceHandler.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/handlers line 38 Java Problem The method execute(ExecutionEvent) of type XWikiExplorerView.RefreshHandler must override a superclass method XWikiExplorerView.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/views line 109 Java Problem I've verified that this happen on Eclipse 3.4.1, 3.6.2 and also 3.7-M4. Is that a known issue? If so, is there any fix already available for it? Thanks, Karel

3 7

[xwiki-devs] Need help fixing a bug
by Supreet Pal Singh 21 Apr '11

21 Apr '11

Hey I wanted to try and fix a bug. I feel the bug "Some top menu URLs are pointing to the skin wiki instead of the local wiki" <http://jira.xwiki.org/jira/browse/XWIKI-6544> (http://jira.xwiki.org/jira/browse/XWIKI-6544) can be worked upon by me as I have studied velocity and have gone through the code of menuview.vm but I am unable to understand the scenario in which the bug surfaces. If someone could help me understand it , it would be of great help to me. Thanks, Supreet

3 8

Re: [xwiki-devs] Photo Album Application for GSOC 2011
by shweta agrawal 21 Apr '11

21 Apr '11

Hi, I have submitted my proposal of GSOC for idea "Photo Album Application" today. Looking for your feedback. Thanks Shweta Agrawal On Thu, Apr 7, 2011 at 3:01 AM, Ecaterina Moraru (Valica) <valicac(a)gmail.com > wrote: > Hi, > > On Wed, Apr 6, 2011 at 22:23, shweta agrawal <shweta.9996(a)gmail.com>wrote: > >> Hi, >> >> I have identified following task list. >> >> *File Uploading Part -* >> Allow upload of Zip files and Extracting image files from zip archive >> (java.util.zip package). >> //use storage implementation accordingly - filesystem or database. >> //image compression can be done by using java image io api. As Marius >> said there is only resizing capability available in xwiki and jpeg with >> quality near to 60% are optimum for web display, so compression can be used. >> >> >> *Extracting EXIF information from image files.* (This information can be >> stored in a separate db table. I found this >> http://www.drewnoakes.com/drewnoakes.com/code/exif/. It's a java metadata >> extractor library for jpeg image files. ) >> >> Tags - allowing *tagging of attachments*. We can have a separate column >> of tags in the attachment_content table where different tags can be stored >> (separeted via pipeline). WDYT? >> > > Tags can be displayed just for the attachments in the photo application. We > can make it general, but we need to see more use cases. Right now in XWiki > the only things you can add tags are pages. Tags are represented as objects. > > > >> Comments - associating *comments with an attachment*. As I have no idea >> how comments are stored so can't say anything about it right now. >> > > Just like tags, comments are stored as objects to pages. > > >> >> Designing and Implementing *Browsing Interface and Album/Photo >> manipulation interface* >> Browsing Interface - interface that allows users to browse albums easily >> thumbnail view and slide show >> browse based on some metadata info like author or location >> Album manipulation interface >> Add Photos >> Delete Photos >> Managing manipulation rights for the album >> Editing basic info about Album >> Photo Manipulation Interface >> Using canvas element - manipulate rotation, opacity, cropping, adjusting >> gamma, contrast, brightness etc >> Editing basic info about Photo >> >> Currently I am working on gsoc proposal and basic drafts of album browsing >> interface. >> Is this task list ok? >> > > The list is ok. Go ahead and complete your proposal. > > Thanks, > Caty > > >> Further, I am thinking that I should start with Browsing Interface, then >> after that file uploading part and EXIF information extraction will be >> implemented. What do you say? (I need it for describing project plan and >> timeline in gsoc proposal). >> >> Looking for your feedback. >> >> Thanks >> Shweta Agrawal >> >> On Mon, Apr 4, 2011 at 8:05 PM, Ecaterina Moraru (Valica) < >> valicac(a)gmail.com> wrote: >> >> Hi, >>> >>> >>> On Sat, Apr 2, 2011 at 14:03, shweta agrawal <shweta.9996(a)gmail.com>wrote: >>> >>> Hi, >>>> >>>> >>>> I have checked out the HTML 5 specifications for geo-location api, file >>>> uploading api and canvas container. >>>> >>>> At present, all the attachments are stored in database irrespective of >>>> their nature (the old photo album also uses db to store images). I browsed >>>> to find out which is better for storing image files - database or file >>>> system and found that most of the posts favored filesystem (in case of large >>>> number of images). I need your suggestion regarding which one is better in >>>> xwiki's context. In case of using filesystem for storing image files, >>>> migration of older version photo albums will be complicated as image files >>>> will need to be imported from database to file system. >>>> >>> Right now from what I know attachments are stored in the database. Caleb >>> is working on a new storage that will use the filesystem. So IMO you don't >>> have to worry about this aspect and also it will not be very relevant for >>> this project (you will only have to use the storage, not implement it). See >>> http://markmail.org/thread/pl7v4sew2ujksrvv >>> >>> >>>> Secondly, most of the online photo album application (flickr, picasa >>>> web album, facebook) uses image compression for rendering images fastly on >>>> slower networks, so do we also intend to use some compression algorithm and >>>> optimize the image files for display on web. (xwiki can have something of >>>> this sort that is if image size is more than some threshold value (say 1 Mb >>>> or 512 kb) then it can be stored as a compressed image). I haven't checked >>>> out which algorithms are used and does there exist any library or API for >>>> image compression, so can't say how much time it will take to implement. >>>> >>>> I think we already have some image compression on the server side. >>> Marius can give more information about this. See >>> http://markmail.org/thread/kbazwdlgmrlsllcv >>> >>> >>>> what about sharing photo album only with a specific group not all users >>>> and also having manipulating rights to some users only (unlike the old photo >>>> album application, any registered user can add or delete photos created by >>>> some other user)? >>>> >>>> >>>> This won't be a problem either. If the application is located at space >>> level and let's say albums are identified at page level, then you can easily >>> play with the rights system and give permissions just to a group or user, >>> etc. See >>> http://platform.xwiki.org/xwiki/bin/view/Features/RightsManagement >>> >>> Thanks, >>> Caty >>> >>> >>>> Thanks >>>> Shweta Agrawal >>>> >>>> >>>> On Tue, Mar 29, 2011 at 2:35 AM, Ecaterina Moraru (Valica) < >>>> valicac(a)gmail.com> wrote: >>>> >>>> >>>>> >>>>> On Mon, Mar 28, 2011 at 16:38, shweta agrawal <shweta.9996(a)gmail.com>wrote: >>>>> >>>>> Hi, >>>>>> >>>>>> I am Shweta Agrawal, final year computer science student at IIT >>>>>> Roorkee, >>>>>> India. I want to apply for GSoC this year and am interested in working >>>>>> on >>>>>> Photo Album Application. I have four year experience in web >>>>>> development and >>>>>> have good understanding of HTML, CSS, Php, python and Javascript. I >>>>>> have >>>>>> worked on creating user interfaces for a couple of websites and >>>>>> developed >>>>>> applications like online music player (similar to grooveshark), online >>>>>> notice board etc for my Institute's intranet. >>>>>> >>>>>> As far as I understand the project, it's aimed at developing an >>>>>> application >>>>>> where users can >>>>>> >>>>>> - upload the photos (one by one or zip files or folders) with >>>>>> information like date, caption, location etc.- this info can be >>>>>> extracted by >>>>>> reading exif information. *additional* - multiple file selection and >>>>>> upload, drag and drop functionality (supported by HTML 5 compliant >>>>>> browsers). ** *doubt* that do we intend to create a default album >>>>>> for all >>>>>> the images uploaded/attached by user on any of the pages i.e. not >>>>>> only the >>>>>> images that are uploaded for some album. It will provide user an >>>>>> easy way to >>>>>> manipulate and browse through all uploaded image files. >>>>>> >>>>>> the intent is to have albums. This means the user specifies the >>>>> desired photos he wants to add to his album. >>>>> About your idea: to have an album with all the images uploaded by user: >>>>> this is already accessible if you go to Main/AllDocs?view=attachments and >>>>> filter the user. >>>>> >>>>> >>>>>> - create albums and add information like title, caption, >>>>>> description and >>>>>> location. *doubt* - will there be any limit on maximum number of >>>>>> photographs in an album? >>>>>> >>>>>> we don't have any limit on the number of attachments we add to a page, >>>>> so we shouldn't have a limit here either. >>>>> >>>>> >>>>>> - browse through the uploaded photographs (available in browsers >>>>>> not >>>>>> having javascript - It can be done using css3). >>>>>> >>>>> we recently have something like >>>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Gallery+Macro >>>>> and >>>>> >>>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Attachment+Selector+Ma… >>>>> to give you some example of extensions that handle attachment viewers. >>>>> >>>>> >>>>>> - view as thumbnails and slideshow (with adjustable timer and >>>>>> with >>>>>> manual browsing). >>>>>> >>>>>> >>>>>> - migration tool from the old version photo albums. *doubt* - what >>>>>> does >>>>>> old version photo albums refer to? >>>>>> >>>>> This is the very old Photo album application that we want to replace. >>>>> >>>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Photo+Album+Application >>>>> >>>>> >>>>>> - ability to tag and associate comments with attachments. *doubt* - >>>>>> does >>>>>> attachments here refers to image files only or any type of files. >>>>>> >>>>> for the purpose of this project refers to images, but this should be >>>>> extensible so we could comment on any type of files. >>>>> >>>>> >>>>>> I have browsed through the code of older photo album application. I >>>>>> need >>>>>> guidance that is how should I start working on this application? I am >>>>>> thinking about starting with uploading part. >>>>>> >>>>>> Learn a bit XWiki structure and the way applications and extensions >>>>> are done, integrated and reused. >>>>> You can find lots of applications at >>>>> http://extensions.xwiki.org/xwiki/bin/view/Main/ >>>>> You can play with them, see also the source code, etc. >>>>> >>>>> The specifications for this project are very oriented towards the HTML5 >>>>> standard so you should check that out too. >>>>> >>>>> Thanks, >>>>> Caty >>>>> >>>>> >>>>>> Looking forward to your feedback. >>>>>> >>>>>> Regards >>>>>> >>>>>> Shweta Agrawal >>>>>> B.Tech IV YR CSE >>>>>> IIT Roorkee >>>>>> _______________________________________________ >>>>>> devs mailing list >>>>>> devs(a)xwiki.org >>>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>>> >>>>> >>>>> >>>> >>> >> >> >

2 4

[xwiki-devs] [PROPOSAL] Keep working on svn for 3.0 branch
by Thomas Mortagne 21 Apr '11

21 Apr '11

For simplicity I suggest we keep working on svn for the 3.0 branch. The project organization is very different between 3.1 and 3.0 and I don't see us doing the same refactoring on 3.0 branch. It means merging stuff by hand but it's not very hard. WDYT ? -- Thomas Mortagne

4 6