xwiki-devs January 2011

xwiki-devs@xwiki.org

32 participants
67 discussions

[xwiki-devs] FOSDEM 2011: presence of XWiki devs

by Vincent Massol

Hi everyone, FOSDEM (http://www.fosdem.org/2011/) is around the corner (5-6 feb 2011) and some XWiki developers are going: - Anca Luca - Ludovic Dubost - Jerome Velociter - Oana Tabaranu Anca will also give a talk on 6th February, from 14:40 to 14:55 PM, on annotations : "XWiki: Annotating documents, the eXtensible wiki way". Summary: " Since version 2.3, XWiki integrates document annotations in its collaborative environment (http://extensions.xwiki.org/xwiki/bin/view/Extension/Annotations+Application). This talk will focus on the implementation of the annotation feature, with the challenges that an eXtensible wiki implies: handling user collaboration on documents and annotations, annotating dynamically generated content, flexible annotations structure to allow customization. As a default XWiki feature, it allows users to add notes on all types of content, plain unstructured documents or structured documents. It is also used in the Scribo project (http://www.scribo.ws) to manipulate automatic semantic annotations on wiki documents and collaboration around them. Since a demo is worth a thousand words, the presentation will center upon showing all these at work. " So if you intend to go to FOSDEM let us know here and it would be cool to meetup. Some details here: http://www.xwiki.com/xwiki/bin/view/Blog/XWiki%20Fosdem Thanks -Vincent

13 years, 7 months

[xwiki-devs] State of filesystem attachment storage.

by Caleb James DeLisle

Hello, Here's an update on the current state of new filesystem attachment storage: There are a couple platforms on which attachment storage sits: * Transaction handling - This is finished to my satisfaction. We may decide later that it is inadequate or needs changing but it serves this purpose now. * Transaction safe file save/delete - Finished (based on transaction handling) * Serialization - Finished refactoring of XMLWriter and generic Serializer and XMLSerializer. * Providing of files - Mostly finished, needs review to see if there is a cleaner way. Barring any major changes, this should not take longer than 1 day to complete. * Locking - Needed, lock management exists but does not handle deadlock nor "greedy thread" situations. 3 days needed to do code review on Apache commons LockManager to determine if it handles these situations, I'm guessing 2 days are needed to integrate LockManager and in place of the existing lock mechanism and a further 3 days to implement one of the features on top of LockManager if need be. "Consumer" code: * FilesystemAttachmentStore - Complete, enabling requires adding the .jar file to WEB-INF and changing a line in xwiki.cfg. Suffers from deadlock because the locking mechanism, is inadequate. * FilesystemAttachmentVersioningStore - Complete but needs tests, enabling is same as for FilesystemAttachmentStore. 1-2 days should be adequate for testing. * FilesystemAttachmentRecycleBinStore - in progress, 3 days to complete and test (?). Finished DeletedFilesystemAttachment, need TransactionRunnables for saving and deleting and serializer for deleted attachment meta-data. * Need a plan for migrating data from old system. FilesystemAttachmentStore fails over to old store if an attachment cannot be found. Is this correct? Should migration scripts be distributed instead? WDYT? * Consumer code all needs more tests. Any amount of time could be spent on this, I think a week is adequate. Since this contains a large amount of code and all storage code is critical, I think this should go through a release cycle in the platform but disabled by default so that it can be beta tested before it becomes official. WDYT? Caleb

13 years, 7 months

[xwiki-devs] State of the XWiki Community

by Sergiu Dumitriu

Hi Community, The following message expresses my personal opinions as a member of the community, so it might not be entirely accurate. The goal is to start a discussion about how can we attract more contributors and committers to the XWiki open source project, and will address three main subjects: - the current state of the community and committers - the possibility of joining or creating a non-profit foundation to govern XWiki - the possibility of using Fundry as a way for users to fund XWiki development ----- Status of the community At the start of a new year, it's time to look a bit at the status of XWiki, the project and the community. XWiki was created by Ludovic Dubost as an open source project from the start. Later, he founded a commercial company (XWiki SAS, back then XPertNet SaRL) as a way to financially support the development of the product. It kept the project entirely open, unlike the many false open source companies that only offer a basic open source version, forcing people to buy the commercial one (the open core model), or that only release the source code while still doing behind-the-curtains development, or that almost completely ignore the outside community. See the XWiki SAS values: http://purl.org/xwiki/sas-values and manifesto: http://purl.org/xwiki/sas-manifesto The committers, elected for their merit, and not made automatically as employees of the company, always tried to maintain a healthy community and attract new contributors/committers. Thus, the XWiki software is developed not by the XWiki SAS company, but by the XWiki community. http://dev.xwiki.org/xwiki/bin/Community/ has a lot of information about the community, and the development process. As of January 2011, there are 16 core committers, 12 of which are XWiki SAS employees, and 3 are or were related to XWiki SAS one way or another. http://dev.xwiki.org/xwiki/bin/Community/HallOfFame#HCoreCommitters A big part of the development is aided by non-committer members of the community, either by providing patches, testing and reporting bugs, requesting new features, providing feedback, answering on the mailing lists, etc. As committers, we tried to listen to the community when developing the project, but as paid employees we have to also listen to the company requirements. With a limited manpower it's very hard to evolve as fast as the community would want, or in all the directions that the community wants. And we welcome any help here. The project is healthy, we have regular and frequent releases, with visible progress with each new release (see Vincent's statistics on http://massol.myxwiki.org/xwiki/bin/Blog/XWikiIn2010 for more details). Still, I'm a little disappointed with the development speed. Lately, out of the 16 committers on average about 3-4 are actually available for platform development during a day. * How can we help speed up the growth of the community? * How can we attract more developers outside XWiki SAS? ----- Joining/forming a free software foundation One possible reason while so few people are willing to become committers could be that XWiki SAS might appear to over-control the software, and a clear non-profit foundation on top of XWiki might make it more obvious that XWiki is a true open source project, and anybody is welcome to join. XWiki SAS is a member of the OW2 consortium http://ow2.org/ , and this membership also extends a bit to the XWiki project. OW2 used to host all our infrastructure, SVN, mailing lists, downloads... Currently only the official downloads linked from the main download page are hosted on OW2 servers, as we've gradually moved parts of the development infrastructure on servers provided by XWiki SAS. While OW2 is a great home for XWiki SAS, it's mostly a company consortium, not a software development foundation. The most development help coming from OW2 consists of research projects involving both OW2 and XWiki SAS, thus the OW2 membership doesn't bring much value when it comes to code. One option is to form an XWiki non-profit Foundation, which will govern all XWiki-related software development. The main disadvantage would be that there's a risk that it won't make any difference at all, while adding the burden of more paperwork. This is where your opinion comes into play, since there's no point in doing all the hard work if the community doesn't see a clear benefit in it. The Apache Foundation has the huge disadvantage that it requires a license change, but it's a very well known home for software development, with good visibility. The Software Freedom Conservancy has been getting a lot of press recently, since several high profile projects joined it. It's got a few top-notch projects under its hood, so XWiki would be among well known projects in there. A smaller, compatible alternative is Codehaus, but I'm not convinced they would make a difference with respect to our needs. Other foundations aren't really suited for XWiki, since they either don't bring value to the community because they don't foster inter-project collaboration (SourceForge, Google Code), or don't match the project goals (FSF, GNU, Eclipse, Linux, Mozilla...). So, some questions in regard to this subject: * Is there anybody that would like contribute more / become a committer? * Do users believe that a foundation on top of XWiki will help attract more developers? Please note that this is not THE discussion about which foundation to join, just trying to see if there is a benefit in doing so. ----- Supporting code development Becoming a committer requires time, and few people can spend that time when there's no direct benefit involved. XWiki SAS employees are already being paid to work with XWiki, so they can contribute to the platform because the company benefits directly from their work. Employees of other companies that deal with XWiki do spend time contributing, but very few actually got to hang around enough to be voted as committers, although many came close, but stopped short of it. One way of supporting code development is to contact XWiki SAS and sign a contract to develop one or more features with a higher priority. An alternative, which allows to share the cost with other companies/individuals, is to collaboratively request and support feature development (crowdfunding), for example through Fundry, a new site especially designed for this. I've set up an account for XWiki at https://fundry.com/project/58-xwiki . This is also a good place to donate to the XWiki project, since there are no visible ways to financially support the project. Fundry would allow to gather financial incentives for non-employees to contribute more code, thus involving the community more in the direction the software evolves, and attracting more potential contributors. * Do you (the community) think this is a good idea and it would help? * Would you be willing to contribute/donate to the project? ----- Please provide us with your feedback, so we can advance on these topics. Thanks, -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years, 7 months

[xwiki-devs] [discussion] Gadgets in wiki syntax vs gadgets in objects

by Anca Luca

Hi team, I talked on Friday with Vincent about how to approach editing of a dashboard, and we rethought the current approach of specifying the gadgets in a dashboard. Right now, the solution I started to implement is Option 4) in the Dashboard syntax section, http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration#HOption429Colu… , having the gadgets be actual macro calls in wiki syntax in the content of the dashboard macro. This is causing quite some issues on editing, because the wiki syntax of the document needs to be re-generated when the dashboard changes. We detailed another solution, option 5) in the same document http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration#HOption529Gadg… , where gadgets will be specified by objects in the dashboard document, and the dashboard macro call in the page will only mark the point where the objects are read and rendered as a dashboard. Editing should be easier in this case, as the data is more structured than in option 4) (reading and changing object fields). My question here is, does anyone see anything wrong with option 5) ? So far to me it seems a better choice than 4), easier to implement and fixing more problems, and it feels a bit more "semantic" to store the gadgets as structured data, rather than "unstructured" document content. Thanks, Anca

13 years, 7 months

[xwiki-devs] Reminder: Corporate Wiki Users' Perception Survey

by Zeeshan-Ahmed.BHATTI

Hello Everyone, Please help me in my Doctoral dissertation survey about "Corporate Wiki Users' Perception of Wikis". I need respondents(corporate Wiki users) for my web survey on Wiki perceptions. I will highly appreciate your help in this. The survey takes 5 min. If anyone is interested, He/She can also get the results of the study. The link to survey is: http://www.kwiksurveys.com/?s=HBJEMM_bfb8d99c (English) http://www.kwiksurveys.com/?s=HCEKKH_f6159e79 (Français) Thank You All, Regards// Zeeshan Ahmed BHATTI Doctoral Student, IAE Graduate School of Management, Aix-en-Provence, FRANCE Cell: +33(0)632008933

13 years, 7 months

Re: [xwiki-devs] [xwiki-notifications] r34206 - platform/core/trunk/xwiki-skin

by Sergiu Dumitriu

On 01/25/2011 03:29 PM, jvelociter (SVN) wrote: > Author: jvelociter > Date: 2011-01-25 15:29:51 +0100 (Tue, 25 Jan 2011) > New Revision: 34206 > > Modified: > platform/core/trunk/xwiki-skin/pom.xml > Log: > Align name and description with other modules > > > Modified: platform/core/trunk/xwiki-skin/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-skin/pom.xml 2011-01-25 12:49:33 UTC (rev 34205) > +++ platform/core/trunk/xwiki-skin/pom.xml 2011-01-25 14:29:51 UTC (rev 34206) > @@ -7,8 +7,8 @@ > <version>3.0-SNAPSHOT</version> > </parent> > <artifactId>xwiki-core-skin</artifactId> > -<name>XWiki Core - Skin Component</name> > -<description>XWiki Core - Skin Component</description> > +<name>XWiki Platform - Core - Skin</name> This is something I really don't like. The description should not be the same as the name, otherwise there wouldn't be a need to have the same information in two places. The description should be a real description, a full sentence that makes sense and really describes what's the module for. > +<description>XWiki Platform - Core - Skin</description> > <properties> > <xwiki.clirr.skip>true</xwiki.clirr.skip> > </properties> -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years, 7 months

[xwiki-devs] Corporate Wiki Users' Perception Survey

by Zeeshan-Ahmed.BHATTI

13 years, 7 months

[xwiki-devs] [Announcement] XWiki Enterprise 3.0 Milestone 1 Released

by Marius Dumitru Florea

The XWiki development team is pleased to announce the release of XWiki Enterprise 3.0 Milestone 1. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This is the start of the 3.x release cycle, bringing in several backwards-incompatible changes, like removing old deprecated APIs, and upgrading to the new version of Velocity Engine 1.7. Several more major changes are planned for the next 3.0 milestones, like changing the default theme, a new logo for the XWiki Open Source product, upgrading all documents to the 2.0 (or 2.1) syntax, a new administration interface, and many others. The highlights of this release are: * Better WYSIWYG editor support for Opera, Safari and Chorome * More ColorTheme customization options * More standardized UI forms * PDF export improvements * Activity stream performance improvements * Upgrade to Velocity 1.7 For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris… Thanks -The XWiki dev team

13 years, 7 months

[xwiki-devs] [Discussion] Velocity 1.7 - Migration guide?

by Vincent Massol

Hi Sergiu, I'd like to discuss this point that you've made in some other mail: "Velocity 1.7, which brings many new features and improvements, but breaks a lot of velocity macros (still working on fixing the broken code)" Does this mean users who have existing scripts will have things not working anymore? (I guess so if we have broken stuff on our side) If so, what can we do to make them suffer less when upgrading? Can we start by listing broken stuff here and add them to the release notes? Thanks -Vincent

13 years, 7 months

[xwiki-devs] [proposal] Introduce a new persistence engine.

by Caleb James DeLisle

Hi, I have been working hard on filesystem attachments and I found that synchronizing manual filesystem transactions with automatic database transactions was a difficult job and I needed a new tool to do it. So I wrote what I am proposing to be the next XWiki Persistence Engine. I'll start off with the fun part of the proposal, I have been calling it xwiki-store so far but I am so excited about the capabilities of this engine that I don't think it does it justice to name it "store" after the place on the corner with milk and eggs. I am proposing it be named "XWiki Persistence Engine", the directory will be renamed xwiki-persistence, the artifact name xwiki-core-persistence, and the package name org.xwiki.persistence. Persistence is an attribute of castles, mountains and redwood trees which I think is fitting for a conservatively designed storage engine. Now a little explanation of what I'm so excited about: The common and error prone way of saving things in the database is to open a transaction, enter a try clause, do something then commit. If we catch an exception, then we rollback. something like this: begin transaction; try { do something; do something else; commit; } catch (Any exception which may occur) { rollback; } There are 3 things which can go wrong. 1 we forget to begin the transaction, 2 we forget to commit and 3 we do not rollback properly. What makes things worse is often the database will "assume we meant to..." and things will work ok most of the time which makes things much worse because bugs will hide very well. My answer to this problem is a class called TransactionRunnable. It provides a set of 5 empty methods to override: onPreRun(), onRun(), onCommit(), onRollback(), and onComplete(). the exact circumstances under which each are called is documented in the javadoc comments here: http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-… I wrote TransactionRunnable twice, I wrote it, used it for attachments, then after having real experience as a user, I wrote it again. To repeat our original example with TransactionRunnable you might say this: public class DoSomethingTransactionRunnable extends TransactionRunnable { public void onRun() { do something; do something else; } } Now we can use another TransactionRunnable which opens and closes the transaction for us. StartableTransactionRunnable transaction = new HibernateTransactionRunnable(); new DoSomethingTransactionRunnable().runIn(transaction); transaction.start(); the runIn() function allows us to run one TransactionRunnable inside of another. Supposing we wanted to reuse "do something else" in other places, we can make it a separate TransactionRunnable and use the runIn() function to hook it to our DoSomethingTransactionRunnable ie: public class DoSomethingTransactionRunnable extends TransactionRunnable { public DoSomethingTransactionRunnable() { new DoSomethingElseTransactionRunnable().runIn(this); } .. The only limitations on running TransactionRunnables inside of one another are they cannot run more than once and they cannot call themselves (this would be an infinite loop). This pattern makes each job which is done on storage easily isolated and, as I have so far experienced, trivial to test. However, it still leaves the possibility that we might forget that DoSomethingTransactionRunnable must be run inside of a hibernate transaction. I have devised a solution for this too. Using generics, I offered a means for the author of a TransactionRunnable to communicate to the compiler what other TransactionRunnable their runnable must be run in and without explicit casting or defining of an intermediary runnable, this requirement cannot be violated or else it wouldn't compile! Finally we have the issue of starting the runnable. Who's to say I won't be tired one day and just write new DoSomethingTransactionRunnable().start() without opening a transaction first? If DoSomethingTransactionRunnable cannot be safely run outside of a transaction all it needs to do is not extend StartableTransactionRunnable and it won't have any start function. I have taken a multitude of very easy mistakes and given the author of a TransactionRunnable the tools to make it very hard for the user to make them. Also, since a TransactionRunnable has no reason to be very long (it can just branch off into another runnable) this will make testing and code review easy in the place where it is most important. This part of the code is entirely generic and has no dependence on hibernate or anything else. I propose we move: contrib/sandbox/xwiki-store/xwiki-store-transaction/ to: platform/core/xwiki-persistence/xwiki-persistence-transaction And I will propose moving each additional piece in the coming days. WDYT? Caleb

13 years, 7 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs January 2011